Introduction la modlisation oriente objets avec UML

Olivier Sigaud

Table des matires

1 Vocation de ce document 2 Prsentation gnrale dUML 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Unied : historique des mthodes de conception . . . . . 2.3 Modeling : analyse et conception . . . . . . . . . . . . . 2.4 Language : mthodologie ou langage de modlisation ? 2.5 Diffrentes vues et diagrammes dUML . . . . . . . . . 2 3 3 4 5 6 7 8 8 9 10 10 11 11 12 12 13 14 15 15 16 17 17 18

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

3 Le diagramme des cas (vue fonctionnelle) 3.1 Les cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Liens entre cas dutilisation : include et extend . . . . . . . . . . . . 4 Le diagramme des classes (vue structurelle) 4.1 Introduction au diagramme des classes . . 4.2 Les diffrents niveaux de description . . . 4.3 Les diagrammes de packages . . . . . . . 4.4 Description dune classe . . . . . . . . . 4.4.1 Les attributs . . . . . . . . . . . . 4.4.2 Les oprations . . . . . . . . . . 4.5 Les interfaces . . . . . . . . . . . . . . . 4.6 Les associations . . . . . . . . . . . . . . 4.6.1 Les cardinalits (ou multiplicits) 4.6.2 Attributs et classes dassociation . 4.6.3 Qualicatifs . . . . . . . . . . . . 4.6.4 Associations et attributs drivs . 4.6.5 Ajout de contraintes et de rgles . 1

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

4.7 4.8

Sous-types et gnralisation . . . . . . . . . . . . . . . . . . . . . . 4.7.1 Agrgation et composition . . . . . . . . . . . . . . . . . . . Classes paramtriques . . . . . . . . . . . . . . . . . . . . . . . . . .

18 19 20 21 23 24 24 25 26 26 27 28 29 29 30 31 31 33 48 48 49

5 Les diagrammes de squences (vue fonctionnelle) 6 Les diagrammes dtats (vue dynamique) 6.1 Etats et Transitions . . . . . . . . . . . . . . . . 6.2 Actions et activits . . . . . . . . . . . . . . . . 6.2.1 Exemple : diagramme dtats dun rveil 6.2.2 vnements spciaux . . . . . . . . . . . 6.3 Ordonnancement . . . . . . . . . . . . . . . . . 6.4 Diagrammes hirarchiss . . . . . . . . . . . . . 6.4.1 Paralllisme et synchronisation . . . . . . 6.5 Le diagramme dactivit (vue dynamique) . . . . 6.6 Extension de UML : les strotypes . . . . . . . 6.7 Conclusion . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

7 Glossaire 7.1 Extrait franais du glossaire . . . . . . . . . . . . . . . . . . . . . . . 7.2 Glossaire complet en anglais . . . . . . . . . . . . . . . . . . . . . . 8 NETographie (dernire mise jour : 2001-2002) 8.1 Programmation objets et UML . . . . . . . . . . . . . . . . . . . . . 8.2 Les patterns (ou patrons) . . . . . . . . . . . . . . . . . . . . . . . .

1 Vocation de ce document
Ce document sadresse de futurs ingnieurs qui seront confronts dans leur vie professionnelle au dveloppement dapplications informatiques industrielles, en tant que concepteurs aussi bien que clients. De par sa fonction, lingnieur, quil soit spcialiste dinformatique ou non, doit tre capable de spcier clairement le problme quil doit rsoudre. Sil nest pas informaticien, il aura sans doute dialoguer avec des quipes de conception pour sassurer que ses spcications sont bien comprises. Sil est responsable dune quipe de dveloppement, il aura assimiler les spcications quil aura contribu tablir, puis il devra en mener lanalyse et la conception avant de coner le codage proprement dit des dveloppeurs, puis dialoguer avec les clients pour sassurer de leur satisfaction.

Dans tous les cas, lingnieur aura besoin dun langage ou dune mthode de spcication et de modlisation pour communiquer avec ses collaborateurs, clients et fournisseurs. Cest dans ce cadre que nous prsentons quelques lments du langage UML (Unied Modeling Language), qui sest impos comme un standard que rencontrent tous les ingnieurs dans lindustrie informatique qui utilisent des langages orients objets. Nous considrons dans ce document que le lecteur a dj t form aux principales notions de la programmation oriente objets. Nous renvoyons un polycopi sur le langage JAVA si ce nest pas le cas ([Sig04b]). Par ailleurs, les aspects de mise en uvre dune dmarche reposant sur UML font lobjet dun polycopi complmentaire ([Sig04a]). Nous nous contentons ici dexposer les lments du langage standard de modlisation oriente objets UML, en dcrivant sommairement les diffrentes vues des applications quil permet de modliser. Cette prsentation est conue comme un support pragmatique pour faciliter la tche du lecteur lors de sa premire utilisation dUML, en lui prsentant les aspects les plus utiles et les principales difcults auxquelles il risque dtre confront, plutt que comme un manuel de rfrence ou un catalogue exhaustif. Nous invitons le lecteur consulter les ouvrages de rfrence ([JBR97a, JBR97b, JBR97c]) pour une information approfondie ds lors que ce premier tour dhorizon lui aura permis de sorienter.

2 Prsentation gnrale dUML

2.1 Introduction
Le gnie logiciel et la mthodologie sefforcent de couvrir tous les aspects de la vie du logiciel. Issus de lexprience des dveloppeurs, concepteurs et chefs de projets, ils sont en constante volution, paralllement lvolution des techniques informatiques et du savoir-faire des quipes. Comme toutes les tentatives de mise plat dune exprience et dun savoir-faire, les mthodologies ont parfois souffert dune formalisation excessive, imposant aux dveloppeurs des contraintes parfois contre-productives sur leur faon de travailler. Avec la mise en commun de lexprience et la maturation des savoir-faire, on voit se dvelopper prsent des mthodes de travail la fois plus proches de la pratique relle des experts et moins contraignantes. UML, qui se veut un instrument de capitalisation des savoir-faire puisquil propose un langage qui soit commun tous les experts du logiciel, va dans le sens de cet assouplissement des contraintes mthodologiques. UML signie Unied Modeling Language. La justication de chacun de ces mots

nous servira de l conducteur pour cette prsentation.

2.2 Unied : historique des mthodes de conception

temps

fin 2004

UML 2.0

Rvision 9/97 Soumission lOMG 1/97 Bta version OOPSLA96 OOPSLA95 ...

UML 1.1

UML 1.0
UML 0.9 Unified Method 0.8 Booch93 Booch OMT2 OMT

OCL(IBM)

OOSE

F IG . 1 Historique de la constitution dUML chacune des diffrentes phases de la conception dun logiciel correspondent des problmes ou des contraintes diffrentes. Naturellement, ces niveaux ont fait lobjet de recherches mthodologiques considrables depuis les annes 80. Il en rsulte que de nombreuses mthodes de dveloppement ou danalyse de logiciel ont vu le jour, chacune plus ou moins spcialise ou adapte une dmarche particulire, voire un secteur industriel particulier (bases de donnes, matriel embarqu, ...) [url1]. Celles-ci ayant t dveloppes indpendamment les unes des autres, elles sont souvent partiellement redondantes ou incompatibles entre elles lorsquelles font appel des notations ou des terminologies diffrentes, voire des faux amis. De plus, chaque mthode correspond un ou plusieurs moyens (plus ou moins formel) de reprsentation des rsultats. Celui-ci peut tre graphique (diagramme synoptique, plan physique dun rseau, organigramme) ou textuel (expression dun besoin en langage naturel, jusquau listing du code source). Dans les annes 90, un certain nombre de mthodes orientes objets ont merg, en particulier les mthodes : OMT de James RUMBAUGH [Rum96], BOOCH de Grady B OOCH [Boo94],

 OOSE (Object Oriented Software Engineering) de Ivar JACOBSON qui lon doit les Use cases [JCJO92] 1 . En 1994, on recensait plus de 50 mthodologies orientes objets. Cest dans le but de remdier cette dispersion que les poids-lourds de la mthodologie oriente objets ont entrepris de se regrouper autour dun standard. En octobre 1994, Grady Booch et James Rumbaugh se sont runis au sein de la socit R ATIONAL [url3] dans le but de travailler llaboration dune mthode commune qui intgre les avantages de lensemble des mthodes reconnues, en corrigeant les dfauts et en comblant les dcits. Lors de OOPSLA95 (Object Oriented Programming Systems, Languages and Applications, la grande confrence de la programmation oriente objets), ils prsentent U NIFIED M ETHOD V 0.8. En 1996, Ivar Jacobson les rejoint. Leurs travaux ne visent plus constituer une mthodologie, mais un langage 2 . Leur initiative a t soutenue par de nombreuses socits, que ce soit des socits de dveloppement (dont Microsoft, Oracle, Hewlet-Packard, IBM qui a apport son langage de contraintes OCL , ...) ou des socits de conception dateliers logiciels. Un projet a t dpos en janvier 1997 lOMG 3 en vue de la normalisation dun langage de modlisation. Aprs amendement, celui-ci a t accept en novembre 97 par lOMG sous la rfrence UML-1.1. La version UML-2.0 est annonce pour la n 2004.

2.3 Modeling : analyse et conception

Une bonne mthodologie de ralisation de logiciels suppose une bonne matrise de la distinction entre lanalyse et la conception, distinction que nous exposons dans le polycopi complmentaire ([Sig04a]). Le lecteur verra quen pratique, le respect dune distinction entre des phases danalyse et de conception rigoureusement indpendantes nest pas tenable, mais il est important davoir en tte la diffrence lorsquon sapprte raliser un logiciel. Encore une fois, il est important de garder lesprit quUML noffre pas une mthodologie pour lanalyse et la conception, mais un langage qui permet dexprimer le rsultat de ces phases. Du point de vue des notations employes en UML, les diffrences entre lanalyse et la conception se traduisent avant tout par des diffrences de niveau de dtail dans les diagrammes utiliss. On peut ainsi noter les diffrences suivantes : Dans un diagramme de classes danalyse, les seules classes qui apparaissent servent dcrire des objets concrets du domaine modlis. Dans un diagramme de classes de conception, par opposition, on trouve aussi toutes les classes utilitaires destines assurer le fonctionnement du logiciel.
1 cas 2 voir

dutilisations, cf. la section 3 la page 8 la section 2.4 la page 6 3 Object Management Group, qui sest rendu clbre pour la norme CORBA [url4]

 Dans un diagramme de classes danalyse, on peut se contenter de faire apparatre juste la dnomination des classes, avec parfois le nom de quelques attributs et mthodes quand ceux-ci dcoulent naturellement du domaine modlis. Dans un diagramme de classes de conception, par opposition, tous les attributs et toutes les mthodes doivent apparatre de faon dtaille, avec tous les types de paramtres et les types de retour. Dans un diagramme de squence danalyse, les communications entre les principaux objets sont crits sous forme textuelle, sans se soucier de la forme que prendront ces changes lors de la ralisation du logiciel. Dans un diagramme de squence de conception, par opposition, les changes entre classes gurent sous la forme dappels de mthodes dont les signatures sont totalement explicites. Les tapes permettant de passer de diagrammes danalyse des diagrammes de conception et les motivations de la formalisation progressive que cela entrane sont traits dans le polycopi complmentaire ([Sig04a]).

2.4 Language : mthodologie ou langage de modlisation ?

Il est important de bien faire la distinction entre une mthode qui est une dmarche dorganisation et de conception en vue de rsoudre un problme informatique, et le formalisme dont elle peut user pour exprimer le rsultat (voir le glossaire en annexe). Les grandes entreprises ont souvent leurs propres mthodes de conception ou de ralisation de projets informatiques. Celles-ci sont lies des raisons historiques, dorganisation administrative interne ou encore dautres contraintes denvironnement (dfense nationale, ...) et il nest pas facile den changer. Il ntait donc pas raliste de tenter de standardiser une mthodologie de conception au niveau mondial. UML nest pas une mthode, mais un langage. Il peut donc tre utilis sans remettre en cause les procds habituels de conception de lentreprise et, en particulier, les mthodes plus anciennes telles que celle propose par OMT sont tout fait utilisables. Dailleurs, la socit R ATIONAL (principale actrice de UML) propose son propre processus de conception appel O BJECTORY [JBR97a] et entirement bas sur UML. Ainsi, UML facilite la communication entre clients et concepteurs, ainsi quentre quipes de concepteurs. De plus, sa smantique tant formellement dnie 4 dans [JBR97b] (sous forme de diagramme UML), cela acclre le dveloppement des outils graphiques datelier de gnie logiciel permettant ainsi daller de la spcication (haut niveau) en UML vers la gnration de code (JAVA, C++, ADA, ...). De plus, cela autorise lchange lectronique de documents qui deviennent des spcications excu4 Les contraintes elles-mmes font lobjet dune dnition formelle grce au langage OCL (Object Constraint Language, voir la section 4.6.5 la page 18).

tables en UML. UML ne se contente pas dhomogniser des formalismes existants, mais apporte galement un certain nombre de nouveauts telles que la modlisation darchitectures distribues ou la modlisation dapplications temps-rel avec gestion du multi-tches, dont lexpos dpasse le cadre de ce document.

2.5 Diffrentes vues et diagrammes dUML

Toutes les vues proposes par UML sont complmentaires les unes des autres, elles permettent de mettre en vidence diffrents aspects dun logiciel raliser. On peut organiser une prsentation dUML autour dun dcoupage en vues, ou bien en diffrents diagrammes, selon quon spare plutt les aspects fonctionnels des aspects architecturaux, ou les aspects statiques des aspects dynamiques. Nous adopterons plutt dans la suite un dcoupage en diagrammes, mais nous commenons par prsenter les diffrentes vues, qui sont les suivantes : 1 - la vue fonctionnelle, interactive, qui est reprsente laide de diagrammes de cas et de diagrammes des squences, fera lobjet des sections 3 la page 8 et 5 la page 21. Elle cherche apprhender les interactions entre les diffrents acteurs/utilisateurs et le systme, sous forme dobjectif atteindre dun ct et sous forme chronologique de scnarios dinteraction typiques de lautre. 2 - la vue structurelle, ou statique, prsente dans la section 4 la page 10, runit les diagrammes de classes et les diagrammes de packages. Les premiers favorisent la structuration des donnes et tentent didentier les objets/composants constituant le programme, leurs attributs, oprations et mthodes, ainsi que les liens ou associations qui les unissent. Les seconds sattachent regrouper les classes fortement lies entre elles en des composants les plus autonomes possibles. A lintrieur de chaque package, on trouve un diagramme de classes. 3 - la vue dynamique, qui est exprime par les diagrammes dtats, sera introduite dans la section 6 la page 23. Cette vue est plus algorithmique et oriente traitement , elle vise dcrire lvolution (la dynamique) des objets complexes du programme tout au long de leur cycle de vie. De leur naissance leur mort, les objets voient leurs changement dtats guids par les interactions avec les autres objets. Le diagramme dactivit est une sorte dorganigramme correspondant une version simplie du diagramme dtats. Il permet de modliser des activits qui se droulent en parallle les unes des autres, quand ce paralllisme peut poser problme. En gnral, les diagrammes dtats eux seuls ne permettent pas de faire apparatre les problmes spciques poss par la synchronisation des processus en concurrence, pour assurer la cohrence du comportement et labsence 7

dinterblocage. Etablir un diagramme dactivit peut aider mettre au point un diagramme dtats. Outre les diagrammes prcdemment mentionns, il existe aussi les diagrammes suivants, que nous ne prsenterons pas, dans la mesure o ils relvent plus spciquement de la conception ou de limplmentation. 1 - les diagrammes de collaboration, en appoint de la vue fonctionnelle. Proches des scnarios ou diagrammes de squences, ces diagrammes insistent moins sur le squencement chronologique des vnements. En numrotant les messages pour conserver lordre, ils insistent sur les liens entre objets metteurs et rcepteurs de messages, ainsi que sur des informations supplmentaires comme des conditions denvoi ou des comportements en boucle, ce que ne permettent pas les diagrammes de squence, trop linaires. 2 - les diagrammes de dploiement, spciques de limplmentation, qui indiquent sur quelle architecture matrielle seront dploys les diffrents processus qui ralisent lapplication.

3 Le diagramme des cas (vue fonctionnelle)

3.1 Les cas dutilisation
Le diagramme des cas est un apport dIvar Jacobson UML.

Livreur

Client

Rceptionniste

Comptable

Facturation

Traitement de commande

Gestion de compte client

F IG . 2 Exemple de diagramme de cas Un cas dutilisation (use case) modlise une interaction entre le systme informatique dvelopper et un utilisateur ou acteur interagissant avec le systme. Plus prcisment, un cas dutilisation dcrit une squence dactions ralises par le systme qui produit un rsultat observable pour un acteur. Il y a en gnral deux types de description des use cases : une description textuelle de chaque cas ; 8

 le diagramme des cas, constituant une synthse de lensemble des cas ; Il nexiste pas de norme tablie pour la description textuelle des cas. On y trouve gnralement pour chaque cas son nom, un bref rsum de son droulement, le contexte dans lequel il sapplique, les acteurs quil met en jeu, puis une description dtaille, faisant apparatre le droulement nominal de toutes les interactions, les cas ncessitant des traitements dexceptions, les effets du droulement sur lensemble du systme, etc.

3.2 Liens entre cas dutilisation : include et extend

Il est parfois intressant dutiliser des liens entre cas (sans passer par un acteur), UML en fournit de deux types : la relation utilise (include) et la relation tend (extend). Utilisation de cas : La relation utilise (include) est employe quand deux cas dutilisation ont en commun une mme fonctionnalit et que lon souhaite factoriser celle-ci en crant un sous-cas, ou cas intermdiaire, an de marquer les diffrences dutilisation. Extension de cas (extend) : Schmatiquement, nous dirons quil y a extension dun cas dutilisation quand un cas est globalement similaire un autre, tout en effectuant un peu plus de travail (voire un travail plus spcique). Cette notion utiliser avec discernement permet didentier des cas particuliers (comme des procdures suivre en cas dincident) ds le dbut ou lorsque lattitude face un utilisateur spcique du systme doit tre spcialise ou adapte. Il sagit grosso modo dune variation du cas dutilisation normale.

Retrait despces
uses uses extends

Service lutilisateur

Service au client de la banque

F IG . 3 Exemple dextension et dutilisation Par exemple, dans le cas dun distributeur automatique de billets dans une banque, les utilisateurs du distributeur qui sont clients de la banque peuvent effectuer des oprations qui ne sont pas accessibles lutilisateur normal (par exemple, consultation de solde).

On dira que le cas service au client de la banque tend le cas service lutilisateur . Mais on peut dire aussi que les deux types de clients peuvent effectuer des retraits, si bien que les cas service au client de la banque et service lutilisateur utilisent tous les deux le cas retrait despces . On reprsente cet exemple sur la gure 3.

4 Le diagramme des classes (vue structurelle)

Le modle qui va suivre a t particulirement mis en exergue dans les mthodes orientes objets. Les sections 4.1 la page 10 4.6 la page 15 regroupent les concepts de base et dans les sections 4.7 la page 18 4.8 la page 20 prsentent des notions plus avances.

4.1 Introduction au diagramme des classes

Chauffeur Age Nom
1 conduit 0..* 2..* dessert 1..* 2..* effectue 1 0..*

Trajet
1..*

comprend

Bus

Station

F IG . 4 Un diagramme des classes Un diagramme des classes dcrit le type des objets ou donnes du systme ainsi que les diffrentes formes de relation statiques qui les relient entre eux. On distingue classiquement deux types principaux de relations entre objets : les associations, bien connues des vieux modles entit/association utiliss dans la conception des bases de donnes depuis les annes 70 ; les sous-types, particulirement en vogue en conception oriente objets, puisquils sexpriment trs bien laide de lhritage en programmation. La gure 4 prsente un exemple de diagramme de classes trs simple, tel quon pourrait en rencontrer en analyse. On voit quun simple coup dil suft se faire une premire ide des entits modlises et de leurs relations. Nous allons examiner successivement chacun des lments qui le constituent. Auparavant, nous introduirons les packages.

10

4.2 Les diffrents niveaux de description

Selon lactivit de lingnieur, quil sagisse danalyse, de conception ou dimplmentation, le niveau de dtail avec lequel est reprsent le diagramme des classes change normment. Avant de dessiner un diagramme des classes, il est crucial de savoir partir duquel des trois points de vues lon dcide de se placer : le point de vue de lanalyse, qui en gnral se doit doublier tout aspect de mise en uvre et, en ce sens, est compltement indpendant du logiciel (on ny parlera pas de structuration des donnes : tableaux, pointeurs, listes, ...) ; le point de vue de la conception, qui cherche identier les interfaces, les types des objets, leur comportement externe et la faon interne de les mettre en uvre, sans tre encore x sur un langage ; le point de vue de limplmentation, qui cherche dcrire une classe, ses attributs et ses mthodes en pensant dj au code qui les implmentera et prend en compte les contraintes matrielles de temps dexcution, darchitecture, etc. Dans le cadre dune analyse, seuls les noms des attributs et les principales mthodes publiques de la classe ont tre mentionnes. Dans le cadre dune conception et, plus forte raison, dune implmentation, la description des classes devra tre exhaustive. Mais les diffrences ne se limitent pas au seul niveau de description. De nombreuses classes spciques seront ajoutes lorsque lon passe de lanalyse la conception, lorganisation des diagrammes peut voluer, etc.

4.3 Les diagrammes de packages

IHM Application

Window Manager

Traitements

Accs BDD

F IG . 5 Exemple de diagramme de packages Il nest pas toujours facile de dcomposer proprement un grand projet logiciel en sous-systmes cohrents. En pratique, il sagit de regrouper entre elles des classes lies les unes aux autres de manire faciliter la maintenance ou lvolution du projet et de rendre aussi indpendantes que possible les diffrentes parties dun logiciel. Lart de la conception de grands projets rside dans la division ou modularisation en paquets (package en JAVA), de faible dimension, minimisant les liens interpackages tout en favorisant les regroupements smantiques.

11

Minimiser les liens inter-packages permet de coner la conception et le dveloppement des quipes spares en vitant leurs interactions, donc lventuel cumul des dlais, chaque quipe attendant quune autre ait termin son travail. Les liens entre paquets sont exprims par des relations de dpendance et sont reprsents par une che en pointill, comme il apparat sur la gure 5. Certains outils vrient quil ny a pas de dpendances croises entre paquets. Diverses questions lies au dcoupage en paquets sont traites dans le polycopi complmentaire ([Sig04a]).

4.4 Description dune classe

Lensemble des lments qui dcrivent une classe sont reprsents sur la gure 6. On notera que lon peut spcier le package dappartenance de la classe, dans lequel gure sa description complte, au dessus du nom de la classe.
<< Vehicule >> Voiture + Marque : string = Peugeot Modle : string = 205 GTI + N Imm : string = 75 ZZ 75 # Turbo : boolean = true Nb Roues : int = 4 + Demarrer() + Rouler() Freiner(vitesse: float) : Temps

F IG . 6 Exemple de reprsentation dune classe

4.4.1 Les attributs Pour une classe, un attribut est une forme dgnre dassociation (voir la section 4.6 la page 15) entre un objet de la classe et un objet de classe standard : cest une variable qui lui est en gnral propre (dans certains cas elle peut tre commune la classe et non particulire lobjet, on parle dattributs de classes). Dans le cadre dun diagramme de classes UML en analyse, il faut sinterdire de reprsenter une variable propre une classe sous forme dattribut si la variable est elle-mme instance dune classe du modle. On reprsente donc les relations 12

dattribution entre classes sous forme dassociations et ce nest quau moment du passage la conception que lon dcidera quelles associations peuvent tre reprsentes par des attributs. En revanche, plus on se rapproche de la programmation, plus il faut envisager lattribut comme un champ, une donne proprit de lobjet, alors quune association est bien souvent une rfrence vers un autre objet. La notation complte pour les attributs est la suivante :

visibilit

nomAttribut

type

valeur par dfaut

La visibilit (ou degr de protection) indique qui peut avoir accs lattribut (ou aux oprations dans le cas des oprations). Elle est symbolise par un oprateur : + pour une opration publique, cest--dire accessible toutes les classes (a priori associe la classe propritaire) ; # pour les oprations protges, autrement dit accessibles uniquement par les sous-classes (cf. section 4.7 la page 18) de la classe propritaire ; - pour les oprations prives, inaccessibles tout objet hors de la classe. Il ny a pas de visibilit par dfaut en UML ; labsence de visibilit nindique ni un attribut public ni priv, mais seulement que cette information nest pas fournie. Le type est en gnral un type de base (entier, ottant, boolen, caractres, tableaux...), compte tenu de ce qui a t dit plus haut. La valeur par dfaut est affecte lattribut la cration des instances de la classe, moins quune autre valeur ne soit spcie lors de cette cration. En analyse, on se contente souvent dindiquer le nom des attributs. On note en les soulignant les attributs de classe, cest--dire les attributs qui sont partags par toutes les instances de la classe. Cette notion, reprsente par le mot clef static en C++, se traduit par le fait que les instances nauront pas dans la zone mmoire qui leur est alloue leur propre champ correspondant lattribut, mais iront chercher sa valeur directement dans la dnition de la classe. 4.4.2 Les oprations Une opration, pour une classe donne, est avant tout un travail quune classe doit mener bien, un contrat quelle sengage tenir si une autre classe y fait appel. Sous langle de la programmation, il sagit dune mthode de la classe. La notation complte pour les oprations est la suivante :

visibilit

nomOpration

(listeParamtres) :

typeRetour

{proprit}

13

La proprit, note en franais, ou sous forme dquation logique, permet dindiquer un pr-requis ou un invariant que doit satisfaire lopration. La liste des paramtres est de la forme nom : type = valeur par dfaut Il est souhaitable de distinguer deux familles doprations, celles susceptibles de changer ltat de lobjet (ou un de ses attributs) et celles qui se contentent dy accder et de le visualiser sans laltrer. On parle de modiants, ou mutateurs et de requtes ou accesseurs. On parle galement doprations daccs (qui se contentent de renvoyer la valeur dun attribut) ou doprations de mise jour qui se cantonnent mettre jour la valeur dun attribut. Notons quune opration ne se traduit pas toujours par une unique mthode. Une opration est invoque sur un objet (un appel de procdure) alors quune mthode est le corps de cette mme procdure. En cas de polymorphisme, quand un super-type a plusieurs sous-types, une mme opration correspond autant de mthodes quil y a de sous-types qui ont redni cette opration (+1).

4.5 Les interfaces

Rectangle Size Position Resizable

Drawable

F IG . 7 Exemple de reprsentation dinterfaces La notion dinterface est lgrement variable dun langage de programmation lautre. En C++, on conoit plutt linterface comme la totalit des lments dun objet visibles de lextrieur de cet objet. En pratique, il sagit des mthodes et attributs publics, cest--dire accessibles par toutes les autres classes de lapplication. En JAVA, linterface est plutt vue comme une spcication externe des interactions quune classe peut avoir avec les autres classes de lapplication. Distincte de la liste des mthodes publiques, linterface est plutt un contrat de la spcication de lensemble des traitements que la classe sengage effectuer si elle veut prtendre disposer dune certaine interface. Une classe qui dispose dune interface doit implmenter toutes les oprations dcrites par celle-ci. La notion dinterface propose par UML, bien que thoriquement indpendante de tout langage, semble davantage se rapprocher du sens donn cette notion en JAVA. Un exemple de reprsentation dinterface apparat sur la gure 7.

14

4.6 Les associations

Les associations reprsentent des relations entre objets, cest--dire entre des instances de classes. En gnral, une association est nomme. Par essence, elle a deux rles, selon le sens dans lequel on la regarde. Le rapport entre un client et ses demandes na rien voir avec celui qui unit une demande son client, ne serait-ce que dans le sens o un client peut avoir un nombre quelconque de demandes alors quune demande na en gnral quun client propritaire. On cherchera, pour plus de lisibilit et pour faciliter les phases suivantes de la conception, expliciter sur le diagramme le nom dun rle. En labsence de nom explicite, il est dusage de baptiser le rle du nom de la classe cible. un rle peut tre ajoute une indication de navigabilit, qui exprime une obligation de la part de lobjet source identier le ou les objets cibles, cest--dire en connatre la ou les rfrences. Quand une navigabilit nexiste que dans un seul sens de lassociation, lassociation est dite monodirectionnelle. On place gnralement une che sur le lien qui la reprsente graphiquement, mais ce lien peut tre omis quand il ny a pas dambigut. Une association est bidirectionnelle quand il y a navigabilit dans les deux sens, et induit la contrainte supplmentaire que les deux rles sont inverses lun de lautre. 4.6.1 Les cardinalits (ou multiplicits) Un rle est dot dune multiplicit qui fournit une indication sur le nombre dobjets dune mme classe participant lassociation. La notation est la suivante :
1 0..1 0..* ou * ..* .. , , : : : : : : Obligatoire (un et un seul) Optionnel (0 ou 1) Quelconque Au moins Entre et , , ou

F IG . 8 Cardinalits : notation Les termes que lon retrouve le plus souvent sont : 1,*, 1..* et 0..1 (cf. gure 9). Mais on peut imaginer dautres cardinalits comme 2, pour les extrmits dune arte dun graphe. Il faut noter que les cardinalits se lisent en UML dans le sens inverse du sens utilis dans M ERISE. Ici, la multiplicit qualie la classe auprs de laquelle elle est note.

15

Mari Homme Homme

est mari avec 1 1 est mari avec 0..1 0..1 a t mari avec * *

Epouse Femme Femme

F IG . 9 Cardinalits : exemples Ainsi, sur la gure 4, on indique quun chauffeur peut conduire un nombre quelconque de bus. 4.6.2 Attributs et classes dassociation

Employ

embauche 1..* 1..*

Entreprise

Numro de contrat
F IG . 10 Attribut dassociation Il est frquent quun lien smantique entre deux classes soit porteur de donnes qui le caractrisent. On utilise alors des attributs dassociation, comme cest le cas sur la gure 10.
Employ
embauche 1..* 1..*

Entreprise

Contrat de travail N de contrat

1..* respecte

Convention collective Grille de salaires

F IG . 11 Classe dassociation Lorsque le lien smantique est porteur de donnes qui constituent une classe du modle, on utilise des classes dassociation, comme cest le cas sur la gure 11. On peut aussi avoir utiliser des associations -aires, lorsque les liens smantiques sont intrinsquement partags entre plusieurs objets.

16

4.6.3 Qualicatifs
Socit
matricule 1 1

Employ

F IG . 12 Reprsentation des qualicatifs Un qualicatif est un attribut dassociation (ou un ensemble dattributs) dont les valeurs partitionnent lensemble des objets relis un objet travers une association. On le reprsente comme il apparat sur la gure 12. Par exemple, le numro de scurit sociale permet didentier sans ambigut tous les bnciaires dune prestation sociale. Ou encore, la conjonction dune ligne et dune colonne permet didentier toute case sur un chiquier. La cardinalit indique est contrainte par lemploi du qualicatif : une socit emploie un grand nombre demploys, mais un seul par matricule. 4.6.4 Associations et attributs drivs
contient
1

Socit

Service
*

1 /emploie
{Employ.Socit= Employ.Service.Socit}

0..1

emploie

Employ date de naissance /age

0..1

F IG . 13 Associations et attributs drivs On parle dattribut (ou dassociation) driv(e) lorsque lattribut ou lassociation en question dcoule (ou drive) dautres attributs de la classe ou de ses sous-classes. On les symbolise comme il apparat sur la gure 13 par le prxe / . Bien que les informations quils portent soient souvent redondantes, puisquelles drivent dautres, il est utile de les faire gurer, en spciant le fait quils drivent dautres, pour que les classes qui voudraient se servir dune telle information puissent y accder (sans passer par des chemins complexes ou avoir faire des calculs).

17

On peut voir de tels attributs comme des caches sauvant une valeur pour ne pas avoir la calculer sans cesse, valeur mettre jour au moment opportun, en accord avec les attributs dont ils dpendent. Les reprer comme drivs vite les risques dincohrence. 4.6.5 Ajout de contraintes et de rgles UML propose dajouter des contraintes ou rgles dutilisation, entre accolades. La syntaxe de ces rgles est donne par le langage OCL, contribution dIBM UML. Dans lidal, ces rgles, oprant sur les classes ou les associations devraient correspondre des assertions dans le code du programme, cest--dire des tests de validit, pour viter tout risque de comportement smantiquement incorrect. Il y a un certain nombre de contraintes prdnies dans le langage (tels and, or, incomplete, ordered, disjoint pour les contraintes entre liens), mais on peut aussi crire ses propres contraintes laide dexpressions algorithmiques.

4.7 Sous-types et gnralisation

Les relations de gnralisation/spcialisation nous semblent naturelles car elles sont omniprsentes dans notre conception du monde. Toute classication, par exemple la taxonomie, ou classication des espces animales, exprime des relations de gnralisation/spcialisation. Ainsi, les chimpanzs sont des primates , qui eux-mmes sont des mammifres, qui sont des animaux. On dira que le type chimpanz est un sous-type du type primate, qui lui-mme est un sous-type du type mammifre, qui lui-mme est un sous-type du type animal. Rciproquement, le type primate est une gnralisation des sous-types quil recouvre, savoir le chimpanz, le gorille, lourang-outang, et lhomme. Ces relations sont particulirement utiles et rpandues en analyse et conception orientes objets parce que, derrire toute ide de gnralisation, il y a une ide de description commune, aussi bien pour ce qui est des attributs que des comportements. Analyser ou concevoir en utilisant une hirarchie de types, de classes ou dobjets permet donc de factoriser des attributs ou des comportements communs et navoir dcrire pour chaque sous-type spcialis que ce quil a de spcique. En termes de modlisation, on parle de classication simple ou multiple. Dans le cadre de la classication simple, un objet ne peut appartenir qu un type et un seul, type qui peut ventuellement hriter dun super-type. En classication multiple, un objet peut tre dcrit par plusieurs types qui nont pas forcment de rapport entre eux. Par exemple, du point de vue de la zoologie, un buf est un mammifre, tandis que du point de vue du consommateur cest un aliment riche en protines.

18

Avion
{incomplete}

Planeur

Chasseur
{disjoint}

Avion de ligne

Moyen courrier

Long courrier

F IG . 14 Exemple darbre de gnralisation/spcialisation La classication dynamique permet pour sa part de changer le type dun objet en cours dexcution du programme (en gnral quand on ne peut connatre son type la cration). loppos, une classication statique ne permet pas, une fois instanci dans un type donn, de changer le type de lobjet. La multiplicit ou la dynamicit des classications sont manipuler avec prcaution car ces deux notions ne sont pas supports par tous les langages. Ces aspects peuvent bien souvent tre plus proprement (au sens du langage objets qui les traduira) pris en compte par la notion de classe abstraite ou dinterface. Du point de vue de la programmation, bien entendu, lhritage de classes sera utilis pour raliser ce sous-typage. Selon le langage que lon utilise, toutefois, les contraintes qui psent sur lhritage ne sont pas les mmes. En C++, il est possible, moyennant de grandes prcautions, dutiliser lhritage multiple entre classes. En JAVA, cest impossible, mais les objets peuvent par contre disposer de plusieurs interfaces qui distinguent les diffrentes catgories de service quils sont capables de rendre. 4.7.1 Agrgation et composition Il est des cas particuliers dassociations qui posent souvent problme, ce sont les relations de la forme partie de , pour lesquels plusieurs dnitions existent et donc plusieurs modles et manires de faire. Aussi faut-il sentendre entre concepteurs sur les dnitions qui vont suivre. La composition, reprsente par un losange noir, indique que lobjet partie de ne peut appartenir qu un seul tout. On considre en gnral que les parties dune composition naissent et meurent avec lobjet propritaire. Par exemple, les chambres dun htel entretiennent une relation de composition avec lhtel. Si on rase lhtel, on dtruit les chambres. linverse, on parle dagrgation quand les objets partie de sont juste rfrencs par lobjet, qui peut y accder, mais nen est pas propritaire. Cette relation est note par un losange blanc. Par exemple, un train est constitu dune srie de wa-

19

Agrgation

Composition

F IG . 15 Reprsentations de lagrgation et la composition gons, mais ces wagons peuvent tre employs pour former dautres trains. Si le train est dmantel, les wagons existent toujours. La confusion entre composition et agrgation illustre parfaitement la relative permabilit entre lanalyse et la conception. Devant la difcult dcider de la nature dune relation, dcision qui relve pourtant de lanalyse, on sappuie gnralement sur la conception pour xer son choix. En pratique, on se demande si lobjet partie de peut ou doit tre dtruit lorsquon dtruit lobjet qui le contient et, si la rponse est afrmative, on choisit une relation de composition.

4.8 Classes paramtriques

T Liste

insert(T)

F IG . 16 Reprsentation dune classe paramtrique Les classes paramtriques se rencontrent quand on veut reprsenter des collections dobjets dans un langage fortement typ, o la collection est amene oprer sur diffrents types. An dviter de crer une classe pour toutes les combinaisons collection/type dobjet, on prfre paramtrer toutes les collections par un type formel, sans avoir dcider du type dobjet sur lequel elles seront amenes porter. Les conteneurs dobjets sont en gnral cods sous la forme de classes paramtriques. Cest le cas dans la STL (Standard Templates Library), la librairie de classes paramtriques standard dveloppe pour le C++. Une variante de la STL existe en JAVA, mais elle nest pas reprsente laide de classes paramtriques. Cette notion nest pas supporte en JAVA.

20

Par exemple, quel que soit le type dobjets que contient une liste, il y a des comportements communs toutes les listes : renvoyer le premier ou le dernier lment, compter les lments, insrer ou supprimer un lment, parcourir tous les lments, etc. Pour raliser une seule fois les comportements communs, il suft de reprsenter la classe gnrique Liste, dote de toutes les mthodes et attributs utiles aux travaux raliser sur les objets de la collection et de lui associer le type gnrique T . lintrieur de la classe, T reprsente le type gnrique manipul par la collection. Sur lexemple de la gure 16, lopration insert() prend comme paramtre une variable du type gnrique T. Lorsque lon souhaite par la suite manipuler un cas particulier de liste, une syntaxe proche du C++ est utilise en UML, du type Liste arete Enn, si lon souhaite expliciter tous les cas de listes dont on veut pouvoir se servir, on indique la manire dun sous-typage, mais en pointill, les liens entre la liste mre paramtrique et ses instanciations. Cette association na rien voir avec un sous-typage, il ne sagit en aucun cas de rajouter ou de spcialiser des mthodes particulires dans les nouvelles sous-classes, elles sont parfaitement caractrises par la classe mre et le type T particulier sur lequel elles oprent. En revanche, les compilateurs se chargent en gnral de vrier quont t dnis convenablement sur tous les types T utiliss, tous les attributs et les oprations dont Liste se sert sur T.

5 Les diagrammes de squences (vue fonctionnelle)

Les diagrammes de squences mettent en valeur les changes de messages (dclenchant des vnements) entre acteurs et objets (ou entre objets et objets) de manire chronologique, lvolution du temps se lisant de haut en bas. Chaque colonne correspond un objet (dcrit dans le diagramme des classes), ou ventuellement un acteur, introduit dans le diagramme des cas. La ligne de vie de lobjet reprsente la dure de son interaction avec les autres objets du diagramme. Un diagramme de squences est un moyen semi-formel de capturer le comportement de tous les objets et acteurs impliqus dans un cas dutilisation. On peut indiquer un type de message particulier : les retours de fonction qui, bien entendu, ne concernent aucun message mais signient la n de lappel de lobjet appel. Ils permettent dindiquer la libration de lobjet appelant (ou de lacteur). Un emploi abusif de retours de fonction peut alourdir considrablement le diagramme, aussi un usage parcimonieux est-il conseill. On peut faire apparatre de nombreuses informations de contrle le long de la ligne 21

:Ascenseur Jean:Personne

250 ms

Appel (2ime tage) Allumage bouton dappel Ouverture porte(2ime tage) Ouverture porte(3ime tage)

                

Jacques:Personne
Appel (RdC) 250 ms

Allumage bouton dappel Ouverture porte(RdC) Choix Etage 3 Allumage voyant 3

Ouverture porte(3ime tage)

                                                        

F IG . 17 Un diagramme de squences (ici, il sagit dun diagramme de squence danalyse) de vie dun objet. Par exemple, sur la gure 17, on a fait apparatre le dlai de 250 millisecondes entre le moment o lutilisateur appuie sur un bouton et le moment o le voyant correspondant sallume. Deux notions, lies au contrle des interactions savrent utiles : la premire est la condition qui indique quand un message doit tre envoy. Le message ne sera transmis que si la condition est vrie. On indique les conditions entre crochets au-dessus de larc du message ; la seconde est la faon de marquer la rptitivit dun envoi de message. Par exemple, si lon doit rpter un appel pour toute une collection dobjets (pour tous les lments de la liste des demandes), on fera prcder le dnominateur du message par un * . Un diagramme des squences permet de vrier que tous les acteurs, les classes, les associations et les oprations ont bien t identis dans les diagrammes de cas et de classes. Il constitue par ailleurs une spcication utile pour le codage dun algorithme ou la conception dun automate. Le diagramme de squence de conception ci-dessous permet de voir un exemple dans lequel la signature des mthodes est peu prs formalise.

22

myMan:Manager

myServ:Serveur

          
getAllTransactions() tr1:Transaction tr2:Transaction tr3:Transaction

                                                       

cl2:Client

getAccountNumber(myId) number:int

addMoney(accountNb:int, amount:int) newCashAmount:int

                                                     

250 ms

F IG . 18 Un diagramme de squences de conception

6 Les diagrammes dtats (vue dynamique)

#! $ #$

Etat initial

Etat final

!! ""

Mineur

anniversaire[age=18]

Majeur

Evnement

Contrainte

F IG . 19 Le diagramme dtats dun citoyen Les diagrammes dtats dcrivent tous les tats possibles dun objet (vu comme une machine tats). Ils indiquent en quoi ses changements dtats sont induits par des vnements. Les modles orients objets sappuient la plupart du temps sur les Statecharts de David Harel [Har87]. Cest aussi le cas dUML. Si les diagrammes de squences regroupaient tous les objets impliqus dans un unique cas dutilisation, les diagrammes dtats indiquent tous les changements dtats dun seul objet travers lensemble des cas dutilisation dans lequel il est impliqu. Cest donc une vue synthtique du fonctionnement dynamique dun objet. 23

Les diagrammes dtats identient pour une classe donne le comportement dun objet tout au long de son cycle de vie (de la naissance ou tat initial, symbolise par le disque plein noir, la mort ou tat nal, disque noir couronn de blanc).

6.1 Etats et Transitions

On distingue deux types dinformation sur un diagramme dtats : des tats, comme ltat initial, ltat nal, ou les tats courants (sur la gure 19, Mineur et Majeur). et des transitions, induisant un changement dtat, cest--dire le passage dun tat un autre. Une transition est en gnral tiquete par un label selon la syntaxe :

Nomvnement

Garde (ou contrainte) ] /

NomAction

Sur la gure 19, lvnement anniversaire fait passer de ltat Mineur dans ltat Majeur, si lge est 18 ans,. Une garde est une condition attache une transition. La transition garde ne sera franchie que si la condition de garde est satisfaite. En gnral, un tat a une activit associe, quon indique sous le nom de ltat avec le mot-clef do/ .

6.2 Actions et activits

e3[cond Y]/a5

Etat e1[cond X]/a0 entry[cond In]/a1 e2/a4 do/activit exit[cond Out]/a2

e4[cond Z]/a3

F IG . 20 Les diffrents types daction et dactivits Il est important de faire la distinction entre une action (ponctuelle) attache une transition et une activit (continue), attache un tat. On dira quune action se caractrise par un traitement bref et atomique (inscable donc non premptif). En revanche, une activit nest pas ncessairement instantane et peut tre interrompue par larrive dun vnement extrieur, et de laction quil induira.

24

Quand une transition ne dispose pas de label (donc pas dvnement), il est sousentendu que la transition aura lieu ds la n de lactivit. On parle de transition automatique. Une auto-transition est une transition dun tat vers lui-mme. On nindique de telles transitions que si elles rpondent un vnement externe auquel lobjet doit rpondre. Si un tat rpond un vnement laide dune action qui ne provoque pas un changement dtat, on parle daction interne. On lindique, pour allger le diagramme, en crivant : Nomvnement / NomActionInterne dans le corps de ltat. Le comportement en cas daction interne est compltement diffrent de celui de lauto-transition, comme cela apparatra dans la section 6.3 la page 26. 6.2.1 Exemple : diagramme dtats dun rveil
alarm on(H alarme) [heure= H alarme]

% '% '&

Dsarm
alarm off

Arm

do/sonner
stop sonnerie

alarm off

F IG . 21 Exemple : diagramme dtats dun rveil On veut modliser un rveil matin qui dispose de trois boutons : alarm on/off, arrt de la sonnerie et rglage de lalarme. tout moment, le rveil dispose dune heure dalarme, lheure laquelle il doit sonner. Cette heure dalarme peut tre modie, on suppose simplement quon xe une heure dalarme quand on met lalarme sur on . Chaque appui sur les boutons constitue un vnement qui dclenche une transition, si le rveil tait dans un tat sensible lvnement. Si le rveil est dsarm et si on appuie sur alarm on, il passe dans ltat arm. Si le rveil est arm ou est en train de sonner et si on appuie sur alarm off, il passe dans ltat dsarm. Si le rveil est en train de sonner et si lon appuie sur arrt, il passe dans ltat arm. 25

Par ailleurs, si lheure dalarme est atteinte et si le rveil est arm, il se met sonner. La transition automatique indique que, quand la sonnerie cesse toute seule la n de lactivit do/sonner , le rveil passe automatiquement dans ltat arm. 6.2.2 vnements spciaux UML offre la possibilit de distinguer deux types dvnements spciques, que sont les vnements dentre (nots entry/) et les vnements de sortie (nots exit/). Toute action relie un vnement dentre sera excute chaque fois quon entre dans ltat, par nimporte quelle transition qui y conduit. A loppos, laction lie un vnement de sortie est dclenche chaque fois que lon sort de ltat, quelle que soit la transition incrimine. En cas dauto-transition, ou transition propre, on effectue les oprations correspondant une sortie puis les oprations correspondant une entre. Un plantage dordinateur constitue un bon exemple de transition propre : vous tiez en train de saisir un texte, lordinateur plante (vnement), vous le reboutez (action associe) puis vous reprenez votre activit zro (le contexte na pas t sauv).

6.3 Ordonnancement
Lordre dexcution des actions et activits dun tat donn est x de la faon suivante, selon le type dvnement dclencheur : En entre On commence par raliser laction sur la transition dentre, puis laction dentre, puis lactivit associe ltat. Sur lexemple de la gure 20, si toutes les conditions sont vries, le dclenchement de lvnement entrane la squence dactions , , puis le lancement de lactivit.

021 043

(!)

En interne On commence par interrompre lactivit en cours, puis on excute laction interne, puis on reprend lactivit. Le contexte de lactivit est sauv lors de son interruption, en vue de la reprise. Sur lexemple de la gure 20, si toutes les conditions sont vries, le dclenchement de lvnement entrane linterruption de lactivit, lexcution de laction , puis la reprise de lactivit.

087

(65

En sortie On commence par interrompre lactivit en cours, puis on excute laction de sortie, puis laction sur la transition de sortie. Cette fois, le contexte de lactivit nest pas sauv lors de son interruption. Sur lexemple de la gure 20, si toutes les conditions sont vries, le dclenchement de lvnement entrane linterruption de lactivit, puis lexcution des actions puis .

0BA

02C

(@9

26

Transition propre On commence par interrompre lactivit en cours, puis on excute laction de sortie, puis laction associe la transition propre, puis laction dentre, puis lactivit associe ltat. On note que cette fois lactivit est rinitialise, puisquon est sorti de ltat. Sur lexemple de la gure 20, si toutes les conditions sont vries, le dclenchement de lvnement entrane linterruption de lactivit, puis lexcution des actions , , puis , puis le lancement de lactivit.

0BA 0BE

(6D 0F3

6.4 Diagrammes hirarchiss

Transmission

G IG IH P QP QH

Point mort
Stop Forward

Backward Stop

Marche arrire

Marche avant
Up Up

Premire

Down

Seconde

Down

Troisime

F IG . 22 Exemple de diagramme hirarchis : transmission automatique De dcoupage en dcoupage, un diagramme dtats devient vite illisible. Trop dtats senchanent et leurs liens se multiplient. Les automates hirarchiques visent rsoudre ce problme. La construction dautomates hirarchiques permet de retrouver au niveau dynamique des notions structurelles propres aux diagrammes de classes. On peut rafner la description dun tat en le dcomposant en sous-tats, pour faire apparatre un comportement dynamique interne ltat. On peut au contraire donner une vue plus synthtique en rassemblant sous un mme tat un ensemble dtats constituant un comportement dynamique isolable . Dans un cas comme dans lautre, il faut respecter des contraintes dhomognit sur les vnements, actions et auto-transitions an que le comportement externe du sur-tat concide avec celui du diagramme plus prcis quil contient. En particulier, quand on entre dans le sur-tat, il faut prciser lequel des sous-tats est le sous-tat initial. Par ailleurs, le fait de faire apparatre des tats embots permet dassocier ltat englobant les actions et transitions qui sont communes tous les sous-tats. Lintrt principal de la hirarchie est donc la factorisation des actions et activits. En pratique, un sous-tat hrite de son sur-tat les actions internes et les transitions de sortie, mais il nhrite pas des transitions en entre ni des activits.

27

Ein

Etat englobant entry/a0 exit/a1

Eout Ein Etat interne entry/a2 exit/a3 Eout a0,a2 a3,a1

RSTS R TR

F IG . 23 Ordonnancement La ralisation dautomates hirarchiques pose de nouveaux problmes dordonnancement. La logique qui prside cet ordonnancement est simple, elle apparat sur la gure 23. Quand on entre dans ltat englobant, on entre dans ltat interne initial. On commence par entrer dans ltat le plus englobant pour aller vers le plus interne. On commence par sortir de ltat le plus interne avant de sortir de ltat le plus englobant. 6.4.1 Paralllisme et synchronisation

X YX YV

`VaV ` aV ` aV ` aV ` aV ` aV ` a` `VaV ` aV ` aV ` aV ` aV ` aV ` a` `V bV`V ba `V ba `V ba `V ba `V ba `V ba `cba cV cV cV cV cV cV bVcV b cV b cV b cV b cV b cV b cb bVcV b cV b cV b cV b cV b cV b cb

Etat composite do/a1 do/a3 do/a5

f gV f gV f gV f gV f gV f gf gV f gV f gV f gV f gV f gf gfVgV f f f f f feV V g V g V g V g V g gV d d d d d d gfed V e V e V e V e V e do/a4 d eV d eV d eV d eV d eV d ed eV d d d d d d ed V e V e V e V e V e eV do/a6

do/a2

U WU WV

F IG . 24 Paralllisme et synchronisation Les automates permettent de modliser le paralllisme. Un mme objet ou une collection dobjets peuvent se trouver un instant donn dans plusieurs tats distincts reprsentant diffrents aspects de leur fonctionnement. On peut ainsi associer un objet plusieurs automates qui fonctionnent en parallle. Mais, par ailleurs, on peut vouloir coordonner ces automates ou les synchroniser. Cela se fait laide de ots de contrle convergents et divergents. Sur la gure 24, les activits A1, A3 et A5 seront lances en mme temps. A2 sera lance la n de A1, A4 celle de A3 et A6 celle de A5. Par contre, la transition vers ltat nal naura

28

lieu quune fois que A2, A4 et A6 seront toutes termines.

6.5 Le diagramme dactivit (vue dynamique)

s ts ti
Mettre un filtre Mettre du caf

Chercher un caf

Remplir le rservoir deau Prendre une tasse

Allumer la cafetire Le caf passe

Servir

qiri q ri q ri q ri q ri q ri q ri q ri q ri q rq hipi h ph

F IG . 25 Exemple de diagramme dactivit : faire un caf Le diagramme dactivit est un cas particulier de diagramme dtats, dans lequel chaque tat correspond une activit constituant un lment dune tche globale raliser. Le but de ce diagramme est de mettre en vidence les contraintes de squentialit et de paralllisme qui psent sur la tche globale. Ainsi, sur la gure 25, on voit que, pour se faire un caf, on peut simultanment mettre un ltre la cafetire, remplir le rservoir deau et prendre une tasse mais que, par contre, il faut attendre davoir mis un ltre pour mettre du caf.

6.6 Extension de UML : les strotypes

Avant de conclure, il faut signaler que le langage UML est extensible grce la notion de strotype. Un certain nombre de strotypes sont prdnis. Cest le cas par exemple pour la notion dinterface, qui est dnie en UML par un strotype, mais un utilisateur peut en dnir dautres pour les besoins dun projet. Ainsi, rien nempche dtendre le nombre de diagrammes utilisables. Par exemple, pour certaines applications, on peut utiliser un modle driv du Grafcet [url5] en alternative aux modles des StateCharts [Har87] sur lequel sappuie le langage UML pour dcrire laspect dynamique des objets. Toutefois, il ne faut pas abuser de cette

29

possibilit de rednition, dans la mesure o elle remet en cause le caractre standard des vues proposes par UML.

6.7 Conclusion
Il faut retenir de ce document quUML fournit un moyen visuel standard pour spcier, concevoir et documenter les applications orientes objets, en collectant ce qui se faisait de mieux dans les dmarches mthodologiques prexistantes. En n de compte, lintrt de la normalisation dun langage de modlisation tel que UML rside dans sa stabilit et son indpendance vis--vis de tout fournisseur doutil logiciel. Quand au langage lui-mme, il a t conu pour couvrir tous les aspects de lanalyse et de la conception dun logiciel, en favorisant une dmarche souple fonde sur les interactions entre les diffrentes vues que lon peut avoir dune application. Il permet enn de fournir directement une bonne partie de la documentation de ralisation, dans le cours mme des processus danalyse et de conception. Finalement, les bnces que lon retire dUML sont multiples. Dune part, le langage, tel quil a t conu, incite ladoption dune dmarche de modlisation souple et itrative qui permet de converger efcacement vers une bonne analyse et une bonne conception. Dautre part, parce quil est formalis (cest--dire que sa smantique est clairement spcie et dcrite, on parle de langage semi-formel) et standard, le langage est support par diffrents outils, qui peuvent rendre des services dans la transition des diffrentes vues au code et du code aux diffrentes vues. Dans le premier cas, les outils deviennent capables de gnrer des squelettes de code. Dans le second cas, il sagit dengendrer des vues UML partir du code, cest le reverse engineering 5 . Enn, on peut imaginer termes des outils de dtection automatiques dincohrence entre les diffrentes vues. Certains de ces aspects sont oprationnels (la dtection dinterdpendances entre packages, la propagation des modication dune classe sur diffrentes vues, ...) dautres sont encore du domaine de la recherche, nous ne les aborderons pas.
5 Sur

ces deux points, voir le polycopi complmentaire [?].

30

7 Glossaire
Le glossaire ci-dessous dnit la majorit des termes utiliss dans UML. Il a t tabli par lOMG 6 , organisation internationale qui se charge de standardiser ou normaliser les pratiques de la programmation et de la conception oriente objets. Nous avons choisi de conserver ce glossaire en anglais pour viter les problmes de traduction que posent tous les vocabulaires techniques. Nous commenons nanmoins par donner un extrait de glossaire en franais.

7.1 Extrait franais du glossaire

acteur : un acteur est une entit externe au systme dvelopper, mais il est actif dans les transactions avec celui-ci. Un acteur peut non seulement tre humain (par exemple un client) mais encore purement matriel ou logiciel. Il est utilis dans les diagrammes de cas. action : opration instantane (ininterruptible) ralise par un tat ou une transition dun tat vers un autre tat. activit : opration continue ralis par un tat lorsquil est actif. agrgation : une forme spciale dassociation de la forme partie de dans laquelle une classe (lagrgat) est constitue dun ensemble dautres classes. cache : moyen de conserver en mmoire une information prcdemment calcule dans le but de la rendre accessible rapidement. Par exemple les attributs drivs sont un moyen de raliser un cache. collections : type de donnes forms partir dlments de base. Une collection peut tre ordonne (comme les listes) ou non (comme les ensembles). composition : forme particulire dagrgation dans laquelle la vie de llment composite et celle des composants sont lies. Les composants peuvent tre assimils des parties physiques du composite. entit/association : modle assez ancien et essentiellement utilis pour les systme de base de donnes (Merise, MCX). tat : situation dun objet un instant donn. La situation dun objet est dnie par ses attributs et par ltat des objets dont il dpend. Un objet peut changer dtat par le franchissement dune transition. Un tat composite (ou super-tat) peut contenir plusieurs tats. Il existe trois tats particuliers appels pseudo-tat : ltat dentre (reprsent par un disque noir), ltat de sortie (disque noir dans un cercle) et lhistorique (un H dans un cercle). Le pseudo-tat historique est une
6 Object

Management Group

31

forme de pseudo-tat dentre pour lequel lobjet (ou ltat composite) reprend la dernire situation active quil avait avant sa dsactivation. Ltat est llment principal du diagramme dtats propos par UML. vnement : un changement signicatif (qui a une inuence) dans lenvironnement ou ltat dun objet, parfaitement localise dans le temps et dans lespace. Un vnement peut tre constitu par la rception dun message. extends : relation de dpendance de type extension entre deux use cases. formalisme : ensemble de notations associ une smantique formelle (et non ambigu). garde (condition de) : condition qui doit tre satisfaite pour valider le dclenchement de la transition qui lui est associe. gnralisation : relation entre une classe plus gnrale et une classe plus spcique. Une instance de llment le plus spcique peut tre utilis lendroit o lutilisation de llment le plus gnral est autoris. hritage : caractristique de la programmation oriente objets qui permet une classe (la lle) hritant dune autre classe (la mre) davoir lensemble des attributs et mthodes de la classe mre prdnis lors de sa cration. interface : construction permettant de dcrire le comportement visible de lextrieur dune classe, dun objet ou dune autre entit. Linterface comprend en particulier la signature des oprations de cette classe. Une interface est une classe abstraite sans attributs ni mthodes, contenant seulement des oprations abstraites. mthode (1) : dmarche dorganisation et de conception en vue de rsoudre un problme informatique (par opposition un formalisme utilis par cette mthode). mthode (2) : corps de la procdure invoque par un objet lors de la demande dune opration. Il peut y avoir plusieurs mthodes pour une mme opration. message : mcanisme par lequel les objets communiquent entre eux. Un message est destin transmettre de linformation et/ou demander une raction en retour. La rception dun message est considrer comme un vnement. La syntaxe de lmission dun message est de la forme : nomObjetDestination.nomMessage(parametresEventuels) Un message peut tre respectivement synchrone ou asynchrone suivant que lmetteur attend ou non une rponse. opration : demande faite par message un objet. Lobjet invoque alors la mthode correspondante qui peut en cas dhritage tre dnie dans la classe mre de la classe destination. 32

signature : ensemble dinformations dune mthode comprenant le nombre, lordre et le type des paramtres. La signature et le contexte dappel permet au compilateur de choisir entre plusieurs mthodes de mme nom pour une mme opration donne. strotype : moyen propos par UML pour dcrire une extension au langage. Un strotype permet de regrouper sous un mme nom un ensemble de classes ayant des caractristiques communes. transition : permet un objet de passer dun tat source un autre tat destination. Si les tats source et destination sont identiques, on parle dauto-transition. uses : relation de dpendance de type utilisation entre deux use cases visibilit (ou protection) : caractristique des attributs dterminant laspect de condentialit de ceux-ci vis--vis des autres classes. Les visibilits suivantes sont reconnues par UML : + (publique) toute classe accs cet attribut, # (protg) seules les mthodes de la classe ou dune classe lle ont accs cet attribut, - (priv) laccs et restreint aux mthodes de la classe mme,

7.2 Glossaire complet en anglais

abstract : class A class that cannot be directly instantiated. Contrast :concrete class. abstraction : The essential characteristics of an entity that distinguish it from all other kinds of entities. An abstraction denes a boundary relative to the perspective of the viewer. action : The specication of an executable statement that forms an abstraction of a computational procedure. An action typically results in a change in the state of the system, and can be realized by sending a message to an object or modifying a link or a value of an attribute. action sequence : An expression that resolves to a sequence of actions. action state : A state that represents the execution of an atomic action, typically the invocation of an operation. activation : The execution of an action. active class : A class whose instances are active objects. See : active object. active object : An object that owns a thread and can initiate control activity. An instance of active class. See : active class, thread.

33

activity graph : A special case of a state machine that is used to model processes involving one or more classiers. Contrast : statechart diagram. actor [class ] : A coherent set of roles that users of use cases play when interacting with these use cases. An actor has one role for each use case with which it communicates. actual parameter : Synonym : argument. aggregate [class ] : A class that represents the whole in an aggregation (whole-part) relationship. See : aggregation. aggregation : A special form of association that species a whole-part relationship between the aggregate (whole) and a component part. See : composition. analysis : The part of the software development process whose primary purpose is to formulate a model of the problem domain. Analysis focuses what to do, design focuses on how to do it. Contrast : design. analysis time : Refers to something that occurs during an analysis phase of the software development process. See : design time, modeling time. architecture : The organizational structure and associated behavior of asystem. An architecture can be recursively decomposed intoparts that interact through interfaces, relationships thatconnect parts, and constraints for assembling parts. Partsthat interact through interfaces include classes, components and subsystems. argument : A binding for a parameter that resolves to a run-time instance. Synonym : actual parameter. Contrast : parameter. artifact : A piece of information that is used or produced by a software development process. An artifact can be a model, a description, or software. Synonym : product. association : The semantic relationship between two or more classiers that species connections among their instances. association class : A model element that has both association and class properties. An association class can be seen as an association that also has class properties, or as a class that also has association properties. association end : The endpoint of an association, which connects the association to a classier. attribute : A feature within a classier that describes a range of values that instances of the classier may hold. behavior : The observable effects of an operation or event, including its results.

34

behavioral feature : A dynamic feature of a model element, such as an operation or method. behavioral model aspect : A model aspect that emphasizes the behavior of the instances in a system, including their methods, collaborations, and state histories. binary association : An association between two classes. A special case of an n-ary association. binding : The creation of a model element from a template by supplying arguments for the parameters of the template. boolean : An enumeration whose values are true and false. boolean expression : An expression that evaluates to a boolean value. cardinality : The number of elements in a set. Contrast : multiplicity. child : In a generalization relationship, the specialization of another element, the parent. See : subclass, subtype. Contrast : parent. call : An action state that invokes an operation on a classier. class : A description of a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment. See : interface. classier : A mechanism that describes behavioral and structural features. Classiers include interfaces, classes, datatypes, and components. classication : The assignment of an object to a classier. See dynamic classication, multiple classication and static classication. class diagram : A diagram that shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships. client : A classier that requests a service from another classier. Contrast : supplier. collaboration : The specication of how an operation or classier, such as a use case, is realized by a set of classiers and associations playing specic roles used in a specic way. The collaboration denes an interaction. See : interaction. collaboration : diagram A diagram that shows interactions organized around the structure of a model, using either classiers and associations or instances and links. Unlike a sequence diagram, a collaboration diagram shows the relationships among the instances. Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. See : sequence diagram. comment : An annotation attached to an element or a collection of elements. A note has no semantics. Contrast : constraint.

35

compile time : Refers to something that occurs during the compilation of a software module. See : modeling time, run time. component : A physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code (source, binary or executable) or equivalents such as scripts or command les. component diagram : A diagram that shows the organizations and dependencies among components. composite [class ] : A class that is related to one or more classes by a composition relationship. See : composition. composite aggregation : Synonym : composition. composite state : A state that consists of either concurrent (orthogonal) substates or sequential (disjoint) substates : See : substate. composition : A form of aggregation association with strong ownership and coincident lifetime as part of the whole. Parts with non-xed multiplicity may be created after the composite itself, but once created they live and die with it (i.e., they share lifetimes). Such parts can also be explicitly removed before the death of the composite. Composition may be recursive. Synonym : composite aggregation. concrete class : A class that can be directly instantiated. Contrast : abstract class. concurrency : The occurrence of two or more activities during the same time interval. Concurrency can be achieved by interleaving or simultaneously executing two or more threads. See : thread. concurrent substate : A substate that can be held simultaneously with other substates contained in the same composite state. See : composite state. Contrast : disjoint substate. constraint : A semantic condition or restriction. Certain constraints are predened in the UML, others may be user dened. Constraints are one of three extensibility mechanisms in UML. See : tagged value, stereotype. container : 1. An instance that exists to contain other instances, and that provides operations to access or iterate over its contents. (for example, arrays, lists, sets). 2. A component that exists to contain other components. containment hierarchy : A namespace hierarchy consisting of model elements, and the containment relationships that exist between them. A containment hierarchy forms a graph. 36

context : A view of a set of related modeling elements for a particular purpose, such as specifying an operation. datatype : A descriptor of a set of values that lack identity and whose operations do not have side effects. Datatypes include primitive pre-dened types and userdenable types. Pre-dened types include numbers, string and time. User-denable types include enumerations. dening model [MOF ] : The model on which a repository is based. Any number of repositories can have the same dening model. delegation : The ability of an object to issue a message to another object in response to a message. Delegation can be used as an alternative to inheritance. Contrast : inheritance. dependency : A relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element). deployment diagram : A diagram that shows the conguration of run-time processing nodes and the components, processes, and objects that live on them. Components represent run-time manifestations of code units. See : component diagrams. derived element : A model element that can be computed from another element, but that is shown for clarity or that is included for design purposes even though it adds no semantic information. design : The part of the software development process whose primary purpose is to decide how the system will be implemented. During design strategic and tactical decisions are made to meet the required functional and quality requirements of a system. design time : Refers to something that occurs during a design phase of the software development process. See : modeling time. Contrast : analysis time. development process : A set of partially ordered steps performed for a given purpose during software development, such as constructing models or implementing models. diagram : A graphical presentation of a collection of model elements, most often rendered as a connected graph of arcs (relationships) and vertices (other model elements). UML supports the following diagrams : class diagram, object diagram, use case diagram, sequence diagram, collaboration diagram, state diagram, activity diagram, component diagram, and deployment diagram. disjoint substate : A substate that cannot be held simultaneously with other substates contained in the same composite state. See : composite state. Contrast : concurrent substate. 37

distribution unit : A set of objects or components that are allocated to a process or a processor as a group. A distribution unit can be represented by a run-time composite or an aggregate. domain : An area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area. dynamic classication : A semantic variation of generalization in which an object may change its classier. Contrast : static classication. element : An atomic constituent of a model. entry action : An action executed upon entering a state in a state machine regardless of the transition taken to reach that state. enumeration : A list of named values used as the range of a particular attribute type. For example, RGBColor = {red, green, blue}. Boolean is a predened enumeration with values from the set {false, true}. event : The specication of a signicant occurrence that has a location in time and space. In the context of state diagrams, an event is an occurrence that can trigger a transition. exit action : An action executed upon exiting a state in a state machine regardless of the transition taken to exit that state. export : In the context of packages, to make an element visible outside its enclosing namespace. See : visibility. Contrast : export [OMA], import. expression : A string that evaluates to a value of a particular type. For example, the expression (7 + 5 * 3) evaluates to a value of type number. extend : A relationship from an extension use case to a base use case, specifying how the behavior dened for the extension use case augments (subject to conditions specied in the extension) the behavior dened for the base use case. The behavior is inserted at the location dened by the extension point in the base use case. The base use case does not depend on performing the behavior of the extension use case. See extension point, include. facade : A stereotyped package containing only references to model elements owned by another package. It is used to provide a public view of some of the contents of a package. feature : A property, like operation or attribute, which is encapsulated within a classier, such as an interface, a class, or a datatype. nal state : A special kind of state signifying that the enclosing composite state or the entire state machine is completed. 38

re : To execute a state transition. See : transition. focus of control : A symbol on a sequence diagram that shows the period of time during which an object is performing an action, either directly or through a subordinate procedure. formal parameter : Synonym : parameter. framework : 1. A stereotyped package consisting mainly of patterns. See : pattern. 2. An architectural pattern that provides an extensible template for for applications within a specic domain. generalizable element : A model element that may participate in a generalization relationship. See : generalization. generalization : A taxonomic relationship between a more general element and a more specic element. The more specic element is fully consistent with the more general element and contains additional information. An instance of the more specic element may be used where the more general element is allowed. See : inheritance. guard condition : A condition that must be satised in order to enable an associated transition to re. implementation : A denition of how something is constructed or computed. For example, a class is an implementation of a type, a method is an implementation of an operation. implementation inheritance : The inheritance of the implementation of a more specic element. Includes inheritance of the interface. Contrast : interface inheritance. import : In the context of packages, a dependency that shows the packages whose classes may be referenced within a given package (including packages recursively embedded within it). Contrast : export. include : A relationship from a base use case to an inclusion use case, specifying how the behavior for the base use case contains the behavior of the inclusion use case. The behavior is included at the location which is dened in the base use case. The base use case depends on performing the behavior of the inclusion use case, but not on its structure (i.e., attributes or operations). See extend. inheritance : The mechanism by which more specic elements incorporate structure and behavior of more general elements related by behavior. See generalization. instance An entity to which a set of operations can be applied and which has a state that stores the effects of the operations. See : object.

39

interaction : A specication of how stimuli are sent between instances to perform a specic task. The interaction is dened in the context of a collaboration. See collaboration. interaction diagram : A generic term that applies to several types of diagrams that emphasize object interactions. These include collaboration diagrams and sequence diagrams. interface : A named set of operations that characterize the behavior of an element. interface inheritance : The inheritance of the interface of a more specic element. Does not include inheritance of the implementation. Contrast : implementation inheritance. internal transition : A transition signifying a response to an event without changing the state of an object. layer : The organization of classiers or packages at the same level of abstraction. A layer represents a horizontal slice through an architecture, whereas a partition represents a vertical slice. Contrast : partition. link : A semantic connection among a tuple of objects. An instance of an association. See : association. link end : An instance of an association end. See : association end. message : A specication of the conveyance of information from one instance to another, with the expectation that activity will ensue. A message may specify the raising of a signal or thecall of an operation. metaclass : A class whose instances are classes. Metaclasses are typically used to construct metamodels. meta-metamodel : A model that denes the language for expressing a metamodel. The relationship between a meta-metamodel and a metamodel is analogous to the relationship between a metamodel and a model. metamodel : A model that denes the language for expressing a model. metaobject : A generic term for all metaentities in a metamodeling language. For example, metatypes, metaclasses, metaattributes, and metaassociations. method : The implementation of an operation. It species the algorithm or procedure associated with an operation. model [MOF ] : An abstraction of a physical system, with a certain purpose. See : physical system. Usage note : In the context of the MOF specication, which describes a meta-metamodel, for brevity the meta-metamodel is frequently to as simply the model. 40

model aspect : A dimension of modeling that emphasizes particular qualities of the metamodel. For example, the structural model aspect emphasizes the structural qualities of the metamodel. model elaboration : The process of generating a repository type from a published model. Includes the generation of interfaces and implementations which allows repositories to be instantiated and populated based on, and in compliance with, the model elaborated. model element [MOF ] : An element that is an abstraction drawn from the system being modeled. Contrast : view element. In the MOF specication model elements are considered to be metaobjects. modeling time : Refers to something that occurs during a modeling phase of the software development process. It includes analysis time and design time. Usage note : When discussing object systems, it is often important to distinguish between modeling-time and run-time concerns. See : analysis time, design time. Contrast : run time. module : A software unit of storage and manipulation. Modules include source code modules, binary code modules, and executable code modules. See : component. multiple classication : A semantic variation of generalization in which an object may belong directly to more than one classier. See : static classication, dynamic classication. multiple inheritance : A semantic variation of generalization in which a type may have more than one supertype. Contrast : single inheritance. multiplicity : A specication of the range of allowable cardinalities that a set may assume. Multiplicity specications may be given for roles within associations, parts within composites, repetitions, and other purposes. Essentially a multiplicity is a (possibly innite) subset of the non-negative integers. Contrast : cardinality. multi-valued [MOF ] : A model element with multiplicity dened whose Multiplicity Type : : upper attribute is set to a number greater than one. The term multi-valued does not pertain to the number of values held by an attribute, parameter, etc. at any point in time. Contrast : single-valued. n-ary association : An association among three or more classes. Each instance of the association is an n-tuple of values from the respective classes. Contrast : binary association. name : A string used to identify a model element.

41

namespace : A part of the model in which the names may be dened and used. Within a namespace, each name has a unique meaning. See : name. node : A node is classier that represents a run-time computational resource, which generally has at least a memory and often processing capability. Run-time objects and components may reside on nodes. object : An entity with a well-dened boundary and identity that encapsulates state and behavior. State is represented by attributes and relationships, behavior is represented by operations, methods, and state machines. An object is an instance of a class. See : class, instance. object diagram : A diagram that encompasses objects and their relationships at a point in time. An object diagram may be considered a special case of a class diagram or a collaboration diagram. See : class diagram, collaboration diagram. object ow state : A state in an activity graph that represents the passing of an object from the output of actions in one state to the input of actions in another state. object lifeline : A line in a sequence diagram that represents the existence of an object over a period of time. See : sequence diagram. operation : A service that can be requested from an object to effect behavior. An operation has a signature, which may restrict the actual parameters that are possible. package : A general purpose mechanism for organizing elements into groups. Packages may be nested within other packages. parameter : The specication of a variable that can be changed, passed, or returned. A parameter may include a name, type, and direction. Parameters are used for operations, messages, and events. Synonyms : formal parameter. Contrast : argument. parameterized element : The descriptor for a class with one or more unbound parameters. Synonym : template. parent : In a generalization relationship, the generalization of another element, the child. See : subclass, subtype. Contrast : child. participate : The connection of a model element to a relationship or to a reied relationship. For example, a class participates in an association, an actor participates in a use case. partition : 1. activity graphs : A portion of an activity graphs that organizes the responsibilities for actions. See : swimlane. 2. architecture : A set of related classiers or packages at the same level of abstraction or across layers in a layered architecture. A partition represents a vertical slice through an architecture, whereas a layer represents a horizontal slice. Contrast : layer. 42

pattern : A template collaboration. persistent object : An object that exists after the process or thread that created it has ceased to exist. postcondition : A constraint that must be true at the completion of an operation. precondition : A constraint that must be true when an operation is invoked. primitive type : A pre-dened basic datatype without any substructure, such as an integer or a string. process : 1. A heavyweight unit of concurrency and execution in an operating system. Contrast : thread, which includes heavyweight and lightweight processes. If necessary, an implementation distinction can be made using stereotypes.2. A software development process the steps and guidelines by which to develop a system. 3. To execute an algorithm or otherwise handle something dynamically. projection : A mapping from a set to a subset of it. property : A named value denoting a characteristic of an element. A property has semantic impact. Certain properties are predened in the UML ; others may be user dened. See : tagged value. pseudo-state : A vertex in a state machine that has the form of a state, but does not behave as a state. Pseudo-states include initial and history vertices. physical system : 1. The subject of a model. 2. A collection of connected physical units, which can include software, hardware and people, that are organized to accomplish a specic purpose. A physical system can be described by one or more models, possibly from different viewpoints. Contrast : system. published model [MOF ] : A model which has been frozen, and becomes available for instantiating repositories and for the support in dening other models. A frozen models model elements cannot be changed. qualier : An association attribute or tuple of attributes whose values partition the set of objects related to an object across an association. receive [a message ] : The handling of a stimulus passed from a sender instance. See : sender, receiver. receiver [object ] : The object handling a stimulus passed from a sender object. Contrast : sender. reception : A declaration that a classier is prepared to react to the receipt of a signal. reference : 1. A denotation of a model element. 2. A named slot within a classier that facilitates navigation to other classiers. Synonym : pointer.

43

renement : A relationship that represents a fuller specication of something that has already been specied at a certain level of detail. For example, a design class is a renement of an analysis class. run time : The period of time during which a computer program executes. Contrast : modeling time. relationship : A semantic connection among model elements. Examples of relationships include associations and generalizations. repository : A facility for storing object models, interfaces, and implementations. requirement : A desired feature, property, or behavior of a system. responsibility : A contract or obligation of a classier. reuse : The use of a pre-existing artifact. role : The named specic behavior of an entity participating in a particular context. A role may be static (e.g., an association end) or dynamic (e.g., a collaboration role). scenario : A specic sequence of actions that illustrates behaviors. A scenario may be used to illustrate an interaction or the execution of a use case instance. See : interaction. schema [MOF ] : In the context of the MOF, a schema is analogous to a package which is a container of model elements. Schema corresponds to an MOF package. Contrast : metamodel, package. semantic variation point : A point of variation in the semantics of a metamodel. It provides an intentional degree of freedom for the interpretation of the metamodel semantics. send [a message ] : The passing of a stimulus from a sender instance to a receiver instance. See : sender, receiver. sender [object ] : The object passing a stimulus to a receiver object. Contrast : receiver. sequence diagram : A diagram that shows object interactions arranged in time sequence. In particular, it shows the objects participating in the interaction and the sequence of messages exchanged. Unlike a collaboration diagram, a sequence diagram includes time sequences but does not include object relationships. A sequence diagram can exist in a generic form (describes all possible scenarios) and in an instance form (describes one actual scenario). Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. See : collaboration diagram. 44

signal : The specication of an asynchronous stimulus communicated between instances. Signals may have parameters. signature : The name and parameters of a behavioral feature. A signature may include an optional returned parameter. single inheritance : A semantic variation of generalization in which a type may have only one supertype. Contrast : multiple inheritance. single valued [MOF ] : A model element with multiplicity dened is single valued when its Multiplicity Type : : upper attribute is set to one. The term single-valued does not pertain to the number of values held by an attribute, parameter, etc., at any point in time, since a single-valued attribute (for instance, with a multiplicity lower bound of zero) may have no value. Contrast : multi-valued. specication : A declarative description of what something is or does. Contrast : implementation. state : A condition or situation during the life of an object during which it satises some condition, performs some activity, or waits for some event. Contrast : state [OMA]. statechart diagram : A diagram that shows a state machine. See : state machine. state machine : A behavior that species the sequences of states that an object or an interaction goes through during its life in response to events, together with its responses and actions. static classication : A semantic variation of generalization in which an object may not change classier. Contrast : dynamic classication. stereotype : A new type of modeling element that extends the semantics of the metamodel. Stereotypes must be based on certain existing types or classes in the metamodel. Stereotypes may extend the semantics, but not the structure of preexisting types and classes. Certain stereotypes are predened in the UML, others may be user dened. Stereotypes are one of three extensibility mechanisms in UML. See : constraint, tagged value. stimulus : The passing of information from one instance to another, such as raising a signal or invoking an operation. The receipt of a signal is normally considered an event. See : message. string : A sequence of text characters. The details of string representation depend on implementation, and may include character sets that support international characters and graphics. structural feature : A static feature of a model element, such as an attribute.

45

structural model aspect : A model aspect that emphasizes the structure of the objects in a system, including their types, classes, relationships, attributes, and operations. subactivity state : A state in an activity graph that represents the execution of a nonatomic sequence of steps that has some duration. subclass : In a generalization relationship, the specialization of another class ; the superclass. See : generalization. Contrast : superclass. submachine state : A state in a state machine which is equivalent to a composite state but its contents is described by another state machine. substate : A state that is part of a composite state. See : concurrent state, disjoint state. subpackage : A package that is contained in another package. subsystem : A grouping of model elements that represents a behavioural unit in a physical system. A subsystem offers interfaces and has operations. In addition, the model elements of a subsystem can be partitioned into specication and realization elements. See package. See : physical system. subtype : In a generalization relationship, the specialization of another type ; the supertype. See : generalization. Contrast : supertype. superclass : In a generalization relationship, the generalization of another class ; the subclass. See : generalization. Contrast : subclass. supertype : In a generalization relationship, the generalization of another type ; the subtype. See : generalization. Contrast : subtype. supplier : A classier that provides services that can be invoked by others. Contrast : client. swimlane : A partition on a activity diagram for organizing the responsibilities for actions. Swimlanes typically correspond to organizational units in a business model. See : partition. synch state : A vertex in a state machine used for synchronizing the concurrent regions of a state machine. system : A top-level subsystem in a model. Contrast : physical system. tagged value : The explicit denition of a property as a name-value pair. In a tagged value, the name is referred as the tag. Certain tags are predened in the UML ; others may be user dened. Tagged values are one of three extensibility mechanisms in UML. See : constraint, stereotype. template : Synonym : parameterized element.

46

thread [of control ] : A single path of execution through a program, a dynamic model, or some other representation of control ow. Also, a stereotype for the implementation of an active object as lightweight process. See process. time event : An event that denotes the time elapsed since the current state was entered. See : event. time expression : An expression that resolves to an absolute or relative value of time. timing mark : A denotation for the time at which an event or message occurs. Timing marks may be used in constraints. top level : A stereotype of package denoting the top-most package in a containment hierarchy. The topLevel stereotype denes the outer limit for looking up names, as namespaces see outwards. For example, opLevel subsystem represents the top of the subsystem containment hierarchy. trace : A dependency that indicates a historical or process relationship between two elements that represent the same concept without specic rules for deriving one from the other. transient object : An object that exists only during the execution of the process or thread that created it. transition : A relationship between two states indicating that an object in the rst state will perform certain specied actions and enter the second state when a specied event occurs and specied conditions are satised. On such a change of state, the transition is said to re. type : A stereotype of class that is used to specify a domain of instances (objects) together with the operations applicable to the objects. A type may not contain any methods. See : class, instance. Contrast : interface. type expression : An expression that evaluates to a reference to one or more types. uninterpreted : A placeholder for a type or types whose implementation is not specied by the UML. Every uninterpreted value has a corresponding string representation. See : any [CORBA]. usage : A dependency in which one element (the client) requires the presence of another element (the supplier) for its correct functioning or implementation. use case [class ] : The specication of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. See : use case instances. use case diagram : A diagram that shows the relationships among actors and use cases within a system. 47

use case instance : The performance of a sequence of actions being specied in a use case. An instance of a use case. See : use case class. use case model : A model that describes the functional requirements of a system in terms of use cases. utility : A stereotype that groups global variables and procedures in the form of a class declaration. The utility attributes and operations become global variables and global procedures, respectively. A utility is not a fundamental modelling construct, but a programming convenience. value : An element of a type domain. vertex : A source or a target for a transition in a state machine. A vertex can be either a state or a pseudo-state. See : state, pseudo-state. view : A projection of a model, which is seen from a given perspective or vantage point and omits entities that are not relevant to this perspective. view element : A view element is a textual and/or graphical projection of a collection of model elements. view projection : A projection of model elements onto view elements. A view projection provides a location and a style for each view element. visibility : An enumeration whose value (public, protected, or private) denotes how the model element to which it refers may be seen outside its enclosing namespace.

8 NETographie (dernire mise jour : 2001-2002)

8.1 Programmation objets et UML
url1 - http ://www.csioo.com/cetusfr/software.html : carrefour Cetus : Orient Objets ; excellent, plus de 8000 liens. url2 - http ://www.cyber-espace.com/ronald/ : espace objet francophone. url3 - http ://www.rational.com/UML/resources.html : site de R A TIONAL (principal acteur de UML) url4 - http ://www.omg.org : Object Management Group url5 - http ://www.lurpa.ens-cachan.fr/grafcet/grafcet_fr.html : Tout sur le Grafcet url6 - http ://www.ensta.fr/ osigaud/in204/index.html : Le site web du cours

48

8.2 Les patterns (ou patrons)

http ://www.csioo.com/cetusfr/oo_patterns.html : liste de rfrences concernant les patterns (ou patrons) http ://st-www.cs.uiuc.edu/users/patterns/patterns.html : page dentre principale pour les patterns

Rfrences
[Boo94] G. Booch. Object-Oriented Software Analysis and Design with Applications. Benjamin Cummings, 1994.

[GHJV96] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns : catalogue de modles de conception rutilisables. ITP, France, 1996. [Har87] D. Harel. Statecharts : A visual formalism for complex systems. Science of Computer Programming, 8, 1987.

[JBR97a] I. Jacobson, G. Booch, and J. Rumbaugh. The Objectory Software Development Process. Addison Wesley, 1997. [JBR97b] I. Jacobson, G. Booch, and J. Rumbaugh. Unied Modeling Language Reference Manual. Addison Wesley, 1997. [JBR97c] I. Jacobson, G. Booch, and J. Rumbaugh. Unied Modeling Language User Guide. Addison Wesley, 1997. [JCJO92] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-Oriented Software Engineering : A Use case Driven Approach. Addison Wesley, 1992. [Lor97] [Mey97] [Rum96] [Sig04a] M. Lorenz. Object-Oriented Software Development. Prentice Hall, 1997. B. Meyer. Object-Oriented Software Construction. Prentice Hall, 1997. J. Rumbaugh. France, 1996. Modlisation et conception orientes objets. Masson,

O. Sigaud. Introduction la conduite de projet reposant sur un langage orient objets. support du cours Gnie logiciel et programmation oriente objets de lENSTA, 2004. O. Sigaud. Introduction la programmation oriente objets avec Java. support du cours Gnie logiciel et programmation oriente objets de lENSTA, 2004.

[Sig04b]

49