Introduction à la modélisation orientée objets avec ?· Introduction à la modélisation orientée…

  • Published on
    12-Sep-2018

  • View
    212

  • Download
    0

Embed Size (px)

Transcript

<ul><li><p>Introduction la modlisation oriente objets</p><p>avec UML</p><p>Olivier Sigaud</p><p>Table des matires</p><p>1 Vocation de ce document 2</p><p>2 Prsentation gnrale dUML 32.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3</p><p>2.2 Unified : historique des mthodes de conception . . . . . . . . . . . . 42.3 Modeling : analyse et conception . . . . . . . . . . . . . . . . . . . . 5</p><p>2.4 Language : mthodologie ou langage de modlisation ? . . . . . . . 62.5 Diffrentes vues et diagrammes dUML . . . . . . . . . . . . . . . . 7</p><p>3 Le diagramme des cas (vue fonctionnelle) 83.1 Les cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8</p><p>3.2 Liens entre cas dutilisation : include et extend . . . . . . . . . . . . 9</p><p>4 Le diagramme des classes (vue structurelle) 104.1 Introduction au diagramme des classes . . . . . . . . . . . . . . . . . 10</p><p>4.2 Les diffrents niveaux de description . . . . . . . . . . . . . . . . . . 11</p><p>4.3 Les diagrammes de packages . . . . . . . . . . . . . . . . . . . . . . 11</p><p>4.4 Description dune classe . . . . . . . . . . . . . . . . . . . . . . . . 12</p><p>4.4.1 Les attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . 12</p><p>4.4.2 Les oprations . . . . . . . . . . . . . . . . . . . . . . . . . 13</p><p>4.5 Les interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14</p><p>4.6 Les associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15</p><p>4.6.1 Les cardinalits (ou multiplicits) . . . . . . . . . . . . . . . 15</p><p>4.6.2 Attributs et classes dassociation . . . . . . . . . . . . . . . . 16</p><p>4.6.3 Qualificatifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17</p><p>4.6.4 Associations et attributs drivs . . . . . . . . . . . . . . . . 17</p><p>4.6.5 Ajout de contraintes et de rgles . . . . . . . . . . . . . . . . 18</p><p>1</p></li><li><p>4.7 Sous-types et gnralisation . . . . . . . . . . . . . . . . . . . . . . 18</p><p>4.7.1 Agrgation et composition . . . . . . . . . . . . . . . . . . . 19</p><p>4.8 Classes paramtriques . . . . . . . . . . . . . . . . . . . . . . . . . . 20</p><p>5 Les diagrammes de squences (vue fonctionnelle) 21</p><p>6 Les diagrammes dtats (vue dynamique) 23</p><p>6.1 Etats et Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 24</p><p>6.2 Actions et activits . . . . . . . . . . . . . . . . . . . . . . . . . . . 24</p><p>6.2.1 Exemple : diagramme dtats dun rveil . . . . . . . . . . . 25</p><p>6.2.2 vnements spciaux . . . . . . . . . . . . . . . . . . . . . . 26</p><p>6.3 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26</p><p>6.4 Diagrammes hirarchiss . . . . . . . . . . . . . . . . . . . . . . . . 27</p><p>6.4.1 Paralllisme et synchronisation . . . . . . . . . . . . . . . . . 28</p><p>6.5 Le diagramme dactivit (vue dynamique) . . . . . . . . . . . . . . . 29</p><p>6.6 Extension de UML : les strotypes . . . . . . . . . . . . . . . . . . 29</p><p>6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30</p><p>7 Glossaire 31</p><p>7.1 Extrait franais du glossaire . . . . . . . . . . . . . . . . . . . . . . . 31</p><p>7.2 Glossaire complet en anglais . . . . . . . . . . . . . . . . . . . . . . 33</p><p>8 NETographie (dernire mise jour : 2001-2002) 48</p><p>8.1 Programmation objets et UML . . . . . . . . . . . . . . . . . . . . . 488.2 Les patterns (ou patrons) . . . . . . . . . . . . . . . . . . . . . . . . 49</p><p>1 Vocation de ce document</p><p>Ce document sadresse de futurs ingnieurs qui seront confronts dans leur vie</p><p>professionnelle au dveloppement dapplications informatiques industrielles, en tant</p><p>que concepteurs aussi bien que clients.</p><p>De par sa fonction, lingnieur, quil soit spcialiste dinformatique ou non, doit</p><p>tre capable de spcifier clairement le problme quil doit rsoudre. Sil nest pas in-</p><p>formaticien, il aura sans doute dialoguer avec des quipes de conception pour sas-</p><p>surer que ses spcifications sont bien comprises. Sil est responsable dune quipe de</p><p>dveloppement, il aura assimiler les spcifications quil aura contribu tablir, puis</p><p>il devra en mener lanalyse et la conception avant de confier le codage proprement dit</p><p> des dveloppeurs, puis dialoguer avec les clients pour sassurer de leur satisfaction.</p><p>2</p></li><li><p>Dans tous les cas, lingnieur aura besoin dun langage ou dune mthode de spci-</p><p>fication et de modlisation pour communiquer avec ses collaborateurs, clients et four-</p><p>nisseurs. Cest dans ce cadre que nous prsentons quelques lments du langage UML</p><p>(Unified Modeling Language), qui sest impos comme un standard que rencontrent</p><p>tous les ingnieurs dans lindustrie informatique qui utilisent des langages orients ob-</p><p>jets.</p><p>Nous considrons dans ce document que le lecteur a dj t form aux principales</p><p>notions de la programmation oriente objets. Nous renvoyons un polycopi sur le</p><p>langage JAVA si ce nest pas le cas ([Sig04b]). Par ailleurs, les aspects de mise en</p><p>uvre dune dmarche reposant sur UML font lobjet dun polycopi complmentaire</p><p>([Sig04a]). Nous nous contentons ici dexposer les lments du langage standard de</p><p>modlisation oriente objets UML, en dcrivant sommairement les diffrentes vues des</p><p>applications quil permet de modliser.</p><p>Cette prsentation est conue comme un support pragmatique pour faciliter la tche</p><p>du lecteur lors de sa premire utilisation dUML, en lui prsentant les aspects les plusutiles et les principales difficults auxquelles il risque dtre confront, plutt que</p><p>comme un manuel de rfrence ou un catalogue exhaustif. Nous invitons le lecteur</p><p> consulter les ouvrages de rfrence ([JBR97a, JBR97b, JBR97c]) pour une informa-</p><p>tion approfondie ds lors que ce premier tour dhorizon lui aura permis de sorienter.</p><p>2 Prsentation gnrale dUML</p><p>2.1 Introduction</p><p>Le gnie logiciel et la mthodologie sefforcent de couvrir tous les aspects de la vie</p><p>du logiciel. Issus de lexprience des dveloppeurs, concepteurs et chefs de projets, ils</p><p>sont en constante volution, paralllement lvolution des techniques informatiques</p><p>et du savoir-faire des quipes.</p><p>Comme toutes les tentatives de mise plat dune exprience et dun savoir-faire,</p><p>les mthodologies ont parfois souffert dune formalisation excessive, imposant aux d-</p><p>veloppeurs des contraintes parfois contre-productives sur leur faon de travailler.</p><p>Avec la mise en commun de lexprience et la maturation des savoir-faire, on voit</p><p>se dvelopper prsent des mthodes de travail la fois plus proches de la pratique</p><p>relle des experts et moins contraignantes.</p><p>UML, qui se veut un instrument de capitalisation des savoir-faire puisquil proposeun langage qui soit commun tous les experts du logiciel, va dans le sens de cet assou-</p><p>plissement des contraintes mthodologiques.</p><p>UML signifie Unified Modeling Language. La justification de chacun de ces mots</p><p>3</p></li><li><p>nous servira de fil conducteur pour cette prsentation.</p><p>2.2 Unified : historique des mthodes de conception</p><p>Booch93</p><p>Booch</p><p>OMT2</p><p>OMT</p><p>OOSE</p><p>Rvision 9/97</p><p>Soumission lOMG 1/97</p><p>Bta version OOPSLA96</p><p>OOPSLA95</p><p>UML 1.1</p><p>UML 0.9</p><p>Unified Method 0.8</p><p>OCL(IBM)UML 1.0</p><p>...</p><p>temps</p><p>fin 2004 UML 2.0</p><p>FIG. 1 Historique de la constitution dUML</p><p> chacune des diffrentes phases de la conception dun logiciel correspondent des</p><p>problmes ou des contraintes diffrentes. Naturellement, ces niveaux ont fait lobjet</p><p>de recherches mthodologiques considrables depuis les annes 80. Il en rsulte que</p><p>de nombreuses mthodes de dveloppement ou danalyse de logiciel ont vu le jour,</p><p>chacune plus ou moins spcialise ou adapte une dmarche particulire, voire un</p><p>secteur industriel particulier (bases de donnes, matriel embarqu, ...) [url1]. Celles-ci</p><p>ayant t dveloppes indpendamment les unes des autres, elles sont souvent partiel-</p><p>lement redondantes ou incompatibles entre elles lorsquelles font appel des notations</p><p>ou des terminologies diffrentes, voire des faux amis.</p><p>De plus, chaque mthode correspond un ou plusieurs moyens (plus ou moins for-</p><p>mel) de reprsentation des rsultats. Celui-ci peut tre graphique (diagramme synop-</p><p>tique, plan physique dun rseau, organigramme) ou textuel (expression dun besoin</p><p>en langage naturel, jusquau listing du code source). Dans les annes 90, un certain</p><p>nombre de mthodes orientes objets ont merg, en particulier les mthodes :</p><p> OMT de James RUMBAUGH [Rum96],</p><p> BOOCH de Grady BOOCH [Boo94],</p><p>4</p></li><li><p> OOSE (Object Oriented Software Engineering) de Ivar JACOBSON qui lon</p><p>doit les Use cases [JCJO92] 1.En 1994, on recensait plus de 50 mthodologies orientes objets. Cest dans le but de</p><p>remdier cette dispersion que les poids-lourds de la mthodologie oriente objets</p><p>ont entrepris de se regrouper autour dun standard.</p><p>En octobre 1994, Grady Booch et James Rumbaugh se sont runis au sein de la</p><p>socit RATIONAL [url3] dans le but de travailler llaboration dune mthode com-</p><p>mune qui intgre les avantages de lensemble des mthodes reconnues, en corrigeant</p><p>les dfauts et en comblant les dficits. Lors de OOPSLA95 (Object Oriented Program-</p><p>ming Systems, Languages and Applications, la grande confrence de la programmation</p><p>oriente objets), ils prsentent UNIFIED METHOD V0.8. En 1996, Ivar Jacobson les re-</p><p>joint. Leurs travaux ne visent plus constituer une mthodologie, mais un langage 2.</p><p>Leur initiative a t soutenue par de nombreuses socits, que ce soit des socits de</p><p>dveloppement (dont Microsoft, Oracle, Hewlet-Packard, IBM qui a apport son lan-</p><p>gage de contraintes OCL , ...) ou des socits de conception dateliers logiciels. Un</p><p>projet a t dpos en janvier 1997 lOMG 3 en vue de la normalisation dun langage</p><p>de modlisation. Aprs amendement, celui-ci a t accept en novembre 97 par lOMG</p><p>sous la rfrence UML-1.1. La version UML-2.0 est annonce pour la fin 2004.</p><p>2.3 Modeling : analyse et conception</p><p>Une bonne mthodologie de ralisation de logiciels suppose une bonne matrise de</p><p>la distinction entre lanalyse et la conception, distinction que nous exposons dans le</p><p>polycopi complmentaire ([Sig04a]). Le lecteur verra quen pratique, le respect dune</p><p>distinction entre des phases danalyse et de conception rigoureusement indpendantes</p><p>nest pas tenable, mais il est important davoir en tte la diffrence lorsquon sapprte</p><p> raliser un logiciel. Encore une fois, il est important de garder lesprit quUMLnoffre pas une mthodologie pour lanalyse et la conception, mais un langage qui</p><p>permet dexprimer le rsultat de ces phases.</p><p>Du point de vue des notations employes en UML, les diffrences entre lanalyse</p><p>et la conception se traduisent avant tout par des diffrences de niveau de dtail dans les</p><p>diagrammes utiliss. On peut ainsi noter les diffrences suivantes :</p><p> Dans un diagramme de classes danalyse, les seules classes qui apparaissent</p><p>servent dcrire des objets concrets du domaine modlis. Dans un diagramme</p><p>de classes de conception, par opposition, on trouve aussi toutes les classes utili-</p><p>taires destines assurer le fonctionnement du logiciel.</p><p>1cas dutilisations, cf. la section 3 la page 82voir la section 2.4 la page 63Object Management Group, qui sest rendu clbre pour la norme CORBA [url4]</p><p>5</p></li><li><p> Dans un diagramme de classes danalyse, on peut se contenter de faire appa-</p><p>ratre juste la dnomination des classes, avec parfois le nom de quelques attri-</p><p>buts et mthodes quand ceux-ci dcoulent naturellement du domaine modlis.</p><p>Dans un diagramme de classes de conception, par opposition, tous les attributs</p><p>et toutes les mthodes doivent apparatre de faon dtaille, avec tous les types</p><p>de paramtres et les types de retour.</p><p> Dans un diagramme de squence danalyse, les communications entre les prin-</p><p>cipaux objets sont crits sous forme textuelle, sans se soucier de la forme que</p><p>prendront ces changes lors de la ralisation du logiciel. Dans un diagramme de</p><p>squence de conception, par opposition, les changes entre classes figurent sous</p><p>la forme dappels de mthodes dont les signatures sont totalement explicites.</p><p>Les tapes permettant de passer de diagrammes danalyse des diagrammes de concep-</p><p>tion et les motivations de la formalisation progressive que cela entrane sont traits dans</p><p>le polycopi complmentaire ([Sig04a]).</p><p>2.4 Language : mthodologie ou langage de modlisation ?</p><p>Il est important de bien faire la distinction entre une mthode qui est une dmarchedorganisation et de conception en vue de rsoudre un problme informatique, et le</p><p>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</p><p>ralisation de projets informatiques. Celles-ci sont lies des raisons historiques, dor-</p><p>ganisation administrative interne ou encore dautres contraintes denvironnement (d-</p><p>fense nationale, ...) et il nest pas facile den changer. Il ntait donc pas raliste de</p><p>tenter de standardiser une mthodologie de conception au niveau mondial.</p><p>UML nest pas une mthode, mais un langage. Il peut donc tre utilis sans remettre</p><p>en cause les procds habituels de conception de lentreprise et, en particulier, les m-</p><p>thodes plus anciennes telles que celle propose par OMT sont tout fait utilisables.</p><p>Dailleurs, la socit RATIONAL (principale actrice de UML) propose son propre pro-cessus de conception appel OBJECTORY [JBR97a] et entirement bas sur UML.</p><p>Ainsi, UML facilite la communication entre clients et concepteurs, ainsi quentrequipes de concepteurs. De plus, sa smantique tant formellement dfinie 4 dans</p><p>[JBR97b] (sous forme de diagramme UML), cela acclre le dveloppement des ou-</p><p>tils graphiques datelier de gnie logiciel permettant ainsi daller de la spcification</p><p>(haut niveau) en UML vers la gnration de code (JAVA, C++, ADA, ...). De plus, cela</p><p>autorise lchange lectronique de documents qui deviennent des spcifications excu-</p><p>4Les contraintes elles-mmes font lobjet dune dfinition formelle grce au langage OCL (Object</p><p>Constraint Language, voir la section 4.6.5 la page 18).</p><p>6</p></li><li><p>tables en UML.</p><p>UML ne se contente pas dhomogniser des formalismes existants, mais apportegalement un certain nombre de nouveauts telles que la modlisation darchitectures</p><p>distribues ou la modlisation dapplications temps-rel avec gestion du multi-tches,</p><p>dont lexpos dpasse le cadre de ce document.</p><p>2.5 Diffrentes vues et diagrammes dUML</p><p>Toutes les vues proposes par UML sont complmentaires les unes des autres, elles</p><p>permettent de mettre en vidence diffrents aspects dun logiciel raliser. On peut or-</p><p>ganiser une prsentation dUML autour dun dcoupage en vues, ou bien en diffrents</p><p>diagrammes, selon quon spare plutt les aspects fonctionnels des aspects architec-</p><p>turaux, ou les aspects statiques des aspects dynamiques. Nous adopterons plutt dans</p><p>la suite un dcoupage en diagrammes, mais nous commenons par prsenter les diff-</p><p>rentes vues, qui sont les suivantes :</p><p>1 - la vue fonctionnelle, interactive, qui est reprsente laide de diagrammes decas et de diagrammes des squences, fera lobjet des sections 3 la page 8</p><p>et 5 la page 21. Elle cherche apprhender les interactions entre les diffrents</p><p>acteurs/utilisateurs et le systme, sous forme dobjectif atteindre dun ct et</p><p>sous forme chronologique de scnarios dinteraction typiques de lautre.</p><p>2 - la vue structurelle, ou statique, prsente dans la section 4 la page 10, runit lesdiagrammes de classes et les diagrammes de packages. Les premiers fa-</p><p>vorisent la structuration des donnes et tentent didentifier les objets/composants</p><p>constituant le programme, leurs attributs...</p></li></ul>