Chapitre 1:

Langage De Modélisation UML

Chapitre 1 Le langage de modélisation UML

1.1. Introduction

Le langage UML (Unified Modeling Language) est un langage graphique de

modélisation orienté objet conçu par OMG (Object Management Group) pour visualiser,
spécifier, construire et documenter les composantes d’un système à dominante logicielle
[OMG05]. L'UML représente une collection des meilleures techniques pratiques qui ont été
couronnées de succès dans la modélisation de grands et complexes systèmes.

UML est devenu le langage international du génie logiciel. Il a récemment subi une
révision importante (avancer de la version 1.5 à la version 2.0), y compris une redéfinition
complète des activités [StHa05].La deuxième version d’UML est une évolution importante
dans la modélisation dynamique. Les nouveaux perfectionnements permettent à cette nouvelle
version de décrire plusieurs éléments trouvés dans la technologie logicielle de nos jours aussi
bien que le MDA (Model Driven Architecture) et le SOA (Service-Oriented Architecture)
[Mil03].

Afin de mieux comprendre le langage UML, nous allons d’abord donner une définition
de la Modélisation et la modélisation orientée objet. Ensuite on présente avec un peu de
détail le langage UML avec une explication brièvement détaillé sur le diagramme d’activité
qui est un axe important dans notre travail.

2
Chapitre 1 Le langage de modélisation UML

1.2. Le génie logiciel

1.2.1. L’informatisation

L’informatisation est le phénomène le plus important de notre époque. Elle s’immisce

maintenant dans la plus part des objets de la vie courante et ce, que ce soit dans l’objet
proprement dit, ou bien dans le processus de conception ou de fabrication de cet objet.

1.2.2. Les logiciels

Un logiciel ou une application est un ensemble de programmes, qui permet à un

ordinateur ou à un système informatique d’assurer une tâche ou une fonction en particulier.
[Aud]

Les logiciels, suivant leur taille, peuvent être développés par une personne seule, une
petite équipe, ou un ensemble d’équipes coordonnées. Le développement de grands logiciels
par de grandes équipes pose d’importants problèmes de conception et de coordination. Or, le
développement d’un logiciel est une phase absolument cruciale qui monopolise l’essentiel du
coût d’un produit et conditionne sa réussite et sa pérennité.

Pour ces raisons, le développement de logiciels dans un contexte professionnel suit

souvent des règles strictes encadrant la conception et permettant le travail en groupe et la
maintenance du code. Ainsi, une nouvelle discipline est née : le génie logiciel.

1.2.3. Le génie logiciel

Le génie logiciel est un domaine de recherche qui a été défini (fait rare) du 7 au 11
octobre 1968, à Garmisch-Partenkirchen, sous le parrainage de l’OTAN. Il a pour objectif de
répondre à un problème qui s’énonçait en deux constatations : d’une part le logiciel n’était pas
fiable, d’autre part, il était incroyablement difficile de réaliser dans des délais prévus des
logiciels satisfaisant leur cahier des charges. [Aud]

L’objectif du génie logiciel est d’optimiser le coût de développement du logiciel.

L’importance d’une approche méthodologique s’est imposée à la suite de la crise de
l’industrie du logiciel à la fin des années 1970. Pour apporter une réponse à plusieurs
problèmes liés au domaine, le génie logiciel s’intéresse particulièrement à la manière dont le
code source d’un logiciel est spécifié puis produit.

3
Chapitre 1 Le langage de modélisation UML

1.3. Pourquoi et comment modéliser ?

1.3.1. Qu’est-ce qu’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. [RoVa03].

Les modèles offrent de nombreux avantages. Ceux qui pratiquent UML ou tout autre
langage de modélisation les connaissent bien. L’avantage le plus important qu’ils procurent
est de spécifier différents niveaux d’abstraction, facilitant la gestion de la complexité
inhérente aux applications.

Les modèles très abstraits sont utilisés pour présenter l’architecture générale d’une
application ou sa place dans une organisation, tandis que les modèles très concrets permettent
de spécifier précisément des protocoles de communication réseau ou des algorithmes de
synchronisation. Même si les modèles se situent à des niveaux d’abstraction différents, il est
possible d’exprimer des relations de raffinement entre eux. Véritables liens de traçabilité, ces
relations sont garanties de la cohérence d’un ensemble de modèles représentant une même
application.

En informatique : le modèle d’un système est la spécification formelle des fonctions, de

la structure et/ou du comportement de ce système dans son environnement, dans un certain
but. Un modèle est souvent représenté par des schémas et du texte. Le texte peut être exprimé
dans un langage de modélisation ou en langage naturel [Hoa08]

1.3.2. Pourquoi modéliser ?

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 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. Par exemple, les plateformes de

4
Chapitre 1 Le langage de modélisation UML

modélisation savent maintenant exploiter les modèles pour faire de la génération de code (au
moins au niveau du squelette) voire des allers retours entre le code et le modèle sans perte
d’information.

Le modèle est enfin indispensable pour assurer un bon niveau de qualité et une
maintenance efficace. En effet, une fois mise en production, l’application va devoir être
maintenue, probablement par une autre équipe et, qui plus est, pas nécessairement de la même
société que celle ayant créée l’application. Le choix du modèle a donc une influence capitale
sur les solutions obtenues. Les systèmes non triviaux sont mieux modélisés par un ensemble
de modèles indépendants. Selon les modèles employés, la démarche de modélisation n’est pas
la même [Aud].

1.4. Modèles de cycles de vie d’un logiciel

1.4.1. Modèle de cycle de vie en cascade

Le modèle de cycle de vie en cascade a été mis au point dès 1966, puis formalisé aux
alentours de 1970.

Dans ce modèle le principe est très simple : chaque phase se termine à une date précise
par la production de certains documents ou logiciels. Les résultats sont définis sur la base des
interactions entre étapes, ils sont soumis à une revue approfondie et on ne passe à la phase
suivante que s’ils sont jugés satisfaisants. Le modèle original ne comportait pas de possibilité
de retour en arrière. Celle-ci a été rajoutée ultérieurement sur la base qu’une étape ne remet en
cause que l’étape précédente, ce qui, dans la pratique, s’avère insuffisant.

Figure 0.1: modèle de cycle de vie en cascade

[Aud]
5
Chapitre 1 Le langage de modélisation UML

1.4.2. Modèle de cycle de vie en V

Le modèle en V demeure actuellement le cycle de vie le plus connu et certainement le

plus utilisé. Le principe de ce modèle est qu’avec toute décomposition doit être décrite la
recomposition, et que toute description d’un composant est accompagnée de tests qui
permettront de s’assurer qu’il correspond à sa description. [Aud]

Ceci rend explicite la préparation des dernières phases (validation-vérification) par les
premières (construction du logiciel), et permet ainsi d’éviter un écueil bien connu de la
spécification du logiciel : énoncer une propriété qu’il est impossible de vérifier objectivement
après la réalisation.

Figure 0.2: modèle de cycle de vie V

[Aud]

1.4.3. Modèle de cycle de vie en spirale

Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le précédent. Il
met l’accent sur l’activité d’analyse des risques : chaque cycle de la spirale se déroule en
quatre phases :

1. détermination, à partir des résultats des cycles précédents, ou de l’analyse préliminaire

des besoins, des objectifs du cycle, des alternatives pour les atteindre et des
contraintes;
2. analyse des risques, évaluation des alternatives et, éventuellement maquettage ;
3. développement et vérification de la solution retenue, un modèle « classique » (cascade
ou en V);
4. revue des résultats et vérification du cycle suivant.

6
Chapitre 1 Le langage de modélisation UML

1.4.4. Modèle par incrément

Dans les modèles précédents un logiciel est décomposé en composants développés

séparément et intégrés à la fin du processus. Dans les modèles par incrément un seul ensemble
de composants est développé à la fois : des incréments viennent s’intégrer à un noyau de
logiciel développé au préalable. Chaque incrément est développé selon l’un des modèles
précédents.

1.5. Méthodes d’analyse et de conception

Les méthodes d’analyse et de conception fournissent une méthodologie et des notations

standards qui aident à concevoir des logiciels de qualité. Il existe différentes manières pour
classer ces méthodes, dont :

La distinction entre composition et décomposition : elle met en opposition d’une part les
méthodes ascendantes qui consistent à construire un logiciel par composition à partir de
modules existants et, d’autre part, les méthodes descendantes qui décomposent récursivement
le système jusqu’à arriver à des modules programmables simplement.

La distinction entre fonctionnel (dirigée par le traitement) et orientée objet : dans la

stratégie fonctionnelle (également qualifiée de structurée) un système est vu comme un
ensemble hiérarchique d’unités en interaction, ayant chacune une fonction clairement définie.
Les fonctions disposent d’un état local, mais le système a un état partagé, qui est centralisé et
accessible par l’ensemble des fonctions. Les stratégies orientées objet considèrent qu’un
système est un ensemble d’objets interagissant. Chaque objet dispos d’un ensemble d’attributs
décrivant son état et l’état du système est décrit (de façon décentralisée) par l’état de
l’ensemble.

1.6. L’approche orientée objet :

L’approche orientée objet considère le logiciel comme une collection d’objets dissociés,
et identifiés, définis par des propriétés. Une propriété est soit un attribut (i.e. une donnée
caractérisant l’état de l’objet), entité élémentaire comportementale de l’objet. 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.

7
Chapitre 1 Le langage de modélisation UML

Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :

1.6.1. 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.)

1.6.2. 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.

1.6.3. 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.

La difficulté de cette modélisation consiste à créer une représentation abstraite, sous

forme d’objets, d’entités ayant une existence matérielle (chien, voiture, ampoule, personne,
etc...) ou bien virtuelle (client, temps, etc...).

La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures
logicielles fondées sur les objets du système, plutôt que sur la fonction qu’il est censé réaliser.

1.6.4. 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 et participent à la qualité du logiciel.

a. Notion de classe

Tout d’abord, introduisons la notion de classe. Une classe est un type de données
abstrait, caractérisé par des propriétés (attributs et méthodes) communes à toute une famille

8
Chapitre 1 Le langage de modélisation UML

d’objets et permettant de créer (instancier) des objets possédant ces propriétés. Les autres
concepts importants qu’il nous faut maintenant introduire sont l’encapsulation, l’héritage et
l’agrégation.

b. 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.

c. Héritage, Spécialisation, Généralisation et polymorphisme

L’héritage est un mécanisme de transmission des propriétés d’une classe (ses attributs et
méthodes) vers une 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 peut être simple ou multiple. L’héritage évite la duplication et encourage la
réutilisation.

Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des

objets de classes différentes. Le polymorphisme augmente la généricité, et donc la qualité, du
code.

d. Agrégation

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 complexe

9
Chapitre 1 Le langage de modélisation UML

1.7. Introduction à UML

UML (Unified Modeling Language) est un langage de modélisation orientée objet

développée en réponse à l’appel à propositions lancé par l’OMG (Object Management
Group) dans le but de définir la notation standard pour la modélisation des applications
construites à l’aide d’objets [RuJaBo04]. Il est hérité de plusieurs autres méthodes telles
qu'OMT1 (Object Modeling Technique) et OOSE2 (Object Oriented Software Engineering) et
Booch. Les principaux auteurs de la notation UML sont Grady Booch, Ivar Jacobson et Jim
Rumbaugh.

UML est utilisé pour spécifier un logiciel et/ou pour concevoir un logiciel. Dans la
spécification, le modèle décrit les classes et les cas d’utilisation vus de l’utilisateur final du
logiciel. Le modèle produit par une conception orientée objet est en général une extension du
modèle issu de la spécification [RuJaBo04].

Il enrichit ce dernier de classes, dites techniques, qui n’intéressent pas l’utilisateur final
du logiciel mais seulement ses concepteurs. Il comprend les modèles des classes, des états et
d’interaction. UML est également utilisée dans les phases terminales du développement avec
les modèles de réalisation et de déploiement.

UML est un langage utilisant une représentation graphique. L’usage d’une

représentation graphique est un complément excellent à celui de représentions textuelles. En
effet, l’une comme l’autre sont ambiguës mais leur utilisation simultanée permet de diminuer
les ambiguïtés de chacune d’elle. Un dessin permet bien souvent d’exprimer clairement ce
qu’un texte exprime difficilement et un bon commentaire permet d’enrichir une figure.

Il est nécessaire de préciser qu’un langage tel qu’UML ne suffit pas à produire un
développement de logiciel de qualité à toute seule. En effet, UML n’est qu’un formalisme, ou
plutôt un ensemble de formalismes permettant d’appréhender un problème ou un domaine et
de le modéliser, ni plus ni moins. Un formalisme n’est qu’un outil. Le succès du
développement du logiciel dépendant évidemment de la bonne utilisation d’une méthode
comme UML mais il dépend surtout de la façon dont on utilise cette méthode à l’intérieur du
cycle de développement du logiciel.

1
[Link]
2
[Link]

10
Chapitre 1 Le langage de modélisation UML

UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues
distinctes pour représenter des concepts particuliers du système. Ils se répartissent en deux
grands groupes :

Diagrammes structurels ou diagrammes statiques

 diagramme de classes (Class diagram)

 diagramme d’objets (Object diagram)

 diagramme de composants (Component diagram)

 diagramme de déploiement (Deployment diagram)

 diagramme de paquetages (Package diagram)

 diagramme de structures composites (Composite structure diagram)

Diagrammes comportementaux ou diagrammes dynamiques

 diagramme de cas d’utilisation (Use case diagram)

 diagramme d’activités (Activity diagram)

 diagramme d’états-transitions (State machine diagram)

 Diagrammes d’interaction (Interaction diagram)

 diagramme de séquence (Sequence diagram)

 diagramme de communication (Communication diagram)

 diagramme global d’interaction (Interaction overview diagram)

 diagramme de temps (Timing diagram)

Ces diagrammes, d’une utilité variable selon les cas, ne sont pas nécessairement tous
produits à l’occasion d’une modélisation. Les plus utiles pour la maîtrise d’ouvrage sont les
diagrammes d’activités, de cas d’utilisation, de classes, d’objets, de séquence et d’états-
transitions. Les diagrammes de composants, de déploiement et de communication sont surtout
utiles pour la maîtrise d’œuvre à qui ils permettent de formaliser les contraintes de la
réalisation et la solution technique.

11
Chapitre 1 Le langage de modélisation UML

1.8. Les diagrammes structurels

1.8.1. Les diagrammes de classe

Les diagrammes de classes expriment de manière générale la structure statique d'un

système, en termes de classes et de relations entre ces classes. Outre les classes, ils
représentent un ensemble d'interactions et de paquetages, ainsi que leurs relations. Les classes
sont les descripteurs d'un ensemble d'objets qui ont une structure, un comportement et des
relations similaires. Les classes sont représentées par des rectangles compartimentés. Les
classes sont reliées l’une à l’autre avec plusieurs formes : les associations (une classe associé
une autre classe), la dépendance (une classe dépend ou utilise une autre classe), la
spécialisation (une classe est une spécialisation d’une autre classe) …etc. [RuJaBo04]

L’exemple de la Figure 1.3 présente un diagramme de classe qui montre la classe auteur
et les classes ordinateurs que l’auteur peut utiliser.

Auteur Ordinateur
Utilise
Nom : String Nom : String
0..1 1..*
Age : Integer Mémoire : Integer

Figure 0.3 : Exemple d’un diagramme de classe

1.8.2. Le diagramme de packages

En UML, un diagramme de paquetages décrit comment un système est organisé en

groupes logiques appelés paquetages tout en montrant les dépendances entres ces paquetages.
En effet, Les packages (paquetages en français) permettent de regrouper et d'isoler des
classes, des associations, et éventuellement d'autre packages. Un package regroupe le plus
souvent un ensemble d'entités qui correspondent à une fonctionnalité bien définie. Bien
souvent, c'est cette fonctionnalité qui définira le nom du package. [RuJaBo04]

Un package n'introduit pas de sémantique particulière. Le système à concevoir est

représenté par un package racine.

12
Chapitre 1 Le langage de modélisation UML

1.8.3. Le diagramme de structure composite

C’est un nouveau diagramme introduit-en UML2. Il permet de présenter la

décomposition hiérarchique d’un objet, un cas d’utilisation, une collaboration, une activité ou
une classe, en un ensemble de structures internes. Ces structures internes sont des ensembles
d’éléments interconnectés avec leurs relations et leurs modes de communication. Ce
diagramme permet de réduire la complexité des objets en donnant une vue détaillée sur
l’architecture interne de ces objets durant l’exécution du système. [RoVa03]

1.8.4. Le diagramme de composant

Les diagrammes de composants décrivent les composants et leurs dépendances dans

l'environnement de réalisation. Les diagrammes de composants sont des vues statiques de
l'implémentation des systèmes qui montrent les choix de réalisation. En général ils ne sont
utilisés que pour des systèmes complexes. Un composant est un élément physique qui
représente une partie implémentée d'un système. Un composant peut être du code (source,
binaire ou exécutable), un script, un fichier de commande, un fichier de données, une table,
etc. il peut égaliser un ensemble d'interfaces qui définissent alors le comportement offert à
d'autres composants. Les services sont implémentés par les éléments du composant. En outre,
chaque composant peut posséder des attributs et des opérations. Un composant est
éventuellement connecté à d'autres composants (via des dépendances ou des compositions).
[RoVa03]

Figure 0.4 : Exemple de diagramme de composants

[GaGa08]

13
Chapitre 1 Le langage de modélisation UML

1.8.5. Le diagramme de déploiement

Un diagramme de déploiement est un graphe composé de nœuds interconnectés par des

liens de communication. Ce diagramme montre la disposition physique des différents
matériels « Les Nœuds » qui entrent dans la composition d'un système et la répartition des
instances de composants, processus et objets qui <<vivent>> sur ces matériels. Il peut
également donner la structure d'une plateforme technique, mais aussi de spécifier la
localisation des nœuds constitués par des unités distribuées, de préciser où se trouvent les
processus et de montrer comment les objets se créent et se déplacent dans une architecture
distribuée. [RoVa03]

1.8.6. Le diagramme d'objets

Le diagramme d'objets, dans le langage de modélisation de donnée UML, permet de

représenter les instances des classes, c'est-à-dire des objets. Comme le diagramme de classes,
il exprime les relations qui existent entre les objets, mais aussi l'état des objets, ce qui permet
d'exprimer des contextes d'exécution. En ce sens, ce diagramme est moins général que le
diagramme de classes. [RuJaBo04]

Les diagrammes d'objets s'utilisent pour montrer l'état des instances d'objet avant et
après une interaction, autrement dit c'est une photographie à un instant précis des attributs et
objet existant. Il est utilisé en phase exploratoire.

1.9. Les diagrammes comportementaux

1.9.1. Le diagramme de cas d’utilisation

Les cas d'utilisations constituent le concept principal de la méthode OOSE (Object

Oriented Software Engineering) d’Ivar Jakobson, un des pères d’UML. Un diagramme de cas
d’utilisation capture le comportement d’un système, d’un sous-système, d’une classe ou d’un
composant tel qu’un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en
unités cohérentes, les cas d’utilisation, ayant un sens pour les acteurs. Les cas d’utilisation
permettent d’exprimer le besoin des utilisateurs d’un système, ils sont donc une vision
orientée utilisateur de ce besoin au contraire d’une vision informatique. [RuJaBo04]

Le diagramme de cas d’utilisation se compose d’acteurs un cas d’utilisation. Les traits

entre les acteurs et les cas d’utilisation représentent les interactions.

14
Chapitre 1 Le langage de modélisation UML

Figure 0.5 : Exemple d'un diagramme de cas d’utilisation

[GaGa08]

1.9.2. Le diagramme global d’interaction

Comme son nom indique, le diagramme global d’interaction donne une vue globale sur
les interactions des objets actifs du système. Il regroupe des diagrammes d’activité et des
diagrammes de séquence. Il est présenté soit comme un diagramme d’activités dont les
activités sont remplacées par des diagrammes de séquence. Ou comme un diagramme de
séquence contenant des notations du diagramme d’activité pour montrer le flux des activités.
[RuJaBo04]

1.9.3. Le diagramme de temps

Le diagramme de temps est une nouveauté apparue dans UML2.0. Il permet de

présenter l’interaction entre les objets actifs et leurs changements d’état sur un axe de temps.
L’axe X présente le temps et contient des unités temporelles et l’axe Y montre les objets et
leurs états. [RuJaBo04]

1.9.4. Le diagramme d’activité

Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils sont
donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de
flots de données. Ils permettent ainsi de représenter graphiquement le comportement d’une
méthode ou le déroulement d’un cas d’utilisation [GaGa08].

15
Chapitre 1 Le langage de modélisation UML

Les diagrammes d’activités sont relativement proches des diagrammes d’états-

transitions dans leur présentation, mais leur interprétation est sensiblement différente. Les
diagrammes d’états-transitions sont orientés vers des systèmes réactifs, mais ils ne donnent
pas une vision satisfaisante d’un traitement faisant intervenir plusieurs classeurs et doivent
être complétés, par exemple, par des diagrammes de séquence. Au contraire, les diagrammes
d’activités ne sont pas spécifiquement rattachés à un classeur particulier. On peut attacher un
diagramme d’activités à n’importe quel élément de modélisation afin de visualiser, spécifier,
construire ou documenter le comportement de cet élément.

La différence principale entre les diagrammes d’interaction et les diagrammes

d’activités est que les premiers mettent l’accent sur le flot de contrôle d’un objet à l’autre,
tandis que les seconds insistent sur le flot de contrôle d’une activité à l’autre.

Dans la phase de conception, les diagrammes d’activités sont particulièrement adaptés à

la description des cas d’utilisation. Plus précisément, ils viennent illustrer et consolider la
description textuelle des cas d’utilisation De plus, leur représentation sous forme
d’organigrammes les rend facilement intelligibles et beaucoup plus accessibles que les
diagrammes d’états-transitions. On parle généralement dans ce cas de modélisation
de workflow. On se concentre ici sur les activités telles que les voient les acteurs qui
collaborent avec le système dans le cadre d’un processus métier. La modélisation du flot
d’objets est souvent importante dans ce type d’utilisation des diagrammes d’activités.

Les diagrammes d’activités permettent de spécifier des traitements a priori séquentiels

et offrent une vision très proche de celle des langages de programmation impératifs comme
C++ ou Java. Ainsi, ils peuvent être utiles dans la phase de réalisation car ils permettent une
description si précise des opérations qu’elle autorise la génération automatique du code. La
modélisation d’une opération peut toutefois être assimilée à une utilisation d’UML comme
langage de programmation visuelle, ce qui n’est pas sa finalité. Il ne faut donc pas y avoir
recours de manière systématique mais la réserver à des opérations dont le comportement est
complexe ou sensible [GaGa08].

a. Action

Une action correspond à un traitement qui modifie l’état du système. Cette action peut
être appréhendée soit à un niveau élémentaire proche d’une instruction en termes de
programmation soit à un niveau plus global correspondant à une ou plusieurs opérations.

16
Chapitre 1 Le langage de modélisation UML

 Formalisme et exemple

Une action est représentée par un rectangle dont les coins sont arrondis comme pour les
états du diagramme d’état-transition (Figure 1.6).

Figure 0.6 : Formalisme et exemple d’une action

b. Transition et flot de contrôle

Dès qu’une action est achevée, une transition automatique est déclenchée vers l’action
suivante. Il n’y a donc pas d’événement associé à la transition. L’enchaînement des actions
constitue le flot de contrôle.

 Formalisme et exemple

Le formalisme de représentation d’une transition est donné à la Figure 1.7.

Figure 0.7 : Formalisme de base du diagramme d’activité : actions et transition

c. Activité

Une activité représente le comportement d’une partie du système en termes d’actions et

de transitions. Une activité est composée de trois types de nœuds :

 Nœud d’exécution (action, transition),

 Nœud de contrôle (nœud initial, nœud final, flux de sortie, nœud fourche, nœud de
jonction, nœud de fusion-test, nœud de test-décision, pin d’entrée et de sortie),

 Nœud d’objet.

Une activité peut recevoir des paramètres en entrée et en produire en sortie.

17
Chapitre 1 Le langage de modélisation UML

 Formalisme et exemple

Nous donnons une première représentation simple à la Figure 1.8.

Figure 0.8 : Exemple de représentation d’une activité

[GaGa08]

d. Le nœud fourche (Fork)

Un nœud fourche (fork) permet à partir d’un flot unique entrant de créer plusieurs flots
concurrents en sortie de la barre de synchronisation.

 Formalisme et exemple

Le formalisme de représentation de nœud fourche ainsi qu’un premier exemple sont

donnés à la Figure 1.9. Un second exemple avec nœud fourche est donné à la Figure 1.10.

Figure 0.9 : Exemple 1 d’activités avec nœud fourche

[GaGa08]

Figure 0.10 : Exemple 2 de diagramme d’activité avec bifurcation de flots de contrôle

[GaGa08]

18
Chapitre 1 Le langage de modélisation UML

e. Nœud de jonction (Join)

Un nœud de jonction (join) permet, à partir de plusieurs flots concurrents en entrée de la

synchronisation, de produire un flot unique sortant. Le nœud de jonction est le symétrique du
nœud de fourche.

 Formalisme et exemple

Le formalisme de représentation d’un nœud de jonction est donné à la Figure 1.11.

Figure 0.11 : Exemple d’activités avec nœud de jonction

[GaGa08]

f. Nœud de test-décision

Un nœud de test-décision permet de faire un choix entre plusieurs flots sortants en

fonction des conditions de garde de chaque flot. Un nœud de test-décision n’a qu’un seul flot
en entrée. On peut aussi utiliser seulement deux flots de sortie : le premier correspondant à la
condition vérifiée et l’autre traitant le cas sinon.

 Formalisme et exemple

Le formalisme de représentation d’un nœud de test-décision ainsi qu’un premier

exemple sont donnés à la Figure 1.12. Un second exemple avec nœud de test-décision est
donné à la Figure 1.13.

Figure 0.12 : Formalisme et exemple 1 d’activités avec nœud de test-décision

[GaGa08]

19
Chapitre 1 Le langage de modélisation UML

Figure 0.13 : Exemple 2 de diagramme d’activités avec un nœud de test-décision

[GaGa08]

g. Nœud de fusion-test

Un nœud de fusion-test permet d’avoir plusieurs flots entrants possibles et un seul flot
sortant. Le flot sortant est donc exécuté dès qu’un des flots entrants est activé.

 Formalisme et exemple

Le formalisme de représentation d’un nœud de fusion-test ainsi qu’un exemple sont

donnés à la Figure 1.14.

Figure 0.14 : Formalisme et exemple de diagramme d’activités avec un nœud de fusion-

test
[GaGa08]

h. Pin d’entrée et de sortie

Un pin d’entrée ou de sortie représente un paramètre que l’on peut spécifier en entrée ou
en sortie d’une action. Un nom de donnée et un type de donnée peuvent être associés au pin.
Un paramètre peut être de type objet.

20
Chapitre 1 Le langage de modélisation UML

 Formalisme et exemple

Chaque paramètre se représente dans un petit rectangle. Le nom du paramètre ainsi que
son type sont aussi à indiquer. Le formalisme de représentation de pin d’entrée ou de sortie
ainsi qu’un exemple sont donnés à la Figure 1.15.

Figure 0.15 : Formalisme et exemple d’activité avec pin d’entrée et de sortie

[GaGa08]

i. Flot de données et nœud d’objet

Un nœud d’objet permet de représenter le flot de données véhiculé entre les actions. Les
objets peuvent se représenter de deux manières différentes : soit en utilisant le pin d’objet soit
en représentant explicitement un objet.

 Formalisme et exemple

Le formalisme de représentation de flot de données et nœud d’objet est donné

directement au travers d’un exemple (Figure 1.16).

Figure 0.16 : Exemple de flot de données et de nœud d’objets

[GaGa08]

j. Partition

UML permet aussi d’organiser la présentation du diagramme d’activité en couloir

d’activités. Chaque couloir correspond à un domaine de responsabilité d’un certain nombre
d’actions [GaGa08].

21
Chapitre 1 Le langage de modélisation UML

Les flots d’objets sont aussi représentés dans le diagramme. L’ordre relatif des couloirs
de responsabilité n’est pas significatif.

 Représentation du diagramme d’activité

Un exemple général de diagramme d’activité est donné à la Figure 1.17.

Figure 0.17 : Exemple de diagramme d’activité avec couloir d’activité

[GaGa08]

k. Représentation d’actions de communication

Dans un diagramme d’activité, comme dans un diagramme de temps, des interactions de

communication liées à certains types d’événement peuvent se représenter. Les types
d’événement concernés sont :

 signal,

 écoulement du temps.

 Formalisme et exemple

Le formalisme de représentation ainsi qu’un exemple d’actions de communication sont

donnés à la Figure 1.18.

22
Chapitre 1 Le langage de modélisation UML

Figure 0.18 : exemple de diagramme d’activité avec actions de communication

[GaGa08]

1.9.5. Diagramme d’états-transitions

Un diagramme d'états-transitions présente un automate à états finis. Il permet ainsi de

décrire les changements d'états d'un objet ou d'un composant.

Un état se caractérise par sa durée et sa stabilité.

Une transition représente le passage instantané d'un état vers un autre.

Une transition est déclenchée [RuJaBo04]:

 soit par un événement.

 soit automatiquement lorsque aucun événement déclencheur est spécifié.

Par exemple, le diagramme suivant présente un diagramme d’état.

Figure 0.19: Exemple de digramme états transition

[RuJaBo04]

23
Chapitre 1 Le langage de modélisation UML

1.9.6. Diagramme de séquence :

IL permet d’étudier les interactions entre les objets et constitue une partie dynamique de
système d’information. IL montre d’une façon séquentielle les envois des messages qui
interviennent entre les objets, il peut également montrer les flux des données :

Figure 0.20: Exemple de digramme séquence

[RuJaBo04]

1.9.7. Les diagrammes de communication :

Qui donne une représentation spatiale des objets, des liens des interactions, il est
équivalent au diagramme de séquence

1.10. Points forts et points faibles:

1.10.1. Les points forts d'UML:

 UML est un langage formel et normalisé

o gain de précision

o gage de stabilité

o encourage l'utilisation d'outils

 UML est un support de communication performant

o Il cadre l'analyse.

o Il facilite la compréhension de représentations abstraites complexes.

o Son caractère polyvalent et sa souplesse en font un langage universel.

24
Chapitre 1 Le langage de modélisation UML

[Link] points faibles d'UML:

o La mise en pratique d'UML nécessite un apprentissage et passe par une période

d'adaptation.

Même si l'Espéranto est une utopie, 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.

25
Chapitre 1 Le langage de modélisation UML

[Link]

Comme UML n'impose pas de méthode de travail particulière, il peut être intégré à
n'importe quel processus de développement logiciel de manière transparente. UML est une
sorte de boîte à outils, qui permet d'améliorer progressivement vos méthodes de travail, tout
en préservant vos modes de fonctionnement.

Intégrer UML par étapes dans un processus, de manière pragmatique, est tout à fait
possible. La faculté d'UML de se fondre dans le processus courant, tout en véhiculant une
démarche méthodologique, facilite son intégration et limite de nombreux risques (rejet des
utilisateurs, coûts...).

La deuxième version d’UML est une évolution importante dans la modélisation

dynamique. Toutefois, l’imprécision de sa sémantique exclut l’intégration de toute tâche de
validation. Pour combler ce manque, l’idée de coupler UML (méthode semi-formelle) à des
méthodes formelles (réseaux de Petri) a émergé. Les réseaux de Petri est le sujet du chapitre
suivant.

26