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

Embed Size (px)

Text of Introduction à la modélisation orientée objets avec ?· Introduction à la modélisation...

  • Introduction la modlisation oriente objets

    avec UML

    Olivier Sigaud

    Table des matires

    1 Vocation de ce document 2

    2 Prsentation gnrale dUML 32.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

    2.2 Unified : historique des mthodes de conception . . . . . . . . . . . . 42.3 Modeling : analyse et conception . . . . . . . . . . . . . . . . . . . . 5

    2.4 Language : mthodologie ou langage de modlisation ? . . . . . . . 62.5 Diffrentes vues et diagrammes dUML . . . . . . . . . . . . . . . . 7

    3 Le diagramme des cas (vue fonctionnelle) 83.1 Les cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

    3.2 Liens entre cas dutilisation : include et extend . . . . . . . . . . . . 9

    4 Le diagramme des classes (vue structurelle) 104.1 Introduction au diagramme des classes . . . . . . . . . . . . . . . . . 10

    4.2 Les diffrents niveaux de description . . . . . . . . . . . . . . . . . . 11

    4.3 Les diagrammes de packages . . . . . . . . . . . . . . . . . . . . . . 11

    4.4 Description dune classe . . . . . . . . . . . . . . . . . . . . . . . . 12

    4.4.1 Les attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    4.4.2 Les oprations . . . . . . . . . . . . . . . . . . . . . . . . . 13

    4.5 Les interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

    4.6 Les associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

    4.6.1 Les cardinalits (ou multiplicits) . . . . . . . . . . . . . . . 15

    4.6.2 Attributs et classes dassociation . . . . . . . . . . . . . . . . 16

    4.6.3 Qualificatifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

    4.6.4 Associations et attributs drivs . . . . . . . . . . . . . . . . 17

    4.6.5 Ajout de contraintes et de rgles . . . . . . . . . . . . . . . . 18

    1

  • 4.7 Sous-types et gnralisation . . . . . . . . . . . . . . . . . . . . . . 18

    4.7.1 Agrgation et composition . . . . . . . . . . . . . . . . . . . 19

    4.8 Classes paramtriques . . . . . . . . . . . . . . . . . . . . . . . . . . 20

    5 Les diagrammes de squences (vue fonctionnelle) 21

    6 Les diagrammes dtats (vue dynamique) 23

    6.1 Etats et Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

    6.2 Actions et activits . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

    6.2.1 Exemple : diagramme dtats dun rveil . . . . . . . . . . . 25

    6.2.2 vnements spciaux . . . . . . . . . . . . . . . . . . . . . . 26

    6.3 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

    6.4 Diagrammes hirarchiss . . . . . . . . . . . . . . . . . . . . . . . . 27

    6.4.1 Paralllisme et synchronisation . . . . . . . . . . . . . . . . . 28

    6.5 Le diagramme dactivit (vue dynamique) . . . . . . . . . . . . . . . 29

    6.6 Extension de UML : les strotypes . . . . . . . . . . . . . . . . . . 29

    6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

    7 Glossaire 31

    7.1 Extrait franais du glossaire . . . . . . . . . . . . . . . . . . . . . . . 31

    7.2 Glossaire complet en anglais . . . . . . . . . . . . . . . . . . . . . . 33

    8 NETographie (dernire mise jour : 2001-2002) 48

    8.1 Programmation objets et UML . . . . . . . . . . . . . . . . . . . . . 488.2 Les patterns (ou patrons) . . . . . . . . . . . . . . . . . . . . . . . . 49

    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 spcifier clairement le problme quil doit rsoudre. Sil nest pas in-

    formaticien, il aura sans doute dialoguer avec des quipes de conception pour sas-

    surer que ses spcifications sont bien comprises. Sil est responsable dune quipe de

    dveloppement, il aura assimiler les spcifications quil aura contribu tablir, puis

    il devra en mener lanalyse et la conception avant de confier le codage proprement dit

    des dveloppeurs, puis dialoguer avec les clients pour sassurer de leur satisfaction.

    2

  • Dans tous les cas, lingnieur aura besoin dun langage ou dune mthode de spci-

    fication et de modlisation pour communiquer avec ses collaborateurs, clients et four-

    nisseurs. Cest dans ce cadre que nous prsentons quelques lments du langage UML

    (Unified Modeling Language), qui sest impos comme un standard que rencontrent

    tous les ingnieurs dans lindustrie informatique qui utilisent des langages orients ob-

    jets.

    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 plusutiles et les principales difficults 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 informa-

    tion 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 d-

    veloppeurs 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 proposeun langage qui soit commun tous les experts du logiciel, va dans le sens de cet assou-

    plissement des contraintes mthodologiques.

    UML signifie Unified Modeling Language. La justification de chacun de ces mots

    3

  • nous servira de fil conducteur pour cette prsentation.

    2.2 Unified : historique des mthodes de conception

    Booch93

    Booch

    OMT2

    OMT

    OOSE

    Rvision 9/97

    Soumission lOMG 1/97

    Bta version OOPSLA96

    OOPSLA95

    UML 1.1

    UML 0.9

    Unified Method 0.8

    OCL(IBM)UML 1.0

    ...

    temps

    fin 2004 UML 2.0

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

    lement 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 for-

    mel) de reprsentation des rsultats. Celui-ci peut tre graphique (diagramme synop-

    tique, 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 BOOCH [Boo94],

    4

  • 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 RATIONAL [url3] dans le but de travailler llaboration dune mthode com-

    mune qui intgre les avantages de lensemble des mthodes reconnues, en corrigeant

    les dfauts et en comblant les dficits. Lors de OOPSLA95 (Object Oriented Program-

    ming Systems, Languages and Applications, la grande confrence de la programmation

    oriente objets), ils prsentent UNIFIED METHOD V0.8. En 1996, Ivar Jacobson les re-

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

    gage de contraintes OCL , ...) ou des socits