Cours Cours Uml

ECOLE NATIONALE DES INGENIEURS DES TRAVAUX AGRICOLES DE BORDEAUX DEPARTEMENT ENTREPRISE ET SYSTEME UNITE DE FORMATION INFORMATIQUE ET GENIE
DES EQUIPEMENTS
COURS UML
Ce cours a t crit en grande partie partir du site http://uml.free.fr (Merci son auteur : Laurent Piechocki) ainsi que du cours de Frdric Di Gallo (CNAM angoulme).
COURS UML13.doc Mars 2005
J.STEFFE ENITA de Bordeaux
SOMMAIRE
SOMMAIRE ____________________________________________________________ 2 TABLE DES MATIERES __________________________________________________ 4 INTRODUCTION ________________________________________________________ 1
UML est une norme __________________________________________________________ 3 UML est un langage de modlisation objet._______________________________________ 3 UML est un support de communication _________________________________________ 4 UML est un cadre mthodologique pour une analyse objet__________________________ 5
I). Le contexte dapparition dUML __________________________________________ 8

I.1) Approche fonctionnelle versus approche objet ________________________________ 8
I.1.1) Lapproche fonctionnelle _______________________________________________________ 8 I.1.2) Lapproche objet ____________________________________________________________ 10
I.2) La gense dUML _______________________________________________________ 14

I.2.1) Historique des mthodes danalyse ______________________________________________ I.2.2) Cadre dutilisation dUML _____________________________________________________ I.2.3) Points forts dUML __________________________________________________________ I.2.4) Points faibles dUML _________________________________________________________ 14 15 16 17
II) Dmarche gnrale de modlisation avec UML _____________________________ 18

II.1) Qu'est-ce qu'un modle ? ________________________________________________ 18
II.1.1) Dfinition dun modle _______________________________________________________ 18 II.1.2) Caractristiques fondamentales des modles ______________________________________ 18
II.2 ) Comment modliser avec UML ? _________________________________________ 18

II.2.1) Proposition de dmarche______________________________________________________ 18 II.2.2) La vue 4+1 de ph. Kruchten ________________________________________________ 20 II.2.3) Les niveaux dabstraction _____________________________________________________ 21
II.4 ) Lutilisation de diagrammes _____________________________________________ 23

II.4.1) Dfinition dun diagramme ____________________________________________________ 23 II.4.2) caractristiques des diagrammes UML ___________________________________________ 23 II.4.3) Les diffrents types de diagrammes UML ________________________________________ 23
III) Les Diffrents types de diagrammes _____________________________________ 24

III.1) Vues statiques du systme _______________________________________________ 24
III.1.1) diagrammes de cas d'utilisation ________________________________________________ III.1.2) diagrammes de classes_______________________________________________________ III.1.3) diagrammes d'objets ________________________________________________________ III.1.4) diagrammes de composants ___________________________________________________ III.1.5) diagrammes de dploiement __________________________________________________ III.2.1) diagrammes de collaboration __________________________________________________ III.2.2) diagrammes de squence _____________________________________________________ III.2.3) diagrammes d'tats-transitions_________________________________________________ III.2.4) diagrammes d'activits_______________________________________________________ 24 30 43 44 44 45 47 54 56
III.2) Vues dynamiques du systme : ___________________________________________ 45
IV) Le processus unifi ___________________________________________________ 58

IV.1) Le processus unifi est pilot par les cas dutilisation_________________________ 58
IV.1.1) Prsentation gnrale________________________________________________________ 58 IV.1.2) Stratgie des cas dutilisation _________________________________________________ 58
IV.2) Le processus unifi est centr sur larchitecture _____________________________ 60

IV.2.1) Liens entre cas dutilisation et architecture _______________________________________ 60 IV.2.2) Marche suivre ____________________________________________________________ 60
IV.3) Le processus unifi est itratif et incrmental _______________________________ 61 IV.4) Le cycle de vie du processus unifi ________________________________________ 62 IV.5) Conclusion : un processus intgr ________________________________________ 64
V) Elments de comparaisons entre MERISE et UML __________________________ 65

V.1) Les principes __________________________________________________________ 65
V.1.1) Lapproche systmique _______________________________________________________ V.1.2) Les cycles de construction du systme dinformation _______________________________ V.1.3) Lapproche fonctionnelle _____________________________________________________ V.1.4) La sparation donnes-traitements ______________________________________________ V.1.5) L approche qui part du gnral vers le particulier __________________________________ V.2.1) Le domaine ________________________________________________________________ V.2.2) Lacteur___________________________________________________________________ V.2.3) Les flux ___________________________________________________________________ V.2.4) Les modles conceptuels et organisationnels ______________________________________ 65 65 66 67 67 67 67 68 68
V.2) La modlisation mtier __________________________________________________ 67
V.3) La dmarche___________________________________________________________ 71
V.3.1) Les modles utiliss _________________________________________________________ 71 V.3.2) les tapes du processus dlaboration du systme dinformation _______________________ 72
V.4) Conclusion ____________________________________________________________ 72
CONCLUSION GENERALE ______________________________________________ 73
TABLE DES MATIERES
INTRODUCTION ________________________________________________________ 1
UML est une norme __________________________________________________________ 3 UML est un langage de modlisation objet._______________________________________ 3 UML est un support de communication _________________________________________ 4 UML est un cadre mthodologique pour une analyse objet__________________________ 5
UML n'est pas une mthode _______________________________________________________ 6 Conclusion ____________________________________________________________________ 6
I). Le contexte dapparition dUML __________________________________________ 8

I.1) Approche fonctionnelle versus approche objet ________________________________ 8
I.1.1) Lapproche fonctionnelle _______________________________________________________ 8 La dcoupe fonctionnelle d'un problme informatique : une approche intuitive _______________ 8 La rutilisabilit du code__________________________________________________________ 8 Le revers de la mdaille : maintenance complexe en cas d'volution ________________________ 8 Problmes gnrs par la sparation des donnes et des traitements : _______________________ 8 1re amlioration : rassembler les valeurs qui caractrisent un type, dans le type _______________ 9 2me amlioration : centraliser les traitements associs un type, auprs du type______________ 9 I.1.2) Lapproche objet ____________________________________________________________ 10 Le concept dobjet______________________________________________________________ 10 Les autres concepts importants de l'approche objet. ____________________________________ 11 lencapsulation____________________________________________________________ 11 lhritage ________________________________________________________________ 11 le polymorphisme _________________________________________________________ 11 lagrgation ______________________________________________________________ 12 Historique de lapproche objet ____________________________________________________ 13 Inconvnients de lapproche objet__________________________________________________ 13 Solutions pour remdier aux inconvnients de lapproche objet___________________________ 13
I.2) La gense dUML _______________________________________________________ 14

I.2.1) Historique des mthodes danalyse ______________________________________________ Les premires mthodes d'analyse (annes 70) ________________________________________ L'approche systmique (annes 80)_________________________________________________ L'mergence des mthodes objet (1990-1995) ________________________________________ Les premiers consensus (1995) ____________________________________________________ L'unification et la normalisation des mthodes (1995-1997) _____________________________ I.2.2) Cadre dutilisation dUML _____________________________________________________ UML n'est pas une mthode ou un processus _________________________________________ UML est un langage de modlisation _______________________________________________ UML dcrit un mta modle ______________________________________________________ UML est un support de communication _____________________________________________ I.2.3) Points forts dUML __________________________________________________________ UML est un langage formel et normalis ____________________________________________ UML est un support de communication performant ____________________________________ I.2.4) Points faibles dUML _________________________________________________________ La mise en pratique d'UML ncessite un apprentissage et passe par une priode d'adaptation. ___ Le processus (non couvert par UML) est une autre cl de la russite d'un projet. _____________ 14 14 14 14 14 14 15 15 16 16 16 16 16 17 17 17 17
II) Dmarche gnrale de modlisation avec UML _____________________________ 18

II.1) Qu'est-ce qu'un modle ? ________________________________________________ 18
II.1.1) Dfinition dun modle _______________________________________________________ 18 II.1.2) Caractristiques fondamentales des modles ______________________________________ 18
II.2 ) Comment modliser avec UML ? _________________________________________ 18

II.2.1) Proposition de dmarche______________________________________________________ Une dmarche itrative et incrmentale _____________________________________________ Une dmarche pilote par les besoins des utilisateurs___________________________________ Une dmarche centre sur l'architecture _____________________________________________ II.2.2) La vue 4+1 de ph. Kruchten ________________________________________________ La vue logique_________________________________________________________________ La vue des composants __________________________________________________________ La vue des processus____________________________________________________________ La vue de dploiement __________________________________________________________ La vue des cas dutilisation _______________________________________________________ II.2.3) Les niveaux dabstraction _____________________________________________________ Une non-dmarcation entre conception et analyse _____________________________________ Les niveaux dabstraction ________________________________________________________ Conceptualisation _________________________________________________________ Analyse du domaine _______________________________________________________ Analyse applicative ________________________________________________________ Conception_______________________________________________________________ 18 19 19 19 20 20 20 21 21 21 21 21 22 22 22 22 22
II.4 ) Lutilisation de diagrammes _____________________________________________ 23

II.4.1) Dfinition dun diagramme ____________________________________________________ 23 II.4.2) caractristiques des diagrammes UML ___________________________________________ 23 II.4.3) Les diffrents types de diagrammes UML ________________________________________ 23
III) Les Diffrents types de diagrammes _____________________________________ 24

III.1) Vues statiques du systme _______________________________________________ 24
III.1.1) diagrammes de cas d'utilisation ________________________________________________ Dfinition du cas d'utilisation (use case)_____________________________________________ Elments de modlisation des cas d'utilisation ________________________________________ Lacteur : ________________________________________________________________ Le cas dutilisation_________________________________________________________ La relation _______________________________________________________________ La relation de gnralisation _________________________________________________ La relation dinclusion______________________________________________________ La relation dextension _____________________________________________________ Paquetage________________________________________________________________ Exemple de cas dutilisation _________________________________________________ Elaboration des cas d'utilisation ___________________________________________________ Utilisation des cas d'utilisation ____________________________________________________ III.1.2) diagrammes de classes_______________________________________________________ Dfinition du diagramme de classes ________________________________________________ Les notions utilises par le diagramme de classes______________________________________ La notion de classe ________________________________________________________ La notion dattribut ________________________________________________________ La notion didentifiant ______________________________________________________ La notion dopration ______________________________________________________ La notion de relation _______________________________________________________ Lassociation _____________________________________________________________ La gnralisation / spcialisation______________________________________________ La dpendance ____________________________________________________________ Linterface _______________________________________________________________ Les scnarios _____________________________________________________________ Elaboration dun diagramme de classes _____________________________________________ Gnralits _______________________________________________________________ Rgles dlaboration _______________________________________________________ III.1.3) diagrammes d'objets ________________________________________________________ III.1.4) diagrammes de composants ___________________________________________________ III.1.5) diagrammes de dploiement __________________________________________________ 24 24 24 24 25 26 26 27 28 28 29 30 30 30 30 31 31 32 32 33 33 34 37 40 42 29 43 43 43 43 44 44
III.2) Vues dynamiques du systme : ___________________________________________ 45

III.2.1) diagrammes de collaboration __________________________________________________ 45
Objectifs du diagramme de collaboration ____________________________________________ Les interactions ________________________________________________________________ Les messages__________________________________________________________________ III.2.2) diagrammes de squence _____________________________________________________ Les interactions ________________________________________________________________ Les activations_________________________________________________________________ Les catgories de message _______________________________________________________ Les messages rflexifs___________________________________________________________ Les contraintes temporelles_______________________________________________________ La ligne de vie_________________________________________________________________ III.2.3) diagrammes d'tats-transitions_________________________________________________ Caractristiques et rgles de construction ____________________________________________ Etat_____________________________________________________________________ Evnements et transitions ___________________________________________________ Les traitements____________________________________________________________ La hirarchie des tats ______________________________________________________ Les tats prdfinis ________________________________________________________ III.2.4) diagrammes d'activits_______________________________________________________ Le droulement squentiel des activits _____________________________________________ La synchronisation _____________________________________________________________ Les couloirs d'activits __________________________________________________________
45 45 46 47 48 48 49 51 52 52 54 54 54 54 55 55 55 56 56 56 57
IV) Elments de comparaisons entre MERISE et UML _________________________ 58

IV.1) Les principes__________________________________________________________ 65
IV.1.1) Lapproche systmique ______________________________________________________ IV.1.2) Les cycles de construction du systme dinformation _______________________________ Le cycle de vie ________________________________________________________________ Le cycle dabstraction ___________________________________________________________ Le cycle de dcision ____________________________________________________________ IV.1.3) Lapproche fonctionnelle_____________________________________________________ IV.1.4) La sparation donnes-traitements _____________________________________________ IV.1.5) L approche qui part du gnral vers le particulier _________________________________ IV.2.1) Le domaine _______________________________________________________________ IV.2.2) Lacteur __________________________________________________________________ IV.2.3) Les flux __________________________________________________________________ IV.2.4) Les modles conceptuels et organisationnels _____________________________________ Les modles conceptuels_________________________________________________________ Le modle conceptuel des donnes ____________________________________________ Le concept de proprit _____________________________________________________ Le concept dentit ________________________________________________________ Le concept dassociation ____________________________________________________ La normalisation du modle _________________________________________________ Le modle conceptuel des traitements __________________________________________ Les vnements ___________________________________________________________ Les oprations ____________________________________________________________ La synchronisation_________________________________________________________ Les modles organisationnels _____________________________________________________ Le modle organisationnel des traitements ______________________________________ Le modle organisationnel des donnes ________________________________________ 65 65 66 66 66 66 67 67 67 67 68 68 68 68 68 68 69 69 70 70 70 70 70 70 71
IV.2) La modlisation mtier _________________________________________________ 67
IV.3) La dmarche __________________________________________________________ 71

IV.3.1) Les modles utiliss_________________________________________________________ 71 IV.3.2) les tapes du processus dlaboration du systme dinformation ______________________ 72
IV.4) Conclusion____________________________________________________________ 72
CONCLUSION GENERALE ______________________________________________ 73
INTRODUCTION
Pour faire face la complexit croissante des systmes dinformation, de nouvelles mthodes et outils ont t cres. La principale avance des quinze dernires annes rside dans la programmation oriente objet (P.O.O.). Face ce nouveau mode de programmation, les mthodes de modlisation classique (telle MERISE) ont rapidement montr certaines limites et ont d sadapter (cf. MERISE/2). De trs nombreuses mthodes ont galement vu le jour comme Booch, OMT Dans ce contexte et devant le foisonnement de nouvelles mthodes de conception oriente objet , lObject Management Group (OMG) a eu comme objectif de dfinir une notation standard utilisable dans les dveloppements informatiques bass sur lobjet. Cest ainsi quest apparu UML (Unified Modified Language langage de modlisation objet unifi ), qui est issu de la fusion des mthodes Booch, OMT (Object Modelling Technique) et OOSE (Object Oriented Software Engineering). Issu du terrain et fruit d'un travail d'experts reconnus, UML est le rsultat d'un large consensus. De trs nombreux acteurs industriels de renom ont adopt UML et participent son dveloppement. En l'espace d'une poigne d'annes seulement, UML est devenu un standard incontournable. Ceci nous amne nous questionner sur : - les apports rels dUML dans la modlisation - la place des mthodes dites traditionnelles telle que MERISE. UML est en effet apparu trs tardivement, car lapproche objet se pratique depuis de trs nombreuses annes dj. Simula, premier langage de programmation implmenter le concept de type abstrait l'aide de classes, date de 1967 ! En 1976 dj, Smalltalk implmente les concepts fondateurs de l'approche objet : encapsulation, agrgation, hritage. Les premiers compilateurs C++ datent du dbut des annes 80 et de nombreux langages orients objets "acadmiques" ont tay les concepts objets (Eiffel, Objective C, Loops...). Il y donc dj longtemps que l'approche objet est devenue une ralit. Les concepts de base de l'approche objet sont stables et largement prouvs. De nos jours, programmer "objet", c'est bnficier d'une panoplie d'outils et de langages performants. L'approche objet est une solution technologique incontournable. Ce n'est plus une mode, mais un rflexe quasi-automatique ds lors qu'on cherche concevoir des logiciels complexes qui doivent "rsister" des volutions incessantes. Toutefois, lapproche objet nest pas une panace : - elle est moins intuitive que l'approche fonctionnelle. Malgr les apparences, il est plus naturel pour l'esprit humain de dcomposer un problme informatique sous forme d'une hirarchie de fonctions atomiques et de donnes, qu'en terme d'objets et d'interaction entre ces objets. Or, rien dans les concepts de base de l'approche objet ne dicte comment modliser la structure objet d'un systme de manire pertinente. Quels moyens doit-on alors utiliser
COURS UML13.doc janv 2003
pour mener une analyse qui respecte les concepts objet ? Sans un cadre mthodologique appropri, la drive fonctionnelle de la conception est invitable... - l'application des concepts objet ncessite une trs grande rigueur. Le vocabulaire prcis est un facteur d'chec important dans la mise en oeuvre d'une approche objet (risques d'ambiguts et d'incomprhensions). Beaucoup de dveloppeurs (mme expriments) ne pensent souvent objet qu' travers un langage de programmation. Or, les langages orients objet ne sont que des outils qui proposent une manire particulire d'implmenter certains concepts objet. Ils ne valident en rien l'utilisation de ces moyens techniques pour concevoir un systme conforme la philosophie objet. Connatre C++ ou Java n'est donc pas une fin en soi, il faut aussi savoir se servir de ces langages bon escient. La question est donc de savoir "qui va nous guider dans l'utilisation des concepts objet, si ce ne sont pas les langages orients objet ?". Enfin, comment comparer deux solutions de dcoupe objet d'un systme si l'on ne dispose pas d'un moyen de reprsentation adquat ? Il est trs simple de dcrire le rsultat d'une analyse fonctionnelle, mais qu'en est-il d'une dcoupe objet ?
Pour remdier ces inconvnients majeurs de l'approche objet, il faut donc : 1) un langage (pour s'exprimer clairement l'aide des concepts objets) Le langage doit permettre de reprsenter des concepts abstraits (graphiquement par exemple), limiter les ambiguts (parler un langage commun, au vocabulaire prcis, indpendant des langages orients objet), faciliter l'analyse (simplifier la comparaison et l'valuation de solutions). 2) une dmarche d'analyse et de conception objet Une dmarche danalyse et de conception objet est ncessaire afin de ne pas effectuer une analyse fonctionnelle et se contenter d'une implmentation objet, mais penser objet ds le dpart, dfinir les vues qui permettent de dcrire tous les aspects d'un systme avec des concepts objets. Il faut donc disposer d'un outil qui donne une dimension mthodologique l'approche objet et qui permette de mieux matriser sa richesse. La prise de conscience de l'importance d'une mthode spcifiquement objet ("comment structurer un systme sans centrer l'analyse uniquement sur les donnes ou uniquement sur les traitements, mais sur les deux"), ne date pas d'hier. Plus de 50 mthodes objet sont apparues durant le milieu des annes 90 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...). Aucune ne s'est rellement impose. L'absence de consensus sur une mthode d'analyse objet a longtemps frein l'essor des technologies objet. Ce n'est que rcemment que les grands acteurs du monde informatique ont pris conscience de ce problme. L'unification et la normalisation des mthodes objet dominantes (OMT, Booch et OOSE) ne datent que de 1995. UML est le fruit de cette fusion. UML, ainsi que les mthodes dont il est issu, s'accordent sur un point : une analyse objet passe par une modlisation objet. Quest-ce quun modle ? Un modle est une abstraction de la ralit. L'abstraction est un des piliers de l'approche objet. Il s'agit d'un processus qui consiste identifier les caractristiques intressantes d'une entit en vue d'une utilisation prcise. L'abstraction dsigne aussi le
rsultat de ce processus, c'est--dire l'ensemble des caractristiques essentielles d'une entit, retenues par un observateur. Un modle est une vue subjective, mais pertinente de la ralit. Un modle dfinit une frontire entre la ralit et la perspective de l'observateur. Ce n'est pas "la ralit", mais une vue trs subjective de la ralit. Bien qu'un modle ne reprsente pas une ralit absolue, un modle reflte des aspects importants de la ralit, il en donne donc une vue juste et pertinente. Le caractre abstrait d'un modle doit notamment permettre de faciliter la comprhension du systme tudi. Il rduit la complexit du systme tudi, permet de simuler le systme, le reprsente et reproduit ses comportements. Concrtement, un modle rduit (dcompose) la ralit, dans le but de disposer d'lments de travail exploitables par des moyens mathmatiques ou informatiques. UML permet donc de modliser une application selon une vision objet. Lapprhension dUML est complexe car UML est la fois : - une norme, - un langage de modlisation objet, - un support de communication, - un cadre mthodologique.
UML est une norme

Fin 1997, UML est devenu une norme OMG (Object Management Group). L'OMG est un organisme but non lucratif, cr en 1989 l'initiative de grandes socits (HP, Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'OMG fdre plus de 850 acteurs du monde informatique. Son rle est de promouvoir des standards qui garantissent l'interoprabilit entre applications orientes objet, dveloppes sur des rseaux htrognes. L'OMG propose notamment l'architecture CORBA (Common Object Request Broker Architecture), un modle standard pour la construction d'applications objets distribus (rpartis sur un rseau). CORBA fait partie d'une vision globale de la construction d'applications rparties, appele OMA (Object Management Architecture) et dfinie par l'OMG. Sans rentrer dans les dtails, on peut rsumer cette vision par la volont de favoriser l'essor industriel des technologies objet, en offrant un ensemble de solutions technologiques non propritaires, qui suppriment les clivages techniques. UML a t adopt (normalis) par l'OMG et intgr l'OMA, car il participe cette vision et parce qu'il rpond la "philosophie" OMG.
UML est un langage de modlisation objet.

Pour penser et concevoir objet, il faut savoir "prendre de la hauteur", jongler avec des concepts abstraits, indpendants des langages d'implmentation et des contraintes purement techniques. Les langages de programmation ne sont pas un support d'analyse adquat pour "concevoir objet". Ils ne permettent pas de dcrire des solutions en terme de concepts abstraits et constituent un cadre trop rigide pour mener une analyse itrative. Pour conduire une analyse objet cohrente, il ne faut pas directement penser en terme de pointeurs, d'attributs et de tableaux, mais en terme d'association, de proprits et de cardinalits... Utiliser le langage de programmation comme support de conception ne J.STEFFE ENITA de Bordeaux 3
revient bien souvent qu' juxtaposer de manire fonctionnelle un ensemble de mcanismes d'implmentation, pour rsoudre un problme qui ncessite en ralit une modlisation objet. Lapproche objet ncessite une analyse rflchie, qui passe par diffrentes phases exploratoires. Bien que raisonner en terme d'objets semble naturel, l'approche fonctionnelle reste la plus intuitive pour nos esprits cartsiens... Voil pourquoi il ne faut pas se contenter d'une implmentation objet, mais se discipliner "penser objet" au cours d'une phase d'analyse pralable. Toutes les drives fonctionnelles de code objet ont pour origine le non respect des concepts de base de l'approche objet (encapsulation...) ou une utilisation dtourne de ces concepts (hritage sans classification...). Ces drives ne sont pas dues de mauvaises techniques de programmation ; la racine du mal est bien plus profonde : programmer en C++ ou en Java n'implique pas forcment concevoir objet... Les difficults de mise en oeuvre d'une approche "rellement objet" ont engendr bien souvent des dceptions, ce qui a longtemps constitu un obstacle important l'essor des technologies objet. Beaucoup ont cd au leurre des langages de programmation orients objet et oubli que le code n'est qu'un "moyen". Le respect des concepts fondamentaux de l'approche objet prime sur la manire dont on les implmente. Ne penser qu' travers un langage de programmation objet dtourne de l'essentiel. Pour sortir les technologies objet de cette impasse, l'OMG propose UML. UML comble une lacune importante des technologies objet. Il permet d'exprimer et d'laborer des modles objet, indpendamment de tout langage de programmation. Il a t pens pour servir de support une analyse base sur les concepts objet. UML est un langage formel, dfini par un mtamodle. Le mtamodle d'UML dcrit de manire trs prcise tous les lments de modlisation (les concepts vhiculs et manipuls par le langage) et la smantique de ces lments (leur dfinition et le sens de leur utilisation). En d'autres termes : UML normalise les concepts objet. Un mtamodle permet de limiter les ambiguts et encourage la construction d'outils. Il permet aussi de classer les diffrents concepts du langage (selon leur niveau d'abstraction ou leur domaine d'application) et expose ainsi clairement sa structure. Enfin, on peut noter que le mtamodle d'UML est lui-mme dcrit par un mta-mtamodle de manire standardise, l'aide de MOF (Meta Object Facility : norme OMG de description des mtamodles). Vritable cl de vote de l'OMA, UML est donc un outil indispensable pour tous ceux qui ont compris que programmer objet, c'est d'abord concevoir objet. UML n'est pas l'origine des concepts objets, mais il en constitue une tape majeure, car il unifie les diffrentes approches et en donne une dfinition plus formelle.
UML est un support de communication

UML est avant tout un support de communication performant, qui facilite la reprsentation et la comprhension de solutions objet. Sa notation graphique permet d'exprimer visuellement une solution objet, ce qui facilite la comparaison et l'valuation de solutions. L'aspect formel de sa notation limite les ambiguts et les incomprhensions.
Son indpendance par rapport aux langages de programmation, aux domaines d'application et aux processus, en font un langage universel. La notation graphique d'UML n'est que le support du langage. La vritable force d'UML, c'est qu'il repose sur un mtamodle. En d'autres termes : la puissance et l'intrt d'UML, c'est qu'il normalise la smantique des concepts qu'il vhicule ! Qu'une association d'hritage entre deux classes soit reprsente par une flche termine par un triangle ou un cercle, n'a que peu d'importance par rapport au sens que cela donne votre modle. La notation graphique est essentiellement guide par des considrations esthtiques, mme si elle a t pense dans ses moindres dtails. Par contre, utiliser une relation d'hritage, reflte l'intention de donner votre modle un sens particulier. Un "bon" langage de modlisation doit permettre n'importe qui de dchiffrer cette intention de manire non quivoque. Il est donc primordial de s'accorder sur la smantique des lments de modlisation, bien avant de s'intresser la manire de les reprsenter. Le mtamodle UML apporte une solution ce problme fondamental. UML est donc bien plus qu'un simple outil qui permet de "dessiner" des reprsentations mentales... Il permet de parler un langage commun, normalis mais accessible, car visuel.
UML est un cadre mthodologique pour une analyse objet

Une autre caractristique importante d'UML, est qu'il cadre l'analyse. UML permet de reprsenter un systme selon diffrentes vues complmentaires : les diagrammes. Un diagramme UML est une reprsentation graphique, qui s'intresse un aspect prcis du modle ; c'est une perspective du modle. Chaque type de diagramme UML possde une structure (les types des lments de modlisation qui le composent sont prdfinis) et vhicule une smantique prcise (il offre toujours la mme vue d'un systme). Combins, les diffrents types de diagrammes UML offrent une vue complte des aspects statiques et dynamiques d'un systme. Les diagrammes permettent donc d'inspecter un modle selon diffrentes perspectives et guident l'utilisation des lments de modlisation (les concepts objet), car ils possdent une structure. Une caractristique importante des diagrammes UML, est qu'ils supportent l'abstraction. Cela permet de mieux contrler la complexit dans l'expression et l'laboration des solutions objet. UML opte en effet pour l'laboration des modles, plutt que pour une approche qui impose une barrire stricte entre analyse et conception. Les modles d'analyse et de conception ne diffrent que par leur niveau de dtail, il n'y a pas de diffrence dans les concepts utiliss. UML n'introduit pas d'lments de modlisation propres une activit (analyse, conception...) ; le langage reste le mme tous les niveaux d'abstraction. Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction. L'laboration encourage une approche non linaire, les "retours en arrire" entre niveaux d'abstraction diffrents sont facilits et la traabilit entre modles de niveaux diffrents est assure par l'unicit du langage. UML favorise donc le prototypage, et c'est l une de ses forces. En effet, modliser une application n'est pas une activit linaire. Il s'agit d'une tche trs complexe, qui ncessite une approche itrative, car il est plus efficace de construire et valider par tapes, ce qui est difficile cerner et matriser.
UML permet donc non seulement de reprsenter et de manipuler les concepts objet, il sous-entend une dmarche d'analyse qui permet de concevoir une solution objet de manire itrative, grce aux diagrammes, qui supportent l'abstraction.
UML n'est pas une mthode

UML est un langage qui permet de reprsenter des modles, mais il ne dfinit pas le processus d'laboration des modles. Qualifier UML de "mthode objet" n'est donc pas tout fait appropri. Une mthode propose aussi un processus, qui rgit notamment l'enchanement des activits de production d'une entreprise. Or UML n'a pas t pens pour rgir les activits de l'entreprise. Les auteurs d'UML sont tout fait conscients de l'importance du processus, mais ce sujet a t intentionnellement exclu des travaux de l'OMG. Comment prendre en compte toutes les organisations et cultures d'entreprises ? Un processus est adapt (donc trs li) au domaine d'activit de l'entreprise ; mme s'il constitue un cadre gnral, il faut l'adapter au contexte de l'entreprise. Bref, amliorer un processus est une discipline part entire, c'est un objectif qui dpasse trs largement le cadre de l'OMA. Cependant, mme si pour l'OMG, l'acceptabilit industrielle de la modlisation objet passe d'abord par la disponibilit d'un langage d'analyse objet performant et standard, les auteurs d'UML prconisent d'utiliser une dmarche : guide par les besoins des utilisateurs du systme, centre sur l'architecture logicielle, itrative et incrmentale. D'aprs les auteurs d'UML, un processus de dveloppement qui possde ces qualits fondamentales "devrait" favoriser la russite d'un projet. Une source frquente de malentendus sur UML a pour origine la facult d'UML de modliser un processus, pour le documenter et l'optimiser par exemple. En fin de compte, qu'est-ce qu'un processus ? Un ensemble d'activits coordonnes et rgules, en partie ordonnes, dont le but est de crer un produit (matriel ou intellectuel). UML permet tout fait de modliser les activits (c'est--dire la dynamique) d'un processus, de dcrire le rle des acteurs du processus, la structure des lments manipuls et produits, etc... Une extension d'UML ("UML extension for business modeling") propose d'ailleurs un certain nombre de strotypes standards (extensions du mtamodle) pour mieux dcrire les processus. Le RUP ("Rational Unified Process"), processus de dveloppement "cl en main", propos par Rational Software, est lui aussi modlis (document) avec UML. Il offre un cadre mthodologique gnrique qui repose sur UML et la suite d'outils Rational.
Conclusion
Comme UML n'impose pas de mthode de travail particulire, il peut tre intgr n'importe quel processus de dveloppement logiciel de manire transparente. UML est une sorte de bote outils, qui permet d'amliorer progressivement vos mthodes de travail, tout en prservant vos modes de fonctionnement. Intgrer UML par tapes dans un processus, de manire pragmatique, est tout fait possible. La facult d'UML de se fondre dans le processus courant, tout en vhiculant une dmarche mthodologique, facilite son intgration et limite de nombreux risques (rejet des utilisateurs, cots...).
Intgrer UML dans un processus ne signifie donc pas rvolutionner ses mthodes de travail, mais cela devrait tre loccasion de se remettre en question.
I). Le contexte dapparition dUML

I.1) Approche fonctionnelle versus approche objet I.1.1) Lapproche fonctionnelle La dcoupe fonctionnelle d'un problme informatique : une approche intuitive
La dcoupe fonctionnelle dun problme (sur laquelle reposent les langages de programmation structure) consiste dcouper le problme en blocs indpendants. En ce sens, elle prsente un caractre intuitif fort.
La rutilisabilit du code
Le dcoupage dun problme en blocs indpendants (fonctions et procdures) va permettre aux programmeurs de rutiliser les fonctions dj dveloppes ( condition quelles soient suffisamment gnriques). La productivit se trouve donc accrue.
Le revers de la mdaille : maintenance complexe en cas d'volution

Le dcoupage en blocs fonctionnels n'a malheureusement pas que des avantages. Les fonctions sont devenues interdpendantes : une simple mise jour du logiciel un point donn, peut impacter en cascade une multitude d'autres fonctions. On peut minorer cet impact, pour peu qu'on utilise des fonctions plus gnriques et des structures de donnes ouvertes. Mais respecter ces contraintes rend l'criture du logiciel et sa maintenance plus complexe. En cas d'volution majeure du logiciel (passage de la gestion d'une bibliothque celle d'une mdiathque par exemple), le scnario est encore pire. Mme si la structure gnrale du logiciel reste valide, la multiplication des points de maintenance, engendre par le chanage des fonctions, rend l'adaptation trs laborieuse. Le logiciel doit tre retouch dans sa globalit : - on a de nouvelles donnes grer (ex : DVD) - les traitements voluent : laffichage sera diffrent selon le type (livre, CD, DVD )
Problmes gnrs par la sparation des donnes et des traitements :

Examinons le problme de l'volution de code fonctionnel plus en dtail... Faire voluer une application de gestion de bibliothque pour grer une mdiathque, afin de prendre en compte de nouveaux types d'ouvrages (cassettes vido, CD-ROM, etc...), ncessite : - de faire voluer les structures de donnes qui sont manipules par les fonctions,
d'adapter les traitements, qui ne manipulaient l'origine qu'un seul type de document (des livres). Il faudra donc modifier toutes les portions de code qui utilisent la base documentaire, pour grer les donnes et les actions propres aux diffrents types de documents. Il faudra par exemple modifier la fonction qui ralise l'dition des "lettres de rappel" (une lettre de rappel est une mise en demeure, qu'on envoie automatiquement aux personnes qui tardent rendre un ouvrage emprunt). Si l'on dsire que le dlai avant rappel varie selon le type de document emprunt, il faut prvoir une rgle de calcul pour chaque type de document. En fait, c'est la quasi-totalit de l'application qui devra tre adapte, pour grer les nouvelles donnes et raliser les traitements correspondants. Et cela, chaque fois qu'on dcidera de grer un nouveau type de document !
1re amlioration : rassembler les valeurs qui caractrisent un type, dans le type
Une solution relativement lgante la multiplication des branches conditionnelles et des redondances dans le code (consquence logique d'une trop grande ouverture des donnes), consiste tout simplement centraliser dans les structures de donnes, les valeurs qui leurs sont propres. Par exemple, le dlai avant rappel peut tre dfini pour chaque type de document. Cela permet donc de crer une fonction plus gnrique qui sapplique tous les types de documents.
2me amlioration : centraliser les traitements associs un type, auprs du type

Pourquoi ne pas aussi rassembler dans une mme unit physique les types de donnes et tous les traitements associs ? Que se passerait-il par exemple si l'on centralisait dans un mme fichier, la structure de donnes qui dcrit les documents et la fonction de calcul du dlai avant rappel ? Cela nous permettrait de retrouver immdiatement la partie de code qui est charge de calculer le dlai avant rappel d'un document, puisqu'elle se trouve au plus prs de la structure de donnes concerne. Ainsi, si notre mdiathque devait grer un nouveau type d'ouvrage, il suffirait de modifier une seule fonction (qu'on sait retrouver instantanment), pour assurer la prise en compte de ce nouveau type de document dans le calcul du dlai avant rappel. Plus besoin de fouiller partout dans le code... Ecrit en ces termes, le logiciel serait plus facile maintenir et bien plus lisible. Le stockage et le calcul du dlai avant rappel des documents, serait dsormais assur par une seule et unique unit physique (quelques lignes de code, rapidement identifiables). Pour accder la caractristique "dlai avant rappel" d'un document, il suffit de rcuprer la valeur correspondante parmi les champs qui dcrivent le document. Pour assurer la prise en compte d'un nouveau type de document dans le calcul du dlai avant rappel, il suffit de
modifier une seule fonction, situe au mme endroit que la structure de donnes qui dcrit les documents.
Document Code document Nom document Type document Calculer date rappel
Centraliser les donnes d'un type et les traitements associs, dans une mme unit physique, permet de limiter les points de maintenance dans le code et facilite l'accs l'information en cas d'volution du logiciel.
I.1.2) Lapproche objet Le concept dobjet

Les modifications qui ont t apportes au logiciel de gestion de mdiathque, nous ont amen transformer ce qui tait l'origine une structure de donnes, manipule par des fonctions, en une entit autonome, qui regroupe un ensemble de proprits cohrentes et de traitements associs. Une telle entit s'appelle... un objet et constitue le concept fondateur de l'approche du mme nom. Un objet est une entit aux frontires prcises qui possde une identit (un nom). Un ensemble d'attributs caractrise l'tat de l'objet. Un ensemble d'oprations (mthodes) en dfinissent le comportement. Un objet est une instance de classe (une occurrence d'un type abstrait). Une classe est un type de donnes abstrait, caractris par des proprits (attributs et mthodes) communes des objets et permettant de crer des objets possdant ces proprits.
Docum ent + code docum ent : int + nom docum ent : String + T ype docum ent : String + Calculer date rappel () : Date
Classe : regroupement dobjets
MERISE_UML_document C1 De Merise vers UML Support de cours
Objet : instance dune classe
10
Les autres concepts importants de l'approche objet. lencapsulation

Lencapsulation consiste masquer les dtails d'implmentation d'un objet, en dfinissant une interface. L'interface est la vue externe d'un objet, elle dfinit les services accessibles (offerts) aux utilisateurs de l'objet. L'encapsulation facilite l'volution d'une application car elle stabilise l'utilisation des objets : on peut modifier l'implmentation des attributs d'un objet sans modifier son interface. L'encapsulation garantit l'intgrit des donnes, car elle permet d'interdire l'accs direct aux attributs des objets.
lhritage
L'hritage est un mcanisme de transmission des proprits d'une classe (ses attributs et mthodes) vers une sous-classe. Une classe peut tre spcialise en d'autres classes, afin d'y ajouter des caractristiques spcifiques ou d'en adapter certaines. Plusieurs classes peuvent tre gnralises en une classe qui les factorise, afin de regrouper les caractristiques communes d'un ensemble de classes. La spcialisation et la gnralisation permettent de construire des hirarchies de classes. L'hritage peut tre simple ou multiple. L'hritage vite la duplication et encourage la rutilisation.
Oeuvre T itre Auteur
Heritage_2 Livre
Heritage_1 Film
Heritage_3 Roman
Heritage_4 BD
le polymorphisme
Le polymorphisme reprsente la facult d'une mme opration de s'excuter diffremment suivant le contexte de la classe o elle se trouve. J.STEFFE ENITA de Bordeaux 11
Ainsi, une opration dfinie dans une superclasse peut s'excuter de faon diffrente selon la sous-classe o elle est hrite. Ex : excution d'une opration de calcul des salaires dans 2 sous-classes spcialises : une pour les cadres, l'autre pour les non-cadres. Le polymorphisme augmente la gnricit du code.
Oeuvre Titre Auteur
Heritage_2 Livre
Heritage_1 Film
Dupliquer sur support() { papier }
Dupliquer sur support() { magntique }
lagrgation
Il s'agit d'une relation entre deux classes, spcifiant que les objets d'une classe sont des composants de l'autre classe. Une relation d'agrgation permet donc de dfinir des objets composs d'autres objets. L'agrgation permet d'assembler des objets de base, afin de construire des objets plus complexes.
Eau : molcule Hygrogne : atome
Hygrogne : atome Oxygne : atome
12
Historique de lapproche objet

Les concepts objet sont stables et prouvs (issus du terrain) : - Simula, 1er langage de programmation implmenter le concept de type abstrait ( l'aide de classes), date de 1967 ! - En 1976 dj, Smalltalk implmente les concepts fondateurs de l'approche objet (encapsulation, agrgation, hritage) l'aide de : o classes o associations entre classes o hirarchies de classes o messages entre objets - Le 1er compilateur C++ date de 1980, et C++ est normalis par l'ANSI. - De nombreux langages orients objets acadmiques ont tays les concepts objets : Eiffel, Objective C, Loops Les concepts objet sont anciens, mais ils n'ont jamais t autant d'actualit : - L'approche fonctionnelle n'est pas adapte au dveloppement d'applications qui voluent sans cesse et dont la complexit croit continuellement. - L'approche objet a t invente pour faciliter l'volution d'applications complexes. De nos jours, les outils orients objet sont fiables et performants - Les compilateurs C++ produisent un code robuste et optimis. - De trs nombreux outils facilitent le dveloppement d'applications C++ : o bibliothques (STL, USL, Rogue Wave, MFC...) o environnements de dveloppement intgrs (Developper Studio, Sniff+...) o outils de qualimtrie et de tests (Cantata++, Insure++, Logiscope...) o bases de donnes orientes objet (O2, ObjectStore, Versant...)
Inconvnients de lapproche objet

L'approche objet est moins intuitive que l'approche fonctionnelle. L'application des concepts objets ncessite une grande rigueur : le vocabulaire est prcis (risques d'ambiguts, d'incomprhensions).
Solutions pour remdier aux inconvnients de lapproche objet

Il faut bnficier dun langage pour exprimer les concepts objet qu'on utilise, afin de pouvoir : - reprsenter des concepts abstraits (graphiquement par exemple). - limiter les ambiguts (parler un langage commun). - faciliter l'analyse (simplifier la comparaison et l'valuation de solutions). Il faut galement une dmarche d'analyse et de conception objet, pour : - ne pas effectuer une analyse fonctionnelle et se contenter d'une implmentation objet, mais penser objet ds le dpart. - dfinir les vues qui permettent de couvrir tous les aspects d'un systme, avec des concepts objets.
13
I.2) La gense dUML I.2.1) Historique des mthodes danalyse Les premires mthodes d'analyse (annes 70)
Dcoupe cartsienne (fonctionnelle et hirarchique) d'un systme.
L'approche systmique (annes 80)

Modlisation des donnes + modlisation des traitements (Merise ...).
L'mergence des mthodes objet (1990-1995)

Prise de conscience de l'importance d'une mthode spcifiquement objet : - comment structurer un systme sans centrer l'analyse uniquement sur les donnes ou uniquement sur les traitements (mais sur les deux) ? - Plus de 50 mthodes objet sont apparues durant cette priode (Booch, ClasseRelation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) ! - Aucun mthode ne s'est rellement impose.
Les premiers consensus (1995)

OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un systme o issue du centre de R&D de General Electric. o Notation graphique riche et lisible. OOD (Grady Booch) : vues logiques et physiques du systme o Dfinie pour le DOD, afin de rationaliser de dveloppement d'applications ADA, puis C++. o Ne couvre pas la phase d'analyse dans ses 1res versions (prconise SADT). o Introduit le concept de package (lment d'organisation des modles). OOSE (Ivar Jacobson) : couvre tout le cycle de dveloppement o Issue d'un centre de dveloppement d'Ericsson, en Sude. o La mthodologie repose sur l'analyse des besoins des utilisateurs.
L'unification et la normalisation des mthodes (1995-1997)

En octobre 1994, G. Booch (pre fondateur de la mthode Booch) et J. Rumbaugh (principal auteur de la mthode OMT) ont dcid de travailler ensemble pour unifier leurs mthodes au sein de la socit Rational Software. Un an aprs, I . Jacobson (auteur de la mthode OOSE et des cas dutilisation) a rejoint Rational Software pour travailler sur lunification. Unified Modified Language (UML) est n. Les travaux sur ce langage ont continu avec son adoption par de grands acteurs industriels comme HP, Microsoft, Oracle ou Unisys. Ce travail a abouti en 1997 UML 1.0. Le langage a t soumis par Rational Software et ses partenaires lOMG comme rponse un appel doffres sur la standardisation des langages de modlisation. Lappel doffres de lOMG a recueilli un avis favorable, puisque 6 rponses concurrentes sont parvenues lOMG. IBM et Object Time (mthode ROOM pour les systmes temps rel ractifs) ont dcid de rejoindre lquipe UML ; leur proposition tait en fait une extension dUML 1.0.
14
Certains autres auteurs qui ont rpondu lappel doffres ont abandonn leur proposition pour rejoindre leur tour UML. En novembre 1997, UML a t adopt par lOMG.
Autres mthodes Booch 91 OMT 1 OOSE
1993
Booch 93
OMT 2
1995
Unified method 0,8
1996
UML 0.9
Partenaires : IBM, HP, Microsoft, Oracle
soumis l'OMG jan 1997 adopt par l'OMG Nov 1997
UML 1.0
UML 1.1
UML est donc le rsultat dun large consensus et tient compte des dernires avances en matire de modlisation et de dveloppement logiciel. L'OMG RTF (nombreux acteurs industriels) centralise et normalise les volutions d'UML au niveau international et de nombreux groupes d'utilisateurs UML favorisent le partage des expriences.
I.2.2) Cadre dutilisation dUML UML n'est pas une mthode ou un processus
Si l'on parle de mthode objet pour UML, c'est par abus de langage. Ce constat vaut aussi pour OMT ou d'autres techniques / langages de modlisation. Une mthode propose aussi un processus, qui rgit notamment l'enchanement des activits de production d'une entreprise. Or, UML a t pens pour permettre de modliser les activits de l'entreprise, pas pour les rgir. Des mthodes orientes objet les plus connues, seules les mthodes OOSE et BOOCH incluent cet aspect processus de manire explicite et formelle. Ces 2 auteurs se sont dailleurs toujours dmarqus des autres sur ce point. Par leur nature, les processus doivent tre adapts aux organisations, leurs domaines dactivit, leur culture De ce fait, ni la normalisation ni la standardisation dun processus de dveloppement logiciel ne peut faire lobjet dun consensus international suffisant pour aboutir un standard acceptable et utilisable.
15
UML est un langage de modlisation

UML est un langage de modlisation au sens de la thorie des langages. Il contient de ce fait les lments constitutifs de tout langage, savoir : des concepts, une syntaxe et une smantique. De plus, UML a choisi une notation supplmentaire : il sagit dune forme visuelle fonde sur des diagrammes. Si lunification dune notation est secondaire par rapports aux lments constituant le langage, elle reste cependant primordiale pour la communication et la comprhension.
UML dcrit un mta modle

UML est fond sur un mtamodle, qui dfinit : - les lments de modlisation (les concepts manipuls par le langage), - la smantique de ces lments (leur dfinition et le sens de leur utilisation). Un mtamodle est une description trs formelle de tous les concepts d'un langage. Il limite les ambiguts et encourage la construction d'outils. Le mtamodle d'UML permet de classer les concepts du langage (selon leur niveau d'abstraction ou domaine d'application) et expose sa structure. Le mtamodle UML est lui-mme dcrit par un mta-mtamodle (OMG-MOF). UML propose aussi une notation, qui permet de reprsenter graphiquement les lments de modlisation du mtamodle. Cette notation graphique est le support du langage UML. UML offre : - diffrentes vues (perspectives) complmentaires d'un systme, qui guident l'utilisation des concept objets - plusieurs niveaux d'abstraction, qui permettent de mieux contrler la complexit dans l'expression des solutions objets.
UML est un support de communication

Sa notation graphique permet d'exprimer visuellement une solution objet. L'aspect formel de sa notation limite les ambiguts et les incomprhensions. Son aspect visuel facilite la comparaison et l'valuation de solutions. Son indpendance (par rapport aux langages d'implmentation, domaine d'application, processus...) en font un langage universel.
I.2.3) Points forts dUML UML est un langage formel et normalis

Il permet ainsi : - un gain de prcision - un gage de stabilit - l'utilisation d'outils
16
UML est un support de communication performant

Il cadre l'analyse et facilite la comprhension de reprsentations abstraites complexes. Son caractre polyvalent et sa souplesse en font un langage universel.
I.2.4) Points faibles dUML La mise en pratique d'UML ncessite un apprentissage et passe par une priode d'adaptation.
Mme si l'Espranto est une utopie, la ncessit de s'accorder sur des modes d'expression communs est vitale en informatique. UML n 'est pas l'origine des concepts objets, mais en constitue une tape majeure, car il unifie les diffrentes approches et en donne une dfinition plus formelle.
Le processus (non couvert par UML) est une autre cl de la russite d'un projet.
L'intgration d'UML dans un processus n'est pas triviale et amliorer un processus est un tche complexe et longue.
17
II) Dmarche gnrale de modlisation avec UML

II.1) Qu'est-ce qu'un modle ? II.1.1) Dfinition dun modle
Un modle est une abstraction de la ralit L'abstraction est un des piliers de l'approche objet : il s'agit d'un processus qui consiste identifier les caractristiques intressantes d'une entit, en vue d'une utilisation prcise. L'abstraction dsigne aussi le rsultat de ce processus, c'est--dire l'ensemble des caractristiques essentielles d'une entit, retenues par un observateur. Un modle est une vue subjective mais pertinente de la ralit. Un modle dfinit une frontire entre la ralit et la perspective de l'observateur. Ce n'est pas "la ralit", mais une vue trs subjective de la ralit. Bien qu'un modle ne reprsente pas une ralit absolue, un modle reflte des aspects importants de la ralit, il en donne donc une vue juste et pertinente.
II.1.2) Caractristiques fondamentales des modles

Le caractre abstrait d'un modle doit notamment permettre : - de faciliter la comprhension du systme tudi : un modle rduit la complexit du systme tudi. - de simuler le systme tudi : un modle reprsente le systme tudi et reproduit ses comportements.
II.2 ) Comment modliser avec UML ? II.2.1) Proposition de dmarche

UML est un langage qui permet de reprsenter des modles, mais il ne dfinit pas le processus d'laboration des modles : UML nest donc pas une mthode de modlisation. Cependant, dans le cadre de la modlisation d'une application informatique, les auteurs d'UML prconisent d'utiliser une dmarche : - itrative et incrmentale, - guide par les besoins des utilisateurs du systme, - centre sur l'architecture logicielle. D'aprs les auteurs d'UML, un processus de dveloppement qui possde ces qualits devrait favoriser la russite d'un projet.
18
Une dmarche itrative et incrmentale

Pour modliser (comprendre et reprsenter) un systme complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par tapes. Cette dmarche doit aussi s'appliquer au cycle de dveloppement dans son ensemble, en favorisant le prototypage. Le but est de mieux matriser la part d'inconnu et d'incertitudes qui caractrisent les systmes complexes.
Une dmarche pilote par les besoins des utilisateurs

Avec UML, ce sont les utilisateurs qui guident la dfinition des modles : Le primtre du systme modliser est dfini par les besoins des utilisateurs (les utilisateurs dfinissent ce que doit tre le systme). Le but du systme modliser est de rpondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du systme). Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de dveloppement (itratif et incrmental) : - chaque itration de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs. - chaque itration de la phase de conception et de ralisation, on veille la prise en compte des besoins des utilisateurs. - chaque itration de la phase de test, on vrifie que les besoins des utilisateurs sont satisfaits.
Une dmarche centre sur l'architecture

Une architecture adapte est la cl de vote du succs d'un dveloppement. Elle dcrit des choix stratgiques qui dterminent en grande partie les qualits du logiciel (adaptabilit, performances, fiabilit...). Ph. Kruchten propose diffrentes perspectives, indpendantes et complmentaires, qui permettent de dfinir un modle d'architecture (publication IEEE, 1995). Ph. Kruchten dfend lide que larchitecture logicielle doit tre une discipline part entire. Il propose que plusieurs perspectives concourent lexpression de larchitecture dun systme et il explique quil est ncessaire de garantir la sparation et lindpendance de ces diffrentes perspectives. Lvolution de lune des perspectives ne doit pas avoir dimpact (sinon limit) sur les autres. La relation entre les diffrentes perspectives a t reprsente par ph. Kruchten dans le schma suivant, dit schma 4+1 vues .
19
Vue logique
Vue des composants Vue des cas d'utilisation
Vue des processus
Vue de dploiement
II.2.2) La vue 4+1 de ph. Kruchten La vue logique

Cette vue concerne lintgrit de conception . Cette vue de haut niveau se concentre sur l'abstraction et l'encapsulation, elle modlise les lments et mcanismes principaux du systme. Elle identifie les lments du domaine, ainsi que les relations et interactions entre ces lments notions de classes et de relations : - les lments du domaine sont lis au(x) mtier(s) de l'entreprise, - ils sont indispensables la mission du systme, - ils gagnent tre rutiliss (ils reprsentent un savoir-faire). Cette vue organise aussi (selon des critres purement logiques), les lments du domaine en "catgories" : - pour rpartir les tches dans les quipes, - regrouper ce qui peut tre gnrique, - isoler ce qui est propre une version donne, etc...
La vue des composants

Cette vue concerne lintgrit de gestion . Elle exprime la perspective physique de lorganisation du code en termes de modules, de composants et surtout des concepts du langage ou de lenvironnement dimplmentation. Dans cette perspective, larchitecte est surtout concern par les aspects de gestion du code, dordre de compilation, de rutilisation, dintgration et dautres contraintes de dveloppement pur. Pour reprsenter cette perspective, UML fournit des concepts adapts tels que les modules, les composants, les relations de dpendance, linterface Cette vue de bas niveau (aussi appele vue de ralisation ), montre ainsi : - l'allocation des lments de modlisation dans des modules (fichiers sources, bibliothques dynamiques, bases de donnes, excutables, etc...). Cette vue identifie les modules qui ralisent (physiquement) les classes de la vue logique. - l'organisation des composants, c'est--dire la distribution du code en gestion de configuration, les dpendances entre les composants... - les contraintes de dveloppement (bibliothques externes...). - l'organisation des modules en "sous-systmes", les interfaces des sous-systmes et leurs dpendances (avec d'autres sous-systmes ou modules).
20
La vue des processus

Cette vue concerne lintgrit dexcution . Cette vue est trs importante dans les environnements multitches ; elle exprime la perspective sur les activits concurrentes et parallles. Elle montre ainsi : - la dcomposition du systme en terme de processus (tches). - les interactions entre les processus (leur communication). - la synchronisation et la communication des activits parallles (threads).
La vue de dploiement
Cette vue concerne lintgrit de performance . Elle exprime la rpartition du systme travers un rseau de calculateurs et de nuds logiques de traitements . Cette vue est particulirement utile pour dcrire la distribution dun systme rparti. Elle montre : - la disposition et nature physique des matriels, ainsi que leurs performances. - l'implantation des modules principaux sur les nuds du rseau. - les exigences en terme de performances (temps de rponse, tolrance aux fautes et pannes...).
La vue des cas dutilisation

Cette vue est particulire en ce sens quelle guide toutes les autres. Cette vue permet : - de trouver le bon modle Les cas dutilisation permettent de guider la modlisation. Lutilisation des scnarios et des cas dutilisation savre plus rigoureuse et plus systmatique que les entretiens et lanalyse des documents pour dcouvrir les abstractions du domaine. - dexpliquer et de justifier ses choix Il est en effet ncessaire dexpliquer le systme, de justifier les choix qui ont guid sa conception et son fonctionnement pour pouvoir le construire, le maintenir et le tester. Pour cela UML offre des concepts adapts tels que les scnarios et les cas dutilisation.
II.2.3) Les niveaux dabstraction Une non-dmarcation entre conception et analyse

UML opte pour l'laboration des modles, plutt que pour une approche qui impose une barrire stricte entre analyse et conception : - les modles d'analyse et de conception ne diffrent que par leur niveau de dtail, il n'y a pas de diffrence dans les concepts utiliss. - UML n'introduit pas d'lments de modlisation propres une activit (analyse, conception...) ; le langage reste le mme tous les niveaux d'abstraction. Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction : - l'laboration encourage une approche non linaire (les "retours en arrire" entre niveaux d'abstraction diffrents sont facilits). - la traabilit entre modles de niveaux diffrents est assure par l'unicit du langage. J.STEFFE ENITA de Bordeaux 21
Les niveaux dabstraction Conceptualisation

L'entre de l'analyse ce niveau est le dossier d'expression des besoins client. A ce niveau d'abstraction, on doit capturer les besoins principaux des utilisateurs. Il ne faut pas chercher l'exhaustivit, mais clarifier, filtrer et organiser les besoins. Le but de la conceptualisation est : - de dfinir le contour du systme modliser (de spcifier le "quoi"), - de capturer les fonctionnalits principales du systme, afin d'en fournir une meilleure comprhension (le modle produit sert d'interface entre les acteurs du projet), - de fournir une base la planification du projet.
Analyse du domaine
L'entre de l'analyse ce niveau, est le modle des besoins clients (les "cas d'utilisation" UML). Il s'agit de modliser les lments et mcanismes principaux du systme. On identifie les lments du domaine, ainsi que les relations et interactions entre ces lments : - les lments du domaine sont lis au(x) mtier(s) de l'entreprise, - ils sont indispensables la mission du systme, - ils gagnent tre rutiliss (ils reprsentent un savoir-faire). A ce stade, on organise aussi (selon des critres purement logiques), les lments du domaine en "catgories", pour rpartir les tches dans les quipes, regrouper ce qui peut tre gnrique, etc...
Analyse applicative
A ce niveau, on modlise les aspects informatiques du systme, sans pour autant rentrer dans les dtails d'implmentation. Les interfaces des lments de modlisation sont dfinis (cf. encapsulation). Les relations entre les lments des modles sont dfinies. Les lments de modlisation utiliss peuvent tre propres une version du systme.
Conception
On y modlise tous les rouages d'implmentation et on dtaille tous les lments de modlisation issus des niveaux suprieurs. Les modles sont optimiss, car destins tre implments.
22
II.4 ) Lutilisation de diagrammes

UML permet de dfinir et de visualiser un modle, l'aide de diagrammes.
II.4.1) Dfinition dun diagramme

Un diagramme UML est une reprsentation graphique, qui s'intresse un aspect prcis du modle. C'est une perspective du modle, pas "le modle". Chaque type de diagramme UML possde une structure (les types des lments de modlisation qui le composent sont prdfinis). Un type de diagramme UML vhicule une smantique prcise (un type de diagramme offre toujours la mme vue d'un systme). Combins, les diffrents types de diagrammes UML offrent une vue complte des aspects statiques et dynamiques d'un systme. Par extension et abus de langage, un diagramme UML est aussi un modle (un diagramme modlise un aspect du modle global).
II.4.2) caractristiques des diagrammes UML

Les diagrammes UML supportent l'abstraction. Leur niveau de dtail caractrise le niveau d'abstraction du modle. La structure des diagrammes UML et la notation graphique des lments de modlisation est normalise (document "UML notation guide"). Rappel : la smantique des lments de modlisation et de leur utilisation est dfinie par le mtamodle UML (document "UML semantics").
II.4.3) Les diffrents types de diagrammes UML

Il existe 2 types de vues du systme qui comportent chacune leurs propres diagrammes : - les vues statiques : o diagrammes de cas d'utilisation o diagrammes d'objets o diagrammes de classes o diagrammes de composants o diagrammes de dploiement - les vues dynamiques : o diagrammes de collaboration o diagrammes de squence o diagrammes d'tats-transitions o diagrammes d'activits
23
III) Les Diffrents types de diagrammes

III.1) Vues statiques du systme
Le but de la conceptualisation est de comprendre et structurer les besoins du client. : Il ne faut pas chercher l'exhaustivit, mais clarifier, filtrer et organiser les besoins. Une fois identifis et structurs, ces besoins : - dfinissent le contour du systme modliser (ils prcisent le but atteindre), - permettent d'identifier les fonctionnalits principales (critiques) du systme. Le modle conceptuel doit permettre une meilleure comprhension du systme. Le modle conceptuel doit servir d'interface entre tous les acteurs du projet. Les besoins des clients sont des lments de traabilit dans un processus intgrant UML. Le modle conceptuel joue un rle central, il est capital de bien le dfinir.
III.1.1) diagrammes de cas d'utilisation Dfinition du cas d'utilisation (use case)

Les use cases permettent de structurer les besoins des utilisateurs et les objectifs correspondants d'un systme. Ils centrent l'expression des exigences du systme sur ses utilisateurs : ils partent du principe que les objectifs du systme sont tous motivs. La dtermination et la comprhension des besoins sont souvent difficiles car les intervenants sont noys sous de trop grandes quantits d'informations : il faut clarifier et organiser les besoins des clients (les modliser). Pour cela, les cas dutilisation identifient les utilisateurs du systme (acteurs) et leurs interactions avec le systme. Ils permettent de classer les acteurs et structurer les objectifs du systme. Une fois identifis et structurs, ces besoins : dfinissent le contour du systme modliser (ils prcisent le but atteindre), permettent d'identifier les fonctionnalits principales (critiques) du systme. Les use cases ne doivent donc en aucun cas dcrire des solutions d'implmentation. Leur but est justement d'viter de tomber dans la drive d'une approche fonctionnelle, o l'on liste une litanie de fonctions que le systme doit raliser.
Elments de modlisation des cas d'utilisation Lacteur :

La premire tape de modlisation consiste dfinir le primtre du systme, dfinir le contour de lorganisation et le modliser. Toute entit qui est en dehors de cette organisation et qui interagit avec elle est appel acteur selon UML.
24
Un acteur est un type strotyp reprsentant une abstraction qui rside juste en dehors du systme modliser. Un acteur reprsente un rle jou par une personne ou une chose qui interagit avec le systme. (la mme personne physique peut donc tre reprsente par plusieurs acteurs en fonction des rles quelle joue). Pour identifier les acteurs, il faut donc se concentrer sur les rles jous par les entits extrieures au primtre. Dans UML, il ny a pas de notion dacteur interne et externe. Par dfinition, un acteur est externe au primtre de ltude, quil appartienne ou pas la socit. Enfin, un acteur nest pas ncessairement une personne physique : il peut tre un service, une socit, un systme informatique Il existe 4 catgories dacteurs : - les acteurs principaux : les personnes qui utilisent les fonctions principales du systme - les acteurs secondaires : les personnes qui effectuent des tches administratives ou de maintenance. - le matriel externe : les dispositifs matriels incontournables qui font partie du domaine de lapplication et qui doivent tre utiliss. - les autres systmes : les systmes avec lesquels le systme doit interagir.
Formalisme :
Nom acteur
Le cas dutilisation
Le cas dutilisation (ou use case) correspond un objectif du systme, motiv par un besoin dun ou plusieurs acteurs. L'ensemble des use cases dcrit les objectifs (le but) du systme.
25
Formalisme :
Nom d u use case
La relation
Elle exprime linteraction existant entre un acteur et un cas dutilisation. Formalisme :
retirer argent
Prospect
Il existe 3 types de relations entre cas dutilisation : - la relation de gnralisation - la relation dextension - la relation dinclusion
La relation de gnralisation
Dans une relation de gnralisation entre 2 cas dutilisation, le cas dutilisation enfant est une spcialisation du cas dutilisation parent. Formalisme et exemple :
cas d'utilisation parent
Virement bancaire
cas d'utilisation enfant
virement par internet
NB : un acteur peut galement participer des relations de gnralisation avec dautres acteurs. Les acteurs enfant seront alors capables de communiquer avec les mmes cas dutilisation que les acteurs parents .
26
Formalisme et exemple :
retirer argent
Prospect
obtenir informations compte Client agence
La relation dinclusion
Elle indique que le cas dutilisation source contient aussi le comportement dcrit dans le cas dutilisation destination. Linclusion a un caractre obligatoire, la source spcifiant quel endroit le cas dutilisation cible doit tre inclus. Cette relation permet ainsi de dcomposer des comportements et de dfinir des comportements partageables entre plusieurs cas dutilisation. Formalisme :
Virement
<<include>>
Identification
Pour raliser lobjectif virement , on utilise obligatoirement identification .
27
La relation dextension
Elle indique que le cas dutilisation source ajoute son comportement au cas dutilisation destination. Lextension peut tre soumise condition. Le comportement ajout est insr au niveau dun point dextension dfini dans le cas dutilisation destination. Cette relation permet de modliser les variantes de comportement dun cas dutilisation (selon les interactions des acteurs et lenvironnement du systme).
Formalisme :
Cas d'utilisation source
<<extend>>
Cas d'utilisation destination
Exemple :
Virement
<<extend>>
Vrification solde compte
Paquetage
Un paquetage (package) est un groupement dlment de modlisation. Un paquetage peut contenir aussi bien des paquetages embots que des lments de modlisation ordinaires. Le systme entier peut tre pens comme un unique paquetage de haut niveau comprenant lensemble. Tous les lments de modlisation dUML, y compris les diagrammes, peuvent tre organiss en paquetage. Les uses cases peuvent tre organiss en paquetages (packages).
28
Exemple de cas dutilisation
Virement Client local
<<extend>> <<include>> virement par internet
Identification
Vrification solde compte
Client distant
Les scnarios
Un cas dutilisation est une abstraction de plusieurs chemins dexcution. Une instance de cas dutilisation est appele : scnario . Chaque fois quune instance dun acteur dclenche un cas dutilisation, un scnario est cr (le cas dutilisation est instanci). Ce scnario suivra un chemin particulier dans le cas dutilisation. Un scnario ne contient pas de branche du type Si condition alors car pendant lexcution, la condition est soit vraie, soit fausse, mais elle aura une valeur. Aprs la description des cas dutilisation, il est ncessaire de slectionner un ensemble de scnarios qui vont servir piloter litration en cours de dveloppement. Le choix et le nombre de scnarios retenir est une tape difficile raliser : lexhaustivit est difficile, voire impossible atteindre. Le nombre dinstances pour un cas dutilisation peut tre trs important, voire infini. Les scnarios peuvent tre classs en : - scnarios principaux : il correspond linstance principal du cas dutilisation. Cest souvent le chemin normal dexcution du cas dutilisation qui nimplique pas derreurs. - Scnarios secondaires : il peut tre un cas alternatif (un choix), un cas exceptionnel ou une erreur. Les scnarios sont utiles pour : - analyser et concevoir le systme - justifier les choix effectus (ils serviront la documentation des cas dutilisation) - tester : les scnarios constituent le meilleur moyen de spcifier les tests.
29
Elaboration des cas d'utilisation

Un cas dutilisation doit tre avant tout simple, intelligible et dcrit de manire claire et concise. Le nombre dacteurs qui interagissent avec le cas dutilisation est souvent limit. Il y a souvent un acteur pas cas dutilisation. Lors de llaboration dun cas dutilisation, il faut se demander : - quelles sont les tches de lacteur ? - quelles informations lacteur doit-il crer, sauvegarder, modifier ou lire ? - lacteur devra-t-il informer le systme des changements externes ? - le systme devra-t-il informer lacteur des conditions internes ? - quelles sont les conditions de dmarrage et darrt du cas dutilisation ? Les cas dutilisation peuvent tre prsents travers de vues multiples : un acteur avec tous ses cas dutilisation, un cas dutilisation avec tous ses acteurs Un cas dutilisation est une abstraction : il dcrit de manire abstraite une famille de scnarios. Il ne faut donc pas raliser trop de cas dutilisation car cela constituerait un manque dabstraction. Dans nimporte quels systme, il y a relativement peu de cas dutilisation mais beaucoup de scnarios. Un grand nombre de cas dutilisation signifie par consquent que lessence du systme nest pas comprise.
Utilisation des cas d'utilisation

La porte des cas dutilisation dpasse largement la dfinition des besoins du systme. Les cas dutilisation interviennent tout au long du cycle de vie du projet, depuis le cahier des charges jusquaux tests. Intervenant Utilisateur Rle des cas Exprimer dutilisation Analyste Architecte Comprendre Concevoir Programmeur Testeur raliser vrifier
III.1.2) diagrammes de classes Dfinition du diagramme de classes

Le diagramme de classes exprime la structure statique du systme en termes de classes et de relations entre ces classes. Lintrt du diagramme de classe est de modliser les entits du systme dinformation. Le diagramme de classe permet de reprsenter lensemble des informations finalises qui sont gres par le domaine. Ces informations sont structures, cest--dire quelles ont regroupes dans des classes. Le diagramme met en vidence dventuelles relations entre ces classes. Le diagramme de classes comporte 6 concepts : - classe - attribut - identifiant - relation - opration - gnralisation / spcialisation
30
Les notions utilises par le diagramme de classes La notion de classe

Dfinition : une classe est une description abstraite (condense) dun ensemble dobjets du domaine de lapplication : elle dfinit leur structure, leur comportement et leurs relations. Reprsentation : les classes sont reprsentes par des rectangles compartiments : - le 1er compartiment reprsente le nom de la classe - le 2me compartiment reprsente les attributs de la classe - le 3me compartiment reprsente les oprations de la classe Formalisme :
NOM CLASSE Attribut_1 : int Attribut_2 : int Attribut_3 : int Operation_1 () : void Operation_2 () : void
Les compartiments dune classe peuvent tre supprims (en totalit ou en partie) lorsque leur contenu nest pas pertinent dans le contexte dun diagramme. La suppression des compartiments reste purement visuelle : elle ne signifie pas quil ny a pas dattribut ou dopration. Formalisme de reprsentation simplifie :
NOM CLASSE
Formalisme de reprsentation avec chemin complet :
nom paquetage :: NOM CLASSE
Le rectangle qui symbolise une classe peut contenir un strotype et des proprits. UML dfinit les strotypes de classe suivants : - classe implmentation : il sagit de limplmentation dune classe dans un langage de programmation - numration : il sagit dune classe qui dfinit un ensemble didentificateurs formant le domaine de la valeur. - mtaclasse : il sagit de la classe dune classe, comme en Smalltalk - powertype : une classe est un mtatype : ses instances sont toutes des soustypes dun type donn - processus : il sagit dune classe active qui reprsente un flot de contrles lourd - thread : il sagit dune classe active qui reprsente un flot de contrles lger - type : il sagit dune classe qui dfinit un domaine dobjets et les oprations applicables ces objets.
31
utilitaire : il sagit dune classe rduite au concept de module et qui ne peut tre instancie.
La notion dattribut
Dfinition : Une classe correspond un concept global dinformation et se compose dun ensemble dinformations lmentaires, appeles attributs de classe. Un attribut reprsente la modlisation dune information lmentaire reprsente par son nom et son format. Par commodit de gestion, on choisit parfois de conserver dans un attribut le rsultat dun calcul effectu partir dautres classes : on parle alors dattribut driv. Pour reprer un attribut driv : on place un / devant son nom. Formalisme :
NOM CLASSE Attribut_1 : int Attribut_2 : int Attribut_3 : int Operation_1 () : void Operation_2 () : void
Visibilit et porte des attributs : UML dfinit 3 niveaux de visibilit pour les attributs : 1- public (+) : llment est visible pour tous les clients de la classe 2- protg (#) : llment est visible pour les sous-classes de la classe 3- priv (-) : llment nest visible que par les objets de la classe dans laquelle il est dclar. Formalisme :
NO M CL A S S E + # A ttri b u t p u b l i c A ttri b u t p ro t g A ttri b u t p ri v : int : int : int
La notion didentifiant
Lidentifiant est un attribut particulier, qui permet de reprer de faon unique chaque objet, instance de la classe. Formalisme :
FACT URE + + + + No facture Date M ontant / M ontant T VA : : : : n doubl e doubl e n
32
La notion dopration
Dfinition : lopration reprsente un lment de comportement des objets, dfini de manire globale dans la classe. Une opration est une fonctionnalit assure par une classe. La description des oprations peut prciser les paramtres dentre et de sortie ainsi que les actions lmentaires excuter. Formalisme :
ERU TCAF n: erutcaf oN + e lbuod : etaD + e lbuod : t n at n o M + n : A V T t n at n o M / + d iov : )( ret idE d iov : )( ret lusnoC d iov : )( rerC
Visibilit et porte des oprations : Comme pour les attributs, on retrouve 3 niveaux de visibilit pour les oprations : 1- public (+) : lopration est visible pour tous les clients de la classe 2- protg (#) : lopration est visible pour les sous-classes de la classe 3- priv (-) : lopration nest visible que par les objets de la classe dans laquelle elle est dclare. Formalisme :
ERU TCAF tn i : erutcaf oN etaD : etaD e lbuod : tnatnoM e lbuod : AV T tnatnoM / )( euq i lbup pO )( egtorp pO )( ev irp pO + + + + + # -
La notion de relation
Sil existe des liens entre objets, cela se traduit ncessairement par des relations qui existent entre leurs classes respectives. Les liens entre les objets doivent tre considrs comme des instances de relations entre classes. Il existe plusieurs types de relations entre classes : - lassociation
33
la gnralisation/spcialisation la dpendance
Lassociation
Lassociation est la relation la plus courante et la plus riche du point de vue smantique. Une association est une relation statique n-aire (le plus souvent : elle est binaire) : cest-dire quelle relie plusieurs classes entre elles. Lassociation existe entre les classes et non entre les instances : elle est introduite pour montrer une structure et non pour montrer des changes de donnes. Une association n-aire possde n rles qui sont les points terminaux de lassociation ou terminaisons. Chaque classe qui participe lassociation joue un rle. Les rles sont dfinis par 2 proprits : - la multiplicit : elle dfinit le nombre dinstances de lassociation pour une instance de la classe. La multiplicit est dfinie par un nombre entier ou un intervalle de valeurs. La multiplicit est note sur le rle (elle est note lenvers de la notation MERISE). 1 0..1 N ou * M..N 0..* 1..* Un et un seul Zro ou un N (entier naturel) De M N (entiers naturels) De zros plusieurs De 1 plusieurs
Formalisme et exemple en employant les noms des rles et leur multiplicit :

S O C IE T E 0 ..1 e m p lo ye u r 0 ..* e m p lo y P E RSO NNE
Formalisme et exemple en employant le noms de lassociation et la multiplicit des rles :

S O C IE T E 0 ..1 e m p lo ye r 0 ..* P E RSO NNE
La multiplicit peut galement sexprimer par des symboles :
34
Les valeurs de multiplicit expriment les contraintes lies au domaine de lapplication. Il est donc important de dterminer les valeurs de multiplicit optimales pour trouver le bon quilibre entre complexit et efficacit. La surestimation des valeurs de multiplicit entrane un surcot de taille de stockage et en vitesse dexcution (requte avec plus de jointures). - la navigabilit La navigabilit na rien voir avec le sens de lecture de lassociation. Une navigabilit place sur une terminaison cible indique si ce rle est accessible partir de la source. Par dfaut les associations sont navigables dans les 2 sens. Dans certains cas, une seule direction de navigation est utile : lextrmit dassociation vers laquelle la navigation est possible porte alors une flche. Formalisme :
A B
Dans lexemple ci-dessus, les instances de A voient les instances de B mais les instances de B ne voient pas les instances de A. Les classes-association Les attributs dune classe dpendent fonctionnellement de lidentifiant de la classe. Parfois, un attribut dpend fonctionnellement de 2 identifiants, appartenant 2 classes diffrentes. Par exemple, lattribut quantit commande dpend fonctionnellement du numro de commande et du code produit. On va donc placer lattribut quantit commande dans lassociation comporter . Dans ce cas, lassociation est dite porteuse dattributs . Une association porteuse dattributs est appele classe-association.
Commande No commande
comporter
Produit Code produit
Qt commande
Exemple : Toute classe-association peut tre remplace par une classe intermdiaire et qui sert de pivot pour une paire dassociation. Exemple :
Commande No commande
0..* 1..1
Ligne commande
Quantit commande
0..* 1..1
Produit
Code produit
De mme, toute association (qui ne contient pas dattributs) impliquant 3 classes ou plus peut donner lieu une dcomposition avec une classe intermdiaire.
35
Lagrgation Dans UML, lagrgation nest pas un type de relation mais une variante de lassociation. Une agrgation reprsente une association non symtrique dans laquelle une des extrmits joue un rle prdominant par rapport lautre extrmit. Lagrgation ne peut concerner quun seul rle dune association. Lagrgation se reprsente toujours avec un petit losange du ct de lagrgat. Le choix dune association de type agrgation traduit la volont de renforcer la dpendance entre classes. Cest donc un type dassociation qui exprime un couplage plus fort entre les classes. Lagrgation permet de modliser des relations de type matre et esclaves. Lagrgation permet de modliser une contrainte dintgrit et de dsigner lagrgat comme contrainte. A travers une telle contrainte, il est possible de reprsenter par exemple : - la propagation des valeurs dattributs dune classe vers une autre classe - une action sur une classe qui implique une action sur une autre classe - une subordination des objets dune classe une autre classe Formalisme et exemple : TYPE
1..1
0..*
VEHICULE
Lexemple ci-dessus montre que lon veut grer une classification de vhicules. Chaque vhicule est classifi selon son type. En consquence, il sera possible de prendre connaissance pour un vhicule de lensemble des caractristiques du type de vhicule auquel il est associ. NB : un agrgat peut tre multiple. Dans lexemple ci-dessous, un vhicule peut appartenir plusieurs types.
TYPE 1..* 0..* VEHICULE
Cas particulier des associations rflexives : On peut avoir des cas dagrgation rflexive ds que lon modlise des relations hirarchiques ou des liens de parent par exemple.
PERSONNE 2 parent
* enfant
La composition La composition est un cas particulier de lagrgation dans laquelle la vie des composants est lie celle des agrgats. Elle fait souvent rfrence une contenance physique. Dans la composition lagrgat ne peut tre multiple. 36
La composition implique, en plus de lagrgation, une concidence des dures de vie des composants : la destruction de lagrgat (ou conteneur) implique automatiquement la destruction de tous les composants lis. Formalisme et exemple :
VEHICULE
1..*
1..*
1..1 CHASSIS
1..1 MOTEUR
La gnralisation / spcialisation
Le principe de gnralisation / spcialisation Le principe de gnralisation / spcialisation permet didentifier parmi les objets dune classe (gnrique) des sous-ensembles dobjets (des classes spcialises) ayant des dfinitions spcifiques. La classe plus spcifique (appele aussi classe fille, classe drive, classe spcialise, classe descendante ) est cohrente avec la classe plus gnrale (appele aussi classe mre, classe gnrale ), cest--dire quelle contient par hritage tous les attributs, les membres, les relations de la classe gnrale, et peut contenir dautres. Les relations de gnralisation peuvent tre dcouvertes de 2 manires : - la gnralisation : il sagit de prendre des classes existantes dj mises en vidences) et de crer de nouvelles classes qui regroupent leurs parties communes ; il faut aller du plus spcifique au plus gnral. - La spcialisation : il sagit de slectionner des classes existantes (dj identifies) et den driver des nouvelles classes plus spcialises, en spcifiant simplement les diffrences. Ces 2 dmarches, mme si elles sont fondamentalement diffrentes, mnent au mme rsultat, savoir la constitution dune hirarchie de classes relies par des relations de gnralisation. La relation de gnralisation est trs puissante car elle permet de construire simplement de nouvelles classes partir de classes existantes. Cependant, elle est trs contraignante dans le sens o elle dfinit une relation trs forte entre les classes. Ainsi, lvolution dune classe de base entrane une volution de toutes les classes qui en drivent. Cet effet boule de neige peut avoir des consquences aussi bien positives (quand cest leffet recherch) que ngatives.
37
Formalisme et exemple :
Instrum ent Code instrum ent date fabri cati on Nom i nstrum ent
A corde Nb de cordes
A percussi on Nb de percussi ons
A vent Nb de pistons
La spcialisation multiple Les classes peuvent avoir plusieurs superclasses ; dans ce cas, la gnralisation est dite multiple et plusieurs flches partent de la sous-classe vers les diffrentes superclasses. La gnralisation multiple consiste fusionner plusieurs classes en une seule classe. Formalisme et exemple :
Client Salari
Client spcial
Bnficie
Tarif prfrentiel
La classe client spcial est une spcialisation de client et de salari. Ce modle permet dindiquer que lon accorde des tarifs prfrentiels aux salaris. Les contraintes sur les associations Il existe plusieurs types de contraintes sur les associations :
38
- La contrainte de partition Elle indique que toutes les instances dune classe correspondent une et une seule instance des classes lies.
Socit
{partition}
Client Prospect
Toutes les socits sont soit clientes, soit considres comme des prospects. - la contrainte dexclusion Elle permet de prciser quune instance dassociation exclut une autre instance. Par exemple, un employ ne peut tre la fois directeur financier et directeur commercial.
Ici, un employ ne peut pas tre la fois directeur commercial et directeur financier. Mais tout employ nest pas directeur commercial ou directeur financier (contrainte de partition). - la contrainte de totalit Toutes les instances dune classe correspondent au moins une des instances des classes lies.
39
Socit
{Totalit}
Partenaire Client privilgi
Toute socit est au moins partenaire ou client privilgie. Et elle peut tre les 2 la fois. - la contrainte dinclusion Elle permet de prciser quune collection est incluse dans une autre collection. (la flche de la relation de dpendance indique le sens de la contrainte). Par exemple, on pourra indiquer que le contractant dun contrat fait obligatoirement partie des individus assurs. Exemple :
La dpendance
Les relations de dpendance sont utilises lorsquil existe une relation smantique entre plusieurs lments qui nest pas de nature structurelle. Une relation de dpendance dfinit une relation unidirectionnelle entre un lment source et un lment cible. Une dpendance est une relation entre deux lments de modlisation dans laquelle toute modification effectue sur un lment de modlisation (l'lment influent) affecte l'autre lment (lment dpendant). UML dfinit 4 types de relation de dpendance. Pour chaque type de dpendance, un mot cl ou strotype entre guillemets peut tre ajout la relation de dpendance pour prciser sa nature. Les 4 types de relation sont : - abstraction Il sagit dune relation de dpendance entre lments qui reprsentent un mme concept diffrents niveaux dabstraction ou selon des points de vue distincts.
40
Les mots-cls sont : o drive Reprsente un lment dfini ou calcul partir dun autre. Par exemple, un attribut ou un rle peut driver dautres attributs ou rles. o raffine Reprsente une relation de dpendance entre des lments smantiques diffrents (analyse et conception par exemple). o ralise Reprsente une relation de dpendance entre une spcification (cible) et llment qui implmente cette spcification (source) o trace Reprsente lhistorique des constructions prsentes dans les diffrents modles. - Liaison Les paramtres formels dune classe ou collaboration paramtrables doivent tre lis des valeurs. Cette dpendance cre une liaison entre la classe ou collaboration paramtrable (la cible) et la classe ou collaboration paramtre (source). o lie - Permission Un lment (source) a le droit daccder un espace de nommage (cible) o ami Reprsente un lment source (paquetage, classe, opration ) qui a accs llment destination (paquetage, classe, opration ) quelle que soit la spcification de visibilit de ce dernier. - Utilisation Un lment (source) requiert la prsence dun autre lment (cible) pour son bon fonctionnement ou son implmentation. o utilise o appelle Reprsente une relation de dpendance entre une opration qui invoque une opration dune autre classe. Cette relation est reprsente en connectant les oprations ou les classes qui possdent ces oprations. o cre Reprsente le classificateur source qui cre une instance du classificateur cible o instancie Reprsente une relation de dpendance entre classificateurs due la cration dune instance du classificateur cible par une opration du classificateur source.
41
Formalisme :
Classe A
<<derive>> Classe B
Linterface
Une interface dfinit le comportement visible dune classe. Ce comportement est dfini par une liste doprations ayant une visibilit public . Aucun attribut ou association nest dfini pour une interface. Une interface est en fait une classe particulire (avec le strotype interface ). UML reprsente les interfaces : - soit au moyen de petits cercles relis par un trait llment qui fournit les services dcrits par linterface - soit au moyen de classes avec le mot cl interface . Cette notation permet de faire figurer dans le compartiment des oprations la liste des services de linterface. Les relations possibles sur une interface sont : - la fourniture Cette relation spcifie quune classe donne fournit linterface ses clients : cest--dire que la classe possde cette interface. Une classe peut fournir plusieurs interfaces ses clients et chaque interface dfinit un des services de la classe. Cette technique permet de rduire la visibilit dune classe. En effet, une classe qui expose ses oprations publiques les expose toutes les autres classes du modle. Le concept dinterface permet une classe de dfinir plusieurs profils en permettant chaque classe de nutiliser que le profil qui lintresse. Une classe peut ainsi tre vue avec plusieurs perspectives diffrentes en fonction de la classe qui lutilise, ce qui augmente la rutilisabilit. - lutilisation Cette relation concerne toute classe client qui souhaite accder la classe interface de manire accder ses oprations. Cest une relation dutilisation standard. - la ralisation Cette relation nest utilise que pour les interfaces. Une ralisation est une relation entre une classe et une interface. Elle montre que la classe ralise les oprations offertes par l'interface.
42
Exemple et formalisme :
utilise Entreprise utilise Client utilise interface Assurance Banque Crdit
Lexemple ci-dessus illustre la modlisation de 2 interfaces crdit et assurance dune classe banque. Une relation de ralisation indique que la classe banque ralise linterface assurance.
Elaboration dun diagramme de classes Gnralits

Un diagramme de classes est une collection d'lments de modlisation statiques (classes, paquetages...), qui montre la structure d'un modle. Un diagramme de classes fait abstraction des aspects dynamiques et temporels. Pour un modle complexe, plusieurs diagrammes de classes complmentaires doivent tre construits. On peut par exemple se focaliser sur : - les classes qui participent un cas d'utilisation (cf. collaboration), - les classes associes dans la ralisation d'un scnario prcis, - les classes qui composent un paquetage, - la structure hirarchique d'un ensemble de classes. Pour reprsenter un contexte prcis, un diagramme de classes peut tre instanci en diagrammes d'objets.
Rgles dlaboration
Les rgles de normalisation des modles entit-relation, issues de lalgbre relationnelle, peuvent tre utilement appliques un modle de classes UML, mme si UML ne contient aucune prconisation sur ces rgles. Ces rgles aident conduire les travaux de modlisation en vitant le plus possible la redondance de linformation, tout en restant fidle aux rgles de gestion.
III.1.3) diagrammes d'objets

Le diagramme dobjets permet de mettre en vidence des liens entre les objets. Les objets, instances de classes, sont relis par des liens, instances dassociations. A lexception de la multiplicit, qui est explicitement indique, le diagramme dobjets utilise les mmes concepts que le diagramme de classes. Ils sont essentiellement utiliss pour comprendre ou illustrer des parties complexes dun diagramme de classes.
43
Exemple :
Salari : Dupont
1..1 Suprieur Salari Diriger
0..* Subordonn
Salari : Martin
Salari : Durand
III.1.4) diagrammes de composants

Les diagrammes de composants dcrivent les composants et leurs dpendances dans lenvironnement de ralisation. En gnral, ils ne sont utiliss que pour des systmes complexes. Un composant est une vue physique qui reprsente une partie implmentable dun systme. Un composant peut tre du code, un script, un fichier de commandes, un fichier de donnes, une table Il peut raliser un ensemble dinterfaces qui dfinissent alors le comportement offert dautres composants. Formalisme :
Fichier Consultation
Archivage
UML dfinit 5 strotypes aux composants : - document : un document quelconque - excutable : un programme qui peut sexcuter - fichier : un document contenant un code source ou des donnes - bibliothque : une bibliothque statique ou dynamique - table : une table de base de donnes relationnelle Pour montrer les instances des composants, un diagramme de dploiement peut tre utilis.
III.1.5) diagrammes de dploiement

Les diagrammes de dploiement montrent la disposition physique des diffrents matriels (les nuds) qui entrent dans la composition dun systme et la rpartition des instances de composants, processus et objets qui vivent sur ces matriels. Les diagrammes de dploiement sont donc trs utiles pour modliser larchitecture physique dun systme.
44
III.2) Vues dynamiques du systme :

Les cas dutilisation sont centrs sur les besoins des utilisateurs. Ils aident construire le bon systme. Les cas dutilisation ne fournissent pas pour autant la bonne manire de faire le systme., ni la forme de larchitecture logicielle : ils disent ce quun systme doit faire, non comment il doit le faire. La vue des cas dutilisation est une description fonctionnelle des besoins, structure par rapport des acteurs. Le passage lapproche objet seffectue en associant une collaboration chaque cas dutilisation. Une collaboration dcrit les objets du domaine, les connexions entre ces objets et les messages changs par les objets. Chaque scnario, instance du cas dutilisation ralis par la collaboration se reprsente par une interaction entre les objets dcrits dans le contexte de la collaboration.
III.2.1) diagrammes de collaboration Objectifs du diagramme de collaboration

Le diagramme de collaboration permet de mettre en vidence les interactions entre les diffrents objets du systme. Dans le cadre de lanalyse, il sera utilis - pour prciser le contexte dans lequel chaque objet volue - pour mettre en vidence les dpendances entre les diffrents objets impliqus dans lexcution dun processus ou dun cas dutilisation. Un diagramme de collaboration fait apparatre les interactions entre des objets et les messages quils changent.
Les interactions
Une interaction dfinit la communication entre les objets sous la forme dun ensemble partiellement ordonn de messages. Lobjet metteur envoie un message lobjet rcepteur. Les objets reprsents dans les diagrammes de collaboration ne sont pas ncessairement des instances dentits. Certains messages peuvent avoir pour origine des acteurs que lon pourra reprsenter. Formalisme : linteraction se reprsente par une flche avec un texte dcrivant le message. Exemple dinteraction entre objets :
: commande livraison faite : produit
Exemple dinteraction entre un objet et un acteur ;

calculer stock : produit
Grant
45
Les messages
Les messages sont le seul moyen de communication entre les objets. Ils sont dcrits essentiellement par lobjet metteur et lobjet rcepteur. Leur description peut tre complte par un nom, une squence, des arguments, un rsultat attendu, une synchronisation, une condition dmission. La squence permet de prciser lordre dmission des messages. Formalisme et exemple :
: produit
1 : demande devis 2 ; calcul prix
Client
4 : devis
Commercial
: catgorie client
3 : calcul ristourne
Le message 1 peut avoir comme arguments lintitul du produit souhait, la quantit et la catgorie du client. Certains messages peuvent solliciter un rsultat. Ce cas peut tre modliser de 2 faons : - un message de demande et un message de rponse - indiquer sur le premier message le rsultat attendu (lorsque le message en retour est attendu immdiatement). Exemple :
calculer stock : produit
Grant
2 : Valeur stock
Ou
Valeur stock= calculer stock : produit
Grant
Ici, le message mis par le grant implique la restitution immdiate du rsultat du calcul : la valeur du stock. Nb : lmission de message peut galement tre soumis une condition, qui sexprime alors sur le texte du message.
46
[qt < seuil] Demande approvisionnement : produit
Magasinier
Exemple : la demande de rapprovisionnement nest envoye au magasinier que lorsque la quantit en stock est infrieure au seuil de rapprovisionnement.
III.2.2) diagrammes de squence

Le diagramme de squence est une variante du diagramme de collaboration. Par opposition aux diagrammes de collaboration, les diagrammes de squence possdent intrinsquement une dimension temporelle mais ne reprsente pas explicitement les liens entre les objets. Ils privilgient ainsi la reprsentation temporelle la reprsentation spatiale et sont plus aptes modliser les aspects dynamiques du systme. En revanche, ils ne rendent pas compte du contexte des objets de manire explicite, comme les diagrammes de collaboration. Le diagramme de squence permet de visualiser les messages par une lecture de haut en bas. Laxe vertical reprsente le temps, laxe horizontal les objets qui collaborent. Une ligne verticale en pointill est attache chaque objet et reprsente sa dure de vie. Les messages sont reprsents comme dans le diagramme de collaboration. (NB : un message de retour sera reprsent avec des traits en pointills)
47
Exemple :
Produit Catgorie client
Client Demande devis
Commercial
Calcul prix
Calcul ristourne
Devis
Les interactions
Linteraction se traduit par lenvoi dun message entre objets. Le diagramme de squence insiste sur la chronologie des objets en utilisant la ligne de vie des objets.
Les activations
Les diagrammes de squence permettent de reprsenter les priodes dactivit des objets. Une priode dactivit correspond au temps pendant lequel un objet effectue une action, soit directement, soit par lintermdiaire dun autre objet qui lui sert de sous-traitant.
48
Formalisme : les priodes dactivit se reprsentent par des bandes rectangulaires places sur la ligne de vie des objets.
Les catgories de message

Les diagrammes de squence distinguent 3 catgories denvois de message : - flot de contrle plat Cette catgorie denvois est utilise pour indiquer le progression vers la prochaine tape dune squence. Formalisme : une flche simple symbolise de tels messages.
Un objet Objet 2 Objet_3
Message 1
Message 2
Alternativement, une demi-flche peut tre utilise pour reprsenter explicitement des messages asynchrones pour des systmes concurrents (la flche pleine correspond alors un message avec attente de prise en compte).
49
O bjet 1
Objet 2
M e ssa g e a syn ch ro n e
- appel de procdure (ou flot de contrle embot) Dans un contrle embot, la squence embote doit se terminer pour que la squence englobante reprenne le contrle. Un objet poursuit donc son excution une fois le comportement initi par le message termin. Formalisme : Des flches extrmits pleines symbolisent de tels messages.
Objet 1 Objet 2
Procdure
Lobjet 1 rcupre le contrle quand lobjet 2 a fini sa tche. - Retour de procdure Le retour de procdure est implicite la fin dune activation. Nanmoins, en cas denvois de messages asynchrones, il savre utile pour montrer la fin de lexcution dune sousprocdure et le renvoi ventuel de paramtres.
50
Obj et 1
Obj et 2
Procdure
Retour expl i ci te
Les messages rflexifs

Un objet peut senvoyer un message. Formalisme : Cette situation se reprsente par une flche qui revient en boucle sur la ligne de vie de lobjet.
Un objet
Un acteur
Message
message rflexif
autre mesage rflexif
51
Les contraintes temporelles

Une flche qui symbolise un message peut tre reprsente en oblique pour matrialiser les dlais de transmission non ngligeables par rapport la dynamique gnrale de lapplication.
Un objet
Un acteur
M essage
Des annotations temporelles concernent les messages peuvent galement tre ajoutes. Exemple :
Un objet
Un acteur
M essage 1
Dl ai < 9 secondes M essage 2
La ligne de vie
La ligne de vie des objets est reprsente par une ligne verticale en traits pointills, place sous le symbole de lobjet concern. Cette ligne de vie prcise lexistence de lobjet concern durant un certain laps de temps. En gnral, une ligne de vie est reprsente sur toute la hauteur du diagramme de squence. Par contre, elle peut dbuter et sinterrompre lintrieur du diagramme. Formalisme : la cration se reprsente en faisant pointer le message de cration sur le rectangle qui symbolise lobjet cr. La destruction est indique par la fin de la ligne de vie et par une croix (X), soit la hauteur du message qui cause la destruction, soit aprs le dernier message envoy par un objet qui se suicide.
52
Un objet
Crer
Un autre objet
Dtruire
Un o b j e t
Cr e r
Un a u tre o b j e t
M e ssa g e d e re to u r a ve c a uto d e stru ctio n
Pour reprsenter la collaboration entre les objets, on dispose donc dans UML de 2 diagrammes (collaboration et squence). On peut utiliser lun ou lautre, voire les 2. On peut ainsi dcrire lensemble des interactions avec des messages complets (nom, squence, rsultat attendu, synchronisation et condition dmission) sur un diagramme de collaboration et complter cette description par des diagrammes de squence ne visualisant que les noms des messages.
53
III.2.3) diagrammes d'tats-transitions

Ils ont pour rle de reprsenter les traitements (oprations) qui vont grer le domaine tudi. Ils dfinissent l'enchanement des tats de classe et font donc apparatre l'ordonnancement des travaux. Le diagramme d'tats-transition est associ une classe pour laquelle on gre diffrents tats : il permet de reprsenter tous les tats possibles ainsi que les vnements qui provoquent les changements d'tat.
Caractristiques et rgles de construction Etat

Un tat correspond une situation durable dans laquelle se trouvent les objets d'une classe. On lui associe les rgles de gestion et les activits particulires. Etat : objets d'une classe + rgles de gestion + changements d'tats La reprsentation symbolique des tats d'une classe d'objets est la suivante (rectangle aux bords arrondis) : Etat 1 Exemple pour une commande : Etat "en prparation" Etat "en cours" Etat 2
Evnements et transitions
Un objet passe d'un tat un autre suite un vnement, certains vnements pouvant ne pas provoquer de changement d'tat. Une transition est une relation entre 2 tats. Elle est oriente ce qui signifie que l'tat 2 est possible si certains vnements sont vrifis. Sa reprsentation symbolique est une flche sur laquelle est annot l'vnement qui concourt au changement d'tat. Evnement Etat 1 Etat 2
Exemple : Une commande passera dans l'tat "En attente" ds lors qu'elle aura t expdie Expdition
En prparation
En attente
La transition peut tre soumise la vrification d'une expression appele "expression de garde" note ainsi :
54
Evnement [garde] Etat 1 Etat 2
Exemple : La commande n'est expdie que si la commande comporte au moins 3 produits.

Expdition [nb_produits_commands > 2 ]
En prparation
En attente
Les traitements
Les oprations de description des classes sont dcrites dans le diagramme d'tatstransitions sous forme d'actions et d'activits. Une action est une opration lmentaire et instantane. Elle peut tre associe l'vnement lui-mme ou l'entre dans l'tat ou la sortie de l'tat Une activit est une opration qui dure et qui est donc associe un tat. Elle peut tre squentielle ou cyclique : - La fin d'une activit squentielle correspond la sortie de l'tat : une transition automatique est gnre. - une activit cyclique ne se termine que par une transition de sortie identifie. Exemple de formalisme sur une commande "en prparation" : En prparation Entry : -choix fournisseur Etat
Action d'entre Evnement : action
Evts : -nouveau tarif : revalorisation
Do : - prparation de la commande
Activit
Exit : - enregistrer la date d'expdition - envoi au fournisseur Expdition
Action de sortie
Evnement
La hirarchie des tats

Pour faciliter la comprhension de traitements complexes, il est possible de crer des supertats qui contiendront des actions et activits communes d'autres tats (sous-tats).
Les tats prdfinis

Deux tats sont prdfinis : 55
- l'tat initial d'un objet : il est obligatoire et unique - l'tat final : selon les vnements, il peut exister plusieurs tats finaux Leurs symbolismes sont les suivants : Crer Etat initial Etat 1 activit 1 Etat 2 activit 2 Dtruire Etat final
III.2.4) diagrammes d'activits

Le diagramme d'activit est attach une catgorie de classe et dcrit le droulement des activits de cette catgorie. Le droulement s'appelle "flot de contrle". Il indique la part prise par chaque objet dans l'excution d'un travail. Il sera enrichi par les conditions de squencement. Il pourra comporter des synchronisations pour reprsenter les droulements parallles. La notion de couloir d'activit va dcrire les responsabilits en rpartissant les activits entre les diffrents acteurs oprationnels.
Le droulement squentiel des activits

Le diagramme d'tats-transitions vu prcdemment prsente dj un squencement des activits d'une classe. Crer Etat initial Etat 1 activit 1 Etat 2 activit 2 Dtruire Etat final
Le diagramme d'activits va modifier cette reprsentation pour n'en conserver que le squencement. La notion d'tat disparat. On obtient ce graphe : Activit 1 Activit 2
Comme dans le diagramme d'tats-transitions, la transaction peut tre complte par une condition de garde. Activit 1
[condition]
Activit 2
La synchronisation
Les flots de contrle parallles sont spars ou runis par des barres de synchronisation. Les activits 2 et 3 seront simultanes.
56
Activit 1
Activit 2
Activit 3
Les couloirs d'activits

Le diagramme d'activits fait intervenir les acteurs de chaque activit. Chaque activit sera place dans une colonne (couloir) qui correspond l'acteur. Acteur 1 Acteur 2
Activit 1
Activit 2
57
IV) Le processus unifi

Le processus unifi est un processus de dveloppement logiciel : il regroupe les activits mener pour transformer les besoins dun utilisateur en systme logiciel. Caractristiques essentielles du processus unifi : - Le processus unifi est base de composants, - Le processus unifi utilise le langage UML (ensemble d'outils et de diagramme), - Le processus unifi est pilot par les cas dutilisation, - Centr sur larchitecture, - Itratif et incrmental.
IV.1) Le processus unifi est pilot par les cas dutilisation IV.1.1) Prsentation gnrale
Lobjectif principal dun systme logiciel est de rendre service ses utilisateurs ; il faut par consquent bien comprendre les dsirs et les besoins des futurs utilisateurs. Le processus de dveloppement sera donc centr sur l'utilisateur. Le terme utilisateur ne dsigne pas seulement les utilisateurs humains mais galement les autres systmes. Lutilisateur reprsente donc une personne ou une chose dialoguant avec le systme en cours de dveloppement. Ce type dinteraction est appel cas dutilisation. Les cas dutilisation font apparatre les besoins fonctionnels et leur ensemble constitue le modle des cas dutilisation qui dcrit les fonctionnalits compltes du systme. Nous ne sommes pas dans une approche de type fonctionnelle mais une approche pilote par des cas d'utilisation.
IV.1.2) Stratgie des cas dutilisation

Les cas dutilisation ne sont pas un simple outil de spcification des besoins du systme. Ils vont compltement guider le processus de dveloppement travers lutilisation de modles bass sur lutilisation du langage UML.
58
A partir du modle des cas dutilisation, les dveloppeurs crent une srie de modles de conception et dimplmentation ralisant les cas dutilisation. Chacun des modles successifs est ensuite rvis pour en contrler la conformit par rapport au modle des cas dutilisation. Enfin, les testeurs testent limplmentation pour sassurer que les composants du modle dimplmentation mettent correctement en uvre les cas dutilisation.
Les cas dutilisation garantissent la cohrence du processus de dveloppement du systme. Sil est vrai que les cas dutilisation guident le processus de dveloppement, ils ne sont pas slectionns de faon isole, mais doivent absolument tre dvelopps "en tandem" avec larchitecture du systme.
59
IV.2) Le processus unifi est centr sur larchitecture

Ds le dmarrage du processus, on aura une vue sur l'architecture mettre en place. Larchitecture dun systme logiciel peut tre dcrite comme les diffrentes vues du systme qui doit tre construit. Larchitecture logicielle quivaut aux aspects statiques et dynamiques les plus significatifs du systme. Larchitecture merge des besoins de lentreprise, tels quils sont exprims par les utilisateurs et autres intervenants et tels quils sont reflts par les cas dutilisation. Elle subit galement linfluence dautres facteurs : - la plate-forme sur laquelle devra sexcuter le systme ; - les briques de bases rutilisables disponibles pour le dveloppement ; - les considrations de dploiement, les systmes existants et les besoins non fonctionnels (performance, fiabilit..)
IV.2.1) Liens entre cas dutilisation et architecture

Tout produit est la fois forme et fonction. Les cas dutilisation doivent une fois raliss, trouver leur place dans larchitecture. Larchitecture doit prvoir la ralisation de tous les cas dutilisation. Larchitecture et les cas dutilisation doivent voluer de faon concomitante.
IV.2.2) Marche suivre

Larchitecte cre une bauche grossire de larchitecture, en partant de laspect qui nest pas propre aux cas dutilisation (plate forme..). Bien que cette partie de larchitecture soit indpendante des cas dutilisation. Larchitecte doit avoir une comprhension globale de ceux ci avant den esquisser larchitecture. Il travaille ensuite, sur un sous ensemble des cas dutilisation identifis, ceux qui reprsentent les fonctions essentielles du systme en cours de dveloppement. Larchitecture se dvoile peu peu, au rythme de la spcification et de la maturation des cas dutilisation, qui favorisent, leur tour, le dveloppement dun nombre croissant de cas dutilisation. Ce processus se poursuit jusqu ce que larchitecture soit juge stable.
60
IV.3) Le processus unifi est itratif et incrmental

Le dveloppement dun produit logiciel destin la commercialisation est une vaste entreprise qui peut stendre sur plusieurs mois. On ne va pas tout dvelopper dun coup. On peut dcouper le travail en plusieurs parties qui sont autant de mini projets. Chacun dentre eux reprsentant une itration qui donne lieu un incrment. Une itration dsigne la succession des tapes de lenchanement dactivits, tandis quun incrment correspond une avance dans les diffrents stades de dveloppement. Le choix de ce qui doit tre implment au cours dune itration repose sur deux facteurs : Une itration prend en compte un certain nombre de cas dutilisation qui ensemble, amliorent lutilisabilit du produit un certain stade de dveloppement. Litration traite en priorit les risques majeurs. Un incrment constitue souvent un additif. A chaque itration, les dveloppeurs identifient et spcifient les cas dutilisations pertinents, crent une conception en se laissant guider par larchitecture choisie, implmentent cette conception sous forme de composants et vrifie que ceux ci sont conformes aux cas dutilisation. Ds quune itration rpond aux objectifs fixs le dveloppement passe litration suivante. Pour rentabiliser le dveloppement il faut slectionner les itrations ncessaires pour atteindre les objectifs du projet. Ces itrations devront se succder dans un ordre logique. Un projet russi suivra un droulement direct, tabli ds le dbut par les dveloppeurs et dont ils ne sloigneront que de faon trs marginale. Llimination des problmes imprvus fait partie des objectifs de rduction des risques. Avantages dun processus itratif contrl Permet de limiter les cots, en termes de risques, aux strictes dpenses lies une itration. Permet de limiter les risques de retard de mise sur le march du produit dvelopp (identification des problmes ds les premiers stades de dveloppement et non en phase de test comme avec lapproche classique ). Permet dacclrer le rythme de dveloppement grce des objectifs clairs et court terme. Permet de prendre en compte le fait que les besoins des utilisateurs et les exigences correspondantes ne peuvent tre intgralement dfinis lavance et se dgagent peu peu des itrations successives Larchitecture fournit la structure qui servira de cadre au travail effectu au cours des itrations, tandis que les cas dutilisation dfinissent les objectifs et orientent le travail de chaque itration. Il ne faut donc pas msestimer lun des trois concepts.
61
IV.4) Le cycle de vie du processus unifi

Le processus unifi rpte un certain nombre de fois une srie de cycles. Tout cycle se conclut par la livraison dune version du produit aux clients et sarticule en 4 phases : cration, laboration, construction et transition, chacune dentre elles se subdivisant son tour en itrations. Chaque cycle se traduit par une nouvelle version du systme. Ce produit se compose dun corps de code source rparti sur plusieurs composants pouvant tre compils et excuts et saccompagne de manuels et de produits associs. Pour mener efficacement le cycle, les dveloppeurs ont besoin de construire toutes les reprsentations du produit logiciel : Modle des cas dutilisation Modle danalyse Expose les cas dutilisation et leurs relations avec les utilisateurs Dtaille les cas dutilisation et procde une premire rpartition du comportement du systme entre divers objets Dfinit la structure statique du systme sous forme de sous systme, classes et interfaces ; Dfinit les cas dutilisation raliss sous forme de collaborations entre les sous systmes les classes et les interfaces Intgre les composants (code source) et la correspondance entre les classes et les composants Dfinit les nuds physiques des ordinateurs et laffectation de ces composants sur ces nuds. Dcrit les cas de test vrifiant les cas dutilisation Description de larchitecture
Modle de conception
Modle dimplmentation Modle de dploiement Modle de test Reprsentation de larchitecture
Tous ces modles sont lis. Ensemble, ils reprsentent le systme comme un tout. Les lments de chacun des modles prsentent des dpendances de traabilit ; ce qui facilite la comprhension et les modifications ultrieures.
62
Prsentation du cycle de vie de UP
Phase
Phase de cration
Phase dlaboration
Phase de construction
Phase de transition
Description et Enchanement dactivits Traduit une ide en vision de produit fini et prsente une tude de rentabilit pour ce produit - Que va faire le systme pour les utilisateurs ? - A quoi peut ressembler larchitecture dun tel systme ? - Quels sont lorganisation et les cots du dveloppement de ce produit ? On fait apparatre les principaux cas dutilisation. Larchitecture est provisoire, identification des risques majeurs et planification de la phase dlaboration. Permet de prciser la plupart des cas dutilisation et de concevoir larchitecture du systme. Larchitecture doit tre exprime sous forme de vue de chacun des modles. Emergence dune architecture de rfrence. A lissue de cette phase, le chef de projet doit tre en mesure de prvoir les activits et destimer les ressources ncessaires lachvement du projet. Moment o lon construit le produit. Larchitecture de rfrence se mtamorphose en produit complet, elle est maintenant stable. Le produit contient tous les cas dutilisation que les chefs de projet, en accord avec les utilisateurs ont dcid de mettre au point pour cette version. Celle ci doit encore avoir des anomalies qui peuvent tre en partie rsolue lors de la phase de transition. Le produit est en version bta. Un groupe dutilisateurs essaye le produit et dtecte les anomalies et dfauts. Cette phase suppose des activits comme la fabrication, la 63
formation des utilisateurs clients, la mise en uvre dun service dassistance et la correction des anomalies constates.(o le report de leur correction la version suivante)
IV.5) Conclusion : un processus intgr

Le processus unifi est bas sur des composants. Il utilise UML et est bas sur les cas dutilisation, larchitecture et le dveloppement incrmental. Pour mettre en pratique ces ides il faut recourir un processus multi-facettes prenant en considration les cycles, les phases, les enchanements dactivits, la rduction des risques, le contrle qualit, la gestion de projet et la gestion de configuration. Le processus unifi a mis en place un cadre gnral (framework) intgrant chacune de ces facettes.
64
V) Elments de comparaisons entre MERISE et UML

Il ne sagit pas ici dlire une mthode ou un langage numro 1 (UML nest pas le remplaant de MERISE) mais dessayer de comprendre quels sont les apports de ces 2 dmarches et en quoi elles peuvent tres complmentaires. Il conviendra ensuite au lecteur dadapter leur utilisation (qui peut tre combine) en fonction du problme explorer. Reprenons pour cela les principaux points cl de MERISE que nous comparerons un par un ceux dUML : - les principes - la modlisation du mtier - la dmarche
V.1) Les principes

MERISE repose sur 5 principes fondamentaux : - lapproche systmique - les cycles de construction du systme dinformation - lapproche fonctionnelle - la sparation donnes-traitements - approche qui part du gnral vers le particulier
V.1.1) Lapproche systmique

MERISE trouve ses fondements dans la thorie systmique qui dcoupe lentreprise ne 3 sous-systmes : - le systme de dcision - le systme dinformation - le systme oprant Tout systme tudi ne doit pas ltre de faon tenir compte du systme complet dans lequel il volue. Dans UML, lapproche par les cas dutilisation constitue de ce fait une approche systmique. Le systme tudi est considr comme une bote noire qui ragit des sollicitations extrieurs qui sont formalises par des flches et dont lorigine est lacteur. Les cas dutilisation traduisent ainsi la structure du systme modliser . La structure interne du systme (compose dobjets)est modlise par les diagrammes de collaboration.
V.1.2) Les cycles de construction du systme dinformation

MERISE est une dmarche qui repose sur 3 cycles : - le cycle de vie - le cycle dabstraction - le cycle de dcision
65
Le cycle de vie
Dans la mthode Merise on distingue diffrentes priodes qui vont de la conception du systme d'information sa maintenance. On se situe dans une situation dynamique en considrant que le systme d'information va natre, grandir, tre entretenu puis va disparatre et tre remplac par un autre. UML ne dfinit pas de cycle de vie. Le cycle de dveloppement sous-jacent est itratif et incrmental, guid par les cas dutilisation et centr sur larchitecture.
Le cycle dabstraction
Dans MERISE, ce cycle permet disoler un niveau spcifique, les lments significatifs contribuant la description du systme dinformation. Les niveaux conceptuel, logique ou organisationnel, physique ou oprationnel se situent dans ce cycle. UML offre plusieurs diagrammes pour modliser le systme aux diffrents niveaux dabstraction (diagramme de squences, de classes ). Mais la diffrence de MERISE, il ny a pas de diagramme spcifique par niveau dabstraction. Le formalisme UML est le mme tout au long du processus de fabrication. UML laisse le soin de prsenter les diagrammes cohrents qui contiennent des objets de mme niveau de proccupation.
Le cycle de dcision
Il concerne les diffrentes dcisions et choix qui sont effectus tout au long du cycle de vie, et permettent de faire valider petit petit le systme que l'on est en train de construire. Ces dcisions marquent la fin d'une tape et le dbut d'une autre, ce sont des passages obligs avant de poursuivre l'tude du projet. Ces tapes de validation sont fondamentales dans MERISE et permettent l'appropriation du systme d'information par lensemble de la communaut. UML, tout comme MERISE, se soucie dassocier troitement les utilisateurs dans les tches danalyse et de conception (notamment au niveau des cas dutilisation).
V.1.3) Lapproche fonctionnelle

MERISE propose une approche descendante o le systme rel est dcompos en activits, elles-mmes dclines en fonctions. Les fonctions sont composes de rgles de gestion, elles-mmes regroupes en oprations. Ces rgles de gestion au niveau conceptuel gnrent des modules dcomposs en module plus simple et ainsi de suite jusqu obtenir des modules lmentaires. Ceci correspond bien aux langages de programmation structure mais la rutilisation des modules prsente des difficults. En effet, les modules sont difficilement extensibles et exploitables pour de nouveaux systmes. A ce niveau, UML se dmarque fortement de MERISE en proposant une architecture qui rend le systme le plus indpendant possible des besoins, o les classes donnent naissance des composants rutilisables dans diffrents contextes de besoins. Le degr de rutilisabilit est donc plus fort dans UML mais ncessite un plus haut niveau dabstraction.
66
V.1.4) La sparation donnes-traitements

Tout au long de sa dmarche, la mthode MERISE est caractrise par les approches conjointes et parallles des donnes et des traitements, approches qui se traduisent par des modles spcifiques. Les modles de donnes rendent compte de laspect statique du systme alors que les modles de traitement rendent compte des aspects dynamiques. UML, tout comme MERISE, traite des donnes et des traitements. Mais au lieu de les sparer, elle les associe. Elle repose en effet sur une vritable approche objet qui intgre donnes et traitements.
V.1.5) Lapproche qui part du gnral vers le particulier

MERISE reposant sur une dmarche fonctionnelle : elle applique une mthode de type descendante : la vision globale du systme doit tre affine par intgrations successives des diffrentes orientations retenues. UML permet aussi bien une approche descendante quune approche ascendante. Les diffrents diagrammes fournissent les supports pour matrialiser une dmarche progressive, allant du global vers le dtaill. Lavantage dUML rside dans le fait que le concept dobjet peut tre dclin sur tout le cycle dabstraction, ce qui facilite une analyse ascendante.
V.2) La modlisation mtier

Pour dcrire le mtier de lentreprise, MERISE sappuie sur les concepts de : - domaine - acteur - flux - modles conceptuels et organisationnels.
V.2.1) Le domaine
Une des premires tapes dans MERISE consiste dlimiter le domaine de ltude. Le domaine regroupe lensemble des processus contenus dans le systme tudier. Il est trs important car il sert fixer les limites du cadre de ltude. On retrouve dans UML la mme importance dfinir le domaine dtude. De la dfinition fiable et stable du domaine dtude dpend en effet le choix des cas dutilisation, des acteurs
V.2.2) Lacteur
Dans MERISE, le concept dacteur apparat trs tt dans la conception du systme dinformation (ex : modle de flux). MERISE distingue 2 types dacteurs : des acteurs internes et externes. Les acteurs externes sont des acteurs qui nappartiennent pas au domaine dfini. Lacteur externe nappartenant pas au champ dtude, seules ses principales caractristiques sont dcrites. Pour UML, le concept dacteur signifie de fait acteur externe.
67
La diffrence avec MERISE rside dans le fait que les acteurs sont analyss du point de vue du rle quils jouent vis--vis du systme (la mme personne peut jouer plusieurs rles).
V.2.3) Les flux

La modlisation des flux tient une place importante dans MERISE et se retrouve tout au long du processus de modlisation des traitements : du diagramme de flux trs gnral visant dcrire le domaine au modle organisationnel des traitements (MOT) qui dcrit les processus en dtails. MERISE adopte ici aussi une approche descendante qui part du gnral vers le particulier. Dans UML, le diagramme des cas dutilisation est une reprsentation externe qui montre les liens de haut niveau sans reprsenter le dtail des changes. Au niveau interne, les diagrammes de squence et les diagrammes dactivits permettent de reprsenter les flux. La diffrence essentielle dans la modlisation des flux entre MERISE et UML provient de la faon daborder les processus : on les dcoupe par fonctions dans MERISE et on les aborde par les rles jous par les acteurs dans UML.
V.2.4) Les modles conceptuels et organisationnels Les modles conceptuels Le modle conceptuel des donnes
Dans MERISE, le MCD est la reprsentation de l'ensemble des donnes mmorisables du domaine sans tenir compte des aspects techniques de stockage ni se rfrer aux conditions d'utilisation par tel ou tel traitement. Pour laborer un MCD, MERISE sappuie sur les concepts suivants : - proprit - entit - association
Le concept de proprit
La proprit est la modlisation de l'information lmentaire. C'est un ensemble de donnes ayant la mme structure et reprsentant des informations analogues. La modlisation des proprits doit viter les synonymes et les polysmes. Il ny a pas de diffrence ce niveau entre MERISE et UML. Les attributs des objets sont comparables aux proprits des entits. UML possde simplement un formalisme spcifique pour les informations calcules (cf. attribut driv) alors quelles sont fortement dconseilles dans MERISE et quelles ninterviennent que dans le MPD (modle physique des donnes) aprs dgradation.
Le concept dentit
L'entit est un groupe de proprits permettant de modliser un ensemble d'objets de mme nature. Dans UML, la notion dentit correspond la composante statique de la notion de classe dans le diagramme des classes. La notion de classe est toutefois plus large que la notion dentit : elle contient en effet des oprations qui ne sont pas modlises dans MERISE. Les classes ont un comportement qui rsulte de lanalyse de leurs responsabilits, offrent des services qui sont raliss par des J.STEFFE ENITA de Bordeaux 68
mthodes et des oprations ; les instances communiquent grce des messages. Autant de notions inconnues dans MERISE. De plus, les classes ne sont pas utilises uniquement pour modliser les objets mtier, elles servent aussi modliser les objets techniques. Le diagramme des classes dUML est donc plus riche que le MCD de MERISE : on peut transformer un MCD en diagramme de classes mais linverse nest pas possible. Ceci reflte la diffrence fondamentale entre UML et MERISE : UML intgre lobjet et associe donc au sein du mme concept des aspects statiques et dynamiques. Cette diffrence se traduit par la modlisation des oprations dans les classes mais galement par la porte de la modlisation : linverse de MERISE, les objets ne se limitent pas la modlisation du processus mtier. Les classes dUML respecteront par consquent les mmes rgles de normalisation que dans MERISE mais sont cres dans une optique diffrente des entits. Quant au formalisme, il ny a pas de diffrence notoire entre MERISE et UML. NB : la porte des attributs (public, protg, ou priv) apparaissent dans MERISE 2 au niveau du modle organisationnel des donnes.
Le concept dassociation
Une association modlise un ensemble de liens de mme nature entre deux ou plusieurs occurrences d'entits. On ne note pas de diffrence flagrantes entre MERISE et UML ce niveau. Les diffrences se situent essentiellement au niveau du formalisme des cardinalits par exemple (sens de lecture invers par exemple ), ou de la description de lassociation (description des 2 rles en UML). Les associations de MERISE qui contiennent des proprits se traduisent en UML par des classes-associations. Quant au concept de gnralisation / spcialisation et la notion dhritage qui en dcoule, on le retrouve galement dans MERISE 2, tout comme la modlisation des contraintes (partition, exclusion, totalit ..) Il faut noter quUML exprime certaines notions (comme lagrgation ou la composition) avec un symbolisme particulier qui nest pas prsent dans MERISE.
La normalisation du modle
La normalisation est un ensemble de rgles introduites lorigine dans le modle relationnel. Elles ont pour objectif de garantir la cohrence de la base de donnes lors des diffrentes manipulations (insertion, mise jour, suppression). Transposes au modle conceptuel des donnes, elles permettent de rapprocher le formalisme entit-association de MERISE, du modle relationnel. MERISE propose ainsi des rgles de validation : - pertinence - identification - vrification - unicit - homognit
69
Ensuite, le modle doit respecter au moins les 3 premires formes normales. Cette normalisation a fait la force de MERISE pour modliser les donnes. A la diffrence de MERISE, UML ne se proccupe pas de normalisation. Rien nempche toutefois dappliquer les rgles de normalisation prconises dans MERISE au diagramme de clases.
Le modle conceptuel des traitements

Dans MERISE, le modle conceptuel des traitements (MCT) a pour objectif de reprsenter les activits exerces par le domaine. Il exprime ce que fait le domaine et non, o, comment, quand et par qui, ces activits sont ralises (cette modlisation est ralise au niveau organisationnel). A ce stade, on fait abstraction de lorganisation du domaine. Le MCT repose sur plusieurs concepts - les vnements - les oprations - la synchronisation
Les vnements
MERISE distingue deux types dvnement : - des vnements dclencheurs provoquant une opration - des vnements rsultats produits par une opration suite une rgle dmission Dans UML, les concepts de flux assez similaires. Seul le mode de reprsentation diffre (cf. diagramme de squences).
Les oprations
Une opration dcrit le comportement du domaine et de son systme dinformation face un ou plusieurs vnements. Une opration est dclenche par la survenance dun vnement, ou de plusieurs vnements synchroniss. Elle comprend lensemble des activits que le domaine peut effectuer partir des informations fournies par lvnement, et de celles dj connues dans la mmoire du systme dinformation. Dans UML, les oprations sont reprsentes dans des diagrammes dactivits. Les activits sont hirarchiques et donc se dcrivent elles-mmes par des activits.
La synchronisation
La synchronisation est une condition pralable au dmarrage dune opration. Elle se traduit par une opration logique. Dans UML, les synchronisations peuvent apparatre dans les diagrammes dactivits et dtats-transition.
Les modles organisationnels Le modle organisationnel des traitements

Le MCT permet de dcrire les fonctions sans rfrence aux ressources pour en assurer le fonctionnement. Le modle organisationnel des traitements dcrit la manire dont ces fonctions sont matriellement assures.
70
Dans UML, les aspects dynamiques de lorganisation sont tudis par les diagrammes de squence et les diagrammes dactivits. Le diagramme dactivits permet de visualiser le squencement des tches en les attribuant aux travailleurs dinterface et de contrle. Les changes et les contrles apparaissent de faon claire. Ainsi, lenchanement des tches dans le MOT trouve son quivalent dans le diagramme dactivits. Le diagramme de squences apporte par contre une dimension supplmentaire par apport au MOT en faisant apparatre les objets entits. Toutefois, on retrouve galement ce lien dans MERISE 2 au travers du MOTA (Modle organisationnel des traitements analytique).
Le modle organisationnel des donnes

Le MOD utilise le mme formalisme et les mmes concepts que le MCD. Les caractristiques de chaque donne sont enrichies par des notions de confidentialit, de scurit, de besoin dhistorique. On distingue les donnes prives, protges et partages. On retrouve ces notions dans UML, notamment au niveau du diagramme de classes.
V.3) La dmarche
Deux points seront abords pour comparer les dmarches utilises dans MERISE et UML : - les modles - les tapes du processus dlaboration du systme dinformation
V.3.1) Les modles utiliss

MERISE utilise diffrents types de modle en fonction du niveau dabstraction et de la nature de lobjet tudi (donnes ou traitements) et se fonde avant tout sur une analyse fonctionnelle descendante UML propose une approche en 2 temps : - la couche mtier se rapproche des niveaux conceptuel et organisationnel - la couche ressource de rapproche des niveaux logique et physique Les diagrammes de la couche mtier sont complts dans la couche ressource sans changement de formalisme. Il existe des quivalences entre les modles MERISE et les modles UML. Le diagramme de cas dutilisation ne montre que les acteurs, les cas dutilisation et leur relation : il ne matrialise pas les flux et les changes. Il ne faut donc pas le confondre avec le diagramme des flux. Le diagramme de classes et le diagramme dobjets sont proches des MCD et MOD. Les diffrences fondamentales rsident dans lintgration des mthodes dans les classes et les objets. De plus, le diagramme des classes ne se limite pas aux seules entits mtier comme le MCD et contient galement des paquetages et des interfaces. Le diagramme de collaboration na pas dquivalence Le diagramme dtats-transitions na pas dquivalence dans MERISE. Il sapparente au CVO (cycle de vie des entits et objets) dans MERISE 2
71
Le diagramme dactivits prsente des similitudes avec le diagramme des flux et se rapproche du MCT et MOT (MCTA et MOTA dans MERISE 2) pour fournir une vue globale de lorganisation. Le diagramme de composants montre la mise en uvre physique des modles logiques avec lenvironnement de dveloppement. Elle tient compte des problmatiques de programmation, compilation, rutilisation Le diagramme de dploiement est spcifique UML. Il nest cependant pas trs intressant dtablir des liens de correspondance entre les modles de MERISE et dUML car les 2 modles ne sont pas raliss avec les mmes objectifs et nutilisent pas toujours les mmes concepts.
V.3.2) les tapes dinformation
du
processus
dlaboration
du
systme
MERISE identifie 3 grandes tapes dans le processus dlaboration dun systme dinformation : la conception, la ralisation et la maintenance, quon peut dtailler ainsi : Conception o Schma directeur o Etude pralable o Etude dtaille Ralisation o Etude technique o Production logicielle o Mise en uvre Maintenance o Mise en service - Maintenance
A la diffrence de MERISE, UML ne propose pas de cycle prcis : les organisations sont libres de choisir le cycle qui leur convient. UML fonctionne sur un principe ditrations qui ne soppose pas aux phases dfinies dans MERISE. MERISE dcoupe plus au travers de ses phases lanalyse mtier et larchitecture logicielle. Dans UML, larchitecture logicielle a une place prpondrante et est intgre trs en amont dans llaboration du systme dinformation. Dans UML, lavancement du projet est mesur par le nombre de cas dutilisation, de classes... rellement implantes et non par la documentation produite. Les itrations servent en outre rpartir lintgration et les tests tout au long du processus dlaboration du systme dinformation .
V.4) Conclusion
En rsum, on retiendra que : - les niveaux dabstraction ne sont pas nettement distingus dans UML - il ny a pas de diffrence de formalisme en fonction des niveaux dabstraction dans UML - UML intgre lobjet et a t conu pour et autour de lobjet. - UML est plus proche du langage de programmation que MERISE
72
CONCLUSION GENERALE
Les principes de base de MERISE sont ses points forts. MERISE permet de modliser le mtier de lentreprise indpendamment des techniques, aux niveaux conceptuel et organisationnel. Le systme informatique est un sous-ensemble du systme dinformation. Les modles en nombre limit (6) sont progressivement labors et enrichis, et constituent des supports de communication et de participation pour les utilisateurs. UML prsente des caractristiques voisines. Les modles bass sur un nombre dtermin de diagrammes en fonction de la vue sont progressivement enrichis. Mais UML reste incontournable si lentreprise veut utiliser les techniques objet. Ainsi, mme sil existe des points de convergence, le passage de MERISE UML nest pas uniquement dordre syntaxique.
73

Cours Cours Uml

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours Cours Uml

Transféré par

Droits d'auteur :

Formats disponibles

ECOLE NATIONALE DES INGENIEURS DES TRAVAUX AGRICOLES DE BORDEAUX DEPARTEMENT ENTREPRISE ET SYSTEME UNITE DE FORMATION INFORMATIQUE ET GENIE

COURS UML13.doc Mars 2005

J.STEFFE ENITA de Bordeaux

I). Le contexte dapparition dUML __________________________________________ 8

I.2) La gense dUML _______________________________________________________ 14

II) Dmarche gnrale de modlisation avec UML _____________________________ 18

II.2 ) Comment modliser avec UML ? _________________________________________ 18

II.4 ) Lutilisation de diagrammes _____________________________________________ 23

III) Les Diffrents types de diagrammes _____________________________________ 24

III.2) Vues dynamiques du systme : ___________________________________________ 45

IV) Le processus unifi ___________________________________________________ 58

J.STEFFE ENITA de Bordeaux

IV.1.1) Prsentation gnrale________________________________________________________ 58 IV.1.2) Stratgie des cas dutilisation _________________________________________________ 58

IV.2) Le processus unifi est centr sur larchitecture _____________________________ 60

V) Elments de comparaisons entre MERISE et UML __________________________ 65

V.2) La modlisation mtier __________________________________________________ 67

V.4) Conclusion ____________________________________________________________ 72

CONCLUSION GENERALE ______________________________________________ 73

COURS UML13.doc Mars 2005

J.STEFFE ENITA de Bordeaux

TABLE DES MATIERES

I). Le contexte dapparition dUML __________________________________________ 8

I.2) La gense dUML _______________________________________________________ 14

II) Dmarche gnrale de modlisation avec UML _____________________________ 18

COURS UML13.doc Mars 2005

J.STEFFE ENITA de Bordeaux

II.2 ) Comment modliser avec UML ? _________________________________________ 18

II.4 ) Lutilisation de diagrammes _____________________________________________ 23

III) Les Diffrents types de diagrammes _____________________________________ 24

III.2) Vues dynamiques du systme : ___________________________________________ 45

COURS UML13.doc Mars 2005

J.STEFFE ENITA de Bordeaux

IV) Elments de comparaisons entre MERISE et UML _________________________ 58

IV.2) La modlisation mtier _________________________________________________ 67

IV.3) La dmarche __________________________________________________________ 71

CONCLUSION GENERALE ______________________________________________ 73

COURS UML13.doc Mars 2005

J.STEFFE ENITA de Bordeaux

COURS UML13.doc janv 2003

J.STEFFE ENITA de Bordeaux

COURS UML13.doc janv 2003

J.STEFFE ENITA de Bordeaux

UML est une norme

UML est un langage de modlisation objet.

COURS UML13.doc janv 2003

UML est un support de communication

COURS UML13.doc janv 2003

J.STEFFE ENITA de Bordeaux

UML est un cadre mthodologique pour une analyse objet

COURS UML13.doc janv 2003

J.STEFFE ENITA de Bordeaux

UML n'est pas une mthode

COURS UML13.doc janv 2003

J.STEFFE ENITA de Bordeaux

COURS UML13.doc janv 2003

J.STEFFE ENITA de Bordeaux

I). Le contexte dapparition dUML

Le revers de la mdaille : maintenance complexe en cas d'volution

Problmes gnrs par la sparation des donnes et des traitements :

J.STEFFE ENITA de Bordeaux

2me amlioration : centraliser les traitements associs un type, auprs du type

COURS UML13.doc janv 2003

J.STEFFE ENITA de Bordeaux

I.1.2) Lapproche objet Le concept dobjet

IV.1.1) Prsentation gnrale________ 58 IV.1.2) Stratgie des cas dutilisation _ 58