Introduction à UML 2 - gerard/docs/cours/uml-cours-support.pdf · 4.2 Diagrammes...

Introduction UML 2

Modlisation Oriente Objet de Systmes Logiciels

Pierre Grard

Universit de Paris 13 IUT Villetaneuse

DUT Informatique S2D - 2008/2009

Table des matires

1 Introduction la Modlisation Oriente Objet 1

2 Modlisation objet lmentaire avec UML 52.1 Diagrammes de cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Diagrammes d'objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4 Diagrammes de squences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 UML et mthododologie 333.1 Des besoins au code avec UML : une mthode minimale . . . . . . . . . . . . . . 333.2 Rational Unied Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3 eXtreme programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 Modlisation avance avec UML 534.1 Expression de contraintes avec OCL . . . . . . . . . . . . . . . . . . . . . . . . . 534.2 Diagrammes d'tats-transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3 Digrammes d'activits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.4 Diagrammes de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.5 Diagrammes de composants et de dploiement . . . . . . . . . . . . . . . . . . . . 87

5 Bonnes pratiques de la modlisation objet 895.1 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

1 INTRODUCTION LA MODLISATION ORIENTE OBJET

1 Introduction la Modlisation Oriente Objet

Bibliographie UML UML 2.0, guide de rfrence James Rumbaugh, Ivar Jacobson, Grady Booch Editions Campus Press (2005)

UML 2.0 Benot Charoux, Aomar Osmani, Yann Thierry-Mieg Editions Pearson, Education France (2008)

UML 2.0 Superstructure et UML 2.0 Infrastructure OMG (Object Management Group) www.uml.org (2004).

Bibliographie OCL UML 2.0 Object Constraint Language (OCL) OMG (Object Management Group) www.uml.org (2004)

Cours de Jean-Marie Favre, IMAG http://megaplanet.org/jean-marie-favre

Matriel et logiciel Systmes informatiques : 80 % de logiciel ; 20 % de matriel.

Depuis quelques annes, la fabrication du matriel est assure par quelques fabricantsseulement. Le matriel est relativement able. Le march est standardis.

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

La crise du logiciel tude sur 8 380 projets (Standish Group, 1995) : Succs : 16 % ; Problmatique : 53 % (budget ou dlais non respects, dfaut de fonctionnalits) ; chec : 31 % (abandonn).

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

Gnie Logiciel (Software Engineering) : Comment faire des logiciels de qualit ? Qu'attend-on d'un logiciel ? Quels sont les critres de qualit ?

Critres de qualit d'un logiciel Utilit Adquation entre le logiciel et les besoins des utilisateurs ;

Utilisabilit Fiabilit Interoprabilit Interactions avec d'autres logiciels ;

Introduction UML 2 1 / 96


Performance Portabilit Rutilisabilit Facilit de maintenance Un logiciel ne s'use pas pourtant, la maintenance absorbe une trs grosse partie deseorts de dveloppement.

Poids de la maintenance

Rartition eortdv.

Origine deserreurs

Cot de lamaintenance

Dnition desbesoins

6% 56% 82%

Conception 5% 27% 13%Codage 7% 7% 1%

Intgration Tests 15% 10% 4%Maintenance 67%

(Zeltovitz, De Marco)

Cycle de vie

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

Pour obtenir un logiciel de qualit, il faut en matriser le processus d'laboration. La vie d'un logiciel est compose de direntes tapes. La succession de ces tapes forme le cycle de vie du logiciel. Il faut contrler la succession de ces direntes tapes.

Etapes du dveloppement

tude de faisabilit Spcication Dterminer les fonctionnalits du logiciel.

Conception Dterminer la faon dont dont le logiciel fournit les direntes fonctionnalits recherches.

Codage Tests Essayer le logiciel sur des donnes d'exemple pour s'assurer qu'il fonctionne correctement.

Maintenance

Modlisation

2 / 96 Introduction UML 2


Modle

Un modle est une reprsentation abstraite de la ralit qui exclut certains dtails du monderel. Il permet de rduire la complexit d'un phnomne en liminant les dtails qui n'inu-encent pas son comportement de manire signicative.

Il rete ce que le concepteur croit important pour la comprhension et la prdictiondu phnomne modlis, les limites du phnomne modlis dpendent des objectifs dumodle.

Langages de modlisation

Un langage de modlisation doit dnir : La smantique des concepts ; Une notation pour la reprsentation de concepts ; Des rgles de construction et d'utilisation des concepts.

Des langages dirents niveaux de formalisation Langages formels (Z,B,VDM) : le plus souvent mathmatiques, au grand pouvoird'expression et permettant des preuves formelles sur les spcications ;

Langages semi-formels (MERISE, UML...) : le plus souvent graphiques, au pouvoird'expression moindre mais plus faciles d'emploi.

L'industrie du logiciel dispose de nombreux langages de modlisation : Adapts aux systmes procduraux (MERISE...) ; Adapts aux systmes temps rel (ROOM, SADT...) ; Adapts aux systmes objets (OMT, Booch, UML...).

Le rle des outils (Ateliers Gnie Logiciel) est primordial pour l'utilisabilit en pratiquedes langages de modlisation.

Modlisation par dcomposition fonctionnelle

Approche descendante : Dcomposer la fonction globale jusqu' obtenir des fonctions simples apprhender etdonc programmer.

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



Modlisation oriente objets La Conception Oriente Objet (COO) est la mthode qui conduit des architectures logi-cielles fondes sur les objets du systme, plutt que sur une dcomposition fonctionelle.

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

On peut partir des objets du domaine (briques de base) et remonter vers le systme global :approche ascendante.

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

Unied Modeling Language Au milieu des annes 90, les auteurs de Booch, OOSE et OMT ont dcid de crer unlangage de modlisation uni avec pour objectifs : Modliser un systme des concepts l'excutable, en utilisant les techniques orienteobjet ;

Rduire la complexit de la modlisation ; Utilisable par l'homme comme la machine : Reprsentations graphiques mais disposant de qualits formelles susantes pour tretraduites automatiquement en code source ;

Ces reprsentations ne disposent cependant pas de qualits formelles susantes pourjustier d'aussi bonnes proprits mathmatiquesque des langeges de spcicationformelle (Z, VDM...).

Ociellement UML est n en 1994.

UML v2.0 date de 2005. Il s'agit d'une version majeure apportant des innovations radicaleset tendant largement le champ d'application d'UML.


2 MODLISATION OBJET LMENTAIRE AVEC UML

2 Modlisation objet lmentaire avec UML

2.1 Diagrammes de cas d'utilisation

Modlisation des besoins

Avant de dvelopper un systme, il faut savoir prcisment QUOI il devra servir, cad quelsbesoins il devra rpondre.

Modliser les besoins permet de : Faire l'inventaire des fonctionnalits attendues ; Organiser les besoins entre eux, de manire faire apparatre des relations (rutilsationspossibles, ...).

Avec UML, on modlise les besoins au moyen de diagrammes de cas d'utilsation.

Exemple de diagramme de cas d'utilisation

Cas d'utilisation Un cas d'utilisation est un service rendu l'utilisateur, il implique des sries d'actions pluslmentaires.

Un acteurs est une entit extrieure au systme modlis, et qui interagit directement aveclui.

Un cas d'utilisation est l'expression d'un service ralis de bout en bout, avec un dclenche-ment, un droulement et une n, pour l'acteur qui l'initie.

Acteurs et cas d'utilisation


2 MODLISATION OBJET LMENTAIRE AVEC UML2.1 Diagrammes de cas d'utilisation

Relations entre cas d'utilisation en acteurs

Les acteurs impliqus dans un cas d'utilisation lui sont lis par une association. Un acteur peut utiliser plusieurs fois le mme cas d'utilisation.

Relations entre cas d'utilisation

Inclusion : le cas A inclut le cas B (B est une partie obligatoire de A).

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

Gnralisation : le cas A est une gnralisation du cas du cas B (B est une sorte de A).

Dpendances d'inclusion et d'extension

Les inclusions et les extensions sont reprsentes par des dpendances. Lorsqu'un cas B inclut un cas A, B dpend de A. Lorsqu'un cas B tend un cas A, B dpend aussi de A. On note toujours la dpendance par une che pointille B 99K A qui se lit B dpendde A .

Losqu'un lment A dpend d'un lment B, toute modication de B sera susceptibled'avoir un impact sur A.

Les incude et les extend sont des strotypes (entre guillements) des relations dedpendance.

Attention

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

Rutilisabilit avec les inclusions et les extensions

Les relations entre cas permettent la rutilisabilit du cas s'authentier : il sera inutilede dvelopper plusieurs fois un module d'authentication.


2.1 Diagrammes de cas d'utilisation2 MODLISATION OBJET LMENTAIRE AVEC UML

Dcomposition grce aux inclusions et aux extensions

Quand un cas est trop complexe (faisant intervenir un trop grand nombre d'actions), onpeut procder sa dcomposition en cas plus simples.

Gnralisation

Un virement est est un cas particulier de paiement.

Un virement est une sorte de paiement.

La che pointe vers l'lment gnral. Cette relation de gnralisation/spcialisation est prsente dans la plupart des diagrammesUML et se traduit par le concept d'hritage dans les langages orients objet.

Relations entre acteurs

Une seule relation possible : la gnralisation.


2 MODLISATION OBJET LMENTAIRE AVEC UML2.1 Diagrammes de cas d'utilisation

Identication des acteurs Les principaux acteurs sont les utilisateurs du systme.

Attention

Un acteur correspond un rle, pas une personne physique.

Une mme personne physique peut tre reprsente par plusieurs acteurs si elle a plusieursrles.

Si plusieurs personnes jouent le mme rle vis--vis du systme, elles seront reprsentespar un seul acteur.

En plus des utilisateurs, les acteurs peuvent tre : Des priphriques manipuls par le systme (imprimantes...) ; Des logiciels dj disponibles intgrer dans le projet ; Des systmes informatiques externes au systme mais qui interagissent avec lui, etc.

Pour faciliter la recherche des acteurs, on se fonde sur les frontires du systme.

Acteurs principaux et secondaires L'acteur est dit principal pour un cas d'utilisation lorsque l'acteur est l'initiative deschanges ncessaires pour raliser le cas d'utilisation.

Les acteurs secondaires sont sollicits par le systme alors que le plus souvent, les acteursprincipaux ont l'initiative des interactions. Le plus souvent, les acteurs secondaires sont d'autres ystmes informatiques avec lesquelsle systme dvelopp est inter-connect.

Recenser les cas d'utilisation Il n'y a pas une manire mcanique et totalement objective de reprer les cas d'utilisation. Il faut se placer du point de vue de chaque acteur et dterminer comment il se sert dusystme, dans quels cas il l'utilise, et quelles fonctionnalits il doit avoir accs.

Il faut viter les redondances et limiter le nombre de cas en se situant au bon niveaud'abstraction (par exemple, ne pas rduire un cas une seule action).

Il ne faut pas faire apparatre les dtails des cas d'utilisation, mais il faut rester au niveaudes grandes fonctions du systme.

Trouver le bon niveau de dtail pour les cas d'utilisation est un problme dicile qui ncessitede l'exprience.


2.1 Diagrammes de cas d'utilisation2 MODLISATION OBJET LMENTAIRE AVEC UML

Description des cas d'utilisation Le diagramme de cas d'utilisation dcrit les grandes fonctions d'un systme du point devue des acteurs, mais n'expose pas de faon dtaille le dialogue entre les acteurs et les casd'utilisation.

Un simple nom est tout fait insusant pour dcrire un cas d'utilisation.

Chaque cas d'utilisation doit tre document pour qu'il n'y ait aucune ambigut concer-nant son droulement et ce qu'il recouvre prcisment.

Description textuelle Identication : Nom du cas : Payer CB Objectif : Dtailler les tapes permettant client de payer par carte bancaire Acteurs : Client, Banque (secondaire) Date : 18/09 Responsables : Toto Version : 1.0

Squencements : Le cas d'utilisation commence lorsqu'un client demande le paiement par carte bancaire Pr-conditions Le client a valid sa commande

Enchanement nominal

1. Le client saisit les informations de sa carte bancaire

2. Le systme vrie que le numro de CB est correct

3. Le systme vrie la carte auprs du systme bancaire

4. Le systme demande au systme bancaire de dbiter le client

5. Le systme notie le client du bon droulement de la transaction

Enchanements alternatifs

1. En (2) : si le numro est incorrect, le client est averti de l'erreur, et invit recom-mencer

2. En (3) : si les informations sont errones, elles sont re-demandes au client

Post-conditions La commande est valide Le compte de l'entreprise est crdit

Rubriques optionnelles Contraintes non fonctionnelles : Fiabilit : les accs doivent tre scuriss Condentialit : les informations concernant le client ne doivent pas tre divulgus

Contraintes lies l'interface homme-machine : Toujours demander la validation des oprations bancaires


2.2 Diagrammes de classes 2 MODLISATION OBJET LMENTAIRE AVEC UML

2.2 Diagrammes de classes

Objectif Les diagrammes de cas d'utilisation modlisent QUOI sert le systme. Le systme est compos d'objets qui interagissent entre eux et avec les acteurs pour raliserces cas d'utilisation.

Les diagrammes de classes permettent de spcier la structure et les liens entre lesobjets dont le systme est compos.

Exemple de diagramme de classes

Concepts et instances Une instance est la concrtisation d'un concept abstrait. Concept : Stylo Instance : le stylo que vous utilisez ce moment prcis est une instance du concept stylo :il a sa propre forme, sa propre couleur, son propre niveau d'usure, etc.

Un objet est une instance d'une classe Classe : Vido Objets : Pink Floyd (Live Pompey), 2001 Odysse de l'Espace etc.

Une classe dcrit un type d'objets concrets.

Une classe spcie la manire dont tous les objets de mme type seront dcrits (dsig-nation, label, auteur, etc).

Un lien est une instance d'association. Association : Concept avis d'internaute qui lie commentaire et article Lien : instance [Jean avec son avis ngatif], [Paul avec son avis positif]

Classes et objets Une classe est la description d'un ensemble d'objets ayant une smantique, des attributs,des mthodes et des relations en commun. Elle spcie l'ensemble des caractristiques quicomposent des objets de mme type. Une classe est compose d'un nom, d'attributs et d'oprations. Selon l'avancement de la modlisation, ces informations ne sont pas forcement toutesconnues.


2 MODLISATION OBJET LMENTAIRE AVEC UML 2.2 Diagrammes de classes

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

Proprits : attributs et oprations Les attributs et les oprations sont les proprits d'une classe. Leur nom commence parune minuscule. Un attribut dcrit une donne de la classe. Les types des attributs et leurs initialisations ainsi que les modicateurs d'accs peu-vent tre prciss dans le modle

Les attributs prennent des valeurs lorsque la classe est instancie : ils sont en quelquesorte des variables attaches aux objets.

Une opration est un service oert par la classe (un traitement que les objets correspon-dant peuvent eectuer).

Compartiment des attributs Un attribut peut tre initialis et sa visibilit est dnie lors de sa dclaration. Syntaxe de la dclaration d'un attribut :

modifAcces nomAtt:nomClasse[multi]= valeurInit

Compartiment des oprations

Une opration est dnie par son ainsi que par les types de ses paramtres et le type de sa valeurde retour.

La syntaxe de la dclaration d'une opration est la suivante :

modifAcces nomOperation(parametres ): ClasseRetour

La syntaxe de la liste des paramtres est la suivante :

nomClasse1 nomParam1 , ... , nomClasseN nomParamN



Mthodes et Oprations Une opration est la spcication d'une mthode (sa signature) indpendamment de sonimplantation. UML 2 autorise galement la dnition des oprations dans n'importe quel langagedonn.

Exemples de mthodes pour l'opration fact(n:int):int :

{ // implementation iterative

int resultat =1~;

for (int i = n~; i>0~; i--)

resultat *=i~;

return resultat ~;

}

{ // implementation recursive

if (n==0 || n==1)

return 1~;

return (n * fact(n -1))~;

}

Relations entre classes Une relation d'hritage est une relation de gnralisation/spcialisation permettant l'ab-straction.

Une dpendance est une relation unidirectionnelle exprimant une dpendance smantiqueentre les lments du modle (che ouverte pointille).

Une association reprsente une relation smantique entre les objets d'une classe. Une relation d'agrgation dcrit une relation de contenance ou de composition.

Association Une association est une relation structurelle entre objets. Une association est souvent utilise pour reprsenter les liens posibles entre objets declasses donnes.

Elle est reprsente par un trait entre classes.

Multiplicits des associations La notion de multiplicit permet le contrle du nombre d'objets intervenant dans chaqueinstance d'une association. Exemple : un article n'appartient qu' une seule catgorie (1) ; une catgorie concerneplus de 0 articles, sans maximum (*).

La syntaxe est MultMin..MultMax. * la place de MultMax signie plusieurs sans prciser de nombre. n..n se note aussi n , et 0..* se note * .

Navigabilit d'une association La navigabilit permet de spcier dans quel(s) sens il est possible de traverser l'association l'excution.

On restreint la navigabilit d'une association un seul sens l'aide d'une che.



Exemple : Connaissant un article on connat les commentaires, mais pas l'inverse. On peut aussi reprsenter les associations navigables dans un seul sens par des attributs. Exemple : En ajoutant un attribut avisInternaute de classe Commentaire laplace de l'association.

Association unidirectionnelle de 1 vers 1

Implantation

public class Adresse {...}

public class Client{

private Adresse livraison;

public void setAdresse(Adresse adresse ){

this.livraison = adresse;

}

public Adresse getAdresse (){

return livraison;

}

}

Association bidirectionnelle de 1 vers 1

Implantation

public class Client{

Adresse facturation;

public void setAdresse(Adresse uneAdresse ){

if(uneAdresse !=null){

this.facturation = uneAdresse;

facturation.client = this; // correspondance

}

}

}

public class Adresse{

Client client;

public void setClient(Client unClient ){

this.client = client;

client.facturation = this; // correspondance

}

}

Association unidirectionnelle de 1 vers *



Implantation

public class Commentaire {...}

public class Article{

private Vector avisInternaute = new Vector ();

public void addCommentaire(Commentaire commentaire ){

avisInternaute.addElement(commentaire );

}

public void removeCommentaire(Commentaire commentaire ){

avisInternaute.removeElement(commentaire );

}

}

Implantation d'une association bidirectionnelle de * vers *

Plus dicile : grer la fois la cohrence et les collections

Associations rexives L'association la plus utilise est l'association binaire (reliant deux classs). Parfois, les deux extrmits de l'association pointent vers le mme classeur. Dans ce cas,l'association est dite rexive .

Classe-association Une association peut tre rane et avoir ses propres attributs, qui ne sont disponiblesdans aucune des classes qu'elle lie.

Comme, dans le modle objet, seules les classes peuvent avoir des attributs, cette associa-tion devient alors une classe appele classe-association .

Associations n-aires Une association n-aire lie plus de deux classes. Notation avec un losange central pouvant ventuellement accueillir une classe-association. La multiplicit de chaque classe s'applique une instance du losange.



Les associations n-aires sont peu frquentes et concernent surtout les cas o les multplicits sonttoutes * . Dans la plupart des cas, on utilisera plus avantageusement des classes-associationou plusieurs relations binaires.

Association de type agrgation Une agrgation est une forme particulire d'association. Elle reprsente la relation d'inclusiond'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'agrgatet la partie l'agrg.

Association de type composition La relation de composition dcrit une contenance structurelle entre instances. On utiliseun losange plein.

La destruction et la copie de l'objet composite (l'ensemble) impliquent respectivementla destruction ou la copie de ses composants (les parties).

Une instance de la partie n'appartient jamais plus d'une instance de l'lment com-posite.



Composition et agrgation Ds lors que l'on a une relation du tout sa partie, on a une relation d'agrgation ou decomposition.

La composition est aussi dite agrgation forte .

Pour dcider de mettre une composition plutt qu'une agrgation, on doit se poser lesquestions suivantes : Est-ce que la destruction de l'objet composite (du tout) implique ncessairement ladestruction des objets composants (les parties) ? C'est le cas si les composants n'ont pasd'autonomie vis--vis des composites.

Lorsque l'on copie le composite, doit-on aussi copier les composants, ou est-ce qu'on peutles rutiliser , auquel cas un composant peut faire partie de plusieurs composites ?

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

Relation d'hritage L'hritage une relation de spcialisation/gnralisation. Les lments spcialiss hritent de la structure et du comportement des lments plusgnraux (attributs et oprations)

Exemple : Par hritage d'Article, un livre a d'oce un prix, une dsignation et uneopration acheter(), sans qu'il soit ncessaire de le prciser

Implantation de l'hritage en Java

class Article {

...

void acheter () {

...

}

}

class Livre

extends Article {

...

}

Attention

Les extends Java n'a rien voir avec le extend UML vu pour les cas d'utilisation



Encapsulation L'encapsulation est un principe de conception consistant protger le coeur d'un systmedes accs intempestifs venant de l'extrieur.

En UML, utilisation de modicateurs d'accs sur les attributs ou les classes : Public ou + : proprit ou classe visible partout Protected ou # . proprit ou classe visible dans la classe et par tous ses descendants. Private ou - : proprit ou classe visible uniquement dans la classe Package, ou : proprit ou classe visible uniquement dans le paquetage

Il n'y a pas de visibilit par dfaut .

Package (paquetage)

Les packages contiennent des lments de modle de haut niveau, comme des classes, des dia-grammes de cas d'utilisation ou d'autres packages. On organise les lments modliss en packageset sous-packages.

Exemple d'encapsulation

Les modicateurs d'accs sont galement applicables aux oprations.

Relation d'hritage et proprits La classe enfant possde toutes les proprits de ses classes parents (attributs et oprations) La classe enfant est la classe spcialise (ici Livre) La classe parent est la classe gnrale (ici Article)

Toutefois, elle n'a pas accs aux proprits prives.



Terminologie de l'hritage Une classe enfant peut rednir (mme signature) une ou plusieurs mthodes de la classeparent. Sauf indications contraires, un objet utilise les oprations les plus spcialises dans lahirarchie des classes.

La surcharge d'oprations (mme nom, mais signatures des oprations direntes) estpossible dans toutes les classes.

Toutes les associations de la classe parent s'appliquent, par dfaut, aux classes drives(classes enfant).

Principe de substitution : une instance d'une classe peut tre utilise partout o une in-stance de sa classe parent est attendue. Par exemple, toute opration acceptant un objet d'une classe Animal doit accepter toutobjet de la classe Chat (l'inverse n'est pas toujours vrai).

Classes abstraites Une mthode est dite abstraite lorsqu'on connat son entte mais pas la manire dont ellepeut 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'uneclasse parent contient une mthode abstraite non encore ralise.

Hritage multiple Une classe peut avoir plusieurs classes parents. On parle alors d'hritage multiple. Le langage C++ est un des langages objet permettant son implantation eective. Java ne le permet pas.

Interface Le rle d'une interface est de regrouper un ensemble d'oprations assurant un servicecohrent oert par un classeur et une classe en particulier.

Une interface est dnie comme une classe, avec les mmes compartiments. On ajoute lestrotype 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 dcritesdans l'interface



Classe cliente d'une interface Quand une classe dpend d'une interface (interface requise) pour raliser ses oprations,elle est dite classe cliente de l'interface

On utilise une relation de dpendance entre la classe cliente et l'interface requise. Touteclasse implmentant l'interface pourra tre utilise.

Exemple d'interface

Elments drivs Les attributs drivs peuvent tre calculs partir d'autres attributs et des formules decalcul. Les attributs drivs sont symboliss par l'ajout d'un / devant leur nom. Lors de la conception, un attribut driv peut tre utilis comme marqueur jusqu' ceque vous puissiez dterminer les rgles lui appliquer.

Une association drive est conditionne ou peut tre dduite partir d'autres autresassociations. On utilise galement le symbole / .

Attributs de classe Par dfaut, les valeurs des attributs dnis dans une classe dirent d'un objet un autre.Parfois, il est ncessaire de dnir un attribut de classe qui garde une valeur unique etpartage par toutes les instances.

Graphiquement, un attribut de classe est soulign

Oprations de classe Semblable aux attributs de classe Une opration de classe est une proprit de la classe, et non de ses instances. Elle n'a pas accs aux attributs des objets de la classe.



Classe paramtre Pour dnir une classe gnrique et paramtrable en fonction de valeurs et/ou de types : Dnition d'une classe paramtre par des lments spcis dans un rectangle en pointil-ls ;

Utilisation d'une dpendance strotype bind pour dnir des classes en fonction dela classe paramtre.

Java5 : gnricit C++ : templates

Diagrammes de classes direntes tapes de la conception On peut utiliser les diagrammes de classes pour reprsenter un systme dirents niveauxd'abstraction : Le point de vue spcication met l'accent sur les interfaces des classes plutt que surleurs contenus.

Le point de vue conceptuel capture les concepts du domaine et les liens qui les lient. Ils'intresse peu ou prou la manire ventuelle d'implmenter ces concepts et relationset aux langages d'implantation.

Le point de vue implantation, le plus courant, dtaille le contenu et l'implantation dechaque classe.

Les diagrammes de classes s'toent mesure qu'on va de hauts niveaux de bas niveauxd'abstraction (de la spcication vers l'implantation)

Construction d'un diagramme de classes

1. Trouver les classes du domaine tudi ; Souvent, concepts et substantifs du domaine.

2. Trouver les associations entre classes ; Souvent, verbes mettant en relation plusieurs classes.

3. Trouver les attributs des classes ; Souvent, substantifs correspondant un niveau de granularit plus n que les classes.Les adjectifs et les valeurs correspondent souvent des valeurs d'attributs.

4. Organiser et simplier le modle en utilisant l'hritage ;

5. Tester les chemins d'accs aux classes ;

6. Itrer et raner le modle.


2.3 Diagrammes d'objets 2 MODLISATION OBJET LMENTAIRE AVEC UML

2.3 Diagrammes d'objets

Objectif Le diagramme d'objets reprsente les objets d'un systme un instant donn. Il permetde : Illustrer le modle de classes (en montrant un exemple qui explique le modle) ; Prciser certains aspects du systme (en mettant en vidence des dtails imperceptiblesdans le diagramme de classes) ;

Exprimer une exception (en modlisant des cas particuliers, des connaissances non gnral-isables. . . ).

Le diagramme de classes modlise des rgles etle diagramme d'objets modlise des faits.

Reprsentation des objets Comme les classes, on utilise des cadres compartiments. En revanche, les noms des objets sont souligns et on peut rajouter son identiant devantle nom de sa classe.

Les valeurs (a) ou l'tat (f) d'un objet peuvent tre spcies. Les instances peuvent tre anonymes (a,c,d), nommes (b,f), orphelines (e), multiples (d)ou strotypes (g).

Diagramme de classes et diagramme d'objets Le diagramme de classes contraint la structure et les liens entre les objets.

Diagramme cohrent avec le diagramme de classes :


2 MODLISATION OBJET LMENTAIRE AVEC UML 2.3 Diagrammes d'objets

Diagramme incohrent avec le diagramme de classes :

Liens Un lien est une instance d'une association. Un lien se reprsente comme une association mais s'il a un nom, il est soulign.

Attention

Naturellement, on ne reprsente pas les multiplicits qui n'ont aucun sens au niveau desobjets.

Relation de dpendance d'instanciation La relation de dpendance d'instanciation (strotype) dcrit la relation entre un classeuret ses instances.

Elle relie, en particulier, les associations aux liens et les classes aux objets.


2.4 Diagrammes de squences 2 MODLISATION OBJET LMENTAIRE AVEC UML

2.4 Diagrammes de squences

Objectif des diagrammes de squence Les diagrammes de cas d'utilisation modlisent QUOI sert le systme, en organisant lesinteractions possibles avec les acteurs.

Les diagrammes de classes permettent de spcier la structure et les liens entre les objetsdont le systme est compos : ils spcie QUI sera l'oeuvre dans le systme pour raliserles fonctionnalits dcrites par les diagrammes de cas d'utilisation.

Les diagrammes de squences permettent de dcrire COMMENT les lments du sys-tme interagissent entre eux et avec les acteurs. Les objets au coeur d'un systme interagissent en s'changent des messages. Les acteurs interagissent avec le systme au moyen d'IHM (Interfaces Homme-Machine).

Exemple d'interaction Cas d'utilisation :

Diagramme de squences correspondant :

Oprations ncessaires dans le diagramme de classes :

Ligne de vie Une ligne de vie reprsente un participant une interaction (objet ou acteur).

nomLigneDeVie[selecteur ]: nomClasseOuActeur

Dans le cas d'une collection de participants, un slecteur permet de choisir un objet parmin (par exemple objets[2]).

Messages Les principales informations contenues dans un diagramme de squence sont les messageschangs entre les lignes de vie, prsents dans un ordre chronologique.


2 MODLISATION OBJET LMENTAIRE AVEC UML 2.4 Diagrammes de squences

Un message dnit une communication particulire entre des lignes de vie (objets ouacteurs).

Plusieurs types de messages existent, dont les plus courants : l'envoi d'un signal ; l'invocation d'une opration (appel de mthode) ; la cration ou la destruction d'un objet.

La rception des messages provoque une priode d'activit (rectangle vertical sur la ligne devie) marquant le traitement du message (spcication d'excution dans le cas d'un appelde mthode).

Principaux types de messages

Un message synchrone bloque l'expditeur jusqu' la rponse du destinataire. Le ot decontrle passe de l'metteur au rcepteur. Typiquement : appel de mthode Si un objet A invoque une mthode d'un objet B, A reste bloqu tant que B n'a pastermin.

On peut associer aux messages d'appel de mthode un message de retour (en pointills)marquant la reprise du contrle par l'objet metteur du message synchrone.

Un message asynchrone n'est pas bloquant pour l'expditeur. Le message envoy peuttre pris en compte par le rcepteur tout moment ou ignor. Typiquement : envoi de signal (voir strotype de classe signal ).

Correspondance messages / oprations

Lesmessages synchrones correspondent des oprations dans le diagramme de classes.

Envoyer un message et attendre la rponse pour poursuivre son activit revient invoquerune mthode et attendre le retour pour poursuivre ses traitements.

implantation des messages synchrones



class B {

C c;

op1(p:Type){

c.op2(p);

c.op3();

}

}

class C {

op2(p:Type){

...

}

op3(){

...

}

}

Correspondance messages / signaux Les messages asynchrones correspondent des signaux dans le diagramme de classes.

Les signaux sont des objets dont la classe est strotype signal et dont les attributs(porteurs d'information) correspondent aux paramtres du message.

Cration et destruction de lignes de vie La cration d'un objet est matrialise par une che qui pointe sur le sommet d'une lignede vie. On peut aussi utiliser un message asynchrone ordinaire portant le nom create .

La destruction d'un objet est matrialise par une croix qui marque la n de la ligne devie de l'objet.



Messages complets, perdus et trouvs Un message complet est tel que les vnements d'envoi et de rception sont connus. Un message complet est reprsent par une che partant d'une ligne de vie et arrivant une autre ligne de vie.

Un message perdu est tel que l'vnement d'envoi est connu, mais pas l'vnement derception.

La che part d'une ligne de vie mais arrive sur un cercle indpendant marquant lamconnaissance du destinataire.

Exemple : broadcast. Un message trouv est tel que l'vnement de rception est connu, mais pas l'vnementd'mission.

Syntaxe des messages La syntaxe des messages est :

nomSignalOuOperation(parametres)

La syntaxe des arguments est la suivante :

nomParametre=valeurParametre

Pour un argument modiable :

nomParametre:valeurParametre

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

Messages de retour Le rcepteur d'un message synchrone rend la main l'metteur du message en lui envoyantun message de retour Les messages de retour sont optionnels : la n de la priode d'activit marque galementla n de l'excution d'une mthode.

Ils sont utiliss pour spcier le rsultat de la mthode invoque.

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



Syntaxe des messages de retour La syntaxe des messages de retour est :

attributCible=nomOperation(params ): valeurRetour

La syntaxe des paramtres est :

nomParam=valeurParam

ou

nomParam:valeurParam

Les messages de retour sont reprsents en pointills.

Fragment combin Un fragment combin permet de dcomposer une interaction complexe en fragments su-isamment simples pour tre compris. Recombiner les fragments restitue la complexit. Syntaxe complte avec UML 2 : reprsentation complte de processus avec un langagesimple (ex : processus parallles).

Un fragment combin se reprsente de la mme faon qu'une interaction. Il est reprsentun rectangle dont le coin suprieur gauche contient un pentagone. Dans le pentagone gure le type de la combinaison (appel oprateur d'interaction ).

Exemple de fragment avec l'oprateur conditionnel

Type d'oprateurs d'interaction Oprateurs de branchement ( choix et boucles) : alternative, option, break et loop ;

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

Oprateurs contrlant l'envoi de messages : ignore, consider, assertion et negative ;

Oprateurs xant l'ordre d'envoi des messages : weak sequencing et strict sequencing.

Oprateur de boucle



Syntaxe de l'oprateur loop

Syntaxe d'une boucle :

loop(minNbIterations ,maxNbIterations)

La boucle est rpte au moins minNbItrations fois avant qu'une ventuelle conditionboolenne ne soit teste (la condition est place entre crochets dans le fragment)

Tant que la condition est vraie, la boucle continue, au plus maxNbItrations fois. Notations : loop(valeur) est quivalent loop(valeur,valeur). loop est quivalent loop(0,*), o * signie illimit .

Oprateur parallle

L'oprateur par permet d'envoyer des messages en parallle. Ce qui se passe de part et d'autre de la ligne pointille est indpendant.

Rutilisation d'une interaction

Rutiliser une interaction consiste placer un fragment portant la rfrence ref l ol'interaction est utile.



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

Utilisation d'un DS pour modliser un cas d'utilisation Chaque cas d'utilisation donne lieu un diagramme de squences

Les inclusions et les extensions sont des cas typiques d'utilisation de la rutilisation parrfrencement

Utilisation d'un DS pour spcier une mthode Une interaction peut tre identie par un fragment sd (pour pour sequence diagram)pr-cisant son nom

Un message peut partir du bord de l'interaction, spciant le comportement du systmeaprs rception du message, quel que soit l'expditeur


3 UML ET MTHODODOLOGIE

3 UML et mthododologie

3.1 Des besoins au code avec UML : une mthode minimale

Pourquoi une mthode ?

Processus de dveloppement

Ensemble d'tapes partiellement ordonnes, qui concourent l'obtention d'un systme logicielou l'volution d'un systme existant.

Objectif : produire des logiciels De qualit (qui rpondent aux besoins de leurs utilisateurs) Dans des temps et des cots prvisibles

A chaque tape, on produit : Des modles ; De la documentation ; Du code.

Mthode = Dmarche + Langage La mthode MERISE fournit : Un langage de modlisation graphique (MCD, MPD, MOT, MCT...)ET Une dmarche adopter pour dveloppent un logiciel.

UML n'est qu'un langage : Il spcie comment dcrire des cas d'utilisation, des classes, des interactions Mais ne prjuge pas de la dmarche employe.

Mthodes s'appuyant sur UML : RUP (Rational Unied Process) - par les auteurs d'UML ; XP (eXtreme Programming) - pouvant s'appuyer sur UML.

Mthode minimale

Objectif

Rsoudre 80% des problmes avec 20% d'UML.

Proposition d'une mthode archi-minimale : Trs nettement moins complexe que RUP ; Adapte pour projets modestes ; Minimum vital pour qui prtend utiliser un peu UML.

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


3 UML ET MTHODODOLOGIE3.1 Des besoins au code avec UML : une mthode minimale

Cas d'utilsation Comment dnir les besoins ?

1. Identier les limites du systme ;

2. Identier les acteurs ;

3. Identier les cas d'utilisation ;

4. Structurer les cas d'utilisation en packages ;

5. Ajouter les relations entre cas d'utilisation ;

6. Classer les cas d'utilisation par ordre d'importance.

Exemple de classement

Cas d'utilisation Priorit RisqueAjouter article au panier Haute MoyenChanger prix Article Moyen MoyenRechercher par mots-cls Bas Moyen... etc ... ... etc ... ... etc ...

Un tel classement permet de dterminer les cas d'utilisation centraux en fonction : De leur priorit fonctionnelle ; Du risque qu'il font courrir au projet dans son ensemble.

Les fonctionnalits des cas les plus centraux seront dveloppes prioritairement.

Modle du domaine

Le modle du domaine est constitu d'un ensemble de classes dans lesquelles aucune oprationn'est dnie.

Le modle du domaine dcrit les concepts invariants du domaine d'application. Exemple : Pour un logiciel de gestions de factures, on aura des classes comme Produit,Client, Facture... Peu importe que le logiciel soit en ligne ou non. Peu importent les technologies employes.


3.1 Des besoins au code avec UML : une mthode minimale3 UML ET MTHODODOLOGIE

Etapes de la dmarche :

1. Identier les concepts du domaine ;

2. Ajouter les associations et les attributs ;

3. Gnraliser les concepts ;

4. Structurer en packages : structuration selon les principes de cohrence et d'indpen-dance.

Les concepts du domaine peuvent tre identis directement partir de la connaissancedu domaine ou par interview des experts mtier.

Exemple de modle du domaine

Structuration en packages

Squences systme

Les squences systme formalisent les descriptions textuelles des cas d'utilisation, en utilisantdes diagrammes de squence.

Construire les Diagrammes de Squences Systme implique souvent la mise jour des casd'utilisation la lumire des rexions que nous inspirent la production des DSS.

Les DSS permettent de spcier les oprations systme. Le systme est considr comme un tout : On s'intresse ses interactions avec les acteurs ; On utilise une classe Systme qui part les acteurs donnera lieu la seule lignede vie des DSS.



Un nouveau DSS est produit pour chacun des cas d'utilisation.

Les DSS sont parfois trs simples mais ils seront enrichis par la suite.

Exemple de diagramme de squence systme

Oprations systme

Les oprations systme sont des oprations qui devront tre ralises par l'une ou l'autredes classes du systme.

Elles correspondent tous les messages qui viennent des acteurs vers le systme dans lesdirents DSS.

Classes participantes Pour chaque cas d'utilisation, on dnit les classes d'analyse mises en oeuvre pour saralisation eective.

Typologie des classes d'analyse : Les classes mtier (ou entits) reprsentent les objets mtier. Elles correspondent auxclasses du modle du domaine.

Les classes de dialogue sont celles qui permettent les interactions entre les acteurs etl'application.

Les classes de contrle permettent d'abstraire les fonctionnalits du systme : Elles font le lien entre les classes dialogue et les classes mtier. Elles permettent de contrler la cinmatique de l'application, cad l'ordre dans lequelles choses doivent se drouler.

Diagramme de classes participantes


3.1 Des besoins au code avec UML : une mthode minimale3 UML ET MTHODODOLOGIE

Le Diagramme des Classes Participantes est un diagramme de classes dcrivant toutes les classesd'analyse.

Le DCP est une version enrichie du modle du domaine, auquel on adjoint les classes d'interactionet de contrle.

A ce point du dveloppement, seules les classes de dialogue ont des oprations, qui corre-spondent aux oprations systme, c'est dire aux messages changs avec les acteurs, queseules les classes de dialogues sont habilites intercepter ou mettre.

Architecture en couches : Les dialogues ne peuvent tre relis qu'aux contrles ou d'autres dialogues (en gnral,associations unidirectionnelles).

Les classes mtier ne peuvent tre relies qu'aux contrles ou d'autres classes mtier. Les contrles peuvent tre associs tous les types de classes.

Exemple de diagramme de classes participantes

Diagrammes d'interaction Dans les diagrammes de squence systme, le systme tait vu comme une bote noire (lignede vie Systme ). On sait maintenant de objets est compos le systme (diag. de classes participantes). Le systme n'est plus une bote noire.

Chaque diagramme de squence systme donne lieu un diagramme d'interaction. Il y ena donc autant que de cas d'utilisation.

En plus des interactions du systme avec l'extrieur, les Diagrammes d'Interaction mon-trent les interactions internes provoques.

Les DSS sont repris mais l'objet Systme est clat pour donner le dtail des classesd'analyse : Les lignes de vie correspondent aux classes participantes.



Des squences systme aux interactions internes

Diagramme des classes de conception

Les diagrammes d'interaction permettent de dnir les oprations (ncessaires et su-isantes) des classes mtier et de contrle (messages synchrones).

Le Diagramme des Classes de Conception reprend le diagramme de classes participantes en yadjoignant toutes les oprations ncessaires.

Le DCC est en outre enrichi pour : Prendre en compte l'architecture logicielle hte ; Modliser les opration prives des direntes classes ; Finaliser le modle des classes avant l'Implantation.


3.2 Rational Unied Process 3 UML ET MTHODODOLOGIE

3.2 Rational Unied Process

Modles de cycles de vie linaire Les phases du dveloppement se suivent dans l'ordre et sans retour en arrire.

Problmes des cycles linaires Risques levs et non contrls : Identication tardive des problmes ; Preuve tardive de bon fonctionnement ; Eet tunnel.

Amliorations : construction itrative du systme : Chaque itration produit un nouvel incrment ; Chaque nouvel incrment a pour objectif la matrise d'une partie des risques et apporteune preuve tangible de faisabilit ou d'adquation : Enrichissement d'une srie de prototypes ; Les versions livres correspondent des tapes de la chane des prototypes.

Production itrative d'incrments Les itrations de 1 7 sont produites successivement, chacune ajoutant au systme denouvelles fonctionnalits, jusqu' former un systme complet.


3 UML ET MTHODODOLOGIE 3.2 Rational Unied Process

A chaque itration, on refait :

1. Spcication ;

2. Conception ;

3. Implmentation ;

4. Tests.

Elimination des risques chaque itration

On peut voir le dveloppement d'un logiciel comme un processus graduel d'limination de risques.

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

Rational Unied Process

RUP est une dmarche de dveloppement qui est souvent utilis conjointement au langage UML.

Rational Unied Process est Pilot par les cas d'utilisation ; Centr sur l'architecture ; Itratif et incrmental.

RUP est itratif et incrmental Chaque itration prend en compte un certain nombre de cas d'utilisation. Les risques majeurs sont traits en priorit. Chaque itration donne lieu un incrment et produit une nouvelle version excutable.

RUP est pilot par les cas d'utilisation La principale qualit d'un logiciel est son utilit : Adquation du service rendu par le logiciel avec les besoins des utilisateurs.

Le dveloppement d'un logiciel doit tre centr sur l'utilisateur. Les cas d'utilisation permettent d'exprimer ces besoins : Dtection et description des besoins fonctionnels ; Organisation des besoins fonctionnels.



RUP est centr sur l'architecture Modlisation de direntes pespectives indpendantes et complmentaires. Architecture en couches et vues de Krutchen.

Vues du systme Vue cas d'utilisation : Description du systme comme un ensemble de transactions du point de vue de l'util-isateur.

Vue logique : Cre lors de la phase d'laboration et rane lors de la phase de construction ; Utilisation de diagrammes de classes, de squences...

Vue composants : Description de l'architecture logicielle.

Vue dploiement : Description de l'architecture matrielle du systme.

Vue implmentation : Description des algorithmes, code source.

Organisation en phases du dveloppement Initialisation : Dnition du problme.

Elaboration : Planication des activits, aectation des ressources, analyse.

Construction : Dveloppement du logiciel par incrments successifs.

Transition : Recettage et dploiement.

Les phases du dveloppement sont les grandes tapes du dveloppement du logiciel Le projet commence en phase d'initialisation et termine en phase de transition

Phase d'initialisation : Objectifs Dnition du cadre du projet, son concept, et inventaire du contenu ; Elaboration des cas d'utilisation critiques ayant le plus d'inuence sur l'architecture et laconception ;

Ralisation d'un ou de plusieurs prototypes dmontrant les fonctionnalits dcrites par lescas d'utilisation principaux ;

Estimation dtaille de la charge de travail, du cot et du planning gnral ainsi que de laphase suivante d'laboration Estimation des risques.



Phase d'initialisation : Activits Formulation du cadre du projet, des besoins, des contraintes et des critres d'acceptation ; Planication et prparation de la justication conomique du projet et valuation desalternatives en termes de gestion des risques, ressources, planication ;

Synthse des architectures candidates, valuation des cots.

Phase d'initialisation : Livrables Un document de vision prsentant les besoins de base, les contraintes et fonctionnalitsprincipales ;

Une premire version du modle de cas d'utilisation ; Un glossaire de projet ; Un document de justication conomique incluant le contexte gnral de ralisation, lesfacteurs de succs et la prvision nancire ;

Une valuation des risques ; Un plan de projet prsentant phases et itrations ; Un ou plusieurs prototypes.

Phase d'initialisation : Critres d'valuation Un consensus sur : La planication ; L'estimation des cots ; La dnition de l'ensemble des projets des parties concernes.

La comprhension commune des besoins.

Phase d'laboration : objectifs Dnir, valider et arrter l'architecture ; Dmontrer l'ecacit de cette architecture rpondre notre besoin ; Planier la phase de construction.

Phase d'laboration : activits Elaboration de la vision gnrale du systme, les cas d'utilisation principaux sont compriset valids ;

Le processus de projet, l'infrastructure, les outils et l'environnement de dveloppementsont tablis et mis en place ;

Elaboration de l'architecture et slection des composants.

Phase d'laboration : livrables Le modle de cas d'utilisation est produit au moins 80 % ; La liste des exigences et contraintes non fonctionnelles identies ; Une description de l'architecture ; Un excutable permettant de valider l'architecture du logiciel travers certaines fonction-nalits complexes ;

La liste des risques revue et la mise jour de la justication conomique du projet ; Le plan de ralisation, y compris un plan de dveloppement prsentant les phases, lesitrations et les critres d'valuation ;

Phase d'laboration : Critres d'valuation La stabilit de la vision du produit nal ; La stabilit de l'architecture ; La prise en charge des risques princip aux est adresse par le(s) prototype(s) ; La dnition et le dtail du plan de projet pour la phase de construction ;



Un consensus, par toutes les parties prenantes, sur la ractualisation de la planication,des cots et de la dnition de projet.

Phase de construction : objectifs La minimisation des cots de dveloppement par : L'optimisation des ressources ; La minimisation des travaux non ncessaires.

Le maintien de la qualit ; Ralisation des versions excutables.

Phase de construction : Activits Gestion et le contrle des ressources et l'optimisation du processus de projet ; Evaluation des versions produites en regard des critres d'acceptation dnis.

Phase de construction : Livrables Les versions excutables du logiciel correspondant l'enrichissement itration par itrationdes fonctionnalits ;

Les manuels d'utilisation raliss en parallle la livraison incrmentale des excutables ; Une description des versions produites.

Phase de construction : Critres d'valuation La stabilit et la qualit des excutables ; La prparation des parties prenantes ; La situation nancire du projet en regard du budget initial.

Phase de transition : Objectifs Le dploiement du logiciel dans l'environnement d'exploitation des utilisateurs ; La prise en charge des problmes lis la transition ; Atteindre un niveau de stabilit tel que l'utilisateur est indpendant ; Atteindre un niveau de stabilit et qualit tel que les parties prenantes considrent le projetcomme termin.

Phase de transition : Activits Activits de packaging du logiciel pour le mettre disposition des utilisateurs et del'quipe d'exploitation ;

Correction des erreurs rsiduelles et amlioration de la performance et du champ d'utilisa-tion ;

Evaluation du produit nal en regard des critres d'acceptation dnis.

Phase de transition : Livrables La version nale du logiciel ; Les manuels d'utilisation.

Phase de transition : Critres d'valuation La satisfaction des utilisateurs ; La situation nancire du projet en regard du budget initial.



Organisation en activits de dveloppement Chaque phase comprend plusieurs itrations Pour chacune des itrations, on se livre plusieurs activits : Modlisation mtier ; Expression des besoins ; Analyse ; Conception ; Implmentation ; Test ; Dploiement.

Les activits sont des tapes dans le dveloppement d'un logiciel, mais un niveau degranularit beaucoup plus n que les phases.

Chaque activit est rpte autant de fois qu'il y a d'itrations.

Modlisation mtier Objectif : Mieux comprendre la structure et la dynamique de l'organisation : Proposer la meilleure solution dans le contexte de l'organisation cliente ; Ralisation d'un glossaire des termes mtiers ; Cartographie des processus mtier de l'organisation cliente.

Activit coteuse mais qui permet d'acclrer la comprhension d'un problme.

Expression des besoins Objectif : Cibler les besoins des utilisateurs et du clients grce une srie d'interviews. L'ensemble des parties prenantes du projet, matrise d'oeuvre et matrise d'ouvrage, estacteur de cette activit.

L'activit de recueil et d'expression des besoins dbouche sur ce que doit faire le systme(question QUOI ? )

Utilisation des cas d'utilisation pour : Schmatiser les besoins ; Structurer les documents de spcications fonctionnelles.

Les cas d'utilisation sont dcomposs en scnarios d'usage du systme, dans lesquels l'util-isateur raconte ce qu'il fait grce au systme et ses interactions avec le systme.

Un maquettage est ralisable pour mieux immerger l'utilisateur dans le futur systme. Une fois poses les limites fonctionnelles, le projet est plani et une prvision des cotsest ralise.

Analyse Objectif : Transformer les besoins utilisateurs en modles UML. Analyse objet servant de base une rexion sur les mcanismes internes du systme.



Principaux livrables : Modles d'analyse, neutre vis vis d'une technologie ; Livre une spcication plus prcise des besoins.

Peut envisag comme une premire bauche du modle de conception.

Conception

Objectif : Modliser comment le systme va fonctionner : Exigences non fonctionnelles ; Choix technologiques.

Le systme est analys et on produit : Une proposition d'architecture ; Un dcoupage en composants.

Impmentation

Objectif : Implmenter le systme par composants. Le systme est dvelopp par morceaux dpendant les uns des autres. Optimisation de l'utilisation des ressources selon leurs expertises.

Les dcoupages fonctionnel et en couches sont indispensable pour cette activit. Il est tout fait envisageable de retoucher les modles d'analyse et de conception cestade.

Test

Objectif : Vrier des rsultats de l'implmentation en testant la construction : Tests unitaires : tests composants par composants ; Tests d'intgration : tests de l'interaction de composants pralablement tests individu-ellement.

Mthode : Planication pour chaque itration ; Implmentation des tests en crant des cas de tests ; Excuter les tests ; Prendre en compte le rsultat de chacun.

Dploiement

Objectif : Dployer les dveloppements une fois raliss. Peut tre ralis trs tt dans le processus dans une sousactivit de prototypage dontl'objectif est de valider : L'architecture physique ; Les choix technologiques.

Importance des activits dans chaque phase



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

Analyse Modles mtier, cas d'utilisation ; Diagramme des classes, de squences et de dploiement.

Conception Diagramme des classes, de squences ; Diagramme tat/transition ; Diagramme d'activit ; Diagramme de dploiement et de composant.

2TUP, une variante du Unied Process . 2TUP, avec un processus de dveloppement en Y , dvelopp par Valtech. UML 2.0, en action : De l'analyse des besoins la conception J2EE Pascal Roques, Franck Valle Editions Eyrolles (2004)


3.3 eXtreme programming 3 UML ET MTHODODOLOGIE

3.3 eXtreme programming

Mthodes agiles

Quelles activits pouvons nous abandonner tout en produisant des logiciels de qualit ?

Comment mieux travailler avec le client pour nous focaliser sur ses besoins les plus prioritaireset tre aussi ractifs que possible ?

Filiation avec le RAD. Exemples de mthodes agiles : XP (eXtreme Programming), DSDM (Dynamic Software Development Method), ASD(Adaptative Software Development), CCM (Crystal Clear Methodologies), SCRUM,FDD (Feature Driven Development).

Priorits des mthodes agiles Priorit aux personnes et aux interactions sur les procdures de les outils ; Priorit aux applications fonctionnelles sur une documentation plthorique ; Priorit la collaboration avec le client sur la ngociation de contrat ; Priorit l'acceptation du changement sur la planication.

eXtreme Programming

eXtreme Programming, une mthode base sur des pratiques qui sont autant de boutons pousssau maximum .

Mthode qui peut sembler naturelle mais concrtement dicile appliquer et matriser : Rclame beaucoup de discipline et de communication (contrairement la premire im-pression qui peut faire penser une bullition de cerveaux individuels).

Aller vite mais sans perdre de vue la rigueur du codage et les fonctions nales de l'ap-plication.

Force de XP : sa simplicit et le fait qu'on va droit l'essentiel, selon un rythme qui doitrester constant.

Valeurs d'XP Communication : XP favorise la communication directe, plutt que le cloisonnement des activits et leschanges de documents formels.

Les dveloppeurs travaillent directement avec la matrise d'ouvrage. Feedback : Les pratiques XP sont conues pour donner un maximum de feedback sur le droulementdu projet an de corriger la trajectoire au plus tt.

Simplicit : Du processus ; Du code.

Courage : D'honorer les autres valeurs ; De maintenir une communication franche et ouverte ; D'accepter et de traiter de front les mauvaises nouvelles.


3 UML ET MTHODODOLOGIE 3.3 eXtreme programming

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

Pratiques de gestion de projets Livraisons frquentes : L'quipe vise la mise en production rapide d'une version minimale du logiciel, puis ellefournit ensuite rgulirement de nouvelles livraisons en tenant compte des retours duclient.

Planication itrative : Un plan de dveloppement est prpar au dbut du projet, puis il est revu et remanitout au long du dveloppement pour tenir compte de l'exprience acquise par le clientet l'quipe de dveloppement.

Client sur site : Le client est intgr l'quipe de dveloppement pour rpondre aux questions desdveloppeurs et dnir les tests fonctionnels.

Rythme durable : L'quipe adopte un rythme de travail qui lui permet de fournir un travail de qualit toutau long du projet.

Jamais plus de 40h de travail par semaine (un dveloppeur fatigu dveloppe mal).

Pratiques de programmation Conception simple : On ne dveloppe rien qui ne soit utile tout de suite.

Remaniement : Le code est en permanence rorganis pour rester aussi clair et simple que possible.

Tests unitaires : Les dveloppeurs mettent en place une batterie de tests de nonrgression qui leur per-mettent de faire des modications sans crainte.

Tests de recette : Les testeurs mettent en place des tests automatiques qui vrient que le logiciel rpondaux exigences du client.

Ces tests permettent des recettes automatiques du logiciel.

Pratiques de collaboration Responsabilit collective du code : Chaque dveloppeur est susceptible de travailler sur n'importe quelle partie de l'appli-cation.

Programmation en binmes : Les dveloppeurs travaillent toujours en binmes, ces binmes tant renouvels frquem-ment.

Rgles de codage : Les dveloppeurs se plient des rgles de codage strictes dnies par l'quipe elle-mme.

Mtaphore : Les dveloppeurs s'appuient sur une description commune du design.

Intgration continue : L'intgration des nouveaux dveloppements est faite chaque jour.

Cycle de vie XP



Exploration Les dveloppeurs se penchent sur des questions techniques : Explorer les direntes possibilits d'architecture pour le systme : Etudier par exemple les limites au niveau des performances prsentes par chacune dessolutions possibles.

Le client s'habitue exprimer ses besoins sous forme de user strories (proches de dia-grammes de cas illustrs par des diagrammes de squences). Les dveloppeurs estiment les temps de dveloppement.

Planning Planning de la premire release : Uniquement les fonctionnalits essentielles ; Premire release enrichir par la suite.

Dure du planning : 1 ou 2 jours. Premire version (release) au bout de 2 6 mois.

Itrations jusqu' la premire release Dveloppement de la premire version de l'application. Itrations de une quatre semaines : Chaque itration produit un sous ensemble des fonctionnalits principales ; Le produit de chaque itration subit des tests fonctionnels ; Itrations courtes pour identier trs tt des dviation par rapport au planning.

Brves runions quotidiennes runissant toute l'quipe, pour mettre chacun au courant del'avancement du projet.

Mise en production La mise en production produit un logiciel : Orant toutes les fonctionnalits indispensables ; Parfaitement fonctionnel ; Mis disposition des utilisateurs.

Itrations trs courtes ; Tests constants en parallle du dveloppement ; Les dveloppeurs procdent des rglages ans pour amliorer les performances du logi-ciel.

Maintenance Continuer faire fonctionner le systme ;


3 UML ET MTHODODOLOGIE 3.3 eXtreme programming

Adjonction de nouvelles fonctionnalits secondaires. Pour les fonctionnalits secondaires, on recommence par une rapide exploration. L'ajout de fonctionnalits secondaires donne lieu de nouvelles releases.

Mort Quand le client ne parvient plus spcier de nouveaux besoins, le projet est dit mort Soit que tous les besoins possibles sont remplis ; Soit que le systme ne supporte plus de nouvelles modications en restsant rentable.

Equipe XP Pour un travil en quipe, on distingue 6 rles principaux au sein d'une quipe XP : Dveloppeur ; Client ; Testeur ; Tracker ; Manager ; Coach.

Dveloppeur Conception et programmation, mme combat ! Participe aux sances de planication, value les tches et leur dicult ; Dnition des test unitaires ; Implmentation des fonctionnalits et des tests unitaires.

Client crit, explique et matrise les scnarios ; Spcie les tests fonctionnels de recette ; Dnit les priorits.

Testeur criture des tests de recette automatiques pour valider les scnarios clients ; Peut inuer sur les choix du clients en fonction de la testatibilit des scnarios.

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

Manager Suprieur hirarchique des dveloppeurs : Responsable du projet.

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

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



Spcication avec XP Pas de documents d'analyse ou de spcications dtailles. Les tests de recette remplacent les spcications. Emergence de l'architecture au fur et mesure du dveloppement.

XP vs RUP Inconvnients de XP : Focalisation sur l'aspect individuel du dveloppement, au dtriment d'une vue globaleet des pratiques de management ou de formalisation ;

Manquer de contrle et de structuration, risques de drive. Inconvnients de RUP : Fait tout, mais lourd, usine gaz ; Parfois dicile mettre en oeuvre de faon spcique.

XP pour les petits projets en quipe de 12 max ; RUP pour les gros projets qui gnrent beaucoup de documentation.


4 MODLISATION AVANCE AVEC UML

4 Modlisation avance avec UML

4.1 Expression de contraintes avec OCL

Expression de contraintes avec UML Les dirents diagrammes d'UML expriment en fait des contraintes Graphiquement Contraintes structurelles (un attribut dans une classe) Contraintes de types (sous-typage) Contraintes diverses (composition, cardinalit, etc.)

Via des proprits prdnies Sur des classes ({abstract}) Sur des rles ({ordered})

C'est toutefois insusant

Insusances d'UML pour reprsenter certaines contraintes Certaines contraintes videntes sont dicilement exprimables avec UML seul.

Le signataire d'une carte bleue est titulaire du compte correspondant

Expression des contraintes en langage naturel Simple mettre en oeuvre : Utilisation des notes en UML + texte libre, Comprhensible par tous.

Indispensable : Documenter les contraintes est essentiel, Dtecter les problmes le plus tt possible.

Probmlatique Ambigu, imprcis, Dicile d'exprimer clairement des contraintes complexes, Dicile de lier le texte aux lments du modle.

Exemples de contraintes exprimables en OCL Le solde d'un compte ne doit pas tre infrieur au dcouvert maximum. Le signataire d'une carte bleue associe un compte en est le titulaire. Une carte bleue est accepte dans tous les distributeurs des consortiums de la banque. ...


4 MODLISATION AVANCE AVEC UML 4.1 Expression de contraintes avec OCL

Le solde d'un compte ne doit pas tre infrieur au dcouvert maximum autoris Si l'attribut dMax de la classe Compte est un rel et que le dcouvert est exprim par unevaleur ngative :

context c~: Compte

inv: solde >= dMax

Si le dcouvert est exprim par un nombre positif (par ex : 300 euros si on ne doit pasdescendre en dessous de 300 euros)

context c~: Compte

inv: solde >= -dMax

Le signataire d'une carte bleue associe un compte est titulaire de ce compte ... est le titulaire ...

context CarteBleue

inv: signataire = compte.titulaires

... est un des titulaires ...

context CarteBleue

inv: compte.titulaires -> includes(signataire)

Une carte bleue est accepte dans tous les distributeurs des consortiums de labanque

context CarteBleue

inv: distributeur

= compte.banque.consortium.distributeur

OCL pour l'criture de contraintes OCL : Object Constraint Language Langage de requtes et de contraintes Relativement simple crire et comprendre syntaxe purement textuelle sans symboles tranges

Parfaitement intgr UML Smantique d'UML crite en OCL : tous les schmas UML produits ont une traductionen OCL

En pleine expansion


4.1 Expression de contraintes avec OCL 4 MODLISATION AVANCE AVEC UML

Nouvelle version majeure avec UML2.0 Essentiel pour avoir des modles susemment prcis De plus en plus d'outils dition, vrication, gnration (partielle) de code...

Caractristiques d'OCL Langage d'expressions (fonctionnel) Valeurs, expressions, types Fortement typ Pas d'eets de bords

Langage de spcication, pas de programmation Haut niveau d'abstraction Pas forcment excutable (seul un sous-ensemble l'est) Permet de trouver des erreurs beaucoup plus tt dans le cycle de vie

Avantages et inconvnients d'OCL Points faibles Pas aussi rigoureux que des langages de spcication formelle comme VDM, Z ou B Pas de preuves formelles possibles dans tous les cas

Puissance d'expression limite Points forts Relativement simple crire et comprendre Trs bien intgr UML Bon compromis entre simplicit et puissance d'expression Passage vers direntes plateformes technologiques

Contexte d'une contrainte Une contrainte est toujours associe un lment de modle : le contexte de la contrainte. Deux techniques pour spcier le contexte : En crivant la contrainte entre accolades {...} dans une note. L'lment point par lanote est alors le contexte de la contrainte

En utilsant le mot cl context dans un document quelconque.

context CarteBleue

inv: compte.titulaires ->includes(signataire)

inv: code >0 and code 10

Dnition de prdicats avec OCL OCL peut tre utilis pour dcrire trois types de prdicats avec les mots cl : inv: invariants de classes

inv: solde


pre: montantARetirer >0

post: post-conditions d'oprations

post: solde >solde@pre

Dnition d'expressions avec OCL OCL peut galement tre utilis pour dcrire des expressions avec les mots cls : def: dclarer des attributs ou des oprations

def: nbEnfants:Integer

init: spcier la valeur initiale des attributs

init: enfants ->size()

body: exprimer le corps de mthodes {query}

body: enfants ->select(age size ()=1

La navigation permet de tester si la valeur est dnie (l'ensemble vide reprsente la valeurindnie)

pere ->isEmpty ()

epouse ->notEmpty ()

implies self.epouse.sexe=sexe:: feminin

Si une association n'a pas de nom de rle alors on peut utiliser le nom de la classe destination



Navigation vers une association rexive Si l'association est rexive, pour viter les ambiguits, il faut indiquer avec un rle entrecrochets [...] comment est parcourue l'association

objet.nomAssociation[nomDeRole]

p.evaluation[chefs]

p.evaluation[employes]

p.evaluation[chefs ].note -> sum()

Navigation via une association qualie Accs quali

lien.nomderole[valeur1 ,valeur2 , ... ]

ou ensemble d'objets lis

lien.nomderole

b.compte [4029]

b.compte

compte

Invariant (inv) Prdicat associ une classe ou une association Doit tre vri tout instant

Le contexte est dni par un objet Cet objet peut tre rfrenc par self

L'invariant peut tre nomm

context Personne

inv pasTropVieux ~: age < 110

inv~: self.age >= 0

Exemples d'invariants

context Personne

inv~: age >0 and self.age 16

inv enfantsOk ~: enfants ->size() < 20

inv~: not enfants ->includes(self)

inv~: enfants ->includesAll(filles)

inv~: enfants ->forall(e | self.age -e.age


Pr-condition et post-condition Prdicats associs une opration Les pr-conditions doivent tre vries avant l'excution Les post-conditions sont vraies aprs l'excution

self dsigne l'objet sur lequel l'opration lieu Dans une post-condition : @pre permet de faire rfrence la valeur avant que opration ne soit eectue result designe le resultat de l'opration ocsIsNew() indique si un objet n'existait pas dans l'tat prcdent

context Classe :: operation (...): ClasseValRetour

pre nom1~: param1 < ...

post~: ... result > ...

Exemples de pr et post-conditions

context Personne :: retirer(montant:Integer)

pre~: montant > 0

post~: solde < solde@pre - montant

context Personne :: salaire (): integer

post~: result >= Legislation :: salaireMinimum

context Compagnie :: embaucheEmploye(p:Personne ): Contrat

pre pasPresent ~: not employes ->includes(p)

post~: employes=employes@pre ->including(p)

post~: result.oclIsNew ()

post~: result.compagnie=self and result.employe=p

Dnition additionnelle (def) Il est possible en OCL de dnir dans une classe existante: de nouveaux attributs de nouvelles oprations

context Classe

def~: nomAtt ~: type = expr

def~: nomOp ...~: type = expr

Utile pour dcomposer des requetes ou contraintes

context Personne

def: ancestres ()~:

Set(Personne) = parents

->union(parents.ancestres ()

->asSet ())

inv: not ancestres()->includes(self)

Expression du corps d'une mthode (body) Description d'une mthode sans eet de bord ({isQuery}) Equivalent une requte

context Personne:acf(p:Personne ): OrderedSet(Personne)

body~: self.ancestres ()

->select(sexe=Sexe:: Feminin)

->sortedBy(dateDeNaissance)

context Personne



def: ancestres ~: Set(Personne) = parents

->union(parents.ancestres ->asSet ())

Syntaxe des expressions OCL est un langage simple d'expressions constantes identificateur self expr op expr exprobjet.propobjet exprobjet.propobjet ( parametres ) exprcollection -> propcollection(parametres) package::package::element if cond then expr else expr endif let var : type = expr in expr

Accs aux proprits et aux lments . permet d'accder une proprit d'un objet -> permet d'accder une proprit d'une collection :: permet d'accder un lment d'un paquetage, d'une classe, . . . Des rgles permettent de mixer collections et objets

self.impots (1998) / self.enfants ->size()

self.salaire ()-100

self.enfants ->select(sexe=Sexe:: masculin)

self.enfants ->isEmpty ()

self.enfants ->forall(age >20)

self.enfants ->collect(salaire)->sum()

self.enfants.salaire ->sum()

self.enfants ->union(self.parents)->collect(age)

Types entiers et rels Integer Valeurs : 1, -5, 34, 24343, ... Oprations : +, -, *, div, mod, abs, max, min

Real Valeurs : 1.5, 1.34, ... Oprations : +, -, *, /, oor, round, max, min

Le type Integer est conforme au type Real

Type boolen Boolean Valeurs : true, false Oprations : not, and, or, xor, implies, if-then-else-endif

L'valuation des oprateurs or, and, if est partielle true or x est toujours vrai, mme si x est indni false and x est toujours faux, mme si x est indni

(age 1000)

and (age >=40 implies salaire >2000)

if age 1000

else salaire > 2000 endif



salaire > (if age notEmpty ()

implies epouse.sexe=Sexe:: Feminin

Elments et singletons Dans tout langage typ il faut distinguer un lment e du singleton contenant cet lment Set{e}

Pour simplier la navigation OCL, une conversion implicite est faite lorsqu'une oprationsur une collection est applique un lement isol elem->prop est quivalent Set{elem}->prop self->size() = 1

Collections Ensembles : Set(T) Elments unique non ordonns

Ensembles ordonns : OrderedSet(T) Elments uniques et ordonns

Sac : Bag(T)



Elments rptables sans ordre Sequence : Sequence(T) Elments rptables mais ordonns

Collection est le type de base Collection(T)

Oprations de base sur les collections Cardinalit : coll -> size() Vide : coll -> isEmpty() Non vide : coll -> nonEmpty() Nombre d'occurrences : coll -> count(elem) Appartenance : coll -> includes( elem ) Non appartenance : coll -> excludes( elem ) Inclusion : coll -> includesAll(coll) Exclusion: coll -> excludesAll(coll) Somme des lements : coll -> sum()

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

Filtrage Select retient les lments vriant la condition coll -> select( cond )

Reject limine ces lements coll -> reject( cond )

Any slectionne l'un des lments vriant la condition coll -> any( cond ) opration non dterministe utile lors de collection ne contenant qu'un lment retourne la valeur indnie si l'ensemble est vide

self.enfants ->select(age >10 and sexe=Sexe:: Masculin)

Autres syntaxes pour le ltrage Il est galement possible de nommer la variable d'expliciter son type

self.employe ->select(age > 50)

self.employe ->select(p | p.age >50 )

self.employe ->select(p:Personne | p.age >50)

self.employe ->reject(p:Personne | p.age forAll( cond )

Exists est le quanticteur existentiel



coll -> exists( cond )

self.enfants ->forall(age exists(sexe=Sexe:: Masculin)

Il est possible de nommer la variable d'expliciter son type de parcourir plusieurs variables la fois

self.enfants

->exists(e1 ,e2 | e1.age=e2.age and e1 e2 )

Unicit Retourne vrai si pour chaque valeur de la collection, l'expression retourne une valeur dif-frente coll->isUnique(expr) Equivalence entre

self.enfants ->isUnique(prenom )}

self.enfants

->forall( e1 ,e2~: Personne |

e1 e2 implies

e1.prenom e2.prenom)

Utile pour dnir la notion de cl en BD

T-uples Champs nomms, pas d'ordre entre les champs Tuples (valeurs)

Tuple{x=-1.5,y=12.6}

Tuple{y=12.6,x=-1.5}

Tuple{y:Real =12.6,x:Real =-1.5}

Tuple{nom='dupont ',prenom='leon ',

age =43}

A partir d'UML 2.0 Dnition de types tuples

TupleType(x:Real ,y:Real)

TupleType(y:Real ,x:Real)

TupleType(nom:String ,prenom:String ,

age:Integer)

Collections imbriques Collections imbriques Jusqu' UML 2.0 pas de collections de collections car peu utilis et plus complexe comprendre

Mise plat intuitive lors de la navigation

self.parents.parents

Mise plat par default li l'opration implicite collect A partir de UML 2.0 imbrications arbitraires des constructeurs de types

Set(Set(Personne ))

Sequence(OrderedSet(Jour))

Trs utile pour spcier des structures non triviales



Conservation de l'imbrication pour la navigation L'opration collect met plat les collections utile pour naviger

enfants.enfants.prenom

= enfants ->collect(enfants)->collect(prenom)

= Bag\{'pierre ','paul ','marie ','paul '}

CollectNested permet de conserver l'imbrication

enfants ->collectNested(enfants.prenom)

= Bag{Bag{'pierre ','paul '},

Bag\{'marie ','paul '}}

Itrateur gnral L'itrateur le plus gnral est iterate Les autres itrateurs (forall, exist, select, etc.) en sont des cas particulier coll -> iterate(

coll ->iterate(

elem~: Type1~;

accumulateur:Type2=

| )

Exemple

enfants ->iterate(

e:Enfant;

ac:Integer =0

| acc+e.age )

Ordre vs. Tri Collections ordonnes Sequence OrderedSet

. . .mais pas forcment tries Squence simple (l'ordre compte) : Sequence { 12, 23, 5, 5, 12 }

Squence trie : Sequence { 5, 5, 12, 12, 23 }

Tri d'une collection Pour trier une collection en fonction d'une expression coll -> sortedBy(expr) L'opration < doit tre dnie sur le type correspond expr

enfants ->sortedBy(age)

let ages = enfants.age -> sortedBy(a|a) in

ages.last()-ages.first ()

enfants ->sortedBy(enfants ->size())->last()

Le rsultat est de type OrderedSet si l'opration est applique sur un Set Sequence si l'opration est applique sur un Bag


4.2 Diagrammes d'tats-transitions 4 MODLISATION AVANCE AVEC UML

4.2 Diagrammes d'tats-transitions

Automates Un automate tats nis est la spcication de la squence d'tats que subira un objet aucours de son cycle de vie.

Un tel automate reprsente le comportement d'un classeur dont les sorties ne dpendent pas seulement de ses entres, mais aussi d'un historique des sollicitations passes.

Cet historique est caractris par un tat. Les objets changent d'tat en rponse des vnements extrieurs donnant lieu destransitions entre tats.

Sauf cas particuliers, chaque instant, chaque objet est dans un et un seul tat.

Etat et transition Les tats sont reprsents par des rectangles aux coins arrondis Les transitions sont reprsentes par des arcs orients liant les tats entre eux. Certains tats, dits composites , peuvent contenir des sous-diagrammes.

Les diagrammes d'tat-transition d'UML reprsentent en fait des automates pile avec embote-ment et concurrence et pas seulement des automates tats nis comme dans les premiresversions d'UML

Diagramme d'tat-transition L'organisation des tats et des transitions pour un classeur donn est reprsente dans undiagramme 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 faonindpendante des autres.

Exemple de diagramme d'tats-transitions


4 MODLISATION AVANCE AVEC UML 4.2 Diagrammes d'tats-transitions

Etat initial et tat nal L'tat initial est un pseudo-tat qui dnit le point de dpart par dfaut pour l'automateou le sous-tat. Lorsqu'un objet est cr, il entre dans l'tat initial.

L'tat nal est un pseudo-tat qui indique que l'excution de l'automate ou du sous-tatest termine.

Evnement dclencheur Les transitions d'un diagramme d'tats-transitions sont dclenches par des vnementsdclencheurs. Un appel de mthode sur l'objet courant gnre un vnement de type call. Le passage de faux vrai de la valeur de vrit d'une condition boolenne gnre im-plicitement un vnement de type change.

La rception d'un signal asynchrone, explicitement mis par un autre objet, gnre unvnement de type signal.

L'coulement d'une dure dtermine aprs un vnement donn gnre un vnementde type after. Par dfaut, le temps commence s'couler ds l'entre dans l'tat courant.

L'vnement dclencheur est indiqu cte de la che reprsentant la transition

Evnements call et signal Un vnement de type call ou signal est dclar ainsi :

nomEvenement(params)

Chaque paramtre a la forme :

param:ClasseParam

Les vnements de type call sont des mthodes dclares au niveau du diagramme declasses.

Les signaux sont dclars par la dnition d'une classe portant le strotype signal, nefournissant pas d'oprations, et dont les attributs sont interprts comme des arguments.

Evnements change et after Un vnement de type change est introduit de la faon suivante :

when(conditionBooleenne)

Il prend la forme d'un test continu et se dclenche potentiellement chaque changementde valeurs des variables intervenant dans la condition.


4.2 Diagrammes d'tats-transitions 4 MODLISATION AVANCE AVEC UML

Un vnement temporel de type after est spci par :

after(duree)

Le paramtre s'value comme une dure, par dfaut coule depuis l'entre dans l'tatcourant.

Par exemple : after(10 secondes).

Transition simple Une transition entre deux tats est reprsente par un arc qui les lie l'un l'autre. Elle indique qu'une instance peut changer d'tat et excuter certaines activits, si unvnement dclencheur se produit et que les conditions de garde sont vries.

Sa syntaxe est la suivante :

nomEvenement(params) [

Introduction à UML 2 - gerard/docs/cours/uml-cours-support.pdf · 4.2 Diagrammes...

Documents

Transcript of Introduction à UML 2 - gerard/docs/cours/uml-cours-support.pdf · 4.2 Diagrammes...