Uml Cours Support PDF

Introduction UML 2
Modlisation Oriente Objet de Systmes Logiciels

Pierre Grard
Universit de Paris 13 IUT Villetaneuse
DUT Informatique S2D - 2008/2009
Table des matires

1 Introduction la Modlisation Oriente Objet 1
2 Modlisation objet lmentaire avec UML 5
2.1 Diagrammes de cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Diagrammes d'objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Diagrammes de squences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 UML et mthododologie 33
3.1 Des besoins au code avec UML : une mthode minimale . . . . . . . . . . . . . . 33
3.2 Rational Unied Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 eXtreme programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4 Modlisation avance avec UML 53

4.1 Expression de contraintes avec OCL . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Diagrammes d'tats-transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3 Digrammes d'activits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4 Diagrammes de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.5 Diagrammes de composants et de dploiement . . . . . . . . . . . . . . . . . . . . 87
5 Bonnes pratiques de la modlisation objet 89

5.1 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
1 INTRODUCTION LA MODLISATION ORIENTE OBJET
1 Introduction la Modlisation Oriente 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 ;
Introduction UML 2 1 / 96
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 eort Origine des Cot de la

dv. erreurs maintenance
Dnition des 6% 56% 82%
besoins
Conception 5% 27% 13%
Codage 7% 7% 1%
Intgration Tests 15% 10% 4%
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
2 / 96 Introduction UML 2
Modle
Un modle est une reprsentation abstraite de la ralit qui exclut certains dtails du monde
rel.
Il permet de rduire la complexit d'un phnomne en liminant les dtails qui n'inu-
encent pas son comportement de manire signicative.
Il rete ce que le concepteur croit important pour la comprhension et la prdiction
du phnomne modlis, les limites du phnomne modlis dpendent des objectifs du
modle.
Langages de modlisation
Un langage de modlisation doit dnir :
La smantique des concepts ;
Une notation pour la reprsentation de concepts ;
Des rgles de construction et d'utilisation des concepts.
Des langages dirents niveaux de formalisation
Langages formels (Z,B,VDM) : le plus souvent mathmatiques, au grand pouvoir
d'expression et permettant des preuves formelles sur les spcications ;
Langages semi-formels (MERISE, UML...) : le plus souvent graphiques, au pouvoir
d'expression moindre mais plus faciles d'emploi.
L'industrie du logiciel dispose de nombreux langages de modlisation :
Adapts aux systmes procduraux (MERISE...) ;
Adapts aux systmes temps rel (ROOM, SADT...) ;
Adapts aux systmes objets (OMT, Booch, UML...).
Le rle des outils (Ateliers Gnie Logiciel) est primordial pour l'utilisabilit en pratique
des langages de modlisation.
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 logi-
cielles 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.
2 MODLISATION OBJET LMENTAIRE AVEC UML
2 Modlisation objet lmentaire avec UML

2.1 Diagrammes de cas d'utilisation
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 dclenche-
ment, 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 concer-
nant son droulement et ce qu'il recouvre prcisment.
Description textuelle
Identication :
Nom du cas : Payer CB
Objectif : Dtailler les tapes permettant client de payer par carte bancaire
Acteurs : Client, Banque (secondaire)
Date : 18/09
Responsables : Toto
Version : 1.0
Squencements :
Le cas d'utilisation commence lorsqu'un client demande le paiement par carte bancaire
Pr-conditions
Le client a valid sa commande
Enchanement nominal
1. Le client saisit les informations de sa carte bancaire
2. Le systme vrie que le numro de CB est correct
3. Le systme vrie la carte auprs du systme bancaire
4. Le systme demande au systme bancaire de dbiter le client
5. Le systme notie le client du bon droulement de la transaction
Enchanements alternatifs
1. En (2) : si le numro est incorrect, le client est averti de l'erreur, et invit recom-
mencer
2. En (3) : si les informations sont errones, elles sont re-demandes au client
Post-conditions
La commande est valide
Le compte de l'entreprise est crdit
Rubriques optionnelles
Contraintes non fonctionnelles :
Fiabilit : les accs doivent tre scuriss
Condentialit : les informations concernant le client ne doivent pas tre divulgus
Contraintes lies l'interface homme-machine :
Toujours demander la validation des oprations bancaires
2.2 Diagrammes de classes 2 MODLISATION OBJET LMENTAIRE AVEC UML
2.2 Diagrammes de classes

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 (dsig-
nation, label, auteur, etc).
Un lien est une instance d'association.
Association : Concept avis d'internaute qui lie commentaire et article
Lien : instance [Jean avec son avis ngatif], [Paul avec son avis positif]
Classes et objets
Une classe est la description d'un ensemble d'objets ayant une smantique, des attributs,
des mthodes et des relations en commun. Elle spcie l'ensemble des caractristiques qui
composent des objets de mme type.
Une classe est compose d'un nom, d'attributs et d'oprations.
Selon l'avancement de la modlisation, ces informations ne sont pas forcement toutes
connues.
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.2 Diagrammes de classes
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 peu-
vent 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 correspon-
dant 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'ab-
straction.
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 associa-
tion devient alors une classe appele classe-association .
Associations n-aires
Une association n-aire lie plus de deux classes.
Notation avec un losange central pouvant ventuellement accueillir une classe-association.
La multiplicit de chaque classe s'applique une instance du losange.
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 com-
posite.
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 dia-
grammes 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)
La classe enfant est la classe spcialise (ici Livre)
La classe parent est la classe gnrale (ici Article)
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 in-
stance de sa classe parent est attendue.
Par exemple, toute opration acceptant un objet d'une classe Animal doit accepter tout
objet de la classe Chat (l'inverse n'est pas toujours vrai).
Classes abstraites
Une mthode est dite abstraite lorsqu'on connat son entte mais pas la manire dont elle
peut tre ralise.
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 pointil-
ls ;
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.
2.3 Diagrammes d'objets 2 MODLISATION OBJET LMENTAIRE AVEC UML
2.3 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 gnral-
isables. . . ).
Le diagramme de classes modlise des rgles etle 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 :
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.3 Diagrammes d'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.
2.4 Diagrammes de squences 2 MODLISATION OBJET LMENTAIRE AVEC UML
2.4 Diagrammes de squences

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 sys-
tme 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 :
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.
2 MODLISATION OBJET LMENTAIRE AVEC UML 2.4 Diagrammes de squences
Un message dnit une communication particulire entre des lignes de vie (objets ou
acteurs).
Plusieurs types de messages existent, dont les plus courants :
l'envoi d'un signal ;
l'invocation d'une opration (appel de mthode) ;
la cration ou la destruction d'un objet.
La rception des messages provoque une priode d'activit (rectangle vertical sur la ligne de
vie) marquant le traitement du message (spcication d'excution dans le cas d'un appel
de mthode).
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 B {
C c;
op1 ( p : Type ){
c . op2 ( p );
c . op3 ();
}
}
class C {
op2 ( p : Type ){
...
}
op3 (){
...
}
}
Correspondance messages / signaux

Les messages asynchrones correspondent des signaux dans le diagramme de classes.
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 su-
isamment simples pour tre compris.
Recombiner les fragments restitue la complexit.
Syntaxe complte avec UML 2 : reprsentation complte de processus avec un langage
simple (ex : processus parallles).
Un fragment combin se reprsente de la mme faon qu'une interaction. Il est reprsent
un rectangle dont le coin suprieur gauche contient un pentagone.
Dans le pentagone gure le type de la combinaison (appel oprateur d'interaction ).
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
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 )pr-
cisant 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
3 UML ET MTHODODOLOGIE
3 UML et mthododologie
3.1 Des besoins au code avec UML : une mthode minimale
Pourquoi une mthode ?
Processus de dveloppement
Ensemble d'tapes partiellement ordonnes, qui concourent l'obtention d'un systme logiciel
ou l'volution d'un systme existant.
Objectif : produire des logiciels
De qualit (qui rpondent aux besoins de leurs utilisateurs)
Dans des temps et des cots prvisibles
A chaque tape, on produit :
Des modles ;
De la documentation ;
Du code.
Mthode = 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.
Inspire de
UML 2 - Modliser une application web
Pascal Roques
Editions Eyrolles (2006)
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'indpen-
dance.
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 corre-
spondent aux oprations systme, c'est dire aux messages changs avec les acteurs, que
seules les classes de dialogues sont habilites intercepter ou mettre.
Architecture en couches :
Les dialogues ne peuvent tre relis qu'aux contrles ou d'autres dialogues (en gnral,
associations unidirectionnelles).
Les classes mtier ne peuvent tre relies qu'aux contrles ou d'autres classes mtier.
Les contrles peuvent tre associs tous les types de classes.
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 mon-
trent les interactions internes provoques.
Les DSS sont repris mais l'objet Systme est clat pour donner le dtail des classes
d'analyse :
Les lignes de vie correspondent aux classes participantes.
Des squences systme aux interactions internes
Diagramme des classes de conception
Les diagrammes d'interaction permettent de dnir les oprations (ncessaires et su-

isantes) des classes mtier et de contrle (messages synchrones).
Le Diagramme des Classes de Conception reprend le diagramme de classes participantes en y

adjoignant toutes les oprations ncessaires.
Le DCC est en outre enrichi pour :
Prendre en compte l'architecture logicielle hte ;
Modliser les opration prives des direntes classes ;
Finaliser le modle des classes avant l'Implantation.
3.2 Rational Unied Process 3 UML ET MTHODODOLOGIE
3.2 Rational Unied Process

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

Les itrations de 1 7 sont produites successivement, chacune ajoutant au systme de
nouvelles fonctionnalits, jusqu' former un systme complet.
3 UML ET MTHODODOLOGIE 3.2 Rational Unied Process
A chaque itration, on refait :

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.
Rational Unied Process
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'util-
isateur.
Vue logique :
Cre lors de la phase d'laboration et rane lors de la phase de construction ;
Utilisation de diagrammes de classes, de squences...
Vue composants :
Description de l'architecture logicielle.
Vue dploiement :
Description de l'architecture matrielle du systme.
Vue implmentation :
Description des algorithmes, code source.
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 fonction-
nalits 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'utilisa-
tion ;
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 ? )
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'util-
isateur 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 individu-
ellement.
Mthode :
Planication pour chaque itration ;
Implmentation des tests en crant des cas de tests ;
Excuter les tests ;
Prendre en compte le rsultat de chacun.
Dploiement
Objectif : Dployer les dveloppements une fois raliss.
Peut tre ralis trs tt dans le processus dans une sousactivit de prototypage dont
l'objectif est de valider :
L'architecture physique ;
Les choix technologiques.
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)
3.3 eXtreme programming 3 UML ET MTHODODOLOGIE
3.3 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 im-
pression qui peut faire penser une bullition de cerveaux individuels).
Aller vite mais sans perdre de vue la rigueur du codage et les fonctions nales de l'ap-
plication.
Force de XP : sa simplicit et le fait qu'on va droit l'essentiel, selon un rythme qui doit
rester constant.
Valeurs d'XP
Communication :
XP favorise la communication directe, plutt que le cloisonnement des activits et les
changes de documents formels.
Les dveloppeurs travaillent directement avec la matrise d'ouvrage.
Feedback :
Les pratiques XP sont conues pour donner un maximum de feedback sur le droulement
du projet an de corriger la trajectoire au plus tt.
Simplicit :
Du processus ;
Du code.
Courage :
D'honorer les autres valeurs ;
De maintenir une communication franche et ouverte ;
D'accepter et de traiter de front les mauvaises nouvelles.
3 UML ET MTHODODOLOGIE 3.3 eXtreme programming
Pratiques d'XP
XP est fond sur des valeurs, mais surtout sur 13 pratiques rparties en 3 catgories :
Gestion de projets ;
Programmation ;
Collaboration.
Pratiques de 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 per-
mettent de faire des modications sans crainte.
Tests de recette :
Les testeurs mettent en place des tests automatiques qui vrient que le logiciel rpond
aux exigences du client.
Ces tests permettent des recettes automatiques du logiciel.
Pratiques de collaboration
Responsabilit collective du code :
Chaque dveloppeur est susceptible de travailler sur n'importe quelle partie de l'appli-
cation.
Programmation en binmes :
Les dveloppeurs travaillent toujours en binmes, ces binmes tant renouvels frquem-
ment.
Rgles de codage :
Les dveloppeurs se plient des rgles de codage strictes dnies par l'quipe elle-mme.
Mtaphore :
Les dveloppeurs s'appuient sur une description commune du design.
Intgration continue :
L'intgration des nouveaux dveloppements est faite chaque jour.
Cycle de vie XP
Exploration
Les dveloppeurs se penchent sur des questions techniques :
Explorer les direntes possibilits d'architecture pour le systme :
Etudier par exemple les limites au niveau des performances prsentes par chacune des
solutions possibles.
Le client s'habitue exprimer ses besoins sous forme de user strories (proches de dia-
grammes de cas illustrs par des diagrammes de squences).
Les dveloppeurs estiment les temps de dveloppement.
Planning
Planning de la premire release :
Uniquement les fonctionnalits essentielles ;
Premire release enrichir par la suite.
Dure du planning : 1 ou 2 jours.
Premire version (release) au bout de 2 6 mois.
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 logi-
ciel.
Maintenance
Continuer faire fonctionner le systme ;
3 UML ET MTHODODOLOGIE 3.3 eXtreme programming
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.
4 MODLISATION AVANCE AVEC UML
4 Modlisation avance avec UML

4.1 Expression de contraintes avec OCL
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.
...
4 MODLISATION AVANCE AVEC UML 4.1 Expression de contraintes avec OCL
Le solde d'un compte ne doit pas tre infrieur au dcouvert maximum autoris
Si l'attribut dMax de la classe Compte est un rel et que le dcouvert est exprim par une
valeur ngative :
context c ~: Compte
inv : solde >= dMax
Si le dcouvert est exprim par un nombre positif (par ex : 300 euros si on ne doit pas
descendre en dessous de 300 euros)
context c ~: Compte
inv : solde >= - dMax
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
4.1 Expression de contraintes avec OCL 4 MODLISATION AVANCE AVEC UML
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
Les pr-conditions doivent tre vries avant l'excution
Les post-conditions sont vraies aprs l'excution
self dsigne l'objet sur lequel l'opration lieu
Dans une post-condition :
@pre permet de faire rfrence la valeur avant que opration ne soit eectue
result designe le resultat de l'opration
ocsIsNew() indique si un objet n'existait pas dans l'tat prcdent
context Classe :: operation (...): ClasseValRetour
pre nom1 ~: param1 < ...
post ~: ... result > ...
Exemples de pr et post-conditions
context Personne :: retirer ( montant : Integer )
pre ~: montant > 0
post ~: solde < solde@pre - montant
context Personne :: 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 dif-
frente
coll->isUnique(expr)
Equivalence entre
self . enfants - > isUnique ( prenom )}
self . enfants
-> forall ( e1 , e2 ~: Personne |
e1 <> e2 implies
e1 . prenom <> e2 . prenom )
Utile pour dnir la notion de cl en BD
T-uples
Champs nomms, pas d'ordre entre les champs
Tuples (valeurs)
Tuple { x = -1.5 , y =12.6}
Tuple { y =12.6 , x = -1.5}
Tuple { y : Real =12.6 , x : Real = -1.5}
Tuple { nom = ' dupont ' , prenom = ' leon ' ,
age =43}
A partir d'UML 2.0
Dnition de types tuples
TupleType ( x : Real , y : Real )
TupleType ( y : Real , x : Real )
TupleType ( nom : String , prenom : String ,
age : Integer )
Collections imbriques
Collections imbriques
Jusqu' UML 2.0 pas de collections de collections car peu utilis et plus complexe
comprendre
Mise plat intuitive lors de la navigation
self . parents . parents
Mise plat par default li l'opration implicite collect
A partir de UML 2.0 imbrications arbitraires des constructeurs de types
Set ( Set ( Personne ))
Sequence ( OrderedSet ( Jour ))
Trs utile pour spcier des structures non triviales
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
4.2 Diagrammes d'tats-transitions 4 MODLISATION AVANCE AVEC UML
4.2 Diagrammes d'tats-transitions

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 embote-
ment et concurrence et pas seulement des automates tats nis comme dans les premires
versions d'UML
Diagramme d'tat-transition
L'organisation des tats et des transitions pour un classeur donn est reprsente dans un
diagramme d'tats-transitions.
Le modle dynamique comprend plusieurs diagrammes d'tats.
Attention
Chaque diagramme d'tats ne concerne qu'une seule classe.
Chaque automate tats nis s'excute concurremment et peut changer d'tat de faon
indpendante des autres.
Exemple de diagramme d'tats-transitions
4 MODLISATION AVANCE AVEC UML 4.2 Diagrammes 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 im-
plicitement un vnement de type change.
La rception d'un signal asynchrone, explicitement mis par un autre objet, gnre un
vnement de type signal.
L'coulement d'une dure dtermine aprs un vnement donn gnre un vnement
de type after. Par dfaut, le temps commence s'couler ds l'entre dans l'tat courant.
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 diagramme de
classes.
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 transi-
tion,
L'activit dsigne des instructions eectuer au moment du tir.
Point de dcision
On peut reprsenter des alternatives pour le franchissement d'une transition.
On utilise pour cela des pseudo-tats particuliers :
Les points de jonction (petit cercle plein) permettent de partager des segments de
transition.
Ils ne sont qu'un raccourci d'criture.
Ils permettent des reprsentations plus compactes.
Les points de choix (losange) sont plus que des raccourcis d'criture.
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.
Reprsentation d'alternativesavec 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.
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'imbri-
cation.
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 in-
dpendamment.
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 concur-
rence.
Pour pouvoir continuer leur excution, toutes les tches concurrentes doivent pralable-
ment tre prtes franchir la transition.
4.3 Digrammes d'activits 4 MODLISATION AVANCE AVEC UML
4.3 Digrammes d'activits

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 squen-
tielles. 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 in-
tervenir plusieurs.
A l'inverse, les diagrammes d'activit permettent une description s'aranchissant (partielle-
ment) de la structuration de l'application en classeurs.
La vision des diagrammes d'activits se rapproche des langages de programmation impra-
tive (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
4 MODLISATION AVANCE AVEC UML 4.3 Digrammes d'activits
Activit
Les activits dcrivent un traitement.
Le ot de contrle reste dans l'activit jusqu' ce que les traitements soient termins.
On peut dnir des variables locales une activit et manipuler les variables accessibles
depuis le contexte de l'activit (classe contenante en particulier).
Les activits peuvent tre imbriques hirarchiquement : on parle alors d'activits com-
posites.
Transition
Les transitions sont reprsentes par des ches pleines qui connectent les activits entre
elles.
Elles sont dclenches ds que l'activit source est termine.
Elles provoquent automatiquement le dbut immdiat de la prochaine activit d-
clencher (l'activit cible).
Contrairement aux activits, les transitions sont franchies de manire atomique, en
principe sans dure perceptible.
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 squen-
tielles.
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 transi-
tion de type fork qui correspond une duplication du ot de contrle en plusieurs ots
indpendants.
Lorsque la barre de synchronisation a plusieurs transitions en entre, on parle de transi-
tion de type join qui correspond un rendez-vous entre des ots de contrle.
Pour plus de commodit, il est possible de fusionner des barres de synchronisation de type
join et fork.
On a alors plusieurs transitions entrantes et sortantes sur une mme barre.
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 dia-
grammes d'activit.
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 dia-
gramme 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.
4.4 Diagrammes de communication 4 MODLISATION AVANCE AVEC UML
4.4 Diagrammes de communication

Diagrammes de squence
Les diagrammes de squence permettent de modliser l'change d'informations entre dif-

frents 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 con-
traintes de temps, comme les systmes temps rel.
Diagrammes de squence et de communication
Rles et connecteurs
Le rle permet de dnir le contexte d'utilisation de l'interaction.
4 MODLISATION AVANCE AVEC UML 4.4 Diagrammes de communication
Une rle dans un diagramme de communication correspond une ligne de vie dans un
diagramme de squences.
Les relations entre les lignes de vie sont appeles connecteurs .
Un connecteur se reprsente de la mme faon qu'une association mais la smantique est
plus large : un connecteur est souvent une association transitoire.
Comme pour les diagrammes de squence, la syntaxe d'une ligne de vie est :
< nomRole >[ < selecteur >]: < nomClasseur >
Types de messages
Comme dans les diagrammes de squence, on distingue deux types de messages :
Un message synchrone bloque l'expditeur jusqu' la rponse du destinataire. Le ot de
contrle passe de l'metteur au rcepteur.
Un message asynchrone n'est pas bloquant pour l'expditeur. Le message envoy peut
tre pris en compte par le rcepteur tout moment ou ignor.
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 con-
necteur 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
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.
4 MODLISATION AVANCE AVEC UML 4.4 Diagrammes de communication
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 com-
partiments.
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
4.5 Diagrammes de composants et de dploiement

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 of-
fertes.
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 environ-
nement matriel particulier.
UML permet de reprsenter un environnement d'excution ainsi que des ressources physiques
(avec les parties du systme qui s'y excutent) grce aux diagrammes de dploiement.
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.
5 BONNES PRATIQUES DE LA MODLISATION OBJET
5 Bonnes pratiques de la modlisation objet

5.1 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
5 BONNES PRATIQUES DE LA MODLISATION OBJET 5.1 Design Patterns
Les patrons sont nombreux (23 dans l'ouvrage du GOF, d'autres sont publis rgulire-
ment)
Lesquels sont semblables ?
Les patrons sont parfois de niveaux dirents : certains patterns s 'appuient sur d
'autres...
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, reprsen-
ts.
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 de-
scription
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.
5.1 Design Patterns 5 BONNES PRATIQUES DE LA MODLISATION OBJET
Motivation :
Spooler d'impression, gestionnaire d'achage
Gnrateur de nombres alatoires avec graine
Singleton : Structure
Singleton : Implmentation
public class Singleton {
private static Singleton uniqueInstance = null ;
private Singleton () {...}
public static Singleton Instance () {
if ( uniqueInstance == null )
uniqueInstance = new Singleton ();
return uniqueInstance ;
}
}
A ajouter :
Attributs et mthodes spciques de la classe singleton en question.
Paramtres de constructeur si besoin .
Structural patterns
Formes de structure :
Comment les objets sont assembls
Les patterns sont complmentaires les uns des autre
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 es-
compte.
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 con-
squence sur le code client (pas de recompilation)
Bridge : Motivation
Bridge : Structure
Composite
Intention :
Composition d'objets en structures arborescentes pour reprsenter des structures com-
posant/compos.
Permettre au client de traiter de la mme manire les objets atomiques et les combi-
naisons de ceux-ci.
Indications :
On souhaite reprsenter des hirarchies d'individus l'ensemble
On souhaite que le client n'ait pas se proccuper de la dirence entre combinaisons
d'objets et objets individuels
Composite : Motivation
Composite : Structure
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
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
Pour plus de dtails, lire
Design Patterns. Catalogue de modles de conception rutilisables.
Richard Helm, Ralph Johnson, John Lissides, Eric Gamma
UML 2 et les Dseign Patterns
Craig Larman, M.C. Baland, L. Carite, E. Burr
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 inter-
changeables.
Indications :
Plusieurs classes apparentes ne dirent que par leur comportement.
On a besoin de plusieurs variantes d'un algorithme.
Un algorithme utilise des donnes que les clients n'ont pas connatre.
Une classe dnit un ensemble de comportements qui gurent dans des oprations sous
la forme de dclarations conditionnelles multiples.
Strategy : Motivation
Strategy : Structure
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 con-
ception 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 Support PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uml Cours Support PDF

Uploaded by

Copyright:

Available Formats

Introduction UML 2

Modlisation Oriente Objet de Systmes Logiciels

Table des matires

4 Modlisation avance avec UML 53

5 Bonnes pratiques de la modlisation objet 89

1 Introduction la Modlisation Oriente Objet

Les problmes lis l'informatique sont essentiellement des problmes de logiciel.

Critres de qualit d'un logiciel

Rartition eort Origine des Cot de la

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.

Modlisation par dcomposition fonctionnelle

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

Modlisation oriente objets

C'est la structure du systme lui donne sa forme.

Attention, l'approche objet n'est pas seulement ascendante.

Unied Modeling Language

2 Modlisation objet lmentaire avec UML

Exemple de diagramme de cas d'utilisation

Acteurs et cas d'utilisation

Relations entre cas d'utilisation en acteurs

Relations entre cas d'utilisation

 Extension : le cas B tend le cas A (A est une partie optionelle de A).

Dpendances d'inclusion et d'extension

Rutilisabilit avec les inclusions et les extensions

Dcomposition grce aux inclusions et aux extensions

 Un virement est est un cas particulier de paiement.

Un virement est une sorte de paiement.

 La che pointe vers l'lment gnral.

Relations entre acteurs

Identication des acteurs

Acteurs principaux et secondaires

Recenser les cas d'utilisation

Description des cas d'utilisation

2.2 Diagrammes de classes

Exemple de diagramme de classes

Une classe dcrit un type d'objets concrets.

 D'autres compartiments peuvent tre ajouts : responsabilits, exceptions, etc.

Proprits : attributs et oprations

Compartiment des attributs

Compartiment des oprations

Relations entre classes

Multiplicits des associations

 La syntaxe est MultMin..MultMax.

Navigabilit d'une association

 Exemple : Connaissant un article on connat les commentaires, mais pas l'inverse.

Association unidirectionnelle de 1 vers 1

public class Client {

Association bidirectionnelle de 1 vers 1

Association unidirectionnelle de 1 vers *

public class Article {

Implantation d'une association bidirectionnelle de * vers *

Plus dicile : grer la fois la cohrence et les collections

Association de type agrgation

Association de type composition

 La destruction et la copie de l'objet composite (l'ensemble) impliquent respectivement

La composition est aussi dite  agrgation forte .

Implantation de l'hritage en Java

Les modicateurs d'accs sont galement applicables aux oprations.

Relation d'hritage et proprits

Il appartient aux classes enfant de dnir les methodes abstraites.

Classe cliente d'une interface

Diagrammes de classes direntes tapes de la conception

Rartition eort Origine des Cot de la

Pour obtenir un logiciel de qualit, il faut en matriser le processus d'laboration.

Unied Modeling Language

Extension : le cas B tend le cas A (A est une partie optionelle de A).

Un virement est est un cas particulier de paiement.

La che pointe vers l'lment gnral.

Identication des acteurs

D'autres compartiments peuvent tre ajouts : responsabilits, exceptions, etc.

La syntaxe est MultMin..MultMax.

Exemple : Connaissant un article on connat les commentaires, mais pas l'inverse.

Plus dicile : grer la fois la cohrence et les collections

La destruction et la copie de l'objet composite (l'ensemble) impliquent respectivement

La composition est aussi dite agrgation forte .

Les modicateurs d'accs sont galement applicables aux oprations.

Il appartient aux classes enfant de dnir les methodes abstraites.

Diagrammes de classes direntes tapes de la conception

Diagramme de squences correspondant :

Oprations ncessaires dans le diagramme de classes :

La syntaxe des paramtres est :

Les messages de retour sont reprsents en pointills.

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

Utilisation d'un DS pour spcier une mthode

Un tel classement permet de dterminer les cas d'utilisation centraux en fonction :

Les diagrammes d'interaction permettent de dnir les oprations (ncessaires et su-

3.2 Rational Unied Process

A chaque itration, on refait :

C'est pendant Planication et xcution qu'on rpte Spcication Conception

Rational Unied Process

Un consensus, par toutes les parties prenantes, sur la ractualisation de la planication,