Uml Cours Slides PDF

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 DUT Informatique S2D 1 / 342
Introduction la Modlisation Oriente Objet
Plan
1 Introduction la Modlisation Oriente Objet

2 Modlisation objet lmentaire avec UML
3 UML et mthododologie
4 Modlisation avance avec UML
5 Bonnes pratiques de la modlisation objet
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).
Bibliographie OCL
UML 2.0 Object Constraint Language (OCL)

OMG (Object Management Group)
www.uml.org (2004)
Cours de Jean-Marie Favre, IMAG
http://megaplanet.org/jean-marie-favre
Matriel et logiciel
Systmes informatiques :
80 % de logiciel ;
20 % de matriel.
Depuis quelques annes, la fabrication du matriel est assure par
quelques fabricants seulement.
Le matriel est relativement able.
Le march est standardis.
Les problmes lis l'informatique sont essentiellement des problmes de

logiciel.
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 ?
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.
Poids de la maintenance
Rartition Origine des Cot de la

eort dv. erreurs maintenance
Dnition 6% 56% 82%
des besoins
Conception 5% 27% 13%
Codage 7% 7% 1%
Intgration 15% 10% 4%
Tests
Maintenance 67%
(Zeltovitz, De Marco)
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.
Etapes du dveloppement
tude de faisabilit
Spcication
Dterminer les fonctionnalits du logiciel.
Conception
Dterminer la faon dont dont le logiciel fournit les direntes
fonctionnalits recherches.
Codage
Tests
Essayer le logiciel sur des donnes d'exemple pour s'assurer qu'il
fonctionne correctement.
Maintenance
Modlisation
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.
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.
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.
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.
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.
Modlisation objet lmentaire avec UML Diagrammes de cas d'utilisation
Plan
Diagrammes de cas d'utilisation
Diagrammes de classes
Diagrammes d'objets
Diagrammes de squences
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.
Exemple de diagramme de cas d'utilisation
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.
Acteurs et cas d'utilisation
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.
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).
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.
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.
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.
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.
Relations entre acteurs
Une seule relation possible : la gnralisation.
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.
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.
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.
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.
Description textuelle
Identication :
Nom du cas : Payer CB
Objectif : Dtailler les tapes permettant client de payer par carte
bancaire
Acteurs : Client, Banque (secondaire)
Date : 18/09
Responsables : Toto
Version : 1.0
Squencements :
Le cas d'utilisation commence lorsqu'un client demande le paiement
par carte bancaire
Pr-conditions
Le client a valid sa commande
Enchanement nominal
1 Le client saisit les informations de sa carte bancaire
2 Le systme vrie que le numro de CB est correct
3 Le systme vrie la carte auprs du systme bancaire
4 Le systme demande au systme bancaire de dbiter le client
5 Le systme notie le client du bon droulement de la transaction
Enchanements alternatifs
1 En (2) : si le numro est incorrect, le client est averti de l'erreur, et
invit recommencer
2 En (3) : si les informations sont errones, elles sont re-demandes au
client
Post-conditions
La commande est valide
Le compte de l'entreprise est crdit
Rubriques optionnelles
Contraintes non fonctionnelles :
Fiabilit : les accs doivent tre scuriss
Condentialit : les informations concernant le client ne doivent pas
tre divulgus
Contraintes lies l'interface homme-machine :
Toujours demander la validation des oprations bancaires
Modlisation objet lmentaire avec UML Diagrammes de classes
Plan
Diagrammes d'objets
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.
Exemple de diagramme de classes
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]
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.
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).
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
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
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))~;
}
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.
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.
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 * .
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.
Association unidirectionnelle de 1 vers 1
Implantation
public class Adresse {...}
public class Client {

private Adresse livraison ;
public void setAdresse ( Adresse adresse ){
this . livraison = adresse ;
}
public Adresse getAdresse (){
return livraison ;
}
}
Association bidirectionnelle de 1 vers 1
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
}
}
Association unidirectionnelle de 1 vers *
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 );
}
}
Implantation d'une association

bidirectionnelle de * vers *
Plus dicile : grer la fois la cohrence et les collections
Associations rexives
L'association la plus utilise est l'association binaire (reliant deux

classs).
Parfois, les deux extrmits de l'association pointent vers le mme
classeur. Dans ce cas, l'association est dite rexive .
Classe-association
Une association peut tre rane et avoir ses propres attributs, qui ne
sont disponibles dans aucune des classes qu'elle lie.
Comme, dans le modle objet, seules les classes peuvent avoir des
attributs, cette association devient alors une classe appele
classe-association .
Associations n-aires
Une association n-aire lie plus de deux classes.
Notation avec un losange central pouvant ventuellement accueillir une
classe-association.
La multiplicit de chaque classe s'applique une instance du losange.
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.
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.
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.
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.
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
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
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.
Exemple d'encapsulation
Les modicateurs d'accs sont galement applicables aux oprations.

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)
La classe
parent est la classe gnrale (ici Article)
La classe
Toutefois, elle n'a pas accs aux proprits prives.
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).
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.
Hritage multiple
Une classe peut avoir plusieurs classes parents. On parle alors

d'hritage multiple.
Le langage C++ est un des langages objet permettant son
implantation eective.
Java ne le permet pas.
Interface
Le rle d'une interface est de regrouper un ensemble d'oprations
assurant un service cohrent oert par un classeur et une classe en
particulier.
Une interface est dnie comme une classe, avec les mmes
compartiments. On ajoute le strotype interface avant le nom de
l'interface.
On utilise une relation de type ralisation entre une interface et une
classe qui l'implmente.
Les classes implmentant une interface doivent implmenter toutes les

oprations dcrites dans l'interface
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.
Exemple d'interface
Elments drivs
Les attributs drivs peuvent tre calculs partir d'autres attributs

et des formules de calcul.
Les attributs drivs sont symboliss par l'ajout d'un / devant leur
nom.
Lors de la conception, un attribut driv peut tre utilis comme
marqueur jusqu' ce que vous puissiez dterminer les rgles lui
appliquer.
Une association drive est conditionne ou peut tre dduite
partir d'autres autres associations. On utilise galement le symbole
/ .
Attributs de classe
Par dfaut, les valeurs des attributs dnis dans une classe dirent
d'un objet un autre. Parfois, il est ncessaire de dnir un attribut
de classe qui garde une valeur unique et partage par toutes les
instances.
Graphiquement, un attribut de classe est soulign
Oprations de classe
Semblable aux attributs de classe

Une opration de classe est une proprit de la classe, et non de ses
instances.
Elle n'a pas accs aux attributs des objets de la classe.
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
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)
Construction d'un diagramme de classes
1 Trouver les classes du domaine tudi ;

Souvent, concepts et substantifs du domaine.
2 Trouver les associations entre classes ;
Souvent, verbes mettant en relation plusieurs classes.
3 Trouver les attributs des 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 Organiser et simplier le modle en utilisant l'hritage ;
5 Tester les chemins d'accs aux classes ;
6 Itrer et raner le modle.
Modlisation objet lmentaire avec UML Diagrammes d'objets
Plan
Diagrammes d'objets
Objectif
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.
Reprsentation des 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).
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 :
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 :
Liens
Un lien est une instance d'une association.

Un lien se reprsente comme une association mais s'il a un nom, il est
soulign.
Attention
Naturellement, on ne reprsente pas les multiplicits qui n'ont aucun sens
au niveau des objets.
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.
Modlisation objet lmentaire avec UML Diagrammes de squences
Plan
Diagrammes d'objets
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).
Exemple d'interaction
Cas d'utilisation :
Diagramme de squences correspondant :
Exemple d'interaction
Diagramme de squences correspondant :
Oprations ncessaires dans le diagramme de classes :
Ligne de vie
Une ligne de vie reprsente un participant une interaction (objet ou
acteur).
nomLigneDeVie [ selecteur ]: nomClasseOuActeur
Dans le cas d'une collection de participants, un slecteur permet de
choisir un objet parmi n (par exemple objets[2]).
Messages
Les principales informations contenues dans un diagramme de

squence sont les messages changs entre les lignes de vie, prsents
dans un ordre chronologique.
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).
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 ).
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.
implantation des messages synchrones
class C {
class B {
op2 ( p : Type ){
C c;
...
op1 ( p : Type ){
}
c . op2 ( p );
op3 (){
c . op3 ();
...
}
}
}
}
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.
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.
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.
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)
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.
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.
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 ).
Exemple de fragment avec l'oprateur

conditionnel
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.
Oprateur de boucle
DUT Informatique S2D 100 /

Pierre Grard (P13 IUT Villetaneuse) Introduction UML 2 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 .

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.

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.

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

UML et mthododologie Des besoins au code avec UML : une mthode minimale
Plan
Des besoins au code avec UML : une mthode minimale
Rational Unied Process
eXtreme programming

Pourquoi une mthode ?

Processus de dveloppement
Ensemble d'tapes partiellement ordonnes, qui concourent l'obtention

d'un systme logiciel ou l'volution d'un systme existant.
Objectif : produire des logiciels
De qualit (qui rpondent aux besoins de leurs utilisateurs)
Dans des temps et des cots prvisibles
A chaque tape, on produit :
Des modles ;
De la documentation ;
Du code.

Mthode = Dmarche + Langage
La mthode MERISE fournit :

Un langage de modlisation graphique (MCD, MPD, MOT, MCT...)
ET 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.

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.

Mthode minimale
Objectif
Inspire de
UML 2 - Modliser une application web
Pascal Roques
Editions Eyrolles (2006)

Mthode minimale
Objectif

Cas d'utilsation
Comment dnir les besoins ?
1 Identier les limites du systme ;
2 Identier les acteurs ;
3 Identier les cas d'utilisation ;
4 Structurer les cas d'utilisation en packages ;
5 Ajouter les relations entre cas d'utilisation ;
6 Classer les cas d'utilisation par ordre d'importance.

Exemple de classement
Cas d'utilisation Priorit Risque

Ajouter article au panier Haute Moyen
Changer prix Article Moyen Moyen
Rechercher par mots-cls Bas Moyen
... etc ... ... etc ... ... etc ...
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.

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 Identier les concepts du domaine ;
2 Ajouter les associations et les attributs ;
3 Gnraliser les concepts ;
4 Structurer en packages : structuration selon les principes de cohrence
et d'indpendance.
Les concepts du domaine peuvent tre identis directement partir
de la connaissance du domaine ou par interview des experts mtier.
Exemple de modle du domaine

Structuration en packages

Squences systme
Les squences systme formalisent les descriptions textuelles des cas
d'utilisation, en utilisant des diagrammes de squence.
Construire les Diagrammes de Squences Systme implique

souvent la mise jour des cas d'utilisation la lumire des rexions
que nous inspirent la production des DSS.
Les DSS permettent de spcier les oprations systme.
Le systme est considr comme un tout :
On s'intresse ses interactions avec les acteurs ;
On utilise une classe Systme qui part les acteurs donnera
lieu la seule ligne de vie des DSS.
Un nouveau DSS est produit pour chacun des cas d'utilisation.

Les DSS sont parfois trs simples mais ils seront enrichis par la suite.
Exemple de diagramme de squence systme

Oprations systme
Les oprations systme sont des oprations qui devront tre ralises
par l'une ou l'autre des classes du systme.
Elles correspondent tous les messages qui viennent des acteurs vers
le systme dans les dirents DSS.
Classes participantes
Pour chaque cas d'utilisation, on dnit les classes d'analyse mises en

oeuvre pour sa ralisation eective.
Typologie des classes d'analyse :
Les classes mtier (ou entits) reprsentent les objets mtier. Elles
correspondent aux classes du modle du domaine.
Les classes de dialogue sont celles qui permettent les interactions
entre les acteurs et l'application.
Les classes de contrle permettent d'abstraire les fonctionnalits du
systme :
Elles font le lien entre les classes dialogue et les classes mtier.
Elles permettent de contrler la cinmatique de l'application, cad
l'ordre dans lequel les choses doivent se drouler.

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.
Exemple de diagramme de classes participantes

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.
Des squences systme aux interactions internes

Des squences systme aux interactions internes

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).
UML et mthododologie Rational Unied Process
Plan
eXtreme programming

Modles de cycles de vie linaire

Les phases du dveloppement se suivent dans l'ordre et sans retour en
arrire.

Modles de cycles de vie linaire

Les phases du dveloppement se suivent dans l'ordre et sans retour en
arrire.

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.

Production itrative d'incrments

Itrations 0
A chaque itration, on refait :

1 Spcication ;
2 Conception ;
3 Implmentation ;
4 Tests.

Itrations 1

1 Spcication ;
2 Conception ;
3 Implmentation ;
4 Tests.

Itrations 2

1 Spcication ;
2 Conception ;
3 Implmentation ;
4 Tests.

Itrations 3

1 Spcication ;
2 Conception ;
3 Implmentation ;
4 Tests.

Itrations 4

1 Spcication ;
2 Conception ;
3 Implmentation ;
4 Tests.

Itrations 5

1 Spcication ;
2 Conception ;
3 Implmentation ;
4 Tests.

Itrations 6

1 Spcication ;
2 Conception ;
3 Implmentation ;
4 Tests.

Itrations 7

1 Spcication ;
2 Conception ;
3 Implmentation ;
4 Tests.
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.
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.

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.

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.

RUP est centr sur l'architecture
Modlisation de direntes pespectives indpendantes et

complmentaires.
Architecture en couches et vues de Krutchen.

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.

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

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.

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.

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.

Phase d'laboration : objectifs
Dnir, valider et arrter l'architecture ;

Dmontrer l'ecacit de cette architecture rpondre notre besoin ;
Planier la phase de construction.

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.

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 ;

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.

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.

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.

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.

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.

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.

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.

Phase de transition : Livrables
La version nale du logiciel ;

Les manuels d'utilisation.

Phase de transition : Critres d'valuation
La satisfaction des utilisateurs ;

La situation nancire du projet en regard du budget initial.

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

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 ? )

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.

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.

Conception
Objectif : Modliser comment le systme va fonctionner :

Exigences non fonctionnelles ;
Choix technologiques.
Le systme est analys et on produit :
Une proposition d'architecture ;
Un dcoupage en composants.

Impmentation
Objectif : Implmenter le systme par composants.

Le systme est dvelopp par morceaux dpendant les uns des autres.
Optimisation de l'utilisation des ressources selon leurs expertises.
Les dcoupages fonctionnel et en couches sont indispensable pour
cette activit.
Il est tout fait envisageable de retoucher les modles d'analyse et de
conception ce stade.

Test
Objectif : Vrier des rsultats de l'implmentation en testant la

construction :
Tests unitaires : tests composants par composants ;
Tests d'intgration : tests de l'interaction de composants
pralablement tests 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.

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.

Importance des activits dans chaque phase

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 des classes, de squences ;
Diagramme tat/transition ;
Diagramme d'activit ;
Diagramme de dploiement et de composant.

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)

UML et mthododologie eXtreme programming
Plan
eXtreme programming

Mthodes agiles
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).

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.

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.

Valeurs d'XP
Communication :
XP favorise la communication directe, plutt que le cloisonnement des
activits et les changes de documents formels.
Les dveloppeurs travaillent directement avec la matrise d'ouvrage.
Feedback :
Les pratiques XP sont conues pour donner un maximum de feedback
sur le droulement du projet an de corriger la trajectoire au plus tt.
Simplicit :
Du processus ;
Du code.
Courage :
D'honorer les autres valeurs ;
De maintenir une communication franche et ouverte ;
D'accepter et de traiter de front les mauvaises nouvelles.

Pratiques d'XP
XP est fond sur des valeurs, mais surtout sur 13 pratiques rparties
en 3 catgories :
Gestion de projets ;
Programmation ;
Collaboration.

Pratiques de 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).
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.

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.

Cycle de vie XP

Exploration
Les dveloppeurs se penchent sur des questions techniques :

Explorer les direntes possibilits d'architecture pour le systme :
Etudier par exemple les limites au niveau des performances prsentes
par chacune des solutions possibles.
Le client s'habitue exprimer ses besoins sous forme de user strories
(proches de diagrammes de cas illustrs par des diagrammes de
squences).
Les dveloppeurs estiment les temps de dveloppement.

Planning
Planning de la premire release :

Uniquement les fonctionnalits essentielles ;
Premire release enrichir par la suite.
Dure du planning : 1 ou 2 jours.
Premire version (release) au bout de 2 6 mois.

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.

Mise en production
La mise en production produit un logiciel :

Orant toutes les fonctionnalits indispensables ;
Parfaitement fonctionnel ;
Mis disposition des utilisateurs.
Itrations trs courtes ;
Tests constants en parallle du dveloppement ;
Les dveloppeurs procdent des rglages ans pour amliorer les
performances du logiciel.

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

Mort
Quand le client ne parvient plus spcier de nouveaux besoins, le

projet est dit mort
Soit que tous les besoins possibles sont remplis ;
Soit que le systme ne supporte plus de nouvelles modications en
restsant rentable.

Equipe XP
Pour un travil en quipe, on distingue 6 rles principaux au sein d'une

quipe XP :
Dveloppeur ;
Client ;
Testeur ;
Tracker ;
Manager ;
Coach.

Dveloppeur
Conception et programmation, mme combat !

Participe aux sances de planication, value les tches et leur
dicult ;
Dnition des test unitaires ;
Implmentation des fonctionnalits et des tests unitaires.

Client
crit, explique et matrise les scnarios ;

Spcie les tests fonctionnels de recette ;
Dnit les priorits.

Testeur
criture des tests de recette automatiques pour valider les scnarios

clients ;
Peut inuer sur les choix du clients en fonction de la testatibilit
des scnarios.

Tracker
Suivre le planning pour chaque itration ;

Comprendre les estimations produites par les dveloppeurs concernant
leur charges ;
Interagir avec les dveloppeurs pour le respect du planning de
l'itration courante ;
Dtection des ventuels retards et rectications si besoin.

Manager
Suprieur hirarchique des dveloppeurs :

Responsable du projet.
Vrication de la satisfaction du client ;
Contrle le planning ;
Gestion des ressources.

Coach
Garant du processus XP :
Organise et anime les sances de planications ;
Favorise la crativit du groupe, n'impose pas ses solutions techniques ;
Coup de gueules. . .

Spcication avec XP
Pas de documents d'analyse ou de spcications dtailles.

Les tests de recette remplacent les spcications.
Emergence de l'architecture au fur et mesure du dveloppement.

XP vs RUP
Inconvnients de XP :
Focalisation sur l'aspect individuel du dveloppement, au dtriment
d'une vue globale et des pratiques de management ou de formalisation ;
Manquer de contrle et de structuration, risques de drive.
Inconvnients de RUP :
Fait tout, mais lourd, usine gaz ;
Parfois dicile mettre en oeuvre de faon spcique.
XP pour les petits projets en quipe de 12 max ;

RUP pour les gros projets qui gnrent beaucoup de documentation.

Modlisation avance avec UML Expression de contraintes avec OCL
Plan
Expression de contraintes avec OCL
Diagrammes d'tats-transitions
Digrammes d'activits
Diagrammes de communication
Diagrammes de composants et de dploiement

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

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

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.

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

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

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 )

Une carte bleue est accepte dans tous les

distributeurs des consortiums de la banque
context CarteBleue
inv : distributeur
= compte . banque . consortium . distributeur

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

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

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

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

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

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

Accs un attribut ou une mthode
Accs un attribut : objet.attribut

Ex : self.dateDeNaissance
Accs une mthode objet.operation(param1, ... )
Ex : self.impots(1998)

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}
X
Set(X)
OrderedSet(X)

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

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 ()

Navigation via une association qualie

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

lien . nomderole
b . compte [4029]
b . compte
compte

Invariant (inv)
Prdicat associ une classe ou une association

Doit tre vri tout instant
Le contexte est dni par un objet
Cet objet peut tre rfrenc par self
L'invariant peut tre nomm
context Personne
inv pasTropVieux ~: age < 110
inv ~: self . age >= 0

Exemples d'invariants
context Personne
inv ~: age >0 and self . age <110
inv mariageLegal ~: marie implies age > 16
inv enfantsOk ~: enfants - > size () < 20
inv ~: not enfants - > includes ( self )
inv ~: enfants - > includesAll ( filles )
inv ~: enfants - > forall ( e | self . age - e . age <14)

Pr-condition et post-condition
Prdicats associs une opration
pr-conditions doivent tre vries avant l'excution
Les
post-conditions sont vraies aprs l'excution
Les
self dsigne l'objet sur lequel l'opration lieu
Dans une post-condition :
@pre permet de faire rfrence la valeur avant que opration ne soit
eectue
result designe le resultat de l'opration
ocsIsNew() indique si un objet n'existait pas dans l'tat prcdent
context Classe :: operation (...): ClasseValRetour
pre nom1 ~: param1 < ...
post ~: ... result > ...

Exemples de pr et post-conditions
context Personne :: retirer ( montant : Integer )

pre ~: montant > 0
post ~: solde < solde@pre - montant
context Personne :: 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

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 )

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 ())

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

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 )

Types entiers et rels
Integer
Valeurs : 1, -5, 34, 24343, ...
Oprations : +, -, *, div, mod, abs, max, min
Real
Valeurs : 1.5, 1.34, ...
Oprations : +, -, *, /, oor, round, max, min
Le type Integer est conforme au type Real

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 )

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

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

Elments et singletons
Dans tout langage typ il faut distinguer

un lment e
du singleton contenant cet lment Set{e}
Pour simplier la navigation OCL, une conversion implicite est faite
lorsqu'une opration sur une collection est applique un lement
isol
elem->prop est quivalent Set{elem}->prop
self->size() = 1

Collections
Ensembles : Set(T)
Elments unique non ordonns
Ensembles ordonns : OrderedSet(T)
Elments uniques et ordonns
Sac : Bag(T)
Elments rptables sans ordre
Sequence : Sequence(T)
Elments rptables mais ordonns
Collection est le type de base Collection(T)

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()

Oprations ensemblistes
Union : ens->union(ens)
Dierence : ens1-ens2
Ajout d'un lment : ens->including(elem)
Suppression d'un lment : ens->excluding(elem)
Conversion vers une liste : ens->asSequence()
Conversion vers un sac : ens->asBag()
Conv.vers un ens. ord. : ens->asOrderedSet()

Filtrage
Select retient les lments vriant la condition

coll -> select( cond )
Reject limine ces lements
coll -> reject( cond )
Any slectionne l'un des lments vriant la condition
coll -> any( cond )
opration non dterministe
utile lors de collection ne contenant qu'un lment
retourne la valeur indnie si l'ensemble est vide
self . enfants - > select ( age >10 and sexe = Sexe :: Masculin )

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)

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 )

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

T-uples
Champs nomms, pas d'ordre entre les champs
Tuples (valeurs)
Tuple { x = -1.5 , y =12.6}
Tuple { y =12.6 , x = -1.5}
Tuple { y : Real =12.6 , x : Real = -1.5}
Tuple { nom = ' dupont ' , prenom = ' leon ' ,
age =43}
A partir d'UML 2.0
Dnition de types tuples
TupleType ( x : Real , y : Real )
TupleType ( y : Real , x : Real )
TupleType ( nom : String , prenom : String ,
age : Integer )

Collections imbriques
Collections imbriques
Jusqu' UML 2.0 pas de collections de collections car peu utilis et plus
complexe comprendre
Mise plat intuitive lors de la navigation
self . parents . parents
Mise plat par default li l'opration implicite collect
A partir de UML 2.0 imbrications arbitraires des constructeurs de types
Set ( Set ( Personne ))
Sequence ( OrderedSet ( Jour ))
Trs utile pour spcier des structures non triviales

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 '}}

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 )

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 }

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

Modlisation avance avec UML Diagrammes d'tats-transitions
Plan

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.

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

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.

Exemple de diagramme d'tats-transitions

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.

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

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.

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

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.

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.

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.
Simplication avec les points de jonction

Reprsentation d'alternatives
avec les points de jonction

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.

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

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

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

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.

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.

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.

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.

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.

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

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.

Modlisation avance avec UML Digrammes d'activits
Plan

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.

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

Exemple de diagramme d'activits

Activit
Les activits dcrivent un traitement.
Le ot de contrle reste dans l'activit jusqu' ce que les traitements
soient termins.
On peut dnir des variables locales une activit et manipuler les
variables accessibles depuis le contexte de l'activit (classe contenante
en particulier).
Les activits peuvent tre imbriques hirarchiquement : on parle alors
d'activits composites.

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.

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.

Exemples de structures conditionnelles

Activits structures
Les activits structures utilisent les structures de contrle usuelles

(conditionnelles et boucle) travers une syntaxe qui dpend de l'outil.
La syntaxe prcise de ces annotations pas dnie dans la norme UML.
Dans une activit structure, on dnit les arguments d'entre et les
sorties par des ches encadres.

Partitions
Pour modliser un traitement mettant en oeuvre plusieurs classeurs,
on peut spcier le classeur responsable de chaque activit.
Les partitions permettent d'attribuer les activits des lments
particuliers du modle.
Une partition peut elle-mme tre dcompose en sous-partitions.
Pour spcier qu'une activit est eectue par un classeur particulier,
on la positionne dans la partiction correspondante.

Partitions multidimensionnelles

Partitions explicites
Cette notation est moins encombrante graphiquement

Toutefois, elle met moins bien en valeur l'appartenance de groupes
d'activits un mme conteneur.

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.

Pin
Un pin reprsente un point de

connexion pour une action.
L'action ne peut dbuter que si l'on
aecte une valeur chacun de ses
pins d'entre.
Les valeurs sont passes par copie.
Quand l'activit se termine, une
valeur doit tre aecte chacun des
pibs de sortie

Flot de donnes
Un ot d'objets permet de passer des donnes d'une activit une
autre.
De fait, un arc qui a pour origine et destination un pin correspond un
ot de donnes.
Un noeud d'objets permettent de mieux mettre en valeur les

donnes.
C'est un conteneur typ qui permet le transit des donnes.

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.
selection indique l'ordre dans lequel les objets sont choisis dans
le noeud pour le quitter.

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 .

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.

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.

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.

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.

Appel asynchrone
Les appels asynchrones de type send correspondent des envois de

messages asynchrones.
Le broadcast signal permet d'mettre vers plusieurs destinataires la
fois
Cette possibilit est rarement oerte par les langages de
programmation.
L'action symtrique ct rcepteur est accept event, qui permet la
rception d'un signal.

Exceptions
Les exceptions permettent d'interrompre un traitement quand une

situation qui dvie du traitement normal se produit. Elles assurent une
gestion plus propre des erreurs qui peuvent se produire au cours d'un
traitement.
On utilise des pins d'exception (avec un triangle) un pour grer l'envoi
d'exceptions et la capture d'exceptions.
Un ot de donnes correspondant une exception est matrialis par

une che en zigue zague .

Exemple de traitement d'exceptions

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.

Exemple de rgion interruptible

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.

Modlisation avance avec UML Diagrammes de communication
Plan

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

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.

Diagrammes de squence et de communication

Diagrammes de squence et de communication

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 >

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.

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.

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 (){...}
}
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

Equivalence avec un diagramme de squence

Equivalence avec un diagramme de squence

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

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.

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.

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.

Exemple de collaboration

Diagramme de collaboration
Une collaboration peut aussi se reprsenter par une ellipse sans

compartiment, portant le nom de la collaboration en son sein. Les
instances sont relies l'ellipse par des lignes qui portent le nom du
rle de chaque instance.
On peut ainsi former des diagrammes de collaborations.

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

Modlisation avance avec UML Diagrammes de composants et de dploiement
Plan

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.

Diagramme de composant
Les diagrammes de composants reprsentent l'architecture logicielle

du systme.
Les composants peuvent tre dcomposs en sous-composants, le cas
chant.
Les liens entre composants sont spcis l'aide de dpendances
entre leurs interfaces.
Le cblage interne d'un composant est spci par les connecteurs
de dlgation. Un tel connecteur connecte un port externe du
composant avec un port de l'un de ses sous-composants internes.

Exemple de modlisation d'un composant

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.

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 .

Noeud
Un noeud est une ressource sur laquelle des artefacts peuvent tre
dploys pour tre excuts.
C'est un classeur qui peut prendre des attributs.
Un noeud se reprsente par un cube dont le nom respecte la syntaxe
des noms de classes.
Les noeuds peuvent tre associs comme des classes et on peut
spcier des multiplicits.

Artefact
Un artefact est la spcication d'une entit physique du monde rel.

Il se reprsente comme une classe par un rectangle contenant le
mot-cl artefact suivi du nom de l'artefact.
Un artefact dploy sur un noeud est symbolis par une che en trait
pointill qui porte le strotype dploy et qui pointe vers le noeud.
L'artefact peut aussi tre inclus directement dans le cube reprsentant
le noeud.
Plusieurs strotypes standard existent pour les artefacts : document,
excutable, chier, librairie, source.

Instanciation de noeuds et d'artefacts
Les noms des instances de noeuds et d'artefacts sont souligns.

Excution des composants
On utilise des ches de dpendance pour montrer la capacit

d'un noeud prendre en charge un type de composant.

Bonnes pratiques de la modlisation objet Design Patterns
Plan

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

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

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

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

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

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.

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

Creational patterns
Formes de cration pour :

Abstraire le processus d'instanciation des objets.
Rendre indpendant de la faon dont les objets sont crs, composs,
assembls, reprsents.
Encapsuler la connaissance de la classe concrte qui instancie.
Cacher ce qui est cr, qui cre, comment et quand.

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

Singleton
Intention :
Garantir qu'une classe n'a qu'une seule instance et fournit un point
d'accs global cette classe.
Indications :
S'il doit n'y avoir exactement qu'une instance de la classe et qu'elle
doit tre accessible aux clients de manire globale.
Si l'instance doit pouvoir tre sous-classe et si l'extension doit tre
accessible aux clients sans qu'ils n'aient modier leur code.
Motivation :
Spooler d'impression, gestionnaire d'achage
Gnrateur de nombres alatoires avec graine

Singleton : Structure

Singleton : Implmentation
public class Singleton {

private static Singleton uniqueInstance = null ;
private Singleton () {...}
public static Singleton Instance () {
if ( uniqueInstance == null )
uniqueInstance = new Singleton ();
return uniqueInstance ;
}
}
A ajouter :
Attributs et mthodes spciques de la classe singleton en question.
Paramtres de constructeur si besoin .

Structural patterns
Formes de structure :
Comment les objets sont assembls
Les patterns sont complmentaires les uns des autre

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

Adapter
Intention :
Convertir l'interface d'une classe en une autre qui soit conforme aux
attentes d'un client. L'adaptateur permet des classes de collaborer
malgr des interfaces incompatibles.
Indications :
On veut utiliser une classe existante, mais son interface ne concide pas
avec celle escompte.
On souhaite crer une classe rutilisable qui collaborera avec des
classes encore inconnues, mais qui n'auront pas ncessairement
l'interface escompte

Adapter : Motivation

Adapter : Structure

Bridge
Intention :
Dcouple une abstraction de son implmentation an que les deux
lments puissent tre modis indpendamment l'un de l'autre
Indications :
On souhaite viter un lien dnitif entre une abstraction et son
implmentation, les deux devant pouvoir tre tendues par hritage
Les modications de l'implmentation d'une abstraction ne doievent
pas avoir de consquence sur le code client (pas de recompilation)

Bridge : Motivation

Bridge : Motivation

Bridge : Structure

Composite
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

Composite : Motivation

Composite : Motivation

Composite : Structure

Behavioural patterns
Formes de comportement pour dcrire :

des algorithmes
des comportements entre objets
des formes de communication entre objet

Exemples de Behavioural patterns

Chain of
Responsibility Pour plus de dtails, lire
Command Design Patterns.
Catalogue de modles de
Interpreter conception rutilisables.
Iterator
Mediator Richard Helm, Ralph
Johnson, John Lissides,
Memento Eric Gamma
Observer UML 2 et les Dseign
State Patterns
Craig Larman, M.C.
Strategy Baland, L. Carite, E.
Template Method Burr
Visitor
Observer
Intention :
Dnir une dpendance de type un plusieurs de faon ce que,
quand un objet change d'tat, tous ceux qui en dpendent en soient
notis et automatiquement mis jour.
Indications :
Quand un concept a plusieurs reprsentations, l'une dpendant de
l'autre.
Quand un la modication d'un objet ncessite la modication dautres
objets, sans qu'on en connaisse le nombre exact.
Quand un objet doit notier d'autres objets avec lesquels il n'est pas
fortement coupl.

Observer Motivation

Observer Structure

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

Strategy : Motivation

Strategy : Structure

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, Observer
et Strategy
On trouve sans trop de mal des bibliothques de patterns sur Internet


Uml Cours Slides PDF

Transféré par

Informations du document

Titre original

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 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Introduction UML 2

Modlisation Oriente Objet de Systmes Logiciels

DUT Informatique  S2D

1 Introduction la Modlisation Oriente Objet

 UML 2.0, guide de rfrence 

 UML 2.0 Object Constraint Language (OCL) 

Les problmes lis l'informatique sont essentiellement des problmes de

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

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

Critres de qualit d'un logiciel

Rartition Origine des Cot de la

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

Un modle est une reprsentation abstraite de la ralit qui exclut

Modlisation par dcomposition fonctionnelle

C'est la fonction qui donne la forme du systme.

Modlisation oriente objets

La Conception Oriente Objet (COO) est la mthode qui conduit

Unied Modeling Language

Modlisation des besoins

Avant de dvelopper un systme, il faut savoir prcisment QUOI il

Exemple de diagramme de cas d'utilisation

Un acteurs est une entit extrieure au systme modlis, et qui

Un cas d'utilisation est l'expression d'un service ralis de bout en bout,

Acteurs et cas d'utilisation

Relations entre cas d'utilisation en acteurs

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

Dpendances d'inclusion et d'extension

Rutilisabilit avec les inclusions et les extensions

Les relations entre cas permettent la rutilisabilit du cas

Dcomposition grce aux inclusions et aux

Un virement est est un cas

La che pointe vers l'lment gnral.

Relations entre acteurs

Une seule relation possible : la gnralisation.

Identication des acteurs

Acteurs principaux et secondaires

Recenser les cas d'utilisation

Il n'y a pas une manire mcanique et totalement objective de reprer

Description des cas d'utilisation

Le diagramme de cas d'utilisation dcrit les grandes fonctions d'un

Les diagrammes de cas d'utilisation modlisent QUOI sert le

Exemple de diagramme de classes

Une classe dcrit un type d'objets concrets.

Proprits : attributs et oprations

Compartiment des attributs

Un attribut peut tre initialis et sa visibilit est dnie lors de sa

Compartiment des oprations

Relations entre classes

Une relation d'hritage est une relation de

Une association est une relation structurelle entre objets.

Multiplicits des associations

La notion de multiplicit permet le contrle du nombre d'objets

La syntaxe est MultMin..MultMax.

Navigabilit d'une association

Exemple : Connaissant un article on connat les commentaires, mais

Association unidirectionnelle de 1 vers 1

public class Adresse {...}

public class Client {

Association bidirectionnelle de 1 vers 1

Association unidirectionnelle de 1 vers *

DUT Informatique S2D

UML 2.0, guide de rfrence

UML 2.0 Object Constraint Language (OCL)

Unied Modeling Language

La che pointe vers l'lment gnral.

Identication des acteurs

Un attribut peut tre initialis et sa visibilit est dnie lors de sa

Plus dicile : grer la fois la cohrence et les collections

Si on rpond par l'armative ces deux questions, on doit utiliser une

Les modicateurs d'accs sont galement applicables aux oprations.

Diagrammes de classes direntes tapes de la

Pour un argument modiable :

Le retour des messages asynchrones s'eectue par l'envoi de nouveaux

DUT Informatique S2D 100 /

DUT Informatique S2D 101 /

DUT Informatique S2D 102 /

On spcie le nom de l'interaction dans le fragment.

Utilisation d'un DS pour spcier une mthode

DUT Informatique S2D 105 /