I.

Génie logiciel
1. Objectifs d’un processus de
développement
2. Activités de développement
(rappel)
3. Modèles de développement
1. Objectifs d’un processus de développement
Un processus définit :
 QUI (fait quoi);
 QUOI (le travail à faire),
 QUAND (à quel moment )
 et COMMENT ( la manière de le faire)
pour atteindre un certain objectif :

• Construire des modèles d’un ou de plusieurs systèmes

• Organiser projet
• Gérer le cycle de vie du projet de A à Z
• Gérer les risques
• Obtenir de manière répétitive des produits de qualité constante
 2. Activités de développement

Les activités de développements peuvent se résumer en ceci:

 Planification (Étude de la faisabilité)
 Spécification des besoins
 Analyse (Spécification formelle)
 Conception (Spécification technique)
 Implémentation (Codage)
 Tests unitaires
 Intégration et tests
 Livraison
 Maintenance
3. Modèles de développement

Modèle en cascade
 3. Modèles de développement
(suite)
Modèle en V
 3. Modèles de développement
(suite)
Modèle en spirale
 II. Présentation d’UML
Le langage de modélisation unifié, de
l'anglais Unified Modeling Language
(UML), est un langage de modélisation
graphique à base de pictogrammes conçu
pour fournir une méthode normalisée pour
visualiser la conception d'un système. Il est
couramment utilisé en développement
logiciel et en conception orientée objet
UML permet donc de modéliser une application
selon une vision objet.
L’appréhension d’UML est complexe car UML
est à la fois :
• une norme,
• un langage de modélisation objet,
• un support de communication,
• un cadre méthodologique.
L’acceptabilité industrielle de la modélisation objet
passe d'abord par la disponibilité d'un langage
d'analyse objet performant et standard, les auteurs
d'UML préconisent d'utiliser une démarche :
• guidée par les besoins des utilisateurs du système,
• centrée sur l'architecture logicielle,
• itérative et incrémentale.
 La genèse d’UML

Historique des méthodes d’analyse

• Les premières méthodes d'analyse
(années 70)
Découpe cartésienne (fonctionnelle et
hiérarchique) d'un système.
L'approche systémique (années 80)
Modélisation des données + modélisation des
traitements (Merise ...).
L'émergence des méthodes objet (1990-1995)
Prise de conscience de l'importance d'une méthode
spécifiquement objet :
• comment structurer un système sans centrer l'analyse
uniquement sur les données ou uniquement sur les
traitements (mais sur les deux) ?
• Plus de 50 méthodes objet sont apparues durant cette
période (Booch, Classe-Relation,Fusion, HOOD, OMT,
OOA, OOD, OOM, OOSE...) !
• Aucune méthode ne s'est réellement imposée.
 L'unification et la normalisation des méthodes (1995-1997)

En octobre 1994, G. Booch (père fondateur de la

méthode Booch) et J. Rumbaugh (principal
auteur de la méthode OMT) ont décidé de
travailler ensemble pour unifier leurs méthodes
au sein de la société Rational Software. Un an
après, I . Jacobson (auteur de la méthode OOSE
et des cas d’utilisation) a rejoint Rational
Software pour travailler sur l’unification. Unified
Modified Language (UML) est né.
 Les premiers consensus (1995)

• OMT (James Rumbaugh) : vues

statiques, dynamiques et
fonctionnelles d'un système

◦ issue du centre de R&D de General

Electric.
◦ Notation graphique riche et lisible
• OOD (Grady Booch) : vues logiques et
physiques du système
◦ Définie pour le DOD, afin de rationaliser
de développement d'applications ADA,
puis C++.
◦ Ne couvre pas la phase d'analyse dans ses
1ères versions (préconise SADT).
◦ Introduit le concept de package (élément
d'organisation des modèles).
• OOSE (Ivar Jacobson) : couvre
tout le cycle de développement
◦ Issue d'un centre de
développement d'Ericsson, en
Suède.
◦ La méthodologie repose sur
l'analyse des besoins des
utilisateurs.
III. LES DIFFÉRENTS TYPES DE
DIAGRAMME
 Les besoins des utilisateurs (1)

Cette partie représente le cœur de

l’analyse. Il est composé de cas
d’utilisation (que nous verrons plus tard).
On y décrit le contexte, les acteurs ou
utilisateurs du projet logiciel, les
fonctionnalités du logiciel mais aussi les
interactions entre ces acteurs et ces
fonctionnalités. C’est d’ailleurs aussi le
cœur de notre cours. 
 Les besoins des utilisateurs (1)

Le besoin des utilisateurs peut

être décrit à l’aide de deux
diagrammes.
• de package;
• et de cas d’utilisation.
 1. Le diagramme de packages 

permet de décomposer le système en

catégories ou parties plus facilement
observables, appelés « packages ».
Cela permet également d’indiquer les
acteurs qui interviennent dans chacun
des packages.
1. Le diagramme de packages
1. Le diagramme de packages
Ici le système peut être divisé en trois
parties ou packages a savoir :

1. La gestion des commandes client

2. La gestion des stocks
3. La gestion des achats
 2. Le diagramme de cas d’utilisation

 représente les fonctionnalités (ou dit cas

d’utilisation) nécessaires aux utilisateurs.
On peut faire un diagramme de cas
d’utilisation pour le logiciel entier ou
pour chaque package.
2. Le diagramme de cas d’utilisation
 Vue logique (2)
a pour but d’identifier les éléments du
domaine, les relations et interactions entre
ces éléments. Cette vue organise les
éléments du domaine en « catégories ».
Deux diagrammes peuvent être utilisés
pour cette vue à savoir :
• Le diagramme de classes ;
• Le diagramme d’objets.
 3. Le diagramme de classes 
Dans la phase d’analyse, ce diagramme
représente les entités (des informations)
manipulées par les utilisateurs.
Dans la phase de conception, il représente
la structure objet d’un développement
orienté objet.
 4. Le diagramme d’objets 
sert à illustrer les classes complexes en
utilisant des exemples d’instances.
4. Le diagramme d’objets 
 Vue des processus (3)

démontre :
• la décomposition du système en
processus et actions ;
• les interactions entre les processus ;
• la synchronisation et la communication
des activités parallèles.
 Vue des processus (3)

• La vue des processus s’appuie sur

plusieurs diagrammes.
5. Le diagramme de séquence
Les diagrammes de séquences sont la
représentation graphique des
interactions entre les acteurs et le
système selon un ordre chronologique
dans la formulation UML.
5. Le diagramme de séquence
 6. Le diagramme d’activité
Le diagramme d’activité représente le
déroulement des actions, sans utiliser les
objets. En phase d’analyse, il est utilisé
pour consolider les spécifications d’un
cas d’utilisation.
6. Le diagramme d’activité
 7. Le diagramme de collaboration
(appelé également diagramme de
communication) permet de mettre en
évidence les échanges de messages entre
objets. Cela nous aide à voir clair dans les
actions qui sont nécessaires pour produire
ces échanges de messages. Et donc de
compléter, si besoin, les diagrammes de
séquence et de classes.
7. Le diagramme de collaboration
8. Le diagramme d’état-transition 
Le diagramme d’état-transition permet
de décrire le cycle de vie des objets d’une
classe.
9. Le diagramme global d’interaction

 Permet de donner une vue d’ensemble des

interactions du système. Il est réalisé avec
le même graphisme que le diagramme
d’activité. Chaque élément du diagramme
peut ensuite être détaillé à l’aide d’un
diagramme de séquence ou d’un
diagramme d’activité. Ce diagramme ne
sera pas étudié dans ce cours.
9. Lediagramme global d’interaction
 10.Le diagramme de temps
Le diagramme de temps est destiné à
l’analyse et la conception de systèmes
ayant des contraintes temps-réel. Il s’agit
là de décrire les interactions entre objets
avec des contraintes temporelles fortes.
Ce diagramme ne sera pas étudié dans ce
cours.
10. Le diagramme de temps
 Vue des composants (4)
 (vue de réalisation) met en évidence
les différentes parties qui
composeront le futur système
(fichiers sources, bibliothèques,
bases de données, exécutables, etc.).
Cette vue comprend deux
diagrammes.
11.Le diagramme de structure composite

 Décrit un objet complexe lors de son

exécution. Ce diagramme ne sera pas
étudié dans ce cours
11. Le diagramme de structure
composite
12.Le diagramme de composants

 Décrit tous les composants utiles à

l’exécution du système (applications,
librairies, instances de base de
données, exécutables, etc.).
12.Le diagramme de composants
 Vue de déploiement (5)

La vue de déploiement décrit les

ressources matérielles et la répartition
des parties du logiciel sur ces éléments.
Il contient un diagramme :
13.Le diagramme de déploiement

Le diagramme de
déploiement correspond à la
description de l’environnement
d’exécution du système (matériel,
réseau…) et de la façon dont les
composants y sont installés.
13.Le diagramme de déploiement
A. LES BESOINS DES UTILISATEURS
a. LE DIAGRAMME DE CAS
D'UTILISATION
 Sommaire
1. Introduction
2. Acteur
3. Cas d’utilisation
4. Relation ou lien
5. Description textuelle du cas d’utilisation
UML permet de définir et de visualiser un modèle, à
l'aide de diagrammes.

Un diagramme UML est une représentation

graphique, qui s'intéresse à un aspect précis du
modèle.

C'est une perspective du modèle, pas "le modèle".

Chaque type de diagramme UML possède une
structure (les types des éléments de modélisation
qui le composent sont prédéfinis).

Un type de diagramme UML véhicule une

sémantique précise (un type de diagramme offre
toujours la même vue d'un système).
Combinés, les différents types de diagrammes
UML offrent une vue complète des aspects
statiques et dynamiques d'un système.

Par extension et abus de langage, un diagramme

UML est aussi un modèle (un diagramme
modélise un aspect du modèle global).
 Définition
Les cas d’utilisations permettent de
structurer les besoins des utilisateurs et les
objectifs correspondants d'un système. Ils
centrent l'expression des exigences du
système sur ses utilisateurs : ils partent du
principe que les objectifs du système sont
tous motivés.
 Définition
La détermination et la compréhension des
besoins sont souvent difficiles car les
intervenants sont noyés sous de trop grandes
quantités d'informations : il faut clarifier et
organiser les besoins des clients (les modéliser).
Pour cela, les cas d’utilisation identifient les
utilisateurs du système (acteurs) et leurs
interactions avec le système. Ils permettent de
classer les acteurs et structurer les objectifs du
système.
 Définition
Une fois identifiés et structurés, ces besoins :
• définissent le contour du système à modéliser (ils
précisent le but à atteindre),
• permettent d'identifier les fonctionnalités
principales (critiques) du système.
Les use cases ne doivent donc en aucun cas décrire
des solutions d'implémentation. Leur but est
justement d'éviter de tomber dans la dérive d'une
approche fonctionnelle, où l'on liste une litanie de
fonctions que le système doit réaliser.
Le premier diagramme dessiné est le diagramme de cas
d’utilisation. Les cas d’utilisation sont développés par du
texte dans des scénarios non représentés dans le
diagramme. Les scénarios seront modélisés par des
diagrammes d’activité présentés dans la section suivante.
Les éléments de modèle d’un diagramme de cas
d’utilisation sont les acteurs extérieurs au système
contenant les cas d’utilisation. Les interactions des
acteurs avec les cas d’utilisation du système sont
modélisées par des liens de communication.
 Système
La première étape de modélisation
consiste à définir le périmètre du système,
à définir le contour de l’organisation et à
le modéliser.
 Acteur
• Toute entité qui est en dehors système et qui interagit
avec lui est appelé acteur selon UML.
• Un acteur est un type stéréotypé représentant une
abstraction qui réside juste en dehors du
système à modéliser.
• Un acteur représente un rôle joué par une personne
ou une chose qui interagit avec le système. (la même
personne physique peut donc être représentée par
plusieurs acteurs en fonction des rôles qu’elle joue).
• Pour identifier les acteurs, il faut donc se
concentrer sur les rôles joués par les entités
extérieures au périmètre.
• Dans UML, il n’y a pas de notion d’acteur
interne et externe. Par définition, un acteur est
externe au périmètre de l’étude, qu’il
appartienne ou pas à la société.
• Enfin, un acteur n’est pas nécessairement une
personne physique : il peut être un service,
une société, un système informatique…
Il existe 4 catégories d’acteurs :
•les acteurs principaux : les personnes qui utilisent les
fonctions principales du système

• les acteurs secondaires : les personnes qui effectuent

des tâches administratives ou de maintenance.

•le matériel externe : les dispositifs matériels

incontournables qui font partie du domaine de
l’application et qui doivent être utilisés.

•les autres systèmes : les systèmes avec lesquels le

système doit interagir.
 Acteur

Formalisme
 Acteur
Un acteur est une « entité » externe au système qui
interagit avec le système. La notation UML de
l’acteur est soit le dessin « simplifié » d’un personnage
complété en dessous par un libellé soit le dessin d’un
rectangle contenant le libellé du nom de l’acteur en
dessous du libellé du stéréotype1 «« acteur» ».
La notation graphique que nous préférons est bien sûr
le dessin du personnage, plus facile à repérer dans un
diagramme
Une attention particulière doit être attachée au nommage
des acteurs. L’usage veut de choisir un substantif extrait
du cahier des charges, donc proposé par le client ou
l’utilisateur final. En effet, rappelons que les
diagrammes de cas d’utilisation sont une modélisation
directe du cahier des charges et servent au client pour
vérifier que l’analyste comprend le problème du client.
Il est donc important que l’équipe de développement
s’adapte au client et montre qu’elle s’adapte au domaine
applicatif, c’est-à-dire au métier du client.
 Le cas d’utilisation

Le cas d’utilisation (ou use case) correspond à un

objectif du système, motivé par un besoin d’un ou
plusieurs acteurs.
L'ensemble des use cases décrit les objectifs (le
but) du système.
Formalisme

Cas d’utilisation
 Relation ou lien

Elle exprime l’interaction existant entre un

acteur et un cas d’utilisation.
Formalisme

Use case
Lien ou relation
Nom acteur
 Relation ou lien

Il existe 3 types de relations entre cas d’utilisation

:
• la relation de généralisation
• la relation d’extension
• la relation d’inclusion
 Relation ou lien

La relation de généralisation :
Dans une relation de généralisation entre 2 cas
d’utilisation, le cas d’utilisation enfant est une
spécialisation du cas d’utilisation parent
• Comme pour les classes, le sous-cas d’utilisation hérite du
comportement du sur-cas d’utilisation. Le sous-cas d’utilisation hérite
aussi de toutes les associations du sur-cas (relations d’association avec
les acteurs, relations d’inclusions, et relations d’extensions).
• Quelquefois, le sur-cas d’utilisation est abstrait (c’est-à-dire qu’il ne
peut pas être instancié). Il correspond à un comportement partiel et
sert uniquement de base pour les sous-cas d’utilisation qui en
hériteront.
• La relation de généralisation est représentée par une flèche avec
une extrémité triangulaire.
• Le nom d’un cas d’utilisation abstrait est écrit en italique (ou
accompagné du stéréotype « abstract »).
 Relation ou lien

Formalisme exemple
Cas d’utilisation
Virement bancaire
parent

Cas d’utilisation
enfant Virement par internet
 Relation ou lien

un acteur peut également participer à des relations

de généralisation avec d’autres acteurs. Les acteurs
« enfant » seront alors capables de communiquer
avec les mêmes cas d’utilisation que les acteurs «
parents ».
 Relation ou lien

Formalisme
 Relation ou lien
La relation d’inclusion:
Elle indique que le cas d’utilisation source contient
aussi le comportement décrit dans le cas d’utilisation
destination. L’inclusion a un caractère obligatoire, la
source spécifiant à quel endroit le cas d’utilisation
cible doit être inclus. Cette relation permet ainsi de
décomposer des comportements et de définir des
comportements partageables entre plusieurs cas
d’utilisation
 Relation ou lien
Formalisme : Reservation

Pour réaliser l’objectif

« reservation », « include »
on utilise obligatoirement
« s’authentifier».

S’authentifier
 Relation ou lien
La relation d’extension :
Elle indique que le cas d’utilisation source ajoute son
comportement au cas d’utilisation destination.
L’extension peut être soumise à condition.
Le comportement ajouté est inséré au niveau d’un point
d’extension défini dans le cas d’utilisation destination.
Cette relation permet de modéliser les variantes de
comportement d’un cas d’utilisation (selon les
interactions des acteurs et l’environnement du système).
 Relation ou lien
Formalisme

virement « extend» Vérification solde du

compte
 Multiplicité
Lorsqu’un acteur peut interagir plusieurs fois
avec un cas d’utilisation, il est possible d’ajouter
une multiplicité sur l’association du côté du cas
d’utilisation. Le symbole * signifie plusieurs.
Exactement n s’écrit tout simplement n, n..m
signifie entre n et m, etc. Préciser une
multiplicité sur une relation n’implique pas
nécessairement que les cas sont utilisés en même
temps.
Multiplicité
 Point d’extension
• L’extension peut intervenir à un point précis du cas
étendu. Ce point s’appelle le point d’extension. Il
porte un nom, qui figure dans un compartiment du
cas étendu sous la rubrique point d’extension, et est
éventuellement associé à une contrainte indiquant
le moment où l’extension intervient. Une extension
est souvent soumise à condition.

• Graphiquement, la condition est exprimée sous la

forme d’une note.
Point d’extension
Description textuelle des cas d’utilisation

Ce n’est pas obligatoire, mais il est recommandé

de rédiger une description textuelle de chaque
cas d’utilisation afin de les détailler.
• Une description textuelle classique se compose de trois
parties :

Partie 1 : Identification.
Titre : Nom du cas d’utilisation
Résumé : description du cas d’utilisation. –
Acteurs : descriptions des acteurs principaux et secondaires.
Dates : Date de création et date de mise à jour.
Responsable : Noms du ou des responsables.
Version : Numéro de la version.
Partie 2 : Description des scénarios.
 Les pré-conditions : État du système avant que le cas
d’utilisation puisse être déclenché.
 Les Scénarios (un scénario est une instance d’un cas
d’utilisation dans lequel tous les paramètres ont été fixés). Il
y a plusieurs types de scénarios :
o Le scénario nominal qui correspond à un déroulement normale d’un
cas d’utilisation.
o Les scénarios alternatifs qui sont des variantes du scénario normale.
o Les scénarios d’exceptions qui décrivent ce qui se passe lors d’une
erreur. - Les post-conditions : Elles décrivent l’état du système après
l’issue de chaque scénario.
• Partie 3 : Exigence non fonctionnelle.
La partie 3 peut être omise, mais si elle est
présente, elle permet de préciser des
spécifications non fonctionnelles (fréquence,
fiabilité, type d’interface homme-.machine...).
Exemple de description textuelle:
Le cas d‘utilisation ‘Retirer de l’argent’ du DAB

Partie 1 : Description.
Titre : Retirer de l’argent.
Résumé : Ce cas d’utilisation permet aux possesseurs de carte
bancaire de retire de l’argent.
Acteur principale : Un porteur de carte bancaire.
Acteurs secondaires : Le Système d’Information de la banque et le
Système d’Autorisation Globale Carte Bancaire.
Date : 11/03/2020
Responsable : Belespoir KOUALA
Version : 1.0
Partie 2 : Description des scénarios.
• Pré-conditions :
– Le DAB contient des billets.
– Les connexions avec le Système d’Autorisation et
le Système d’information de la banque sont
opérationnelles.
Partie 2 : Description des scénarios.
• Scénario nominale :
1. Le Porteur de carte introduit sa carte dans le DAB.
2. Le DAB vérifie que la carte introduite est bien une carte
bancaire.
3. Le DAB demande le code de la carte au Porteur de carte.
4. Le Porteur de carte saisit son code.
5. Le DAB compare ce code avec celui qui est codé sur la carte.
6. Le DAB demande une autorisation au Système Globale
d’autorisation
7. Le Système d’Autorisation globale donne son accord et
indique le crédit hebdomadaire.
8. Le DAB demande le montant désiré au Porteur de carte.
Partie 2 : Description des scénarios.
• Scénario nominale(suite) :
9. Le Porteur de carte saisit le montant.
10. Le DAB vérifie si le montant demandé est inférieur ou égale au
crédit hebdomadaire.
11. Le DAB rend la carte et demande au Porteur de carte de la retirer.
12. Le Porteur de carte reprend sa carte.
13. Le DAB demande au Porteur de carte s’il désire un ticket.
14. Le Porteur de carte accepte le ticket.
15. Le DAB délivre le ticket et les billets.
16. Le Porteur de carte prend les billets et le ticket.
 Partie 2 : Description des scénarios.

• Scénarios alternatifs :
Scénario alternatif SA1: Le code est erroné
pour la première ou la deuxième fois.
SA1 commence au point 5 du scénario nominale.
Le DAB indique que le code est erroné.
Le DAB enregistre l’échec.
Le scénario reprend au point 3 du scénario nominal
Scénario alternatif SA2: Le montant demandé
est trop élevé.
SA2 commence au point 10 du scénario
nominale.
Le DAB affiche le montant max et demande au
Porteur de carte de ressaisir un montant.
Le scénario reprend au point 9 du scénario
nominal.
 Scénario alternatif SA3: Le ticket est refusé.
SA1 commence au point 13 du scénario
nominale.
14) L’utilisateur refuse le ticket.
15) Le DAB délivre les billets.
16) L’utilisateur prend les billets.
Scénario alternatif SA4: Le porteur de carte est
client de la banque.
SA1 commence au point 7 du scénario nominale.
Le DAB demande une autorisation auprès du
Système d’Information de la banque.
Le scénario reprend au point 9 du scénario nominal.
• Scénarios d’exception:
Scénario d’exception SE1: Carte non valide.
SE1 commence au point 2 du scénario nominal.
Le DAB Indique que la carte n’est pas valide restitue
la carte et met fin au cas.
Scénario d’exception SE2: Le code est erroné
pour la troisième fois.
SE2 commence au point 5 du scénario nominal.
Le DAB Indique que le code est erroné pour la
troisième fois, confisque la carte et met fin au
cas.
Scénario d’exception SE3: Retrait non autorisé.
SE3 commence au point 6 du scénario nominal.
Le DAB Indique que tout retrait est impossible,
restitue la carte et met fin au cas.
Scénario d’exception SE4: Carte non reprise.
SE4 commence au point 11 du scénario nominal.
Au bout de 30s, le DAB confisque la carte et met
fin au cas.
Scénario d’exception SE5: Billets non pris.
SE5 commence au point 15 du scénario nominal.
Au bout de 30s, le DAB reprend les billets et
met fin au cas.
Scénario d’exception SE6: Annulation de la
transaction.
SE6 peut démarrer entre les points 4 et 9 du
scénario nominal.
Le DAB éjecte la carte et met fin au cas.
• Post-conditions:
Les détails de la transaction doivent être
enregistrés (montant, numéro carte, date…) aussi
bien en cas de succès que d’échec.
Partie 3 : Exigences non fonctionnelles

La saisie du code confidentiel ne doit pas faire

apparaître le code à l’écran.
Le compte du client ne doit pas être débité tant
que le billets n’ont pas été distribués.