Académique Documents
Professionnel Documents
Culture Documents
3 UML et mthododologie 33
3.1 Des besoins au code avec UML : une mthode minimale . . . . . . . . . . . . . . 33
3.2 Rational Unied Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 eXtreme programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Bibliographie OCL
UML 2.0 Object Constraint Language (OCL)
OMG (Object Management Group)
www.uml.org (2004)
Cours de Jean-Marie Favre, IMAG
http://megaplanet.org/jean-marie-favre
Matriel et logiciel
Systmes informatiques :
80 % de logiciel ;
20 % de matriel.
Depuis quelques annes, la fabrication du matriel est assure par quelques fabricants
seulement.
Le matriel est relativement able.
Le march est standardis.
La crise du logiciel
tude sur 8 380 projets (Standish Group, 1995) :
Succs : 16 % ;
Problmatique : 53 % (budget ou dlais non respects, dfaut de fonctionnalits) ;
chec : 31 % (abandonn).
Le taux de succs dcrot avec la taille des projets et la taille des entreprises.
Gnie Logiciel (Software Engineering) :
Comment faire des logiciels de qualit ?
Qu'attend-on d'un logiciel ? Quels sont les critres de qualit ?
Introduction UML 2 1 / 96
1 INTRODUCTION LA MODLISATION ORIENTE OBJET
Performance
Portabilit
Rutilisabilit
Facilit de maintenance
Un logiciel ne s'use pas pourtant, la maintenance absorbe une trs grosse partie des
eorts de dveloppement.
Poids de la maintenance
Cycle de vie
Etapes du dveloppement
tude de faisabilit
Spcication
Dterminer les fonctionnalits du logiciel.
Conception
Dterminer la faon dont dont le logiciel fournit les direntes fonctionnalits recherches.
Codage
Tests
Essayer le logiciel sur des donnes d'exemple pour s'assurer qu'il fonctionne correctement.
Maintenance
Modlisation
2 / 96 Introduction UML 2
1 INTRODUCTION LA MODLISATION ORIENTE OBJET
Modle
Un modle est une reprsentation abstraite de la ralit qui exclut certains dtails du monde
rel.
Il permet de rduire la complexit d'un phnomne en liminant les dtails qui n'inu-
encent pas son comportement de manire signicative.
Il rete ce que le concepteur croit important pour la comprhension et la prdiction
du phnomne modlis, les limites du phnomne modlis dpendent des objectifs du
modle.
Langages de modlisation
Un langage de modlisation doit dnir :
La smantique des concepts ;
Une notation pour la reprsentation de concepts ;
Des rgles de construction et d'utilisation des concepts.
Des langages dirents niveaux de formalisation
Langages formels (Z,B,VDM) : le plus souvent mathmatiques, au grand pouvoir
d'expression et permettant des preuves formelles sur les spcications ;
Langages semi-formels (MERISE, UML...) : le plus souvent graphiques, au pouvoir
d'expression moindre mais plus faciles d'emploi.
L'industrie du logiciel dispose de nombreux langages de modlisation :
Adapts aux systmes procduraux (MERISE...) ;
Adapts aux systmes temps rel (ROOM, SADT...) ;
Adapts aux systmes objets (OMT, Booch, UML...).
Le rle des outils (Ateliers Gnie Logiciel) est primordial pour l'utilisabilit en pratique
des langages de modlisation.
Introduction UML 2 3 / 96
1 INTRODUCTION LA MODLISATION ORIENTE OBJET
UML v2.0 date de 2005. Il s'agit d'une version majeure apportant des innovations radicales
et tendant largement le champ d'application d'UML.
4 / 96 Introduction UML 2
2 MODLISATION OBJET LMENTAIRE AVEC UML
Avant de dvelopper un systme, il faut savoir prcisment QUOI il devra servir, cad quels
besoins il devra rpondre.
Modliser les besoins permet de :
Faire l'inventaire des fonctionnalits attendues ;
Organiser les besoins entre eux, de manire faire apparatre des relations (rutilsations
possibles, ...).
Avec UML, on modlise les besoins au moyen de diagrammes de cas d'utilsation.
Cas d'utilisation
Un cas d'utilisation est un service rendu l'utilisateur, il implique des sries d'actions plus
lmentaires.
Un acteurs est une entit extrieure au systme modlis, et qui interagit directement avec
lui.
Un cas d'utilisation est l'expression d'un service ralis de bout en bout, avec un dclenche-
ment, un droulement et une n, pour l'acteur qui l'initie.
Introduction UML 2 5 / 96
2 MODLISATION OBJET LMENTAIRE AVEC UML
2.1 Diagrammes de cas d'utilisation
Gnralisation : le cas A est une gnralisation du cas du cas B (B est une sorte de A).
Attention
Le sens des ches indique le dpendance, pas le sens de la relation d'inclusion.
6 / 96 Introduction UML 2
2.1 Diagrammes de cas d'utilisation
2 MODLISATION OBJET LMENTAIRE AVEC UML
Gnralisation
Introduction UML 2 7 / 96
2 MODLISATION OBJET LMENTAIRE AVEC UML
2.1 Diagrammes de cas d'utilisation
Les acteurs secondaires sont sollicits par le systme alors que le plus souvent, les acteurs
principaux ont l'initiative des interactions.
Le plus souvent, les acteurs secondaires sont d'autres ystmes informatiques avec lesquels
le systme dvelopp est inter-connect.
Trouver le bon niveau de dtail pour les cas d'utilisation est un problme dicile qui ncessite
de l'exprience.
8 / 96 Introduction UML 2
2.1 Diagrammes de cas d'utilisation
2 MODLISATION OBJET LMENTAIRE AVEC UML
Chaque cas d'utilisation doit tre document pour qu'il n'y ait aucune ambigut concer-
nant son droulement et ce qu'il recouvre prcisment.
Description textuelle
Identication :
Nom du cas : Payer CB
Objectif : Dtailler les tapes permettant client de payer par carte bancaire
Acteurs : Client, Banque (secondaire)
Date : 18/09
Responsables : Toto
Version : 1.0
Squencements :
Le cas d'utilisation commence lorsqu'un client demande le paiement par carte bancaire
Pr-conditions
Le client a valid sa commande
Enchanement nominal
1. Le client saisit les informations de sa carte bancaire
2. Le systme vrie que le numro de CB est correct
3. Le systme vrie la carte auprs du systme bancaire
4. Le systme demande au systme bancaire de dbiter le client
5. Le systme notie le client du bon droulement de la transaction
Enchanements alternatifs
1. En (2) : si le numro est incorrect, le client est averti de l'erreur, et invit recom-
mencer
2. En (3) : si les informations sont errones, elles sont re-demandes au client
Post-conditions
La commande est valide
Le compte de l'entreprise est crdit
Rubriques optionnelles
Contraintes non fonctionnelles :
Fiabilit : les accs doivent tre scuriss
Condentialit : les informations concernant le client ne doivent pas tre divulgus
Contraintes lies l'interface homme-machine :
Toujours demander la validation des oprations bancaires
Introduction UML 2 9 / 96
2.2 Diagrammes de classes 2 MODLISATION OBJET LMENTAIRE AVEC UML
Concepts et instances
Une instance est la concrtisation d'un concept abstrait.
Concept : Stylo
Instance : le stylo que vous utilisez ce moment prcis est une instance du concept stylo :
il a sa propre forme, sa propre couleur, son propre niveau d'usure, etc.
Un objet est une instance d'une classe
Classe : Vido
Objets : Pink Floyd (Live Pompey), 2001 Odysse de l'Espace etc.
Une classe spcie la manire dont tous les objets de mme type seront dcrits (dsig-
nation, label, auteur, etc).
Un lien est une instance d'association.
Association : Concept avis d'internaute qui lie commentaire et article
Lien : instance [Jean avec son avis ngatif], [Paul avec son avis positif]
Classes et objets
Une classe est la description d'un ensemble d'objets ayant une smantique, des attributs,
des mthodes et des relations en commun. Elle spcie l'ensemble des caractristiques qui
composent des objets de mme type.
Une classe est compose d'un nom, d'attributs et d'oprations.
Selon l'avancement de la modlisation, ces informations ne sont pas forcement toutes
connues.
Introduction UML 2 11 / 96
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.2 Diagrammes de classes
Une opration est dnie par son ainsi que par les types de ses paramtres et le type de sa valeur
de retour.
La syntaxe de la dclaration d'une opration est la suivante :
modifAcces nomOperation ( parametres ): ClasseRetour
La syntaxe de la liste des paramtres est la suivante :
nomClasse1 nomParam1 , ... , nomClasseN nomParamN
12 / 96 Introduction UML 2
2.2 Diagrammes de classes 2 MODLISATION OBJET LMENTAIRE AVEC UML
Mthodes et Oprations
Une opration est la spcication d'une mthode (sa signature) indpendamment de son
implantation.
UML 2 autorise galement la dnition des oprations dans n'importe quel langage
donn.
Exemples de mthodes pour l'opration fact(n:int):int :
{ // implementation iterative
int resultat =1~;
for ( int i = n ~; i >0~; i - -)
resultat *= i ~;
return resultat ~;
}
{ // implementation recursive
if ( n ==0 || n ==1)
return 1~;
return ( n * fact (n -1))~;
}
Association
Une association est une relation structurelle entre objets.
Une association est souvent utilise pour reprsenter les liens posibles entre objets de
classes donnes.
Elle est reprsente par un trait entre classes.
Introduction UML 2 13 / 96
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.2 Diagrammes de classes
Implantation
public class Adresse {...}
Implantation
public class Client {
Adresse facturation ;
public void setAdresse ( Adresse uneAdresse ){
if ( uneAdresse != null ){
this . facturation = uneAdresse ;
facturation . client = this ; // correspondance
}
}
}
public class Adresse {
Client client ;
public void setClient ( Client unClient ){
this . client = client ;
client . facturation = this ; // correspondance
}
}
14 / 96 Introduction UML 2
2.2 Diagrammes de classes 2 MODLISATION OBJET LMENTAIRE AVEC UML
Implantation
public class Commentaire {...}
Associations rexives
L'association la plus utilise est l'association binaire (reliant deux classs).
Parfois, les deux extrmits de l'association pointent vers le mme classeur. Dans ce cas,
l'association est dite rexive .
Classe-association
Une association peut tre rane et avoir ses propres attributs, qui ne sont disponibles
dans aucune des classes qu'elle lie.
Comme, dans le modle objet, seules les classes peuvent avoir des attributs, cette associa-
tion devient alors une classe appele classe-association .
Associations n-aires
Une association n-aire lie plus de deux classes.
Notation avec un losange central pouvant ventuellement accueillir une classe-association.
La multiplicit de chaque classe s'applique une instance du losange.
Introduction UML 2 15 / 96
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.2 Diagrammes de classes
Les associations n-aires sont peu frquentes et concernent surtout les cas o les multplicits sont
toutes * . Dans la plupart des cas, on utilisera plus avantageusement des classes-association
ou plusieurs relations binaires.
Une agrgation dnote une relation d'un ensemble ses parties. L'ensemble est l'agrgat
et la partie l'agrg.
16 / 96 Introduction UML 2
2.2 Diagrammes de classes 2 MODLISATION OBJET LMENTAIRE AVEC UML
Composition et agrgation
Ds lors que l'on a une relation du tout sa partie, on a une relation d'agrgation ou de
composition.
Si on rpond par l'armative ces deux questions, on doit utiliser une composition.
Relation d'hritage
L'hritage une relation de spcialisation/gnralisation.
Les lments spcialiss hritent de la structure et du comportement des lments plus
gnraux (attributs et oprations)
Exemple : Par hritage d'Article, un livre a d'oce un prix, une dsignation et une
opration acheter(), sans qu'il soit ncessaire de le prciser
Attention
Les extends Java n'a rien voir avec le extend UML vu pour les cas d'utilisation
Introduction UML 2 17 / 96
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.2 Diagrammes de classes
Encapsulation
L'encapsulation est un principe de conception consistant protger le coeur d'un systme
des accs intempestifs venant de l'extrieur.
En UML, utilisation de modicateurs d'accs sur les attributs ou les classes :
Public ou + : proprit ou classe visible partout
Protected ou # . proprit ou classe visible dans la classe et par tous ses descendants.
Private ou - : proprit ou classe visible uniquement dans la classe
Package, ou : proprit ou classe visible uniquement dans le paquetage
Il n'y a pas de visibilit par dfaut .
Package (paquetage)
Les packages contiennent des lments de modle de haut niveau, comme des classes, des dia-
grammes de cas d'utilisation ou d'autres packages. On organise les lments modliss en packages
et sous-packages.
Exemple d'encapsulation
18 / 96 Introduction UML 2
2.2 Diagrammes de classes 2 MODLISATION OBJET LMENTAIRE AVEC UML
Terminologie de l'hritage
Une classe enfant peut rednir (mme signature) une ou plusieurs mthodes de la classe
parent.
Sauf indications contraires, un objet utilise les oprations les plus spcialises dans la
hirarchie des classes.
La surcharge d'oprations (mme nom, mais signatures des oprations direntes) est
possible dans toutes les classes.
Toutes les associations de la classe parent s'appliquent, par dfaut, aux classes drives
(classes enfant).
Principe de substitution : une instance d'une classe peut tre utilise partout o une in-
stance de sa classe parent est attendue.
Par exemple, toute opration acceptant un objet d'une classe Animal doit accepter tout
objet de la classe Chat (l'inverse n'est pas toujours vrai).
Classes abstraites
Une mthode est dite abstraite lorsqu'on connat son entte mais pas la manire dont elle
peut tre ralise.
Hritage multiple
Une classe peut avoir plusieurs classes parents. On parle alors d'hritage multiple.
Le langage C++ est un des langages objet permettant son implantation eective.
Java ne le permet pas.
Interface
Le rle d'une interface est de regrouper un ensemble d'oprations assurant un service
cohrent oert par un classeur et une classe en particulier.
Une interface est dnie comme une classe, avec les mmes compartiments. On ajoute le
strotype interface avant le nom de l'interface.
On utilise une relation de type ralisation entre une interface et une classe qui l'implmente.
Les classes implmentant une interface doivent implmenter toutes les oprations dcrites
dans l'interface
Introduction UML 2 19 / 96
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.2 Diagrammes de classes
Exemple d'interface
Elments drivs
Les attributs drivs peuvent tre calculs partir d'autres attributs et des formules de
calcul.
Les attributs drivs sont symboliss par l'ajout d'un / devant leur nom.
Lors de la conception, un attribut driv peut tre utilis comme marqueur jusqu' ce
que vous puissiez dterminer les rgles lui appliquer.
Une association drive est conditionne ou peut tre dduite partir d'autres autres
associations. On utilise galement le symbole / .
Attributs de classe
Par dfaut, les valeurs des attributs dnis dans une classe dirent d'un objet un autre.
Parfois, il est ncessaire de dnir un attribut de classe qui garde une valeur unique et
partage par toutes les instances.
Graphiquement, un attribut de classe est soulign
Oprations de classe
Semblable aux attributs de classe
Une opration de classe est une proprit de la classe, et non de ses instances.
Elle n'a pas accs aux attributs des objets de la classe.
20 / 96 Introduction UML 2
2.2 Diagrammes de classes 2 MODLISATION OBJET LMENTAIRE AVEC UML
Classe paramtre
Pour dnir une classe gnrique et paramtrable en fonction de valeurs et/ou de types :
Dnition d'une classe paramtre par des lments spcis dans un rectangle en pointil-
ls ;
Utilisation d'une dpendance strotype bind pour dnir des classes en fonction de
la classe paramtre.
Java5 : gnricit
C++ : templates
Introduction UML 2 21 / 96
2.3 Diagrammes d'objets 2 MODLISATION OBJET LMENTAIRE AVEC UML
Le diagramme de classes modlise des rgles etle diagramme d'objets modlise des faits.
Introduction UML 2 23 / 96
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.3 Diagrammes d'objets
Liens
Un lien est une instance d'une association.
Un lien se reprsente comme une association mais s'il a un nom, il est soulign.
Attention
Naturellement, on ne reprsente pas les multiplicits qui n'ont aucun sens au niveau des
objets.
24 / 96 Introduction UML 2
2.4 Diagrammes de squences 2 MODLISATION OBJET LMENTAIRE AVEC UML
Exemple d'interaction
Cas d'utilisation :
Ligne de vie
Une ligne de vie reprsente un participant une interaction (objet ou acteur).
nomLigneDeVie [ selecteur ]: nomClasseOuActeur
Dans le cas d'une collection de participants, un slecteur permet de choisir un objet parmi
n (par exemple objets[2]).
Messages
Les principales informations contenues dans un diagramme de squence sont les messages
changs entre les lignes de vie, prsents dans un ordre chronologique.
Introduction UML 2 25 / 96
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.4 Diagrammes de squences
Un message dnit une communication particulire entre des lignes de vie (objets ou
acteurs).
Plusieurs types de messages existent, dont les plus courants :
l'envoi d'un signal ;
l'invocation d'une opration (appel de mthode) ;
la cration ou la destruction d'un objet.
La rception des messages provoque une priode d'activit (rectangle vertical sur la ligne de
vie) marquant le traitement du message (spcication d'excution dans le cas d'un appel
de mthode).
On peut associer aux messages d'appel de mthode un message de retour (en pointills)
marquant la reprise du contrle par l'objet metteur du message synchrone.
Un message asynchrone n'est pas bloquant pour l'expditeur. Le message envoy peut
tre pris en compte par le rcepteur tout moment ou ignor.
Typiquement : envoi de signal (voir strotype de classe signal ).
Envoyer un message et attendre la rponse pour poursuivre son activit revient invoquer
une mthode et attendre le retour pour poursuivre ses traitements.
26 / 96 Introduction UML 2
2.4 Diagrammes de squences 2 MODLISATION OBJET LMENTAIRE AVEC UML
class B {
C c;
op1 ( p : Type ){
c . op2 ( p );
c . op3 ();
}
}
class C {
op2 ( p : Type ){
...
}
op3 (){
...
}
}
Les signaux sont des objets dont la classe est strotype signal et dont les attributs
(porteurs d'information) correspondent aux paramtres du message.
La destruction d'un objet est matrialise par une croix qui marque la n de la ligne de
vie de l'objet.
Introduction UML 2 27 / 96
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.4 Diagrammes de squences
La che part d'une ligne de vie mais arrive sur un cercle indpendant marquant la
mconnaissance du destinataire.
Exemple : broadcast.
Un message trouv est tel que l'vnement de rception est connu, mais pas l'vnement
d'mission.
Messages de retour
Le rcepteur d'un message synchrone rend la main l'metteur du message en lui envoyant
un message de retour
Les messages de retour sont optionnels : la n de la priode d'activit marque galement
la n de l'excution d'une mthode.
Ils sont utiliss pour spcier le rsultat de la mthode invoque.
Le retour des messages asynchrones s'eectue par l'envoi de nouveaux messages asynchrones.
28 / 96 Introduction UML 2
2.4 Diagrammes de squences 2 MODLISATION OBJET LMENTAIRE AVEC UML
ou
nomParam : valeurParam
Fragment combin
Un fragment combin permet de dcomposer une interaction complexe en fragments su-
isamment simples pour tre compris.
Recombiner les fragments restitue la complexit.
Syntaxe complte avec UML 2 : reprsentation complte de processus avec un langage
simple (ex : processus parallles).
Un fragment combin se reprsente de la mme faon qu'une interaction. Il est reprsent
un rectangle dont le coin suprieur gauche contient un pentagone.
Dans le pentagone gure le type de la combinaison (appel oprateur d'interaction ).
Oprateur de boucle
Introduction UML 2 29 / 96
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.4 Diagrammes de squences
La boucle est rpte au moins minNbItrations fois avant qu'une ventuelle condition
boolenne ne soit teste (la condition est place entre crochets dans le fragment)
Tant que la condition est vraie, la boucle continue, au plus maxNbItrations fois.
Notations :
loop(valeur) est quivalent loop(valeur,valeur).
loop est quivalent loop(0,*), o * signie illimit .
Oprateur parallle
L'oprateur par permet d'envoyer des messages en parallle.
Ce qui se passe de part et d'autre de la ligne pointille est indpendant.
30 / 96 Introduction UML 2
2.4 Diagrammes de squences 2 MODLISATION OBJET LMENTAIRE AVEC UML
Les inclusions et les extensions sont des cas typiques d'utilisation de la rutilisation par
rfrencement
Introduction UML 2 31 / 96
3 UML ET MTHODODOLOGIE
3 UML et mthododologie
3.1 Des besoins au code avec UML : une mthode minimale
Pourquoi une mthode ?
Processus de dveloppement
Ensemble d'tapes partiellement ordonnes, qui concourent l'obtention d'un systme logiciel
ou l'volution d'un systme existant.
Objectif : produire des logiciels
De qualit (qui rpondent aux besoins de leurs utilisateurs)
Dans des temps et des cots prvisibles
A chaque tape, on produit :
Des modles ;
De la documentation ;
Du code.
Mthode minimale
Objectif
Introduction UML 2 33 / 96
3 UML ET MTHODODOLOGIE
3.1 Des besoins au code avec UML : une mthode minimale
Cas d'utilsation
Comment dnir les besoins ?
1. Identier les limites du systme ;
2. Identier les acteurs ;
3. Identier les cas d'utilisation ;
4. Structurer les cas d'utilisation en packages ;
5. Ajouter les relations entre cas d'utilisation ;
6. Classer les cas d'utilisation par ordre d'importance.
Exemple de classement
Cas d'utilisation Priorit Risque
Ajouter article au panier Haute Moyen
Changer prix Article Moyen Moyen
Rechercher par mots-cls Bas Moyen
... etc ... ... etc ... ... etc ...
Modle du domaine
Le modle du domaine est constitu d'un ensemble de classes dans lesquelles aucune opration
n'est dnie.
Le modle du domaine dcrit les concepts invariants du domaine d'application.
Exemple : Pour un logiciel de gestions de factures, on aura des classes comme Produit,
Client, Facture...
Peu importe que le logiciel soit en ligne ou non.
Peu importent les technologies employes.
34 / 96 Introduction UML 2
3.1 Des besoins au code avec UML : une mthode minimale
3 UML ET MTHODODOLOGIE
Etapes de la dmarche :
1. Identier les concepts du domaine ;
2. Ajouter les associations et les attributs ;
3. Gnraliser les concepts ;
4. Structurer en packages : structuration selon les principes de cohrence et d'indpen-
dance.
Les concepts du domaine peuvent tre identis directement partir de la connaissance
du domaine ou par interview des experts mtier.
Structuration en packages
Squences systme
Les squences systme formalisent les descriptions textuelles des cas d'utilisation, en utilisant
des diagrammes de squence.
Construire les Diagrammes de Squences Systme implique souvent la mise jour des cas
d'utilisation la lumire des rexions que nous inspirent la production des DSS.
Les DSS permettent de spcier les oprations systme.
Le systme est considr comme un tout :
On s'intresse ses interactions avec les acteurs ;
On utilise une classe Systme qui part les acteurs donnera lieu la seule ligne
de vie des DSS.
Introduction UML 2 35 / 96
3 UML ET MTHODODOLOGIE
3.1 Des besoins au code avec UML : une mthode minimale
Oprations systme
Les oprations systme sont des oprations qui devront tre ralises par l'une ou l'autre
des classes du systme.
Elles correspondent tous les messages qui viennent des acteurs vers le systme dans les
dirents DSS.
Classes participantes
Pour chaque cas d'utilisation, on dnit les classes d'analyse mises en oeuvre pour sa
ralisation eective.
Typologie des classes d'analyse :
Les classes mtier (ou entits) reprsentent les objets mtier. Elles correspondent aux
classes du modle du domaine.
Les classes de dialogue sont celles qui permettent les interactions entre les acteurs et
l'application.
Les classes de contrle permettent d'abstraire les fonctionnalits du systme :
Elles font le lien entre les classes dialogue et les classes mtier.
Elles permettent de contrler la cinmatique de l'application, cad l'ordre dans lequel
les choses doivent se drouler.
36 / 96 Introduction UML 2
3.1 Des besoins au code avec UML : une mthode minimale
3 UML ET MTHODODOLOGIE
Le Diagramme des Classes Participantes est un diagramme de classes dcrivant toutes les classes
d'analyse.
Le DCP est une version enrichie du modle du domaine, auquel on adjoint les classes d'interaction
et de contrle.
A ce point du dveloppement, seules les classes de dialogue ont des oprations, qui corre-
spondent aux oprations systme, c'est dire aux messages changs avec les acteurs, que
seules les classes de dialogues sont habilites intercepter ou mettre.
Architecture en couches :
Les dialogues ne peuvent tre relis qu'aux contrles ou d'autres dialogues (en gnral,
associations unidirectionnelles).
Les classes mtier ne peuvent tre relies qu'aux contrles ou d'autres classes mtier.
Les contrles peuvent tre associs tous les types de classes.
Diagrammes d'interaction
Dans les diagrammes de squence systme, le systme tait vu comme une bote noire (ligne
de vie Systme ).
On sait maintenant de objets est compos le systme (diag. de classes participantes).
Le systme n'est plus une bote noire.
En plus des interactions du systme avec l'extrieur, les Diagrammes d'Interaction mon-
trent les interactions internes provoques.
Les DSS sont repris mais l'objet Systme est clat pour donner le dtail des classes
d'analyse :
Les lignes de vie correspondent aux classes participantes.
Introduction UML 2 37 / 96
3 UML ET MTHODODOLOGIE
3.1 Des besoins au code avec UML : une mthode minimale
38 / 96 Introduction UML 2
3.2 Rational Unied Process 3 UML ET MTHODODOLOGIE
Introduction UML 2 39 / 96
3 UML ET MTHODODOLOGIE 3.2 Rational Unied Process
On peut voir le dveloppement d'un logiciel comme un processus graduel d'limination de risques.
RUP est une dmarche de dveloppement qui est souvent utilis conjointement au langage UML.
Rational Unied Process est
Pilot par les cas d'utilisation ;
Centr sur l'architecture ;
Itratif et incrmental.
40 / 96 Introduction UML 2
3.2 Rational Unied Process 3 UML ET MTHODODOLOGIE
Vues du systme
Vue cas d'utilisation :
Description du systme comme un ensemble de transactions du point de vue de l'util-
isateur.
Vue logique :
Cre lors de la phase d'laboration et rane lors de la phase de construction ;
Utilisation de diagrammes de classes, de squences...
Vue composants :
Description de l'architecture logicielle.
Vue dploiement :
Description de l'architecture matrielle du systme.
Vue implmentation :
Description des algorithmes, code source.
Introduction UML 2 41 / 96
3 UML ET MTHODODOLOGIE 3.2 Rational Unied Process
42 / 96 Introduction UML 2
3.2 Rational Unied Process 3 UML ET MTHODODOLOGIE
Introduction UML 2 43 / 96
3 UML ET MTHODODOLOGIE 3.2 Rational Unied Process
Les activits sont des tapes dans le dveloppement d'un logiciel, mais un niveau de
granularit beaucoup plus n que les phases.
Chaque activit est rpte autant de fois qu'il y a d'itrations.
Modlisation mtier
Objectif : Mieux comprendre la structure et la dynamique de l'organisation :
Proposer la meilleure solution dans le contexte de l'organisation cliente ;
Ralisation d'un glossaire des termes mtiers ;
Cartographie des processus mtier de l'organisation cliente.
Activit coteuse mais qui permet d'acclrer la comprhension d'un problme.
Analyse
Objectif : Transformer les besoins utilisateurs en modles UML.
Analyse objet servant de base une rexion sur les mcanismes internes du systme.
44 / 96 Introduction UML 2
3.2 Rational Unied Process 3 UML ET MTHODODOLOGIE
Principaux livrables :
Modles d'analyse, neutre vis vis d'une technologie ;
Livre une spcication plus prcise des besoins.
Peut envisag comme une premire bauche du modle de conception.
Conception
Objectif : Modliser comment le systme va fonctionner :
Exigences non fonctionnelles ;
Choix technologiques.
Le systme est analys et on produit :
Une proposition d'architecture ;
Un dcoupage en composants.
Impmentation
Objectif : Implmenter le systme par composants.
Le systme est dvelopp par morceaux dpendant les uns des autres.
Optimisation de l'utilisation des ressources selon leurs expertises.
Les dcoupages fonctionnel et en couches sont indispensable pour cette activit.
Il est tout fait envisageable de retoucher les modles d'analyse et de conception ce
stade.
Test
Objectif : Vrier des rsultats de l'implmentation en testant la construction :
Tests unitaires : tests composants par composants ;
Tests d'intgration : tests de l'interaction de composants pralablement tests individu-
ellement.
Mthode :
Planication pour chaque itration ;
Implmentation des tests en crant des cas de tests ;
Excuter les tests ;
Prendre en compte le rsultat de chacun.
Dploiement
Objectif : Dployer les dveloppements une fois raliss.
Peut tre ralis trs tt dans le processus dans une sousactivit de prototypage dont
l'objectif est de valider :
L'architecture physique ;
Les choix technologiques.
Introduction UML 2 45 / 96
3 UML ET MTHODODOLOGIE 3.2 Rational Unied Process
46 / 96 Introduction UML 2
3.3 eXtreme programming 3 UML ET MTHODODOLOGIE
Quelles activits pouvons nous abandonner tout en produisant des logiciels de qualit ?
Comment mieux travailler avec le client pour nous focaliser sur ses besoins les plus prioritaires
et tre aussi ractifs que possible ?
Filiation avec le RAD.
Exemples de mthodes agiles :
XP (eXtreme Programming), DSDM (Dynamic Software Development Method), ASD
(Adaptative Software Development), CCM (Crystal Clear Methodologies), SCRUM,
FDD (Feature Driven Development).
eXtreme Programming
eXtreme Programming, une mthode base sur des pratiques qui sont autant de boutons pousss
au maximum .
Mthode qui peut sembler naturelle mais concrtement dicile appliquer et matriser :
Rclame beaucoup de discipline et de communication (contrairement la premire im-
pression qui peut faire penser une bullition de cerveaux individuels).
Aller vite mais sans perdre de vue la rigueur du codage et les fonctions nales de l'ap-
plication.
Force de XP : sa simplicit et le fait qu'on va droit l'essentiel, selon un rythme qui doit
rester constant.
Valeurs d'XP
Communication :
XP favorise la communication directe, plutt que le cloisonnement des activits et les
changes de documents formels.
Les dveloppeurs travaillent directement avec la matrise d'ouvrage.
Feedback :
Les pratiques XP sont conues pour donner un maximum de feedback sur le droulement
du projet an de corriger la trajectoire au plus tt.
Simplicit :
Du processus ;
Du code.
Courage :
D'honorer les autres valeurs ;
De maintenir une communication franche et ouverte ;
D'accepter et de traiter de front les mauvaises nouvelles.
Introduction UML 2 47 / 96
3 UML ET MTHODODOLOGIE 3.3 eXtreme programming
Pratiques d'XP
XP est fond sur des valeurs, mais surtout sur 13 pratiques rparties en 3 catgories :
Gestion de projets ;
Programmation ;
Collaboration.
Pratiques de programmation
Conception simple :
On ne dveloppe rien qui ne soit utile tout de suite.
Remaniement :
Le code est en permanence rorganis pour rester aussi clair et simple que possible.
Tests unitaires :
Les dveloppeurs mettent en place une batterie de tests de nonrgression qui leur per-
mettent de faire des modications sans crainte.
Tests de recette :
Les testeurs mettent en place des tests automatiques qui vrient que le logiciel rpond
aux exigences du client.
Ces tests permettent des recettes automatiques du logiciel.
Pratiques de collaboration
Responsabilit collective du code :
Chaque dveloppeur est susceptible de travailler sur n'importe quelle partie de l'appli-
cation.
Programmation en binmes :
Les dveloppeurs travaillent toujours en binmes, ces binmes tant renouvels frquem-
ment.
Rgles de codage :
Les dveloppeurs se plient des rgles de codage strictes dnies par l'quipe elle-mme.
Mtaphore :
Les dveloppeurs s'appuient sur une description commune du design.
Intgration continue :
L'intgration des nouveaux dveloppements est faite chaque jour.
Cycle de vie XP
48 / 96 Introduction UML 2
3.3 eXtreme programming 3 UML ET MTHODODOLOGIE
Exploration
Les dveloppeurs se penchent sur des questions techniques :
Explorer les direntes possibilits d'architecture pour le systme :
Etudier par exemple les limites au niveau des performances prsentes par chacune des
solutions possibles.
Le client s'habitue exprimer ses besoins sous forme de user strories (proches de dia-
grammes de cas illustrs par des diagrammes de squences).
Les dveloppeurs estiment les temps de dveloppement.
Planning
Planning de la premire release :
Uniquement les fonctionnalits essentielles ;
Premire release enrichir par la suite.
Dure du planning : 1 ou 2 jours.
Premire version (release) au bout de 2 6 mois.
Mise en production
La mise en production produit un logiciel :
Orant toutes les fonctionnalits indispensables ;
Parfaitement fonctionnel ;
Mis disposition des utilisateurs.
Itrations trs courtes ;
Tests constants en parallle du dveloppement ;
Les dveloppeurs procdent des rglages ans pour amliorer les performances du logi-
ciel.
Maintenance
Continuer faire fonctionner le systme ;
Introduction UML 2 49 / 96
3 UML ET MTHODODOLOGIE 3.3 eXtreme programming
Mort
Quand le client ne parvient plus spcier de nouveaux besoins, le projet est dit mort
Soit que tous les besoins possibles sont remplis ;
Soit que le systme ne supporte plus de nouvelles modications en restsant rentable.
Equipe XP
Pour un travil en quipe, on distingue 6 rles principaux au sein d'une quipe XP :
Dveloppeur ;
Client ;
Testeur ;
Tracker ;
Manager ;
Coach.
Dveloppeur
Conception et programmation, mme combat !
Participe aux sances de planication, value les tches et leur dicult ;
Dnition des test unitaires ;
Implmentation des fonctionnalits et des tests unitaires.
Client
crit, explique et matrise les scnarios ;
Spcie les tests fonctionnels de recette ;
Dnit les priorits.
Testeur
criture des tests de recette automatiques pour valider les scnarios clients ;
Peut inuer sur les choix du clients en fonction de la testatibilit des scnarios.
Tracker
Suivre le planning pour chaque itration ;
Comprendre les estimations produites par les dveloppeurs concernant leur charges ;
Interagir avec les dveloppeurs pour le respect du planning de l'itration courante ;
Dtection des ventuels retards et rectications si besoin.
Manager
Suprieur hirarchique des dveloppeurs :
Responsable du projet.
Vrication de la satisfaction du client ;
Contrle le planning ;
Gestion des ressources.
Coach
Garant du processus XP :
Organise et anime les sances de planications ;
Favorise la crativit du groupe, n'impose pas ses solutions techniques ;
Coup de gueules. . .
50 / 96 Introduction UML 2
3.3 eXtreme programming 3 UML ET MTHODODOLOGIE
Spcication avec XP
Pas de documents d'analyse ou de spcications dtailles.
Les tests de recette remplacent les spcications.
Emergence de l'architecture au fur et mesure du dveloppement.
XP vs RUP
Inconvnients de XP :
Focalisation sur l'aspect individuel du dveloppement, au dtriment d'une vue globale
et des pratiques de management ou de formalisation ;
Manquer de contrle et de structuration, risques de drive.
Inconvnients de RUP :
Fait tout, mais lourd, usine gaz ;
Parfois dicile mettre en oeuvre de faon spcique.
Introduction UML 2 51 / 96
4 MODLISATION AVANCE AVEC UML
Introduction UML 2 53 / 96
4 MODLISATION AVANCE AVEC UML 4.1 Expression de contraintes avec OCL
Le solde d'un compte ne doit pas tre infrieur au dcouvert maximum autoris
Si l'attribut dMax de la classe Compte est un rel et que le dcouvert est exprim par une
valeur ngative :
context c ~: Compte
inv : solde >= dMax
Si le dcouvert est exprim par un nombre positif (par ex : 300 euros si on ne doit pas
descendre en dessous de 300 euros)
context c ~: Compte
inv : solde >= - dMax
Une carte bleue est accepte dans tous les distributeurs des consortiums de la
banque
context CarteBleue
inv : distributeur
= compte . banque . consortium . distributeur
54 / 96 Introduction UML 2
4.1 Expression de contraintes avec OCL 4 MODLISATION AVANCE AVEC UML
Caractristiques d'OCL
Langage d'expressions (fonctionnel )
Valeurs, expressions, types
Fortement typ
Pas d'eets de bords
Langage de spcication, pas de programmation
Haut niveau d'abstraction
Pas forcment excutable (seul un sous-ensemble l'est)
Permet de trouver des erreurs beaucoup plus tt dans le cycle de vie
context CarteBleue
inv : compte . titulaires - > includes ( signataire )
inv : code >0 and code <=9999
inv : retraitMax >10
Introduction UML 2 55 / 96
4 MODLISATION AVANCE AVEC UML 4.1 Expression de contraintes avec OCL
Set(X)
OrderedSet(X)
56 / 96 Introduction UML 2
4.1 Expression de contraintes avec OCL 4 MODLISATION AVANCE AVEC UML
p . evaluation [ chefs ]
p . evaluation [ employes ]
p . evaluation [ chefs ]. note -> sum ()
b . compte [4029]
b . compte
compte
Invariant (inv)
Prdicat associ une classe ou une association
Doit tre vri tout instant
Le contexte est dni par un objet
Cet objet peut tre rfrenc par self
L'invariant peut tre nomm
context Personne
inv pasTropVieux ~: age < 110
inv ~: self . age >= 0
Exemples d'invariants
context Personne
inv ~: age >0 and self . age <110
inv mariageLegal ~: marie implies age > 16
inv enfantsOk ~: enfants - > size () < 20
inv ~: not enfants - > includes ( self )
inv ~: enfants - > includesAll ( filles )
inv ~: enfants - > forall ( e | self . age - e . age <14)
Introduction UML 2 57 / 96
4 MODLISATION AVANCE AVEC UML 4.1 Expression de contraintes avec OCL
Pr-condition et post-condition
Prdicats associs une opration
Les pr-conditions doivent tre vries avant l'excution
Les post-conditions sont vraies aprs l'excution
self dsigne l'objet sur lequel l'opration lieu
Dans une post-condition :
@pre permet de faire rfrence la valeur avant que opration ne soit eectue
result designe le resultat de l'opration
ocsIsNew() indique si un objet n'existait pas dans l'tat prcdent
context Classe :: operation (...): ClasseValRetour
pre nom1 ~: param1 < ...
post ~: ... result > ...
Exemples de pr et post-conditions
context Personne :: retirer ( montant : Integer )
pre ~: montant > 0
post ~: solde < solde@pre - montant
context Personne
58 / 96 Introduction UML 2
4.1 Expression de contraintes avec OCL 4 MODLISATION AVANCE AVEC UML
Type boolen
Boolean
Valeurs : true, false
Oprations : not, and, or, xor, implies, if-then-else-endif
L'valuation des oprateurs or, and, if est partielle
true or x est toujours vrai, mme si x est indni
false and x est toujours faux, mme si x est indni
( age <40 implies salaire >1000)
and ( age >=40 implies salaire >2000)
Introduction UML 2 59 / 96
4 MODLISATION AVANCE AVEC UML 4.1 Expression de contraintes avec OCL
Chanes de caractres
String
Valeurs :,'une phrase'
Oprations :
=
s.size()
s1.concat(s2), s1.substring(i1,i2)
s.toUpper(), s.toLower()
nom = nom . substring (1 ,1)
. toUpper (). concat (
nom . substring (2 , nom . size ()). toLower ())
Les chanes ne sont pas des squences de caractres
String<>Sequence(character), le type character n'existe pas
Elments et singletons
Dans tout langage typ il faut distinguer
un lment e
du singleton contenant cet lment Set{e}
Pour simplier la navigation OCL, une conversion implicite est faite lorsqu'une opration
sur une collection est applique un lement isol
elem->prop est quivalent Set{elem}->prop
self->size() = 1
Collections
Ensembles : Set(T)
Elments unique non ordonns
Ensembles ordonns : OrderedSet(T)
Elments uniques et ordonns
Sac : Bag(T)
60 / 96 Introduction UML 2
4.1 Expression de contraintes avec OCL 4 MODLISATION AVANCE AVEC UML
Oprations ensemblistes
Union : ens->union(ens)
Dierence : ens1-ens2
Ajout d'un lment : ens->including(elem)
Suppression d'un lment : ens->excluding(elem)
Conversion vers une liste : ens->asSequence()
Conversion vers un sac : ens->asBag()
Conv.vers un ens. ord. : ens->asOrderedSet()
Filtrage
Select retient les lments vriant la condition
coll -> select( cond )
Reject limine ces lements
coll -> reject( cond )
Any slectionne l'un des lments vriant la condition
coll -> any( cond )
opration non dterministe
utile lors de collection ne contenant qu'un lment
retourne la valeur indnie si l'ensemble est vide
self . enfants - > select ( age >10 and sexe = Sexe :: Masculin )
Quanticateurs
ForAll est le quanticateur universel
coll -> forAll( cond )
Exists est le quanticteur existentiel
Introduction UML 2 61 / 96
4 MODLISATION AVANCE AVEC UML 4.1 Expression de contraintes avec OCL
Unicit
Retourne vrai si pour chaque valeur de la collection, l'expression retourne une valeur dif-
frente
coll->isUnique(expr)
Equivalence entre
self . enfants - > isUnique ( prenom )}
self . enfants
-> forall ( e1 , e2 ~: Personne |
e1 <> e2 implies
e1 . prenom <> e2 . prenom )
Utile pour dnir la notion de cl en BD
T-uples
Champs nomms, pas d'ordre entre les champs
Tuples (valeurs)
Tuple { x = -1.5 , y =12.6}
Tuple { y =12.6 , x = -1.5}
Tuple { y : Real =12.6 , x : Real = -1.5}
Tuple { nom = ' dupont ' , prenom = ' leon ' ,
age =43}
A partir d'UML 2.0
Dnition de types tuples
TupleType ( x : Real , y : Real )
TupleType ( y : Real , x : Real )
TupleType ( nom : String , prenom : String ,
age : Integer )
Collections imbriques
Collections imbriques
Jusqu' UML 2.0 pas de collections de collections car peu utilis et plus complexe
comprendre
Mise plat intuitive lors de la navigation
self . parents . parents
Mise plat par default li l'opration implicite collect
A partir de UML 2.0 imbrications arbitraires des constructeurs de types
Set ( Set ( Personne ))
Sequence ( OrderedSet ( Jour ))
Trs utile pour spcier des structures non triviales
62 / 96 Introduction UML 2
4.1 Expression de contraintes avec OCL 4 MODLISATION AVANCE AVEC UML
Itrateur gnral
L'itrateur le plus gnral est iterate
Les autres itrateurs (forall, exist, select, etc.) en sont des cas particulier
coll -> iterate(
coll - > iterate (
elem ~: Type1 ~;
accumulateur : Type2 = < valInit >
| < expr > )
Exemple
enfants - > iterate (
e : Enfant ;
ac : Integer =0
| acc + e . age )
Introduction UML 2 63 / 96
4.2 Diagrammes d'tats-transitions 4 MODLISATION AVANCE AVEC UML
Etat et transition
Les tats sont reprsents par des rectangles aux coins arrondis
Les transitions sont reprsentes par des arcs orients liant les tats entre eux.
Certains tats, dits composites , peuvent contenir des sous-diagrammes.
Les diagrammes d'tat-transition d'UML reprsentent en fait des automates pile avec embote-
ment et concurrence et pas seulement des automates tats nis comme dans les premires
versions d'UML
Diagramme d'tat-transition
L'organisation des tats et des transitions pour un classeur donn est reprsente dans un
diagramme d'tats-transitions.
Le modle dynamique comprend plusieurs diagrammes d'tats.
Attention
Chaque diagramme d'tats ne concerne qu'une seule classe.
Chaque automate tats nis s'excute concurremment et peut changer d'tat de faon
indpendante des autres.
Introduction UML 2 65 / 96
4 MODLISATION AVANCE AVEC UML 4.2 Diagrammes d'tats-transitions
L'tat nal est un pseudo-tat qui indique que l'excution de l'automate ou du sous-tat
est termine.
Evnement dclencheur
Les transitions d'un diagramme d'tats-transitions sont dclenches par des vnements
dclencheurs.
Un appel de mthode sur l'objet courant gnre un vnement de type call.
Le passage de faux vrai de la valeur de vrit d'une condition boolenne gnre im-
plicitement un vnement de type change.
La rception d'un signal asynchrone, explicitement mis par un autre objet, gnre un
vnement de type signal.
L'coulement d'une dure dtermine aprs un vnement donn gnre un vnement
de type after. Par dfaut, le temps commence s'couler ds l'entre dans l'tat courant.
66 / 96 Introduction UML 2
4.2 Diagrammes d'tats-transitions 4 MODLISATION AVANCE AVEC UML
Le paramtre s'value comme une dure, par dfaut coule depuis l'entre dans l'tat
courant.
Par exemple : after(10 secondes).
Transition simple
Une transition entre deux tats est reprsente par un arc qui les lie l'un l'autre.
Elle indique qu'une instance peut changer d'tat et excuter certaines activits, si un
vnement dclencheur se produit et que les conditions de garde sont vries.
Sa syntaxe est la suivante :
nomEvenement ( params ) [ garde ] / activite
La garde dsigne une condition qui doit tre remplie pour pouvoir dclencher la transi-
tion,
L'activit dsigne des instructions eectuer au moment du tir.
Point de dcision
On peut reprsenter des alternatives pour le franchissement d'une transition.
On utilise pour cela des pseudo-tats particuliers :
Les points de jonction (petit cercle plein) permettent de partager des segments de
transition.
Ils ne sont qu'un raccourci d'criture.
Ils permettent des reprsentations plus compactes.
Les points de choix (losange) sont plus que des raccourcis d'criture.
Pour emprunter un chemin, toutes les gardes le long de ce chemin doivent s'valuer vrai
ds le franchissement du premier segment.
Introduction UML 2 67 / 96
4 MODLISATION AVANCE AVEC UML 4.2 Diagrammes d'tats-transitions
Contrairement aux points de jonction, les points de choix ne sont pas de simples racourcis
d'criture.
Transition interne
Un objet reste dans un tat durant une certaine dure et des transitions internes peuvent
intervenir.
Une transition interne ne modie pas l'tat courant, mais suit globalement les rgles d'une
transition simple entre deux tats.
Trois dclencheurs particuliers sont introduits permettant le tir de transitions internes :
entry/, do/, et exit/.
68 / 96 Introduction UML 2
4.2 Diagrammes d'tats-transitions 4 MODLISATION AVANCE AVEC UML
Etat composite
Un tat composite, par opposition un tat dit simple , est dcompos en deux ou
plusieurs sous-tats.
Tout tat ou sous-tat peut ainsi tre dcompos en sous-tats imbriqus sans limite a
priori de profondeur.
Un tat composite est reprsent par les deux compartiments de nom et d'actions internes
habituelles, et par un compartiment contenant le sous-diagramme.
Introduction UML 2 69 / 96
4 MODLISATION AVANCE AVEC UML 4.2 Diagrammes d'tats-transitions
Historique
Un pseudo-tat historique est not par un H cercl.
Une transition ayant pour cible le pseudo-tat historique est quivalente une transition
qui a pour cible le dernier tat visit dans la rgion contenant le H.
H* dsigne un historique profond, cad un historique valable pour tous les niveaux d'imbri-
cation.
Etat concurrent
Avec un sparateur en pointills, on peu reprsenter plusieurs automates s'excutant in-
dpendamment.
Un objet peut alors tre simultanment dans plusieurs tats concurrents.
70 / 96 Introduction UML 2
4.2 Diagrammes d'tats-transitions 4 MODLISATION AVANCE AVEC UML
Transition concurrente
Une transition fork correspond la cration de deux tats concurrentes.
Une transition join correspond une barrire de synchronisation qui supprime la concur-
rence.
Pour pouvoir continuer leur excution, toutes les tches concurrentes doivent pralable-
ment tre prtes franchir la transition.
Introduction UML 2 71 / 96
4.3 Digrammes d'activits 4 MODLISATION AVANCE AVEC UML
Introduction UML 2 73 / 96
4 MODLISATION AVANCE AVEC UML 4.3 Digrammes d'activits
Activit
Les activits dcrivent un traitement.
Le ot de contrle reste dans l'activit jusqu' ce que les traitements soient termins.
On peut dnir des variables locales une activit et manipuler les variables accessibles
depuis le contexte de l'activit (classe contenante en particulier).
Les activits peuvent tre imbriques hirarchiquement : on parle alors d'activits com-
posites.
Transition
Les transitions sont reprsentes par des ches pleines qui connectent les activits entre
elles.
Elles sont dclenches ds que l'activit source est termine.
Elles provoquent automatiquement le dbut immdiat de la prochaine activit d-
clencher (l'activit cible).
Contrairement aux activits, les transitions sont franchies de manire atomique, en
principe sans dure perceptible.
74 / 96 Introduction UML 2
4.3 Digrammes d'activits 4 MODLISATION AVANCE AVEC UML
Activits structures
Les activits structures utilisent les structures de contrle usuelles (conditionnelles et
boucle) travers une syntaxe qui dpend de l'outil.
La syntaxe prcise de ces annotations pas dnie dans la norme UML.
Dans une activit structure, on dnit les arguments d'entre et les sorties par des
ches encadres.
Partitions
Pour modliser un traitement mettant en oeuvre plusieurs classeurs, on peut spcier le
classeur responsable de chaque activit.
Les partitions permettent d'attribuer les activits des lments particuliers du modle.
Une partition peut elle-mme tre dcompose en sous-partitions.
Pour spcier qu'une activit est eectue par un classeur particulier, on la positionne dans
la partiction correspondante.
Partitions multidimensionnelles
Partitions explicites
Cette notation est moins encombrante graphiquement
Toutefois, elle met moins bien en valeur l'appartenance de groupes d'activits un mme
conteneur.
Introduction UML 2 75 / 96
4 MODLISATION AVANCE AVEC UML 4.3 Digrammes d'activits
Pin
Un pin reprsente un point de connexion pour une action.
L'action ne peut dbuter que si l'on aecte une valeur chacun de ses pins d'entre.
Les valeurs sont passes par copie.
Quand l'activit se termine, une valeur doit tre aecte chacun des pibs de sortie
Flot de donnes
Un ot d'objets permet de passer des donnes d'une activit une autre.
De fait, un arc qui a pour origine et destination un pin correspond un ot de donnes.
Concurrence
Les diagrammes d'activits permettent en principe de reprsenter des activits squen-
tielles.
Nanmoins, on peut reprsenter des activits concurrentes avec :
Les barres de synchronisation,
Les noeuds de contrle de type ow nal .
76 / 96 Introduction UML 2
4.3 Digrammes d'activits 4 MODLISATION AVANCE AVEC UML
Barre de synchronisation
Plusieurs transitions peuvent avoir pour source ou pour cible une barre de synchronisation.
Lorsque la barre de synchronisation a plusieurs transitions en sortie, on parle de transi-
tion de type fork qui correspond une duplication du ot de contrle en plusieurs ots
indpendants.
Lorsque la barre de synchronisation a plusieurs transitions en entre, on parle de transi-
tion de type join qui correspond un rendez-vous entre des ots de contrle.
Pour plus de commodit, il est possible de fusionner des barres de synchronisation de type
join et fork.
On a alors plusieurs transitions entrantes et sortantes sur une mme barre.
Actions de communication
Les actions de communication grent
le passage et le retour de paramtres,
les mcanismes d'appels d'oprations synchrones et asynchrones.
Les actions de communication peuvent tre employs comme des activits dans les dia-
grammes d'activit.
Introduction UML 2 77 / 96
4 MODLISATION AVANCE AVEC UML 4.3 Digrammes d'activits
Appel asynchrone
Les appels asynchrones de type send correspondent des envois de messages asynchrones.
Le broadcast signal permet d'mettre vers plusieurs destinataires la fois
Cette possibilit est rarement oerte par les langages de programmation.
L'action symtrique ct rcepteur est accept event, qui permet la rception d'un signal.
Exceptions
Les exceptions permettent d'interrompre un traitement quand une situation qui dvie du
traitement normal se produit. Elles assurent une gestion plus propre des erreurs qui peuvent
se produire au cours d'un traitement.
On utilise des pins d'exception (avec un triangle) un pour grer l'envoi d'exceptions et la
capture d'exceptions.
Un ot de donnes correspondant une exception est matrialis par une che en zigue
zague .
Rgions interruptibles
Ce mcanisme est analogue celui des interruptions, mais il est moins dtaill.
Les rgions interruptibles sont mieux adaptes aux phases de modlisation fonctionnelles.
Une rgion interruptible est reprsente par un cadre arrondi en pointills.
Si l'vnement d'interruption se produit, toutes les activits en cours dans la rgion
interruptible sont stoppes
Le ot de contrle suit la che en zigzag qui quitte la rgion.
78 / 96 Introduction UML 2
4.3 Digrammes d'activits 4 MODLISATION AVANCE AVEC UML
Introduction UML 2 79 / 96
4.4 Diagrammes de communication 4 MODLISATION AVANCE AVEC UML
Diagrammes d'interaction
Les diagrammes de communication et les diagrammes de squences sont deux types de
diagramme d'interaction
Un diagramme de squence montre des interactions sous un angle temporel, en mettant
l'emphase sur le squencement temporel de messages changs entre des lignes de vie
Un diagramme de communication montre une reprsentation spatiale des lignes de vie.
Ils reprsentent la mme chose, mais sous des formes direntes.
A ces diagrammes, UML 2.0 en ajoute un troisime : le diagramme de timing.
Son usage est limit la modlisation des systmes qui s'excutent sous de fortes con-
traintes de temps, comme les systmes temps rel.
Rles et connecteurs
Le rle permet de dnir le contexte d'utilisation de l'interaction.
Introduction UML 2 81 / 96
4 MODLISATION AVANCE AVEC UML 4.4 Diagrammes de communication
Une rle dans un diagramme de communication correspond une ligne de vie dans un
diagramme de squences.
Les relations entre les lignes de vie sont appeles connecteurs .
Un connecteur se reprsente de la mme faon qu'une association mais la smantique est
plus large : un connecteur est souvent une association transitoire.
Comme pour les diagrammes de squence, la syntaxe d'une ligne de vie est :
< nomRole >[ < selecteur >]: < nomClasseur >
Types de messages
Comme dans les diagrammes de squence, on distingue deux types de messages :
Un message synchrone bloque l'expditeur jusqu' la rponse du destinataire. Le ot de
contrle passe de l'metteur au rcepteur.
Un message asynchrone n'est pas bloquant pour l'expditeur. Le message envoy peut
tre pris en compte par le rcepteur tout moment ou ignor.
82 / 96 Introduction UML 2
4.4 Diagrammes de communication 4 MODLISATION AVANCE AVEC UML
Messages simultans
Lorsque des messages sont envoys en parallle, on les numrote avec des lettres
1.a, 1.b,... pour des messages simultans envoys en rponse un message dont l'envoi
portait le numro 1
Introduction UML 2 83 / 96
4 MODLISATION AVANCE AVEC UML 4.4 Diagrammes de communication
Collaboration
Une collaboration montre des instances qui collaborent dans un contexte donn pour mettre
en oeuvre une fonctionnalit d'un systme.
Une collaboration est reprsente par une ellipse en traits pointills comprenant deux com-
partiments.
Le compartiment suprieur contient le nom de la collaboration ayant pour syntaxe :
< nomRole >: < nomType >[ < multiplicite >]
Exemple de collaboration
Diagramme de collaboration
Une collaboration peut aussi se reprsenter par une ellipse sans compartiment, portant le
nom de la collaboration en son sein. Les instances sont relies l'ellipse par des lignes qui
portent le nom du rle de chaque instance.
On peut ainsi former des diagrammes de collaborations.
84 / 96 Introduction UML 2
4.4 Diagrammes de communication 4 MODLISATION AVANCE AVEC UML
Collaborations et interactions
Les collaborations donnent lieu des interactions
Les interactions documentent les collaborations
Les collaborations organisent les interactions.
Les interactions se repsentent indiremment par des diagrammes de communication ou
de squence
Introduction UML 2 85 / 96
4.5 Diagrammes de composants et de dploiement
4 MODLISATION AVANCE AVEC UML
Diagramme de composant
Les diagrammes de composants reprsentent l'architecture logicielle du systme.
Les composants peuvent tre dcomposs en sous-composants, le cas chant.
Les liens entre composants sont spcis l'aide de dpendances entre leurs interfaces.
Le cblage interne d'un composant est spci par les connecteurs de dlgation.
Un tel connecteur connecte un port externe du composant avec un port de l'un de ses
sous-composants internes.
Architecture matrielle
En dernier lieu, un systme doit s'excuter sur des ressources matrielles dans un environ-
nement matriel particulier.
UML permet de reprsenter un environnement d'excution ainsi que des ressources physiques
(avec les parties du systme qui s'y excutent) grce aux diagrammes de dploiement.
Introduction UML 2 87 / 96
4 MODLISATION AVANCE AVEC UML
4.5 Diagrammes de composants et de dploiement
Noeud
Un noeud est une ressource sur laquelle des artefacts peuvent tre dploys pour tre
excuts.
C'est un classeur qui peut prendre des attributs.
Un noeud se reprsente par un cube dont le nom respecte la syntaxe des noms de classes.
Les noeuds peuvent tre associs comme des classes et on peut spcier des multiplicits.
Artefact
Un artefact est la spcication d'une entit physique du monde rel.
Il se reprsente comme une classe par un rectangle contenant le mot-cl artefact suivi du
nom de l'artefact.
Un artefact dploy sur un noeud est symbolis par une che en trait pointill qui porte
le strotype dploy et qui pointe vers le noeud.
L'artefact peut aussi tre inclus directement dans le cube reprsentant le noeud.
Plusieurs strotypes standard existent pour les artefacts : document, excutable, chier,
librairie, source.
88 / 96 Introduction UML 2
5 BONNES PRATIQUES DE LA MODLISATION OBJET
Introduction UML 2 89 / 96
5 BONNES PRATIQUES DE LA MODLISATION OBJET 5.1 Design Patterns
Les patrons sont nombreux (23 dans l'ouvrage du GOF, d'autres sont publis rgulire-
ment)
Lesquels sont semblables ?
Les patrons sont parfois de niveaux dirents : certains patterns s 'appuient sur d
'autres...
Creational patterns
Formes de cration pour :
Abstraire le processus d'instanciation des objets.
Rendre indpendant de la faon dont les objets sont crs, composs, assembls, reprsen-
ts.
Encapsuler la connaissance de la classe concrte qui instancie.
Cacher ce qui est cr, qui cre, comment et quand.
Singleton
Intention :
Garantir qu'une classe n'a qu'une seule instance et fournit un point d'accs global cette
classe.
Indications :
S'il doit n'y avoir exactement qu'une instance de la classe et qu'elle doit tre accessible
aux clients de manire globale.
Si l'instance doit pouvoir tre sous-classe et si l'extension doit tre accessible aux clients
sans qu'ils n'aient modier leur code.
90 / 96 Introduction UML 2
5.1 Design Patterns 5 BONNES PRATIQUES DE LA MODLISATION OBJET
Motivation :
Spooler d'impression, gestionnaire d'achage
Gnrateur de nombres alatoires avec graine
Singleton : Structure
Singleton : Implmentation
public class Singleton {
private static Singleton uniqueInstance = null ;
private Singleton () {...}
public static Singleton Instance () {
if ( uniqueInstance == null )
uniqueInstance = new Singleton ();
return uniqueInstance ;
}
}
A ajouter :
Attributs et mthodes spciques de la classe singleton en question.
Paramtres de constructeur si besoin .
Structural patterns
Formes de structure :
Comment les objets sont assembls
Les patterns sont complmentaires les uns des autre
Adapter
Intention :
Convertir l'interface d'une classe en une autre qui soit conforme aux attentes d'un client.
L'adaptateur permet des classes de collaborer malgr des interfaces incompatibles.
Indications :
On veut utiliser une classe existante, mais son interface ne concide pas avec celle es-
compte.
On souhaite crer une classe rutilisable qui collaborera avec des classes encore inconnues,
mais qui n'auront pas ncessairement l'interface escompte
Introduction UML 2 91 / 96
5 BONNES PRATIQUES DE LA MODLISATION OBJET 5.1 Design Patterns
Adapter : Motivation
Adapter : Structure
Bridge
Intention :
Dcouple une abstraction de son implmentation an que les deux lments puissent tre
modis indpendamment l'un de l'autre
Indications :
On souhaite viter un lien dnitif entre une abstraction et son implmentation, les deux
devant pouvoir tre tendues par hritage
Les modications de l'implmentation d'une abstraction ne doievent pas avoir de con-
squence sur le code client (pas de recompilation)
Bridge : Motivation
92 / 96 Introduction UML 2
5.1 Design Patterns 5 BONNES PRATIQUES DE LA MODLISATION OBJET
Bridge : Structure
Composite
Intention :
Composition d'objets en structures arborescentes pour reprsenter des structures com-
posant/compos.
Permettre au client de traiter de la mme manire les objets atomiques et les combi-
naisons de ceux-ci.
Indications :
On souhaite reprsenter des hirarchies d'individus l'ensemble
On souhaite que le client n'ait pas se proccuper de la dirence entre combinaisons
d'objets et objets individuels
Composite : Motivation
Composite : Structure
Introduction UML 2 93 / 96
5 BONNES PRATIQUES DE LA MODLISATION OBJET 5.1 Design Patterns
Behavioural patterns
Formes de comportement pour dcrire :
des algorithmes
des comportements entre objets
des formes de communication entre objet
Observer
Intention :
Dnir une dpendance de type un plusieurs de faon ce que, quand un objet
change d'tat, tous ceux qui en dpendent en soient notis et automatiquement mis
jour.
Indications :
Quand un concept a plusieurs reprsentations, l'une dpendant de l'autre.
Quand un la modication d'un objet ncessite la modication dautres objets, sans qu'on
en connaisse le nombre exact.
Quand un objet doit notier d'autres objets avec lesquels il n'est pas fortement coupl.
Observer Motivation
Observer Structure
94 / 96 Introduction UML 2
5.1 Design Patterns 5 BONNES PRATIQUES DE LA MODLISATION OBJET
Strategy
Intention :
Dnir une famille d'algorithmes en encapsulant chacun d'eux et en les rendant inter-
changeables.
Indications :
Plusieurs classes apparentes ne dirent que par leur comportement.
On a besoin de plusieurs variantes d'un algorithme.
Un algorithme utilise des donnes que les clients n'ont pas connatre.
Une classe dnit un ensemble de comportements qui gurent dans des oprations sous
la forme de dclarations conditionnelles multiples.
Strategy : Motivation
Strategy : Structure
Abuser des patrons de conception peut parfois nuire la lisibilit des solutions de con-
ception proposes
On peut aussi produire de nouveaux design patterns
Introduction UML 2 95 / 96
5 BONNES PRATIQUES DE LA MODLISATION OBJET 5.1 Design Patterns
96 / 96 Introduction UML 2