Uml Cours Slides PDF

Modlisation Oriente Objet de Systmes Logiciels
Pierre Grard
Universit de Paris 13 IUT Villetaneuse
Introduction UML 2
DUT Informatique S2D
Pierre
Grard
(P13 IUT Villetaneuse)
Introduction UML 2
1 / 342
Plan
1 2 3 4 5
Introduction la Modlisation Oriente Objet
Introduction la Modlisation Oriente Objet Modlisation objet lmentaire avec UML UML et mthododologie Modlisation avance avec UML Bonnes pratiques de la modlisation objet
Pierre
Grard
Introduction UML 2
2 / 342
Bibliographie UML
UML 2.0, guide de rfrence UML 2.0

iditions gmpus ress @PHHSA
James Rumbaugh, Ivar Jacobson, Grady Booch Benot Charoux, Aomar Osmani, Yann Thierry-Mieg
iditions ersonD idution prne @PHHVA
UML 2.0 Superstructure et UML 2.0 Infrastructure

OMG (Object Management Group)
www.uml.org (2004).
Pierre
Grard
Introduction UML 2
3 / 342
Bibliographie OCL
UML 2.0 Object Constraint Language (OCL)

OMG (Object Management Group)
www.uml.org (2004)
Cours de Jean-Marie Favre, IMAG
http://megaplanet.org/jean-marie-favre
Pierre
Grard
Introduction UML 2
4 / 342
Matriel et logiciel
Systmes informatiques : 80 % de logiciel Y Depuis quelques annes, la fabrication du matriel est assure par quelques fabricants seulement.
ve mtriel est reltivement (leF ve mrh est stndrdisF PH 7 de mtrielF
Les problmes lis l'informatique sont essentiellement des problmes de logiciel.
Pierre
Grard
Introduction UML 2
5 / 342
La crise du logiciel
tude sur 8 380 projets (Standish Group, 1995) :
us X IT 7 Y rolmtique X SQ 7 @udget ou dlis non respetsD dfut de fontionnlitsA Y he X QI 7 @ndonnAF
Le taux de succs dcrot avec la taille des projets et la taille des entreprises. Gnie Logiciel (Software Engineering) :
gomment fire des logiiels de qulit c u9ttendEon d9un logiiel c uels sont les ritres de qulit c
Pierre
Grard
Introduction UML 2
6 / 342
Critres de qualit d'un logiciel

Utilit Utilisabilit Fiabilit Interoprabilit
edqution entre le logiiel et les esoins des utilisteurs Y
Performance Portabilit Rutilisabilit Facilit de maintenance
sntertions ve d9utres logiiels Y
n logiiel ne s9use ps pourtntD l mintenne sore une trs grosse prtie des e'orts de dveloppementF
Introduction UML 2 DUT Informatique S2D 7 / 342
Pierre
Grard
Poids de la maintenance
Rartition eort dv.
6% 5% 7% 15%
Dnition des besoins Conception Codage Intgration Tests Maintenance
Origine des erreurs
56%
Cot de la maintenance
82%
27% 7% 10%
13% 1% 4%
67% (Zeltovitz, De Marco)

Pierre
Grard
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.
v vie d9un logiiel est ompose de di'rentes tpesF v suession de es tpes forme le cycle de vie du logiielF sl fut ontrler l suession de es di'rentes tpesF
Pierre
Grard
Introduction UML 2
9 / 342
Etapes du dveloppement
tude de faisabilit Spcication Conception Codage Tests
hterminer les fontionnlits du logiielF hterminer l fon dont dont le logiiel fournit les di'rentes fontionnlits reherhesF
Maintenance
Pierre
issyer le logiiel sur des donnes d9exemple pour s9ssurer qu9il fontionne orretementF
Grard
Introduction UML 2
10 / 342
Modlisation
Pierre
Grard
Introduction UML 2
11 / 342
Modle
Un modle est une reprsentation abstraite de la ralit qui exclut certains dtails du monde rel.
sl permet de rduire la complexit d9un phnomne en liminnt les dtils qui n9in)uenent ps son omportement de mnire signi(tiveF sl re)te e que le onepteur roit importnt pour l comprhension et l prdiction du phnomne modlisD les limites du phnomne modlis dpendent des ojetifs du modleF
Pierre
Grard
Introduction UML 2
12 / 342
Langages de modlisation
Un langage de modlisation doit dnir :
v smntique des onepts Y ne nottion pour l reprsenttion de onepts Y hes rgles de onstrution et d9utilistion des oneptsF
Des langages dirents niveaux de formalisation Langages formels @DfDhwA X le plus souvent mthmtiquesD u
L'industrie du logiciel dispose de nombreux langages de modlisation : edpts ux systmes procduraux @wisiFFFA Y edpts ux systmes temps rel @yywD ehFFFA Y edpts ux systmes objets @ywD foohD wvFFFAF Le rle des outils (Ateliers Gnie Logiciel) est primordial pour l'utilisabilit en pratique des langages de modlisation.
Pierre
grnd pouvoir d9expression et permettnt des preuves formelles sur les spi(tions Y Langages semi-formels @wisiD wvFFFA X le plus souvent grphiquesD u pouvoir d9expression moindre mis plus files d9emploiF
Grard
Introduction UML 2
13 / 342
Modlisation par dcomposition fonctionnelle

Approche descendante :
homposer l fontion glole jusqu9 otenir des fontions simples pprhender et don progrmmerF
C'est la fonction qui donne la forme du systme.
Pierre
Grard
Introduction UML 2
14 / 342
Modlisation oriente objets

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

Au milieu des annes 90, les auteurs de Booch, OOSE et OMT ont dcid de crer un langage de modlisation uni avec pour objectifs : wodliser un systme des concepts l'excutableD en utilisnt les
tehniques oriente ojet Y
Rduire la complexit de la modlisation Y tilisle pr l9homme comme la machine X
Ociellement UML est n en 1994. UML v2.0 date de 2005. Il s'agit d'une version majeure apportant des innovations radicales et tendant largement le champ d'application d'UML.
Pierre
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...).
Grard
Introduction UML 2
16 / 342
Plan
1 2
Modlisation objet lmentaire avec UML
Diagrammes de cas d'utilisation
Introduction la Modlisation Oriente Objet Modlisation objet lmentaire avec UML

Diagrammes de cas d'utilisation Diagrammes de classes Diagrammes d'objets Diagrammes de squences
3 4 5
Pierre
UML et mthododologie Modlisation avance avec UML Bonnes pratiques de la modlisation objet
Grard
(P13 IUT Villetaneuse) Introduction UML 2 DUT Informatique S2D 17 / 342
Modlisation des besoins
Avant de dvelopper un systme, il faut savoir prcisment QUOI il devra servir, cad quels besoins il devra rpondre.
Modliser les besoins permet de :
d'utilsation.
Avec UML, on modlise les besoins au moyen de diagrammes de cas
pire l9inventire des fontionnlits ttendues Y yrgniser les esoins entre euxD de mnire fire pprtre des reltions @rutilstions possilesD FFFAF
Pierre
Grard
Introduction UML 2
18 / 342
Exemple de diagramme de cas d'utilisation
Pierre
Grard
Introduction UML 2
19 / 342
Cas d'utilisation
Un cas d'utilisation est un service rendu l'utilisateur, il implique des sries d'actions plus lmentaires. Un acteurs est une entit extrieure au systme modlis, et qui interagit directement avec lui.
Un cas d'utilisation est l'expression d'un service ralis de bout en bout, avec un dclenchement, un droulement et une n, pour l'acteur qui l'initie.
Pierre
Grard
Introduction UML 2
20 / 342
Acteurs et cas d'utilisation
Pierre
Grard
Introduction UML 2
21 / 342
Relations entre cas d'utilisation en acteurs

Les acteurs impliqus dans un cas d'utilisation lui sont lis par une association. Un acteur peut utiliser plusieurs fois le mme cas d'utilisation.
Pierre
Grard
Introduction UML 2
22 / 342
Relations entre cas d'utilisation
Inclusion : le cas A inclut le cas B (B est une partie obligatoire de A). Extension : le cas B tend le cas A (A est une partie optionelle de A). Gnralisation : le cas A est une gnralisation du cas du cas B (B
est une sorte de A).
Pierre
Grard
Introduction UML 2
23 / 342
Dpendances d'inclusion et d'extension

dpendances.
Les inclusions et les extensions sont reprsentes par des

vorsqu9un s f inlut un s eD f dpend de eF vorsqu9un s f tend un s eD f dpend ussi de eF yn note toujours l dpendne pr une )he pointille f se lit f dpend de e F e qui
Losqu'un lment A dpend d'un lment B, toute modication de B sera susceptible d'avoir un impact sur A. Les incude et les extend sont des strotypes (entre guillements) des relations de dpendance.
Attention
Le sens des ches indique le dpendance, pas le sens de la relation d'inclusion.

Pierre
Grard
Rutilisabilit avec les inclusions et les extensions

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

Quand un cas est trop complexe (faisant intervenir un trop grand nombre d'actions), on peut procder sa dcomposition en cas plus simples.
Pierre
Grard
Introduction UML 2
26 / 342
Gnralisation
Un virement est est un cas particulier de paiement. Un virement est une sorte de paiement. La che pointe vers l'lment gnral. Cette relation de gnralisation/spcialisation est prsente dans la plupart des diagrammes UML et se traduit par le concept d'hritage dans les langages orients objet.
Pierre
Grard
Introduction UML 2
27 / 342
Relations entre acteurs
Une seule relation possible : la gnralisation.
Pierre
Grard
Introduction UML 2
28 / 342
Identication des acteurs

Attention
Les principaux acteurs sont les utilisateurs du systme. Un acteur correspond un rle, pas une personne physique.
ne mme personne physique peut tre reprsente pr plusieurs teurs si elle plusieurs rlesF i plusieurs personnes jouent le mme rle visEEvis du systmeD elles seront reprsentes pr un seul teurF hes priphriques mnipuls pr le systme @imprimntesFFFA Y hes logiiels dj disponiles intgrer dns le projet Y hes systmes informtiques externes u systme mis qui intergissent ve luiD etF
En plus des utilisateurs, les acteurs peuvent tre :
Pour faciliter la recherche des acteurs, on se fonde sur les frontires du systme.
Pierre
Grard
Introduction UML 2
29 / 342
Acteurs principaux et secondaires
L'acteur est dit principal pour un cas d'utilisation lorsque l'acteur est l'initiative des changes ncessaires pour raliser le cas d'utilisation.
Les acteurs secondaires sont sollicits par le systme alors que le plus souvent, les acteurs principaux ont l'initiative des interactions.
ve plus souventD les teurs seondires sont d9utres ystmes informtiques ve lesquels le systme dvelopp est interEonnetF
Pierre
Grard
Introduction UML 2
30 / 342
Recenser les cas d'utilisation
Il n'y a pas une manire mcanique et totalement objective de reprer les cas d'utilisation.
sl fut se placer du point de vue de chaque acteur et dterminer omment il se sert du systmeD dns quels s il l9utiliseD et quelles fontionnlits il doit voir sF sl fut viter les redondances et limiter le nombre de cas en se situnt u on niveu d9strtion @pr exempleD ne ps rduire un s une seule tionAF sl ne fut ps fire pprtre les dtils des s d9utilistionD mis il fut rester u niveu des grndes fontions du systmeF
Trouver le bon niveau de dtail pour les cas d'utilisation est un problme dicile qui ncessite de l'exprience.
Pierre
Grard
Introduction UML 2
31 / 342
Description des cas d'utilisation
Le diagramme de cas d'utilisation dcrit les grandes fonctions d'un systme du point de vue des acteurs, mais n'expose pas de faon dtaille le dialogue entre les acteurs et les cas d'utilisation. Un simple nom est tout fait insusant pour dcrire un cas d'utilisation. Chaque cas d'utilisation doit tre document pour qu'il n'y ait aucune ambigut concernant son droulement et ce qu'il recouvre prcisment.
Pierre
Grard
Introduction UML 2
32 / 342
Description textuelle
Identication :
nire
Nom du cas X yer gf Objectif X htiller les tpes permettnt lient de pyer pr rte Acteurs X glientD fnque @seondireA Date X IVGHW Responsables X oto Version X IFH
Pierre
Grard
Introduction UML 2
33 / 342
Squencements :
Pr-conditions
1 2 3 4 5 1 2
ve s d9utilistion ommene lorsqu9un lient demnde le piement pr rte nire
Enchanement nominal
Le client a valid sa commande Le client saisit les informations de sa carte bancaire Le systme vrie que le numro de CB est correct Le systme vrie la carte auprs du systme bancaire Le systme demande au systme bancaire de dbiter le client Le systme notie le client du bon droulement de la transaction En (2) : si le numro est incorrect, le client est averti de l'erreur, et invit recommencer En (3) : si les informations sont errones, elles sont re-demandes au client La commande est valide Le compte de l'entreprise est crdit
Enchanements alternatifs Post-conditions

Pierre
Grard
Rubriques optionnelles
Contraintes non fonctionnelles :
Contraintes lies l'interface homme-machine :
Fiabilit : les accs doivent tre scuriss Condentialit : les informations concernant le client ne doivent pas tre divulgus Toujours demander la validation des oprations bancaires
Pierre
Grard
Introduction UML 2
33 / 342
Plan
1 2
Diagrammes de classes

3 4 5
Pierre
Grard
Objectif
Les diagrammes de cas d'utilisation modlisent QUOI sert le systme. Le systme est compos d'objets qui interagissent entre eux et avec les acteurs pour raliser ces cas d'utilisation. Les diagrammes de classes permettent de spcier la structure et les liens entre les objets dont le systme est compos.
Pierre
Grard
Introduction UML 2
35 / 342
Exemple de diagramme de classes
Pierre
Grard
Introduction UML 2
36 / 342
Concepts et instances
Une instance est la concrtisation d'un concept abstrait.
Un objet est une instance d'une classe
gonept X tylo snstne X le stylo que vous utilisez e moment pris est une instne du onept stylo X il s propre formeD s propre ouleurD son propre niveu d9usureD etF glsse X ido yjets X ink ployd @vive ompeyAD PHHI ydysse de l9ispe etF ne lsse drit un type d9ojets onretsF
Un lien est une instance d'association.
ne lsse spi(e l mnire dont tous les ojets de mme type seront drits @dsigntionD lelD uteurD etAF essoition X gonept vis d9internute qui lie ommentire et rtile vien X instne ten ve son vis ngtifD ul ve son vis positif
Pierre
Grard
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.
ne lsse est ompose d9un nomD d9attributs et d9oprationsF elon l9vnement de l modlistionD es informtions ne sont ps forement toutes onnuesF
D'autres compartiments peuvent tre ajouts : responsabilits, exceptions, etc.

Pierre
Grard
Introduction UML 2
38 / 342
Proprits : attributs et oprations
Les attributs et les oprations sont les proprits d'une classe. Leur nom commence par une minuscule. n attribut drit une donne de l lsseF
ne opration est un servie o'ert pr l lsse @un tritement que les ojets orrespondnt peuvent e'etuerAF
Les types des attributs et leurs initialisations ainsi que les modicateurs d'accs peuvent tre prciss dans le modle Les attributs prennent des valeurs lorsque la classe est instancie : ils sont en quelque sorte des variables attaches aux objets.
Pierre
Grard
Introduction UML 2
39 / 342
Compartiment des attributs
Un attribut peut tre initialis et sa visibilit est dnie lors de sa dclaration. Syntaxe de la dclaration d'un attribut :
modifAcces nomAtt : nomClasse [ multi ]= valeurInit
Pierre
Grard
Introduction UML 2
40 / 342
Compartiment des oprations
Une opration est dnie par son ainsi que par les types de ses paramtres et le type de sa valeur de retour. La syntaxe de la dclaration d'une opration est la suivante :
modifAcces nomOperation ( parametres ): ClasseRetour
La syntaxe de la liste des paramtres est la suivante :

nomClasse1 nomParam1 , ... , nomClasseN nomParamN
Pierre
Grard
Introduction UML 2
41 / 342
Mthodes et Oprations
Une opration est la spcication d'une mthode (sa signature) indpendamment de son implantation.
Exemples de mthodes pour l'opration fact(n:int):int :

{ // implementation iterative int resultat =1~; for ( int i = n ~; i >0~; i - -) resultat *= i ~; return resultat ~; } { // implementation recursive if ( n ==0 || n ==1) return 1~; return ( n * fact (n -1))~; }
Pierre
wv P utorise glement l d(nition des oprtions dns n9importe quel lngge donnF
Grard
Introduction UML 2
42 / 342
Relations entre classes
Une relation d'hritage est une relation de gnralisation/spcialisation permettant l'abstraction. Une dpendance est une relation unidirectionnelle exprimant une dpendance smantique entre les lments du modle (che ouverte pointille). Une association reprsente une relation smantique entre les objets d'une classe. Une relation d'agrgation dcrit une relation de contenance ou de composition.
Pierre
Grard
Introduction UML 2
43 / 342
Association
Une association est une relation structurelle entre objets.
ne ssoition est souvent utilise pour reprsenter les liens posiles entre ojets de lsses donnesF ille est reprsente pr un trit entre lssesF
Pierre
Grard
Introduction UML 2
44 / 342
Multiplicits des associations
La notion de multiplicit permet le contrle du nombre d'objets intervenant dans chaque instance d'une association. Exemple : un rtile n9pprtient qu9 une seule tgorie @IA Y une
tgorie onerne plus de H rtilesD sns mximum @BAF
La syntaxe est MultMin..MultMax.
B l ple de wultwx signi(e plusieurs sns priser de nomreF nFFn se note ussi n D et HFFB se note B F
Pierre
Grard
Introduction UML 2
45 / 342
Navigabilit d'une association
La navigabilit permet de spcier dans quel(s) sens il est possible de traverser l'association l'excution. On restreint la navigabilit d'une association un seul sens l'aide d'une che.
Exemple : gonnissnt un rtile on onnt les ommentiresD mis

On peut aussi reprsenter les associations navigables dans un seul sens par des attributs. Exemple : in joutnt un ttriut vissnternute de lsse
gommentire
la place de l9ssoitionF
Pierre
ps l9inverseF
Grard
Introduction UML 2
46 / 342
Association unidirectionnelle de 1 vers 1
Pierre
Grard
Introduction UML 2
47 / 342
Implantation
public class Adresse {...} public class Client { private Adresse livraison ; public void setAdresse ( Adresse adresse ){ this . livraison = adresse ; } public Adresse getAdresse (){ return livraison ; } }
Pierre
Grard
Introduction UML 2
48 / 342
Association bidirectionnelle de 1 vers 1
Pierre
Grard
Introduction UML 2
49 / 342
Implantation
public class Client { Adresse facturation ; public void setAdresse ( Adresse uneAdresse ){ if ( uneAdresse != null ){ this . facturation = uneAdresse ; facturation . client = this ; // correspondance } } } public class Adresse { Client client ; public void setClient ( Client unClient ){ this . client = client ; client . facturation = this ; // correspondance } }
Pierre
Grard
Introduction UML 2
50 / 342
Association unidirectionnelle de 1 vers *
Pierre
Grard
Introduction UML 2
51 / 342
Implantation
public class Commentaire {...}
public class Article { private Vector avisInternaute = new Vector (); public void addCommentaire ( Commentaire commentaire ){ avisInternaute . addElement ( commentaire ); } public void removeCommentaire ( Commentaire commentaire ){ avisInternaute . removeElement ( commentaire ); } }
Pierre
Grard
Introduction UML 2
52 / 342
Implantation d'une association bidirectionnelle de * vers *
Plus dicile : grer la fois la cohrence et les collections
Pierre
Grard
Introduction UML 2
53 / 342
Associations rexives
L'association la plus utilise est l'association binaire (reliant deux classs). Parfois, les deux extrmits de l'association pointent vers le mme classeur. Dans ce cas, l'association est dite rexive .
Pierre
Grard
Introduction UML 2
54 / 342
Classe-association
Une association peut tre rane et avoir ses propres attributs, qui ne sont disponibles dans aucune des classes qu'elle lie. Comme, dans le modle objet, seules les classes peuvent avoir des attributs, cette association devient alors une classe appele classe-association .
Pierre
Grard
Introduction UML 2
55 / 342
Associations n-aires
Une association n-aire lie plus de deux classes.
xottion ve un losnge entrl pouvnt ventuellement ueillir une lsseEssoitionF v multipliit de hque lsse s9pplique une instne du losngeF
Les associations n-aires sont peu frquentes et concernent surtout les cas o les multplicits sont toutes * . Dans la plupart des cas, on utilisera plus avantageusement des classes-association ou plusieurs relations binaires.
Pierre
Grard
Introduction UML 2
56 / 342
Association de type agrgation
Une agrgation est une forme particulire d'association. Elle reprsente la relation d'inclusion d'un lment dans un ensemble. On reprsente l'agrgation par l'ajout d'un losange vide du ct de l'agrgat. Une agrgation dnote une relation d'un ensemble ses parties. L'ensemble est l'agrgat et la partie l'agrg.
Pierre
Grard
Introduction UML 2
57 / 342
Association de type composition
La relation de composition dcrit une contenance structurelle entre instances. On utilise un losange plein.
v destruction et l copie de l9ojet omposite @l9ensemleA impliquent respetivement l destrution ou l opie de ses omposnts @les prtiesAF ne instne de l prtie n9pprtient jmis plus d9une instne de l9lment ompositeF
Pierre
Grard
Introduction UML 2
58 / 342
Composition et agrgation
Ds lors que l'on a une relation du tout sa partie, on a une relation d'agrgation ou de composition. La composition est aussi dite agrgation forte .
Pour dcider de mettre une composition plutt qu'une agrgation, on doit se poser les questions suivantes :
istEe que l destrution de l9ojet omposite @du toutA implique nessirement l destrution des ojets omposnts @les prtiesA c g9est le s si les omposnts n9ont ps d9utonomie visEEvis des ompositesF vorsque l9on opie le ompositeD doitEon ussi opier les omposntsD ou estEe qu9on peut les rutiliser D uquel s un omposnt peut fire prtie de plusieurs omposites c
Si on rpond par l'armative ces deux questions, on doit utiliser une composition.
Pierre
Grard
Introduction UML 2
59 / 342
Relation d'hritage
ves lments spiliss hritent de l struture et du omportement des lments plus gnrux @ttriuts et oprtionsA
L'hritage une relation de spcialisation/gnralisation.
Exemple : r hritge
d9ertileD un livre d9o0e un prixD une dsigntion et une oprtion heter@AD sns qu9il soit nessire de le priser
Pierre
Grard
Introduction UML 2
60 / 342
Implantation de l'hritage en Java

class Article { ... void acheter () { ... } } class Livre extends Article { ... }
Attention
Les extends Java n'a rien voir avec le extend UML vu pour les cas d'utilisation
Grard
Pierre
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 C X proprit ou lsse visile prtout Protected ou 5 F proprit ou lsse visile dns l lsse et pr
Il n'y a pas de visibilit par dfaut .
tous ses desendntsF Private ou E X proprit ou lsse visile uniquement dns l lsse PackageD ou X proprit ou lsse visile uniquement dns le pquetge
Package (paquetage)
Les packages contiennent des lments de modle de haut niveau, comme des classes, des diagrammes de cas d'utilisation ou d'autres packages. On organise les lments modliss en packages et sous-packages.
Grard
Pierre
Exemple d'encapsulation
Les modicateurs d'accs sont galement applicables aux oprations.

Pierre
Grard
Introduction UML 2
63 / 342
Relation d'hritage et proprits
La classe enfant possde toutes les proprits de ses classes parents (attributs et oprations)
v lsse v lsse
enfant est l lsse spilise @ii vivreA parent est l lsse gnrle @ii ertileA Toutefois, elle n'a pas accs aux proprits prives.
Pierre
Grard
Introduction UML 2
64 / 342
Terminologie de l'hritage
Une classe enfant peut rednir (mme signature) une ou plusieurs mthodes de la classe parent.
uf inditions ontriresD un ojet utilise les oprtions les plus spilises dns l hirrhie des lssesF v surcharge d'oprations @mme nomD mis signtures des oprtions di'rentesA est possile dns toutes les lssesF
Toutes les associations de la classe parent s'appliquent, par dfaut, aux classes drives (classes enfant). Principe de substitution : une instance d'une classe peut tre utilise partout o une instance de sa classe parent est attendue.
r exempleD toute oprtion eptnt un ojet d9une lsse eniml doit epter tout ojet de l lsse ght @l9inverse n9est ps toujours vriAF
Pierre
Grard
Introduction UML 2
65 / 342
Classes abstraites
Une mthode est dite abstraite lorsqu'on connat son entte mais pas la manire dont elle peut tre ralise. Il appartient aux classes enfant de dnir les methodes abstraites. Une classe est dite abstraite lorsqu'elle dnit au moins une mthode abstraite ou lorsqu'une classe parent contient une mthode abstraite non encore ralise.
Pierre
Grard
Introduction UML 2
66 / 342
Hritage multiple
Une classe peut avoir plusieurs classes parents. On parle alors d'hritage multiple.
ve lngge gCC est un des lngges ojet permettnt son implnttion e'etiveF tv ne le permet psF
Pierre
Grard
Introduction UML 2
67 / 342
Interface
Le rle d'une interface est de regrouper un ensemble d'oprations assurant un service cohrent oert par un classeur et une classe en particulier. Une interface est dnie comme une classe, avec les mmes compartiments. On ajoute le strotype interface avant le nom de l'interface. On utilise une relation de type ralisation entre une interface et une classe qui l'implmente.
Les classes implmentant une interface doivent implmenter toutes les oprations dcrites dans l'interface
Pierre
Grard
Introduction UML 2
68 / 342
Classe cliente d'une interface
Quand une classe dpend d'une interface (interface requise) pour raliser ses oprations, elle est dite classe cliente de l'interface On utilise une relation de dpendance entre la classe cliente et l'interface requise. Toute classe implmentant l'interface pourra tre utilise.
Pierre
Grard
Introduction UML 2
69 / 342
Exemple d'interface
Pierre
Grard
Introduction UML 2
70 / 342
Elments drivs
Les attributs drivs peuvent tre calculs partir d'autres attributs et des formules de calcul.
Une association drive est conditionne ou peut tre dduite partir d'autres autres associations. On utilise galement le symbole / .
ves ttriuts drivs sont symoliss pr l9jout d9un G devnt leur nomF vors de l oneptionD un ttriut driv peut tre utilis omme mrqueur jusqu9 e que vous puissiez dterminer les rgles lui ppliquerF
Pierre
Grard
Introduction UML 2
71 / 342
Attributs de classe
Par dfaut, les valeurs des attributs dnis dans une classe dirent d'un objet un autre. Parfois, il est ncessaire de dnir un attribut de classe qui garde une valeur unique et partage par toutes les instances. Graphiquement, un attribut de classe est soulign
Pierre
Grard
Introduction UML 2
72 / 342
Oprations de classe
Semblable aux attributs de classe ne opration de classe est une proprit de l lsseD et non de ses
instnesF ille n9 ps s ux ttriuts des ojets de l lsseF
Pierre
Grard
Introduction UML 2
73 / 342
Classe paramtre
Pour dnir une classe gnrique et paramtrable en fonction de valeurs et/ou de types :
h(nition d9une lsse prmtre pr des lments spi(s dns un retngle en pointills Y tilistion d9une dpendne strotype ind pour d(nir des lsses en fontion de l lsse prmtreF
Java5 : C++ :
gnricit templates
Pierre
Grard
Introduction UML 2
74 / 342
Diagrammes de classes direntes tapes de la conception

On peut utiliser les diagrammes de classes pour reprsenter un systme dirents niveaux d'abstraction : ve point de vue spcication met l9ent sur les interfes des lsses
plutt que sur leurs ontenusF ve point de vue conceptuel pture les onepts du domine et les liens qui les lientF sl s9intresse peu ou prou l mnire ventuelle d9implmenter es onepts et reltions et ux lngges d9implnttionF ve point de vue implantationD le plus ourntD dtille le ontenu et l9implnttion de hque lsseF
Les diagrammes de classes s'toent mesure qu'on va de hauts niveaux de bas niveaux d'abstraction (de la spcication vers l'implantation)
Pierre
Grard
Introduction UML 2
75 / 342
Construction d'un diagramme de classes

1
Trouver les classes du domaine tudi ; Trouver les associations entre classes ; Trouver les attributs des classes ;
ouventD onepts et sustntifs du domineF ouventD veres mettnt en reltion plusieurs lssesF ouventD sustntifs orrespondnt un niveu de grnulrit plus (n que les lssesF ves djetifs et les vleurs orrespondent souvent des vleurs d9ttriutsF
4 5 6
Organiser et simplier le modle en utilisant l'hritage ; Tester les chemins d'accs aux classes ; Itrer et raner le modle.
(P13 IUT Villetaneuse) Introduction UML 2
Pierre
Grard
76 / 342
Plan
1 2
Diagrammes d'objets

3 4 5
Pierre
Grard
Objectif
Diagrammes d'objets
Le diagramme d'objets reprsente les objets d'un systme un instant donn. Il permet de :
sllustrer le modle de lsses @en montrnt un exemple qui explique le modleA Y riser ertins spets du systme @en mettnt en videne des dtils impereptiles dns le digrmme de lssesA Y ixprimer une exeption @en modlisnt des s prtiuliersD des onnissnes non gnrlislesF F F AF
Le diagramme de classes modlise des rgles et le diagramme d'objets modlise des faits.
Pierre
Grard
Introduction UML 2
78 / 342
Reprsentation des objets
Diagrammes d'objets
Comme les classes, on utilise des cadres compartiments. En revanche, les noms des objets sont souligns et on peut rajouter son identiant devant le nom de sa classe. Les valeurs (a) ou l'tat (f) d'un objet peuvent tre spcies. Les instances peuvent tre anonymes (a,c,d), nommes (b,f), orphelines (e), multiples (d) ou strotypes (g).
Pierre
Grard
Introduction UML 2
79 / 342
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 :
Diagrammes d'objets
Pierre
Grard
Introduction UML 2
80 / 342
Diagramme de classes et diagramme d'objets

Le diagramme de classes contraint la structure et les liens entre les objets. Diagramme incohrent avec le diagramme de classes :
Diagrammes d'objets
Pierre
Grard
Introduction UML 2
80 / 342
Liens
Diagrammes d'objets
Un lien est une instance d'une association. Un lien se reprsente comme une association mais s'il a un nom, il est soulign.
Attention
Naturellement, on ne reprsente pas les multiplicits qui n'ont aucun sens au niveau des objets.
Pierre
Grard
Introduction UML 2
81 / 342
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.
Diagrammes d'objets
Pierre
Grard
Introduction UML 2
82 / 342
Plan
1 2
Diagrammes de squences

3 4 5
Pierre
Grard
Objectif des diagrammes de squence

Les diagrammes de cas d'utilisation modlisent QUOI sert le systme, en organisant les interactions possibles avec les acteurs. Les diagrammes de classes permettent de spcier la structure et les liens entre les objets dont le systme est compos : ils spcie QUI sera l'oeuvre dans le systme pour raliser les fonctionnalits dcrites par les diagrammes de cas d'utilisation. Les diagrammes de squences permettent de dcrire COMMENT les lments du systme interagissent entre eux et avec les acteurs.
ves ojets u oeur d9un systme intergissent en s9hngent des messgesF ves teurs intergissent ve le systme u moyen d9srw @snterfes rommeEwhineAF
Pierre
Grard
Introduction UML 2
84 / 342
Exemple d'interaction
Cas d'utilisation :
Diagramme de squences correspondant :
Pierre
Grard
Introduction UML 2
85 / 342
Exemple d'interaction
Diagramme de squences correspondant :
Oprations ncessaires dans le diagramme de classes :
Pierre
Grard
Introduction UML 2
85 / 342
Ligne de vie
Une ligne de vie reprsente un participant une interaction (objet ou acteur).

nomLigneDeVie [ selecteur ]: nomClasseOuActeur
Dans le cas d'une collection de participants, un slecteur permet de choisir un objet parmi n (par exemple objets[2]).
Pierre
Grard
Introduction UML 2
86 / 342
Messages
Les principales informations contenues dans un diagramme de squence sont les messages changs entre les lignes de vie, prsents dans un ordre chronologique.
n messge d(nit une ommunition prtiulire entre des lignes de vie @ojets ou teursAF lusieurs types de messges existentD dont les plus ournts X
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).
l'envoi d'un signal ; l'invocation d'une opration (appel de mthode) ; la cration ou la destruction d'un objet.
Pierre
Grard
Introduction UML 2
87 / 342
Principaux types de messages

ypiquement X ppel de mthode
Un message synchrone bloque l'expditeur jusqu' la rponse du destinataire. Le ot de contrle passe de l'metteur au rcepteur.
Si un objet A invoque une mthode d'un objet B, A reste bloqu tant que B n'a pas termin.
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.
yn peut ssoier ux messges d9ppel de mthode un messge de retour @en pointillsA mrqunt l reprise du ontrle pr l9ojet metteur du messge synhroneF
ypiquement X envoi de signl @voir strotype de lsse signl AF
Pierre
Grard
Introduction UML 2
88 / 342
Correspondance messages / oprations

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

Pierre
class C { op2 ( p : Type ){ ... } op3 (){ ... } }

Grard
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.
Pierre
Grard
Introduction UML 2
91 / 342
Cration et destruction de lignes de vie

La cration d'un objet est matrialise par une che qui pointe sur le sommet d'une ligne de vie.
yn peut ussi utiliser un messge synhrone ordinire portnt le nom rete F
La destruction d'un objet est matrialise par une croix qui marque la n de la ligne de vie de l'objet.
Pierre
Grard
Introduction UML 2
92 / 342
Messages complets, perdus et trouvs

Un message complet est tel que les vnements d'envoi et de rception sont connus.
n messge omplet est reprsent pr une )he prtnt d9une ligne de vie et rrivnt une utre ligne de vieF
Un message perdu est tel que l'vnement d'envoi est connu, mais pas l'vnement de rception.
Un message trouv est tel que l'vnement de rception est connu, mais pas l'vnement d'mission.
Pierre
v )he prt d9une ligne de vie mis rrive sur un erle indpendnt mrqunt l monnissne du destintireF ixemple X rodstF
Grard
Introduction UML 2
93 / 342
Syntaxe des messages
La syntaxe des messages est :

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

nomParametre = valeurParametre
Pour un argument modiable :

nomParametre : valeurParametre
Exemples :
appeler("Capitaine Hadock", 54214110) afficher(x,y) initialiser(x=100) f(x:12)

Pierre
Grard
Messages de retour
Le rcepteur d'un message synchrone rend la main l'metteur du message en lui envoyant un message de retour
ves messges de retour sont optionnels X l (n de l priode d9tivit mrque glement l (n de l9exution d9une mthodeF sls sont utiliss pour spi(er le rsultt de l mthode invoqueF
Le retour des messages asynchrones s'eectue par l'envoi de nouveaux messages asynchrones.
Pierre
Grard
Introduction UML 2
95 / 342
Syntaxe des messages de retour
La syntaxe des messages de retour est :

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

nomParam = valeurParam
ou
nomParam : valeurParam
Les messages de retour sont reprsents en pointills.
Pierre
Grard
Introduction UML 2
96 / 342
Fragment combin
Un fragment combin permet de dcomposer une interaction complexe en fragments susamment simples pour tre compris. 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.
hns le pentgone (gure le type de l ominison @ppel oprateur d'interaction AF
eominer les frgments restitue l omplexitF yntxe omplte ve wv P X reprsenttion omplte de proessus ve un lngge simple @ex X proessus prlllesAF
Pierre
Grard
Introduction UML 2
97 / 342
Exemple de fragment avec l'oprateur conditionnel
Pierre
Grard
Introduction UML 2
98 / 342
Type d'oprateurs d'interaction
Oprateurs de branchement ( choix et boucles) : Oprateurs contrlant l'envoi en parallle de messages : Oprateurs contrlant l'envoi de messages : Oprateurs xant l'ordre d'envoi des messages :
wek sequening et strit sequeningF ignoreD onsiderD ssertion et negtive Y prllel et ritil region Y lterntiveD optionD rek et loop Y
Pierre
Grard
Introduction UML 2
99 / 342
Oprateur de boucle
Pierre
Grard
Introduction UML 2
100 / 342
Syntaxe de l'oprateur loop

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

v oule est rpte u moins minxstrtions fois vnt qu9une ventuelle ondition oolenne ne soit teste @l ondition est ple entre rohets dns le frgmentA nt que l ondition est vrieD l oule ontinueD u plus mxxstrtions foisF
Notations :
loop(valeur) est quivlent loop(valeur,valeur)F loop est quivlent loop(0,*)D o * signi(e illimit F
Pierre
Grard
Introduction UML 2
101 / 342
Oprateur parallle
L'oprateur par permet d'envoyer des messages en parallle. Ce qui se passe de part et d'autre de la ligne pointille est indpendant.
Pierre
Grard
Introduction UML 2
102 / 342
Rutilisation d'une interaction
Rutiliser une interaction consiste placer un fragment portant la rfrence ref l o l'interaction est utile.
On spcie le nom de l'interaction dans le fragment.

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

Chaque cas d'utilisation donne lieu un diagramme de squences
Les inclusions et les extensions sont des cas typiques d'utilisation de la rutilisation par rfrencement
Pierre
Grard
Introduction UML 2
104 / 342
Utilisation d'un DS pour spcier une mthode

Une interaction peut tre identie par un fragment sd (pour pour sequence diagram )prcisant son nom Un message peut partir du bord de l'interaction, spciant le comportement du systme aprs rception du message, quel que soit l'expditeur
Pierre
Grard
Introduction UML 2
105 / 342
Plan
1 2 3
UML et mthododologie
Des besoins au code avec UML : une mthode minimale
Introduction la Modlisation Oriente Objet Modlisation objet lmentaire avec UML UML et mthododologie
Des besoins au code avec UML : une mthode minimale Rational Unied Process eXtreme programming
4 5
Modlisation avance avec UML Bonnes pratiques de la modlisation objet

Grard
Pierre
Pourquoi une mthode ?
Pierre
Grard
Introduction UML 2
107 / 342
Processus de dveloppement
Ensemble d'tapes partiellement ordonnes, qui concourent l'obtention d'un systme logiciel ou l'volution d'un systme existant.
Objectif : produire des logiciels

A chaque tape, on produit :
hes modles Y he l doumenttion Y hu odeF
he qulit @qui rpondent ux esoins de leurs utilisteursA hns des temps et des ots prvisiles
Pierre
Grard
Introduction UML 2
108 / 342
Mthode = Dmarche + Langage

La mthode MERISE fournit :
UML n'est qu'un langage :
ET
n lngge de modlistion grphique @wghD whD wyD wgFFFA ne dmrhe dopter pour dveloppent un logiielF sl spi(e omment drire des s d9utilistionD des lssesD des intertions wis ne prjuge ps de l dmrhe employeF @tionl ni(ed roessA E pr les uteurs d9wv Y @etreme rogrmmingA E pouvnt s9ppuyer sur wvF
Mthodes s'appuyant sur UML :
Pierre
Grard
Introduction UML 2
109 / 342
Mthode minimale
Objectif
Rsoudre 80% des problmes avec 20% d'UML.

rs nettement moins omplexe que Y edpte pour projets modestes Y winimum vitl pour qui prtend utiliser un peu wvF
Proposition d'une mthode archi-minimale :
Pierre
Grard
Introduction UML 2
110 / 342
Mthode minimale
Objectif
Inspire de UML 2 - Modliser une application web

Pascal Roques
Editions Eyrolles (2006)
Pierre
Grard
Introduction UML 2
110 / 342
Mthode minimale
Objectif
Pierre
Grard
Introduction UML 2
110 / 342
Cas d'utilsation
1 2 3 4 5 6
Comment dnir les besoins ?
sdenti(er les limites du systme Y sdenti(er les teurs Y sdenti(er les s d9utilistion Y truturer les s d9utilistion en pkges Y ejouter les reltions entre s d9utilistion Y glsser les s d9utilistion pr ordre d9importneF
Pierre
Grard
Introduction UML 2
111 / 342
Exemple de classement
Cas d'utilisation
Ajouter article au panier Changer prix Article Rechercher par mots-cls ... etc ...
Haute Moyen Moyen Moyen Bas Moyen ... etc ... ... etc ...
Priorit
Risque
Un tel classement permet de dterminer les cas d'utilisation centraux en fonction : Les fonctionnalits des cas les plus centraux seront dveloppes prioritairement.
Pierre
he leur priorit fontionnelle Y hu risque qu9il font ourrir u projet dns son ensemleF
Grard
Introduction UML 2
112 / 342
Modle du domaine
Le modle du domaine est constitu d'un ensemble de classes dans lesquelles aucune opration n'est dnie. Le modle du domaine dcrit les concepts invariants du domaine d'application. Exemple : our un logiiel de gestions de fturesD on ur des lsses
omme roduitD glientD ptureFFF
Etapes de la dmarche :
1 2 3 4
Peu importe que le logiciel soit en ligne ou non. Peu importent les technologies employes.
Les concepts du domaine peuvent tre identis directement partir de la connaissance du domaine ou par interview des experts mtier.
Pierre
sdenti(er les onepts du domine Y ejouter les ssoitions et les ttriuts Y qnrliser les onepts Y truturer en pkges X struturtion selon les prinipes de ohrene et d9indpendneF
Grard
Introduction UML 2
113 / 342
Exemple de modle du domaine
Pierre
Grard
Introduction UML 2
114 / 342
Structuration en packages
Pierre
Grard
Introduction UML 2
115 / 342
Squences systme
Les squences systme formalisent les descriptions textuelles des cas d'utilisation, en utilisant des diagrammes de squence. Construire les Diagrammes de Squences Systme implique souvent la mise jour des cas d'utilisation la lumire des rexions que nous inspirent la production des DSS. Les DSS permettent de spcier les oprations systme. Le systme est considr comme un tout :
yn s9intresse ses intertions ve les teurs Y yn utilise une lsse ystme qui ! prt les teurs ! donner lieu l seule ligne de vie des hF
Un nouveau DSS est produit pour chacun des cas d'utilisation. Les DSS sont parfois trs simples mais ils seront enrichis par la suite.
Pierre
Grard
Introduction UML 2
116 / 342
Exemple de diagramme de squence systme
Pierre
Grard
Introduction UML 2
117 / 342
Oprations systme
Les oprations systme sont des oprations qui devront tre ralises par l'une ou l'autre des classes du systme. Elles correspondent tous les messages qui viennent des acteurs vers le systme dans les dirents DSS.
Pierre
Grard
Introduction UML 2
118 / 342
Classes participantes
Pour chaque cas d'utilisation, on dnit les classes d'analyse mises en oeuvre pour sa ralisation eective. Typologie des classes d'analyse : ves classes mtier @ou entitsA reprsentent les ojets mtierF illes
orrespondent ux lsses du modle du domineF ves classes de dialogue sont elles qui permettent les intertions entre les teurs et l9pplitionF ves classes de contrle permettent d9strire les fontionnlits du systme X
Elles font le lien entre les classes dialogue et les classes mtier. Elles permettent de contrler la cinmatique de l'application, cad l'ordre dans lequel les choses doivent se drouler.
Pierre
Grard
Introduction UML 2
119 / 342
Diagramme de classes participantes
Le Diagramme des Classes Participantes est un diagramme de classes dcrivant toutes les classes d'analyse. Le DCP est une version enrichie du modle du domaine, auquel on adjoint les classes d'interaction et de contrle. A ce point du dveloppement, seules les classes de dialogue ont des oprations, qui correspondent aux oprations systme, c'est dire aux messages changs avec les acteurs, que seules les classes de dialogues sont habilites intercepter ou mettre. Architecture en couches :
ves dilogues ne peuvent tre relis qu9ux ontrles ou d9utres dilogues @en gnrlD ssoitions unidiretionnellesAF ves lsses mtier ne peuvent tre relies qu9ux ontrles ou d9utres lsses mtierF ves ontrles peuvent tre ssois tous les types de lssesF
Introduction UML 2 DUT Informatique S2D
Pierre
Grard
120 / 342
Exemple de diagramme de classes participantes
Pierre
Grard
Introduction UML 2
121 / 342
Diagrammes d'interaction
Dans les diagrammes de squence systme, le systme tait vu comme une bote noire (ligne de vie Systme ).
yn sit mintennt de ojets est ompos le systme @digF de lsses prtiipntesAF ve systme n9est plus une ote noireF
Chaque diagramme de squence systme donne lieu un diagramme d'interaction. Il y en a donc autant que de cas d'utilisation. En plus des interactions du systme avec l'extrieur, les Diagrammes d'Interaction montrent les interactions internes provoques. Les DSS sont repris mais l'objet Systme est clat pour donner le dtail des classes d'analyse : Les lignes de vie correspondent aux classes participantes.
Pierre
Grard
Introduction UML 2
122 / 342
Des squences systme aux interactions internes
Pierre
Grard
Introduction UML 2
123 / 342
Des squences systme aux interactions internes
Pierre
Grard
Introduction UML 2
123 / 342
Diagramme des classes de conception
Les diagrammes d'interaction permettent de dnir les oprations (ncessaires et susantes) des classes mtier et de contrle (messages synchrones).
Pierre
Grard
Introduction UML 2
124 / 342
Plan
1 2 3
Rational Unied Process
4 5

Grard
Pierre
Modles de cycles de vie linaire
Les phases du dveloppement se suivent dans l'ordre et sans retour en arrire.
Pierre
Grard
Introduction UML 2
126 / 342
Modles de cycles de vie linaire
Les phases du dveloppement se suivent dans l'ordre et sans retour en arrire.
Pierre
Grard
Introduction UML 2
126 / 342
Problmes des cycles linaires
Risques levs et non contrls : sdenti(tion tardive des prolmes Y reuve tardive de on fontionnement Y Eet tunnelF Amliorations : construction itrative du systme : ghque itrtion produit un nouvel incrment Y
ghque nouvel inrment pour ojetif l mtrise d9une prtie des risques et pporte une preuve tngile de fisilit ou d9dqution X
Enrichissement d'une srie de prototypes ; Les versions livres correspondent des tapes de la chane des prototypes.
Pierre
Grard
Introduction UML 2
127 / 342
Production itrative d'incrments

Itrations 0
A chaque itration, on refait :

1 2 3 4 Pierre
pi(tion Y goneption Y smplmenttion Y estsF
Grard
Introduction UML 2
128 / 342

Itrations 1

1 2 3 4 Pierre
Grard
Introduction UML 2
128 / 342

Itrations 2

1 2 3 4 Pierre
Grard
Introduction UML 2
128 / 342

Itrations 3

1 2 3 4 Pierre
Grard
Introduction UML 2
128 / 342

Itrations 4

1 2 3 4 Pierre
Grard
Introduction UML 2
128 / 342

Itrations 5

1 2 3 4 Pierre
Grard
Introduction UML 2
128 / 342

Itrations 6

1 2 3 4 Pierre
Grard
Introduction UML 2
128 / 342

Itrations 7

1 2 3 4 Pierre
Grard
Introduction UML 2
128 / 342
Elimination des risques chaque itration

On peut voir le dveloppement d'un logiciel comme un processus graduel d'limination de risques.
C'est pendant Planication et xcution qu'on rpte Spcication Conception Implmentation Tests.
Pierre
Grard
Introduction UML 2
129 / 342
RUP est une dmarche de dveloppement qui est souvent utilis conjointement au langage UML.
Rational Unied Process est
ilot pr les s d9utilistion Y gentr sur l9rhiteture Y strtif et inrmentlF
Pierre
Grard
Introduction UML 2
130 / 342
RUP est itratif et incrmental
Chaque itration prend en compte un certain nombre de cas d'utilisation. Les risques majeurs sont traits en priorit. Chaque itration donne lieu un incrment et produit une nouvelle version excutable.
Pierre
Grard
Introduction UML 2
131 / 342
RUP est pilot par les cas d'utilisation

La principale qualit d'un logiciel est son utilit :
Le dveloppement d'un logiciel doit tre centr sur l'utilisateur. Les cas d'utilisation permettent d'exprimer ces besoins :
htetion et desription des esoins fontionnels Y yrgnistion des esoins fontionnelsF
edqution du servie rendu pr le logiiel ve les esoins des utilisteursF
Pierre
Grard
Introduction UML 2
132 / 342
RUP est centr sur l'architecture
Modlisation de direntes pespectives indpendantes et complmentaires. Architecture en couches et vues de Krutchen.
Pierre
Grard
Introduction UML 2
133 / 342
Vues du systme
Vue cas d'utilisation : Vue logique :
hesription du systme omme un ensemle de trnstions du point de vue de l9utilisteurF gre lors de l phse d9lortion et r0ne lors de l phse de onstrution Y tilistion de digrmmes de lssesD de squenesFFF hesription de l9rhiteture logiielleF hesription de l9rhiteture mtrielle du systmeF hesription des lgorithmesD ode soureF
DUT Informatique S2D 134 / 342
Vue composants :
Vue dploiement :
Vue implmentation :
Pierre
Grard
Introduction UML 2
Organisation en phases du dveloppement

Initialisation : Elaboration : Transition :
h(nition du prolmeF lni(tion des tivitsD 'ettion des ressouresD nlyseF hveloppement du logiiel pr inrments suessifsF eettge et dploiementF
Construction :
Les phases du dveloppement sont les grandes tapes du dveloppement du logiciel Le projet commence en phase d'initialisation et termine en phase de transition
Pierre
Grard
Introduction UML 2
135 / 342
Phase d'initialisation : Objectifs
Dnition du cadre du projet, son concept, et inventaire du contenu ; Elaboration des cas d'utilisation critiques ayant le plus d'inuence sur l'architecture et la conception ; Ralisation d'un ou de plusieurs prototypes dmontrant les fonctionnalits dcrites par les cas d'utilisation principaux ; Estimation dtaille de la charge de travail, du cot et du planning gnral ainsi que de la phase suivante d'laboration Estimation des risques.
Pierre
Grard
Introduction UML 2
136 / 342
Phase d'initialisation : Activits
Formulation du cadre du projet, des besoins, des contraintes et des critres d'acceptation ; Planication et prparation de la justication conomique du projet et valuation des alternatives en termes de gestion des risques, ressources, planication ; Synthse des architectures candidates, valuation des cots.
Pierre
Grard
Introduction UML 2
137 / 342
Phase d'initialisation : Livrables
Un document de vision prsentant les besoins de base, les contraintes et fonctionnalits principales ; Une premire version du modle de cas d'utilisation ; Un glossaire de projet ; Un document de justication conomique incluant le contexte gnral de ralisation, les facteurs de succs et la prvision nancire ; Une valuation des risques ; Un plan de projet prsentant phases et itrations ; Un ou plusieurs prototypes.
Pierre
Grard
Introduction UML 2
138 / 342
Phase d'initialisation : Critres d'valuation
Un consensus sur :
La comprhension commune des besoins.
v plni(tion Y v9estimtion des ots Y v d(nition de l9ensemle des projets des prties onernesF
Pierre
Grard
Introduction UML 2
139 / 342
Phase d'laboration : objectifs
Dnir, valider et arrter l'architecture ; Dmontrer l'ecacit de cette architecture rpondre notre besoin ; Planier la phase de construction.
Pierre
Grard
Introduction UML 2
140 / 342
Phase d'laboration : activits
Elaboration de la vision gnrale du systme, les cas d'utilisation principaux sont compris et valids ; Le processus de projet, l'infrastructure, les outils et l'environnement de dveloppement sont tablis et mis en place ; Elaboration de l'architecture et slection des composants.
Pierre
Grard
Introduction UML 2
141 / 342
Phase d'laboration : livrables
Le modle de cas d'utilisation est produit au moins 80 % ; La liste des exigences et contraintes non fonctionnelles identies ; Une description de l'architecture ; Un excutable permettant de valider l'architecture du logiciel travers certaines fonctionnalits complexes ; La liste des risques revue et la mise jour de la justication conomique du projet ; Le plan de ralisation, y compris un plan de dveloppement prsentant les phases, les itrations et les critres d'valuation ;
Pierre
Grard
Introduction UML 2
142 / 342
Phase d'laboration : Critres d'valuation

La stabilit de la vision du produit nal ; La stabilit de l'architecture ; La prise en charge des risques princip aux est adresse par le(s) prototype(s) ; La dnition et le dtail du plan de projet pour la phase de construction ; Un consensus, par toutes les parties prenantes, sur la ractualisation de la planication, des cots et de la dnition de projet.
Pierre
Grard
Introduction UML 2
143 / 342
Phase de construction : objectifs
La minimisation des cots de dveloppement par : Le maintien de la qualit ; Ralisation des versions excutables.
v9optimistion des ressoures Y v minimistion des trvux non nessiresF
Pierre
Grard
Introduction UML 2
144 / 342
Phase de construction : Activits
Gestion et le contrle des ressources et l'optimisation du processus de projet ; Evaluation des versions produites en regard des critres d'acceptation dnis.
Pierre
Grard
Introduction UML 2
145 / 342
Phase de construction : Livrables
Les versions excutables du logiciel correspondant l'enrichissement itration par itration des fonctionnalits ; Les manuels d'utilisation raliss en parallle la livraison incrmentale des excutables ; Une description des versions produites.
Pierre
Grard
Introduction UML 2
146 / 342
Phase de construction : Critres d'valuation
La stabilit et la qualit des excutables ; La prparation des parties prenantes ; La situation nancire du projet en regard du budget initial.
Pierre
Grard
Introduction UML 2
147 / 342
Phase de transition : Objectifs
Le dploiement du logiciel dans l'environnement d'exploitation des utilisateurs ; La prise en charge des problmes lis la transition ; Atteindre un niveau de stabilit tel que l'utilisateur est indpendant ; Atteindre un niveau de stabilit et qualit tel que les parties prenantes considrent le projet comme termin.
Pierre
Grard
Introduction UML 2
148 / 342
Phase de transition : Activits
Activits de packaging du logiciel pour le mettre disposition des utilisateurs et de l'quipe d'exploitation ; Correction des erreurs rsiduelles et amlioration de la performance et du champ d'utilisation ; Evaluation du produit nal en regard des critres d'acceptation dnis.
Pierre
Grard
Introduction UML 2
149 / 342
Phase de transition : Livrables
La version nale du logiciel ; Les manuels d'utilisation.
Pierre
Grard
Introduction UML 2
150 / 342
Phase de transition : Critres d'valuation
La satisfaction des utilisateurs ; La situation nancire du projet en regard du budget initial.
Pierre
Grard
Introduction UML 2
151 / 342
Organisation en activits de dveloppement

Chaque phase comprend plusieurs itrations Pour chacune des itrations, on se livre plusieurs activits :
wodlistion mtier Y
Expression des besoins Y Analyse Y Conception Y Implmentation Y Test Y

hploiementF
Les activits sont des tapes dans le dveloppement d'un logiciel, mais un niveau de granularit beaucoup plus n que les phases. Chaque activit est rpte autant de fois qu'il y a d'itrations.
Pierre
Grard
Introduction UML 2
152 / 342
Modlisation mtier
Objectif : Mieux comprendre la structure et la dynamique de

l'organisation :
roposer l meilleure solution dns le ontexte de l9orgnistion liente Y listion d9un glossire des termes mtiers Y grtogrphie des proessus mtier de l9orgnistion lienteF
Activit coteuse mais qui permet d'acclrer la comprhension d'un problme.
Pierre
Grard
Introduction UML 2
153 / 342
Expression des besoins
Objectif : Cibler les besoins des utilisateurs et du clients grce une

srie d'interviews. L'activit de recueil et d'expression des besoins dbouche sur ce que doit faire le systme (question QUOI ? )
v9ensemle des prties prenntes du projetD mtrise d9oeuvre et mtrise d9ouvrgeD est teur de ette tivitF
Pierre
Grard
Introduction UML 2
154 / 342
Expression des besoins
Utilisation des cas d'utilisation pour :
Les cas d'utilisation sont dcomposs en scnarios d'usage du systme, dans lesquels l'utilisateur raconte ce qu'il fait grce au systme et ses interactions avec le systme. Un maquettage est ralisable pour mieux immerger l'utilisateur dans le futur systme. Une fois poses les limites fonctionnelles, le projet est plani et une prvision des cots est ralise.
hmtiser les esoins Y truturer les douments de spi(tions fontionnellesF
Pierre
Grard
Introduction UML 2
154 / 342
Analyse
Objectif : Transformer les besoins utilisateurs en modles UML.

Principaux livrables :
enlyse ojet servnt de se une r)exion sur les mnismes internes du systmeF wodles d9nlyseD neutre vis vis d9une tehnologie Y vivre une spi(tion plus prise des esoinsF
Peut envisag comme une premire bauche du modle de conception.
Pierre
Grard
Introduction UML 2
155 / 342
Conception
Objectif : Modliser comment le systme va fonctionner :

Le systme est analys et on produit :
ne proposition d9rhiteture Y n doupge en omposntsF ixigenes non fontionnelles Y ghoix tehnologiquesF
Pierre
Grard
Introduction UML 2
156 / 342
Impmentation
Objectif : Implmenter le systme par composants.
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.
ve systme est dvelopp pr moreux dpendnt les uns des utresF yptimistion de l9utilistion des ressoures selon leurs expertisesF
Pierre
Grard
Introduction UML 2
157 / 342
Test
Objectif : Vrier des rsultats de l'implmentation en testant la

construction : Tests unitaires : tests omposnts pr omposnts Y Tests d'intgration : tests de l9intertion de omposnts
prllement tests individuellementF lni(tion pour hque itrtion Y smplmenttion des tests en rnt des s de tests Y ixuter les tests Y rendre en ompte le rsultt de hunF
Mthode :
Pierre
Grard
Introduction UML 2
158 / 342
Dploiement
Objectif : Dployer les dveloppements une fois raliss.

L'architecture physique ; Les choix technologiques.
eut tre rlis trs tt dns le proessus dns une soustivit de prototypge dont l9ojetif est de vlider X
Pierre
Grard
Introduction UML 2
159 / 342
Importance des activits dans chaque phase
Pierre
Grard
Introduction UML 2
160 / 342
Principaux diagrammes UML par activit

Expression des besoins et modlisation mtier : Analyse
wodles mtierD domineD s d9utilistion Y higrmme de squenes Y higrmme d9tivitF
Conception
wodles mtierD s d9utilistion Y higrmme des lssesD de squenes et de dploiementF higrmme higrmme higrmme higrmme des lssesD de squenes Y ttGtrnsition Y d9tivit Y de dploiement et de omposntF
Pierre
Grard
Introduction UML 2
161 / 342
2TUP, une variante du Unied Process .
2TUP, avec un processus de dveloppement en Y , dvelopp par

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

Grard
Pierre
Mthodes agiles
eXtreme programming
Quelles activits pouvons nous abandonner tout en produisant des logiciels de qualit ? Comment mieux travailler avec le client pour nous focaliser sur ses besoins les plus prioritaires et tre aussi ractifs que possible ?
Filiation avec le RAD.
Exemples de mthodes agiles : XP @etreme rogrmmingAD DSDM @hynmi oftwre hevelopment wethodAD ASD @edpttive oftwre hevelopmentAD CCM @grystl gler wethodologiesAD SCRUMD FDD @peture hriven hevelopmentAF
Grard
Pierre
Introduction UML 2
Priorits des mthodes agiles
eXtreme programming
Priorit aux personnes et aux interactions sur les procdures de les outils ; Priorit aux applications fonctionnelles sur une documentation plthorique ; Priorit la collaboration avec le client sur la ngociation de contrat ; Priorit l'acceptation du changement sur la planication.
Pierre
Grard
Introduction UML 2
165 / 342
eXtreme Programming
eXtreme programming
eXtreme Programming, une mthode base sur des pratiques qui sont
autant de boutons pousss au maximum . Mthode qui peut sembler naturelle mais concrtement dicile appliquer et matriser :
Force de XP : sa simplicit et le fait qu'on va droit l'essentiel, selon

un rythme qui doit rester constant.
Pierre
lme euoup de disipline et de ommunition @ontrirement l premire impression qui peut fire penser une ullition de erveux individuelsAF eller vite mis sns perdre de vue l rigueur du odge et les fontions (nles de l9pplitionF
Grard
Introduction UML 2
166 / 342
Valeurs d'XP
eXtreme programming
Communication : Feedback :
fvorise l ommunition direteD plutt que le loisonnement des tivits et les hnges de douments formelsF ves dveloppeurs trvillent diretement ve l mtrise d9ouvrgeF ves prtiques sont onues pour donner un mximum de feedk sur le droulement du projet (n de orriger l trjetoire u plus ttF hu proessus Y hu odeF h9honorer les utres vleurs Y he mintenir une ommunition frnhe et ouverte Y h9epter et de triter de front les muvises nouvellesF
Simplicit : Courage :
Pierre
Grard
Pratiques d'XP
eXtreme programming
XP est fond sur des valeurs, mais surtout sur 13 pratiques rparties en 3 catgories :
qestion de projets Y rogrmmtion Y gollortionF
Pierre
Grard
Introduction UML 2
168 / 342
Pratiques de gestion de projets

Livraisons frquentes :
eXtreme programming
Planication itrative : Client sur site :
v9quipe vise l mise en prodution rpide d9une version minimle du logiielD puis elle fournit ensuite rgulirement de nouvelles livrisons en tennt ompte des retours du lientF n pln de dveloppement est prpr u dut du projetD puis il est revu et remni tout u long du dveloppement pour tenir ompte de l9expriene quise pr le lient et l9quipe de dveloppementF ve lient est intgr l9quipe de dveloppement pour rpondre ux questions des dveloppeurs et d(nir les tests fontionnelsF v9quipe dopte un rythme de trvil qui lui permet de fournir un trvil de qulit tout u long du projetF tmis plus de RHh de trvil pr semine @un dveloppeur ftigu dveloppe mlAF
Rythme durable :
Pierre
Grard
Pratiques de programmation
Conception simple : Remaniement :
eXtreme programming
yn ne dveloppe rien qui ne soit utile tout de suiteF ve ode est en permnene rorgnis pour rester ussi lir et simple que possileF ves dveloppeurs mettent en ple une tterie de tests de nonrgression qui leur permettent de fire des modi(tions sns rinteF ves testeurs mettent en ple des tests utomtiques qui vri(ent que le logiiel rpond ux exigenes du lientF ges tests permettent des reettes utomtiques du logiielF
Tests unitaires :
Tests de recette :
Pierre
Grard
Introduction UML 2
Pratiques de collaboration
eXtreme programming
Responsabilit collective du code : Programmation en binmes : Rgles de codage : Mtaphore :
ghque dveloppeur est suseptile de trviller sur n9importe quelle prtie de l9pplitionF ves dveloppeurs trvillent toujours en inmesD es inmes tnt renouvels frquemmentF ves dveloppeurs se plient des rgles de odge strites d(nies pr l9quipe elleEmmeF ves dveloppeurs s9ppuient sur une desription ommune du designF v9intgrtion des nouveux dveloppements est fite hque jourF
Intgration continue :
Pierre
Grard
Introduction UML 2
Cycle de vie XP
eXtreme programming
Pierre
Grard
Introduction UML 2
172 / 342
Exploration
eXtreme programming
Les dveloppeurs se penchent sur des questions techniques :
Le client s'habitue exprimer ses besoins sous forme de user strories (proches de diagrammes de cas illustrs par des diagrammes de squences).
ves dveloppeurs estiment les temps de dveloppementF
ixplorer les di'rentes possiilits d9rhiteture pour le systme X itudier pr exemple les limites u niveu des performnes prsentes pr hune des solutions possilesF
Pierre
Grard
Introduction UML 2
173 / 342
Planning
eXtreme programming
Planning de la premire release :
Dure du planning : 1 ou 2 jours. Premire version (release) au bout de 2 6 mois.
niquement les fontionnlits essentielles Y remire relese enrihir pr l suiteF
Pierre
Grard
Introduction UML 2
174 / 342
Itrations jusqu' la premire release

Dveloppement de la premire version de l'application. Itrations de une quatre semaines :
eXtreme programming
Brves runions quotidiennes runissant toute l'quipe, pour mettre chacun au courant de l'avancement du projet.
ghque itrtion produit un sous ensemle des fontionnlits priniples Y ve produit de hque itrtion suit des tests fontionnels Y strtions ourtes pour identi(er trs tt des dvition pr rpport u plnningF
Pierre
Grard
Introduction UML 2
175 / 342
Mise en production
eXtreme programming
La mise en production produit un logiciel :
Itrations trs courtes ; Tests constants en parallle du dveloppement ; Les dveloppeurs procdent des rglages ans pour amliorer les performances du logiciel.
y'rnt toutes les fontionnlits indispensles Y rfitement fontionnel Y wis disposition des utilisteursF
Pierre
Grard
Introduction UML 2
176 / 342
Maintenance
eXtreme programming
Continuer faire fonctionner le systme ; Adjonction de nouvelles fonctionnalits secondaires.
our les fontionnlits seondiresD on reommene pr une rpide explortionF v9jout de fontionnlits seondires donne lieu de nouvelles relesesF
Pierre
Grard
Introduction UML 2
177 / 342
Mort
eXtreme programming
Quand le client ne parvient plus spcier de nouveaux besoins, le projet est dit mort
oit que tous les esoins possiles sont remplis Y oit que le systme ne supporte plus de nouvelles modi(tions en restsnt rentleF
Pierre
Grard
Introduction UML 2
178 / 342
Equipe XP
eXtreme programming
Pour un travil en quipe, on distingue 6 rles principaux au sein d'une quipe XP :

hveloppeur Y glient Y esteur Y rker Y wnger Y gohF
Pierre
Grard
Introduction UML 2
179 / 342
Dveloppeur
eXtreme programming
Conception et programmation, mme combat ! Participe aux sances de planication, value les tches et leur dicult ; Dnition des test unitaires ; Implmentation des fonctionnalits et des tests unitaires.
Pierre
Grard
Introduction UML 2
180 / 342
Client
eXtreme programming
crit, explique et matrise les scnarios ; Spcie les tests fonctionnels de recette ; Dnit les priorits.
Pierre
Grard
Introduction UML 2
181 / 342
Testeur
eXtreme programming
criture des tests de recette automatiques pour valider les scnarios clients ; Peut inuer sur les choix du clients en fonction de la testatibilit des scnarios.
Pierre
Grard
Introduction UML 2
182 / 342
Tracker
eXtreme programming
Suivre le planning pour chaque itration ; Comprendre les estimations produites par les dveloppeurs concernant leur charges ; Interagir avec les dveloppeurs pour le respect du planning de l'itration courante ; Dtection des ventuels retards et rectications si besoin.
Pierre
Grard
Introduction UML 2
183 / 342
Manager
eXtreme programming
Suprieur hirarchique des dveloppeurs : Vrication de la satisfaction du client ; Contrle le planning ; Gestion des ressources.
esponsle du projetF
Pierre
Grard
Introduction UML 2
184 / 342
Coach
eXtreme programming
Garant du processus XP :
yrgnise et nime les snes de plni(tions Y pvorise l rtivit du groupeD n9impose ps ses solutions tehniques Y goup de gueulesF F F
Pierre
Grard
Introduction UML 2
185 / 342
Spcication avec XP
eXtreme programming
Pas de documents d'analyse ou de spcications dtailles. Les tests de recette remplacent les spcications. Emergence de l'architecture au fur et mesure du dveloppement.
Pierre
Grard
Introduction UML 2
186 / 342
XP vs RUP
eXtreme programming
Inconvnients de XP :
Inconvnients de RUP :
polistion sur l9spet individuel du dveloppementD u dtriment d9une vue glole et des prtiques de mngement ou de formlistion Y wnquer de ontrle et de struturtionD risques de driveF pit toutD mis lourdD usine gz Y rfois di0ile mettre en oeuvre de fon spi(queF
pour les petits projets en quipe de IP mx Y pour les gros projets qui gnrent euoup de doumenttionF
Pierre
Grard
Introduction UML 2
187 / 342
Plan
1 2 3 4
Modlisation avance avec UML
Expression de contraintes avec OCL
Introduction la Modlisation Oriente Objet Modlisation objet lmentaire avec UML UML et mthododologie Modlisation avance avec UML
Expression de contraintes avec OCL Diagrammes d'tats-transitions Digrammes d'activits Diagrammes de communication Diagrammes de composants et de dploiement
5
Pierre
Bonnes pratiques de la modlisation objet

Grard
Expression de contraintes avec UML
Les dirents diagrammes d'UML expriment en fait des contraintes Graphiquement
Via des proprits prdnies

C'est toutefois insusant
Sur des classes ({abstract}) Sur des rles ({ordered})
Contraintes structurelles (un attribut dans une classe) Contraintes de types (sous-typage) Contraintes diverses (composition, cardinalit, etc.)
Pierre
Grard
Introduction UML 2
189 / 342
Insusances d'UML pour reprsenter certaines contraintes

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

Simple mettre en oeuvre : Indispensable :
tilistion des notes en wv C texte lireD gomprhensile pr tousF houmenter les ontrintes est essentielD hteter les prolmes le plus tt possileF
Probmlatique
AmbiguD imprisD
hi0ile d9exprimer lirement des ontrintes omplexesD hi0ile de lier le texte ux lments du modleF
Pierre
Grard
Introduction UML 2
191 / 342
Exemples de contraintes exprimables en OCL

Le solde d'un compte ne doit pas tre infrieur au dcouvert maximum. Le signataire d'une carte bleue associe un compte en est le titulaire. Une carte bleue est accepte dans tous les distributeurs des consortiums de la banque. ...
Pierre
Grard
Introduction UML 2
192 / 342
Le solde d'un compte ne doit pas tre infrieur au dcouvert maximum autoris
Si l'attribut dMax de la classe Compte est un rel et que le dcouvert est exprim par une valeur ngative :
context c ~: Compte inv : solde >= dMax
Si le dcouvert est exprim par un nombre positif (par ex : 300 euros si on ne doit pas descendre en dessous de 300 euros)
context c ~: Compte inv : solde >= - dMax
Pierre
Grard
Introduction UML 2
193 / 342
Le signataire d'une carte bleue associe un compte est titulaire de ce compte

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

context CarteBleue inv : compte . titulaires -> includes ( signataire )
Pierre
Grard
Introduction UML 2
194 / 342
Une carte bleue est accepte dans tous les distributeurs des consortiums de la banque
context CarteBleue inv : distributeur = compte . banque . consortium . distributeur
Pierre
Grard
Introduction UML 2
195 / 342
OCL pour l'criture de contraintes

OCL : Object Constraint Language Parfaitement intgr UML En pleine expansion
vngge de requtes et de ontrintes eltivement simple rire et omprendre
syntaxe purement textuelle sans symboles tranges
mntique d9wv rite en ygv X tous les shms wv produits ont une trdution en ygv xouvelle version majeure ve wvPFH issentiel pour voir des modles su0semment pris he plus en plus d9outils
dition, vrication, gnration (partielle) de code...
Pierre
Grard
Introduction UML 2
196 / 342
Caractristiques d'OCL
Langage d'expressions (fonctionnel) Langage de spcication, pas de programmation

leursD expressionsD types portement typ s d9e'ets de ords
rut niveu d9strtion s forment exutle @seul un sousEensemle l9estA ermet de trouver des erreurs euoup plus tt dns le yle de vie
Pierre
Grard
Introduction UML 2
197 / 342
Avantages et inconvnients d'OCL

Points faibles
s ussi rigoureux que des lngges de spi(tion formelle omme hwD ou f
Pas de preuves formelles possibles dans tous les cas
Points forts
uissne d9expression limite eltivement simple rire et omprendre rs ien intgr wv fon ompromis entre simpliit et puissne d9expression ssge vers di'rentes plteformes tehnologiques
Pierre
Grard
Introduction UML 2
198 / 342
Contexte d'une contrainte
Une contrainte est toujours associe un lment de modle : le contexte de la contrainte. Deux techniques pour spcier le contexte :
in rivnt l ontrinte entre oldes {FFF} dns une noteF v9lment point pr l note est lors le ontexte de l ontrinte in utilsnt le mot l ontext dns un doument quelonqueF
context CarteBleue inv : compte . titulaires - > includes ( signataire ) inv : code >0 and code <=9999 inv : retraitMax >10
Pierre
Grard
Introduction UML 2
199 / 342
Dnition de prdicats avec OCL
OCL peut tre utilis pour dcrire trois types de prdicats avec les mots cl : inv: invrints de lsses
inv : solde < dMax
pre: prEonditions d9oprtions

pre : montantARetirer >0
post: postEonditions d9oprtions

post : solde > solde@pre
Pierre
Grard
Introduction UML 2
200 / 342
Dnition d'expressions avec OCL
OCL peut galement tre utilis pour dcrire des expressions avec les mots cls : def: dlrer des ttriuts ou des oprtions
def : nbEnfants : Integer
init: spi(er l vleur initile des ttriuts

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

body : enfants - > select ( age < a )
derive: d(nir des lements drivs @GA

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

ix X self.impots(1998) ix X self.dateDeNaissance
... )
Pierre
Grard
Introduction UML 2
202 / 342
Navigation via une association

< objet >. < nomderole >
Accder un ensemble d'objets lis un objet donn

ve rsultt est soit une vleur soit un ensemle ve type du rsultt dpend de l multipliit ile et de l prsene de l ontrinte {ordered}
Set(X) OrderedSet(X)
Pierre
Grard
Introduction UML 2
203 / 342
Notes sur la navigation via les associations

Un lement est converti en singleton lorsqu'une opration sur une collection est applique
pere - > size ()=1
La navigation permet de tester si la valeur est dnie (l'ensemble vide reprsente la valeur indnie)
pere - > isEmpty () epouse - > notEmpty () implies self . epouse . sexe = sexe :: feminin
Si une association n'a pas de nom de rle alors on peut utiliser le nom de la classe destination
Pierre
Grard
Introduction UML 2
204 / 342
Navigation vers une association rexive
Si l'association est rexive, pour viter les ambiguits, il faut indiquer avec un rle entre crochets [...] comment est parcourue l'association
objet . nomAssociation [ nomDeRole ]
p . evaluation [ chefs ] p . evaluation [ employes ] p . evaluation [ chefs ]. note -> sum ()
Pierre
Grard
Introduction UML 2
205 / 342
Navigation via une association qualie

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

lien . nomderole
b . compte [4029] b . compte compte
Pierre
Grard
Introduction UML 2
206 / 342
Invariant (inv)
Prdicat associ une classe ou une association

Le contexte est dni par un objet L'invariant peut tre nomm
hoit tre vri( tout instnt get ojet peut tre rfren pr self
context Personne inv pasTropVieux ~: age < 110 inv ~: self . age >= 0
Pierre
Grard
Introduction UML 2
207 / 342
Exemples d'invariants
context Personne inv ~: age >0 and self . age <110 inv mariageLegal ~: marie implies age > 16 inv enfantsOk ~: enfants - > size () < 20 inv ~: not enfants - > includes ( self ) inv ~: enfants - > includesAll ( filles ) inv ~: enfants - > forall ( e | self . age - e . age <14)
Pierre
Grard
Introduction UML 2
208 / 342
Pr-condition et post-condition
Prdicats associs une opration
ves ves
pr-conditions doivent tre vries avant l'excution post-conditions sont vraies aprs l'excution self dsigne l'objet sur lequel l'opration lieu Dans une post-condition :
@pre permet de fire rfrene l vleur vnt que oprtion ne soit e'etue result designe le resultt de l9oprtion ocsIsNew() indique si un ojet n9existit ps dns l9tt prdent context Classe :: operation (...): ClasseValRetour pre nom1 ~: param1 < ... post ~: ... result > ...
Pierre
Grard
Introduction UML 2
209 / 342
Exemples de pr et post-conditions
context Personne :: retirer ( montant : Integer ) pre ~: montant > 0 post ~: solde < solde@pre - montant context Personne :: salaire (): integer post ~: result >= Legislation :: salaireMinimum context Compagnie :: embaucheEmploye ( p : Personne ): Contrat pre pasPresent ~: not employes - > includes ( p ) post ~: employes = employes@pre - > including ( p ) post ~: result . oclIsNew () post ~: result . compagnie = self and result . employe = p
Pierre
Grard
Introduction UML 2
210 / 342
Dnition additionnelle (def)
Il est possible en OCL de dnir dans une classe existante: de nouveaux attributs de nouvelles oprations
context Classe def ~: nomAtt ~: type = expr def ~: nomOp ...~: type = expr
Utile pour dcomposer des requetes ou contraintes

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

Description d'une mthode sans eet de bord ({isQuery})
Equivalent une requte
context Personne : acf ( p : Personne ): OrderedSet ( Personne ) body ~: self . ancestres () -> select ( sexe = Sexe :: Feminin ) -> sortedBy ( dateDeNaissance ) context Personne def : ancestres ~: Set ( Personne ) = parents -> union ( parents . ancestres - > asSet ())
Pierre
Grard
Introduction UML 2
212 / 342
Syntaxe des expressions
OCL est un langage simple d'expressions
constantes identificateur self expr op expr exprobjet.propobjet exprobjet.propobjet ( parametres ) exprcollection -> propcollection(parametres) package::package::element if cond then expr else expr endif let var : type = expr in expr
Pierre
Grard
Introduction UML 2
213 / 342
Accs aux proprits et aux lments
. permet d'accder une proprit d'un objet -> permet d'accder une proprit d'une collection :: permet d'accder un lment d'un paquetage, d'une classe, ... Des rgles permettent de mixer collections et objets
self . impots (1998) / self . enfants - > size () self . salaire () -100 self . enfants - > select ( sexe = Sexe :: masculin ) self . enfants - > isEmpty () self . enfants - > forall ( age >20) self . enfants - > collect ( salaire ) - > sum () self . enfants . salaire - > sum () self . enfants - > union ( self . parents ) - > collect ( age )
Grard
Pierre
Introduction UML 2
Types entiers et rels

Integer Real
leurs X ID ESD QRD PRQRQD FFF yprtions X CD ED BD divD modD sD mxD min leurs X IFSD IFQRD FFF yprtions X CD ED BD GD )oorD roundD mxD min
Le type Integer est conforme au type Real
Pierre
Grard
Introduction UML 2
215 / 342
Type boolen
Boolean
L'valuation des oprateurs or, and, if est partielle

( age <40 implies salaire >1000) and ( age >=40 implies salaire >2000) if age <40 then salaire > 1000 else salaire > 2000 endif
leurs X trueD flse yprtions X notD ndD orD xorD impliesD ifEthenEelseEendif true or x est toujours vriD mme si x est ind(ni flse nd x est toujours fuxD mme si x est ind(ni
salaire > ( if age <40 then 1000 else 2000 endif )
Pierre
Grard
Introduction UML 2
216 / 342
Chanes de caractres
String
leurs XD9une phrse9 yprtions X
=
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
tring`bequene@hrterAD le type hrter n9existe ps
Pierre
Grard
Introduction UML 2
217 / 342
Utilisation des valeurs de types numrs
Jour::Mardi
Oprations
not #Mardi
vnt wvPFH
aD `b s de reltion d9ordre
epouse - > notEmpty () implies epouse . sexe = Sexe :: Feminin
Pierre
Grard
Introduction UML 2
218 / 342
Elments et singletons
Dans tout langage typ il faut distinguer un lment e du singleton ontennt et 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 quivlent Set{elem}->prop self->size() = 1
Pierre
Grard
Introduction UML 2
219 / 342
Collections
Ensembles : Set(T) Sac : Bag(T)
Ensembles ordonns : OrderedSet(T)

ilments uniques et ordonns
ilments unique non ordonns
Sequence : Sequence(T)
ilments rptles sns ordre ilments rptles mis ordonns
Collection est le type de base Collection(T)
Pierre
Grard
Introduction UML 2
220 / 342
Oprations de base sur les collections

Cardinalit : coll -> size() Vide : coll -> isEmpty() Non vide : coll -> nonEmpty() Nombre d'occurrences : coll -> count(elem) Appartenance : coll -> includes( elem ) Non appartenance : coll -> excludes( elem ) Inclusion : coll -> includesAll(coll) Exclusion: coll -> excludesAll(coll) Somme des lements : coll -> sum()
Pierre
Grard
Introduction UML 2
221 / 342
Oprations ensemblistes
Union : ens->union(ens) Dierence : ens1-ens2 Ajout d'un lment : ens->including(elem) Suppression d'un lment : ens->excluding(elem) Conversion vers une liste : ens->asSequence() Conversion vers un sac : ens->asBag() Conv.vers un ens. ord. : ens->asOrderedSet()
Pierre
Grard
Introduction UML 2
222 / 342
Filtrage
Select retient les lments vriant la condition Reject limine ces lements
coll -> select( cond ) coll -> reject( cond )
Any slectionne l'un des lments vriant la condition

coll -> any( cond ) oprtion non dterministe utile lors de olletion ne ontennt qu9un lment retourne l vleur ind(nie si l9ensemle est vide
self . enfants - > select ( age >10 and sexe = Sexe :: Masculin )
Pierre
Grard
Introduction UML 2
223 / 342
Autres syntaxes pour le ltrage

Il est galement possible de
nommer l vrile d9expliiter son type
self . employe - > select ( age > 50) self . employe - > select ( p | p . age >50 ) self . employe - > select ( p : Personne | p . age >50) self . employe - > reject ( p : Personne | p . age <=50)
Pierre
Grard
Introduction UML 2
224 / 342
Quanticateurs
ForAll est le quanticateur universel Exists est le quanticteur existentiel

coll -> exists( cond ) self . enfants - > forall ( age <10) self . enfants - > exists ( sexe = Sexe :: Masculin ) coll -> forAll( cond )
Il est possible
de nommer l vrile d9expliiter son type de prourir plusieurs vriles l fois
self . enfants -> exists ( e1 , e2 | e1 . age = e2 . age and e1 < > e2 )

Pierre
Grard
Introduction UML 2
Unicit
Retourne vrai si pour chaque valeur de la collection, l'expression retourne une valeur dirente
coll->isUnique(expr) iquivlene entre self . enfants - > isUnique ( prenom )} self . enfants -> forall ( e1 , e2 ~: Personne | e1 <> e2 implies e1 . prenom <> e2 . prenom )
Utile pour dnir la notion de cl en BD

Pierre
Grard
Introduction UML 2
T-uples
Champs nomms, pas d'ordre entre les champs

uples @vleursA
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}
Dnition de types tuples

TupleType ( x : Real , y : Real ) TupleType ( y : Real , x : Real ) TupleType ( nom : String , prenom : String , age : Integer )
Grard
e prtir d9wv PFH
Pierre
Introduction UML 2
Collections imbriques
Collections imbriques
tusqu9 wv PFH ps de olletions de olletions r peu utilis et plus omplexe omprendre wise plt intuitive lors de l nvigtion
self . parents . parents
A partir de UML 2.0 imbrications arbitraires des constructeurs de types

Set ( Set ( Personne )) Sequence ( OrderedSet ( Jour ))
wise plt pr defult li l9oprtion impliite ollet
Trs utile pour spcier des structures non triviales

Grard
Pierre
Introduction UML 2
Conservation de l'imbrication pour la navigation

L'opration collect met plat les collections
utile pour nviger
enfants . enfants . prenom = enfants - > collect ( enfants ) - > collect ( prenom ) = Bag \{ ' pierre ' , ' paul ' , ' marie ' , ' paul '}
CollectNested permet de conserver l'imbrication

enfants - > collectNested ( enfants . prenom ) = Bag { Bag { ' pierre ' , ' paul '} , Bag \{ ' marie ' , ' paul '}}
Pierre
Grard
Introduction UML 2
229 / 342
Itrateur gnral
L'itrateur le plus gnral est iterate
ves utres itrteurs @forllD existD seletD etFA en sont des s prtiulier oll Eb iterte@
coll - > iterate ( elem ~: Type1 ~; accumulateur : Type2 = < valInit > | < expr > )
Exemple
enfants - > iterate ( e : Enfant ; ac : Integer =0 | acc + e . age )
Pierre
Grard
Introduction UML 2
230 / 342
Ordre vs. Tri
Collections ordonnes Sequence OrderedSet . . . mais pas forcment tries

quene trie X
quene simple @l9ordre ompteA X

Sequence { 12, 23, 5, 5, 12 } Sequence { 5, 5, 12, 12, 23 }
Pierre
Grard
Introduction UML 2
231 / 342
Tri d'une collection
Pour trier une collection en fonction d'une expression
coll -> sortedBy(expr) v9oprtion ` doit tre d(nie sur le type orrespond 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 l9oprtion est pplique sur un et Sequence si l9oprtion est pplique sur un fg
Pierre
Grard
Introduction UML 2
232 / 342
Plan
1 2 3 4
Diagrammes d'tats-transitions
5
Pierre

Grard
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 Cet historique est caractris par un tat. Les objets changent d'tat en rponse des vnements extrieurs donnant lieu des transitions entre tats. Sauf cas particuliers, chaque instant, chaque objet est dans un et un seul tat.
Pierre
ne dpendent ps seulement de ses entresD mis ussi d9un historique des solliittions pssesF
Grard
Introduction UML 2
234 / 342
Etat et transition
Les tats sont reprsents par des rectangles aux coins arrondis Les transitions sont reprsentes par des arcs orients liant les tats entre eux. Certains tats, dits composites , peuvent contenir des sous-diagrammes. Les diagrammes d'tat-transition d'UML reprsentent en fait des automates pile avec embotement et concurrence et pas seulement des automates tats nis comme dans les premires versions d'UML
Pierre
Grard
Introduction UML 2
235 / 342
Diagramme d'tat-transition
L'organisation des tats et des transitions pour un classeur donn est reprsente dans un diagramme d'tats-transitions. Le modle dynamique comprend plusieurs diagrammes d'tats.
Attention
Chaque diagramme d'tats ne concerne qu'une seule classe.
Chaque automate tats nis s'excute concurremment et peut changer d'tat de faon indpendante des autres.
Pierre
Grard
Introduction UML 2
236 / 342
Exemple de diagramme d'tats-transitions
Pierre
Grard
Introduction UML 2
237 / 342
Etat initial et tat nal
L'tat initial est un pseudo-tat qui dnit le point de dpart par

dfaut pour l'automate ou le sous-tat.
vorsqu9un ojet est rD il entre dns l9tt initilF
l'automate ou du sous-tat est termine.
L'tat nal est un pseudo-tat qui indique que l'excution de
Pierre
Grard
Introduction UML 2
238 / 342
Evnement dclencheur
Les transitions d'un diagramme d'tats-transitions sont dclenches par des vnements dclencheurs.
n ppel de mthode sur l9ojet ournt gnre un vnement de type callF ve pssge de fux vri de l vleur de vrit d9une ondition oolenne gnre impliitement un vnement de type changeF v reption d9un signl synhroneD expliitement mis pr un utre ojetD gnre un vnement de type signalF v9oulement d9une dure dtermine prs un vnement donn gnre un vnement de type afterF r dfutD le temps ommene s9ouler ds l9entre dns l9tt ourntF
L'vnement dclencheur est indiqu cte de la che reprsentant la transition

Pierre
Grard
Introduction UML 2
239 / 342
Evnements call et signal

nomEvenement ( params )
Un vnement de type call ou signal est dclar ainsi : 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.
Pierre
Grard
Introduction UML 2
Evnements change et after

when ( conditionBooleenne )
Un vnement de type change est introduit de la faon suivante :

sl prend l forme d9un test ontinu et se dlenhe potentiellement hque hngement de vleurs des vriles intervennt dns l onditionF
Un vnement temporel de type after est spci par :

after ( duree )
ve prmtre s9vlue omme une dureD pr dfut oule depuis l9entre dns l9tt ourntF r exemple X fter@IH seondesAF
Pierre
Grard
Introduction UML 2
241 / 342
Transition simple
Une transition entre deux tats est reprsente par un arc qui les lie l'un l'autre. Sa syntaxe est la suivante :
ille indique qu9une instne peut hnger d9tt et exuter ertines tivitsD si un vnement dlenheur se produit et que les onditions de grde sont vri(esF
nomEvenement ( params ) [ garde ] / activite

v grde dsigne une ondition qui doit tre remplie pour pouvoir dlenher l trnsitionD v9tivit dsigne des instrutions e'etuer u moment du tirF
Pierre
Grard
Introduction UML 2
242 / 342
Point de dcision
On peut reprsenter des alternatives pour le franchissement d'une transition. On utilise pour cela des pseudo-tats particuliers : Les points de jonction @petit erle pleinA permettent de prtger des
segments de trnsitionF
Les points de choix @losngeA sont plus que des rouris d9ritureF
Ils ne sont qu'un raccourci d'criture. Ils permettent des reprsentations plus compactes.
Pierre
Grard
Introduction UML 2
243 / 342
Simplication avec les points de jonction
Pour emprunter un chemin, toutes les gardes le long de ce chemin doivent s'valuer vrai ds le franchissement du premier segment.
Pierre
Grard
Introduction UML 2
244 / 342
Simplication avec les points de jonction
Pierre
Grard
Introduction UML 2
244 / 342
Reprsentation d'alternatives avec les points de jonction
Pierre
Grard
Introduction UML 2
245 / 342
Utilisation des points de choix

est atteint.
Les gardes aprs le point de choix sont values au moment o il

gel permet de ser le hoix sur des rsultts otenus en frnhissnt le segment vnt le point de hoixF iD qund le point de hoix est tteintD uun segment en vl n9est frnhissleD le modle est mal formF
gontrirement ux points de jontionD les points de hoix ne sont ps de simples rouris d9ritureF
Pierre
Grard
Introduction UML 2
246 / 342
Transition interne
Un objet reste dans un tat durant une certaine dure et des transitions internes peuvent intervenir. Une transition interne ne modie pas l'tat courant, mais suit globalement les rgles d'une transition simple entre deux tats. Trois dclencheurs particuliers sont introduits permettant le tir de transitions internes : entry/, do/, et exit/.
Pierre
Grard
Introduction UML 2
247 / 342
Dclencheurs de transitions internes prdnis

entry dnit une activit eectuer chaque fois que l'on rentre dans l'tat considr. exit dnit une activit eectuer quand on quitte l'tat. do dnit une activit continue qui est ralise tant que l'on se trouve dans l'tat, ou jusqu' ce que le calcul associ soit termin.
yn pourr dns e dernier s grer l9vnement orrespondnt l (n de ette tivit @ompletion eventAF
Pierre
Grard
Introduction UML 2
248 / 342
Reprsentation des transitions internes
Les transitions internes sont spcies dans le compartiment infrieur de l'tat, sous le compartiment du nom. Chaque transition interne est dcrite selon la syntaxe suivante :
nomEvenement ( params ) [ garde ] / activiteARealiser
Pierre
Grard
Introduction UML 2
249 / 342
Etat composite
Un tat composite, par opposition un tat dit simple , est dcompos en deux ou plusieurs sous-tats.
out tt ou sousEtt peut insi tre dompos en sousEtts imriqus sns limite priori de profondeurF n tt omposite est reprsent pr les deux omprtiments de nom et d9tions internes hituellesD et pr un omprtiment ontennt le sousEdigrmmeF
Pierre
Grard
Introduction UML 2
250 / 342
Etat composite
Un tat composite, par opposition un tat dit simple , est dcompos en deux ou plusieurs sous-tats.
out tt ou sousEtt peut insi tre dompos en sousEtts imriqus sns limite priori de profondeurF n tt omposite est reprsent pr les deux omprtiments de nom et d9tions internes hituellesD et pr un omprtiment ontennt le sousEdigrmmeF
Pierre
Grard
Introduction UML 2
250 / 342
Etats composites et tats initiaux/naux

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

Depuis Etat11, quand event survient
yn produit l squene d9tivits uitteriIID uitteriID tionID intreriPD intrerPID initiliserD intrerPP v9ojet se trouve lors est dns ittPPF
Pierre
Grard
Introduction UML 2
252 / 342
Historique
Un pseudo-tat historique est not par un H cercl. Une transition ayant pour cible le pseudo-tat historique est quivalente une transition qui a pour cible le dernier tat visit dans la rgion contenant le H. H* dsigne un historique profond, cad un historique valable pour tous les niveaux d'imbrication.
Pierre
Grard
Introduction UML 2
253 / 342
Interface des tats composites

Pour pouvoir reprsenter un sous tat indpendamment d'un macro-tat, on a recours des points de connexion.
eve un pour les points de sortie ides pour les points d9entre
Ces interfaces permettent d'abstraire les sous-tats des macro-tats (rutilisabilit).

Pierre
Grard
Introduction UML 2
254 / 342
Etat concurrent
Avec un sparateur en pointills, on peu reprsenter plusieurs automates s'excutant indpendamment. Un objet peut alors tre simultanment dans plusieurs tats concurrents.
Pierre
Grard
Introduction UML 2
255 / 342
Transition concurrente
Une transition fork correspond la cration de deux tats concurrentes. Une transition join correspond une barrire de synchronisation qui supprime la concurrence.
our pouvoir ontinuer leur exutionD toutes les thes onurrentes doivent prllement tre prtes frnhir l trnsitionF
Pierre
Grard
Introduction UML 2
256 / 342
Plan
1 2 3 4
Digrammes d'activits
5
Pierre

Grard
Modlisation des traitements
Les diagrammes d'activit orent une manire graphique et non ambigu pour modliser les traitements. Une activit reprsente une excution d'un mcanisme, un droulement d'tapes squentielles. Le passage d'une activit l'autre autre est matrialis par une transition. Ces diagrammes sont assez semblables aux tats-transitions mais avec une interprtation dirente.
gomportement d9une mthode hroulement d9un s d9utilistion
Pierre
Grard
Introduction UML 2
258 / 342
Une vision transversale des traitements

Les diagrammes d'tats-transitions sont dnis pour chaque classeur et n'en font pas intervenir plusieurs. A l'inverse, les diagrammes d'activit permettent une description s'aranchissant (partiellement) de la structuration de l'application en classeurs. La vision des diagrammes d'activits se rapproche des langages de programmation imprative (C, C++, Java)
ves tts reprsentent des luls sl n9y ps d9vnements externes mis des ttentes de (ns de luls sl peut y voir de l onurrene entre tivits
Pierre
Grard
Introduction UML 2
259 / 342
Exemple de diagramme d'activits
Pierre
Grard
Introduction UML 2
260 / 342
Activit
Les activits dcrivent un traitement.
ve )ot de ontrle reste dns l9tivit jusqu9 e que les tritements soient terminsF yn peut d(nir des vriles loles une tivit et mnipuler les vriles essiles depuis le ontexte de l9tivit @lsse ontennte en prtiulierAF ves tivits peuvent tre imriques hirrhiquement X on prle lors d9tivits ompositesF
Pierre
Grard
Introduction UML 2
261 / 342
Transition
Les transitions sont reprsentes par des ches pleines qui connectent les activits entre elles.
illes sont dlenhes ds que l9tivit soure est termineF illes provoquent utomtiquement le dut immdit de l prohine tivit dlenher @l9tivit ileAF gontrirement ux tivitsD les trnsitions sont frnhies de mnire tomiqueD en prinipe sns dure pereptileF
Les transitions spcient l'enchanement des traitements et dnissent le ot de contrle.
Pierre
Grard
Introduction UML 2
262 / 342
Structure de contrle conditionnelle

Expression de conditions au moyen de transitions munies de gardes
conditionnelles
Les conditions sont notes entre crochets Pour mieux mettre en vidence un branchement conditionnel, on peut utiliser les points de choix (losanges).
ves points de hoix montrent un iguillge du )ot de ontrleF
ges trnsitions ne peuvent tre empruntes que si l grde est vrieF yn dispose d9une luse [else] qui est vlide si et seulement si toutes les utres grdes des trnsitions ynt l mme soure sont fussesF
Pierre
Grard
Introduction UML 2
263 / 342
Exemples de structures conditionnelles
Pierre
Grard
Introduction UML 2
264 / 342
Activits structures
Les activits structures utilisent les structures de contrle usuelles (conditionnelles et boucle) travers une syntaxe qui dpend de l'outil.
v syntxe prise de es nnottions ps d(nie dns l norme wvF hns une tivit strutureD on d(nit les rguments d9entre et les sorties pr des )hes endresF
Pierre
Grard
Introduction UML 2
265 / 342
Partitions
Pour modliser un traitement mettant en oeuvre plusieurs classeurs, on peut spcier le classeur responsable de chaque activit. Les partitions permettent d'attribuer les activits des lments particuliers du modle. Pour spcier qu'une activit est eectue par un classeur particulier, on la positionne dans la partiction correspondante.
ne prtition peut elleEmme tre dompose en sousEprtitionsF
Pierre
Grard
Introduction UML 2
266 / 342
Partitions multidimensionnelles
Pierre
Grard
Introduction UML 2
267 / 342
Partitions explicites
Cette notation est moins encombrante graphiquement Toutefois, elle met moins bien en valeur l'appartenance de groupes d'activits un mme conteneur.
Pierre
Grard
Introduction UML 2
268 / 342
Arguments et valeurs retournes
Les diagrammes d'activits prsents jusqu'ici montrent bien le comportement du ot de contrle. Pourtant, le ot de donnes n'apparat pas.
i une tivit est ien dpte l desription d9une oprtion d9un lsseurD il fut un moyen de spi(er les rguments et vleurs de retour de l9oprtionF g9est le rle des pins, des noeuds, des ots d'objets associs.
Pierre
Grard
Introduction UML 2
269 / 342
Pin
Un pin reprsente un point de connexion pour une action.
Quand l'activit se termine, une valeur doit tre aecte chacun des pibs de sortie
v9tion ne peut duter que si l9on 'ete une vleur hun de ses pins d9entreF ves vleurs sont psses pr opieF
Pierre
Grard
Introduction UML 2
270 / 342
Flot de donnes
Un ot d'objets permet de passer des donnes d'une activit une autre.
he fitD un r qui pour origine et destintion un pin orrespond un )ot de donnesF
Un noeud d'objets permettent de mieux mettre en valeur les donnes.

g9est un onteneur typ qui permet le trnsit des donnesF
Pierre
Grard
Introduction UML 2
271 / 342
Annotation des ots de donnes
Un ot d'objets peut porter une tiquette mentionnant deux annotations particulires : transformation indique une interprttion prtiulire de l
donne trnsmise pr le )otF indique l9ordre dns lequel les ojets sont hoisis dns le noeud pour le quitterF
selection
Pierre
Grard
Introduction UML 2
272 / 342
Concurrence
Les diagrammes d'activits permettent en principe de reprsenter des activits squentielles. Nanmoins, on peut reprsenter des activits concurrentes avec :
ves rres de synhronistionD ves noeuds de ontrle de type )ow (nl F
Pierre
Grard
Introduction UML 2
273 / 342
Barre de synchronisation
Plusieurs transitions peuvent avoir pour source ou pour cible une barre de synchronisation. vorsque l rre de synhronistion plusieurs trnsitions en sortieD on prle de trnsition de type fork qui orrespond une duplication du ot de contrle en plusieurs )ots indpendntsF vorsque l rre de synhronistion plusieurs trnsitions en entreD on prle de trnsition de type join qui orrespond un rendez-vous Pour plus de commodit, il est possible de fusionner des barres de synchronisation de type join et fork.
entre des )ots de ontrleF
yn lors plusieurs trnsitions entrntes et sortntes sur une mme rreF
Pierre
Grard
Introduction UML 2
274 / 342
Noeud de contrle de type ow nal

Un ot de contrle qui atteint un noeud de contrle de type ow nal est dtruit.
ves utres )ots de ontrle ne sont ps 'etsF
Ce type de noeud est moins fort qu'un noeud de contrle nal.

hns e sD tous les utres )ots de ontrle de l9tivit sont interrompus et dtruitsF
Pierre
Grard
Introduction UML 2
275 / 342
Actions de communication
Les actions de
communication grent
Les actions de communication peuvent tre employs comme des activits dans les diagrammes d'activit.
le pssge et le retour de prmtresD les mnismes d9ppels d9oprtions synhrones et synhronesF
Pierre
Grard
Introduction UML 2
276 / 342
Actions de communication
Les actions de type call correspondent des appels de procdure ou de mthode. Call operation orrespond l9ppel d9une oprtion sur un lsseurF Call behavior orrespond l9invotion d9un omportement spi( Les actions accept call et reply peuvent tre utilises du ct rcepteur pour dcomposer la rception de l'appel.
l9ide d9un digrmme wv hns les deux sD il est possile de spi(er des rguments et d9otenir des vleurs en retourF
Pierre
Grard
Introduction UML 2
276 / 342
Appel asynchrone
Les appels asynchrones de type send correspondent des envois de messages asynchrones. Le broadcast signal permet d'mettre vers plusieurs destinataires la fois L'action symtrique ct rcepteur est accept event, qui permet la rception d'un signal.
gette possiilit est rrement o'erte pr les lngges de progrmmtionF
Pierre
Grard
Introduction UML 2
277 / 342
Exceptions
Les exceptions permettent d'interrompre un traitement quand une situation qui dvie du traitement normal se produit. Elles assurent une gestion plus propre des erreurs qui peuvent se produire au cours d'un traitement. On utilise des pins d'exception (avec un triangle) un pour grer l'envoi d'exceptions et la capture d'exceptions.
Un ot de donnes correspondant une exception est matrialis par une che en zigue zague .
Pierre
Grard
Introduction UML 2
278 / 342
Exemple de traitement d'exceptions
Pierre
Grard
Introduction UML 2
279 / 342
Rgions interruptibles
Ce mcanisme est analogue celui des interruptions, mais il est moins dtaill. ves rgions interruptibles sont mieux dptes ux phses de Une rgion interruptible est reprsente par un cadre arrondi en pointills.
modlistion fontionnellesF
i l9vnement d9interruption se produitD toutes les tivits en ours dns l rgion interruptile sont stoppes ve )ot de ontrle suit l )he en zigzg qui quitte l rgionF
Pierre
Grard
Introduction UML 2
280 / 342
Exemple de rgion interruptible
Pierre
Grard
Introduction UML 2
281 / 342
Types de zones d'expansion

Parallel
Iterative Stream
ves exutions de l9tivit interne sur les lments de l olletion sont indpendntes et peuvent tre rlises dns n9importe quel ordre ou mme simultnmentF ves ourrenes d9exution de l9tivit interne doivent s9enhner squentiellementD en suivnt l9ordre de l olletion d9entreF ves lments de l olletion sont psss sous l forme d9un )ux de donnes l9tivit interneD qui doit tre dpte ux tritements de )uxF
Pierre
Grard
Introduction UML 2
282 / 342
Plan
1 2 3 4
Diagrammes de communication
5
Pierre

Grard
Diagrammes de squence
Les diagrammes de squence permettent de modliser l'change d'informations entre dirents classeurs sls sont un type de digrmmes d9interaction
Pierre
Grard
Introduction UML 2
284 / 342
Diagrammes d'interaction
Les diagrammes de communication et les diagrammes de squences sont deux types de diagramme d'interaction n diagramme de squence montre des intertions sous un ngle
temporelD en mettnt l9emphse sur le squenement temporel de messges hngs entre des lignes de vie n diagramme de communication montre une reprsenttion sptile des lignes de vieF sls reprsentent l mme hoseD mis sous des formes di'rentesF
de timing.
A ces diagrammes, UML 2.0 en ajoute un troisime : le diagramme

on usge est limit l modlistion des systmes qui s9exutent sous de fortes ontrintes de tempsD omme les systmes temps relF
Pierre
Grard
Introduction UML 2
285 / 342
Diagrammes de squence et de communication
Pierre
Grard
Introduction UML 2
286 / 342
Diagrammes de squence et de communication
Pierre
Grard
Introduction UML 2
286 / 342
Rles et connecteurs
Le rle permet de dnir le contexte d'utilisation de l'interaction. Une rle dans un diagramme de communication correspond une ligne de vie dans un diagramme de squences. Les relations entre les lignes de vie sont appeles connecteurs . Comme pour les diagrammes de squence, la syntaxe d'une ligne de vie est :
< nomRole >[ < selecteur >]: < nomClasseur >
n onneteur se reprsente de l mme fon qu9une ssoition mis l smntique est plus lrge X un onneteur est souvent une ssoition trnsitoireF
Pierre
Grard
Introduction UML 2
287 / 342
Types de messages
Comme dans les diagrammes de squence, on distingue deux types de messages : n messge synchrone loque l9expditeur jusqu9 l rponse du
destintireF ve )ot de ontrle psse de l9metteur u repteurF n messge asynchrone n9est ps loqunt pour l9expditeurF ve messge envoy peut tre pris en ompte pr le repteur tout moment ou ignorF
Pierre
Grard
Introduction UML 2
288 / 342
Reprsentation des messages

Les ches reprsentant les messages sont traces ct des connecteurs qui les supportent.
Attention
Bien faire la distinction entre les messages et les connecteurs : on pourrait avoir un connecteur sans message, mais jamais l'inverse.
Pierre
Grard
Introduction UML 2
289 / 342
Implmentation de messages synchrones

public class Conducteur { private Voiture voiture ; public void addVoiture ( Voiture voiture ){ if ( voiture != null ){ this . voiture = voiture ; } } public void conduire (){ voiture . demarrer (); } public static void main ( String [] argv ){ conducteur . conduire (); } } public class Voiture { public void demarrer (){...} }
Pierre
Grard
Introduction UML 2
290 / 342
Numros de squence des messages
Pour reprsenter les aspects temporels, on adjoint des numros de squence aux messages.
hes messges suessifs sont ordonns selon un numro de squene roissnt @ID PD QD FFF ou enore QFID QFPD QFQD FFFAF hes messges envoys en sde @ex X ppel de mthode l9intrieur d9une mthodeA portent un numro d9emotement ve une nottion pointe
1.1, 1.2, ... pour des messages appels par une mthode dont l'appel portait le numro 1 2.a.1, 2.a.2, ... pour des messages appels par une mthode dont l'appel portait le numro 2.a
Pierre
Grard
Introduction UML 2
291 / 342
Equivalence avec un diagramme de squence
Pierre
Grard
Introduction UML 2
292 / 342
Equivalence avec un diagramme de squence
Pierre
Grard
Introduction UML 2
292 / 342
Messages simultans
Lorsque des messages sont envoys en parallle, on les numrote avec des lettres
IFD IFDFFF pour des messges simultns envoys en rponse un messge dont l9envoi portit le numro I
Pierre
Grard
Introduction UML 2
293 / 342
Oprateurs de choix et de boucles
Pas d'oprateurs combins dans les diagrammes de communication

*[<clauseItration>] reprsente une itrtionF *[<clauseItration>] reprsente un hoixF v luse de ondition est une ondition oolenneF
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
Pierre
Grard
Introduction UML 2
294 / 342
Syntaxe des messages
Syntaxe complte des messages est :
numeroSquence [expression] : message

messge l mme forme que dns les digrmmes de squene Y numroquene reprsente le numro de squenement des messges Y expression prise une itrtion ou un emrnhementF
Exemples :
2 : affiche(x,y) X messge simpleF 1.3.1 : trouve("Hadock") X ppel emotF 4 [x < 0] : inverse(x,couleur) X onditionnelF 3.1 *[i:=1..10] : recommencer() X itrtionF
Pierre
Grard
Introduction UML 2
295 / 342
Collaboration
Une collaboration montre des instances qui collaborent dans un contexte donn pour mettre en oeuvre une fonctionnalit d'un systme. Une collaboration est reprsente par une ellipse en traits pointills comprenant deux compartiments.
< nomRole >: < nomType >[ < multiplicite >]
ve omprtiment suprieur ontient le nom de l ollortion ynt pour syntxe X ve omprtiment infrieur montre les prtiipnts l ollortionF
Pierre
Grard
Introduction UML 2
296 / 342
Exemple de collaboration
Pierre
Grard
Introduction UML 2
297 / 342
Diagramme de collaboration
Une collaboration peut aussi se reprsenter par une ellipse sans compartiment, portant le nom de la collaboration en son sein. Les instances sont relies l'ellipse par des lignes qui portent le nom du rle de chaque instance. On peut ainsi former des diagrammes de collaborations.
Pierre
Grard
Introduction UML 2
298 / 342
Collaborations et interactions
Les collaborations donnent lieu des interactions Les interactions se repsentent indiremment par des diagrammes de communication ou de squence
ves intertions doumentent les ollortions ves ollortions orgnisent les intertionsF
Pierre
Grard
Introduction UML 2
299 / 342
Plan
1 2 3 4
Diagrammes de composants et de dploiement
5
Pierre

Grard
Composant
Un composant logiciel est une unit logicielle autonome au sein d'un systme global ou d'un sous-systme. C'est un classeur structur particulier, muni d'une ou plusieurs interfaces requises ou oertes.
Pierre
Grard
Introduction UML 2
301 / 342
Diagramme de composant
Les diagrammes de composants reprsentent l'architecture logicielle du systme. ves omposnts peuvent tre domposs en sous-composantsD le s
hntF ves liens entre omposnts sont spi(s l9ide de entre leurs interfacesF
dpendances
de dlgation.
Le cblage interne d'un composant est spci par les connecteurs Un tel connecteur connecte un port externe du composant avec un port de l'un de ses sous-composants internes.
Pierre
Grard
Introduction UML 2
302 / 342
Exemple de modlisation d'un composant
Pierre
Grard
Introduction UML 2
303 / 342
Intrt des diagrammes de composants

Les diagrammes de composants permettent de
truturer une rhiteture logiielle un niveu de grnulrit moindre que les lsses
Les composants peuvent contenir des classes.
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.
pi(er l9intgrtion de riques logiielles tieres @omposnts itfD gyfeD gywC ou FxetD hvFFFA Y sdenti(er les omposnts rutilislesF
Pierre
Grard
Introduction UML 2
304 / 342
Architecture matrielle
En dernier lieu, un systme doit s'excuter sur des ressources matrielles dans un environnement matriel particulier. UML permet de reprsenter un environnement d'excution ainsi que des ressources physiques (avec les parties du systme qui s'y excutent) grce aux diagrammes de dploiement.
v9environnement d9exution ou les ressoures mtrielles sont ppels noeuds F ves prties d9un systme qui s9exutent sur un noeud sont ppeles rtefts F
Pierre
Grard
Introduction UML 2
305 / 342
Noeud
Un noeud est une ressource sur laquelle des artefacts peuvent tre dploys pour tre excuts. C'est un classeur qui peut prendre des attributs.
n noeud se reprsente pr un ue dont le nom respete l syntxe des noms de lssesF ves noeuds peuvent tre ssois omme des lsses et on peut spi(er des multipliitsF
Pierre
Grard
Introduction UML 2
306 / 342
Artefact
Un artefact est la spcication d'une entit physique du monde rel. Il se reprsente comme une classe par un rectangle contenant le mot-cl artefact suivi du nom de l'artefact.
Plusieurs strotypes standard existent pour les artefacts : document, excutable, chier, librairie, source.
n rteft dploy sur un noeud est symolis pr une )he en trit pointill qui porte le strotype dploy et qui pointe vers le noeudF v9rteft peut ussi tre inlus diretement dns le ue reprsentnt le noeudF
Pierre
Grard
Introduction UML 2
307 / 342
Instanciation de noeuds et d'artefacts
Les noms des instances de noeuds et d'artefacts sont souligns.
Pierre
Grard
Introduction UML 2
308 / 342
Excution des composants
On utilise des ches de dpendance pour montrer la capacit d'un noeud prendre en charge un type de composant.
Pierre
Grard
Introduction UML 2
309 / 342
Plan
1 2 3 4 5
Design Patterns
Introduction la Modlisation Oriente Objet Modlisation objet lmentaire avec UML UML et mthododologie Modlisation avance avec UML Bonnes pratiques de la modlisation objet
Design Patterns
Pierre
Grard
Introduction UML 2
310 / 342
Un concept issu de l'architecture

Christopher Alexander, architecte, dnit en 1977 les patrons de conception comme
Design Patterns
Ce concept attire les chercheurs en COO ds les annes 80 Design Patterns of Reusable Object-Oriented
Addison-Wesley, 1995
v desription d9un prolme rmnent et de s solution ne solution pouvnt tre utilise des millions de fois sns tre deux fois identique ne forme de oneptionD ptternD modleD ptron de oneption
GOF : Erich Gamma, Richard Helm, Ralph Johson et John Vlissides
Pierre
Grard
Introduction UML 2
311 / 342
Patron de conception logicielle
Design Patterns
Un patron de conception (design pattern) est la description d'une solution classique un problme rcurent. Ce n'est pas
sl drit une prtie de l solutionF F F ve des reltions ve le systme et les utres prtiesF g 9est une tehnique d 9rhiteture logiielleF
ne rique X l9pplition d9un pttern dpend de l9environnement ne rgle X un pttern ne peut ps s9ppliquer mniquement ne mthode X ne guide ps une prise de dision Y un pttern est l dision prise
Pierre
Grard
Introduction UML 2
312 / 342
Documentation d'un patron de conception

Les principaux lments de description d'un pattern sont : ve nom du pttern rsume le prolme de designF on intention est une ourte desription des ojetifs du ptternD de s
rison d9treF ves indication d9utilistion drivent les s o le pttern peut tre utileF v motivation montre un s prtiulier dns lequel le ptron peut tre utilisF v structure est une reprsenttion grphique des lsses du modleF
Design Patterns
Attention
Dans l'ouvrage du GOF (et ce cours), utilisation d'OMT, anctre d'UML
Pierre
Grard
Introduction UML 2
313 / 342
Avantages des patrons de conception

prouv leur ecacit
Design Patterns
Capitalisation de l'exprience : rutilisation de solutions qui ont Elaboration de constructions logicielles de meilleure qualit
grce un niveau d'abstraction plus lev
endre l oneption euoup plus rpide
Communication plus aise
dution du nomre d9erreursD d9utnt que les ptrons sont exmins ve ttention vnt d9tre pulis irire du ode filement omprhensile pr les utres
Apprentissage en suivant de bons exemples
Pierre
Grard
Introduction UML 2
314 / 342
Inconvnients des patrons de conception

Ncessit d'un eort de synthse consquent Ncessit d'un apprentissage et d'exprience Les patterns se dissolvent en tant utiliss Les patrons sont nombreux (23 dans l'ouvrage du GOF, d'autres sont publis rgulirement)
vesquels sont semlles c ves ptrons sont prfois de niveux di'rents X ertins ptterns s 9ppuient sur d 9utresFFF eonntreD strireF F F
Design Patterns
Pierre
Grard
Introduction UML 2
315 / 342
Catgories de patrons de conception

Patrons de cration
Design Patterns
Patrons de structure
sls d(nissent omment fire l9instnition et l on(gurtion des lsses et des ojetsF sls d(nissent l9usge des lsses et des ojets dns des grndes strutures insi que l sprtion entre l9interfe et l9implmenttionF sls d(nissent l mnire de grer les lgorithmes et les divisions de responsilitsF
Patrons de comportement
Pierre
Grard
Introduction UML 2
316 / 342
Classication des patrons du GOF

Cration :
Objets X estrt ftoryD fuilderD rototypeD ingleton Classes X ptory method Objets X edpterD fridgeD gompositeD heortorD pdeD plyweightD
roxy
Design Patterns
Structure :
Comportement :
Classes X edpter Objets X ghin of responsilityD gommndD stertorD wementoD

yserverD tteD trtegy Classes X snterpreterD emplte method
Pierre
Grard
Introduction UML 2
317 / 342
Creational patterns
Design Patterns
Formes de cration pour :
estrire le processus d'instanciation des ojetsF endre indpendnt de l fon dont les ojets sont rsD ompossD ssemlsD reprsentsF inpsuler l onnissne de l lsse onrte qui instnieF gher e qui est rD qui reD omment et qundF
Pierre
Grard
Introduction UML 2
318 / 342
Exemples de Creational patterns
Design Patterns
AbstractFactory pour passer un paramtre la cration qui dnit ce
que l'on va crer Builder pour passer en paramtre un objet qui sait construire l'objet partir d'une description FactoryMethod pour que la classe sollicite appelle des mthode abstraites Prototype : des prototypes varis existent qui sont copis et assembls Singleton pour garantir qu'il n'y ait qu'une seule instance de la classe
Pierre
Grard
Introduction UML 2
319 / 342
Singleton
Design Patterns
Intention :
Indications :
qrntir qu9une lsse n9 qu9une seule instne et fournit un point d9s glol ette lsseF 9il doit n9y voir extement qu9une instne de l lsse et qu9elle doit tre essile ux lients de mnire gloleF i l9instne doit pouvoir tre sousElsse et si l9extension doit tre essile ux lients sns qu9ils n9ient modi(er leur odeF pooler d9impressionD gestionnire d90hge qnrteur de nomres ltoires ve grine
Motivation :
Pierre
Grard
Introduction UML 2
320 / 342
Singleton : Structure
Design Patterns
Pierre
Grard
Introduction UML 2
321 / 342
Singleton : Implmentation
Design Patterns
public class Singleton { private static Singleton uniqueInstance = null ; private Singleton () {...} public static Singleton Instance () { if ( uniqueInstance == null ) uniqueInstance = new Singleton (); return uniqueInstance ; } }
A ajouter :
ettriuts et mthodes spi(ques de l lsse singleton en questionF rmtres de onstruteur si esoin F
Pierre
Grard
Introduction UML 2
322 / 342
Structural patterns
Design Patterns
Formes de structure :
gomment les ojets sont ssemls ves ptterns sont omplmentires les uns des utre
Pierre
Grard
Introduction UML 2
323 / 342
Exemples de Structural patterns
Design Patterns
Adapter pour rendre un objet conforme un autre Bridge pour lier une abstraction une implantation Composite : bas sur des objets primitifs et composants Decorator pour ajouter des services un objet Facade pour cacher une structure complexe Flyweight pour de petits objets destins tre partags Proxy quand un objet en masque un autre
Pierre
Grard
Introduction UML 2
324 / 342
Adapter
Design Patterns
Intention :
Indications :
gonvertir l9interfe d9une lsse en une utre qui soit onforme ux ttentes d9un lientF v9dptteur permet des lsses de ollorer mlgr des interfes inomptilesF yn veut utiliser une lsse existnteD mis son interfe ne onide ps ve elle esompteF yn souhite rer une lsse rutilisle qui ollorer ve des lsses enore inonnuesD mis qui n9uront ps nessirement l9interfe esompte
Pierre
Grard
Introduction UML 2
325 / 342
Adapter : Motivation
Design Patterns
Pierre
Grard
Introduction UML 2
326 / 342
Adapter : Structure
Design Patterns
Pierre
Grard
Introduction UML 2
327 / 342
Bridge
Design Patterns
Intention :
Indications :
houple une strtion de son implmenttion (n que les deux lments puissent tre modi(s indpendmment l9un de l9utre yn souhite viter un lien d(nitif entre une strtion et son implmenttionD les deux devnt pouvoir tre tendues pr hritge ves modi(tions de l9implmenttion d9une strtion ne doievent ps voir de onsquene sur le ode lient @ps de reompiltionA
Pierre
Grard
Introduction UML 2
328 / 342
Bridge : Motivation
Design Patterns
Pierre
Grard
Introduction UML 2
329 / 342
Bridge : Motivation
Design Patterns
Pierre
Grard
Introduction UML 2
329 / 342
Bridge : Structure
Design Patterns
Pierre
Grard
Introduction UML 2
330 / 342
Composite
Design Patterns
Intention :
Indications :
gomposition d9ojets en strutures roresentes pour reprsenter des strutures omposntGomposF ermettre u lient de triter de l mme mnire les ojets tomiques et les ominisons de euxEiF yn souhite reprsenter des hirrhies d9individus l9ensemle yn souhite que le lient n9it ps se prouper de l di'rene entre ominisons d9ojets et ojets individuels
Pierre
Grard
Introduction UML 2
331 / 342
Composite : Motivation
Design Patterns
Pierre
Grard
Introduction UML 2
332 / 342
Composite : Motivation
Design Patterns
Pierre
Grard
Introduction UML 2
332 / 342
Composite : Structure
Design Patterns
Pierre
Grard
Introduction UML 2
333 / 342
Behavioural patterns
Design Patterns
Formes de comportement pour dcrire :
des lgorithmes des omportements entre ojets des formes de ommunition entre ojet
Pierre
Grard
Introduction UML 2
334 / 342
Exemples de Behavioural patterns

Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor
Pierre
Design Patterns
Pour plus de dtails, lire
Design Patterns. Catalogue de modles de conception rutilisables.

Richard Helm, Ralph Johnson, John Lissides, Eric Gamma Craig Larman, M.C. Baland, L. Carite, E. Burr
UML 2 et les Dseign Patterns
Grard
Introduction UML 2
Observer
Design Patterns
Intention :
Indications :
h(nir une dpendne de type un plusieurs de fon e queD qund un ojet hnge d9ttD tous eux qui en dpendent en soient noti(s et utomtiquement mis jourF und un onept plusieurs reprsenttionsD l9une dpendnt de l9utreF und un l modi(tion d9un ojet nessite l modi(tion dutres ojetsD sns qu9on en onnisse le nomre extF und un ojet doit noti(er d9utres ojets ve lesquels il n9est ps fortement ouplF
Pierre
Grard
Introduction UML 2
336 / 342
Observer Motivation
Design Patterns
Pierre
Grard
Introduction UML 2
337 / 342
Observer Structure
Design Patterns
Pierre
Grard
Introduction UML 2
338 / 342
Strategy
Design Patterns
Intention :
Indications :
h(nir une fmille d9lgorithmes en enpsulnt hun d9eux et en les rendnt interhngelesF lusieurs lsses pprentes ne di'rent que pr leur omportementF yn esoin de plusieurs vrintes d9un lgorithmeF n lgorithme utilise des donnes que les lients n9ont ps onntreF ne lsse d(nit un ensemle de omportements qui (gurent dns des oprtions sous l forme de dlrtions onditionnelles multiplesF
Pierre
Grard
Introduction UML 2
339 / 342
Strategy : Motivation
Design Patterns
Pierre
Grard
Introduction UML 2
340 / 342
Strategy : Structure
Design Patterns
Pierre
Grard
Introduction UML 2
341 / 342
Utilisation des design patterns
Design Patterns
Les design patterns ne sont que des lments de conception On les combine pour produire une conception globale de qualit
rouver les ons ojets wieux rutiliserD concevoir
pour l'volution
euser des ptrons de oneption peut prfois nuire l lisiilit des solutions de oneption proposes
On peut aussi produire de nouveaux design patterns

et Strategy
ves h du qyp ne sont ps les seulsD pr exemple X Architecture 3-tiers Modle Vue Contrleur (MVC) : Combinaison de Composite,
Observer
yn trouve sns trop de ml des iliothques de ptterns sur snternet

Pierre
Grard
Introduction UML 2
342 / 342

Uml Cours Slides PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Uml Cours Slides PDF

Transféré par

Droits d'auteur :

Formats disponibles

Modlisation Oriente Objet de Systmes Logiciels

DUT Informatique  S2D

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

 UML 2.0, guide de rfrence   UML 2.0 

 UML 2.0 Superstructure  et  UML 2.0 Infrastructure 

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

 UML 2.0 Object Constraint Language (OCL) 

Cours de Jean-Marie Favre, IMAG

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

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

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

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

us X IT 7 Y rolmtique X SQ 7 @udget ou dlis non respetsD dfut de fontionnlitsA Y he X QI 7 @ndonnAF

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Critres de qualit d'un logiciel

Introduction la Modlisation Oriente Objet

Performance Portabilit Rutilisabilit Facilit de maintenance

sntertions ve d9utres logiiels Y

(P13  IUT Villetaneuse)

Introduction la Modlisation Oriente Objet

Dnition des besoins Conception Codage Intgration Tests Maintenance

Origine des erreurs

67% (Zeltovitz, De Marco)

(P13  IUT Villetaneuse)

Introduction la Modlisation Oriente Objet

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Introduction la Modlisation Oriente Objet

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Modlisation par dcomposition fonctionnelle

Introduction la Modlisation Oriente Objet

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

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Modlisation oriente objets

Introduction la Modlisation Oriente Objet

(P13  IUT Villetaneuse)

DUT Informatique  S2D

Unied Modeling Language

Introduction la Modlisation Oriente Objet

Rduire la complexit de la modlisation Y tilisle pr l9homme comme la machine X

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

UML 2.0, guide de rfrence UML 2.0

UML 2.0 Superstructure et UML 2.0 Infrastructure

(P13 IUT Villetaneuse)

DUT Informatique S2D

UML 2.0 Object Constraint Language (OCL)

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

Dnition des besoins Conception Codage Intgration Tests Maintenance

(P13 IUT Villetaneuse)

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

Unied Modeling Language

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

Le sens des ches indique le dpendance, pas le sens de la relation d'inclusion.

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

(P13 IUT Villetaneuse)

DUT Informatique S2D

Identication des acteurs

(P13 IUT Villetaneuse)

DUT Informatique S2D