Uml Cours Slides

Introduction UML 2
Modlisation Oriente Objet de Systmes Logiciels

Pierre Grard
Universit de Paris 13 IUT Villetaneuse
DUT Informatique S2D
Pierre
Grard
(P13 IUT Villetaneuse)
Introduction UML 2
1 / 342
Plan
Introduction la Modlisation Oriente Objet
Modlisation objet lmentaire avec UML
UML et mthododologie
Modlisation avance avec UML
Bonnes pratiques de la modlisation objet
Pierre
Grard
Introduction UML 2
2 / 342
Bibliographie UML
UML 2.0, guide de rfrence
James Rumbaugh, Ivar Jacobson, Grady Booch

Editions Campus Press (2005)
UML 2.0
Benot Charoux, Aomar Osmani, Yann Thierry-Mieg

Editions Pearson, Education France (2008)
UML 2.0 Superstructure et UML 2.0 Infrastructure

OMG (Object Management Group)
www.uml.org (2004).
Pierre
Grard
Introduction UML 2
3 / 342
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
Pierre
Grard
Introduction UML 2
4 / 342
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.
Les problmes lis l'informatique sont essentiellement des problmes de

logiciel.
Pierre
Grard
Introduction UML 2
5 / 342
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 ?
Pierre
Grard
Introduction UML 2
6 / 342
Critres de qualit d'un logiciel

Utilit
Adquation entre le logiciel et les besoins des utilisateurs ;
Utilisabilit
Fiabilit
Interoprabilit
Interactions avec d'autres logiciels ;
Performance
Portabilit
Rutilisabilit
Facilit de maintenance
Un logiciel ne s'use pas pourtant, la maintenance absorbe une trs

grosse partie des eorts de dveloppement.
Pierre
Grard
Introduction UML 2
7 / 342
Poids de la maintenance
Dnition
des besoins
Conception
Codage
Intgration
Tests
Maintenance
Pierre
Grard
Rartition
eort dv.
Origine des
erreurs
Cot de la
maintenance
5%
7%
15%
27%
7%
10%
13%
1%
4%
6%
56%
82%
67%
(Zeltovitz, De Marco)
Introduction UML 2
8 / 342
Cycle de vie
La qualit du processus de fabrication est garante de la qualit du produit.

Pour obtenir un logiciel de qualit, il faut en matriser le processus
d'laboration.
La vie d'un logiciel est compose de direntes tapes.
La succession de ces tapes forme le cycle de vie du logiciel.
Il faut contrler la succession de ces direntes tapes.
Pierre
Grard
Introduction UML 2
9 / 342
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
Pierre
Grard
Introduction UML 2
10 / 342
Modlisation
Pierre
Grard
Introduction UML 2
11 / 342
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'inuencent 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.
Pierre
Grard
Introduction UML 2
12 / 342
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.
Pierre
Grard
Introduction UML 2
13 / 342
Modlisation par dcomposition fonctionnelle

Approche descendante :
Dcomposer la fonction globale jusqu' obtenir des fonctions simples

apprhender et donc programmer.
C'est la fonction qui donne la forme du systme.
Pierre
Grard
Introduction UML 2
14 / 342
Modlisation oriente objets

La Conception Oriente Objet (COO) est la mthode qui conduit
des architectures logicielles fondes sur les objets du systme, plutt
que sur une dcomposition fonctionelle.
C'est la structure du systme lui donne sa forme.
On peut partir des objets du domaine (briques de base) et remonter
vers le systme global : approche ascendante.
Attention, l'approche objet n'est pas seulement ascendante.
Pierre
Grard
Introduction UML 2
15 / 342
Unied Modeling Language

Au milieu des annes 90, les auteurs de Booch, OOSE et OMT ont
dcid de crer un langage de modlisation uni avec pour objectifs :
Modliser un systme des concepts l'excutable, en utilisant les
techniques oriente objet ;
Rduire la complexit de la modlisation ;

Utilisable par l'homme comme la machine :
Reprsentations graphiques mais disposant de qualits formelles

susantes pour tre traduites automatiquement en code source ;
Ces reprsentations ne disposent cependant pas de qualits formelles
susantes pour justier d'aussi bonnes proprits mathmatiquesque
des langeges de spcication formelle (Z, VDM...).
Ociellement UML est n en 1994.

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.
Pierre
Grard
Introduction UML 2
16 / 342
Plan
Diagrammes de cas d'utilisation
Pierre

Diagrammes de classes
Diagrammes d'objets
Diagrammes de squences
Grard
Introduction UML 2
17 / 342
Modlisation des besoins
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.
Pierre
Grard
Introduction UML 2
18 / 342
Exemple de diagramme de cas d'utilisation
Pierre
Grard
Introduction UML 2
19 / 342
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 dclenchement, un droulement et une n, pour l'acteur qui l'initie.
Pierre
Grard
Introduction UML 2
20 / 342
Acteurs et cas d'utilisation
Pierre
Grard
Introduction UML 2
21 / 342
Relations entre cas d'utilisation en acteurs

Les acteurs impliqus dans un cas d'utilisation lui sont lis par une
association.
Un acteur peut utiliser plusieurs fois le mme cas d'utilisation.
Pierre
Grard
Introduction UML 2
22 / 342
Relations entre cas d'utilisation
Inclusion : le cas A inclut le cas B (B est une partie obligatoire de A).

Extension : le cas B tend le cas A (A est une partie optionelle de A).
Gnralisation : le cas A est une gnralisation du cas du cas B (B
est une sorte de A).
Pierre
Grard
Introduction UML 2
23 / 342
Dpendances d'inclusion et d'extension
Les inclusions et les extensions sont reprsentes par des
dpendances.
Lorsqu'un cas B inclut un cas A, B dpend de A.

Lorsqu'un cas B tend un cas A, B dpend aussi de A.
On note toujours la dpendance par une che pointille B 99K A qui
se lit B dpend de A .
Losqu'un lment A dpend d'un lment B, toute modication de B

sera susceptible d'avoir un impact sur A.
Les incude et les extend sont des strotypes (entre
guillements) des relations de dpendance.
Attention
Le sens des ches indique le dpendance, pas le sens de la relation

d'inclusion.
Pierre
Grard
Introduction UML 2
24 / 342
Rutilisabilit avec les inclusions et les extensions

Les relations entre cas permettent la rutilisabilit du cas
s'authentier : il sera inutile de dvelopper plusieurs fois un
module d'authentication.
Pierre
Grard
Introduction UML 2
25 / 342
Dcomposition grce aux inclusions et aux

extensions
Quand un cas est trop complexe (faisant intervenir un trop grand
nombre d'actions), on peut procder sa dcomposition en cas plus
simples.
Pierre
Grard
Introduction UML 2
26 / 342
Gnralisation
Un virement est est un cas

particulier de paiement.
Un virement est une sorte de
paiement.
La che pointe vers l'lment gnral.
Cette relation de gnralisation/spcialisation est prsente dans la
plupart des diagrammes UML et se traduit par le concept d'hritage
dans les langages orients objet.
Pierre
Grard
Introduction UML 2
27 / 342
Relations entre acteurs
Une seule relation possible : la gnralisation.
Pierre
Grard
Introduction UML 2
28 / 342
Identication des acteurs
Les principaux acteurs sont les utilisateurs du systme.
Attention
Un acteur correspond un rle, pas une personne physique.

Une mme personne physique peut tre reprsente par plusieurs
acteurs si elle a plusieurs rles.
Si plusieurs personnes jouent le mme rle vis--vis du systme, elles
seront reprsentes par un seul acteur.
En plus des utilisateurs, les acteurs peuvent tre :
Des priphriques manipuls par le systme (imprimantes...) ;

Des logiciels dj disponibles intgrer dans le projet ;
Des systmes informatiques externes au systme mais qui interagissent
avec lui, etc.
Pour faciliter la recherche des acteurs, on se fonde sur les frontires

du systme.
Pierre
Grard
Introduction UML 2
29 / 342
Acteurs principaux et secondaires
L'acteur est dit principal pour un cas d'utilisation lorsque l'acteur est
l'initiative des changes ncessaires pour raliser le 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.
Pierre
Grard
Introduction UML 2
30 / 342
Recenser les cas d'utilisation
Il n'y a pas une manire mcanique et totalement objective de reprer

les cas d'utilisation.
Il faut se placer du point de vue de chaque acteur et dterminer
comment il se sert du systme, dans quels cas il l'utilise, et quelles
fonctionnalits il doit avoir accs.
Il faut viter les redondances et limiter le nombre de cas en se situant
au bon niveau d'abstraction (par exemple, ne pas rduire un cas une
seule action).
Il ne faut pas faire apparatre les dtails des cas d'utilisation, mais il
faut rester au niveau des grandes fonctions du systme.
Trouver le bon niveau de dtail pour les cas d'utilisation est un problme
dicile qui ncessite de l'exprience.
Pierre
Grard
Introduction UML 2
31 / 342
Description des cas d'utilisation
Le diagramme de cas d'utilisation dcrit les grandes fonctions d'un

systme du point de vue des acteurs, mais n'expose pas de faon
dtaille le dialogue entre les acteurs et les cas d'utilisation.
Un simple nom est tout fait insusant pour dcrire un cas
d'utilisation.
Chaque cas d'utilisation doit tre document pour qu'il n'y ait aucune
ambigut concernant son droulement et ce qu'il recouvre prcisment.
Pierre
Grard
Introduction UML 2
32 / 342
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
Pierre
Grard
Introduction UML 2
33 / 342
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
2
3
4
5
Le client saisit les informations de sa carte bancaire

Le systme vrie que le numro de CB est correct
Le systme vrie la carte auprs du systme bancaire
Le systme demande au systme bancaire de dbiter le client
Le systme notie le client du bon droulement de la transaction
Enchanements alternatifs
1
2
En (2) : si le numro est incorrect, le client est averti de l'erreur, et

invit recommencer
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
Pierre
Grard
Introduction UML 2
33 / 342
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
Pierre
Grard
Introduction UML 2
33 / 342
Plan
Pierre

Diagrammes d'objets
Grard
Introduction UML 2
34 / 342
Objectif
Les diagrammes de cas d'utilisation modlisent QUOI sert le

systme.
Le systme est compos d'objets qui interagissent entre eux et avec les
acteurs pour raliser ces cas d'utilisation.
Les diagrammes de classes permettent de spcier la structure et les
liens entre les objets dont le systme est compos.
Pierre
Grard
Introduction UML 2
35 / 342
Exemple de diagramme de classes
Pierre
Grard
Introduction UML 2
36 / 342
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 dcrit un type d'objets concrets.
Une classe spcie la manire dont tous les objets de mme type seront
dcrits (dsignation, 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]
Pierre
Grard
Introduction UML 2
37 / 342
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.
D'autres compartiments peuvent tre ajouts : responsabilits,

exceptions, etc.
Pierre
Grard
Introduction UML 2
38 / 342
Proprits : attributs et oprations
Les attributs et les oprations sont les proprits d'une classe. Leur
nom commence par une minuscule.
Un attribut dcrit une donne de la classe.
Les types des attributs et leurs initialisations ainsi que les modicateurs
d'accs peuvent tre prciss dans le modle
Les attributs prennent des valeurs lorsque la classe est instancie : ils
sont en quelque sorte des variables attaches aux objets.
Une opration est un service oert par la classe (un traitement que les
objets correspondant peuvent eectuer).
Pierre
Grard
Introduction UML 2
39 / 342
Compartiment des attributs
Un attribut peut tre initialis et sa visibilit est dnie lors de sa

dclaration.
Syntaxe de la dclaration d'un attribut :
modifAcces nomAtt : nomClasse [ multi ]= valeurInit
Pierre
Grard
Introduction UML 2
40 / 342
Compartiment des oprations
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
Pierre
Grard
Introduction UML 2
41 / 342
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))~;
}
Pierre
Grard
Introduction UML 2
42 / 342
Relations entre classes
Une relation d'hritage est une relation de

gnralisation/spcialisation permettant l'abstraction.
Une dpendance est une relation unidirectionnelle exprimant une
dpendance smantique entre les lments du modle (che ouverte
pointille).
Une association reprsente une relation smantique entre les objets
d'une classe.
Une relation d'agrgation dcrit une relation de contenance ou de
composition.
Pierre
Grard
Introduction UML 2
43 / 342
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.
Pierre
Grard
Introduction UML 2
44 / 342
Multiplicits des associations
La notion de multiplicit permet le contrle du nombre d'objets

intervenant dans chaque instance d'une association.
Exemple : un article n'appartient qu' une seule catgorie (1) ; une
catgorie concerne plus de 0 articles, sans maximum (*).
La syntaxe est MultMin..MultMax.
* la place de MultMax signie plusieurs sans prciser de

nombre.
n..n se note aussi n , et 0..* se note * .
Pierre
Grard
Introduction UML 2
45 / 342
Navigabilit d'une association
La navigabilit permet de spcier dans quel(s) sens il est possible de

traverser l'association l'excution.
On restreint la navigabilit d'une association un seul sens l'aide
d'une che.
Exemple : Connaissant un article on connat les commentaires, mais

pas l'inverse.
On peut aussi reprsenter les associations navigables dans un seul sens

par des attributs.
Exemple : En ajoutant un attribut avisInternaute de classe
Commentaire la place de l'association.
Pierre
Grard
Introduction UML 2
46 / 342
Association unidirectionnelle de 1 vers 1
Pierre
Grard
Introduction UML 2
47 / 342
Implantation
public class Adresse {...}

public class Client {
private Adresse livraison ;
public void setAdresse ( Adresse adresse ){
this . livraison = adresse ;
}
public Adresse getAdresse (){
return livraison ;
}
}
Pierre
Grard
Introduction UML 2
48 / 342
Association bidirectionnelle de 1 vers 1
Pierre
Grard
Introduction UML 2
49 / 342
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
}
}
Pierre
Grard
Introduction UML 2
50 / 342
Association unidirectionnelle de 1 vers *
Pierre
Grard
Introduction UML 2
51 / 342
Implantation
public class Commentaire {...}
public class Article {

private Vector avisInternaute = new Vector ();
public void addCommentaire ( Commentaire commentaire ){
avisInternaute . addElement ( commentaire );
}
public void removeCommentaire ( Commentaire commentaire ){
avisInternaute . removeElement ( commentaire );
}
}
Pierre
Grard
Introduction UML 2
52 / 342
Implantation d'une association

bidirectionnelle de * vers *
Plus dicile : grer la fois la cohrence et les collections
Pierre
Grard
Introduction UML 2
53 / 342
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 .
Pierre
Grard
Introduction UML 2
54 / 342
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 association devient alors une classe appele
classe-association .
Pierre
Grard
Introduction UML 2
55 / 342
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.
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.
Pierre
Grard
Introduction UML 2
56 / 342
Association de type agrgation
Une agrgation est une forme particulire

d'association. Elle reprsente la relation d'inclusion
d'un lment dans un ensemble.
On reprsente l'agrgation par l'ajout d'un losange
vide du ct de l'agrgat.
Une agrgation dnote une relation d'un ensemble ses
parties. L'ensemble est l'agrgat et la partie l'agrg.
Pierre
Grard
Introduction UML 2
57 / 342
Association de type composition
La relation de composition dcrit une contenance structurelle entre

instances. On utilise un losange plein.
La destruction et la copie de l'objet composite (l'ensemble) impliquent
respectivement la destruction ou la copie de ses composants (les parties).
Une instance de la partie n'appartient jamais plus d'une instance de
l'lment composite.
Pierre
Grard
Introduction UML 2
58 / 342
Composition et agrgation
Ds lors que l'on a une relation du tout sa partie, on a une relation

d'agrgation ou de composition.
La composition est aussi dite agrgation forte .
Pour dcider de mettre une composition plutt qu'une

agrgation, on doit se poser les questions suivantes :
Est-ce que la destruction de l'objet composite (du tout) implique

ncessairement la destruction des objets composants (les parties) ?
C'est le cas si les composants n'ont pas d'autonomie vis--vis des
composites.
Lorsque l'on copie le composite, doit-on aussi copier les composants,
ou est-ce qu'on peut les rutiliser , auquel cas un composant peut
faire partie de plusieurs composites ?
Si on rpond par l'armative ces deux questions, on doit utiliser une

composition.
Pierre
Grard
Introduction UML 2
59 / 342
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
Pierre
Grard
Introduction UML 2
60 / 342
Implantation de l'hritage en Java

class Article {
...
void acheter () {
...
}
}
class Livre
extends Article {
...
}
Attention
Les extends Java n'a rien voir avec le extend UML vu pour les
cas d'utilisation
Pierre
Grard
Introduction UML 2
61 / 342
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 diagrammes de cas d'utilisation ou d'autres packages. On
organise les lments modliss en packages et sous-packages.
Pierre
Grard
Introduction UML 2
62 / 342
Exemple d'encapsulation
Les modicateurs d'accs sont galement applicables aux oprations.

Pierre
Grard
Introduction UML 2
63 / 342
Relation d'hritage et proprits
La classe enfant possde toutes les proprits

de ses classes parents (attributs et oprations)
enfant est la classe spcialise (ici Livre)

parent est la classe gnrale (ici Article)
Toutefois, elle n'a pas accs aux proprits prives.
La classe
La classe
Pierre
Grard
Introduction UML 2
64 / 342
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 instance 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).
Pierre
Grard
Introduction UML 2
65 / 342
Classes abstraites
Une mthode est dite abstraite lorsqu'on connat son entte mais pas
la manire dont elle peut tre ralise.
Il appartient aux classes enfant de dnir les methodes abstraites.
Une classe est dite abstraite lorsqu'elle dnit au moins une mthode
abstraite ou lorsqu'une classe parent contient une mthode abstraite
non encore ralise.
Pierre
Grard
Introduction UML 2
66 / 342
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.
Pierre
Grard
Introduction UML 2
67 / 342
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
Pierre
Grard
Introduction UML 2
68 / 342
Classe cliente d'une interface
Quand une classe dpend d'une interface (interface requise) pour

raliser ses oprations, elle est dite classe cliente de l'interface
On utilise une relation de dpendance entre la classe cliente et
l'interface requise. Toute classe implmentant l'interface pourra tre
utilise.
Pierre
Grard
Introduction UML 2
69 / 342
Exemple d'interface
Pierre
Grard
Introduction UML 2
70 / 342
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
/ .
Pierre
Grard
Introduction UML 2
71 / 342
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
Pierre
Grard
Introduction UML 2
72 / 342
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.
Pierre
Grard
Introduction UML 2
73 / 342
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 pointills ;
Utilisation d'une dpendance strotype bind pour dnir des
classes en fonction de la classe paramtre.
Java5 :
gnricit
C++ :
templates
Pierre
Grard
Introduction UML 2
74 / 342
Diagrammes de classes direntes tapes de la

conception
On peut utiliser les diagrammes de classes pour reprsenter un
systme dirents niveaux d'abstraction :
Le point de vue spcication met l'accent sur les interfaces des classes
plutt que sur leurs contenus.
Le point de vue conceptuel capture les concepts du domaine et les
liens qui les lient. Il s'intresse peu ou prou la manire ventuelle
d'implmenter ces concepts et relations et aux langages d'implantation.
Le point de vue implantation, le plus courant, dtaille le contenu et
l'implantation de chaque classe.
Les diagrammes de classes s'toent mesure qu'on va de hauts

niveaux de bas niveaux d'abstraction (de la spcication vers
l'implantation)
Pierre
Grard
Introduction UML 2
75 / 342
Construction d'un diagramme de classes

1
Trouver les classes du domaine tudi ;
Souvent, concepts et substantifs du domaine.
Trouver les associations entre classes ;
Trouver les attributs des classes ;
Souvent, verbes mettant en relation plusieurs classes.

Souvent, substantifs correspondant un niveau de granularit plus n
que les classes. Les adjectifs et les valeurs correspondent souvent des
valeurs d'attributs.
4
5
6
Pierre
Organiser et simplier le modle en utilisant l'hritage ;

Tester les chemins d'accs aux classes ;
Itrer et raner le modle.
Grard
Introduction UML 2
76 / 342
Plan
Diagrammes d'objets
Pierre

Diagrammes d'objets
Grard
Introduction UML 2
77 / 342
Objectif
Diagrammes d'objets
Le diagramme d'objets reprsente les objets d'un systme un

instant donn. Il permet de :
Illustrer le modle de classes (en montrant un exemple qui explique le

modle) ;
Prciser certains aspects du systme (en mettant en vidence des
dtails imperceptibles dans le diagramme de classes) ;
Exprimer une exception (en modlisant des cas particuliers, des
connaissances non gnralisables. . . ).
Le diagramme de classes modlise des rgles et

le diagramme d'objets modlise des faits.
Pierre
Grard
Introduction UML 2
78 / 342
Reprsentation des objets
Diagrammes d'objets
Comme les classes, on utilise des cadres compartiments.

En revanche, les noms des objets sont souligns et on peut
rajouter son identiant devant le nom de sa classe.
Les valeurs (a) ou l'tat (f) d'un objet peuvent tre spcies.
Les instances peuvent tre anonymes (a,c,d), nommes (b,f),
orphelines (e), multiples (d) ou strotypes (g).
Pierre
Grard
Introduction UML 2
79 / 342
Diagrammes d'objets
Diagramme de classes et diagramme d'objets

Le diagramme de classes contraint la structure et les liens entre les
objets.
Diagramme cohrent avec le diagramme de classes :
Pierre
Grard
Introduction UML 2
80 / 342
Diagrammes d'objets
Diagramme de classes et diagramme d'objets

Le diagramme de classes contraint la structure et les liens entre les
objets.
Diagramme incohrent avec le diagramme de classes :
Pierre
Grard
Introduction UML 2
80 / 342
Liens
Diagrammes d'objets
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.
Pierre
Grard
Introduction UML 2
81 / 342
Diagrammes d'objets
Relation de dpendance d'instanciation

La relation de dpendance d'instanciation (strotype) dcrit la
relation entre un classeur et ses instances.
Elle relie, en particulier, les associations aux liens et les classes aux
objets.
Pierre
Grard
Introduction UML 2
82 / 342
Plan
Pierre

Diagrammes d'objets
Grard
Introduction UML 2
83 / 342
Objectif des diagrammes de squence

Les diagrammes de cas d'utilisation modlisent QUOI sert le
systme, en organisant les interactions possibles avec les acteurs.
Les diagrammes de classes permettent de spcier la structure et les
liens entre les objets dont le systme est compos : ils spcie QUI
sera l'oeuvre dans le systme pour raliser les fonctionnalits dcrites
par les diagrammes de cas d'utilisation.
Les diagrammes de squences permettent de dcrire COMMENT
les lments du systme interagissent entre eux et avec les acteurs.
Les objets au coeur d'un systme interagissent en s'changent des
messages.
Les acteurs interagissent avec le systme au moyen d'IHM (Interfaces
Homme-Machine).
Pierre
Grard
Introduction UML 2
84 / 342
Exemple d'interaction
Cas d'utilisation :
Diagramme de squences correspondant :
Pierre
Grard
Introduction UML 2
85 / 342
Exemple d'interaction
Diagramme de squences correspondant :
Oprations ncessaires dans le diagramme de classes :
Pierre
Grard
Introduction UML 2
85 / 342
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]).
Pierre
Grard
Introduction UML 2
86 / 342
Messages
Les principales informations contenues dans un diagramme de

squence sont les messages changs entre les lignes de vie, prsents
dans un ordre chronologique.
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).
Pierre
Grard
Introduction UML 2
87 / 342
Principaux types de messages
Un message synchrone bloque l'expditeur jusqu' la rponse du

destinataire. Le ot de contrle passe de l'metteur au rcepteur.
Typiquement : appel de mthode
Si un objet A invoque une mthode d'un objet B, A reste bloqu tant

que B n'a pas termin.
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 ).
Pierre
Grard
Introduction UML 2
88 / 342
Correspondance messages / oprations

Les messages synchrones correspondent des oprations dans le
diagramme de classes.
Envoyer un message et attendre la rponse pour poursuivre son activit
revient invoquer une mthode et attendre le retour pour poursuivre ses
traitements.
Pierre
Grard
Introduction UML 2
89 / 342
implantation des messages synchrones
class B {
C c;
op1 ( p : Type ){
c . op2 ( p );
c . op3 ();
}
}
Pierre
Grard
class C {
op2 ( p : Type ){
...
}
op3 (){
...
}
}
Introduction UML 2
90 / 342
Correspondance messages / signaux
Les messages asynchrones correspondent des signaux dans le

Les signaux sont des objets dont la classe est strotype signal et
dont les attributs (porteurs d'information) correspondent aux paramtres
du message.
Pierre
Grard
Introduction UML 2
91 / 342
Cration et destruction de lignes de vie

La cration d'un objet est matrialise par une che qui pointe sur le
sommet d'une ligne de vie.
On peut aussi utiliser un message asynchrone ordinaire portant le nom
create .
La destruction d'un objet est matrialise par une croix qui marque la
n de la ligne de vie de l'objet.
Pierre
Grard
Introduction UML 2
92 / 342
Messages complets, perdus et trouvs

Un message complet est tel que les vnements d'envoi et de
rception sont connus.
Un message complet est reprsent par une che partant d'une ligne
de vie et arrivant une autre ligne de vie.
Un message perdu est tel que l'vnement d'envoi est connu, mais
pas l'vnement de rception.
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.
Pierre
Grard
Introduction UML 2
93 / 342
Syntaxe des messages
La syntaxe des messages est :

nomSignalOuOperation ( parametres )
La syntaxe des arguments est la suivante :

nomParametre = valeurParametre
Pour un argument modiable :

nomParametre : valeurParametre
Exemples :
appeler("Capitaine Hadock", 54214110)

afficher(x,y)
initialiser(x=100)
f(x:12)
Pierre
Grard
Introduction UML 2
94 / 342
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.
Pierre
Grard
Introduction UML 2
95 / 342
Syntaxe des messages de retour
La syntaxe des messages de retour est :

attributCible = nomOperation ( params ): valeurRetour
La syntaxe des paramtres est :

nomParam = valeurParam
ou
nomParam : valeurParam
Les messages de retour sont reprsents en pointills.
Pierre
Grard
Introduction UML 2
96 / 342
Fragment combin
Un fragment combin permet de dcomposer une interaction

complexe en fragments susamment 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 ).
Pierre
Grard
Introduction UML 2
97 / 342
Exemple de fragment avec l'oprateur

conditionnel
Pierre
Grard
Introduction UML 2
98 / 342
Type d'oprateurs d'interaction
Oprateurs de branchement ( choix et boucles) :

alternative, option, break et loop ;
Oprateurs contrlant l'envoi en parallle de messages :

parallel et critical region ;
Oprateurs contrlant l'envoi de messages :

ignore, consider, assertion et negative ;
Oprateurs xant l'ordre d'envoi des messages :

weak sequencing et strict sequencing.
Pierre
Grard
Introduction UML 2
99 / 342
Oprateur de boucle
Pierre
Grard
Introduction UML 2
100 /
342
Syntaxe de l'oprateur loop

Syntaxe d'une boucle :
loop ( minNbIterations , maxNbIterations )

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 .
Pierre
Grard
Introduction UML 2
101 /
342
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.
Pierre
Grard
Introduction UML 2
102 /
342
Rutilisation d'une interaction
Rutiliser une interaction consiste placer un fragment portant la

rfrence ref l o l'interaction est utile.
On spcie le nom de l'interaction dans le fragment.

Pierre
Grard
Introduction UML 2
103 /
342
Utilisation d'un DS pour modliser un cas

d'utilisation
Chaque cas d'utilisation donne lieu un diagramme de squences
Les inclusions et les extensions sont des cas typiques d'utilisation de la

rutilisation par rfrencement
Pierre
Grard
Introduction UML 2
104 /
342
Utilisation d'un DS pour spcier une mthode

Une interaction peut tre identie par un fragment sd (pour pour
sequence diagram )prcisant son nom
Un message peut partir du bord de l'interaction, spciant le
comportement du systme aprs rception du message, quel que soit
l'expditeur
Pierre
Grard
Introduction UML 2
105 /
342
Plan
Des besoins au code avec UML : une mthode minimale
Pierre

Rational Unied Process
eXtreme programming
Grard
Introduction UML 2
106 /
342
Pourquoi une mthode ?
Pierre
Grard
Introduction UML 2
107 /
342
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.
Pierre
Grard
Introduction UML 2
108 /
342
Mthode = Dmarche + Langage

La mthode MERISE fournit :
ET
Un langage de modlisation graphique (MCD, MPD, MOT, MCT...)

Une dmarche adopter pour dveloppent un logiciel.
UML n'est qu'un langage :
Il spcie comment dcrire des cas d'utilisation, des classes, des

interactions
Mais ne prjuge pas de la dmarche employe.
Mthodes s'appuyant sur UML :
RUP (Rational Unied Process) - par les auteurs d'UML ;

XP (eXtreme Programming) - pouvant s'appuyer sur UML.
Pierre
Grard
Introduction UML 2
109 /
342
Mthode minimale
Objectif
Rsoudre 80% des problmes avec 20% d'UML.
Proposition d'une mthode archi-minimale :
Trs nettement moins complexe que RUP ;

Adapte pour projets modestes ;
Minimum vital pour qui prtend utiliser un peu UML.
Pierre
Grard
Introduction UML 2
110 /
342
Mthode minimale
Objectif
Inspire de
UML 2 - Modliser une application web
Pascal Roques
Editions Eyrolles (2006)
Pierre
Grard
Introduction UML 2
110 /
342
Mthode minimale
Objectif
Pierre
Grard
Introduction UML 2
110 /
342
Cas d'utilsation
Comment dnir les besoins ?

1
2
3
4
5
6
Pierre
Grard
Identier les limites du systme ;

Identier les acteurs ;
Identier les cas d'utilisation ;
Structurer les cas d'utilisation en packages ;
Ajouter les relations entre cas d'utilisation ;
Classer les cas d'utilisation par ordre d'importance.
Introduction UML 2
111 /
342
Exemple de classement
Cas d'utilisation
Priorit
Ajouter article au panier

Changer prix Article
Rechercher par mots-cls
... etc ...
Risque
Haute
Moyen
Moyen Moyen
Bas
Moyen
... etc ... ... etc ...
Un tel classement permet de dterminer les cas d'utilisation centraux

en fonction :
De leur priorit fonctionnelle ;
Du risque qu'il font courrir au projet dans son ensemble.
Les fonctionnalits des cas les plus centraux seront dveloppes

prioritairement.
Pierre
Grard
Introduction UML 2
112 /
342
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.
Etapes de la dmarche :
1
2
3
4
Identier les concepts du domaine ;

Ajouter les associations et les attributs ;
Gnraliser les concepts ;
Structurer en packages : structuration selon les principes de cohrence
et d'indpendance.
Les concepts du domaine peuvent tre identis directement partir

de la connaissance du domaine ou par interview des experts mtier.
Pierre
Grard
Introduction UML 2
113 /
342
Exemple de modle du domaine
Pierre
Grard
Introduction UML 2
114 /
342
Structuration en packages
Pierre
Grard
Introduction UML 2
115 /
342
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.
Un nouveau DSS est produit pour chacun des cas d'utilisation.

Les DSS sont parfois trs simples mais ils seront enrichis par la suite.
Pierre
Grard
Introduction UML 2
116 /
342
Exemple de diagramme de squence systme
Pierre
Grard
Introduction UML 2
117 /
342
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.
Pierre
Grard
Introduction UML 2
118 /
342
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.
Pierre
Grard
Introduction UML 2
119 /
342
Diagramme de classes participantes
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 correspondent 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.
Pierre
Grard
Introduction UML 2
120 /
342
Exemple de diagramme de classes participantes
Pierre
Grard
Introduction UML 2
121 /
342
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.
Chaque diagramme de squence systme donne lieu un diagramme

d'interaction. Il y en a donc autant que de cas d'utilisation.
En plus des interactions du systme avec l'extrieur, les Diagrammes
d'Interaction montrent 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.
Pierre
Grard
Introduction UML 2
122 /
342
Des squences systme aux interactions internes
Pierre
Grard
Introduction UML 2
123 /
342
Des squences systme aux interactions internes
Pierre
Grard
Introduction UML 2
123 /
342
Diagramme des classes de conception
Les diagrammes d'interaction permettent de dnir les oprations

(ncessaires et susantes) des classes mtier et de contrle (messages
synchrones).
Pierre
Grard
Introduction UML 2
124 /
342
Plan
Pierre

eXtreme programming
Grard
Introduction UML 2
125 /
342
Modles de cycles de vie linaire
Les phases du dveloppement se suivent dans l'ordre et sans retour en

arrire.
Pierre
Grard
Introduction UML 2
126 /
342
Modles de cycles de vie linaire
Les phases du dveloppement se suivent dans l'ordre et sans retour en

arrire.
Pierre
Grard
Introduction UML 2
126 /
342
Problmes des cycles linaires
Risques levs et non contrls :

Identication tardive des problmes ;
Preuve tardive de bon fonctionnement ;
Eet tunnel.
Amliorations : construction itrative du systme :
Chaque itration produit un nouvel incrment ;
Chaque nouvel incrment a pour objectif la matrise d'une partie des

risques et apporte une preuve tangible de faisabilit ou d'adquation :
Enrichissement d'une srie de prototypes ;

Les versions livres correspondent des tapes de la chane des
prototypes.
Pierre
Grard
Introduction UML 2
127 /
342
Production itrative d'incrments

Itrations 0
A chaque itration, on refait :

1
2
3
4
Pierre
Grard
Spcication ;
Conception ;
Implmentation ;
Tests.
Introduction UML 2
128 /
342

Itrations 1

1
2
3
4
Pierre
Grard
Spcication ;
Conception ;
Implmentation ;
Tests.
Introduction UML 2
128 /
342

Itrations

1
2
3
4
Pierre
Grard
Spcication ;
Conception ;
Implmentation ;
Tests.
Introduction UML 2
128 /
342

Itrations

1
2
3
4
Pierre
Grard
Spcication ;
Conception ;
Implmentation ;
Tests.
Introduction UML 2
128 /
342

Itrations

1
2
3
4
Pierre
Grard
Spcication ;
Conception ;
Implmentation ;
Tests.
Introduction UML 2
128 /
342

Itrations

1
2
3
4
Pierre
Grard
Spcication ;
Conception ;
Implmentation ;
Tests.
Introduction UML 2
128 /
342

Itrations

1
2
3
4
Pierre
Grard
Spcication ;
Conception ;
Implmentation ;
Tests.
Introduction UML 2
128 /
342

Itrations

1
2
3
4
Pierre
Grard
Spcication ;
Conception ;
Implmentation ;
Tests.
Introduction UML 2
128 /
342
Elimination des risques chaque itration

On peut voir le dveloppement d'un logiciel comme un processus graduel
d'limination de risques.
C'est pendant Planication et xcution qu'on rpte

Spcication Conception Implmentation Tests.
Pierre
Grard
Introduction UML 2
129 /
342
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.
Pierre
Grard
Introduction UML 2
130 /
342
RUP est itratif et incrmental
Chaque itration prend en compte un certain nombre de cas

d'utilisation.
Les risques majeurs sont traits en priorit.
Chaque itration donne lieu un incrment et produit une nouvelle
version excutable.
Pierre
Grard
Introduction UML 2
131 /
342
RUP est pilot par les cas d'utilisation

La principale qualit d'un logiciel est son utilit :
Adquation du service rendu par le logiciel avec les besoins des

utilisateurs.
Le dveloppement d'un logiciel doit tre centr sur l'utilisateur.

Les cas d'utilisation permettent d'exprimer ces besoins :
Dtection et description des besoins fonctionnels ;
Organisation des besoins fonctionnels.
Pierre
Grard
Introduction UML 2
132 /
342
RUP est centr sur l'architecture
Modlisation de direntes pespectives indpendantes et

complmentaires.
Architecture en couches et vues de Krutchen.
Pierre
Grard
Introduction UML 2
133 /
342
Vues du systme
Vue cas d'utilisation :
Description du systme comme un ensemble de transactions du point

de vue de l'utilisateur.
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.
Pierre
Grard
Introduction UML 2
134 /
342
Organisation en phases du dveloppement

Initialisation :
Dnition du problme.
Elaboration :
Planication des activits, aectation des ressources, analyse.
Construction :
Dveloppement du logiciel par incrments successifs.
Transition :
Recettage et dploiement.
Les phases du dveloppement sont les grandes tapes du dveloppement du

logiciel
Le projet commence en phase d'initialisation et termine en phase de
transition
Pierre
Grard
Introduction UML 2
135 /
342
Phase d'initialisation : Objectifs
Dnition du cadre du projet, son concept, et inventaire du contenu ;

Elaboration des cas d'utilisation critiques ayant le plus d'inuence sur
l'architecture et la conception ;
Ralisation d'un ou de plusieurs prototypes dmontrant les
fonctionnalits dcrites par les cas d'utilisation principaux ;
Estimation dtaille de la charge de travail, du cot et du planning
gnral ainsi que de la phase suivante d'laboration Estimation des
risques.
Pierre
Grard
Introduction UML 2
136 /
342
Phase d'initialisation : Activits
Formulation du cadre du projet, des besoins, des contraintes et des

critres d'acceptation ;
Planication et prparation de la justication conomique du projet et
valuation des alternatives en termes de gestion des risques,
ressources, planication ;
Synthse des architectures candidates, valuation des cots.
Pierre
Grard
Introduction UML 2
137 /
342
Phase d'initialisation : Livrables
Un document de vision prsentant les besoins de base, les contraintes

et fonctionnalits principales ;
Une premire version du modle de cas d'utilisation ;
Un glossaire de projet ;
Un document de justication conomique incluant le contexte gnral
de ralisation, les facteurs de succs et la prvision nancire ;
Une valuation des risques ;
Un plan de projet prsentant phases et itrations ;
Un ou plusieurs prototypes.
Pierre
Grard
Introduction UML 2
138 /
342
Phase d'initialisation : Critres d'valuation
Un consensus sur :
La planication ;
L'estimation des cots ;
La dnition de l'ensemble des projets des parties concernes.
La comprhension commune des besoins.
Pierre
Grard
Introduction UML 2
139 /
342
Phase d'laboration : objectifs
Dnir, valider et arrter l'architecture ;

Dmontrer l'ecacit de cette architecture rpondre notre besoin ;
Planier la phase de construction.
Pierre
Grard
Introduction UML 2
140 /
342
Phase d'laboration : activits
Elaboration de la vision gnrale du systme, les cas d'utilisation

principaux sont compris et valids ;
Le processus de projet, l'infrastructure, les outils et l'environnement de
dveloppement sont tablis et mis en place ;
Elaboration de l'architecture et slection des composants.
Pierre
Grard
Introduction UML 2
141 /
342
Phase d'laboration : livrables
Le modle de cas d'utilisation est produit au moins 80 % ;

La liste des exigences et contraintes non fonctionnelles identies ;
Une description de l'architecture ;
Un excutable permettant de valider l'architecture du logiciel travers
certaines fonctionnalits complexes ;
La liste des risques revue et la mise jour de la justication
conomique du projet ;
Le plan de ralisation, y compris un plan de dveloppement prsentant
les phases, les itrations et les critres d'valuation ;
Pierre
Grard
Introduction UML 2
142 /
342
Phase d'laboration : Critres d'valuation

La stabilit de la vision du produit nal ;
La stabilit de l'architecture ;
La prise en charge des risques princip aux est adresse par le(s)
prototype(s) ;
La dnition et le dtail du plan de projet pour la phase de
construction ;
Un consensus, par toutes les parties prenantes, sur la ractualisation
de la planication, des cots et de la dnition de projet.
Pierre
Grard
Introduction UML 2
143 /
342
Phase de construction : objectifs
La minimisation des cots de dveloppement par :

L'optimisation des ressources ;
La minimisation des travaux non ncessaires.
Le maintien de la qualit ;
Ralisation des versions excutables.
Pierre
Grard
Introduction UML 2
144 /
342
Phase de construction : Activits
Gestion et le contrle des ressources et l'optimisation du processus de

projet ;
Evaluation des versions produites en regard des critres d'acceptation
dnis.
Pierre
Grard
Introduction UML 2
145 /
342
Phase de construction : Livrables
Les versions excutables du logiciel correspondant l'enrichissement

itration par itration des fonctionnalits ;
Les manuels d'utilisation raliss en parallle la livraison
incrmentale des excutables ;
Une description des versions produites.
Pierre
Grard
Introduction UML 2
146 /
342
Phase de construction : Critres d'valuation
La stabilit et la qualit des excutables ;

La prparation des parties prenantes ;
La situation nancire du projet en regard du budget initial.
Pierre
Grard
Introduction UML 2
147 /
342
Phase de transition : Objectifs
Le dploiement du logiciel dans l'environnement d'exploitation des

utilisateurs ;
La prise en charge des problmes lis la transition ;
Atteindre un niveau de stabilit tel que l'utilisateur est indpendant ;
Atteindre un niveau de stabilit et qualit tel que les parties prenantes
considrent le projet comme termin.
Pierre
Grard
Introduction UML 2
148 /
342
Phase de transition : Activits
Activits de packaging du logiciel pour le mettre disposition des

utilisateurs et de l'quipe d'exploitation ;
Correction des erreurs rsiduelles et amlioration de la performance et
du champ d'utilisation ;
Evaluation du produit nal en regard des critres d'acceptation dnis.
Pierre
Grard
Introduction UML 2
149 /
342
Phase de transition : Livrables
La version nale du logiciel ;

Les manuels d'utilisation.
Pierre
Grard
Introduction UML 2
150 /
342
Phase de transition : Critres d'valuation
La satisfaction des utilisateurs ;

La situation nancire du projet en regard du budget initial.
Pierre
Grard
Introduction UML 2
151 /
342
Organisation en activits de dveloppement

Chaque phase comprend
plusieurs itrations
Pour chacune des itrations,
on se livre plusieurs
activits :
Modlisation mtier ;
Expression des besoins ;

Analyse ;
Conception ;
Implmentation ;
Test ;
Dploiement.
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.
Pierre
Grard
Introduction UML 2
152 /
342
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.
Pierre
Grard
Introduction UML 2
153 /
342
Expression des besoins
Objectif : Cibler les besoins des utilisateurs et du clients grce une

srie d'interviews.
L'ensemble des parties prenantes du projet, matrise d'oeuvre et

matrise d'ouvrage, est acteur de cette activit.
L'activit de recueil et d'expression des besoins dbouche sur ce que

doit faire le systme (question QUOI ? )
Pierre
Grard
Introduction UML 2
154 /
342
Expression des besoins
Utilisation des cas d'utilisation pour :
Schmatiser les besoins ;

Structurer les documents de spcications fonctionnelles.
Les cas d'utilisation sont dcomposs en scnarios d'usage du systme,

dans lesquels l'utilisateur raconte ce qu'il fait grce au systme et
ses interactions avec le systme.
Un maquettage est ralisable pour mieux immerger l'utilisateur
dans le futur systme.
Une fois poses les limites fonctionnelles, le projet est plani et une
prvision des cots est ralise.
Pierre
Grard
Introduction UML 2
154 /
342
Analyse
Objectif : Transformer les besoins utilisateurs en modles UML.

Analyse objet servant de base une rexion sur les mcanismes
internes du systme.
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.
Pierre
Grard
Introduction UML 2
155 /
342
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.
Pierre
Grard
Introduction UML 2
156 /
342
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.
Pierre
Grard
Introduction UML 2
157 /
342
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 individuellement.
Mthode :
Planication pour chaque itration ;

Implmentation des tests en crant des cas de tests ;
Excuter les tests ;
Prendre en compte le rsultat de chacun.
Pierre
Grard
Introduction UML 2
158 /
342
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.
Pierre
Grard
Introduction UML 2
159 /
342
Importance des activits dans chaque phase
Pierre
Grard
Introduction UML 2
160 /
342
Principaux diagrammes UML par activit

Expression des besoins et modlisation mtier :
Modles mtier, domaine, cas d'utilisation ;
Diagramme de squences ;
Diagramme d'activit.
Analyse
Modles mtier, cas d'utilisation ;

Diagramme des classes, de squences et de dploiement.
Conception
Diagramme
Diagramme
Diagramme
Diagramme
Pierre
Grard
des classes, de squences ;

tat/transition ;
d'activit ;
de dploiement et de composant.
Introduction UML 2
161 /
342
2TUP, une variante du Unied Process .
2TUP, avec un processus de dveloppement en Y , dvelopp par

Valtech.
UML 2.0, en action : De l'analyse des besoins la conception
J2EE
Pascal Roques, Franck Valle
Editions Eyrolles (2004)
Pierre
Grard
Introduction UML 2
162 /
342
Plan
eXtreme programming
Pierre

eXtreme programming
Grard
Introduction UML 2
163 /
342
Mthodes agiles
eXtreme programming
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).
Pierre
Grard
Introduction UML 2
164 /
342
eXtreme programming
Priorits des mthodes agiles
Priorit aux personnes et aux interactions sur les procdures de les

outils ;
Priorit aux applications fonctionnelles sur une documentation
plthorique ;
Priorit la collaboration avec le client sur la ngociation de
contrat ;
Priorit l'acceptation du changement sur la planication.
Pierre
Grard
Introduction UML 2
165 /
342
eXtreme Programming
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 impression 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'application.
Force de XP : sa simplicit et le fait qu'on va droit l'essentiel, selon

un rythme qui doit rester constant.
Pierre
Grard
Introduction UML 2
166 /
342
Valeurs d'XP
eXtreme programming
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.
Pierre
Grard
Introduction UML 2
167 /
342
Pratiques d'XP
eXtreme programming
XP est fond sur des valeurs, mais surtout sur 13 pratiques rparties
en 3 catgories :
Gestion de projets ;
Programmation ;
Collaboration.
Pierre
Grard
Introduction UML 2
168 /
342
eXtreme programming
Pratiques de gestion de projets

Livraisons frquentes :
L'quipe vise la mise en production rapide d'une version minimale du

logiciel, puis elle fournit ensuite rgulirement de nouvelles livraisons en
tenant compte des retours du client.
Planication itrative :
Un plan de dveloppement est prpar au dbut du projet, puis il est

revu et remani tout au long du dveloppement pour tenir compte de
l'exprience acquise par le client et l'quipe de dveloppement.
Client sur site :
Le client est intgr l'quipe de dveloppement pour rpondre aux

questions des dveloppeurs et dnir les tests fonctionnels.
Rythme durable :
L'quipe adopte un rythme de travail qui lui permet de fournir un

travail de qualit tout au long du projet.
Jamais plus de 40h de travail par semaine (un dveloppeur fatigu
dveloppe mal).
Pierre
Grard
Introduction UML 2
169 /
342
eXtreme programming
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 permettent 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.
Pierre
Grard
Introduction UML 2
170 /
342
eXtreme programming
Pratiques de collaboration
Responsabilit collective du code :
Chaque dveloppeur est susceptible de travailler sur n'importe quelle

partie de l'application.
Programmation en binmes :
Les dveloppeurs travaillent toujours en binmes, ces binmes tant

renouvels frquemment.
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.
Pierre
Grard
Introduction UML 2
171 /
342
Cycle de vie XP
Pierre
Grard
eXtreme programming
Introduction UML 2
172 /
342
Exploration
eXtreme programming
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 diagrammes de cas illustrs par des diagrammes de
squences).
Les dveloppeurs estiment les temps de dveloppement.
Pierre
Grard
Introduction UML 2
173 /
342
Planning
eXtreme programming
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.
Pierre
Grard
Introduction UML 2
174 /
342
eXtreme programming
Itrations jusqu' la premire release

Dveloppement de la premire version de l'application.
Itrations de une quatre semaines :
Chaque itration produit un sous ensemble des fonctionnalits

principales ;
Le produit de chaque itration subit des tests fonctionnels ;
Itrations courtes pour identier trs tt des dviation par rapport au
planning.
Brves runions quotidiennes runissant toute l'quipe, pour mettre

chacun au courant de l'avancement du projet.
Pierre
Grard
Introduction UML 2
175 /
342
Mise en production
eXtreme programming
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 logiciel.
Pierre
Grard
Introduction UML 2
176 /
342
Maintenance
eXtreme programming
Continuer faire fonctionner le systme ;

Adjonction de nouvelles fonctionnalits secondaires.
Pour les fonctionnalits secondaires, on recommence par une rapide

exploration.
L'ajout de fonctionnalits secondaires donne lieu de nouvelles releases.
Pierre
Grard
Introduction UML 2
177 /
342
Mort
eXtreme programming
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.
Pierre
Grard
Introduction UML 2
178 /
342
Equipe XP
eXtreme programming
Pour un travil en quipe, on distingue 6 rles principaux au sein d'une

quipe XP :
Dveloppeur ;
Client ;
Testeur ;
Tracker ;
Manager ;
Coach.
Pierre
Grard
Introduction UML 2
179 /
342
Dveloppeur
eXtreme programming
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.
Pierre
Grard
Introduction UML 2
180 /
342
Client
eXtreme programming
crit, explique et matrise les scnarios ;

Spcie les tests fonctionnels de recette ;
Dnit les priorits.
Pierre
Grard
Introduction UML 2
181 /
342
Testeur
eXtreme programming
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.
Pierre
Grard
Introduction UML 2
182 /
342
Tracker
eXtreme programming
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.
Pierre
Grard
Introduction UML 2
183 /
342
Manager
eXtreme programming
Suprieur hirarchique des dveloppeurs :

Responsable du projet.
Vrication de la satisfaction du client ;

Contrle le planning ;
Gestion des ressources.
Pierre
Grard
Introduction UML 2
184 /
342
Coach
eXtreme programming
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. . .
Pierre
Grard
Introduction UML 2
185 /
342
Spcication avec XP
eXtreme programming
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.
Pierre
Grard
Introduction UML 2
186 /
342
XP vs RUP
eXtreme programming
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.
XP pour les petits projets en quipe de 12 max ;

RUP pour les gros projets qui gnrent beaucoup de documentation.
Pierre
Grard
Introduction UML 2
187 /
342
Plan
Expression de contraintes avec OCL
Pierre

Diagrammes d'tats-transitions
Digrammes d'activits
Diagrammes de communication
Diagrammes de composants et de dploiement
Grard
Introduction UML 2
188 /
342
Expression de contraintes avec UML
Les dirents diagrammes d'UML expriment en fait des contraintes

Graphiquement
Contraintes structurelles (un attribut dans une classe)
Contraintes de types (sous-typage)
Contraintes diverses (composition, cardinalit, etc.)
Via des proprits prdnies

Sur des classes ({abstract})
Sur des rles ({ordered})
C'est toutefois insusant
Pierre
Grard
Introduction UML 2
189 /
342
Insusances d'UML pour reprsenter certaines

contraintes
Certaines contraintes videntes sont
dicilement exprimables avec UML seul.
Le signataire d'une carte bleue est titulaire du
compte correspondant
Pierre
Grard
Introduction UML 2
190 /
342
Expression des contraintes en langage naturel

Simple mettre en oeuvre :
Utilisation des notes en UML + texte libre,

Comprhensible par tous.
Indispensable :
Documenter les contraintes est essentiel,

Dtecter les problmes le plus tt possible.
Probmlatique
Ambigu, imprcis,
Dicile d'exprimer clairement des contraintes complexes,

Dicile de lier le texte aux lments du modle.
Pierre
Grard
Introduction UML 2
191 /
342
Exemples de contraintes exprimables en OCL

Le solde d'un compte ne doit pas tre infrieur au dcouvert maximum.
Le signataire d'une carte bleue associe un compte en est le titulaire.
Une carte bleue est accepte dans tous les distributeurs des
consortiums de la banque.
...
Pierre
Grard
Introduction UML 2
192 /
342
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
Pierre
Grard
Introduction UML 2
193 /
342
Le signataire d'une carte bleue associe un

compte est titulaire de ce compte
... est le titulaire ...
context CarteBleue
inv : signataire = compte . titulaires
... est un des titulaires ...

context CarteBleue
inv : compte . titulaires -> includes ( signataire )
Pierre
Grard
Introduction UML 2
194 /
342
Une carte bleue est accepte dans tous les

distributeurs des consortiums de la banque
context CarteBleue
inv : distributeur
= compte . banque . consortium . distributeur
Pierre
Grard
Introduction UML 2
195 /
342
OCL pour l'criture de contraintes

OCL : Object Constraint Language
Langage de requtes et de contraintes

Relativement simple crire et comprendre
syntaxe purement textuelle sans symboles tranges
Parfaitement intgr UML
Smantique d'UML crite en OCL : tous les schmas UML produits ont
une traduction en OCL
En pleine expansion
Nouvelle version majeure avec UML2.0

Essentiel pour avoir des modles susemment prcis
De plus en plus d'outils
dition, vrication, gnration (partielle) de code...
Pierre
Grard
Introduction UML 2
196 /
342
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
Pierre
Grard
Introduction UML 2
197 /
342
Avantages et inconvnients d'OCL

Points faibles
Pas aussi rigoureux que des langages de spcication formelle comme

VDM, Z ou B
Pas de preuves formelles possibles dans tous les cas
Puissance d'expression limite
Points forts
Relativement simple crire et comprendre

Trs bien intgr UML
Bon compromis entre simplicit et puissance d'expression
Passage vers direntes plateformes technologiques
Pierre
Grard
Introduction UML 2
198 /
342
Contexte d'une contrainte
Une contrainte est toujours associe

un lment de modle : le contexte
de la contrainte.
Deux techniques pour spcier le
contexte :
En crivant la contrainte entre
accolades {...} dans une note.
L'lment point par la note est
alors le contexte de la contrainte
En utilsant le mot cl context
dans un document quelconque.
context CarteBleue
inv : compte . titulaires - > includes ( signataire )
inv : code >0 and code <=9999
inv : retraitMax >10
Pierre
Grard
Introduction UML 2
199 /
342
Dnition de prdicats avec OCL
OCL peut tre utilis pour dcrire trois types de prdicats avec les
mots cl :
inv: invariants de classes
inv : solde < dMax
pre: pr-conditions d'oprations

pre : montantARetirer >0
post: post-conditions d'oprations

post : solde > solde@pre
Pierre
Grard
Introduction UML 2
200 /
342
Dnition d'expressions avec OCL
OCL peut galement tre utilis pour dcrire des expressions avec les
mots cls :
def: dclarer des attributs ou des oprations
def : nbEnfants : Integer
init: spcier la valeur initiale des attributs

init : enfants - > size ()
body: exprimer le corps de mthodes {query}

body : enfants - > select ( age < a )
derive: dnir des lements drivs (/)

derive : age <18
Pierre
Grard
Introduction UML 2
201 /
342
Accs un attribut ou une mthode
Accs un attribut : objet.attribut

Ex : self.dateDeNaissance
Accs une mthode objet.operation(param1,
... )
Ex : self.impots(1998)
Pierre
Grard
Introduction UML 2
202 /
342
Navigation via une association
Accder un ensemble d'objets lis un objet donn

< objet >. < nomderole >
Le rsultat est soit une valeur soit un ensemble
Le type du rsultat dpend de la multiplicit cible et de la prsence de
la contrainte {ordered}
Set(X)
OrderedSet(X)
Pierre
Grard
Introduction UML 2
203 /
342
Notes sur la navigation via les associations

Un lement est converti en singleton lorsqu'une opration sur une
collection est applique
pere - > size ()=1
La navigation permet de tester si la valeur est dnie (l'ensemble vide

reprsente la valeur indnie)
pere - > isEmpty ()
epouse - > notEmpty ()
implies self . epouse . sexe = sexe :: feminin
Si une association n'a pas de nom de rle alors

on peut utiliser le nom de la classe destination
Pierre
Grard
Introduction UML 2
204 /
342
Navigation vers une association rexive
Si l'association est rexive, pour viter les ambiguits, il faut indiquer

avec un rle entre crochets [...] comment est parcourue l'association
objet . nomAssociation [ nomDeRole ]
p . evaluation [ chefs ]
p . evaluation [ employes ]
p . evaluation [ chefs ]. note -> sum ()
Pierre
Grard
Introduction UML 2
205 /
342
Navigation via une association qualie

Accs quali
lien . nomderole [ valeur1 , valeur2 , ... ]
ou ensemble d'objets lis

lien . nomderole
b . compte [4029]
b . compte
compte
Pierre
Grard
Introduction UML 2
206 /
342
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
Pierre
Grard
Introduction UML 2
207 /
342
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)
Pierre
Grard
Introduction UML 2
208 /
342
Pr-condition et post-condition
Prdicats associs une opration
pr-conditions doivent tre vries avant l'excution

post-conditions sont vraies aprs l'excution
self dsigne l'objet sur lequel l'opration lieu
Dans une post-condition :
Les
Les
@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 > ...
Pierre
Grard
Introduction UML 2
209 /
342
Exemples de pr et post-conditions
context Personne :: retirer ( montant : Integer )

pre ~: montant > 0
post ~: solde < solde@pre - montant
context Personne :: salaire (): integer
post ~: result >= Legislation :: salaireMinimum
context Compagnie :: embaucheEmploye ( p : Personne ): Contrat
pre pasPresent ~: not employes - > includes ( p )
post ~: employes = employes@pre - > including ( p )
post ~: result . oclIsNew ()
post ~: result . compagnie = self and result . employe = p
Pierre
Grard
Introduction UML 2
210 /
342
Dnition additionnelle (def)
Il est possible en OCL de dnir dans une classe existante:

de nouveaux attributs
de nouvelles oprations
context Classe
def ~: nomAtt ~: type = expr
def ~: nomOp ...~: type = expr
Utile pour dcomposer des requetes ou contraintes

context Personne
def : ancestres ()~:
Set ( Personne ) = parents
-> union ( parents . ancestres ()
-> asSet ())
inv : not ancestres () - > includes ( self )
Pierre
Grard
Introduction UML 2
211 /
342
Expression du corps d'une mthode (body)

Description d'une mthode sans eet de bord ({isQuery})
Equivalent une requte
context Personne : acf ( p : Personne ): OrderedSet ( Personne )

body ~: self . ancestres ()
-> select ( sexe = Sexe :: Feminin )
-> sortedBy ( dateDeNaissance )
context Personne
def : ancestres ~: Set ( Personne ) = parents
-> union ( parents . ancestres - > asSet ())
Pierre
Grard
Introduction UML 2
212 /
342
Syntaxe des expressions
OCL est un langage simple d'expressions
constantes
identificateur
self
expr op expr
exprobjet.propobjet
exprobjet.propobjet ( parametres )
exprcollection -> propcollection(parametres)
package::package::element
if cond then expr else expr endif
let var : type = expr in expr
Pierre
Grard
Introduction UML 2
213 /
342
Accs aux proprits et aux lments
. permet d'accder une proprit d'un objet

-> permet d'accder une proprit d'une collection
:: permet d'accder un lment d'un paquetage, d'une classe,
...
Des rgles permettent de mixer collections et objets
self . impots (1998) / self . enfants - > size ()
self . salaire () -100
self . enfants - > select ( sexe = Sexe :: masculin )
self . enfants - > isEmpty ()
self . enfants - > forall ( age >20)
self . enfants - > collect ( salaire ) - > sum ()
self . enfants . salaire - > sum ()
self . enfants - > union ( self . parents ) - > collect ( age )
Pierre
Grard
Introduction UML 2
214 /
342
Types entiers et rels
Integer
Real
Valeurs : 1, -5, 34, 24343, ...

Oprations : +, -, *, div, mod, abs, max, min
Valeurs : 1.5, 1.34, ...
Oprations : +, -, *, /, oor, round, max, min
Le type Integer est conforme au type Real
Pierre
Grard
Introduction UML 2
215 /
342
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)
if age <40 then salaire > 1000
else salaire > 2000 endif
salaire > ( if age <40 then 1000 else 2000 endif )
Pierre
Grard
Introduction UML 2
216 /
342
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
Pierre
Grard
Introduction UML 2
217 /
342
Utilisation des valeurs de types numrs
Jour::Mardi
not #Mardi avant UML2.0
Oprations
=, <>
Pas de relation d'ordre
epouse - > notEmpty ()

implies epouse . sexe = Sexe :: Feminin
Pierre
Grard
Introduction UML 2
218 /
342
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
Pierre
Grard
Introduction UML 2
219 /
342
Collections
Ensembles : Set(T)
Elments unique non ordonns
Ensembles ordonns : OrderedSet(T)

Elments uniques et ordonns
Sac : Bag(T)
Elments rptables sans ordre
Sequence : Sequence(T)
Elments rptables mais ordonns
Collection est le type de base Collection(T)
Pierre
Grard
Introduction UML 2
220 /
342
Oprations de base sur les collections

Cardinalit : coll -> size()
Vide : coll -> isEmpty()
Non vide : coll -> nonEmpty()
Nombre d'occurrences : coll -> count(elem)
Appartenance : coll -> includes( elem )
Non appartenance : coll -> excludes( elem )
Inclusion : coll -> includesAll(coll)
Exclusion: coll -> excludesAll(coll)
Somme des lements : coll -> sum()
Pierre
Grard
Introduction UML 2
221 /
342
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()
Pierre
Grard
Introduction UML 2
222 /
342
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 )
Pierre
Grard
Introduction UML 2
223 /
342
Autres syntaxes pour le ltrage

Il est galement possible de
nommer la variable
d'expliciter son type
self . employe - > select ( age > 50)

self . employe - > select ( p | p . age >50 )
self . employe - > select ( p : Personne | p . age >50)
self . employe - > reject ( p : Personne | p . age <=50)
Pierre
Grard
Introduction UML 2
224 /
342
Quanticateurs
ForAll est le quanticateur universel

coll -> forAll( cond )
Exists est le quanticteur existentiel

coll -> exists( cond )
self . enfants - > forall ( age <10)

self . enfants - > exists ( sexe = Sexe :: Masculin )
Il est possible
de nommer la variable
d'expliciter son type
de parcourir plusieurs variables la fois
self . enfants
-> exists ( e1 , e2 | e1 . age = e2 . age and e1 < > e2 )
Pierre
Grard
Introduction UML 2
225 /
342
Unicit
Retourne vrai si pour chaque valeur de la collection, l'expression

retourne une valeur dirente
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
Pierre
Grard
Introduction UML 2
226 /
342
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 )
Pierre
Grard
Introduction UML 2
227 /
342
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
Pierre
Grard
Introduction UML 2
228 /
342
Conservation de l'imbrication pour la navigation

L'opration collect met plat les collections
utile pour naviger
enfants . enfants . prenom

= enfants - > collect ( enfants ) - > collect ( prenom )
= Bag \{ ' pierre ' , ' paul ' , ' marie ' , ' paul '}
CollectNested permet de conserver l'imbrication

enfants - > collectNested ( enfants . prenom )
= Bag { Bag { ' pierre ' , ' paul '} ,
Bag \{ ' marie ' , ' paul '}}
Pierre
Grard
Introduction UML 2
229 /
342
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 )
Pierre
Grard
Introduction UML 2
230 /
342
Ordre vs. Tri
Collections ordonnes
Sequence
OrderedSet
. . . mais pas forcment tries
Squence simple (l'ordre compte) :

Sequence { 12, 23, 5, 5, 12 }
Squence trie :
Sequence { 5, 5, 12, 12, 23 }
Pierre
Grard
Introduction UML 2
231 /
342
Tri d'une collection
Pour trier une collection en fonction d'une expression
coll -> sortedBy(expr)

L'opration < doit tre dnie sur le type correspond expr
enfants - > sortedBy ( age )
let ages = enfants . age -> sortedBy ( a | a ) in
ages . last () - ages . first ()
enfants - > sortedBy ( enfants - > size ()) - > last ()
Le rsultat est de type
OrderedSet si l'opration est applique sur un Set

Sequence si l'opration est applique sur un Bag
Pierre
Grard
Introduction UML 2
232 /
342
Plan
Pierre

Grard
Introduction UML 2
233 /
342
Automates
Un automate tats nis est la spcication de la squence d'tats

que subira un objet au cours de son cycle de vie.
Un tel automate reprsente le comportement d'un classeur dont les
sorties
ne dpendent pas seulement de ses entres,
mais aussi d'un historique des sollicitations passes.
Cet historique est caractris par un tat.

Les objets changent d'tat en rponse des vnements extrieurs
donnant lieu des transitions entre tats.
Sauf cas particuliers, chaque instant, chaque objet est dans un et un
seul tat.
Pierre
Grard
Introduction UML 2
234 /
342
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 embotement et concurrence et pas seulement des
automates tats nis comme dans les premires versions d'UML
Pierre
Grard
Introduction UML 2
235 /
342
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.
Pierre
Grard
Introduction UML 2
236 /
342
Exemple de diagramme d'tats-transitions
Pierre
Grard
Introduction UML 2
237 /
342
Etat initial et tat nal
L'tat initial est un pseudo-tat qui dnit le point de dpart par

dfaut pour l'automate ou le sous-tat.
Lorsqu'un objet est cr, il entre dans l'tat initial.
L'tat nal est un pseudo-tat qui indique que l'excution de
l'automate ou du sous-tat est termine.
Pierre
Grard
Introduction UML 2
238 /
342
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 implicitement 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.
L'vnement dclencheur est indiqu cte de la che reprsentant la

transition
Pierre
Grard
Introduction UML 2
239 /
342
Evnements call et signal
Un vnement de type call ou signal est dclar ainsi :

nomEvenement ( params )
Chaque paramtre a la forme :

param : ClasseParam
Les vnements de type call sont des mthodes dclares au niveau du

Les signaux sont dclars par la dnition d'une classe portant le
strotype signal, ne fournissant pas d'oprations, et dont les attributs
sont interprts comme des arguments.
Pierre
Grard
Introduction UML 2
240 /
342
Evnements change et after
Un vnement de type change est introduit de la faon suivante :

when ( conditionBooleenne )
Il prend la forme d'un test continu et se dclenche potentiellement
chaque changement de valeurs des variables intervenant dans la
condition.
Un vnement temporel de type after est spci par :

after ( duree )
Le paramtre s'value comme une dure, par dfaut coule depuis

l'entre dans l'tat courant.
Par exemple : after(10 secondes).
Pierre
Grard
Introduction UML 2
241 /
342
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 transition,
L'activit dsigne des instructions eectuer au moment du tir.
Pierre
Grard
Introduction UML 2
242 /
342
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.
Pierre
Grard
Introduction UML 2
243 /
342
Simplication avec les points de jonction
Pour emprunter un chemin, toutes les gardes le long de ce chemin

doivent s'valuer vrai ds le franchissement du premier segment.
Pierre
Grard
Introduction UML 2
244 /
342
Simplication avec les points de jonction
Pierre
Grard
Introduction UML 2
244 /
342
Reprsentation d'alternatives
avec les points de jonction
Pierre
Grard
Introduction UML 2
245 /
342
Utilisation des points de choix
Les gardes aprs le point de choix sont values au moment o il

est atteint.
Cela permet de baser le choix sur des rsultats obtenus en franchissant

le segment avant le point de choix.
Si, quand le point de choix est atteint, aucun segment en aval n'est
franchissable, le modle est mal form.
Contrairement aux points de jonction, les points de choix ne sont pas de simples
racourcis d'criture.
Pierre
Grard
Introduction UML 2
246 /
342
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/.
Pierre
Grard
Introduction UML 2
247 /
342
Dclencheurs de transitions internes prdnis

entry dnit une activit eectuer chaque fois que l'on rentre
dans l'tat considr.
exit dnit une activit eectuer quand on quitte l'tat.
do dnit une activit continue qui est ralise tant que l'on se
trouve dans l'tat, ou jusqu' ce que le calcul associ soit termin.
On pourra dans ce dernier cas grer l'vnement correspondant la n
de cette activit (completion event).
Pierre
Grard
Introduction UML 2
248 /
342
Reprsentation des transitions internes
Les transitions internes sont spcies dans le compartiment

infrieur de l'tat, sous le compartiment du nom.
Chaque transition interne est dcrite selon la syntaxe suivante :
nomEvenement ( params ) [ garde ] / activiteARealiser
Pierre
Grard
Introduction UML 2
249 /
342
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.
Pierre
Grard
Introduction UML 2
250 /
342
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.
Pierre
Grard
Introduction UML 2
250 /
342
Etats composites et tats initiaux/naux

Les transitions peuvent avoir pour cible la frontire d'un tat
composite. Elle sont alors quivalentes une transition ayant pour
cible l'tat initial de l'tat composite.
Une transition ayant pour source la frontire d'un tat composite
est quivalente une transition qui s'applique tout sous-tat de
l'tat composite source.
Cette relation est transitive et peut traverser plusieurs niveaux
d'imbrication.
Pierre
Grard
Introduction UML 2
251 /
342
Etats composites et transitions internes

Depuis Etat11, quand event survient
On produit la squence d'activits QuitterE11, QuitterE1, action1,

EntrerE2, Entrer21, initialiser, Entrer22
L'objet se trouve alors est dans Etat22.
Pierre
Grard
Introduction UML 2
252 /
342
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'imbrication.
Pierre
Grard
Introduction UML 2
253 /
342
Interface des tats composites

Pour pouvoir reprsenter
un sous tat
indpendamment d'un
macro-tat, on a recours
des points de connexion.
Avec un X pour les
points de sortie
Vides pour les points
d'entre
Ces interfaces permettent

d'abstraire les sous-tats
des macro-tats
(rutilisabilit).
Pierre
Grard
Introduction UML 2
254 /
342
Etat concurrent
Avec un sparateur en pointills, on peu reprsenter plusieurs

automates s'excutant indpendamment.
Un objet peut alors tre simultanment dans plusieurs tats
concurrents.
Pierre
Grard
Introduction UML 2
255 /
342
Transition concurrente
Une transition fork correspond la cration de deux tats

concurrentes.
Une transition join correspond une barrire de synchronisation qui
supprime la concurrence.
Pour pouvoir continuer leur excution, toutes les tches concurrentes

doivent pralablement tre prtes franchir la transition.
Pierre
Grard
Introduction UML 2
256 /
342
Plan
Pierre

Grard
Introduction UML 2
257 /
342
Modlisation des traitements
Les diagrammes d'activit orent une manire graphique et non

ambigu pour modliser les traitements.
Comportement d'une mthode
Droulement d'un cas d'utilisation
Une activit reprsente une excution d'un mcanisme, un

droulement d'tapes squentielles. Le passage d'une activit l'autre
autre est matrialis par une transition.
Ces diagrammes sont assez semblables aux tats-transitions mais avec
une interprtation dirente.
Pierre
Grard
Introduction UML 2
258 /
342
Une vision transversale des traitements

Les diagrammes d'tats-transitions sont dnis pour chaque classeur
et n'en font pas intervenir plusieurs.
A l'inverse, les diagrammes d'activit permettent une description
s'aranchissant (partiellement) de la structuration de l'application en
classeurs.
La vision des diagrammes d'activits se rapproche des langages de
programmation imprative (C, C++, Java)
Les tats reprsentent des calculs
Il n'y a pas d'vnements externes mais des attentes de ns de calculs
Il peut y avoir de la concurrence entre activits
Pierre
Grard
Introduction UML 2
259 /
342
Exemple de diagramme d'activits
Pierre
Grard
Introduction UML 2
260 /
342
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 composites.
Pierre
Grard
Introduction UML 2
261 /
342
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 dclencher (l'activit cible).
Contrairement aux activits, les transitions sont franchies de manire
atomique, en principe sans dure perceptible.
Les transitions spcient l'enchanement des traitements et dnissent le

ot de contrle.
Pierre
Grard
Introduction UML 2
262 /
342
Structure de contrle conditionnelle

Expression de conditions au moyen de transitions munies de gardes
conditionnelles
Ces transitions ne peuvent tre empruntes que si la garde est vraie.

On dispose d'une clause [else] qui est valide si et seulement si toutes
les autres gardes des transitions ayant la mme source sont fausses.
Les conditions sont notes entre crochets

Pour mieux mettre en vidence un branchement conditionnel, on peut
utiliser les points de choix (losanges).
Les points de choix montrent un aiguillage du ot de contrle.
Pierre
Grard
Introduction UML 2
263 /
342
Exemples de structures conditionnelles
Pierre
Grard
Introduction UML 2
264 /
342
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.
Pierre
Grard
Introduction UML 2
265 /
342
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.
Pierre
Grard
Introduction UML 2
266 /
342
Partitions multidimensionnelles
Pierre
Grard
Introduction UML 2
267 /
342
Partitions explicites
Cette notation est moins encombrante graphiquement

Toutefois, elle met moins bien en valeur l'appartenance de groupes
d'activits un mme conteneur.
Pierre
Grard
Introduction UML 2
268 /
342
Arguments et valeurs retournes
Les diagrammes d'activits prsents jusqu'ici montrent bien le

comportement du ot de contrle.
Pourtant, le ot de donnes n'apparat pas.
Si une activit est bien adapte la description d'une opration d'un

classeur, il faut un moyen de spcier les arguments et valeurs de
retour de l'opration. C'est le rle
des pins,
des noeuds,
des ots d'objets associs.
Pierre
Grard
Introduction UML 2
269 /
342
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
Pierre
Grard
Introduction UML 2
270 /
342
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.
Un noeud d'objets permettent de mieux mettre en valeur les

donnes.
C'est un conteneur typ qui permet le transit des donnes.
Pierre
Grard
Introduction UML 2
271 /
342
Annotation des ots de donnes
Un ot d'objets peut porter une tiquette mentionnant deux

annotations particulires :
transformation indique une interprtation particulire de la
donne transmise par le ot.

indique l'ordre dans lequel les objets sont choisis dans
le noeud pour le quitter.
selection
Pierre
Grard
Introduction UML 2
272 /
342
Concurrence
Les diagrammes d'activits permettent en principe de reprsenter des

activits squentielles.
Nanmoins, on peut reprsenter des activits concurrentes avec :
Les barres de synchronisation,
Les noeuds de contrle de type ow nal .
Pierre
Grard
Introduction UML 2
273 /
342
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 transition 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 transition 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.
Pierre
Grard
Introduction UML 2
274 /
342
Noeud de contrle de type ow nal

Un ot de contrle qui atteint un noeud de contrle de type ow
nal est dtruit.
Les autres ots de contrle ne sont pas aects.
Ce type de noeud est moins fort qu'un noeud de contrle nal.

Dans ce cas, tous les autres ots de contrle de l'activit sont
interrompus et dtruits.
Pierre
Grard
Introduction UML 2
275 /
342
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
diagrammes d'activit.
Pierre
Grard
Introduction UML 2
276 /
342
Actions de communication
Les actions de type call correspondent des appels de procdure ou

de mthode.
Call operation correspond l'appel d'une opration sur un classeur.
Call behavior correspond l'invocation d'un comportement spci
l'aide d'un diagramme UML
Dans les deux cas, il est possible de spcier des arguments et
d'obtenir des valeurs en retour.
Les actions accept call et reply peuvent tre utilises du ct

rcepteur pour dcomposer la rception de l'appel.
Pierre
Grard
Introduction UML 2
276 /
342
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.
Pierre
Grard
Introduction UML 2
277 /
342
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 .
Pierre
Grard
Introduction UML 2
278 /
342
Exemple de traitement d'exceptions
Pierre
Grard
Introduction UML 2
279 /
342
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.
Pierre
Grard
Introduction UML 2
280 /
342
Exemple de rgion interruptible
Pierre
Grard
Introduction UML 2
281 /
342
Types de zones d'expansion

Parallel
Les excutions de l'activit interne sur les lments de la collection sont

indpendantes et peuvent tre ralises dans n'importe quel ordre ou
mme simultanment.
Iterative
Les occurrences d'excution de l'activit interne doivent s'enchaner

squentiellement, en suivant l'ordre de la collection d'entre.
Stream
Les lments de la collection sont passs sous la forme d'un ux de

donnes l'activit interne, qui doit tre adapte aux traitements de
ux.
Pierre
Grard
Introduction UML 2
282 /
342
Plan
Pierre

Grard
Introduction UML 2
283 /
342
Diagrammes de squence
Les diagrammes de squence permettent de modliser l'change

d'informations entre dirents classeurs
Ils sont un type de diagrammes d'interaction
Pierre
Grard
Introduction UML 2
284 /
342
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 contraintes de temps, comme les systmes temps rel.
Pierre
Grard
Introduction UML 2
285 /
342
Diagrammes de squence et de communication
Pierre
Grard
Introduction UML 2
286 /
342
Diagrammes de squence et de communication
Pierre
Grard
Introduction UML 2
286 /
342
Rles et connecteurs
Le rle permet de dnir le contexte d'utilisation de l'interaction.

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 >
Pierre
Grard
Introduction UML 2
287 /
342
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.
Pierre
Grard
Introduction UML 2
288 /
342
Reprsentation des messages

Les ches reprsentant les messages
sont traces ct des connecteurs
qui les supportent.
Attention
Bien faire la distinction entre les messages

et les connecteurs : on pourrait avoir un
connecteur sans message, mais jamais
l'inverse.
Pierre
Grard
Introduction UML 2
289 /
342
Implmentation de messages synchrones

public class Conducteur {
private Voiture voiture ;
public void addVoiture ( Voiture voiture ){
if ( voiture != null ){
this . voiture = voiture ;
}
}
public void conduire (){
voiture . demarrer ();
}
public static void main ( String [] argv ){
conducteur . conduire ();
}
}
public class Voiture {
public void demarrer (){...}
}
Pierre
Grard
Introduction UML 2
290 /
342
Numros de squence des messages
Pour reprsenter les aspects temporels, on adjoint des numros de

squence aux messages.
Des messages successifs sont ordonns selon un numro de squence

croissant (1, 2, 3, ... ou encore 3.1, 3.2, 3.3, ...).
Des messages envoys en cascade (ex : appel de mthode l'intrieur
d'une mthode) portent un numro d'embotement avec une notation
pointe
1.1, 1.2, ... pour des messages appels par une mthode dont l'appel
portait le numro 1
2.a.1, 2.a.2, ... pour des messages appels par une mthode dont
l'appel portait le numro 2.a
Pierre
Grard
Introduction UML 2
291 /
342
Equivalence avec un diagramme de squence
Pierre
Grard
Introduction UML 2
292 /
342
Equivalence avec un diagramme de squence
Pierre
Grard
Introduction UML 2
292 /
342
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
Pierre
Grard
Introduction UML 2
293 /
342
Oprateurs de choix et de boucles
Pas d'oprateurs combins dans les diagrammes de communication

*[<clauseItration>] reprsente une itration.
La clause d'itration peut tre exprime dans le format i:=1..n

Si c'est une condition boolenne, celle-ci reprsente la condition d'arrt
*[<clauseItration>] reprsente un choix. La clause de condition

est une condition boolenne.
Pierre
Grard
Introduction UML 2
294 /
342
Syntaxe des messages
Syntaxe complte des messages est :
numeroSquence [expression] : message

message a la mme forme que dans les diagrammes de squence ;
numroSquence reprsente le numro de squencement des
messages ;
expression prcise une itration ou un embranchement.
Exemples :
2 : affiche(x,y) : message simple.

1.3.1 : trouve("Hadock") : appel embot.
4 [x < 0] : inverse(x,couleur) : conditionnel.
3.1 *[i:=1..10] : recommencer() : itration.
Pierre
Grard
Introduction UML 2
295 /
342
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 compartiments.
Le compartiment suprieur contient le nom de la collaboration ayant

pour syntaxe :
< nomRole >: < nomType >[ < multiplicite >]

Le compartiment infrieur montre les participants la collaboration.
Pierre
Grard
Introduction UML 2
296 /
342
Exemple de collaboration
Pierre
Grard
Introduction UML 2
297 /
342
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.
Pierre
Grard
Introduction UML 2
298 /
342
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
Pierre
Grard
Introduction UML 2
299 /
342
Plan
Pierre

Grard
Introduction UML 2
300 /
342
Composant
Un composant logiciel est une unit logicielle autonome au sein d'un

systme global ou d'un sous-systme.
C'est un classeur structur particulier, muni d'une ou plusieurs
interfaces requises ou oertes.
Pierre
Grard
Introduction UML 2
301 /
342
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
entre leurs interfaces.
dpendances
Le cblage interne d'un composant est spci par les connecteurs

Un tel connecteur connecte un port externe du
composant avec un port de l'un de ses sous-composants internes.
de dlgation.
Pierre
Grard
Introduction UML 2
302 /
342
Exemple de modlisation d'un composant
Pierre
Grard
Introduction UML 2
303 /
342
Intrt des diagrammes de composants

Les diagrammes de composants permettent de
Structurer une architecture logicielle un niveau de granularit

moindre que les classes
Les composants peuvent contenir des classes.
Spcier l'intgration de briques logicielles tierces (composants EJB,

CORBA, COM+ ou .Net, WSDL...) ;
Identier les composants rutilisables.
Un composant est un espace de noms qu'on peut employer pour

organiser les lments de conception, les cas d'utilisation, les
interactions et les artefacts de code.
Pierre
Grard
Introduction UML 2
304 /
342
Architecture matrielle
En dernier lieu, un systme doit s'excuter sur des ressources

matrielles dans un environnement 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.
L'environnement d'excution ou les ressources matrielles sont appels

noeuds .
Les parties d'un systme qui s'excutent sur un noeud sont appeles
artefacts .
Pierre
Grard
Introduction UML 2
305 /
342
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.
Pierre
Grard
Introduction UML 2
306 /
342
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.
Pierre
Grard
Introduction UML 2
307 /
342
Instanciation de noeuds et d'artefacts
Les noms des instances de noeuds et d'artefacts sont souligns.
Pierre
Grard
Introduction UML 2
308 /
342
Excution des composants
On utilise des ches de dpendance pour montrer la capacit

d'un noeud prendre en charge un type de composant.
Pierre
Grard
Introduction UML 2
309 /
342
Plan
Design Patterns
Pierre
Design Patterns
Grard
Introduction UML 2
310 /
342
Design Patterns
Un concept issu de l'architecture

Christopher Alexander, architecte, dnit en 1977 les patrons de
conception comme
La description d'un problme rmanent et de sa solution

Une solution pouvant tre utilise des millions de fois sans tre deux
fois identique
Une forme de conception, pattern, modle, patron de conception
Ce concept attire les chercheurs en COO ds les annes 80

Design Patterns of Reusable Object-Oriented
GOF : Erich Gamma, Richard Helm, Ralph Johson et John Vlissides
Addison-Wesley, 1995
Pierre
Grard
Introduction UML 2
311 /
342
Design Patterns
Patron de conception logicielle
Un patron de conception (design pattern) est la description d'une

solution classique un problme rcurent.
Il dcrit une partie de la solution. . .
avec des relations avec le systme et les autres parties.
C 'est une technique d 'architecture logicielle.
Ce n'est pas
Une brique : l'application d'un pattern dpend de l'environnement

Une rgle : un pattern ne peut pas s'appliquer mcaniquement
Une mthode : ne guide pas une prise de dcision ; un pattern est la
dcision prise
Pierre
Grard
Introduction UML 2
312 /
342
Design Patterns
Documentation d'un patron de conception

Les principaux lments de description d'un pattern sont :
Le nom du pattern rsume le problme de design.
Son intention est une courte description des objectifs du pattern, de sa
raison d'tre.
Les indication d'utilisation dcrivent les cas o le pattern peut tre
utile.
La motivation montre un cas particulier dans lequel le patron peut
tre utilis.
La structure est une reprsentation graphique des classes du modle.
Attention
Dans l'ouvrage du GOF (et ce cours), utilisation d'OMT, anctre d'UML
Pierre
Grard
Introduction UML 2
313 /
342
Design Patterns
Avantages des patrons de conception

Capitalisation de l'exprience : rutilisation de solutions qui ont
prouv leur ecacit
Rendre la conception beaucoup plus rapide
Elaboration de constructions logicielles de meilleure qualit

grce un niveau d'abstraction plus lev
Rduction du nombre d'erreurs, d'autant que les patrons sont examins

avec attention avant d'tre publis
Communication plus aise
Ecrire du code facilement comprhensible par les autres
Apprentissage en suivant de bons exemples
Pierre
Grard
Introduction UML 2
314 /
342
Design Patterns
Inconvnients des patrons de conception

Ncessit d'un eort de synthse consquent
Reconnatre, abstraire. . .
Ncessit d'un apprentissage et d'exprience

Les patterns se dissolvent en tant utiliss
Les patrons sont nombreux (23 dans l'ouvrage du GOF, d'autres sont
publis rgulirement)
Lesquels sont semblables ?
Les patrons sont parfois de niveaux dirents : certains patterns s
'appuient sur d 'autres...
Pierre
Grard
Introduction UML 2
315 /
342
Design Patterns
Catgories de patrons de conception

Patrons de cration
Ils dnissent comment faire l'instanciation et la conguration des

classes et des objets.
Patrons de structure
Ils dnissent l'usage des classes et des objets dans des grandes
structures ainsi que la sparation entre l'interface et l'implmentation.
Patrons de comportement
Ils dnissent la manire de grer les algorithmes et les divisions de

responsabilits.
Pierre
Grard
Introduction UML 2
316 /
342
Design Patterns
Classication des patrons du GOF

Cration :
Objets : Abstract factory, Builder, Prototype, Singleton

Classes : Factory method
Structure :
Objets : Adapter, Bridge, Composite, Decorator, Facade, Flyweight,

Proxy
Classes : Adapter
Comportement :
Objets : Chain of responsability, Command, Iterator, Memento,

Observer, State, Strategy
Classes : Interpreter, Template method
Pierre
Grard
Introduction UML 2
317 /
342
Creational patterns
Design Patterns
Formes de cration pour :
Abstraire le processus d'instanciation des objets.

Rendre indpendant de la faon dont les objets sont crs, composs,
assembls, reprsents.
Encapsuler la connaissance de la classe concrte qui instancie.
Cacher ce qui est cr, qui cre, comment et quand.
Pierre
Grard
Introduction UML 2
318 /
342
Design Patterns
Exemples de Creational patterns
AbstractFactory pour passer un paramtre la cration qui dnit ce
que l'on va crer

Builder pour passer en paramtre un objet qui sait construire l'objet
partir d'une description
FactoryMethod pour que la classe sollicite appelle des mthode
abstraites
Prototype : des prototypes varis existent qui sont copis et assembls
Singleton pour garantir qu'il n'y ait qu'une seule instance de la classe
Pierre
Grard
Introduction UML 2
319 /
342
Singleton
Design Patterns
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.
Motivation :
Spooler d'impression, gestionnaire d'achage

Gnrateur de nombres alatoires avec graine
Pierre
Grard
Introduction UML 2
320 /
342
Singleton : Structure
Pierre
Grard
Design Patterns
Introduction UML 2
321 /
342
Design Patterns
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 .
Pierre
Grard
Introduction UML 2
322 /
342
Structural patterns
Design Patterns
Formes de structure :
Comment les objets sont assembls

Les patterns sont complmentaires les uns des autre
Pierre
Grard
Introduction UML 2
323 /
342
Design Patterns
Exemples de Structural patterns
Adapter pour rendre un objet conforme un autre

Bridge pour lier une abstraction une implantation
Composite : bas sur des objets primitifs et composants
Decorator pour ajouter des services un objet
Facade pour cacher une structure complexe
Flyweight pour de petits objets destins tre partags
Proxy quand un objet en masque un autre
Pierre
Grard
Introduction UML 2
324 /
342
Adapter
Design Patterns
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 escompte.
On souhaite crer une classe rutilisable qui collaborera avec des
classes encore inconnues, mais qui n'auront pas ncessairement
l'interface escompte
Pierre
Grard
Introduction UML 2
325 /
342
Adapter : Motivation
Pierre
Grard
Design Patterns
Introduction UML 2
326 /
342
Adapter : Structure
Pierre
Grard
Design Patterns
Introduction UML 2
327 /
342
Bridge
Design Patterns
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 consquence sur le code client (pas de recompilation)
Pierre
Grard
Introduction UML 2
328 /
342
Bridge : Motivation
Pierre
Grard
Design Patterns
Introduction UML 2
329 /
342
Bridge : Motivation
Pierre
Grard
Design Patterns
Introduction UML 2
329 /
342
Bridge : Structure
Pierre
Grard
Design Patterns
Introduction UML 2
330 /
342
Composite
Design Patterns
Intention :
Composition d'objets en structures arborescentes pour reprsenter des

structures composant/compos.
Permettre au client de traiter de la mme manire les objets atomiques
et les combinaisons 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
Pierre
Grard
Introduction UML 2
331 /
342
Composite : Motivation
Pierre
Grard
Design Patterns
Introduction UML 2
332 /
342
Composite : Motivation
Pierre
Grard
Design Patterns
Introduction UML 2
332 /
342
Composite : Structure
Pierre
Grard
Design Patterns
Introduction UML 2
333 /
342
Behavioural patterns
Design Patterns
Formes de comportement pour dcrire :
des algorithmes
des comportements entre objets
des formes de communication entre objet
Pierre
Grard
Introduction UML 2
334 /
342
Design Patterns
Exemples de Behavioural patterns

Chain of
Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
Pierre
Grard
Pour plus de dtails, lire
Design Patterns.
Catalogue de modles de
conception rutilisables.
Richard Helm, Ralph
Johnson, John Lissides,
Eric Gamma
UML 2 et les Dseign

Patterns
Craig Larman, M.C.

Baland, L. Carite, E.
Burr
Introduction UML 2
335 /
342
Observer
Design Patterns
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.
Pierre
Grard
Introduction UML 2
336 /
342
Observer Motivation
Pierre
Grard
Design Patterns
Introduction UML 2
337 /
342
Observer Structure
Pierre
Grard
Design Patterns
Introduction UML 2
338 /
342
Strategy
Design Patterns
Intention :
Dnir une famille d'algorithmes en encapsulant chacun d'eux et en les

rendant interchangeables.
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.
Pierre
Grard
Introduction UML 2
339 /
342
Strategy : Motivation
Pierre
Grard
Design Patterns
Introduction UML 2
340 /
342
Strategy : Structure
Pierre
Grard
Design Patterns
Introduction UML 2
341 /
342
Design Patterns
Utilisation des design patterns
Les design patterns ne sont que des lments de conception

On les combine pour produire une conception globale de qualit
Trouver les bons objets
Mieux rutiliser, concevoir
pour l'volution
Abuser des patrons de conception peut parfois nuire la lisibilit des solutions de
conception proposes
On peut aussi produire de nouveaux design patterns
Les DP du GOF ne sont pas les seuls, par exemple :

Architecture 3-tiers
Modle Vue Contrleur (MVC) : Combinaison de Composite,
et Strategy
Observer
On trouve sans trop de mal des bibliothques de patterns sur Internet

Pierre
Grard
Introduction UML 2
342 /
342

Uml Cours Slides

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Uml Cours Slides

Transféré par

Droits d'auteur :

Formats disponibles

Introduction UML 2

Modlisation Oriente Objet de Systmes Logiciels

DUT Informatique  S2D

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

Introduction la Modlisation Oriente Objet

Modlisation objet lmentaire avec UML

Modlisation avance avec UML

Bonnes pratiques de la modlisation objet

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

 UML 2.0, guide de rfrence 

James Rumbaugh, Ivar Jacobson, Grady Booch

Benot Charoux, Aomar Osmani, Yann Thierry-Mieg

 UML 2.0 Superstructure  et  UML 2.0 Infrastructure 

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

 UML 2.0 Object Constraint Language (OCL) 

Cours de Jean-Marie Favre, IMAG

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

Depuis quelques annes, la fabrication du matriel est assure par

Les problmes lis l'informatique sont essentiellement des problmes de

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

tude sur 8 380 projets (Standish Group, 1995) :

Le taux de succs dcrot avec la taille des projets et la taille des

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

Critres de qualit d'un logiciel

Adquation entre le logiciel et les besoins des utilisateurs ;

Interactions avec d'autres logiciels ;

Un logiciel ne s'use pas pourtant, la maintenance absorbe une trs

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

La qualit du processus de fabrication est garante de la qualit du produit.

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

Dterminer les fonctionnalits du logiciel.

Dterminer la faon dont dont le logiciel fournit les direntes

Essayer le logiciel sur des donnes d'exemple pour s'assurer qu'il

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

Un modle est une reprsentation abstraite de la ralit qui exclut

Il permet de rduire la complexit d'un phnomne en liminant les

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

La smantique des concepts ;

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

UML 2.0, guide de rfrence

UML 2.0 Superstructure et UML 2.0 Infrastructure

(P13 IUT Villetaneuse)

DUT Informatique S2D

UML 2.0 Object Constraint Language (OCL)

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

Dterminer la faon dont dont le logiciel fournit les direntes

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

Des langages dirents niveaux de formalisation

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

Unied Modeling Language

Ociellement UML est n en 1994.

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D