Expos© UML

  • View
    23

  • Download
    0

Embed Size (px)

Text of Expos© UML

ORGANISATION DELUNIFIED MODELING LANGUAGE Version 2.0 ET Version antrieure

Prsent par: - Mr Vonjy Heritiana RATSITOBAINA Mr Ulrich FARALAHY WONG Mlle Cynthia ANDRIAMANJARISOA

Liste des acronymesOMG: Object Management GroupOMT: Object Modeling TechniqueOOSE: Object Oriented Software EngineeringUML: Unified Modeling Language

INTRODUCTIONParmi les langages de modlisation existants, Unified Modeling Language (en franais Langage de Modlisation Objet Unifi) est le plus soutenu par le march. Cependant, plusieurs versions dUML sont dj normalises par lObject Management Group. Ce langage de modlisation connat une amlioration de la version 1.x la version 2.x. Pour ne pas ngliger les nouveauts apports par UML 2, nous avons dcid de rdiger cet ouvrage intitul Organisation de lUnified Modeling Language version 2.0 et version antrieur. Notre ouvrage sera divis en trois grandes parties. Dabord, la premire partie nous allons faire une prsentation gnrale. Ensuite, la deuxime partie de louvrage sera consacre la prsentation des diffrents types de diagrammes dUML 2. Enfin, dans la troisime partie, nous vous prsenterons un exemple doutil de modlisation avec tude de cas.

Premire partie: Prsentation gnrale

: Historique dUMLDurant les annes 90, Deux mthodes ont t les plus diffuses en France entre autre lOMT de James Rumbaugh et BOOCH de Grady Booch. Par ailleurs, OOSE de Ivar Jacobson sest aussi impose dans le monde objet pour la partie formalisation des besoins.Pour aller plus loin dans le rapprochement, James Rumbaugh et Grady Booch se sont retrouvs au sein de la socit Rational Software et ont t ensuite rejoints par Ivar Jacobson en se donnant comme objectif de fusionner leur mthode et crer UML (Unified Modeling Language).Il est important de noter que contrairement ce qui avait t envisag au dpart, le processus de dveloppement a t sorti du champ couvert par le projet de norme. UML est donc une norme du langage de modlisation objet qui a t publie, dans sa premire version, en novembre 1997 par lOMG, instance de normalisation internationale du domaine de lobjet.En quelques annes, UML sest impose comme standard utiliser en tant que langage de modlisation objet. Et Aujourdhui, en cette fin de la premire dcennie des annes 2000, nous avons dj une dizaine dannes de recul sur lenseignement et la pratique dUML en entreprise.Ainsi, les grandes tapes de lexpansion dUML peuvent se rsumer comme suit: 1993-1994: Les deux mthodes Booch93 et OMT-2 sont leaders sur le march et sont de plus en plus proches. Octobre 1994: James Rumbaugh rejoint Grady Booch chez Rational Software. Ses deux mthodes ont t unifies. Octobre 1995: Mthode Unifie 0.8 Fin 1995: le fondateur dObjectory, Ivar Jacobson, rejoint son tour Rational Software Juin 1996: sortie de la version 0.9 dUML Janvier 1997: Soumission lOMG de la version UML 1.0 Septembre 1997: sortie de la version 1.1 dUML 23 novembre 1997: la version 1.1 dUML est adopte par lOMG 1998-1999: sortie des versions 1.2 et 1.3 dUML 2000-2001: sortie des dernires versions suivantes 1.x 2002-2003: prparation de la version 2 dUML 10 octobre 2004: sortie de la version 2.1 dUML 2007: sortie de la version 2.1.1 et de la version 2.1.2 dUML 2008: sortie de la version 2.2 dUML 2010: sortie de la version 2.3 dUML Aot 2011: sortie de la version 2.4.1 dUMLUML nest donc pas un nouveau langage mais cest une fusion de plusieurs langages. Afin de bien comprendre la fonctionnalit dUML, il est prfrable de dfinir quelques mots qui sont utiliss le long de ltude. Nous consacrerons notre deuxime chapitre de cette premire partie ces quelques dfinitions.

: Quelques dfinitionsUML a t pens pour permettre de modliser les activits de l'entreprise, pas pour les rgir.

Son indpendance (par rapport aux langages d'implmentation, domaine d'application, processus...) en font un langage universel.

Deuxime partie: Les diagrammes dUML 2

Dans cette partie, nous allons prsenter les diffrents types de diagrammes dUML 2. UML dans sa version 2 propose treize diagrammes qui peuvent tre utiliss dans la description dun systme. Ces diagrammes sont regroups dans deux grands ensembles: les diagrammes de comportement et les diagrammes structurels. Pour ne pas mlanger les problmes, les diagrammes sont ensuite dcoups suivant les quatre points de vue de modlisation : fonctionnel, statique, dynamique et implmentation, en insistant pour chacun sur le ou les diagrammes UML principaux.: Les diagrammes de comportementLes diagrammes comportementaux sont focaliss sur la description de la partie dynamique et fonctionnelle du systme modliser. Sept diagrammes sont proposs par UML 2 pour assurer cette description. FonctionnelPour ce point de vue fonctionnel, un seul diagramme sera prsent.1. Le diagramme de cas dutilisation:Les cas dutilisation constituent un moyen de recueillir et de dcrire les besoins des acteurs du systme. Ils permettent de dcrire linteraction entre les acteurs et le systme. Sa reprsentation met en jeu trois concepts : lacteur, le cas dutilisation et linteraction entre lacteur et le cas dutilisation. Un acteur:Cest un utilisateur type qui a toujours le mme comportement vis--vis dun cas dutilisation. Ainsi les utilisateurs dun systme appartiennent une ou plusieurs classes dacteurs selon les rles quils tiennent par rapport au systme. Il peut aussi tre un systme externe avec lequel le cas dutilisation va interagir.Un acteur peut se reprsenter symboliquement par un bonhomme et tre identifi par son nom. Il peut aussi tre formalis par une classe strotype acteur

Figure 1: Reprsentation d'un acteur

Un cas dutilisation:Un cas dutilisation correspond un certain nombre dactions que le systme devra excuter en rponse un besoin dun acteur. Linteraction entre lacteur et le cas dutilisation:Une interaction permet de dcrire les changes entre un acteur et un cas dutilisation.Linteraction entre un acteur et un cas dutilisation se reprsente comme une association. Elle peut comporter des multiplicits comme toute association entre classes.

Figure 2 : Prsentation de cas d'utilisationAfin doptimiser la formalisation des besoins en ayant recours notamment la rutilisation de cas dutilisation, trois relations peuvent tre dcrites entre cas dutilisation : une relation dinclusion ( include ), une relation dextension ( extend ), une relation de gnralisation.

Une relation dinclusion dun cas dutilisation A par rapport un cas dutilisation B signifie quune instance de A contient le comportement dcrit dans B.Une relation dextension dun cas dutilisation A par un cas dutilisation B signifie quune instance de A peut tre tendue par le comportement dcrit dans B. Deux caractristiques sont noter : le caractre optionnel de lextension dans le droulement du cas dutilisation standard (A) ; la mention explicite du point dextension dans le cas dutilisation standard.Une relation de gnralisation de cas dutilisation peut tre dfinie conformment au principe de la spcialisation-gnralisation dj prsente pour les classes.Du point de vue dynamique1. Le diagramme de squence??????????????????2. Le diagramme dtat-transition?????????????????????3. Le diagramme dactivitLe diagramme dactivit prsente un certain nombre de points communs avec le diagramme dtat-transition puisquil concerne le comportement interne des oprations ou des cas dutilisation. Cependant le comportement vis ici sapplique aux flots de contrle et aux flots de donnes propres un ensemble dactivits et non plus relativement une seule classe. Les concepts communs ou trs proches entre le diagramme dactivit et le diagramme dtat-transition sont : transition, nud initial (tat initial), nud final (tat final), nud de fin flot (tat de sortie), nud de dcision (choix).Le formalisme reste identique pour ces nuds de contrle.Les concepts spcifiques au diagramme dactivit sont : nud de bifurcation, nud de jonction, nud de fusion, pin dentre et de sortie, flot dobjet, partition. Une action:Une action correspond un traitement qui modifie ltat du systme. Cette action peut tre apprhende soit un niveau lmentaire proche dune instruction en termes de programmation soit un niveau plus global correspondant une ou plusieurs oprations.Formalisme et exemple:Une action est reprsente par un rectangle dont les coins sont arrondis comme pour les tats du diagramme dtat-transition. La figure ci-dessus illustre notre dfinition.

Figure 3 : Formalisme et exemple d'une action Transition et flot de contrle:Ds quune action est acheve, une transition automatique est dclenche vers laction suivante. Il ny a donc pas dvnement associ la transition. Lenchanement des actions constitue le flot de contrle.Formalisme et exempleLe formalisme de reprsentation dune transition est donn la figure suivante:

Figure 4 : Formalisme de base du diagramme dactivit : actions et transition Une activit:Une activit reprsente le comportement dune partie du systme en termes dactions et de transitions. Une activit est compose de trois types de nuds : nud dexcution (action, transition), nud de contrle (nud initial, nud final, flux de sortie, nud de bifurcation, nud de jonction, nud de fusion-test, nud de test-dcision, pin dentre et de sortie), nud dobjet.Une activit peut recevoir des paramtres en entre et en produire en sortie.

Formalisme et exempleNous donnons une premire reprsentation simple la figure suivante:

Figure 5 : Exemple de reprsentation dune activit Nud de bifurcation (fourche)Un nud de bifurcation (fourche) permet partir dun flot unique entrant de crer plusieurs flots concurrents en sortie de la barre de synchronisation.Formalisme et exemple:Le formalisme de reprsentation de nud de bifurcation ainsi quun premier exemple sont donns la Figure 6. Un second exemple avec nud de bifurcation est donn la Figure 7.

Figure 6 : Exemple 1 dactivits avec nud de bifurcation

Figure 7 : Exemple 2 de diagramme dactivit Nud de jon