SUPPORT DE COURS

UML
Patrice BROU
annee academique 2010

1/27
Unité2 : une introduction à la méthode UML
Plan du cours
Introduction
Diagrammes statiques
Diagrammes dynamiques
Etude de cas

Introduction : Présentation des concepts

Les techniques de modélisation couvrent quatre aspects:

Elles aident à spécifier.

Elles aident à visualiser.
Elles aident à construire.
Elles aident à documenter.

Les techniques de modélisation se présentent souvent comme un ensemble de concepts, de

règles de construction, accompagnés d'un formalisme ( langage ou graphique), qui permet de
visualiser les résultats de la réflexion sur le système modélisé.

Les techniques servant à spécifier et à construire sont appelés modèles. En fait ce sont des
méta-modèles permettant de construire les modèles de l’artefact à modéliser. L'artefact est un
système à fabriquer, en l'occurrence ici, il s'agit d'un système logiciel.
Le produit final d'une modélisation (utilisation d’un modèle) est un diagramme.

La notion de modèles.

Un modèle est un ensemble de concepts prédéfinis (en général dans une méthode), qui aident
à réfléchir sur un artefact construit (existant) ou à construire (futur).

La construction à l'aide d'un modèle permet d'accroître la connaissance, la compréhension

que l'on a d'un système existant ou futur. Le modèle apparaît ici, sous l'angle d’une aide à la
compréhension d’un problème obtenu, il peut être vu comme une structure pour
comprendre ou pour nous aider à comprendre.

Un bon modèle doit être indépendant de la technique. Il doit intégrer le comportement, il doit
permettre d'exprimer le maximum de contraintes. Certaines contraintes sont inhérentes au
modèle (constructeur), d'autres seront explicitement exprimées, d'autres seront implicites,
c'est à dire déduites des autres. Un bon modèle doit réduire les choix possibles du
concepteur.

Les concepts utilisés dans un modèle doivent être propres sémantiquement. Leurs
définitions doivent être précise et mettre le modélisateur sur des rails en le guidant en
permanence dans ses choix.

2/27
Le modèle doit être expressif, il doit permettre de voir et de masquer certain détails du
système. Selon le niveau, l’abstraction (masquage du détail) pourra être plus ou moins
importante. En utilisant le modèle de données, on doit être capable de représenter n'importe
quelle propriété statique ou dynamique d ' intérêt pour le lecteur, avec le degré de précision
souhaité pour capturer la sémantique. Les concepts utilisés doivent être définis avec
précision. Il est indispensable d'avoir des outils associés. Il faut faire la preuve de l'intégrité
dans l'évolution du système d'information.

Le modèle doit être capable de s'auto-représenter.

La notion de diagramme
Le rôle d’un diagramme, s’il est suffisamment proche de la réalité est de nous donner des
renseignements sur le système réel (de manière descriptive: statique ou comportementale).
Son rôle est donc de nous renseigner sur le système réel. Un diagramme de système
d'information doit permettre d'expérimenter l'aspect statique et dynamique du système réel.
Ce diagramme peut représenter des éléments d’un artefact déjà construit ou à construire. Ce
diagramme peut représenter l’artefact sous différents aspects (structurel, comportemental,
fonctionnel) pour différentes préoccupations (conceptuel, organisationnel, logique,
technique).

Conditions de fabrication d’un diagramme:

Un diagramme quelque soit le niveau de préoccupation, est fait dans un but précis. Il doit
être adapté à son lecteur, et être élaboré avec des règles précises de construction qui doivent
être connues du lecteur lui-même. Que serait, une carte sans légende ? A quoi servirait une
mappemonde pour un piéton?

Le diagramme obtenu permet de voir le futur système . Le diagramme apparaît ici, sous
l'angle d'un diagramme pour voir. Il est donc extrêmement utile dans le dialogue avec les
différents interlocuteurs.

Niveau de réflexion et niveau de représentation:

Il est clair que notre pensée ne peut concevoir un système complexe ou comprendre un
système complexe en une seule fois. Les méthodes proposent donc des modèles à différents
niveaux. Se pose alors le problème du lien entre ces différents niveaux. Comment le
concepteur ou l’analyste peut il faire ce lien. De nombreuses méthodes fournissent des
règles de passage pour aller progressivement ( pour le systèmes d’information) vers les
modèles techniques (données, traitement), en suivant les différentes phases du processus de
création d'un système d'information. Un diagramme sémantique est plus précis que des
analyses de besoins informels, mais plus facile à comprendre qu'un diagramme de base de
données, pour un expert du domaine. Inversement, un administrateur de bases de données ou
un développeur seront plus familiers avec des diagrammes de représentation de structure
relationnelles ou de représentation d’algorithmes.

Durant le processus de modélisation, le modèle et le diagramme , dans ses différents états

intermédiaires doivent être clairement compris par les utilisateurs qui sont les personnes qui

3/27
travailleront dans le futur système. Ceci signifie qu'une interface graphique paraît
indispensable.

(Les ateliers de génie logiciel tels que MEGA, AMC DESIGNOR, Paradigm +, Rational
ROSE sont des outils indispensables pour représenter des systèmes. Les diagrammes
obtenus sont lisibles et bien documentés).
De nombreuses suggestions ont été faites pour représenter des diagrammes qui à partir d'une
vue globale d'un système complexe ignorant les détails, arrivent progressivement dans
d'autres modèles à décrire le détail. Ceci un peu comme un atlas qui montre un pays
complet , avant de montrer le pays province par province. Notons que UML propose un lien
« refines » entre le même élément de modèles vu à des niveaux différents.

Qualités d’un bon diagramme.

La représentation doit être la plus directe possible, la plus unique possible, malgré une
réduction de la flexibilité

Un bon diagramme est un outil lisible, clair, documenté, fournissant l’information au bon
niveau du lecteur. La notation ne doit pas être ambiguë. A un concept du modèle doit
correspondre un symbole, une notation. La notation doit être compacte, elle doit éviter tous
signe superflu ( trait, encadrement, etc..).

Le diagramme doit être présenté dans toute sa dimension, ceci nécessite souvent des formats
très grand (A3, A2,..).
Il doit être lisible par le lecteur. La lisibilité peut être vue à deux niveaux : celui de la taille
des informations présentes sur le diagramme et celui du choix des concepts représentés par
rapport au lecteur. Par exemple, la maîtrise d’ouvrage considérera qu’un diagramme
représentant une base de données ou un réseau comme peu utile. Inversement, un
développeur considérera un diagramme conceptuel comme peu utile.

Méthode d’analyse et de conception de logiciel.

Une méthode se doit de proposer 4 éléments fondamentaux:

Elle doit décrire une DEMARCHE, qui liste les tâches à effectuer pour conduire un projet
systèmes d'information.
Elle doit fournir un MODELE pour décrire la sémantique des données, leur comportement.
Elle doit fournir un ensemble de DIAGRAMMES s'appuyant sur un FORMALISME de
description (graphique ou langage).
Il doit être possible de trouver sur le marché des OUTILS LOGICIELS D'AIDE à la
conception.
Ces outils portent le nom d’A.G.L (Atelier de Génie Logiciel) ou C.A.S.E (Computer Aided
Software Engineering)

4/27
Dans le cadre de la conception oriente objet, un langage unifié pour la
modélisation a été développé : UML (Unified Modeling Language ). Il s'agit d'un
langage graphique de modélisation objet permettant de spécifier, de construire, de
visualiser et de décrire les détails d'un système logiciel. il est issu de la fusion de
plusieurs méthodes dont ´ BOOCH ª et ´ OMT ª et est adapté à la modélisation de
tous types de systèmes. La modélisation d'un système s'effectue indépendamment
de toute méthode ou de tout langage de programmation.

UML est un langage : il comprend un vocabulaire et un ensemble de règles centré

sur la représentation conceptuelle et physique d'un système logiciel.

Le modèle conceptuel d'UML

Le modèle conceptuel d'uml comprend les notions de base génériques du langage.

Il définit trois sortes de briques de base :
• les éléments, qui sont les abstractions essentielles à un modèle ;
• les relations, qui constituent des liens entre ces éléments ;
• les diagrammes, qui regroupent des éléments et des liens au sein de divers
ensembles.

Les éléments
Il existe quatre types d'éléments dans uml :
 les éléments structurels (classe, interface, collaboration,...) ;
 les éléments comportementaux (interaction, automate à états finis) ;
 les éléments de regroupement (package) ;
 les éléments d'annotation (note).

Les relations
Il existe quatre types de relations dans uml :
 la dépendance ;
 l'association ;
 la généralisation ;
 la réalisation.

Les diagrammes
Diagramme: représentation graphique d'un ensemble d'éléments et de relations
qui constituent un système.

5/27
uml définit neuf types de diagrammes divisés en deux catégories :

 diagrammes statiques (appelés aussi diagrammes structurels) : diagrammes

de classes, d'objets, de composants, de déploiements et de cas d'utilisation.

 diagrammes dynamiques (appelés aussi diagrammes comportementaux) :

diagrammes d'activités, de séquences, d'états-transitions et de
collaborations.

I – LES DIAGRAMMES STATIQUES

I.1 Le diagramme de classes

Diagrammes de classe: expriment de manière générale la structure statique d'un

système, en termes de classes et de relations entre ces classes.
Présentons les différents éléments d’un diagramme de classe.

I.1. 1 Les packages

Package: mécanisme d'ordre général qui permet d'organiser les éléments en

groupes.
Les packages permettent de définir des soussystèmes formés d'éléments ayant
entre eux une certaine logique. Leurs caractéristiques sont les suivantes :
-- Ils regroupent des éléments de modélisation selon des critères purement
logiques ;
-- Ils permettent d'encapsuler des éléments de modélisation par l'intermédiaire
d'interfaces ;
-- Ils permettent de structurer un système en catégories ou soussystèmes ;
-- Ils servent de « briques » réutilisables dans la conception d'un logiciel.
Chaque package doit avoir un nom différent de celui des autres packages et peut
être composé d'autres éléments, y compris d'autres packages. Les éléments
contenus sont en fait « possédés » (au sens UML du terme), ce qui signifie que la
destruction d'un package implique la destruction de tous ses éléments.

L'importation permet aux éléments d'un package d'accéder aux éléments d'un
autre package. Cette relation est à sens unique et est représentée par une relation
de dépendance associée à un stéréotype « import ».

Représentation graphique d’un package

6/27
I.1. 2 Les classes
Représentation d'un ensemble d'éléments partageant les mêmes attributs, les
mêmes opérations, les mêmes relations et les mêmes sémantiques.
En programmation orientée objet, une classe définit une abstraction, un type
abstrait qui permettra d'instancier des objets. (Cf. cours POO licence Miage)

Graphiquement, une classe décrite en UML peut être plus ou moins précise :

Représentation graphique de classe

Exemple de classe

Les classes abstraites

Classe abstraite: classe ne pouvant pas être instanciée directement. Une telle
classe sert de spécification pour des objets instances de ses sousclasses.

Représentation graphique d'une classe abstraite

Les interfaces

Interface: décrit un contrat d'une classe ou d'un composant sans en imposer

l’implémentation.
Une interface ne décrit aucune structure ni aucune implémentation. Elle ne peut
donc pas contenir d'attributs, ni de méthodes fournies sous la forme d'une
implémentation.

Représentation graphique d'une interface

7/27
I.1. 3 Les relations entre classes

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

Les extrémités d’une association sont appelées rôles et peuvent porter un nom.
Le rôle décrit comment une classe voit une autre classe au travers d’une
association.

Les associations peuvent être nommées en utilisant une forme verbale. On peut
également préciser le sens de lecture par le biais d’un petit triangle dirigé vers la
classe désignée par la forme verbale.

On appelle arité d’une association le nombre de classes qui participent à

l’association.

Il arrive en effet que l’information que l’on veut représenter nécessite la mise en
relation de plus de deux classes. Ces associations n-aires peuvent se
représenter au moyen d’un losange sur lequel arrivent les différents brins de
l’association.

Multiplicité des associations

Chaque rôle peut porter une multiplicité montrant combien d’objets de la classe
considérée (celle qui joue ce rôle) peuvent être liés à une instance de l’autre classe
par l’association. La multiplicité est représentée sous la forme d’un couple de
cardinalités.

8/27
 1..1 noté 1 Un et un seul
0..1 Zéro ou un
0..* noté * De Zéro à n
1..* De un à n
n..m De n à m

Exemple : Lecture de multiplicité

GARAGE
LOCATAIRE
1
1

1..* 1..*

louer
CONTRAT
BOX
1 0..1

1..* Autoriser

0..2 VEHICULE

Une description de ce diagramme de classe en explicitant en une phrase chacune

des multiplicités.

Un box peut être loué par au maximum un seul contrat ou peut rester non loué.
Un contrat concerne la location d'un seul box à la fois.
Un box peut être vide ou contenir au maximum 2 véhicule.
Un véhicule est autorisé à aller dans un box (au minimum) ou plus.
Un contrat ne concerne qu'un seul locataire.
Un locataire peut souscrire plusieurs contrat mais doit en avoir souscrit au moins
un.

b) Les classes associations :

Il 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 :

COMMANDE 1..* 1..* PRODUIT

LIG-COM LIVRAISON
9/27
Quantité
 1..* 1

Ici, NumCommande + RéfProduit → Quantité

Une classe association est une classe comme une autre qui peut entretenir des
relations avec d’autres classes

c) Agrégation

Une agrégation est un type particulier d’association. Elle traduit la volonté de

renforcer la dépendance entre les classes. C’est une association non symétrique
dans laquelle une des extrémités joue un rôle prédominant par rapport à l’autre
extrémité.

Les critères suivants impliquent une agrégation :

- une classe fait partie d’une autre classe,
- une action sur une classe implique une action sur une autre classe,
- les objets d’une classe sont subordonnés aux objets d’une autre
classe.

Attention : l’inverse n’est pas toujours vrai ; l’agrégation n’implique pas

nécessairement tous les critères ci-dessus.

1 1..*
GARAGE BOX

Un agrégat peut être multiple.

d) La composition
La composition est un cas particulier d’agrégation dans laquelle la vie des
composants est liée à celle de l’agrégat. Dans la composition, l’agrégat ne peut
être multiple. La composition se représente par un losange noir.

10/27
 C om m u n e

1 1 1

1 ..* 1..* 1 ..*

M a i ri e C o n s e i l M u n i ci pa l S e rvi ce

Une composition est une association contraignante : la suppression d’un objet

agrégat entraîne la suppression des objets agrégés.

e) Généralisation :
UML emploie le terme de généralisation pour désigner la relation de
classification entre un élément plus général et un élément plus spécifique. La
relation de généralisation signifie « est un » ou « est une sorte de ».

Instrument

+Nom Instrument : undefined

+Date fabrication : undefined

Instrument à cordes Instrument à vent

+Nombre de cordes : undefined +Nombre de pistons : undefined

La classe ‘Instrument’ est une classe générique, elle porte les attributs
communs à tous les instruments. La classe ‘Instrument à cordes’ est une classe
spécialisée qui porte les attributs spécifiques à ce type d’instrument.
Une classe spécialisée peut avoir des relations avec d’autres classes.

11/27
I.2 Les Cas d’utilisation (Uses cases)

I.2.1 Objectifs des cas d’utilisation

Les cas d’utilisation décrivent sous la forme d’actions et de réactions, le

comportement d’un système du point de vue d’un utilisateur. Les cas d’utilisation
servent à structurer les besoins des utilisateurs et les objectifs correspondants du
système.

Un cas d’utilisation est une manière spécifique d’utiliser un système.

C’est l’image d’une fonctionnalité du système, déclenchée en réponse à
la stimulation d’un acteur externe.

I.2.2 Éléments constitutifs des cas d’utilisation

Acteur : entité externe qui agit sur le système ; Le terme acteur ne

désigne pas seulement les utilisateurs humains mais également les
autres systèmes.

Cas d’utilisation : ensemble d’actions réalisées par le système en

réponse à une action d’un acteur.

les cas d’utilisation peuvent être structurés,

les cas d’utilisation peuvent être organisés en paquetages,

12/27
Exemple : Diagramme de cas d’utilisation d’un guichet automatique bancaire

guichet

Retirer de l'argent

Client de la banque
Déposer de l'argent

effectuer des virements entre comptes

Consulter solde compte

Employé de caisse

Ravitailler distributeur

Réparer le distributeur

Agent de maintenance

13/27
I.2.3 Les relations
UML prédéfinit 4 stéréotypes de liens dans un diagramme Use Case :

<<Association>> :
C'est la seule relation autorisée entre une instance d'acteur et une instance de use
case. Nous l'avions particularisée en Procède, Déclenche et Reçoit dans les pages
précédentes.
<<Extend>> :
C'est une relation entre 2 instances de Use Case telle que A extend B signifie que
le comportement d'un B peut être complété par le comportement d'un A.
Exemple : Choix_Fournisseur dans la figure précédente peut être complété en cas
d'urgence par une opération de vérification du délai de livraison.
La relation extend doit spécifier à la fois :
- la condition de l'extension (par exemple RuptureStock:=Vrai)
- le point d'extension, i.e. l'endroit où l'extension doit être faite dans le Use Case
général (par exemple immédiatement après TrouveFournisseursProduit et avant
TrouveMeilleurPrix).
<<Extend>> spécifie donc une possibilité, une option, contrairement à la suivante
:

<<Include>> :
C'est une relation entre 2 instances de Use Case telle que la réalisation de la
fonction de l'un nécessite la réalisation de la fonction de l'autre. Exemple :
Commande_Fournisseur a besoin de Choix_fournisseur dans la figure précédente.
L'endroit ou le case Choix s'insère dans Commande est spécifié par un point
d'extension (sans condition).

<<Generalize>> :
Exprime la relation d'héritage qui sera expliquée plus en détail à l'occasion du
diagramme de structure statique. Nous la nommerons aussi "sorte de" :
Commande_Fournisseur est une spécialisation d'un cas plus général Commande,
dont une autre sorte pourrait être Commande_Client. Contrairement aux
précédentes, il s'agit d'une relation entre 2 Use Case et non entre des instances de
ceux-ci.

14/27
Etapes de construction:

1. Les acteurs
2. Pour chaque acteur, recherche des cas d'utilisation,
3. Structuration des cas d'utilisation pour faire apparaître les
comportements partagés (relation d'inclusion), les cas particuliers
ou options (relation d'extension), les généralisations /
spécialisations.

Instance de Cas d’utilisation

Une instance de cas d’utilisation représente une réalisation particulière d'un Use Case. C’est
un chemin unique dans un Use case.

Une description explicite d’une instance de cas d’utilisation est appelée un scénario.
Le use case comprend au moins deux scénarios: -un ou tout se passe bien, et un autre ou il
y a problème.
Alternative.

scénario Normal

alternative
scénario primaire/scénario secondaire.

Il est préférable de commencer à décrire le déroulement normal, basique, c'est à dire la

séquence la plus commune: c'est le scénario primaire( nominal).

Ensuite, il devient possible d’ écrire des alternatives en utilisant des flots d'événements
alternatifs. Il est possible d'écrire également les alternatives comme des scénarios
secondaires.

Recherche des scénarios secondaires (altrenatifs)

Y a t'il quelques autres actions possibles à ce niveau du scénario ?

Y a t' il quelque chose qui pourrait mal fonctionner à ce niveau du scénario ?
Y 'a t'il quelques comportements qui pourraient arriver à ce moment du scénario ?

15/27
Documentation
Chaque acteur doit être nommé et avoir une description succincte en une ou deux phrases.
Chaque cas d'utilisation doit avoir un nom et une ou deux phrases descriptives.

Le use case complet:

Pré condition:
Ce qui doit arriver avant le cas d'utilisation.
Dans quel état doit être le système au début du use case.

Post Condition:
Ce qui doit être après le use Case.
Quel état doit être vrai à la fin du Use Case.

Flots d'événements.

Il existe plusieurs types de présentation possible: On peut par exemple décrire un Use Case
en utilisant du texte informel, ou encore des étapes numérotées, ou même pour le niveau
technique du pseudo-code.

C'est une série de déclarations montrant les différentes étapes du Use Case.
Possibilité d'introduire une alternative par If; ou une répétitive par For each.
Si l'alternative est complexe, il est possible d'utiliser while.

16/27
II LES DIAGRAMMES DYNAMIQUES

II.1 Le diagramme de séquence

Les diagrammes de séquences montrent la séquence des interactions entre objets

selon un point de vue temporel (chronologique). Ce diagramme permet de
représenter les scénarios d’un cas d’utilisation. Un scénario est une instance d’un
cas d’utilisation. Un message reçu par un objet déclenche l’exécution d’une
opération et renvoie un message qui correspond au résultat de l’opération.

Une ligne en pointillé indique la ligne de vie d'un objet. L'ordre d'envoi des
messages est donné par une position sur l'axe vertical. Il s'agit donc d'un
diagramme équivalent à un Graphe des Flux dans lequel on aurait précisé l'ordre
des messages.

Des notations complémentaires permettent d'exprimer :

- les contraintes temporelles précises en graduant l'axe vertical (pour dire par
exemple :"10 secondes plus tard")
- le mode de réalisation du diagramme : message synchrone ou asynchrone, délai
de transmission d'un message, message de création ou de destruction d'objet,
durée d'une activité d'objet, etc.

17/27
II.2 Le diagramme d’état/transition

État, transition, évènement

L’état d’un objet est défini à un instant T par l’ensemble des valeurs de ses
attributs
Le passage d’un état à un autre s’appelle la transition ; Cette transition peut être
conditionnée
Un évènement est un fait survenu qui déclenche une transition (signal, appel,
temporel… )

Formalisme et exemple

Actions et activités
Une action est une opération instantanée qui ne peut être interrompue ; elle est
associée à une transition.
Une activité est une opération d’une certaine duré e qui ne peut être interrompue
et elle est associée à un état d’un objet.

Exemple

Représenter le diagramme d’état/transition d’un objet « personnel » suivant les

évènements de gestion depuis le recrutement jusqu’à son départ. Après
recrutement, une personne est considérée en activité dès sa prise de fonction. Les
évènements à gérer son :
• Le congé s maladie
• La prise de congés
• La fin de carrière :
Nous retiendrons deux situations :La démission et La retraite

18/27
Diagramme d'état la classe « compte »

Demande EnCoursOuverture
ouverture
DO :CréerCompte

DemandeFermetu Créditeur
re
[solde > =0]
débitEffectué
DemandeRetrait(montant)
enTrainEtreFerm
enTrainDeDébiter
é Virement (montant)
DO : débiter [solde >=0]
DO :ouvrir
créditEffectué

DemandeRetrait(montant) enTrainDeCrédit
er
DO :créditer

Virement(montan
t)

Débiteur

[solde < 0] créditEffectué

19/27
II.3 Le diagramme de collaboration

Le diagramme de collaboration permet de mettre en évidence les interactions

entre les différents objets du système étudié, ainsi que les messages qu’ils
échangent entre eux.

A l’aide du diagramme de collaboration, nous illustrons donc l’interaction entre

objets en créant des liens entre ces objets et en associant des messages à ces
liens. Le nom d’un message doit évoquer l’intention de l’objet appelant lors de
l’interaction avec l’objet associé.

Les messages sont les seuls moyens de communication entre les objets.
Ils sont donc positionnés sur le lien entre deux objets.

- Un nom est associé au message pour faciliter son identification.

- La séquence permet de préciser l’ordre d’émission des
messages.
- Un message peut être complété par un ou plusieurs
arguments :le message 5 ChoixCompteMontant a pour argument le
compte et le montant choisis par le client.
- Certains messages peuvent solliciter un résultat. On peut
représenter ce cas par deux messages : le premier fait la demande,
le second apporte la réponse. Toutefois, lorsque le message en
retour est immédiatement attendu, pour simplifier les diagrammes
on peut les omettre.
- L’émission d’un message peut être soumise à une garde : .Le
contrôle doit être OK pour demander la liste des comptes d’un
client.

Le diagramme de collaboration va nous permettre de compléter le

modèle d’analyse commencé avec le diagramme de classe en ajoutant de
nouvelles classes. Dans une première version du diagramme de classe nous
nous sommes limités à l’études des classes entités. Nous allons voir à
l’aide du diagramme de collaboration qu’il est nécessaire d’avoir recours à
d’autres types de classes pour gérer les interactions entre objets du
système :

- Les classes frontières (ou interfaces) : servent à modéliser

les interactions entre le système et ses acteurs ;
-
- Les classes de contrôle : ces classes encapsulent souvent le
contrôle lié à un cas d’utilisation, ce qui implique qu’un objet de
contrôle est créé au démarrage d’une instance de cas
d’utilisation et prend fin à l’issue de ce scénario. Il y a
néanmoins des exceptions : lorsqu’un objet de contrôle
participe à la réalisation de plusieurs cas d’utilisation, lorsque
plusieurs objets de contrôle (issus de différentes classes de
contrôle) participent à la réalisation du cas d’utilisation, et enfin

20/27
 lorsqu’une réalisation de cas d’utilisation ne nécessite aucun
objet de contrôle.

Un diagramme de collaboration permet de décrire les

interactions entre objets intervenant dans la réalisation d’un
scénario d’un cas d’utilisation.

Le diagramme de collaboration peut être complété par du texte décrivant

de quelle façon les objets dialoguent pour effectuer le scénario du cas
d’utilisation. C’est une description de scénario un peu plus précise.

21/27
 Exemple : Utilisation d’un diagramme de collaboration pour décrire la réalisation du scénario « retrait
autorisé » du cas d’utilisation « retirer de l’argent »

IntGuichet/:IGuichetAccueil 2:DemanderAutorisation(Code)

Contrôleur1/:CAutorisation
1:Identifier(Code)
4:AutoriserCréation(ListeComptes) 3:[ContrôleOK]ObtenirListe()
5:ChoixCompteMontant(Compte,Montant)
IntChoixMontant/:IGuichetMontant
ComptesMartin/:Compte

M. Martin/:Client de la banque

6:DemanderRetrait(Compte, Montant)
CompteClient/:Compte

9:DélivrerArgent()
7:ValiderEtEffectuerRetrait()

Contrôleur2/:CRetrait Multi-objet

8:AutoriserRetrait(montant)
IntDistributeur/:Idistributeur
II.5 Diagramme d’activité

Le contexte : les objets

Nous reviendrons plus en détail sur le concept d'objet. Un objet se définit
par une structure (attributs porteurs de données), un comportement
(attributs porteurs d'opérations) et ses relations avec l'extérieur. En
première approximation on peut donc dire qu'un objet est un système (plus
ou moins complexe). Des objets de structure identique sont groupés dans
une classe.

Le niveau : la méthode
Un diagramme d'activités concerne le comportement d'un objet d'une
classe déterminée. Par exemple, la classe des commandes est notamment
décrite par l'opération "contrôler bon de commande".
Une méthode est l'implémentation d'une opération dans sa classe
propriétaire, par exemple la méthode "Commande :: controle" montre
comment se réalise l'opération qui consiste à contrôler le bon de
commande.

Le point de vue : interne

Un diagramme d'activités sera utilisé pour la description d'opérations
composées de suites d'actions élémentaires continues : le passage à d'une
action à sa suivante est fait automatiquement dès que l'action précédente
est terminée. (Par opposition, si le passage d'une action à une autre se fait
à cause de la survenance d'un événement externe, on utilisera plutôt une
représentation par Statecharts).
Un diagramme d'activités est donc utilisé pour des situations dans
lesquelles un fil d'exécution continu est contrôlable de l'intérieur de l'objet.
Ce n'est pas le cas de la méthode Commande :: contrôle qui doit avoir
recours à d'autres objets externes comme par exemple Client (pour obtenir
le solde du compte) ou Produit (pour savoir s'il existe).

Le principe : un découpage en étapes d'éxecution qui utilise les concepts

suivants :
Un état actif est une étape ou pas d'exécution de l'algorithme interne (avec
un début, au moins une transition de sortie et sans événements extérieurs à
cet état).

Une transition est le passage instantané et automatique à l'action suivante.

Une décision montre les conditions selon lesquelles, à la sortie d'une action,
l'action suivante à exécuter (parmi plusieurs possibles) est déterminée.

Un état actif peut invoquer un autre graphe d'activité complet. On dit qu'il
entre alors dans un sous-état actif dont il ne peut sortir qu'à la terminaison
du graphe invoqué. Un graphe d'activité donné peut être invoqué par
plusieurs sous-états actifs.

23
Soit le cas d'une activité de Réception :

Mr Yao est chargé du magasin. Lors des livraisons, il trie les articles selon
qu'il s'agit de choses courantes (elles sont rangées dans des rayons par
familles d'articles) ou selon qu'il s'agit d'articles spécifiques à une affaire
(rangés dans un casier spécial au nom du client).

Supposons qu'une classe Article a été définie comme possédant notamment

une méthode Réceptionner.

Article :: Réceptionner

Remarques :
Une transition est automatique : l'article est déballé dès qu'il est fini de
décharger, il est rangé dès qu'il est fini de déballer, et le stock est mis à jour
dès que l'article est rangé.

Les conditions (quelquefois appelées gardes) de la décision sont strictement

alternatives, exhaustives et internes : par exemple, il n'y a pas
d'événement externe pour informer sur courant / spécifique, il n'y a pas
d'autres cas possibles et ils sont exclusifs l'un de l'autre.

On retrouve 3 figures habituelles des algorithmes : la séquence, l'alternative

et le sous-programme (sous-états actifs).

L'exemple ne montre pas d'itération mais rien ne l'interdit. Attention

cependant : une itération ne peut concerner qu'une action ou un groupe
d'actions à l'intérieur du diagramme d'activités. Si l'on voulait indiquer que
l'activité elle-même se répète pour plusieurs articles livrés ensemble par
exemple, ceci se ferait par application de la même activité (méthode) à
plusieurs articles (objets, instances de classe) différents.

Des décisions successives peuvent s'enchaîner.

24
Les extensions UML pour le "Business Modeling" :
(NB : nous préférons garder l'expression anglaise des concepts plutôt que
traduire, afin de marquer leur caractère de définitions au sein de la notation
UML)

Worker : une abstraction d'une personne qui agit dans le système. Elle
interagit avec d'autres personnes et manipule des entités. Elle se subdivise
en :

Case worker : une personne qui interagit avec des partenaires extérieurs au
système : par exemple le Chef d'entreprise lorsqu'il négocie les devis avec
les clients.

Internal worker : une personne qui n'interagit avec d'autres qu'à l'intérieur
du système. C'est le cas de notre secrétaire pour l'exemple ci-dessus.

Entity : un objet passif qui n'a pas d'initiative propre d'interaction. L'entité
sert de support au partage des activités entre plusieurs workers. Par
exemple la commande est une entité créée par la secrétaire et visée par le
chef d'entreprise.

Ces concepts peuvent être désignés par des icônes :

Les symboles << >> ont une signification particulière dans UML : ils notent
des stéréotypes.

Les couloirs d'activités

Un couloir d'activité (swimlane) est une unité organisationnelle montrant la
responsabilité des activités au sein d'une classe. Les interactions peuvent
être montrées dans le diagramme par les échanges entre couloirs :

25
III Déploiement

26
IV La demarche

La démarche.
U.M.L ne donne aucune démarche « normalisée »

La plus proche d’U.M.L reste objectory de Y.Jacobson, qui a donné lieu à la création d’un
PROCESSUS UNIFIE.

La démarche est pilotée par les USES CASES, elle est centrée sur la création le plus
tôt possible de l’architecture du logiciel, et le processus est incrémental au début du
processus et Itératif dès que c’est possible.

Faire les cas d’utilisation.

Rechercher les classes et associations.
-Analyse de texte
-Par Use case.
Compléter par des diagrammes de séquence sur les uses cases.
Faire les Diagrammes de transition d’états.
En déduire les premières opérations.

Faire la conception du système.

-Diagramme de déploiement.
Faire la conception des objets.
Scénario
Diagramme d’objets.
Compléter le diagramme de classes.

Le Processus est non linéaire. Il s’agit de faire les activités classique du génie logiciel, à
savoir REQUIREMENTS, ANALYSE , CONCEPTION , IMPLEMENTATION, TEST de
nombreuses fois au cours du cycle qui va comprendre des phases de lancement, puis de
l’élaboration, enfin de construction.

Naturellement chaque type d’activité sera privilégié et forte à son ordre. Par exemple, les
requirements seront beaucoup plus important en phase de lancement qu’en phase de
conception. Mais on ne peut pas nier que cela puisse arriver. En effet, certaines exigences
peuvent apparaître au moment de la construction du système.

27