Génie Logiciel

1
CHAPITRE I : DEFINITIONS GENERALES, PRINCIPES, PROCESSUS
I. Définition et objectifs du génie logiciel (GL)
I.1. Définition
Domaine des sciences de l‟ingénieur dont la finalité est la conception,

la fabrication et la maintenance de systèmes logiciels complexes, sûrs et de
qualité („Software Engineering‟ en anglais). Aujourd‟hui les économies de tous
les pays développés sont dépendantes des systèmes logiciels.
Le Génie logiciel se définit souvent par opposition à la

„programmation‟, c'est-à-dire la production d‟un programme par un individu
unique, considérée comme „facile‟. Dans le cas du GL il s‟agit de la fabrication
collective d‟un système complexe, concrétisée par un ensemble de documents de
conception, de programme et de jeux de tests avec souvent de multiples versions
(« multi-person construction of multi-version software »), et considérée comme
„difficile‟.
I.2. Objectifs – la règle du CQFD
Le GL se préoccupe des procédés de fabrication des logiciels de façon

à s‟assurer que les 4 critères suivants soient satisfaits.
 Le système qui est fabriqué répond aux besoins des utilisateurs (correction
fonctionnelle).
 La qualité correspond au contrat de service initial. La qualité du logiciel
est une notion multiforme qui recouvre :
o -la validité : aptitude d‟un logiciel à réaliser exactement les tâches
définies par sa spécification,
o -la fiabilité : aptitude d‟un logiciel à assurer de manière continue le
service attendu,
Prof. Pierre KAFUNDA KATALAY

En collaboration avec CT Anaclet TSHIKUTU Bikengela D.
2
o -la robustesse : aptitude d‟un logiciel à fonctionner même dans des

conditions anormales,
o -l‟extensibilité : facilité d‟adaptation d‟un logiciel aux changements de
spécification,
o -la réutilisabilité : aptitude d‟un logiciel à être réutilisé en tout ou
partie,
o -la compatibilité : aptitude des logiciels à pouvoir être combinés les
uns aux autres,
o -l‟efficacité : aptitude d‟un logiciel à bien utiliser les ressources
matérielles telles la mémoire, la puissance de l‟U.C., etc.
o -la portabilité : facilité à être porté sur de nouveaux environnements
matériels et/ou logiciels,
o -la traçabilité : capacité à identifier et/ou suivre un élément du cahier
des charges lié à un composant d‟un logiciel,
o -la vérifiabilité : facilité de préparation des procédures de recette et de
certification,
o -l‟intégrité : aptitude d‟un logiciel à protéger ses différents composants
contre des accès ou des modifications non autorisés,
o -la facilité d‟utilisation, d‟entretien, etc.
 Les coûts restent dans les limites prévues au départ.
 Les délais restent dans les limites prévues au départ.
Règle du CQFD : Coût qualité Fonctionnalités Délai.
Ces qualités sont parfois contradictoires (chic et pas cher). Il faut les
pondérer selon les circonstances (logiciel critique / logiciel grand public). Il faut
aussi distinguer les systèmes sur mesure et les produits logiciels de grande
diffusion.

3
I.3. L’état des lieux
Le GL est apparu dans les années 70 pour répondre à la crise du

logiciel. Cette crise est apparue lorsque l‟on a pris conscience que le coût du
logiciel dépassait le coût du matériel. Aujourd‟hui il le dépasse très largement.
Coût logiciel vs matériel La « crise du logiciel »
100%
50%
50 60 70 80 90 200
Figure 1.1 La crise du logiciel
Un autre symptôme de cette crise se situe dans la non qualité des

systèmes produits. Les risques humains et économies sont importants, comme
l‟illustrent les quelques exemples célèbres suivants :
 Arrêt de Transpac pour 7.000 entreprises et 1.000.000 d‟abonnés :
surcharge du réseau,
 TAURUS, un projet d‟informatisation de la bourse londonienne :
définitivement abandonné après 4 années de travail et 100 millions de 
de pertes,
 Mission VENUS : passage à 500.000 Km au lieu de 5.000 km à cause du
remplacement d‟une virgule par un point,
 Avion F16 déclaré sur le dos au passage de l‟équateur : non prise en
compte du référentiel hémisphère sud,

4
 Avion C17 de McDonnel Douglas livré avec un département de 500

millions de $ … (19 calculateurs hétérogènes et 6 langages de
programmation différents),
 Faux départ de la première navette colombus : manque de synchro entre
calculateurs assurant la redondance (un délai modifié de 50ms à 80 ms
entraînant une chance sur 67 d‟annulation par erreur de la procédure de
tir),
 Non reconnaissance de l‟EXOCET dans la guerre des malouines : Exocet
non répertorié comme missile ennemi : 88 morts,
 Non différenciation entre avion civil et avion militaire : guerre du Golfe –
Airbus iranien abattu : 280 morts,
 Mauvais pilote automatique de la commande d‟une bombe au cobalt en
milieu hospitalier : 6 morts,
 Echec d‟Ariane 501 (cf, exercice 1.1 ci-dessous).
D‟après le cabinet de conseil en technologie de l‟information Standish

Group International, les pannes causées par des problèmes de logiciel ont coûté
en 2004 aux entreprises du monde entier environ 175 milliards de dollars, soit
deux fois plus au moins qu‟il y a 2 ans (le Monde 23/10/01).
La solution imaginée pour répondre à cette crise a été

l‟industrialisation de la production du logiciel : organisation des procédés de
production (cycle de vie, méthodes, notations, outils), des équipes de
développement, plan qualité rigoureux, etc. malgré tout le GL reste aujourd‟hui
moins avancé (formalisé, mathématique) et moins bien codifié que d‟autres
„sciences de l‟ingénieur‟, comme le génie civil qui construit des routes et des
ponts, ou le génie chimique. Une des raisons est la nature même du logiciel :

5
 Le logiciel est un objet immatériel (pendant son développement), très

malléable au sens facile à modifier (cf. « hardware/software »),
 Ses caractéristiques attendues sont difficiles à figer au départ et souvent
remises en cause en cours de développement,
 Les défaillances et erreurs ne proviennent ni de défauts dans les matériaux
ni de phénomènes d‟usure dont on connaît les lois mais d‟erreurs
humaines, inhérentes à l‟activité de développement,
 Le logiciel ne s‟use pas, il devient obsolète (par rapport aux concurrents,
par rapport au contexte technique, par rapport aux autres logiciels, …),
 Le développement par assemblage de composants est encore balbutiant
dans le domaine logiciel (beans, EJB, composants CORBA, …),
Cependant, grâce au GL des progrès ont été réalisés. Mais la

complexité des systèmes ne cesse de s‟accroître.
I.4. Caractéristiques (3)
Le GL est en forte relation avec presque tous les autres domaines de

l‟informatique : langages de programmation (modularité, orientation objet,
parallélisme, …), bases de données (modélisation des données, de leur
dynamique, …), informatique théorique (automates, réseaux de Pétri, types
abstraits, …), etc. comme le génie chimique utilise la chimie comme un outil
pour résoudre des problèmes des production industrielle, le GL utilise
l‟informatique comme un outil pour résoudre des problèmes de traitement de
l‟information. Le GL est aussi en relation avec d‟autres disciplines de
l‟ingénieur : ingénierie des systèmes et gestion de projets, sûreté et fiabilité des
systèmes, etc. les principales branches du GL couvrent :
 La conception,
 La validation/vérification,
 La gestion de projet et l‟assurance qualité,
6
 Les aspects socio-économiques.
I.5. Les principes(4)
Cette partie liste sept principes fondamentaux (proposés par Carlo

Ghezzi) :
 Rigueur,
 Séparation des problèmes (« separation of concerns »),
 Modularité,
 Abstraction,
 Anticipation du changement,
 Généricité,
 Construction incrémentale.
5.1 Rigueur
La production de logiciel est une activité créative, mais qui doit se

conduire avec une certaine rigueur. Certains opposent parfois créativité et
rigueur. Il n‟y a pas contradiction : par exemple, le résultat d‟une activité de
création pure peut être évalué rigoureusement, avec des critères précis.
Le niveau maximum de rigueur est la formalité, c'est-à-dire le cas où

les descriptions et les validations s‟appuient sur des notations et lois
mathématiques. Il n‟est pas possible d‟être formel tout le temps : il faut bien
construire la première description formelle à partir de connaissances non
formalisées  mais dans certaines circonstances les techniques formelles sont
utiles.
5.2. ‘’Séparation des problèmes’’

7
C‟est une règle de bons sens qui consiste à considérer séparément

différents aspects d‟un problème afin d‟en maîtriser la complexité. C‟est un
aspect de la stratégie générale du « diviser pour régner ».
Elle prend une multitude de formes :

 Séparation dans le temps (les différents aspects sont abordés
successivement), avec la notion de cycle de vie du logiciel que nous
étudierons en détail,
 Séparation des qualités que l‟on cherche à optimiser à un stade donné
(ex : assurer la correction avant de se préoccuper de l‟efficacité),
 Séparations des „vues‟ que l‟on peut avoir d‟un système (ex : se
concentrer sur l‟aspect „flots de données‟ avant de considérer l‟aspect
ordonnancement des opérations ou „flot de contrôle‟),
 Séparation du système en parties (un noyau, des extensions, …),
 Etc.
Les méthodes aident à organiser le travail en guidant dans la séparation

et l‟ordonnancement des questions à traiter.
5.3. Modularité
Un système est modulaire s‟il est composé de sous-systèmes plus

simples, ou modules. La modularité est une propriété importante de tous les
procédés et produits industriels (cf. Industrie automobile ou le produit et le
procédé sont très structurés et modulaires).
La modularité permet de considérer séparément le contenu du module

et les relations entre modules (ce qui rejoint l‟idée de séparation des questions).
Elle facilite également la réutilisation de composants bien délimités.

8
Un bon découpage modulaire se caractérise par une forte cohésion

interne des modules (ex : fonctionnelle, temporelle, logique, ..) et un faible
couplage entre les modules (relations inter modulaires en nombre limitée et
clairement décrites).
Figure 2.1 La modularité
Toute l‟évolution des langages de programmation vise à rendre plus

facile une programmation modulaire, appelée aujourd‟hui „programmation
composants‟.
5.4. Abstraction
L‟abstraction consiste à ne considérer que les aspects jugés importants

d‟un système à un moment donné, en faisant abstraction des autres aspects (c‟est
encore un exemple de séparation des problèmes).
Une même réalité peut souvent être décrite à différents niveaux

d‟abstraction. Par exemple, un circuit électronique peut être décrit par un
modèle mathématique très abstrait(équation logique), ou par un assemblage de
composants logiques qui font abstraction des détails de réalisation (circuit
logique) , ou par un plan physique de composants réels au sein d‟un circuit
intégré. L‟abstraction permet une meilleure maîtrise de la complexité.

9
5.5. Anticipation du changement
Le caractéristique essentielle du logiciel, par rapport à d‟autres

produits, est qu‟il est presque toujours soumis à des changements continues
(corrections d‟imperfections et évolutions en fonctions de besoins qui changent).
Ceci requiert des efforts particuliers pour prévoir, faciliter et gérer ces
évolutions inévitables. Il faut par exemple :
 Faire en sortie que les changements soient les plus localisés possibles
(bonne modularité),
 Etre capable de gérer les multiples versions des modules et configurations
des versions des modules, constituant des versions du produit complet.
5.6. Généricité
Il est parfois avantageux de remplacer la résolution d‟un problème

spécifique par la résolution d‟un problème plus général. Cette solution générique
(paramétrable ou adaptable) pourra être réutilisée plus facilement.
Exemple : plutôt que d‟écrire une identification spécifique à un écran

particulier, écrire (ou réutiliser) un module générique d‟authentification (saisie
d‟une identification – éventuellement dans une liste et éventuellement d‟un mot
de passe).
5.7. Construction incrémentale
Un procédé incrémental atteint son but par étapes en s‟en approchant

de plus en plus ; chaque résultat est construit en étendant le précédent.
On peut par exemple réaliser d‟abord un noyau des fonctions

essentielles et ajouter progressivement les aspects plus secondaires. Où encore,

10
construire une série de prototypes „simulant‟ plus ou moins complètement le

système envisagé.
5.8. Conclusion
Ces principes sont très abstraits et ne sont pas utilisables directement.

Mais ils font partie du vocabulaire de base du génie logiciel. Ces principes ont
un impact réel sur beaucoup d‟aspects (on le verra dans la suite du cours) et
constituent le type de connaissance le plus stable, dans un domaine où les outils,
les méthodes et les techniques évoluent très vite.
I.6. PROCESSUS DE DÉVELOPPEMENT LOGICIEL (modèles de cycle de vie)
Un processus définit une séquence d’étapes, en partie ordonnées, qui

concourent à l’obtention d’un système logiciel ou à l’évolution d’un système
existant. L’objet d’un processus de développement est de produire des logiciels
de qualité qui répondent aux besoins de leurs utilisateurs dans des temps et des
coûts prévisibles.
6.1. Définitions
Comme pour toutes les fabrications, il est important d‟avoir un

procédé de fabrication du logiciel défini et explicitement décrit et documenté.
En GL, il s‟agit d‟un type de fabrication un peu particulier : en un seul
exemplaire, car la production en série est triviale (recopie).
Les modèles de cycle de vie du logiciel décrivent à un niveau très

abstrait et idéalisé les différentes manières d‟organiser la production. Les étapes,
leur ordonnancement, et parfois les critères pour passer d‟une étape à une autre
sont explicités (critères de terminaison d‟une étape – revue de document, critères
de choix de l‟étape suivante, critères de démarrage d‟une étape).
Il faut souligner la différence entre étapes (découpages temporel) et

activités (découpage selon la nature du travail). Il y a des activités qui se

11
déroulent dans plusieurs étapes (ex : la spécification, la validation et la

vérification), voire dans toutes les étapes (ex : la documentation).
Rappelons aussi la différence entre vérification et validation (B.

Boehm, 76) :
-Verification: « are we building the product right ? “ (“Construisons
nous le produit correctement ?” , correction interne du logiciel, concerne les
utilisateurs),
-Validation : « are we building the rigth product » (« construisons nous
le bon produit ? », adaptation vis à vis des besoins des utilisateurs, concerne les
utilisateurs).
6.2. Le modèle en cascade (‘waterfall’)
Historiquement, la première tentative pour mettre de la rigueur dans le

„développement sauvage‟ (coder et corriger ou „code and fix‟) a consisté à
distinguer une phase d‟analyse avant la phase d‟implantation (séparation des
questions).
Analyse
Implantation
Très vite,
Figure 3.1 Lependant les années
modèle primitif 70,
à phases
on s‟est aperçu qu‟un plus grand nombre d‟étapes étaient nécessaires
pour organiser le développement des applications complexes. Il faut en
particulier distinguer l‟analyse du „quoi faire ?‟ qui doit être validée par rapport
aux objectifs poursuivis et la conception du „comment faire ?, qui doit être
vérifiée pour sa cohérence et sa complétude. Le modèle en cascade (Fig. 3.2)
décrit cette succession (plus ou moins détaillée) d‟étapes ; sont représentées ici
huit étapes fondamentales.

12
Même si on l‟étend avec des possibilités de retour en arrière,

idéalement limitées à la seule phase qui précède celle remise en cause (Fig.
3.3.), le développement reste fondamentalement linéaire. En particulier, il se
fonde sur l‟hypothèse souvent irréaliste que l‟on peut dès le départ définir
complètement et en détail ce qu‟on veut réaliser („requirements‟ ou expressions
des besoins). La pratique montre que c‟est rarement le cas.
Même si elle n‟est pas réalisable, cette représentation très simplifiée a
permis de définir des cadres conceptuels (définition des différentes phases – cf.
Fig. 3.4) et terminologiques, largement acceptés et normalisés par plusieurs
organismes (ISO, AFNOR, IEEE, DOD pour les applications militaires aux
USA, ESA, etc.). Ceci facilite la gestion et le suivi des projets.
Etude Feasibility study

Préliminaire
Requirements analysis
Analyse des And specification
besoins
Analyse du System analysis

système
Conception
Design
du système
Programmation
Coding and et tests unitaires
unit testing
Intégration et
Integration and tests
system testing d‟intégration
Delivery Installation
Maintenance Exploitation
et
maintenance

13
Figure 3.2 Le modèle en cascade
Analyse des
besoins
Analyse du
système
Conception
du système
Programmation
et tests unitaires
Figure 3.3 Le modèle en cascade avec itérations (quelques étapes).
Etude préliminaire ou étude de faisabilité ou planification : (rapport

d‟analyse préliminaire ou schéma directeur)
 Définition globale du problème,
 Différentes stratégies possibles avec avantages/inconvénients,
 Ressources, coûts, délais.
Analyse des besoins ou analyse préalable : (cahier des charges + plan qualité).
 Qualités fonctionnelles attendues en termes des services offerts,
 Qualités non fonctionnelles attendues : efficacité, sûreté, sécurité, facilité
d‟utilisation, portabilité, etc.
 Qualités attendues du procédé de développement (ex : procédures de
contrôle qualité).
Le cahier des charges peut inclure une partie destinée aux clients
(définition de ce que peuvent attendre les clients) et une partie destinée aux
concepteurs (spécification des besoins).

14
Analyse du système : (dossier d‟analyse + plan de validation)
 Modélisation du domaine,
 Modélisation de l‟existant (éventuellement),
 Définition d‟un modèle conceptuel (ou spécification conceptuelle),
 Plan de validation.
Conception : (dossier de conception + plan de test global et par module)

 Proposition de solution au problème spécifié dans l‟analyse,
 Organisation de l‟application en modules et interface des modules
(architectures du logiciel),
 Description détaillée des modules avec les algorithmes essentiels (modèle
logique),
 Structuration des données.
Programmation et tests unitaires : (dossiers de programmation et codes

sources)
 Traduction dans un langage de programmation,
 Tests avec les jeux d‟essais par module selon le plan de test.
Intégration et tests de qualification :

 Composition progressive des modules,
 Tests des regroupements de modules,
 Test en vraie grandeur du système complet selon le plan de test global
(„alpha testing‟).
Installation :
Mise en fonctionnement opérationnel chez les utilisateurs. Parfois

restreint dans un premier temps à des utilisateurs sélectionnés („beta testing‟).

15
Maintenance :
 Maintenance corrective (ou curative),
 Maintenance adaptative,
 Maintenance perfective.
Activités transversales à tout le cycle de vie :

 Spécification, documentation, validation et vérification, management.
Des études ont été menées pour évaluer le coût des différentes étapes
du développement :
Type de système Conception Implantation Test
Gestion 44 28 28
Scientifique 44 26 30
industriel 46 20 34
Mais c‟est la maintenance qui coûte le plus cher.
6.3. Le modèle en V
Le modèle en V (Fig.3.2) est une autre façon de présenter une

démarche qui reste linéaire, mais qui fait mieux apparaître les produits
intermédiaires à des niveaux d‟abstraction et de formalité différents et les
procédures d‟acceptation (validation et vérification) de ces produits
intermédiaires.
Le V est parcouru de gauche à droite en suivant la forme de la lettre :
les activités de construction précèdent les activités de validation et vérification.
Mais l‟acceptation est préparée dès la construction (flèches de gauche à droite).
Cela permet de mieux approfondir la construction et de mieux planifier la
„remontée‟.

16
Chronologie
Orientation Maintenance
faisabilité
+ Préparation de la ……………
Validation
Cahier des Analyse des Tests
charges besoins – analyse d‟acceptation
du système
Système
Vérification
Conception Tests
Spécification architecturale d‟intégralité
architecturale Vérification Logiciel
Conception Tests unitaires
détaillée
Spécification
détaillée Module
Abstraction
Codage
Figure 3.5 Le modèle en V
6.4. Le modèle incrémental
Face aux dérivés bureautiques de certains gros développements, et à

l‟impossibilité de procéder de manière aussi linéaire, le modèle incrémental a été
proposé dans les années 80 (Fig.3.6). le produit est délivré en plusieurs fois, de
manière incrémentale, c'est-à-dire en le complétant au fur et à mesure et en
profitant de l‟expérimentation opérationnelle des incréments précédents. Chaque
incrément peut donner lieu à un cycle de vie classique plus ou moins complet.
Les premiers incréments peuvent être des maquettes (jetables s‟ils s‟agit juste de
comprendre les besoins des utilisateurs) ou des prototypes (réutilisables pour
passer au prochain incrément en les complétant et/ou en optimisant leur
implantation). Le risque de cette approche est celui de la remise en cause du
noyau.

17
6.4. Le modèle en spirale
Enfin le modèle en spirale, de Boehm (88), met l‟accent sur

l‟évaluation des risques (Fig.3.8). A chaque étape, après avoir défini les
objectifs et les alternatives, celles-ci sont évaluées par différentes techniques
(prototypage, simulation, …), l‟étape est réalisée et la suite est planifiée. Le
nombre de cycles est variable selon que le développement est classique ou
incrémental.
Détermination Identification et
des objectifs, des résolution des
alternatives, des risques
contraintes Analyse
des risques
Série de prototypes
Plan du cycle Concept Besoins
de vie Conception
Plan du Validation détaillée
conception
développement
Validation et Tests
Plan des tests et vérification unitaires
de l‟intégration Intégration
Planification des Acceptation Développement, et
phases suivantes vérification/validation
Spirales
supplémentaires
éventuellement
(incréments)

18
CHAPITRE II : LES TECHNIQUES DE SPECIFICATION
1. Introduction
Tout produit complexe à construire doit d‟abord être spécifié ; par

exemple un pont de 30 mètres de long, supportant au moins 1000 tonnes,
construit en béton, etc. ces spécifications peuvent être considérées comme un
contrat entre un client (la collectivité qui veut réaliser le pont) et un producteur
(„l‟entreprise de génie civil).
En informatique, le client et le producteur peuvent être différents selon

les phases du cycle de vie.
 La spécification des besoins ou spécifications des exigences
(„requirements‟) est un contrat entre les futurs utilisateurs et le
concepteur. Elle concerne les caractéristiques attendues (exigences
fonctionnelles et non fonctionnelles ; efficacité, taille, sûreté, portabilité,
etc.). Elle intervient pendant la phase d‟analyse des besoins et se rédige en
langue naturelle.
 La spécification d‟un système est un contrat entre les futurs utilisateurs et
les concepteurs. Elle concerne la nature des fonctions offertes, les
comportements souhaités, les données nécessaires, etc. elle intervient
pendant la phase d‟analyse du système.
 La spécification d‟une architecture de système est un contrat entre les
concepteurs et les réalisateurs. Elle intervient pendant la phase de
conception générale. Elle définit l‟architecture en modules de
l‟application à réaliser.
 La spécification technique d‟un modèle, d‟un programme, d‟une structure
de données ou d‟un type de données est un contrat entre le programmeur
qui l‟implante et les programmeurs qui l‟utilisent. Elle intervient pendant
la phase de conception détaillée.
19
De manière générale une spécification décrit les caractéristiques

attendues (le quoi) d‟une implantation (le comment).
Dans cette partie nous traitons essentiellement de la spécification d‟un
système en termes de fonctions, de données, de comportement.
Il est souhaitable qu‟une spécification soit claire, non ambiguë et
compréhensible. Les descriptions en langue naturelle manquent souvent de
précision. Les spécifications doivent aussi être cohérentes (pas de
contradictions) et complètes.
La complétude peut prendre deux formes :
 „interne‟, c'est-à-dire que tous les concepts utilisés sont clairement
spécifiés,
 Et „externe‟, par rapport à la réalité décrite. Cette seconde forme est
quelque peu illusoire dans la pratique. On ne peut pas en général spécifier
tous détails ou tout le „monde‟ qui entoure un système.
2. Les styles de spécification
Il y a deux critères de classification orthogonaux :

 La formalité : on distingue des spécifications informelles (en langue
naturelle), semi formelles (souvent graphiques, dont la sémantique est
plus ou moins precise), formelles (quand la syntaxe et la sémantique sont
définies formellement par des outils mathématiques).
 Le caractère opérationnel ou déclaratif : les spécifications opérationnelles
décrivent le comportement désiré par un modèle qui permet d‟une certaine
manière de le simuler ; par opposition, les spécifications déclaratives
décrivent seulement les propriétés désirées.

20
3. Des techniques de spécification pour les phases d’analyse
3.1. Les spécifications en langue naturelle
Elles sont très souples, conviennent pour tous les aspects, sont très
facilement communicables à des non spécialistes. Mais elles manquent de
structuration, de précision et sont difficiles à analyser. Des efforts peuvent être
faits pour les structures (spécifications standardisées) : chapitres, sections, items,
justifications („rationnel‟), etc.
3.2. Les spécifications techniques dans des langages spécialisés ou des

langages informatiques de haut niveau
Des langages semi formels spécialisés pour spécifier des systèmes ont
été proposés. Ils comportent des sections et champs prédéfinis, ce qui force à
une certaine structuration.
Certains utilisent aussi des langages de haut niveau comme des
„pseudo codes‟ pour décrire les fonctionnalités attendues.
3.3 Les diagrammes de flots de données (DFD)
Il s‟agit d‟une technique semi-formelle et opérationnelle. Les DFD

décrivent des collections de données manipulées par des fonctions. Les données
peuvent être persistantes (dans des stockages) ou circulantes (flots de données).
La représentation graphique classique distingue :
 Les fonctions par des cercles,
 Les stockages par des boites ouvertes,
 Les flots par des flèches,
 Les entités externes par des rectangles
Au niveau de plus abstrait, on peut se contenter des entités à l‟interface

(„acteurs‟) et des flots qu‟ils s‟échangent, sans décomposition en fonctions. On
parle alors de „diagramme de contexte‟. En faisant apparaître les fonctions et en
21
les raffinant de plus en plus, on obtient des DFD à différents niveaux

d‟abstraction.
Responsable Critère de
du projet sélection
Description
projet
Appel d‟offre
Proposition Lettre
d‟acceptation
Société de Lettre de refus
service
Figure 1. Exemple de diagramme de contexte
Proposition
Lettre d‟acceptation
Critères de
Sélection
PROPOSITIONS
CRITERES Lettre de refus

Note
Description
projet
PROJETS
Figure 2. Raffinement du DFD précédent (les flèches entrantes et sortantes doivent être les mêmes
Les DFD sont une notation semi formelle, car la sémantique des
fonctions n‟est pas spécifiée précisément (que signifie exactement
„Evaluation‟ ?), ni les aspects liés au contrôle (ou séquencement des opérations).

22
Exemple : plusieurs interprétations sont possibles pour le DFD élémentaire

suivant :
A produit une donnée et attend que B la traite pour en produire une

autre, ou A et B sont des processus autonomes avec un tampon entre eux.
Les DFD peuvent être analysés à la recherche de formes „pathologiques‟,
comme le „trou noir‟, le „générateur spontané‟, etc.
Pour ces raisons les DFD sont soit complétées par d‟autres
spécifications, soit étendus : flots de contrôle, tampons, etc. ils connaissent un
très grand succès pour spécifier les fonctions d‟un système à cause de leur
simplicité et de leur facilité de compréhension par des non informaticiens.
3.4. Les machines à états finis
C‟est une technique formelle et opérationnelle très largement répandu

pour décrire les aspects liés au contrôle. Il consiste en :
 Un ensemble fini d‟états (S),
 Un ensemble fini d‟entrées (I),
 Une fonction de transition t : S x I - > S ; c‟est une fonction partielle. Une
certaine entrée dans un certain état fait passer à un autre état.
Graphiquement une machine à états finis est représenté par un graphe

(appelé diagramme d‟états) dont les nœuds sont les états. Un arc nommé a va de
s1 à s2 si et seulement si t(s1,a)=s2. La figure 3 donne comme exemple, le
diagramme d‟états d‟un appel téléphonique.

23
En attente Raccrocher
En tonalité
Délai
terminé
En numérotation Diffusion
Numéro incorrect message
Numéro correct
En connexion
Etat occupé Appel acheminé
En sonnerie
Appel décroche
Fin message
En communication
Appel raccroche
Déconnectée
Figure 3. Diagramme d‟états d‟une ligne téléphonique
Le modèle est souvent enrichi de concepts supplémentaires : un état

initial (so S), des états finaux (F  S), notés souvent par un double cercle, des
signaux de sortie 0 (t : Sxl -> Sx0), notés souvent par <e,s> sur les arcs (l‟entrée
e dans un certain état fait passer à un autre état avec production de la sortie s).

24
3.5. Les schémas entités associations EA (ou entités relations ER)
Il s‟agit d‟une technique semi formelle et déclarative (Peter Chen,

1976). Ces schémas permettent de spécifier la structure des données et leurs
relations, ce qui n‟est fait ni dans les DFD, ni dans les modèles orientés contrôle.
C‟est indispensable pour les systèmes organisés autour de larges ensembles de
données interconnectées.
Les concepts du modèle de base sont :
 Les entités, qui sont des collections d‟items partageant des propriétés
communes (occurrences d‟entités), Entité Entité
Attribut
Attribut
Réel
Rel. Attribut
Attribut
 Les associations (ou relations), qui traduisent l‟existence de liens entre

entités (occurrences d‟associations entre occurrences d‟entités),
 Les attributs (ou propriétés), attachés aux entités et aux associations et qui
les caractérisent.
Une entité existe indépendamment de ce qui l‟entoure. Une association

n‟existe que si les entités extrémités existent. Chaque entité à un attribut
identifiant qui distingue univoquement chaque occurrence d‟entité.
Certains modèles, dits modèles binaires, n‟autorisent que les
associations entre 2 entités. Les associations peuvent être partielles.
Les associations sont souvent caractérisées par leurs cardinalités, qui
peuvent être notées de diverses manières. Avec les notations de Merise, à tout X
correspond :

25
X 0,1 Y 0,n
Au plus un Y X Y Ou ou plusieurs
Y
X 0,1 Y Un et un seul Y 1,n

X Y 1 ou plusieurs
Y
La figure 10 donne un exemple de schéma entités associations.

Num-ens
0,n Nom-ens
Resp-filière
enseignant 0,n
0,n
1,1 0,n
1,n
Sous-resp
Filière Resp-uv Intervenant
0,n
1,n 0,n Cycle 0,n
Num-fil
Num-cycle
Num-fil Inscr 0,n Num-cycle
1,1 0,n
1,n
Unité 0,n Equiv
Etudiant
0,n 1,n
Num-et 0,n
Resu def Num-cont
Nom-et Num-uv
Date-cont
0,n Nom-uv
Adr-et Moy 1,1
coeff
note Contrôle
0,n
Fig.10. un exemple de diagramme entités relations (identifiants en gras)
4. Conclusion
Souvent les techniques de spécifications se complètent, en décrivant

des vues complémentaires d‟un système. Par exemple, un système peut être
spécifié à travers un diagramme de flot de données (sources d‟informations,
types d‟informations stockées et échangées, décomposition en fonctions), un
schéma EA (structuration des informations) et des machines à états finis
(comportement de certains composants). Les méthodes tendent de proposer des
26
assemblages efficaces de telles techniques avec des guides pour les construire et
les valider.
Parler des techniques de spécifications est comme parler des langages
de programmation. Il n‟y a ni langage ni technique idéale, ni langage ni
technique permettant de tout faire. L‟informaticien doit avoir une culture assez
étendue des diverses techniques comme des diverses techniques comme des
divers langages.

27
CHAPITRE III : LA MODELISATION OBJET EN UML
1. Les méthodes d’analyse et de conception
Une méthode :
 Propose une démarche, distinguant les étapes du développement dans le
cycle du vue du logiciel et exploitant au mieux les principes
fondamentaux : modularité, réduction de la complexité, réutilisation,
abstraction, etc.,
 Propose des formalismes (langages) et des types de documents (modèles),
qui facilitent la communication, l‟organisation et la vérification,
Il existe de nombreuses méthodes :

 Méthodes fonctionnelles de décomposition hiérarchique (dites de
première génération) comme SADT, SA-SD, … : application du principe
diviser pour régner (problème → sous problèmes) ;
 Méthodes systémiques (dites de deuxième génération) comme MERISE,
SSADM, … : séparation données/traitements, niveaux conceptuels,
organisationnels, physiques.
 Méthodes objets (dites de troisième génération) comme OMT, OOA,
OOD, Hood, OOSE, OOM, Fusion, …
Parmi les principaux objectifs des méthodes objets, on peut noter la volonté de :
 Regrouper l‟analyse des données et des traitements,
 Etablir un couplage explicite entre les concepts du monde réel et les
composants exécutables (« réduire la distance sémantique entre le langage
des concepteurs et celui des utilisateurs »),
 Faciliter la réutilisation,
 Simplifier les transformations entre le niveau conceptuel et l‟implantation.

28
Au début des années 90, il existait une cinquantaine de méthodes objet,

liées par un certain consensus autour d‟idées communes : objets, classes, sous-
systèmes, etc. mais chacune possédait sa propre notation, ses points forts et ses
manques, et son orientation privilégiée vers un domaine d‟application. L‟idée
d‟une certaine unification des méthodes objet est née de ce constant. La
communauté informatique, autour de l‟OMG („Objet Management Group‟) qui
standardise les technologies de l‟objet, s‟est attachée à la définition d‟un langage
commun unique, utilisable par toutes les méthodes objets, dans toutes les phases
du cycle de vie et compatible avec les techniques de réalisation du moment.
2. UML
Ce langage commun s‟appelle UML („Unified Modeling Language‟).

UML est une notation basée principalement sur les méthodes OOD (de Booch),
OMT (de Rumbaugh) et OOSE (de Jacobson).
UML a été proposé afin de standardiser les produits du développement

(modèles, notations, diagrammes) sans standardiser le processus de
développement. Il est en effet très difficile de standardiser le processus de
développement qui dépend des personnes, des applications, des cultures, etc.
UML se propose de créer un langage de modélisation utilisable à la fois par les
humains (forme graphique) et les machines (syntaxe précise). La figure 1
résume UML avec ses 5 vues et ses 9 diagrammes.

29
Les composants
La structuration logiciels
des objets Vue logique Vue implantation
Statique Statique
Diagrammes : Diagrammes :
classe, objet, composants
collaboration, séquence
Vue externe
Les fonctions du
Diagrammes :
système
Diagrammes : cas d‟utilisation Diagrammes :
état, activité déploiement
Vue logique Vue déploiement

dynamique
La dynamique L‟architecture
des objets physique
Figure 1 : les vues et les diagrammes UML
En résumé :
 UML est une notation, pas une méthode.
 UML est un langage de modélisation objet.
 UML convient pour toutes les méthodes objets.
 UML est dans le domaine public.
UML a pour but de documenter les modèles objets.

3. Les cas d’utilisation
Formalisés par Ivar jacobson dans Objet-Oriented Software

Engineering (Addison-Wesley, 1992), les cas d‟utilisation („use cases‟) servent à
exprimer le comportement du système en termes d‟actions et de réactions, selon
le point de vue de chaque utilisateur (« approche centrée utilisateur »).
Les cas d‟utilisation délimitent le système, ses fonctions (ses arcs), et

ses relations avec son environnement. Ils constituent un moyen de déterminer les
besoins du système. Ils permettent d‟impliquer les utilisateurs dès les premiers
stades du développement pour exprimer leur attente et leurs besoins (analyse des

30
besoins). Ils constituent un fil conducteur pour le projet et la base pour les tests
fonctionnels (cf.Figure 2).
Un acteur est une personne ou un système qui interagit avec le système

étudié, en échangeant de l‟information (en entrée et en sortie). On trouve les
acteurs en observant les utilisateurs directs du système, les responsables de sa
maintenance, ainsi que les autres systèmes qui interagissent avec lui. Un acteur
représente un rôle joué par un utilisateur qui interagit avec le système. La même
personne physique peut jouer le rôle de plusieurs acteurs. D‟autres part,
plusieurs personnes peuvent jouer le même rôle, et donc agir comme un même
acteur.
Exprime Comprend
Analyse
Utilisateur
Cas d‟utilisation
réalise Vérifie
Programmeur Tester
Figure 2 : les cas d‟utilisation, fil conducteur du projet
Notations :
SYSTEME
communication
Acteur humain
Cas d‟utilisation
Acteur <<acteur>>
X
Acteur
Acteur système
Cas d‟utilisation
Y
L‟acteur est source ou destination d‟une

communication
Figure 3 : notation des cas d‟utilisation
31
Les cas d‟utilisations représentent le dialogue entre l‟acteur et le

système de manière abstraite. Les communications sont orientées (avec une
flèche) ou non. Les cas d‟utilisations peuvent aussi être vus comme des classes
de scénarios. Enfin, les cas peuvent être structurés par les relations <<inclut>>
(un cas inclut obligatoirement un autre cas) et <<Etend>> (un cas est une
variante d‟un autre) (cf. Figure 4). On peut aussi avoir de la
généralisation/spécialisation entre acteurs et entre cas (cf. Paragraphe 6).
Virement
Client distant par internet Client local
<<Etend>>
<<Inclut>> Virement
Identification
Figure 4 : structuration des cas d‟utilisation
Démarche d‟utilisation des cas d‟utilisation :

1) Identifier les acteurs et les cas.
2) Décrire les cas en écrivant des scénarios sous forme textuelle.
3) Dessiner les diagrammes de cas.
4) Récapituler les cas, les structures et s‟assurer de la cohérence d‟ensemble.
4. Les objets.
Les objets informatiques définissent une représentation simplifiée des

entités du monde réel, qu‟il s‟agisse d‟entités concrètes (avec une « réalité
physique ») ou conceptuelles. Les objets sont des abstractions qui mettent en
avant les caractéristiques essentielles et dissimulent les détails. Une abstraction
se définit par rapport à un point de vue (tout dépend de l‟intérêt que l‟on porte à
l‟objet).
Exemples d’objets : une transaction bancaire, un client, un pop-up menu.
32
Les trois caractéristiques fondamentales des objets sont l‟état, le

comportement, l‟identité. L‟état correspond aux valeurs instantanées de tous les
attributs (ou données membres) de l‟objet. L‟état évolue au cours du temps.
L‟état d‟un objet à un instant donné est la conséquence de ses comportements
passés.
Exemples : pour un signal électrique : valeurs de l‟amplitude, de la pulsation, de

la phase, … ; pour une voiture ; valeurs de la marque, de la puissance, de la
couleur, du nombre de places assises, de la quantité d‟essence, …
Une voiture
Essence = 30 litres Son état
Une voiture
Après un parcours de 100 km Couleur = Rouge
Poids = 979 kg
Puissance = 16 CV
Essence = 25 litres
Une voiture
Essence = 20 litres
Figure 5 : objet et état
Le comportement décrit les actions et les réactions d‟un objet (ou

„compétences‟ d‟un objet). Le comportement se matérialise sous la forme d‟un
ensemble d‟opérations (ou méthodes ou fonctions membres). On distingue
souvent les opérations selon leur finalité de constructeur, accesseur,
modificateur, destructeur et itérateur.
Un autre objet
Un message Etat
Comportement
Opérateur 1{…}
Opérateur 2{…}
Un objet
Figure 6 : comportement d‟un objet

33
Un objet peut faire appel aux compétences d‟un autre objet par
invocation d‟une opération (ou „envoi de message). Les messages servent à
implanter les flots de données, les flots de contrôle, les événements, etc.
L‟état et le comportement sont liés :
-le comportement dépend de l‟état (cf. la pré condition de l‟opération) ; le
message peut être accepté ou refusé ;
-l‟état est modifié par le comportement (cf. la post condition de l‟opération).
Tout objet possède une identité interne (non modifiable) qui lui est
propre et qui le caractérise. L‟identité permet de distinguer tout objet de façon
non ambiguë, indépendamment de son état (de ses attributs). Les langages objets
utilisent des identifiants internes. Les identifiants et clés primaires des bases de
données sont inutiles en objet.
Intérêt des objets :

 Concurrence : les objets sont autonomes et évoluent indépendamment les
uns des autres.
 Maîtrise de la complexité :
-l‟encapsulation permet de se concentrer sur un objet et un seul,
-il est possible de tester de façon quasi exhaustif un objet.
 Evolution facilitée : rajouter de nouveaux objets est simple.
 Réutilisation possible.
Difficulté des objets :

 Tout n‟est pas naturellement objet.
 Tester un système OO est difficile.
 Penser objet oblige à changer de mentalité.

34
5. Les collaborations
Une application est une société d‟objets qui collaborent afin de réaliser
les fonctions de l‟application. Le comportement global d‟une application repose
donc sur la communication entre les objets qui la composent (échanges de
messages).
5.1. Les diagrammes de collaboration
Les diagrammes de collaboration mettent l‟accent sur les relations

« spatiales » entre objet. Les messages peuvent être numérotés pour introduire
une dimension temporelle. De nombreuses notations annexes permettent de
caractériser les messages. Ils sont souvent utilisés pour décrire grossièrement la
réalisation des cas d‟utilisation.
Exemple : un objet A envoie un message X à un objet B, puis l‟objet B envoie
un message Y à un objet C, et enfin C s‟envoie à lui-même message Z.
A
1:X
B
3:Z
2:Y
Figure 7 : un diagramme de collaboration
5.2. Les diagrammes de séquence
Ils mettent l‟accent sur les relations temporelles. De nombreuses

notations annexes permettent de préciser la nature des messages (appel de
procédure, simple signal, message répétitif, conditionnel, réflexif, récursif, etc.)
et les données véhiculées. Ils peuvent être utilisés aussi bien pour préciser la

35
réalisation des cas d‟utilisation que pour spécifier de manière très détaillée la
dynamique d‟un ensemble d‟objets (appels de méthodes).
A B C
M1
M2
M3
M4
M5
M6
M7
M9
M8
temps M10
„ligne de vie‟
Figure 8 : un diagramme de séquence

6. Les classes
Le monde qui nous entoure est constitué de très nombreux objets. Pour
comprendre le monde, l‟être humain a tendance à regrouper les éléments qui se
ressemblent. Regrouper des objets suivant des critères de ressemblance s‟appelle
classer. Les humains ont classé les animaux, les plantes, les champignons, les
atomes, …
La classe est la description abstraite d‟un ensemble d‟objets. Elle peut
être vue comme la factorisation des éléments communs à un ensemble d‟objets.

36
Nom de classe
Attribut
Règles de visibilité
Opérateurs
+attribut public
Motocyclette #attribut protégé
-attribut privé
Couleur
Cylindrée Téléviseur
+opérateur publique ( )
Vitesse #opérateur protégée
maximale Modèle
-opérateur privée ( )
Démarrer ( ) Allumer
Accélérer ( ) Eteindre
Freiner ( ) Changer le programme( )
Régler le volume
Figure 9 : des exemples de classe
La classe intègre les concepts de type (en tenant que « moule à

instances ») et de module (avec l‟idée d‟interface + corps).
Opération
(méthode)
publique
Classe
Etat Interface
Opération
(méthode)
privée
Figure 10 : interface et corps d’une classe
La hiérarchisation des classes permet de gérer la complexité. Dans un

sens, la généralisation correspond à la factorisation des éléments communs de
classes (attributs, opérations) ce qui favorise la réduction de la complexité et la
généricité. Dans l‟autre sens, la spécification permet d‟adapter une classe

37
générale à un cas particulier ce qui favorise la réutilisation et la modification

incrémentielle.
Super - classe Classe plus
générale
généralisation
Spécialisation
Super - classe Classe plus

spécialisé
Figure 11 : généralisation / spécialisation
Exemple :
Animal
Carnivore Herbivore
Lion Mouton Lapin
Figure 12 : un exemple de hiérarchisation
Les instances de la classe spécialisée héritent de la description des

attributs (variables) et des opérations (méthodes) de la super-classe. Elles
peuvent en ajouter d‟autres et /ou en redéfinir certaines.
On peut dire aussi que le type Lion est un sous type du type Carnivore. Tout lion
est un carnivore (on parle aussi de relation „est – un‟ ou „isa‟ en anglais).
L‟ensemble des lions est un sous ensemble des carnivores. Mais l‟ensemble des
attributs d‟un lion est un sur ensemble de l‟ensemble des attributs d‟un carnivore
(d‟où le mot extends qu‟utilise java pour lier sous –classe et super –classe).

38
La relation de spécification / généralisation est une relation non

réflexive, non symétrique et transitive. L‟héritage multiple (plusieurs super
classes) est possible.
Un même message peut être interprété de manière différente selon la

nature de l‟objet receveur. On parle de polymorphisme. L‟émetteur n‟a pas
besoin de connaître la classe du receveur.
Exemple : on paye des employés de 2 types („mensualisés‟ et „à la tâche‟). Il
suffit d‟envoyer la méthode calculerPaie ( ) à tous les employés. Si un nouveau
type d‟employé apparaît le programme de paie n‟a pas à être modifié.
Employé
Méthode abstraite
CalculerPaie( )
Mensualité A_la_tâche
Méthodes concrètes
CalculerPaie( ) CalculerPaie( )
Figure 13 : polymorphisme
7. Les diagrammes de classes
Les diagrammes de classes expriment la structure statique du système.

Ils décrivent l‟ensemble des classes et leurs associations. Une classe décrit un
ensemble d‟objets (instances de classe). Une association exprime une connexion
sémantique bidirectionnelle entre classes. Une association décrit un ensemble de
liens (instances de l‟association). Le rôle décrit une extrémité d‟une association.
Les cardinalités (ou multiplicité) indiquent le nombre d‟instances d‟une classe
pour chaque instance de l‟autre classe.

39
Exemple : association inscription entre Etudiant et Université (cf. Figure 14) ;

lien d‟inscription entre l‟objet Pierre et l‟objet université de nancy. Rôles
Employeur et Employé de l‟association Emploie.
L‟agrégation est une association qui décrit une relation d‟inclusion entre
une partie et un tout (l‟agrégat). Elle est réflexive, transitive, non symétrique. Si
la relation d‟agrégation est une composition (composant/composé avec des
durées de vie liées pour les objets), elle est symbolisée par un losange plein ;
sinon (pour des durées de vie indépendantes), elle est représenté par un losange
vide du coté de l‟agrégat.
Voiture Circuit autobus
* 1 1 1
Roue Moteur Carrosserie Arrêt
Figure 14 : composition et autre forme d‟agrégation
Attention à ne pas confondre généralisation/spécialisation et

agrégation. Quand une classe est une spécialisation d‟une autre elle est de même
nature, ce qui n‟est pas le cas avec l‟agrégation.
Exemple :
Tarte Fruit
TarteAuxPommes Pomme
Une tarte aux pommes est de même nature qu‟une tarte. Une pomme
n‟est pas de même nature qu‟une tarte.

40
Autres concepts :
- Attributs d‟associations :
Boire
Buveur Vin
A_bu Est_bu
Date
Quantité
Figure 15 : attributs d‟association
-Classe-association : association porteuse d‟attributs ou d‟opérations,

représentée comme une classe anonyme associée à l‟association.
Etudiant 0..* Suit> 1..* Matière
Note
Figure 16 : classe – association
-Association d‟arité n : représentée par un losange avec n ‟pattes‟ auquel peut

être associé une classe porteuse d‟attributs et d‟opérations.
Salle
1
Etudiant 2..* 1 Enseignant
Cours
Début
Fin
Figure 17 : association n-aire

41
-Paquetage (sous modèle) : c‟est une notion qui peut apparaître dans beaucoup
de diagrammes pour spécifier le regroupement d‟éléments au sein d‟un sous
système (cas, classes, objets, composants, autres paquetages, …).
Paquetage
Figure 18 : un paquetage
-Contraintes d‟intégrité entre associations (inclusion, exclusion, …).

-Classes abstraites : elles sont non instanciables directement ; elles décrivent des
mécanismes généraux et laissent non décrits certains aspects (méthodes
abstraites) ; elles sont spécialisées par des classes concrètes (instanciables) qui
précisent les méthodes abstraites.
Window_
window
Window ToFront ( )
{abstract} toBack
ToFront ( )
toBack
Mac_
window
ToFront ( )
toBack
Figure 19 : classe abstraite

42
-Interfaces : ce sont des classes ne contenant que des opérations abstraites ; elles
précisent les fonctionnalités que les classes qui les implantent doivent fournir.
8. Les diagrammes d’état
Les diagrammes d‟état servent à décrire le comportement des objets

(classes) complexes. Ce sont des diagrammes d‟état étendus avec des conditions
(gardes) sur les transitions et des actions sur les transitions et les états (cf.
Figure 21).
Evénement [Condition] Action
Garde
Etat A
A Entry : …
Actions On UnEvénement : …
Exit : …
Figure 20 : les diagrammes d‟état étendus d‟UML
Ces diagrammes permettent aussi la décomposition d‟états en sous

états (cf. Figure 22). On parle aussi d‟état composite.
Etat initial B
A
B1
B2
Transition d‟entrée portant sur le sup avec un état

initial spécifié dans le sup
Figure 21 : décomposition d‟états

43
Enfin, il est possible de décrire du parallélisme entre sous systèmes, ce

qui rapproche les diagrammes d‟états des réseaux de Pétri.
9. Les diagrammes d’activité
Ils permettent de décrire un flot de contrôle entre opérations (calculs).

Il s‟agit d‟un gros ordinogramme incluant éventuellement du parallélisme.
A un niveau macroscopique, les diagrammes d‟activité permettent de
décrire des enchaînements de fonctionnalités. Ils complètent donc bien les cas
d‟utilisation au niveau de l‟analyse des besoins.
A niveau microscopique, les diagrammes d‟activité permettent, par exemple, de
décrire l‟algorithme d‟une action d‟un diagramme d‟états.
10. Autres éléments
10.1. Les diagrammes de composants
Les composants sont des codes (sources, exécutables), des scripts, des
fichiers, des tables, etc.
10.2. Les diagrammes de déploiement
Ces diagrammes illustrent (cf. Figure 25) :

 La disposition physique des différents matériels (ou nœuds) qui entrent
dans la composition du système,
 La répartition des composants (cf. diagrammes de composants) au sein
des nœuds,
 Les supports de communication entre noeuds.
11. Eléments d’une démarche
UML n‟impose pas de processus. La „démarche naturelle‟, impliquée

par la notation UML, part des cas d‟utilisation qui expriment un point de vue
fonctionnel sur le système.

44
Puis les diagrammes de collaboration et de séquence associées aux cas

font apparaître les classes d‟objets impliquées dans le système et donc passer à
une vue „objet‟ (cf. Figure 26).
Mais on peut aussi passer à une vue „hiérarchie de fonctions‟ à partir
des cas d‟utilisation, comme le montre la Figure 27.
Diagrammes essentiels par phase :
 Analyse des besoins : cas d‟utilisation.
 Analyse du système : diagrammes de classes, de collaboration, d‟activités,
(enchaînement des cas).
 Conception : diagrammes de classes, de séquences, d‟activités
(conception méthodes), d‟états, de composants, de déploiement.
EXERCICES
Exercice 1. Diagramme de contexte et diagramme de flots de données (DfD)
On considère la gestion d‟un bureau de localisation pour plusieurs
stations touristiques. Différents prestataires offrent des locations. Ils peuvent les
retirer tant qu‟aucune réservation définitive n‟est réalisée. Ils touchent 90 % du
prix de la location. Les clients adressent des demandes des renseignements. Le
bureau y répond par des propositions de location et d‟assurance annulation ou
une mise en attente. Le client peut alors refuser ou demander une réservation en
envoyant des arrhes et en souscrivant éventuellement l‟assurance annulation. Si
la location choisie est encore libre, elle est réservée, sinon la demande est mise
en attente. Après un délai de 8 jours, la réservation est confirmée de manière
définitive. En cas d‟annulation après ces 8 jours, un pourcentage est dû par le
client sauf s‟il a souscrit l‟assurance annulation. L‟annulation en cas de mise en
liste d‟attente est toujours possible sans frais

45
La facture est envoyée avant le début du séjour. Un rappel suit en cas de non
paiement. En cas de nouveau défaut de paiement le dossier est transmis au
contentieux.
Dessiner le diagramme de contexte et décomposez-le en un premier niveau de
DFD. Raffiner la gestion des réservations avec des DFD plus détaillés
Exercice 2. Diagrammes entités associations.
On reprend l‟énoncé de l‟exercice 2. Après inventaire, les principaux

concepts à représenter sont : les clients, les prestataires, les hébergements
(offerts par les prestataires), les stations (où se situent les hébergements), les
propositions, les réservations, les demandes en attente, les types de prestataires
(souhaités dans les demandes en attente), les types d‟hébergement (souhaités
dans les demandes en attente), les types d‟hébergement (souhaitées dans les
demandes en attente), les activités (possibles dans les stations), les services
(offert par les prestataires).
Proposer un diagramme entités relations avec des cardinalités réalistes. Donnez
les principaux attributs.
Exercice 3. Le GAB – cas d’utilisation
Modélisation d‟un GAB (Guichet Automatique de Banque). Les

principales fonctions sont les suivantes :
-distribution d‟argent à tout porteur d‟une carte de la banque (autorisation d‟un
certain montant par le système d‟information de la banque) ou d‟une carte VISA
(autorisation à distance par le système d‟autorisation VISA),
-consultation du solde, dépôt en numéraire et de chèques pour les possesseurs
d‟une carte de la banque.
Toutes les transactions sont sécurisées (code personnel vérifié avec le code
enregistré sur la puce de la carte ; la carte est avalée après trois échecs).
Il faut parfois recharger le GAB et retirer des choses …
Identifier les acteurs et les cas. Structurer les cas.

46
Exercice 4. Le GAB – diagramme d’activités et diagramme de séquence
a) Modéliser le retrait d‟argent avec une carte VISA avec un diagramme

d‟activités. La carte peut être invalide. Si elle est valide, le client doit
taper son code. La carte est avalée après trois essaies infructueux. Le SA
VISA autorise un certain montant ou refuse tout retrait. Une carte non
récupérée est avalée. Les billets non récupérées par le client sont repris.
Un ticket est toujours imprimé pendant que les billets sont proposés.
b) Modéliser le scénario nominal (succès) avec un diagramme de séquence.
Exercice 5. Le cirque – diagramme de classes
Le propriétaire d‟un cirque souhaite informatiser une partie de la

gestion de ses spectacles. Proposer un modèle conceptuel UML (diagramme de
classes) qui réponde aux spécifications, fournies ci-dessous.
Les membres du personnel du cirque sont caractérisées par un numéro (en
général leur numéro INSEE), leur nom, leur prénom, leur date de naissance et
leur salaire. On souhaite de surcroît stocker les pseudonymes des artistes et le
numéro du permis de conduire des chauffeurs de poids lourds.
Les artistes sont susceptibles d‟assurer plusieurs numéros, chaque numéro étant
caractérisé par un code, son nom, le nombre d‟artistes présents sur scène et sa
durée. De plus, on souhaite savoir l‟instrument utilisé pour les numéros
musicaux, l‟animal concerné par les numéros de dressage et le type des
acrobaties (contorsionnisme, équilibrisme, trapèze volant…).
Par ailleurs, chaque numéro peut nécessiter un certain nombre d‟accessoires
caractérisés par un numéro de série, une désignation, une couleur et un volume.
On souhaite également savoir, individuellement, quels artistes utilisent quels
accessoires.
Enfin, les accessoires sont rangés après chaque spectacle dans des camions
caractérisés par leur numéro d‟immatriculation, leur marque, leur modèle et leur

47
capacité (en volume). Selon la taille du camion, une équipe plus ou moins
nombreuse de chauffeurs lui est assigné (de un à trois chauffeurs).
Exercice 6 : L’institut de formation – diagramme de classes
Il s‟agit d‟établir le schéma des données pour la gestion de formations

d‟un institut privé. Un cours est caractérisé par un numéro de cours
(NOCOURS), un libellé (LIBELLE), une durée en heures (DUREE) et un type
(TYPE). Un cours peut faire l‟objet dans l‟année de plusieurs sessions
identiques. Une session est caractérisée par un numéro (NOSES), une date de
début (DATE) et un prix (PRIX). Une session est le plus souvent assurée par
plusieurs animateurs et est placée sous la responsabilité d‟un animateur
principal. Un animateur peut intervenir dans plusieurs sessions au cours de
l‟année. On désire mémoriser le nombre d‟heures (NBH) effectué par un
animateur pour chaque session.
Un animateur est caractérisé par un numéro (NOANI), un nom (NOMA) et une
adresse (ADRA).
Chaque session est suivie par un certain nombre de participants. Un participant
est une personne indépendante ou un employé d‟une entreprise cliente. Un
participant est caractérisé par un numéro (NO-PAR), un nom (NOMP) et une
adresse (ADRP). Dans le cas d‟un employé, on enregistre le nom (NO-MEN) et
l‟adresse de l‟entreprise (ADREN). On désire pouvoir gérer d‟une manière
séparée (pour la facturation notamment) les personnes indépendantes d‟une part,
et les employés d‟autre part.
Exercice 7. Gestion de parc informatique – diagramme de classes
Une entreprise souhaite informatiser la gestion de son parc

informatique (ordinateurs, imprimantes, etc.) pour en optimiser la maintenance.
Proposer un schéma de clases UML modélisant les spécifications ci-dessous
(classes, associations entre classes, cardinalités des associations, attributs des
classes).
48
Un ordinateur est caractérisé par son numéro d‟inventaire, son adresse réseau
(adresse IP), son modèle, la date de son acquisition, la date de la prochaine
maintenance planifiée et le système d‟exploitation installé.
Sur chaque ordinateur est installé un ensemble de logiciels caractérisés par un
numéro de licence, un nom et une version.
Grâce à un système de mots de passe, chaque ordinateur peut être utilisé par
plusieurs employés mais, pour des raisons de sécurité des données, un employé
n‟a le droit d‟utiliser qu‟un seul ordinateur. Un employé est caractérisé par son
nom, son prénom et sa fonction dans l‟entreprise.
Les ordinateurs sont reliés à un certain nombre de périphériques en réseau
(imprimantes, scanners, etc.). Chaque périphérique est caractérisé par un numéro
d‟inventaire, son adresse IP, son type, son modèle, sa date d‟acquisition et la
date de la prochaine maintenance planifiée. Les périphériques pouvant servir à
plusieurs ordinateurs simultanément, un indice de priorité est affecté à chaque
ordinateur pour chaque périphérique auquel il est connecté.
Chaque ordinateur et chaque périphérique sont localisés dans un bureau donné.
Les bureaux sont caractérisés par un numéro de bureau et le numéro du bâtiment
dans lequel ils se trouvent. Un numéro de bureau est unique dans un bâtiment
donné.
Exercice 8. Cas d’utilisation, diagramme de classes, diagramme de séquence

----------------------------------
Une entreprise souhaite modéliser avec UML le processus de
formation de ses employés afin d‟informatiser certaines tâches.
Le processus de formation est initialisé quand le responsable de formation reçoit
une demande de formation d‟un employé. Cet employé peut éventuellement
consulter le catalogue des formations offertes par les organismes agrées par
l‟entreprise. Cette demande est instruite par le responsable qui transmet son
accord ou son refus à l‟employé.

49
En cas d‟accord, le responsable cherche la formation adéquate dans le

catalogue des formations agrées qu‟il tient à jour. Il informe l‟employé du
contenu de la formation et lui soumet la liste des prochaines sessions prévues.
Lorsque l‟employé a fait son choix il inscrit l‟employé à la session retenue
auprès de l‟organisme de formation concerné.
----------------------------------------------------------------------
En cas d‟empêchement l‟employé doit avertir au plus vite le
responsable formation pour que celui-ci demande l‟annulation de l‟inscription.
A la fin de la formation l‟employé transmet une appréciation sur le
stage suivi et un document attestant sa présence.
Le responsable formation contrôle la facture envoyée par l‟organisme
de formation.
a) dessiner le diagramme des cas d‟utilisation,
b) dessiner le schéma des classes de cette application, incluant toutes les
classes que l‟on peut déduire de l‟énoncé, ainsi que les associations entre
classes avec leurs cardinalités.
c) Dessiner le diagramme de séquences associé à la demande initiale de
l‟employé décrite dans le deuxième paragraphe de l‟énoncé ; assurer la
cohérence avec votre réponse à la question précédente.

50
Exercice 9
Cette étude de cas concerne un système simplifié de réservation de vols pour
une agence de voyages. Les interviews des experts métier auxquelles on a
procédé ont permis de résumer leur connaissance du domaine sous la forme des
phrases suivantes :
1. Des compagnies aériennes proposent différents vols.
2. Un vol est ouvert à la réservation et refermé sur ordre de la compagnie.
3. Un client peut réserver un ou plusieurs vols, pour des passagers différents.
4. Une réservation concerne un seul vol et un seul passager.
5. Une réservation peut être annulée ou confirmée.
6. Un vol a un aéroport de départ et un aéroport d‟arrivée.
7. Un vol a un jour et une heure de départ, et un jour et une heure d‟arrivée.
8. Un vol peut comporter des escales dans des aéroports.
9. Une escale a une heure d‟arrivée et une heure de départ.
10. Chaque aéroport dessert une ou plusieurs villes.
Déterminer le diagramme des classes modélisant le problème

51
Exercice 10
Cet exercice concerne un système simplifié de caisse enregistreuse de
supermarché. Le déroulement normal d‟utilisation de la caisse est le suivant :
• Un client arrive à la caisse avec des articles à payer.

• Le caissier enregistre le numéro d‟identification (CPU) de chaque article, ainsi
que la quantité si elle est supérieure à un.
• La caisse affiche le prix de chaque article et son libellé.
• Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente.
• La caisse affiche le total des achats.
• Le client choisit son mode de paiement :
– numéraire : le caissier encaisse l‟argent reçu, la caisse indique la monnaie à
rendre au client ;
– chèque : le caissier vérifie la solvabilité du client en transmettant une requête à
un centre d‟autorisation via la caisse ;
– carte de crédit : un terminal bancaire fait partie de la caisse. Il transmet une
demande d‟autorisation à un centre d‟autorisation en fonction du type de la
carte.
• La caisse enregistre la vente et imprime un ticket.
• Le caissier donne le ticket de caisse au client.
Après la saisie des articles, le client peut présenter au caissier des coupons de
réduction pour certains articles. Lorsque le paiement est terminé, la caisse
transmet les informations sur le nombre d‟articles vendus au système de gestion
de stocks. Tous les matins, le responsable du magasin initialise les caisses pour
la journée.
1) Déterminer le diagramme de cas d‟utilisation.

52
2) Déterminer le diagramme de séquences.

3) Déterminer le diagramme d‟états.
Exercice 11
Affrètement d’avions
Un aéroport toulousain désire gérer les compagnies, leurs avions et les vols
affrétés. Une compagnie est caractérisée par un code et un nom (comp,
nomComp). Chaque avion est désigné par une immatriculation
(immatriculation), un type (typeAvion), une capacité (capacite). Un avion est la
propriété d‟une compagnie. Un avion peut être affrété par une compagnie à
différentes dates (dateVol), même plusieurs fois par jour par différentes
compagnies. Pour chaque affrètement il faudra stocker le nombre de passagers
transportés (nbPax) et le coût du vol pour la compagnie (cout). On ne pose pas
de contrainte, donc, chaque compagnie peut affréter n‟importe quel avion à
n‟importe quel moment. On suppose toutefois qu‟une compagnie ne peut pas
affréter le même avion plusieurs fois dans la même journée.
L‟aéroport décide de stocker les caractéristiques de chaque type d‟avion : le
code de la désignation commerciale, le nombre maximum de passagers (npMax)
et la désignation commerciale (nomAvion).
Exemple : l‟A320 peut transporter au maximum 180 passagers et se dénomme «
Airbus A320 ».
Déterminer le diagramme des classes modélisant le problème


Génie Logiciel

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Génie Logiciel

Încărcat de

Drepturi de autor:

Formate disponibile

1

CHAPITRE I : DEFINITIONS GENERALES, PRINCIPES, PROCESSUS

I. Définition et objectifs du génie logiciel (GL)

Domaine des sciences de l‟ingénieur dont la finalité est la conception,

Le Génie logiciel se définit souvent par opposition à la

I.2. Objectifs – la règle du CQFD

Le GL se préoccupe des procédés de fabrication des logiciels de façon

Prof. Pierre KAFUNDA KATALAY

o -la robustesse : aptitude d‟un logiciel à fonctionner même dans des

Règle du CQFD : Coût qualité Fonctionnalités Délai.

Prof. Pierre KAFUNDA KATALAY

I.3. L’état des lieux

Le GL est apparu dans les années 70 pour répondre à la crise du

Coût logiciel vs matériel La « crise du logiciel »

Figure 1.1 La crise du logiciel

Un autre symptôme de cette crise se situe dans la non qualité des

Prof. Pierre KAFUNDA KATALAY

 Avion C17 de McDonnel Douglas livré avec un département de 500

D‟après le cabinet de conseil en technologie de l‟information Standish

La solution imaginée pour répondre à cette crise a été

Prof. Pierre KAFUNDA KATALAY

 Le logiciel est un objet immatériel (pendant son développement), très

Cependant, grâce au GL des progrès ont été réalisés. Mais la

I.4. Caractéristiques (3)

Le GL est en forte relation avec presque tous les autres domaines de

 Les aspects socio-économiques.

I.5. Les principes(4)

Cette partie liste sept principes fondamentaux (proposés par Carlo

La production de logiciel est une activité créative, mais qui doit se

Le niveau maximum de rigueur est la formalité, c'est-à-dire le cas où

5.2. ‘’Séparation des problèmes’’

Prof. Pierre KAFUNDA KATALAY

C‟est une règle de bons sens qui consiste à considérer séparément

Elle prend une multitude de formes :

Les méthodes aident à organiser le travail en guidant dans la séparation

Un système est modulaire s‟il est composé de sous-systèmes plus

La modularité permet de considérer séparément le contenu du module

Prof. Pierre KAFUNDA KATALAY

Un bon découpage modulaire se caractérise par une forte cohésion

Figure 2.1 La modularité

Toute l‟évolution des langages de programmation vise à rendre plus

L‟abstraction consiste à ne considérer que les aspects jugés importants

Une même réalité peut souvent être décrite à différents niveaux

Prof. Pierre KAFUNDA KATALAY

5.5. Anticipation du changement

Le caractéristique essentielle du logiciel, par rapport à d‟autres

Il est parfois avantageux de remplacer la résolution d‟un problème

Exemple : plutôt que d‟écrire une identification spécifique à un écran

5.7. Construction incrémentale

Un procédé incrémental atteint son but par étapes en s‟en approchant

On peut par exemple réaliser d‟abord un noyau des fonctions

Prof. Pierre KAFUNDA KATALAY

construire une série de prototypes „simulant‟ plus ou moins complètement le

Ces principes sont très abstraits et ne sont pas utilisables directement.

I.6. PROCESSUS DE DÉVELOPPEMENT LOGICIEL (modèles de cycle de vie)

Un processus définit une séquence d’étapes, en partie ordonnées, qui

Comme pour toutes les fabrications, il est important d‟avoir un

Les modèles de cycle de vie du logiciel décrivent à un niveau très

Il faut souligner la différence entre étapes (découpages temporel) et

Prof. Pierre KAFUNDA KATALAY

déroulent dans plusieurs étapes (ex : la spécification, la validation et la

Rappelons aussi la différence entre vérification et validation (B.

6.2. Le modèle en cascade (‘waterfall’)