Cours UML 1.4

Etablissement Inter – Etats d’Enseignement Supérieur CENTRE D’EXCELLENCE TECHNOLOGIQUE PAUL BIYA
BP 13719 Yaoundé (Cameroun) Tél. (237) 22 72 99 58 - Fax (237) 22 72 99 57 Site web :

www.iaicameroun.com E-mail : contact@iaicameroun.com
Cours Langage de
Modélisation Unifié UML
M. DIFFOUO TAZO EVARISTE
Ingénieur Informaticien / Universitaire /

Enseignant à l’IAI Cameroun
Ce cours a pour objectif d’initier à la maîtrise des

concepts objets ainsi que des diagrammes du
langage de modélisation unifié (UML 1.4). D’une
part, il sera question de montrer en quoi l'approche
objet et UML constituent un "plus" et d'autre part,
d'exposer comment utiliser UML dans la pratique,
c'est-à-dire comment intégrer UML dans un
processus de développement et comment modéliser
avec UML. En somme, ce cours fournira des outils
qui permettront à un analyste de représenter des
systèmes entiers à partir des concepts objets en
utilisant UML : Les processus unifiés et les
modèles de développement.
Contenu
Chapitre I : Historique du langage de modélisation unifié UML et rappels sur des notions liées à
l’approche objet.....................................................................................................................................................3
Introduction........................................................................................................................................................3
I. Les méthodes objets et la genèse du langage de modélisation unifié UML ....................................4
1. Historique des méthodes d’analyse...................................................................................................4
2. Cadre d’utilisation d’UML.................................................................................................................5
3. Les points forts d’UML.......................................................................................................................7
4. Les points faibles d’UML...................................................................................................................7
II. Rappels sur des notions liées à l’approche objet.............................................................................7
1. Concepts importants de l’approche objet.........................................................................................8
2. Limites de l’approche objet................................................................................................................9
3. Solutions pour remédier aux inconvénients de l’approche objet..................................................9
Chapitre II : Démarche générale de modélisation avec UML ......................................................................11
Introduction......................................................................................................................................................11
I. Modélisation objet..................................................................................................................................11
1. Définition d’un modèle.....................................................................................................................11
2. Rôle de la modélisation.....................................................................................................................11
3. Caractéristiques fondamentales des modèles.................................................................................12
II. Comment modéliser avec UML ?....................................................................................................12
1. Proposition de la démarche...............................................................................................................12
2. Les différentes vues d’UML.............................................................................................................13
3. Les niveaux d’abstractions................................................................................................................16
4. Utilisation des diagrammes...............................................................................................................17
Chapitre III : Les différents types de diagrammes UML..............................................................................18
Introduction......................................................................................................................................................18
I. Les vues statiques...................................................................................................................................20
1. Diagramme de cas d’utilisation........................................................................................................20
2. Diagramme de classe.........................................................................................................................25
3. Diagramme d’objet............................................................................................................................31
4. Diagramme des composants.............................................................................................................32
5. Diagramme de déploiement..............................................................................................................33
II. Les vues dynamiques.........................................................................................................................34
1. Le diagramme de séquence...............................................................................................................35
Proposé par M. DIFFOUO TAZO Evariste Page 1

2. Le diagramme de collaboration........................................................................................................37
3. Le diagramme d’état transition........................................................................................................38
4. Le diagramme d’activité...................................................................................................................39
III. Modélisation et association des diagrammes.................................................................................42
IV. Les outils de modélisation................................................................................................................42
V. Quelques langages de programmation orientés objet........................................................................43
Chapitre IV : Le langage OCL et les processus unifiés.................................................................................44
Partie I : Le processus UP..................................................................................................................................44
I. Définition du processus unifié UP.......................................................................................................44
1. Les caractéristiques d’UP.................................................................................................................44
2. Le cycle de vie d’UP..........................................................................................................................46
3. Exemple de processus de développement logiciel qui implémente le Processus Unifié :
2TUP (Two tracks unified process).........................................................................................................48
4. Eléments de comparaisons entre MERISE et UML.....................................................................50
Partie II : Le langage OCL (Object Constraint Language)...........................................................................51
Introduction......................................................................................................................................................51
I. Les principaux concepts d’OCL...........................................................................................................51
1. Contexte (context)..............................................................................................................................52
2. Invariants (inv)...................................................................................................................................52
3. Préconditions et postconditions (pre, post)....................................................................................53
4. Types et opérations utilisables dans les expressions OCL ...........................................................53
5. Accès aux caractéristiques et aux objets dans les contraintes OCL ...........................................54
6. Illustration par l’exemple..................................................................................................................55

Chapitre I : Historique du langage de modélisation unifié UML et rappels sur des
notions liées à l’approche objet
Introduction
Pour faire face à la complexité croissante des systèmes d’information, de
nouvelles méthodes et outils ont été créés. La principale avancée des dernières années
réside dans la programmation orientée objet (P.O.O.).
Face à ce nouveau mode de programmation, les méthodes de modélisation classique
(MERISE, Axial, IE…) ont rapidement montré certaines limites et ont dû s’adapter
(MERISE/2 par exemple).
De très nombreuses autres méthodes ont également vu le jour comme Booch, OMT,
fusion …
Dans ce contexte et devant le foisonnement de nouvelles méthodes de conception «
orientée objet », l’Object Management Group (OMG) a eu comme objectif de définir
une notation standard utilisable dans les développements informatiques basés sur
l’objet. C’est ainsi qu’est apparu UML (Unified Modeling Language « langage de
modélisation unifié »). C’est un langage standard de modélisation des systèmes
d’information. Il en est à ce jour à sa version 2.5. Dans ce cours nous nous arrêterons à
l’étude approfondie d’UML 1.x.

I. Les méthodes objets et la genèse du langage de modélisation unifié UML
1. Historique des méthodes d’analyse
Les méthodes utilisées dans les années 1980 pour organiser la programmation
impérative ou structurée ou fonctionnelles (notamment Merise) étaient fondées sur la
modélisation séparée des données et des traitements.
Lorsque la programmation par objets prend de l’importance au début des années 1990,
la nécessité d’une méthode qui lui soit adaptée devient évidente. Plus de cinquante méthodes
apparaissent entre 1990 et 1995 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD,
OOM, OOSE, etc.) mais aucune ne parvient à s’imposer. En 1994, le consensus se fait autour
de trois méthodes :
– OMT (Object Modeling Technique) de James Rumbaugh fournit une représentation
graphique des aspects statique, dynamique et fonctionnel d’un système ;
– OOD (Object-Oriented Design) ou encore Booch de Grady Booch, introduit le
concept de paquetage (package) ;
– OOSE (Object-Oriented Software Engineering) d’Ivar Jacobson fonde l’analyse sur
la description des besoins des utilisateurs (cas d’utilisation, ou use cases).
Chaque méthode avait ses avantages et ses partisans. Le nombre de méthodes en
compétition s’était réduit, mais le risque d’un éclatement subsistait : la profession pouvait se
diviser entre ces trois méthodes, créant autant de continents intellectuels qui auraient du mal à
communiquer. Événement considérable et presque miraculeux, les trois Acteurs qui régnaient
chacun sur l’une des trois méthodes se mirent d’accord pour définir une méthode commune
qui fédérerait leurs apports respectifs. UML (Unified Modeling Language) est né de cet effort
de convergence. L’adjectif unified est là pour marquer qu’UML unifie, et donc remplace. En
fait, UML n’a pas l’ambition d’être exactement une méthode : c’est un langage. L’unification
a progressé par étapes. En 1995, Booch et Rumbaugh (et quelques autres) se sont mis
d’accord pour construire une méthode unifiée, Unified Method 0.8 ; en 1996, Jacobson les a
rejoints pour produire UML 0.9. Les acteurs les plus importants dans le monde du logiciel
s’associent alors à l’effort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) et UML
1
1.0 est soumis à l’OMG . L’OMG adopte en novembre 1997, UML 1.1 comme langage de
modélisation des systèmes d’information à objets. La dernière version diffusée par l'OMG est
UML 2.5 bêta 2 depuis septembre 2013. Ci-dessous présenté la genèse de UML.
1L’OMG (Object Management Group) est une association américaine à but non-lucratif créée en 1989 dont l’objectif
est de standardiser et promouvoir le modèle objet sous toutes ses formes. L’OMG est notamment à la base des
spécifications UML, MOF, CORBA et IDL. L’OMG est aussi à l’origine de la recommandation MDA

Figure 1 : Genèse de UML
2. Cadre d’utilisation d’UML
UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus
d'élaboration des modèles. UML n'est ni une méthode, ni un processus. Qualifier UML de
"méthode objet" n'est donc pas tout à fait approprié. Une méthode propose aussi un processus,
qui régit notamment l'enchaînement des activités de production d'une entreprise. Or UML n'a
pas été pensé pour régir les activités de l'entreprise. Un processus est adapté (donc très lié) au
domaine d'activité de l'entreprise ; même s'il constitue un cadre général, il faut l'adapter au
contexte de l'entreprise.
UML permet de modéliser des applications selon une vision objet. Son
appréhension est complexe car UML est à la fois :
• une norme,
• un langage de modélisation objet,
• un support de communication,
• un cadre méthodologique.
2.1. UML est une norme
UML est non seulement un outil intéressant mais aussi une norme qui s’impose en
technologie à objets et à laquelle se sont rangés tous les grands acteurs du domaine ; acteurs
qui ont d’ailleurs contribué à son élaboration. En effet en Novembre 1997, UML est devenu
une norme OMG (Object Management Group). Aujourd'hui, l'OMG fédère plus de 850
acteurs du monde informatique. Son rôle est de promouvoir des standards qui garantissent
l'interopérabilité entre applications orientées objet, développées sur des réseaux hétérogènes.

2.2. UML est un langage de modélisation objet
UML est un langage formel, défini par un métamodèle. Un métamodèle permet de
limiter les ambiguïtés et encourage la construction d'outils. Il permet aussi de classer les
différents concepts du langage (selon leur niveau d'abstraction ou leur domaine d'application)
et expose ainsi clairement sa structure. Le métamodèle d'UML décrit de manière très précise
tous les éléments de modélisation et la sémantique de ces éléments. En d'autres termes : UML
normalise les concepts objet. UML est donc un outil indispensable pour tous ceux qui ont
compris que programmer objet, c'est d'abord concevoir objet. UML n'est pas à l'origine des
concepts objets, mais il en constitue une étape majeure, car il unifie les différentes approches
et en donne une définition plus formelle.
2.3. UML est un support de communication

UML est avant tout un support de communication performant, qui facilite la
représentation et la compréhension de solutions objet. Sa notation graphique permet
d'exprimer visuellement une solution objet, ce qui facilite la comparaison et l'évaluation de
solutions. L'aspect formel de sa notation limite les ambiguïtés et les incompréhensions. Son
indépendance par rapport aux langages de programmation, aux domaines d'application et aux
processus, en font un langage universel.
2.4. UML est un cadre méthodologique

Une caractéristique importante d'UML, est qu'il cadre l'analyse. UML permet de
représenter un système selon différentes vues complémentaires : les 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. Chaque type de diagramme UML possède une
structure (les types des éléments de modélisation qui le composent sont prédéfinis) et véhicule
une sémantique précise (il 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. Les diagrammes permettent donc d'inspecter un modèle selon différentes
perspectives et guident l'utilisation des éléments de modélisation (les concepts objet), car ils
possèdent une structure.
Une autre caractéristique importante des diagrammes UML, est qu'ils supportent
l'abstraction. Cela permet de mieux contrôler la complexité dans l'expression et l'élaboration
des solutions objet.

3. Les points forts d’UML
o UML est un langage formel et normalisé. En effet :
 Avec UML comme langage de modélisation ; on a un gain de précision ;
 UML est un gage de stabilité ;
 UML encourage l'utilisation d'outils.
o UML est un support de communication performant. En effet :
 Il cadre l'analyse
 Il facilite la compréhension de représentations abstraites complexes
 Son caractère polyvalent et sa souplesse en font un langage universel
4. Les points faibles d’UML

o La mise en pratique d'UML nécessite un apprentissage et passe par une période
d'adaptation. En effet même si la nécessité de s'accorder sur des modes d'expression communs
est vitale en informatique ; UML n 'est pas à l'origine des concepts objets, mais en constitue
une étape majeure, car il unifie les différentes approches et en donne une définition plus
formelle.
o Le processus (non couvert par UML) est une autre clé de la réussite d'un projet.
Or, l'intégration d'UML dans un processus n'est pas triviale et améliorer un processus est une
tâche complexe et longue. Les auteurs d'UML sont tout à fait conscients de l'importance du
processus, mais l'acceptabilité industrielle de la modélisation objet passe d'abord par la
disponibilité d'un langage d'analyse objet performant et standard.
II. Rappels sur des notions liées à l’approche objet

Aujourd’hui l’approche objet occupe une place prépondérante dans le génie logiciel.
Cette approche considère le logiciel comme une collection d’objets dissociés, identifiés et
possédant des caractéristiques. Une caractéristique est soit un attribut (i.e. une donnée
caractérisant l’état de l’objet), soit une entité comportementale de l’objet (i.e. une fonction).
La fonctionnalité du logiciel émerge alors de l’interaction entre les différents objets qui le
constituent. L’une des particularités de cette approche est qu’elle rapproche les données et
leurs traitements associés au sein d’un unique objet.
Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :
L’identité – L’objet possède une identité, qui permet de le distinguer des autres objets,
indépendamment de son état. On construit généralement cette identité grâce à un identifiant

découlant naturellement du problème (par exemple un produit pourra être repéré par un code,
une voiture par un numéro de série, etc.)
Les attributs – Il s’agit des données caractérisant l’objet. Ce sont des variables stockant des
informations sur l’état de l’objet.
Les méthodes – Les méthodes d’un objet caractérisent son comportement, c’est-à-dire
l’ensemble des actions (appelées opérations) que l’objet est à même de réaliser. Ces
opérations
permettent de faire réagir l’objet aux sollicitations extérieures (ou d’agir sur les autres objets).
De plus, les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre
des valeurs des attributs, ou bien les modifier.
1. Concepts importants de l’approche objet

Nous avons dit que l’approche objet rapproche les données et leurs traitements. Mais
cette approche ne fait pas que ça, d’autres concepts importants sont spécifiques à cette
approche orientée objet et participent à la qualité du logiciel.
Classe et Objet
Une classe est un type de données abstrait qui précise des caractéristiques (attributs et
méthodes) communes à toute une famille d’objets et qui permet de créer (instancier) des
objets possédant ces caractéristiques. On parle de caractéristiques ou de propriétés de classes.
Un objet est une instance de classe (une occurrence d'un type abstrait).
Encapsulation
L’encapsulation consiste à masquer les détails d’implémentation d’un objet, en définissant
une interface. (L’interface est la vue externe d’un objet, elle définit les services accessibles
(offerts) aux utilisateurs de l’objet). L’encapsulation facilite l’évolution d’une application car
elle stabilise l’utilisation des objets : on peut modifier l’implémentation des attributs d’un
objet sans modifier son interface, et donc la façon dont l’objet est utilisé. L’encapsulation
garantit l’intégrité des données, car elle permet d’interdire, ou de restreindre, l’accès direct
aux attributs des objets.
Héritage (Spécialisation et Généralisation)
L’héritage est un mécanisme de transmission des caractéristiques d’une classe (ses attributs et
méthodes) appelée classe mère ou superclasse vers une autre classe appelée classe fille ou
sous-classe. Une classe peut être spécialisée en d’autres classes, afin d’y ajouter des
caractéristiques spécifiques ou d’en adapter certaines. Plusieurs classes peuvent

être généralisées en une classe qui les factorise, afin de regrouper les caractéristiques
communes d’un ensemble de classes.
Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies de classes.
L’héritage évite la duplication et encourage la réutilisation. L’héritage peut être simple ou
multiple.
Polymorphisme
Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des objets de
classes différentes. C’est-à-dire la faculté d'une même opération (méthode) de s'exécuter
différemment suivant le contexte de la classe où elle se trouve.
Ainsi, une opération définie dans une superclasse peut s'exécuter de façon différente selon la
sous-classe où elle est héritée. Le polymorphisme augmente la généricité, et donc la qualité,
du code.
Agrégation et Composition
Il s’agit d’une relation entre deux classes, spécifiant que les objets d’une classe sont des
composants de l’autre classe. Une relation d’agrégation permet donc de définir des objets
composés d’autres objets. L’agrégation permet donc d’assembler des objets de base, afin de
construire des objets plus complexes. Une composition est une agrégation forte.
2. Limites de l’approche objet

o L'approche objet est moins intuitive que l'approche fonctionnelle ! En effet, pour
appliquer l’approche orientée objet, il faut pouvoir répondre aux questions suivantes :
 Quels moyens utiliser pour faciliter l'analyse objet ?
 Quels critères identifient une conception objet pertinente ?
 Comment comparer deux solutions de découpe objet d'un système ?
o L'application des concepts objets nécessite une grande rigueur ! Avec l’approche objet, le
vocabulaire doit être est précis (risques d'ambiguïtés, d'incompréhensions). Ici, il faut
pouvoir répondre à la question suivante :
 Comment décrire la structure objet d'un système de manière pertinente ?
3. Solutions pour remédier aux inconvénients de l’approche objet

Pour remédier aux inconvénients ci haut cités, il faut bénéficier d’un langage pour exprimer
les concepts objet qu'on utilise, afin de pouvoir :
 Représenter des concepts abstraits (graphiquement par exemple) ;

 Limiter les ambiguïtés (parler un langage commun) ;
 Faciliter l'analyse (simplifier la comparaison et l'évaluation de
solutions). Il faut également une démarche d'analyse et de conception objet, pour :
 Ne pas effectuer une analyse fonctionnelle et se contenter d’une
implémentation objet, mais penser objet dès le départ ;
 Définir les vues qui permettent de couvrir tous les aspects d'un système, avec
des concepts objets.

Chapitre II : Démarche générale de modélisation avec UML
Introduction
I. Modélisation objet
1. Définition d’un modèle
Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains détails), d’une
entité (phénomène, processus, système, etc.) du monde réel en vue de le décrire, de
l’expliquer ou de le prévoir. Un modèle est une abstraction de la réalité. L'abstraction est un
des piliers de l'approche objet : il s'agit d'un processus qui consiste à identifier les
caractéristiques intéressantes d'une entité, en vue d'une utilisation précise. Concrètement, un
modèle permet de réduire la complexité d’un phénomène en éliminant les détails qui
n’influencent pas son comportement de manière significative. Il reflète ce que le concepteur
croit important pour la compréhension et la prédiction du phénomène modélisé.
2. Rôle de la modélisation
Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du
système. C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohérence.
Un modèle est un langage commun, précis, qui est connu par tous les membres de l’équipe et
il est donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est
essentielle pour aboutir à une compréhension commune aux différentes parties prenantes
(notamment entre la maîtrise d’ouvrage et la maîtrise d’œuvre informatique) et précise d’un
problème donné.
Dans le domaine de l’ingénierie du logiciel, le modèle permet de mieux répartir les tâches et
d’automatiser certaines d’entre elles. C’est également un facteur de réduction des coûts et des
délais.

3. Caractéristiques fondamentales des modèles
Le caractère abstrait d'un modèle doit notamment permettre :

 de faciliter la compréhension du système étudié : un modèle réduit la
complexité du système étudié.
 de simuler le système étudié : un modèle représente le système étudié et
reproduit ses comportements.
II. Comment modéliser avec UML ?
UML se décompose en plusieurs parties :

 Les vues : ce sont les observables du système. Elles décrivent le système d'un point de
vue donné, qui peut être organisationnel, dynamique, temporel, architectural,
géographique, logique, etc. En combinant toutes ces vues, il est possible de définir (ou
retrouver) le système complet.
 Les diagrammes : ce sont des ensembles d'éléments graphiques qui décrivent le
contenu des vues et qui sont des notions abstraites. Ils peuvent faire partie de plusieurs
vues.
 Les modèles d'élément : ce sont les éléments graphiques des diagrammes.
1. Proposition de la démarche
UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus
d'élaboration des modèles : UML n’est donc pas une méthode de modélisation. Cependant,
dans le cadre de la modélisation d'une application informatique, les auteurs d'UML
préconisent d'utiliser une démarche :
• itérative et incrémentale,
• guidée par les besoins des utilisateurs du système,
• centrée sur l'architecture logicielle.
D'après les auteurs d'UML, un processus de développement qui possède ces qualités devrait
favoriser la réussite d'un projet.
1.1. Une démarche itérative et incrémentale
Pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s'y prendre
en plusieurs fois, en affinant son analyse par étapes. Cette démarche doit aussi s'appliquer au

cycle de développement dans son ensemble, en favorisant le prototypage. Le but est de mieux
maîtriser la part d'inconnu et d'incertitudes qui caractérisent les systèmes complexes.
1.2. Une démarche pilotée par les besoins des utilisateurs
Avec UML, ce sont les utilisateurs qui guident la définition des modèles : Le périmètre du
système à modéliser est défini par les besoins des utilisateurs (les utilisateurs définissent ce
que doit être le système). Le but du système à modéliser est de répondre aux besoins de ses
utilisateurs (les utilisateurs sont les clients du système).
Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de développement
(itératif et incrémental) :
• à chaque itération de la phase d'analyse, on clarifie, affine et valide les besoins des
utilisateurs.
• à chaque itération de la phase de conception et de réalisation, on veille à la prise en
compte des besoins des utilisateurs.
• à chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont
satisfaits.
1.3. Une démarche centrée sur l'architecture
Une architecture adaptée est la clé de voûte du succès d'un développement. Elle décrit des
choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité,
performances, fiabilité...).
2. Les différentes vues d’UML

Les vues sont des observables du système. Elles décrivent le système d’un point de
vue donné qui peut être organisationnelle, dynamique, temporelle, architecturelle,
géographique…
Ph. Kruchten propose différentes perspectives (vues), indépendantes et complémentaires, qui
permettent de définir un modèle d'architecture (publication IEEE, 1995). Ph. Kruchten défend
l’idée que l’architecture logicielle doit être une discipline à part entière. Il propose que
plusieurs perspectives concourent à l’expression de l’architecture d’un système et il explique
qu’il est nécessaire de garantir la séparation et l’indépendance de ces différentes perspectives.
L’évolution de l’une des perspectives ne doit pas avoir d’impact (sinon limité) sur les autres.

La relation entre les différentes perspectives a été représentée par ph. Kruchten dans le
schéma suivant, dit « schéma 4+1 vues ».
En combinant ces vues, il est possible de définir le système complet. Ces vues sont :
2.1. La vue logique
Cette vue concerne « l’intégrité de conception ». Cette vue de haut niveau se concentre sur
l'abstraction et l'encapsulation, elle modélise les éléments et mécanismes principaux du
système. Elle identifie les éléments du domaine, ainsi que les relations et interactions entre ces
éléments « notions de classes et de relations » :
• les éléments du domaine sont liés au(x) métier(s) de l'entreprise,
• ils sont indispensables à la mission du système,
• ils gagnent à être réutilisés (ils représentent un savoir-faire).
Cette vue organise aussi (selon des critères purement logiques), les éléments du domaine en
"catégories" :
• pour répartir les tâches dans les équipes,

• regrouper ce qui peut être générique,
• isoler ce qui est propre à une version donnée, etc...
2.2. La vue des composants ou vue d’implémentation

Cette vue concerne « l’intégrité de gestion ». Elle exprime la perspective physique de
l’organisation du code en termes de modules, de composants et surtout des concepts du
langage ou de l’environnement d’implémentation. Dans cette perspective, l’architecte est
surtout concerné par les aspects de gestion du code, d’ordre de compilation, de réutilisation,
d’intégration et d’autres contraintes de développement pur. Pour représenter cette perspective,

UML fournit des concepts adaptés tels que les modules, les composants, les relations de
dépendance, l’interface …
Cette vue de bas niveau (aussi appelée « vue de réalisation »), montre ainsi :
• l'allocation des éléments de modélisation dans des modules (fichiers sources,
bibliothèques dynamiques, bases de données, exécutables, etc...). Cette vue identifie
les modules qui réalisent (physiquement) les classes de la vue logique.
• l'organisation des composants, c'est-à-dire la distribution du code en gestion de
configuration, les dépendances entre les composants...
• les contraintes de développement (bibliothèques externes...).
• l'organisation des modules en "sous-systèmes", les interfaces des sous-systèmes et
leurs dépendances (avec d'autres sous-systèmes ou modules).
2.3. La vue des processus

Cette vue concerne « l’intégrité d’exécution ». Cette vue est très importante dans les
environnements multitâches ; elle exprime la perspective sur les activités concurrentes et
parallèles. Elle montre ainsi :
• la décomposition du système en termes de processus (tâches).
• les interactions entre les processus (leur communication).
• la synchronisation et la communication des activités parallèles (threads).
2.4. La vue de déploiement

Cette vue concerne « l’intégrité de performance ». Cette vue est très importante dans les
environnements distribués et décrit les ressources matérielles et la répartition du logiciel dans
ces ressources. Elle exprime la répartition du système à travers un réseau de calculateurs et de
nœuds logiques de traitements. Cette vue est particulièrement utile pour décrire la distribution
d’un système réparti. Elle montre :
• la disposition et nature physique des matériels, ainsi que leurs performances.
• l'implantation des modules principaux sur les nœuds du réseau.
• les exigences en termes de performances (temps de réponse, tolérance aux fautes et
pannes...).

2.5. La vue des cas d’utilisation
Cette vue est particulière en ce sens qu’elle guide toutes les autres. Cette vue permet :
• de trouver le « bon » modèle.
Les cas d’utilisation permettent de guider la modélisation. L’utilisation des scénarios et des
cas d’utilisation s’avère plus rigoureuse et plus systématique que les entretiens et l’analyse
des documents pour découvrir les abstractions du domaine.
• d’expliquer et de justifier ses choix.
Il est en effet nécessaire d’expliquer le système, de justifier les choix qui ont guidé sa
conception et son fonctionnement pour pouvoir le construire, le maintenir et le tester. Pour
cela UML offre des concepts adaptés tels que les scénarios et les cas d’utilisation.
3. Les niveaux d’abstractions
3.1. Conceptualisation
L'entrée de l'analyse à ce niveau est le dossier d'expression des besoins client. A ce
niveau d'abstraction, on doit capturer les besoins principaux des utilisateurs. Il ne faut pas
chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins. Le but de la
conceptualisation est :
◦ de définir le contour du système à modéliser (de spécifier le "quoi"),
◦ de capturer les fonctionnalités principales du système, afin d'en fournir une meilleure
compréhension (le modèle produit sert d'interface entre les acteurs du projet),
◦ de fournir une base à la planification du projet.
3.2. Analyse du domaine

L'entrée de l'analyse à ce niveau, est le modèle des besoins clients (les "cas
d'utilisation" UML). Il s'agit de modéliser les éléments et mécanismes principaux du système.
On identifie les éléments du domaine, ainsi que les relations et interactions entre ces éléments
:
◦ les éléments du domaine sont liés au(x) métier(s) de l'entreprise,
◦ ils sont indispensables à la mission du système,
◦ ils gagnent à être réutilisés (ils représentent un savoir-faire).
A ce stade, on organise aussi (selon des critères purement logiques), les éléments du domaine
en "catégories", pour répartir les tâches dans les équipes, regrouper ce qui peut être générique,
etc...

3.3. Analyse applicative
A ce niveau, on modélise les aspects informatiques du système, sans pour autant
rentrer dans les détails d'implémentation. Les interfaces des éléments de modélisation sont
définis (cf. encapsulation). Les relations entre les éléments des modèles sont définies. Les
éléments de modélisation utilisés peuvent être propres à une version du système.
3.4. Conception
Ici, on y modélise tous les rouages d'implémentation et on détaille tous les éléments de
modélisation issue des niveaux supérieurs. Les modèles sont optimisés, car destinés à être
implémentés.
4. Utilisation des 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" car c’est par extension et abus de
langage qu’on traite un diagramme UML d’un modèle (un diagramme modélise un aspect du
modèle global).
Chaque type de diagramme UML possède une structure (les types des éléments de
modélisation qui le composent sont prédéfinis) et véhicule une sémantique précise.
Combinés, les différents types de diagrammes UML offrent une vue complète des
aspects statiques et dynamiques d'un système.
Les diagrammes UML supportent l'abstraction. Leur niveau de détail caractérise le niveau
d'abstraction du modèle. La structure des diagrammes UML et la notation graphique des
éléments de modélisation sont normalisées.

Chapitre III : Les différents types de diagrammes UML
Introduction
UML à partir de sa version 1.3 propose neuf (9) diagrammes tandis qu’il en existe
quatorze (14) depuis UML 2.3.
Les 14 diagrammes UML sont dépendants hiérarchiquement et se complètent, de façon à
permettre la modélisation d'un projet tout au long de son cycle de vie. Ils sont regroupés en
trois grandes vues :
 Diagrammes structurels ou statiques qui rassemblent :
 Diagramme de classes : il représente les classes intervenant dans le système ;
 Diagramme d’objets : il sert à représenter les instances de classes (objets)
utilisées dans le système ;
 Diagramme de composants : il permet de montrer les composants du système
d'un point de vue physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques,
bases de données…)
 Diagramme de déploiement : il sert à représenter les éléments matériels
(ordinateurs, périphériques, réseaux, systèmes de stockage…) et la manière dont
les composants du système sont répartis sur ces éléments matériels et
interagissent entre eux.
 Diagramme des paquetages : un paquetage étant un conteneur logique
permettant de regrouper et d'organiser les éléments dans le modèle UML, le
diagramme de paquetage sert à représenter les dépendances entre paquetages,
c’est-à-dire les dépendances entre ensembles de définitions.
 Diagramme de structure composite : depuis UML 2.x, permet de décrire sous
forme de boîte blanche les relations entre composants d'une classe.
 Diagramme de profils : depuis UML 2.2, permet de spécialiser, de personnaliser
pour un domaine particulier un meta-modèle de référence d'UML.
 Diagrammes comportementaux qui rassemblent :

 Diagramme des cas d'utilisation : il permet d'identifier les possibilités
d'interaction entre le système et les acteurs (intervenants extérieurs au
système), c'est-à-dire toutes les fonctionnalités que doit fournir le système.

 Diagramme états-transitions : permet de décrire sous forme de machine à états
finis le comportement du système ou de ses composants.
 Diagramme d'activité : permet de décrire sous forme de flux ou
d'enchaînement d'activités le comportement du système ou de ses composants.
 Diagrammes d'interaction ou dynamiques qui rassemblent :
 Diagramme de séquence : représentation séquentielle du déroulement des
traitements et des interactions entre les éléments du système et/ou de ses
acteurs.
 Diagramme de communication : depuis UML 2.2, représentation simplifiée
d'un diagramme de séquence se concentrant sur les échanges de messages entre
les objets.
 Diagramme global d'interaction : depuis UML 2.x, permet de décrire les
enchaînements possibles entre les scénarios préalablement identifiés sous
forme de diagrammes de séquences (variante du diagramme d'activité).
 Diagramme de temps : depuis UML 2.3, permet de décrire les variations d'une
donnée au cours du temps.
Nous allons dans le cadre de ce cours nous préoccuper de manière détaillée des diagrammes
d’UML 1.4.
Il existe 2 types de vues du système qui comportent chacune leurs propres diagrammes :
 les vues statiques :

◦ diagrammes de cas d'utilisation
◦ diagrammes d'objets
◦ diagrammes de classes
◦ diagrammes de composants
◦ diagrammes de déploiement
 les vues dynamiques :
◦ diagrammes de collaboration
◦ diagrammes de séquence
◦ diagrammes d'états-transitions
◦ diagrammes d'activités

I. Les vues statiques
Le but de la conceptualisation est de comprendre et structurer les besoins du client. Il ne faut

pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins. 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.
1. Diagramme de cas d’utilisation
A. Représentations graphiques
i. Les composants du diagramme de cas d’utilisation
 L’acteur :
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. Toute entité qui est en dehors de cette organisation
et qui interagit avec elle 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 (Bases de données, des
équipements…) 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.
Formalisme
 Les cas d’utilisations :

Un cas d'utilisation représente une fonctionnalité fournie par le système, typiquement décrite
sous la forme Verbe + objet. Il (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. Les cas d'utilisation sont représentés par une ellipse contenant leur nom.
Formalisme :
 Les associations :
Les associations sont utilisées pour lier des acteurs avec des cas d'utilisation. Elles
indiquent qu'un acteur participe au cas d'utilisation sous une forme quelconque. Les
associations sont représentées par une ligne reliant l'acteur et le cas d'utilisation.
Formalisme :
Représentation d’un diagramme de cas d’utilisation

ii. Les relations entre les cas d’utilisation

iii. La relation entre les acteurs
La seule relation possible entre deux acteurs est la généralisation : un acteur A est une
généralisation d’un acteur B si l’acteur A peut-être substitué par l’acteur B. Dans ce cas, tous
les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai. Le symbole
utilisé pour la généralisation entre acteurs est une flèche avec un trait plein dont la pointe est
un triangle fermé désignant l’acteur le plus général (comme nous l’avons déjà vu pour la
relation de généralisation entre cas d’utilisation).
Par exemple, la figure suivante montre que le directeur des ventes est un préposé aux
commandes avec un pouvoir supplémentaire : en plus de pouvoir passer et suivre une
commande, il peut gérer le stock. Par contre, le préposé aux commandes ne peut pas gérer le
stock.
B. Représentation textuelle des cas d’utilisation

Chaque cas d'utilisation, est associé à une série d'actions représentant la fonctionnalité voulue,
ainsi que les stratégies à utiliser dans l'alternative où la validation échoue, ou des erreurs se
produisent.
Un cas d’utilisation est donc une abstraction de plusieurs chemins d’exécution. Une instance
de cas d’utilisation est appelée : « scénario ». C’est un chemin particulier pris lors de
l’exécution d’un cas d’utilisation.
Le nombre d’instances pour un cas d’utilisation peut être très important, voire infini.
Les scénarios (scénarii) peuvent être classés en :
- scénario principal ou nominal : il correspond à l’instance principale du cas
d’utilisation. C’est le scénario typique de succès. C’est à dire le chemin « normal »
d’exécution du cas d’utilisation qui n’implique pas d’erreurs.

- Scénarios secondaires : il peut être un cas alternatif (un choix), un cas exceptionnel
ou une erreur.
La description textuelle est constituée des éléments suivants :

Le pré-supposé : ce sont les actions qui doivent être remplies avant le lancement du
cas d’utilisation.
La pré-condition : ce sont les conditions qui doivent être remplies avant le lancement
du cas d’utilisation.
Le déclencheur : C’est l’élément qui déclenche le cas d’utilisation.
Le dialogue : C’est le scénario principal et le Scénario secondaire.
La post condition : Ce sont les différents mécanismes pouvant conduire à la fin de
l’exécution du cas d’utilisation.
L’arrêt : C’est l’état du système à l’arrêt du cas d’utilisation.
Exercice d’application : Étude d'un système de réservation

Dans un établissement scolaire, on désire gérer la réservation des salles de cours ainsi
que du matériel pédagogique (ordinateur portable et / ou vidéo projecteur). Seuls les
enseignants sont habilités à effectuer des réservations (sous réserve de disponibilité de la salle
ou du matériel). Le planning des salles peut quant à lui être consulté par tout le monde
(enseignant et étudiant). Par contre, le récapitulatif horaire par enseignant (calculé à partir du
planning des salles) ne peut être consulté que par des enseignants. Enfin, il existe pour chaque
formation un enseignant responsable qui seul peut éditer le récapitulatif horaire pour
l’ensemble de la formation. Le chef d’établissement est le seul qui est habilité à gérer les
comptes d’utilisateurs. Il est également responsable de la gestion des salles de cours ainsi que
du matériel pédagogique.
Travail à faire :
1- Proposez le diagramme de cas d’utilisation (Représentation graphique).
2- Proposez la représentation textuelle des différents cas d’utilisation.
2. Diagramme de classe
Le diagramme de classes exprime la structure statique du système en termes de classes et de
relations entre ces classes.
L’intérêt du diagramme de classe est de modéliser les entités du système d’information. Le
diagramme de classe permet de représenter l’ensemble des informations finalisées qui sont
gérées par le domaine. Ces informations sont structurées, c’est-à-dire qu’elles ont regroupées
dans des classes. Le diagramme met en évidence d’éventuelles relations entre ces classes. Le
diagramme de classes comporte quelques concepts : classe, attribut, identifiant, opération
(méthode) et relation
i. La classe
Une classe est un type abstrait caractérisé par des propriétés (attributs et méthodes) communes
à un ensemble d'objets et permettant de créer des objets ayant ces propriétés. Ou encore la
description d’un ensemble d’objets partageant la même sémantique, ainsi que les mêmes
attributs, opérations et relations.
Représentation :
Les classes sont représentées en UML par des rectangles divisés en trois compartiments :
• le 1er compartiment représente le nom de la classe qui n’est pas souligné ;
• le 2ème compartiment représente les attributs typés de la classe ;
• le 3ème compartiment représente les opérations (méthodes) de la classe.
ii. Les attributs

Une classe correspond à un concept global d’information et se compose d’un ensemble
d’informations élémentaires, appelées attributs de classe. Un attribut représente la
modélisation d’une information élémentaire représentée par son nom et son format.
iii. L’identifiant de la classe

L’identifiant est un attribut particulier, qui permet de repérer de façon unique chaque objet,
instance de la classe.
iv. La notion d’opération (méthode)
L’opération représente un élément de comportement des objets, défini de manière globale

dans la classe. Une opération est une fonctionnalité assurée par une classe. La description des
opérations peut préciser les paramètres d’entrée et de sortie ainsi que les actions élémentaires
à exécuter.
 Visibilité et portée des attributs et des opérations :
v. La notion de relation
S’il existe des liens entre objets, cela se traduit nécessairement par des relations qui existent
entre leurs classes respectives. Les liens entre les objets doivent être considérés comme des
instances de relations entre classes.
Il existe plusieurs types de relations entre classes : l’association, la
généralisation/spécialisation et la dépendance
 L’association
Une association représente une relation structurelle entre classes d’objets. La plupart des
associations sont binaires, c’est à dire qu’elles connectent deux classes. On représente une
association en traçant une ligne entre les classes associées.
Cours Langage de Modélisation Unifié UML IAI
La multiplicité des associations

Elle définit le nombre d’instances de l’association pour une instance de la classe. La
multiplicité est définie par un nombre entier ou un intervalle de valeurs. La multiplicité est
notée sur le rôle (elle est notée à l’envers de la notation MERISE). Les valeurs de multiplicité
expriment les contraintes liées au domaine de l’application. Il est donc important de
déterminer les valeurs de multiplicité optimales pour trouver le bon équilibre entre complexité
et efficacité. La multiplicité est représentée sous la forme d’un couple de cardinalités.
Exemple : Considérons le diagramme de classe suivant :
Proposition de solution :
 Les classes-association
Les attributs d’une classe dépendent fonctionnellement de l’identifiant de la classe. Parfois,
un attribut dépend fonctionnellement de 2 identifiants, appartenant à 2 classes différentes ou il

Cours Langage de Modélisation Unifié UML IAI
peut arriver que l’on ait besoin de garder des informations (attributs ou opérations) propres à
une association. Une classe de ce type est appelée classe association.
Exemple 1 :
L’attribut « quantité » dépend fonctionnellement du numéro de commande et du code produit.

On va donc placer l’attribut « quantité commandée » dans l’association « comporter ».
Exemple 2 :
 L’agrégation
Dans UML, l’agrégation n’est pas un type de relation mais une variante de l’association. Une
agrégation représente une association non symétrique dans laquelle une des extrémités joue
un rôle prédominant par rapport à l’autre extrémité. L’agrégation se représente toujours avec
un petit losange du côté de l’agrégat.
Le choix d’une association de type agrégation traduit la volonté de renforcer la dépendance

entre classes. Les agrégations indiquent une relation de contenant contenu. Elle permet de
modéliser des relations de type maître et esclaves.
L’agrégation permet de modéliser une contrainte d’intégrité et de désigner l’agrégat comme
contrainte.
A travers une telle contrainte, il est possible de représenter par exemple :
• la propagation des valeurs d’attributs d’une classe vers une autre classe ;
• une action sur une classe qui implique une action sur une autre classe ;
• une subordination des objets d’une classe à une autre classe
Exemple :
 La composition
La composition est un cas particulier de l’agrégation dans laquelle la vie des composants est
liée à celle des agrégats. Elle fait souvent référence à une contenance physique. Dans la
composition l’agrégat ne peut être multiple.
La composition implique, en plus de l’agrégation, une coïncidence des durées de vie des
composants : la destruction de l’agrégat (ou conteneur) implique automatiquement la
destruction de tous les composants liés. La composition se représente par un losange noir.
Exemple 1 :

Exemple 2 :
Considérer les classes dossier et fichier (Un dossier contient 0 ou plusieurs fichiers. Un
fichier est dans un dossier).
 La généralisation / spécialisation
Le principe de généralisation / spécialisation permet d’identifier parmi les objets d’une classe
(générique) des sous-ensembles d’objets (des classes spécialisées) ayant des définitions
spécifiques. La classe plus spécifique (appelée aussi classe fille, classe dérivée, classe
spécialisée, classe descendante …) est cohérente avec la classe plus générale (appelée aussi
classe mère, classe générale …), c’est-à-dire qu’elle contient par héritage tous les attributs, les
membres, les relations de la classe générale, et peut contenir d’autres. Une relation de
généralisation est indiquée par une flèche creuse se dirigeant vers la classe "parent".
Exemple :
3. Diagramme d’objet
Un diagramme d’objets représente des objets (i.e. instances de classes) et leurs liens (i.e.
instances de relations). Ils modélisent des exemples de classes et sont employés pour décrire
le système à un instant particulier. A l’exception de la multiplicité, qui est explicitement
indiquée, le diagramme d’objets utilise les mêmes concepts que le diagramme de classes. Ils
sont essentiellement utilisés pour comprendre ou illustrer des parties complexes d’un
diagramme de classes.
Représentation : Les diagrammes des objets représentent seulement les objets et les
associations.

i. Les objets
Des objets sont identifiés en plaçant le nom d'instance suivi des deux points (:) devant le nom
de la classe, les deux soulignés. Les valeurs de propriété sont écrites comme des paires
"nom=valeur". L'icône représentant un objet est un rectangle divisé en sections.
ii. L’association
Les associations entre les objets sont représentées simplement en utilisant une ligne les
joignant.
Exemple : diagramme de classes et de diagramme d’objets associé
4. Diagramme des composants

Le diagramme des composants est principalement employé pour décrire les dépendances entre
les divers composants logiciels tels que la dépendance entre les fichiers exécutables et les
fichiers source.
Représentation : Ils décrivent les composants et leurs dépendances dans l’environnement de
réalisation.
i. Composants
Un composant représente une entité logicielle d'un système. Un composant est représenté par
une boîte rectangulaire, avec deux rectangles dépassant du côté gauche.
UML définit 5 stéréotypes aux composants :

- « « document » » : un document quelconque,
- « « exécutable » » : un programme qui peut s’exécuter,

- « « fichier » » : un document contenant un code source ou des données,
- « « bibliothèque » » : une bibliothèque statique ou dynamique,
- « « table » » : une table de base de données relationnelle.
ii. Dépendance
Une dépendance est utilisée pour modéliser la relation entre deux composants. La
notation utilisée pour cette relation de dépendance est une flèche pointillée, se
dirigeant d'un composant donné au composant dont il dépend.
5. Diagramme de déploiement
Le diagramme de déploiement modélise les composants matériels utilisés pour

implémenter un système et l'association entre ces composants. Des diagrammes de
déploiement peuvent être mise en œuvre dès la phase de conception pour documenter
l'architecture physique du système.
Représentation : Les éléments utilisés dans des diagrammes de déploiement sont des
composants, comme dans les diagrammes des composants, et des nœuds, qui
représentent les ressources physiques de traitement du système, et leurs associations.
i. Composant
Un composant représente une entité logicielle du système. (Fichier de code source,
programmes, documents, fichiers de ressource, etc.). Sur un diagramme de
déploiement, les composants sont placés dans des nœuds pour identifier l'endroit de
leur déploiement.
ii. Nœud
Un nœud représente un ensemble d'éléments matériels du système. Cette entité
est représentée par un cube tridimensionnel.

iii. Association
Une association, représentée par une ligne pleine entre deux nœuds, indique une
ligne de communication entre les éléments matériels.
Exemple2
II. Les vues dynamiques

Les cas d’utilisation sont centrés sur les besoins des utilisateurs. Ils aident à construire le bon
système. Ils disent ce qu’un système doit faire, non comment il doit le faire. La vue des cas
d’utilisation est une description fonctionnelle des besoins, structurée par rapport à des acteurs.

Le passage à l’approche objet s’effectue en associant une collaboration à chaque cas
d’utilisation.
Une collaboration décrit les objets du domaine, les connexions entre ces objets et les
messages échangés par les objets.
1. Le diagramme de séquence
Les diagrammes des séquences documentent les interactions à mettre en œuvre entre les
classes pour réaliser un résultat, tel qu'un cas d'utilisation. UML étant conçu pour la
programmation orientée objet, ces communications entre les classes sont reconnues comme
des messages. Le diagramme des séquences énumère des objets horizontalement, et le temps
verticalement. Il modélise l'exécution des différents messages en fonction du temps.
Représentation : Dans un diagramme des séquences, les classes et les acteurs sont énumérés
en colonnes, avec leurs lignes de vie verticales indiquant la durée de vie de l'objet.
i. Objet
Les objets sont des instances des classes, et sont rangés horizontalement. La représentation
graphique pour un objet est similaire à une classe (un rectangle) précédée du nom d'objet
(facultatif) et des deux points (:).
ii. Acteur
Les acteurs peuvent également communiquer avec des objets, ainsi ils peuvent eux aussi être
énumérés en colonne. Un acteur est modélisé en utilisant le symbole habituel :
iii. Ligne de vie

Les lignes de vie, LifeLine, identifient l'existence de l'objet par rapport au temps. La notation
utilisée pour une ligne de vie est une ligne pointillée verticale partant de l'objet.
iv. Activation
Les activations, sont modélisées par des boîtes rectangulaires sur la ligne de vie. Elles
indiquent quand l'objet effectue une action.

Message
Les messages, modélisés par des flèches horizontales entre les activations, indiquent les
communications entre les objets.
L'exemple ci-dessous représente un diagramme des séquences qui utilise des objets
par défaut (aucun nom n'est spécifié).
Exemple

Le diagramme de collaboration
Les diagrammes de collaboration modélisent les interactions entre les objets. Ce type de
diagramme est un croisement entre un diagramme des objets et un diagramme des séquences.
À la différence du diagramme des séquences qui modélise l'interaction dans un format de type
ligne-colonne, le diagramme des collaborations emploie une disposition libre des objets tels
qu'on les trouve dans un diagramme des objets. Ceci facilite la vision de toutes les
interactions impliquant un objet particulier.
Afin de maintenir l'ordonnancement des messages dans un tel diagramme de formes libres,
ces derniers sont notés avec un numéro chronologique. La lecture d'un diagramme des
collaborations implique de commencer au message 1.0, et de suivre ainsi la séquence des
messages d'objet en objet.
Représentation :
i. Objet :
Les objets, instances des classes, représentent une des entités impliquées dans les
communications. La représentation graphique pour un objet est similaire à une classe
(un rectangle) précédée du nom d'objet (facultatif) et des deux points (:).
ii. Acteur
Les acteurs peuvent également communiquer avec des objets, aussi peuvent-ils être présents
sur des diagrammes de collaborations. Un acteur est modélisé en utilisant le symbole habituel
suivant :
iii. Message
Les messages, modélisés par des flèches entre les objets, sont affectés d'un numéro et
indiquent les communications entre les objets.
Exemple

3. Le diagramme d’état transition
Les diagrammes d'état sont utilisés pour documenter les divers modes ("état") qu'une classe
peut prendre, et les événements qui causent une transition d'état. Ils ont pour rôle de
représenter les traitements (opérations) qui vont gérer le domaine étudié. Ils définissent
l'enchaînement des états de classe et font donc apparaître l'ordonnancement des travaux.
Représentation :
i. Etat :
Un état correspond à une situation durable dans laquelle se trouvent les objets d'une classe.
On lui associe les règles de gestion et les activités particulières.
Etat : objets d'une classe + règles de gestion + changements d'états
Elle est représentée par rectangle avec les coins arrondis, contenant le nom de l'état.
Exemples pour une commande : Etat "en préparation" et Etat "en cours"
ii. Transition ou événement
Une transition décrit le changement de l'état d'un objet, provoqué par un événement. Un objet
passe d'un état à un autre suite à un événement, certains événements pouvant ne pas provoquer
de changement d'état. Une transition est une relation entre 2 états. Elle est orientée. Sa
représentation symbolique est une flèche sur laquelle est annoté l'événement qui concourt au
changement d'état.
Ou
Exemple : Une commande passera dans l'état "En attente" dès lors qu'elle aura été expédiée.
iii. Etat initial

L’état initial est l'état d'un objet avant toutes transitions. L'état initial est représenté par un
cercle plein. Un seul état initial est autorisé sur un diagramme.
iv. Etat final
L’état final représente la destruction de l'objet que nous modélisons. Selon les événements, il
peut exister plusieurs états finaux. Ces états sont représentés par un cercle plein entouré d'un
cercle.
Exemple 1 : Diagramme d'état qui modélise l'état du compte d'un utilisateur :
Exemple 2 : de diagramme d'état qui modélise l'état d’une commande :
4. Le diagramme d’activité
Les diagrammes d'activité sont utilisés pour documenter le déroulement des opérations dans
un système, du niveau commercial au niveau opérationnel (de haut en bas). En regardant un
diagramme d'activité, vous trouverez des éléments des diagrammes d'état. En fait, le
diagramme d'activité est une variante du diagramme d'état où les "états" représentent des
opérations, et les transitions représentent les activités qui se produisent quand l'opération est
terminée. L'usage général des diagrammes d'activité permet de faire apparaître les flots de
traitements induits par les processus internes par rapport aux évènements externes.
Représentation :
i. Etat d’activité ou une activité :
L’état d'activité marque une action faite par un objet. Il est représenté par un rectangle
arrondi.

ii. Transition
Quand un état d'activité est accompli, le traitement passe à un autre état d'activité. Les
transitions sont utilisées pour marquer ce passage. Les transitions sont modélisées par des
flèches.
iii. Couloir
Le diagramme d'activités fait intervenir les acteurs de chaque activité. Chaque activité sera
placée dans une colonne (couloir) qui correspond à l'acteur. Les objets sont énumérés au-
dessus de la colonne, et les barres verticales séparent les colonnes pour former les couloirs
d’activités.
iv. Etat initial
L’état initial marque le point d'entrée la première activité. Il est représenté, comme dans le
diagramme d'état, par un cercle plein. Il ne peut y avoir qu'un seul état initial sur un
diagramme.
v. Etat final
L'état final marque la fin du déroulement des opérations modélisées. Il peut y avoir des états
finaux multiples sur un diagramme. Ils sont représentés par un cercle plein entouré d'un autre
cercle.
vi. Barre de Synchronisation
Souvent, certaines activités peuvent être faites en parallèle. Pour dédoubler le traitement
"Fork", ou le reprendre quand des activités multiples ont été accomplies ("join"), des barres
de synchronisation sont utilisées. Celles-ci sont modélisées par des rectangles pleins, avec des
transitions multiples entrantes ou sortantes.

alisme du Diagramme
Exemple : Authentification d’un utilisateur

III. Modélisation et association des diagrammes
UML étant un langage de modélisation, n’impose pas une méthode de travail. Pour la
réalisation d’un projet, l’utilisation de tous les diagrammes n’est pas obligatoire. Leur
utilisation varie en fonction des exigences et des fonctionnalités du système étudié.
Le tableau ci-dessous résume l’utilisation de quelques diagrammes pour la réalisation
de chaque phase d’un projet.
Besoins des utilisateurs : spécifier le système en Diagramme de cas

définissant les acteurs, les cas d’utilisation et les d’utilisation
associations équivalentes)
Interactions entre objets : Modéliser les objets Diagramme de séquence
communicants en identifiant et en nommant les instances Diagramme de collaboration
(objets physiques puis abstraits), on spécifie les liens entre
les objets et les messages transitant par ces liens.)
Structure statique : Modéliser la structure de Diagramme de classes
l’application Diagramme objet
Dynamique des objets : Modéliser le comportement des Diagramme états -transition
objets et les traitements. Diagramme d’activités
Réalisation et déploiement : Modéliser l’implantation de Diagramme de composants
l’application Diagramme de déploiement
IV. Les outils de modélisation
Voici une liste non exhaustive des logiciels de modélisation des diagrammes en UML.
Logiciels libres :
Neptune outil permettant de vérifier les modèles UML1.x via des règles OCL ;
ATL solution open source pour faire des transformations de modèles vers ou depuis
UML (entre autres);
ArgoUml un modeleur UML sous Licence BSD ;
Gaphorun modeleur UML sous GPL;
BOUML, un modeleur UML sous GPL pour Windows, Linux, MacOS X et Solaris ;
Eclipse UML2, Méta modèle UML2, sans interface graphique ; Netbeans [1],
logiciel open source de Sun;
Papyrus un modeleur UML2 open source pour la plateforme Eclipse Licence EPL;

Delphia Object Modeler (version personnelle), Outil de modélisation et de prototypage.
Logiciels propriétaires
Enterprise Architect, un outil de modélisation UML ;
MagicDraw, un éditeur de diagrammes UML ;
Objecteering d'Objecteering Software ;
Poseidon (version commerciale), basé sur ArgoUml (logiciel libre);
PowerAMC / PowerDesigner [3], de Sybase (un outil de modélisation complet intégrant
l'UML en plus des classiques MCD, MPD ...) ;
Rhapsody de Telelogic pour une modélisation PSM (Platform Specific Model)
complète de systèmes ou de logiciels embarqués ;
Rational Software Architect/ Rational Software Modeler (et toujours Rose/XDE), de
IBM Software Rational ;
SDE for Eclipse, un plugin UML pour Eclipse;
Visual Paradigm for UML, de Visual Paradigm International Ltd;
Delphia Object Modeler (version commerciale), Outil de modélisation et de
prototypage. Diagrammes de classe et d'état. Langage objet intégré. Générateur de
Java…
V. Quelques langages de programmation orientés objet
• Ada
• C++ (voir aussi la catégorie C++)
• C#
• Delphi (=Pascal orienté objet)
• Java
• Kylix
• Objective-C
• Objective Caml (ocaml)
• Perl
• PHP (Depuis la version 4)
• Python
• SmallTalk (totalement objet)
Etc.

Chapitre IV : Le langage OCL et les processus unifiés
Partie I : Le processus UP
I. Définition du processus unifié UP
La maîtrise des processus de développement implique une organisation et un suivi des

activités : c’est ce à quoi s’attachent les différentes méthodes qui s’appuient sur l’utilisation
du langage UML pour modéliser un système d’information. UP (Unified Process) est une
méthode générique de développement de logiciel. Générique signifie qu'il est nécessaire
d'adapter UP au contexte du projet, de l'équipe, du domaine et/ou de l'organisation (exemple :
R.UP, X.UP, 2 TUP…).
1. Les caractéristiques d’UP
Le processus unifié est un processus de développement logiciel : il regroupe les activités à

mener pour transformer les besoins d’un utilisateur en système logiciel.
Les caractéristiques essentielles du processus unifié sont :

- Il est à base de composants,
- Il utilise le langage UML (ensemble d'outils et de diagramme),
- Il est piloté par les cas d’utilisation,
- Il est centré sur l’architecture,
- Il est itératif et incrémental.
a) Le processus unifie est pilote par les cas d’utilisation
L’objectif principal d’un système logiciel est de rendre service à ses utilisateurs ; il faut par
conséquent bien comprendre les désirs et les besoins des futurs utilisateurs. Le processus de
développement sera donc centré sur l'utilisateur. Le terme utilisateur ne désigne pas seulement
les utilisateurs humains mais également les autres systèmes.
Les cas d’utilisation ne sont pas un simple outil de spécification des besoins du
système. Ils vont complètement guider le processus de développement à travers l’utilisation
de modèles basés sur l’utilisation du langage UML.

b) Le processus unifie est centre sur l’architecture
Dès le démarrage du processus, on aura une vue sur l'architecture à mettre en place.
L’architecture d’un système logiciel peut être décrite comme les différentes vues du système
qui doit être construit. L’architecture logicielle équivaut aux aspects statiques et dynamiques
les plus significatifs du système. L’architecture émerge des besoins de l’entreprise, tels qu’ils
sont exprimés par les utilisateurs et autres intervenants et tels qu’ils sont reflétés par les cas
d’utilisation.
Elle subit également l’influence d’autres facteurs :
 la plate-forme sur laquelle devra s’exécuter le système ;
 les briques de bases réutilisables disponibles pour le développement ;
 les considérations de déploiement, les systèmes existants et les besoins non
fonctionnels (performance, fiabilité..).
c) Le processus unifie est itératif et incrémental
Le développement d’un produit logiciel destiné à la commercialisation est une vaste entreprise
qui peut s’étendre sur plusieurs mois. On ne va pas tout développer d’un coup. On

peut découper le travail en plusieurs parties qui sont autant de mini projets. Chacun d’entre
eux représentant une itération qui donne lieu à un incrément.
Une itération désigne la succession des étapes de l’enchaînement d’activités, tandis

qu’un incrément correspond à une avancée dans les différents stades de développement. Le
choix de ce qui doit être implémenté au cours d’une itération repose sur deux facteurs :
 Une itération prend en compte un certain nombre de cas d’utilisation qui ensemble,
améliorent l’utilisabilité du produit à un certain stade de développement.
 L’itération traite en priorité les risques majeurs.
Un incrément constitue souvent un additif. A chaque itération, les développeurs identifient et

spécifient les cas d’utilisations pertinents, créent une conception en se laissant guider par
l’architecture choisie, implémentent cette conception sous forme de composants et vérifie que
ceux-ci sont conformes aux cas d’utilisation. Dès qu’une itération répond aux objectifs fixés
le développement passe à l’itération suivante. Pour rentabiliser le développement il faut
sélectionner les itérations nécessaires pour atteindre les objectifs du projet. Ces itérations
devront se succéder dans un ordre logique. Un projet réussi suivra un déroulement direct,
établi dès le début par les développeurs et dont ils ne s’éloigneront que de façon très
marginale. L’élimination des problèmes imprévus fait partie des objectifs de réduction des
risques.
2. Le cycle de vie d’UP
Présentation

Description
Le processus unifié répète un certain nombre de fois une série de cycles. Tout cycle se conclut
par la livraison d’une version du produit aux clients et s’articule en 4 phases : création,
élaboration, construction et transition, chacune d’entre elles se subdivisant à son tour en
itérations. Pour mener efficacement le cycle, les développeurs ont besoin de construire toutes
les représentations du produit logiciel :

3. Exemple de processus de développement logiciel qui implémente le
Processus Unifié : 2TUP (Two tracks unified process)
Dans le processus 2TUP, les activités de développement sont organisées suivant 5

workflows qui décrivent :
 La capture des besoins,
 L’analyse,
 La conception,
 L’implémentation
 Et le test.
Le processus 2TUP est une trame des meilleures pratiques de développement, il doit
être utilisé comme un guide pour réaliser un projet et non comme l’arme ultime et
universelle de développement.
A. Le cycle de développement avec 2TUP
Le 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques

des aspects fonctionnels. Il commence par une étude préliminaire qui consiste
essentiellement à identifier les acteurs qui vont interagir avec le système à construire,
les messages qu'échangent les acteurs et le système. En suite à produire le cahier des
charges et à modéliser le contexte. Le processus s'articule autour de 3 phases
essentielles : une branche technique ; une branche fonctionnelle et une phase de
réalisation.
i. La branche fonctionnelle
La branche fonctionnelle capitalise la connaissance du métier de l’entreprise. Cette branche

comporte :
 La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le
métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un système
inadapté aux utilisateurs. De son côté, la maîtrise d’œuvre consolide les spécifications et
en vérifie la cohérence et l'exhaustivité.
 L'analyse, qui consiste à étudier précisément la spécification fonctionnelle de manière à
obtenir une idée de ce que va réaliser le système en termes de métier. Les résultats de
l'analyse ne dépendent d'aucune technologie particulière.

ii. La branche technique
La branche technique capitalise un savoir-faire technique et/ou des contraintes techniques.

Les techniques développées pour le système le sont indépendamment des fonctions à réaliser.
Cette branche droite comporte :
 La capture des besoins techniques, qui recense toutes les contraintes et les choix
dimensionnant la conception du système. Les outils et les matériels sélectionnés ainsi
que la prise en compte de contraintes d'intégration avec l'existant conditionnent
généralement des pré-requis d'architecture technique ;
 La conception générique, qui définit ensuite les composants nécessaires à la
construction de l'architecture technique. Celle conception est complètement
indépendante des aspects fonctionnels. Elle a pour objectif d'uniformiser et de
réutiliser les mêmes mécanismes pour tout un système. L'architecture technique
construit le squelette du système informatique et écarte la plupart des risques de
niveau technique. L'importance de sa réussite est telle qu'il est conseillé de réaliser un
prototype pour assurer sa validité.
iii. La phase de réalisation
La phase de réalisation consiste à réunir les deux branches, permettant de mener une
conception applicative et enfin la livraison d'une solution adaptée aux besoins. La branche du
milieu comporte :
 La conception préliminaire, qui représente une étape délicate, car elle intègre le
modèle d'analyse dans l'architecture technique de manière à tracer la cartographie des
composants du système à développer,
 La conception détaillée, qui étudie ensuite comment réaliser chaque composant ;
 L’étape de codage, qui produit ces composants et teste au fur et à mesure les unités de
code réalisées,
 L’étape de recette, qui consiste enfin à valider les fonctions du système développé.
iv. Représentation

4. Eléments de comparaisons entre MERISE et UML
MERISE :UML :
Méthode d’Étude et de Réalisation Unified Modeling Language

Informatique pour les Systèmes d’Entreprises
MERISE est une méthode systémique UML n’est cependant pas une méthode
d’analyse et de conception de systèmes mais plutôt un langage de modélisation
d’information. C'est-à-dire qu’elle utilise objet à qui il faut associer une démarche
une approche systémique. pour en faire une méthode. c’est le cas de
la méthode 2TUP, RUT et XP.
MERISE propose de considérer le UML propose une approche différente

système réel selon deux points de vue: de celle de MERISE en ce sens qu’il
associe les données et les traitements.
- Une vue statique (données)
- Une vue dynamique (traitements). Car avec UML, centraliser les données d'un
type et les traitements associés permet de
C'est-à-dire qu’avec la méthode MERISE, limiter les points de maintenance dans le
nous avons une étude séparée des données et code et facilite l'accès à l'information en
des traitements. cas d'évolution du logiciel. De plus, UML
décrit la dynamique du système
d’information comme un ensemble
d’opérations attachées aux objets du
système.

Partie II : Le langage OCL (Object Constraint Language)
Introduction
Pour spécifier complètement une application, les diagrammes UML seuls sont généralement
insuffisants. Il est donc nécessaire de rajouter des contraintes.
C’est avec OCL (Object Constraint Language) qu’UML formalise l’expression des
contraintes. Il s’agit donc d’un langage formel d’expression de contraintes bien adapté aux
diagrammes d’UML, et en particulier au diagramme de classes.
OCL existe depuis la version 1.1 d’UML et est une contribution d’IBM. OCL fait partie
intégrante de la norme UML depuis la version 1.3 d’UML. Dans le cadre d’UML 2.0, les
spécifications du langage OCL figurent dans un document indépendant de la norme d’UML,
décrivant en détail la syntaxe formelle et la façon d’utiliser ce langage.
OCL peut s’appliquer sur la plupart des diagrammes d’UML et permet de spécifier des
contraintes sur l’état d’un objet ou d’un ensemble d’objets comme :
– des invariants sur des classes ;
– des pré-conditions et des post-conditions à l’exécution d’opérations : les pré-

conditions doivent être vérifiées avant l’exécution et les post-conditions doivent être vérifiées
après l’exécution ;
– des gardes sur des transitions de diagrammes d’états-transitions ou des messages de

diagrammes d’interaction ;
– des ensembles d’objets destinataires pour un envoi de message ;
– des attributs dérivés, etc.
Note : Une expression OCL décrit une contrainte à respecter et pas le « code » d'une méthode.
I. Les principaux concepts d’OCL

Considérons le diagramme de classe suivant associé à une application de gestion
bancaire.

1. Contexte (context)
Une contrainte est toujours associée à un élément de modèle. C’est cet élément qui constitue
le contexte de la contrainte. On dit aussi qu’une expression OCL est toujours définie dans un
contexte.
Il existe deux manières pour spécifier le contexte d’une contrainte OCL :
– En écrivant la contrainte entre accolades ({}) dans une note. L’élément pointé par la
note est alors le contexte de la contrainte.
– En utilisant le mot-clef context dans un document accompagnant le diagramme.
Syntaxe : context <élément>
<élément> peut être une classe, une opération, etc.
Pour faire référence à un élément op (comme un opération) d’un classeur C (comme une
classe), ou d’un paquetage, . . ., il faut utiliser les :: comme séparateur (comme C::op).
Exemple
 context Compte est le contexte est la classe Compte ;

 context Compte::getSolde() est le contexte de l’opération getSolde() de la classe
Compte ;
 on peut simplement ajouter une note pour préciser contrainte : {solde > 0},
2. Invariants (inv)
Un invariant exprime une contrainte prédicative sur un objet, ou un groupe d’objets, qui doit
être respectée en permanence.
Syntaxe : inv : <expression_logique>

<expression_logique> est une expression logique qui doit toujours être
vraie. Exemple
Le solde d’un compte doit toujours être positif.
context Compte
inv : solde > 0
3. Préconditions et postconditions (pre, post)

Une précondition (respectivement une postcondition) permet de spécifier une contrainte
prédicative qui doit être vérifiée avant (respectivement après) l’appel d’une opération.
Dans l’expression de la contrainte de la postcondition, deux éléments particuliers sont
utilisables :
– l’attribut result qui désigne la valeur retournée par l’opération,
– et <nom_attribut>@pre qui désigne la valeur de l’attribut <nom_attribut> avant
l’appelde l’opération.
Syntaxe :
– Précondition : pre : <expression_logique>
– Postcondition : post : <expression_logique>
<expression_logique> est une expression logique qui doit toujours être vraie.
Exemple
Concernant la méthode débiter de la classe Compte, la somme à débiter doit être positive pour
que l’appel de l’opération soit valide et, après l’exécution de l’opération, l’attribut solde doit
avoir pour valeur la différence de sa valeur avant l’appel et de la somme passée en paramètre.
context Compte::débiter(somme : Real)
pre : somme > 0
post : solde = solde@pre - somme
Le résultat de l’appel de l’opération getSolde doit être égal à l’attribut solde.
context Compte : :getSolde() : Real
post : result = solde
4. Types et opérations utilisables dans les expressions OCL

Le langage OCL possède un certain nombre de types prédéfinis et d’opérations prédéfinies
sur ces types. Ces types et ces opérations sont utilisables dans n’importe quelle contrainte et
sont indépendants du modèle auquel sont rattachées ces contraintes.
Le tableau suivant donne un aperçu des types et opérations prédéfinis dans les contraintes
OCL.
OCL définit également la notion d’ensemble sous le terme générique de collection

(collection en anglais). Il existe plusieurs sous-types du type abstrait Collection :
 Ensemble (Set) : collection non ordonnée d’éléments uniques (i.e. pas
d’élément en double).
 Ensemble ordonné (OrderedSet) : collection ordonnée d’éléments uniques.
 Sac (Bag) : collection non ordonnée d’éléments identifiables (i.e. comme un
ensemble, mais pouvant comporter des doublons).
 Séquence (Sequence) : collection ordonnée d’éléments identifiables.
Jusqu’à UML 2.0 exclu, les collections étaient toujours plates : une collection ne pouvait pas
posséder des collections comme éléments. Cette restriction n’existe plus à partir d’UML 2.0.
5. Accès aux caractéristiques et aux objets dans les contraintes OCL

Dans une contrainte OCL associée à un objet, il est possible d’accéder aux caractéristiques
(attributs, opérations et terminaison d’association) de cet objet, et donc, d’accéder de manière
transitive à tous les objets (et leurs caractéristiques) avec qui il est en relation.
 Accès aux attributs et aux opérations (self)
Pour faire référence à un attribut ou une opération de l’objet désigné par le contexte, il suffit
d’utiliser le nom de cet élément. L’objet désigné par le contexte est également accessible par
l’expression self. On peut donc également utiliser la notation pointée : self.<propriété>.
Une opération peut avoir des paramètres, il faut alors les préciser entre les parenthèses de
l’opération.
Par exemple, dans le contexte de la classe Compte, on peut utiliser les expressions suivantes :
– solde

– self.solde
– getSolde()
– self.getSolde()
– débiter(1000)
– self.débiter(1000)
Dans l’exemple précédent, le résultat de l’expression self.débiter(1000) est un singleton du
type Real.
 Navigation via une association
Pour faire référence à un objet, ou un groupe d’objets, en association avec l’objet désigné par
le contexte, il suffit d’utiliser le nom de la classe associée (en minuscule) ou le nom du rôle
d’association du coté de cette classe. Quand c’est possible, il est préférable d’utiliser le nom
de rôle de l’association du côté de l’objet auquel on désire faire référence.
Par exemple, dans le contexte de la classe Société (context Société) :
– directeur désigne le directeur de la société (résultat de type Personne) ;
– employé désigne l’ensemble des employés de la société (résultat de type Set(Personne)) ;
– employé.compte désigne l’ensemble des comptes de tous les employés de la société (résultat
de type Bag(Compte)) ;
– employé.date_de_naissance désigne l’ensemble des dates de naissance des employés de la

société (résultat de type Bag(Date)).
6. Illustration par l’exemple

Utilisation du langage de contrainte OCL sur l’exemple bancaire. On obtient

Cours UML 1.4

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours UML 1.4

Transféré par

Droits d'auteur :

Formats disponibles

Etablissement Inter – Etats d’Enseignement Supérieur CENTRE D’EXCELLENCE TECHNOLOGIQUE PAUL BIYA

BP 13719 Yaoundé (Cameroun) Tél. (237) 22 72 99 58 - Fax (237) 22 72 99 57 Site web :

M. DIFFOUO TAZO EVARISTE

Ingénieur Informaticien / Universitaire /

Ce cours a pour objectif d’initier à la maîtrise des

Proposé par M. DIFFOUO TAZO Evariste Page 1

Proposé par M. DIFFOUO TAZO Evariste Page 2

Proposé par M. DIFFOUO TAZO Evariste Page 3

Proposé par M. DIFFOUO TAZO Evariste Page 4

Proposé par M. DIFFOUO TAZO Evariste Page 5

2.3. UML est un support de communication

2.4. UML est un cadre méthodologique

Proposé par M. DIFFOUO TAZO Evariste Page 6

4. Les points faibles d’UML

II. Rappels sur des notions liées à l’approche objet

Proposé par M. DIFFOUO TAZO Evariste Page 7

1. Concepts importants de l’approche objet

Proposé par M. DIFFOUO TAZO Evariste Page 8

2. Limites de l’approche objet

3. Solutions pour remédier aux inconvénients de l’approche objet

Proposé par M. DIFFOUO TAZO Evariste Page 9

Proposé par M. DIFFOUO TAZO Evariste Page 10

Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du

système. C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohérence.

Proposé par M. DIFFOUO TAZO Evariste Page 11

Le caractère abstrait d'un modèle doit notamment permettre :

II. Comment modéliser avec UML ?

UML se décompose en plusieurs parties :

1.1. Une démarche itérative et incrémentale

Proposé par M. DIFFOUO TAZO Evariste Page 12

1.2. Une démarche pilotée par les besoins des utilisateurs

1.3. Une démarche centrée sur l'architecture

2. Les différentes vues d’UML

Proposé par M. DIFFOUO TAZO Evariste Page 13

2.1. La vue logique

• pour répartir les tâches dans les équipes,

2.2. La vue des composants ou vue d’implémentation

Proposé par M. DIFFOUO TAZO Evariste Page 14

2.3. La vue des processus

2.4. La vue de déploiement

Proposé par M. DIFFOUO TAZO Evariste Page 15

3. Les niveaux d’abstractions

3.2. Analyse du domaine

Proposé par M. DIFFOUO TAZO Evariste Page 16

4. Utilisation des diagrammes

Proposé par M. DIFFOUO TAZO Evariste Page 17

 Diagrammes comportementaux qui rassemblent :

Proposé par M. DIFFOUO TAZO Evariste Page 18

 les vues statiques :

Proposé par M. DIFFOUO TAZO Evariste Page 19

Le but de la conceptualisation est de comprendre et structurer les besoins du client. Il ne faut

Proposé par M. DIFFOUO TAZO Evariste Page 20

 Les cas d’utilisations :

Représentation d’un diagramme de cas d’utilisation

Proposé par M. DIFFOUO TAZO Evariste Page 21

Proposé par M. DIFFOUO TAZO Evariste Page 22

B. Représentation textuelle des cas d’utilisation

Proposé par M. DIFFOUO TAZO Evariste Page 24

La description textuelle est constituée des éléments suivants :

Exercice d’application : Étude d'un système de réservation

ii. Les attributs

iii. L’identifiant de la classe

iv. La notion d’opération (méthode)

L’opération représente un élément de comportement des objets, défini de manière globale