Cour Complet Uml

Click here to load reader

  • date post

    23-Jun-2015
  • Category

    Documents

  • view

    364
  • download

    1

Embed Size (px)

Transcript of Cour Complet Uml

Introduction la modlisation oriente objets avec UMLOlivier Sigaud Edition 2005-2006

Table des matires1 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

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

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

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

1

4.7 4.8

4.6.4 Associations et attributs drivs 4.6.5 Ajout de contraintes et de rgles Sous-types et gnralisation . . . . . . 4.7.1 Agrgation et composition . . . Classes paramtriques . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

17 18 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 documentCe 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

2

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 ([Sig05b]). Par ailleurs, les aspects de mise en uvre dune dmarche reposant sur UML font lobjet dun polycopi complmentaire ([Sig05a]). 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 dUML2.1 IntroductionLe 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 assou-

3

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

fin 2004

UML 2.0

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

UML 1.1

UML 1.0UML 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], 4

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 conceptionUne bonne mt