Vous êtes sur la page 1sur 69

1

CONSERVATOIRE NATIONAL DES ARTS ET METIERS CENTRE REGIONAL ASSOCIE DE TOURS

EXAMEN PROBATOIRE

prsent en vue dobtenir Le DIPLOME DINGENIEUR Du Conservatoire National des Arts et Mtiers

Spcialit : INFORMATIQUE

Sujet : La mthode UML

Par Laurent GOUTHIERE

Soutenu le 3 Juillet 1998 devant la commission du jury

Prsidents :
Monsieur le professeur S. NATKIN Monsieur H. BENAZIZI Professeur responsable au C.N.A.M. de PARIS Professeur correspondant au C.R.A. du C.N.A.M. de TOURS

Assists de :
Monsieur C. MARTIN Monsieur A. HERNANDEZ Professeur correspondant au C.R.A. du C.N.A.M. de TOURS Professeur correspondant au C.R.A. du C.N.A.M. de TOURS

Mthode UML : Le langage de modlisation objet unifi

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

TABLE DES MATIERES


1. PRINCIPES ET CONCEPTS OBJETS............................................................................................. 5 1.1 1.2 1.3 1.4 2. NOTION DOBJET, NOTION DE CLASSE ..............................................................................................5 ENCAPSULATION ET ABSTRACTION ..................................................................................................5 HERITAGE ......................................................................................................................................6 POLYMORPHISME............................................................................................................................8

INTERETS DE LA MODELISATION ............................................................................................. 8 2.1 2.2 POURQUOI A-T-ON BESOIN DE LA MODELISATION ? ...........................................................................8 LE LOGICIEL DANS LE FUTUR ...........................................................................................................9

3.

GENESE DE UML............................................................................................................................. 9 3.1 3.2 HISTORIQUE ...................................................................................................................................9 NOUVEAUX CONCEPTS ..................................................................................................................10

4.

UML UN LANGAGE GRAPHIQUE .............................................................................................. 11 4.1 DIAGRAMMES DES CAS DUTILISATION ...........................................................................................11 4.1.1 Origine ................................................................................................................................11 4.1.2 Dfinition ............................................................................................................................11 4.1.3 Exemple de diagramme de cas dutilisation .........................................................................12 4.1.4 Intrts des diagrammes des cas dutilisation ......................................................................12 4.2 DIAGRAMME DE CLASSES ..............................................................................................................12 4.2.1 Origine ................................................................................................................................12 4.2.2 Dfinition ............................................................................................................................13 4.2.3 Exemples de diagrammes de classes ....................................................................................13 4.2.4 Intrts des diagrammes de classes ......................................................................................15 4.3 DIAGRAMMES DE COMPORTEMENT (BEHAVIOR DIAGRAMS).............................................................16 4.3.1 Diagrammes dtats-transitions (State diagrams).................................................................16
4.3.1.1 4.3.1.2 4.3.1.3 4.3.1.4 Origine........................................................................................................................................... 16 Dfinition....................................................................................................................................... 16 Exemple de diagramme dtats-transitions...................................................................................... 17 Intrts des diagrammes dtats-transitions..................................................................................... 17

4.3.2
4.3.2.1 4.3.2.2 4.3.2.3 4.3.2.4

Les diagrammes dactivit (Activity diagrams).....................................................................18


Origine........................................................................................................................................... 18 Dfinition....................................................................................................................................... 18 Exemples de diagramme dactivit ................................................................................................. 18 Intrts des diagrammes dactivit .................................................................................................. 19

4.3.3
4.3.3.1 4.3.3.2 4.3.3.3 4.3.3.4

Les diagrammes de squence ...............................................................................................20


Origine........................................................................................................................................... 20 Dfinition....................................................................................................................................... 20 Exemple de diagrammes de squences............................................................................................ 20 Intrts des diagrammes de squences ............................................................................................ 21

4.3.4
4.3.4.1 4.3.4.2 4.3.4.3 4.3.4.4

Les diagrammes de collaboration ........................................................................................21


Origine........................................................................................................................................... 21 Dfinition....................................................................................................................................... 22 Exemples de diagrammes de collaboration...................................................................................... 22 Intrts des diagrammes de collaboration ........................................................................................ 22

4.4 LES DIAGRAMMES DIMPLEMENTATION ..........................................................................................22 4.4.1 Les diagrammes de composants ...........................................................................................23
4.4.1.1 4.4.1.2 4.4.1.3 4.4.1.4 Origine........................................................................................................................................... 23 Dfinition....................................................................................................................................... 23 Exemple de diagramme de composants ........................................................................................... 23 Intrts des diagrammes de composants .......................................................................................... 24

4.4.2
4.4.2.1 4.4.2.2

Diagrammes de dploiement ................................................................................................24


Origine........................................................................................................................................... 24 Dfinition....................................................................................................................................... 24

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi


4.4.2.3 4.4.2.4

Exemple de diagramme de dploiement .......................................................................................... 25 Intrts des diagrammes de dploiement ......................................................................................... 25

5.

GENIE LOGICIEL, CONDUITE DE PROJET AVEC UML ....................................................... 25 5.1 DEMARCHE FONCTIONNELLE ET DEMARCHE OBJET .........................................................................25 5.1.1 La dmarche fonctionnelle...................................................................................................25 5.1.2 La dmarche objet ...............................................................................................................26 5.1.3 Comparaisons des approches fonctionnelles et objets ..........................................................27 5.2 PROPOSITION DUN PROCESSUS DETUDE ........................................................................................27 5.3 CYCLE DE VIE ITERATIF .................................................................................................................28 5.3.1 Approche du cycle de vie itratif..........................................................................................28 5.3.2 Trois lments importants dans lapproche itrative ............................................................29 5.3.3 Bnfices rsultants .............................................................................................................29 5.3.4 Profil de risque dun dveloppement itratif ........................................................................29 5.3.5 Management du risque phases par phases............................................................................29 5.3.6 La rduction des risques conduit aux itrations ...................................................................30 5.3.7 Phase dlaboration et itration ...........................................................................................31 5.3.8 Le cycle de vie par itration : processus en mini-cascade ....................................................32 5.3.9 Cycle de vie itrations dtailles.......................................................................................32 5.3.10 Travail effectuer dans une itration ..................................................................................33 5.3.11 Evaluation de lit ration......................................................................................................33 5.3.12 Choisir le nombre ditrations .............................................................................................33 5.3.13 La premire itration ...........................................................................................................34 5.3.14 Pourquoi le cycle itratif ? ..................................................................................................34

6. 7. 8. 9.

ANNEXE .......................................................................................................................................... 35 GLOSSAIRE UML .......................................................................................................................... 44 BIBLIOGRAPHIE........................................................................................................................... 64 REFERENCES................................................................................................................................. 66

10. ADRESSES INTERNET.................................................................................................................. 68

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

1. PRINCIPES ET CONCEPTS OBJETS


On va rappeler ici les principaux concepts objets, car en effet, ces notions sont trs importantes pour la comprhension des diffrents modles dUML et leurs implmentations, plus exactement les diagrammes qui vont dcrire les concepts de UML (qui est avant tout un langage graphique).

1.1

Notion dobjet, notion de classe

Un objet est une entit hermtique qui contient la fois des donnes et des traitements (les donnes sont appeles attributs et les traitements oprations ou mthodes). Une classe est une abstraction dobjets (ne pas confondre avec labstraction des concepts objets). Cest dire une structure qui rassemble des proprits communes une collection dobjets. On dit quun objet est une instance de classe, cest dire une valeur particulire de la classe (notion dinstanciation). Par exemple une instance de la classe Voiture est : Renault Laguna .

1.2

Encapsulation et abstraction

On dit que les informations (qui sont des donnes) et les comportements (qui sont les traitements ou encore mthodes ou oprations) dun objet sont encapsuls. En effet celles-ci sont lintrieur dune entit (objet figure 1.2-a).

Informations Nom = Dupont Prnom = Marcel Age = 38 ans Situation = Clibataire Comportements ChangerNom ChangerAge ChangerSituation Lobjet Personne

Figure 1.2-a : Les informations (donnes) et les comportements (traitements ou oprations) de lobjet Personne sont encapsuls cest dire regroups dans une entit qui est lobjet Personne.

Intrt de lencapsulation : On peut protger le contenu des classes dune manipulation maladroite et ou mal intentionne.
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

Un objet est caractris par ses donnes et ses traitements mais il est aussi caractris par une partie publique, une partie prive et une partie implmentation, cest ce que lon appelle labstraction. On dit que les donnes ont un accs priv cest dire que seuls les traitements de cet objet peuvent, le cas chant, modifier ces donnes (attention les donnes peuvent tre aussi publiques mais cela na aucun intrt). Les traitements extrieurs lobjet ne peuvent pas modifier les donnes de lobjet. Les traitements ont un accs priv ou public. Si les traitements sont publics, ceux-ci appartiennent lobjet et peuvent tre appels et modifier les donnes. Si les traitements sont privs, alors seuls des traitements publics appartenant lobjet pourront dclencher lexcution des traitements privs ( condition quils figurent dans le codage). Les traitements privs sont appels mthodes dimplmentation (voir figures 1.2-b).
Nom = Dupont Nom = Dupont Parties prives Nom = DUPONT Age Age NomEnMajuscule ChangerNom(Dupont)

ChangerNom(UnNom)

ChangerNom(UnNom)

Les attributs et les mthodes sont publics. Les attributs peuvent tre modifis directement sans passer par les mthodes.

Les attributs sont privs. Les attributs ne peuvent tre modifis que par la mthode publique (ici ChangerNom) qui fait appel une mthode dimplmentation (ici NomEnMajuscule)

Figures 1.2-b : Accs publics et accs privs un objet Personne.

1.3

Hritage

On parle dhritage lorsque lon a affaire des objets et des classes et de gnralisation / spcialisation uniquement pour des classes. On distingue deux types dhritage : lhritage simple (voir figure 1.3-a), lhritage multiple (voir figure 1.3-b). On va factoriser les attributs et les mthodes communs plusieurs classes dans une classe principale : on parle de gnralisation. Les classes drives deviennent des sous-classes : on parle de spcialisation.
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

Personne Nom Prnom Adresse Age ChangerNom ChangerAdresse ChangerAge Gnralisation

Professeur Statut Matire ChangerStatut ChangerMatire Spcialisation

Etudiant Filire ChangerFilire

Figure 1.3-a : Les classes professeur et tudiant drivent et peuvent utiliser les attributs et les mthodes de la classe Personne : on parle dhritage simple.

CompteBancaire Montant CompteEpargne Intrts Dbiter(2)

CompteChque ChquierEmis Dbiter(1)

CompteChqueRmunr

Figure 1.3-b : La classe CompteChqueRmunr va hriter : deux fois des attributs et des mthodes de CompteBancaire et va hriter aussi des attributs et des mthodes des classes CompteChque et CompteEpargne : on parle dhritage multiple.

Intrts de lhritage : Lhritage permet la rutilisation du code. En effet lorsque lon va instancier une classe spcialise, le code des attributs et des mthodes de la classe hrite ne seront pas implments nouveau. Lautre avantage de lhritage et quil permet lorganisation hirarchique des classes. Cest dire quil

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

rend plus ais lexploration et la maintenance dune bibliothque de classe pour une quipe de dveloppement.

1.4

Polymorphisme

Le polymorphisme est la possibilit pour un mme message de dclencher des traitements diffrents, suivant les objets auxquels il est adress. Le mcanisme de polymorphisme permet donc de donner le mme nom des traitements diffrents (voir figure 1.4-a).
Voiture n immatriculation

Porsche 911 AcclrerAFond

Renault 21 AcclrerAFond

Figure 1.4-a : Lorsque le message AcclrerAFond est excut, il na pas le mme effet sur lobjet Porsche 911 et sur lobjet Renault 21. La mthode AcclrerAFond est polymorphe.

Intrt du polymorphisme : Le polymorphisme permet de donner le mme nom des traitements diffrents ou encore, permet le choix dynamique dun traitement en fonction de lobjet auquel il est appliqu (en effet le choix de la mthode polymorphe excuter est dtermin lexcution du programme. Cest pour cela quon dit quelle est dynamique, par oppos statique qui est dtermin lors de la compilation).

2. INTERETS DE LA MODELISATION 2.1 Pourquoi a-t-on besoin de la modlisation ?

On va aborder maintenant limportance de la modlisation face laugmentation des exigences de systmes complexes. On construit des modles de systmes complexes parce que nous ne pouvons pas comprendre un systme dans sa totalit. Des techniques de modlisation performantes sont ncessaires face laugmentation de la complexit des systmes. Il y a de nombreux facteurs la russite dun projet et avoir une mthodologie rigoureuse est un facteur essentiel. Un langage de modlisation doit comprendre :
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

lments du modle des concepts de modlisation fondamentaux et une smantique ; une notation une interprtation visuelle des lments du modle ; aide en ligne (lignes de guidage) idiomes de lusage.

2.2

Le logiciel dans le futur

Comme le logiciel augmente sa valeur stratgique, lindustrie cherche des techniques pour automatiser la production de logiciels. On cherche ainsi des techniques pour amliorer la qualit et rduire le cot et le temps de dveloppement. On cherche des techniques pour manager la complexit des systmes qui augmente sensiblement. En particulier, on reconnat le besoin de rsoudre des problmes darchitecture qui se reproduisent, comme la distribution physique (physical distribution), la concurrence, la rplication, la scurit, lquilibrage des charges dans un systme distribu (load balancing), et la tolrance aux pannes. La complexit varie en fonction du domaine dapplication et de la phase de traitement. Une cl de lintressement une mthode de modlisation dans lesprit des dveloppeurs en UML est de crer un ensemble de smantique et de notation qui permet de rsoudre les diffrents niveaux de complexit travers les diffrents domaines [RAT1-97].

3. GENESE DE UML 3.1 Historique

Les langages de modlisation orients objets sont apparus au milieu des annes 1970 et jusqu fin des annes 1980 comme des mthodes exprimentales. Les mthodes orientes objets sont passes de moins de 10 jusqu 50 pendant les annes 1989-1994. A partir des annes 1990, une nouvelle mouture de mthodes est apparue et en particulier, la mthode OOD (Object Oriented Design) Booch93 et OMT (Object Modeling Technique) [RUM1-96]. Puis a merg OOSE (Object Oriented Software Engineering). Chacune de ces mthodes tait complte et puissante. Plus simplement OOSE avait une approche objet avec ses cas dutilisation (use cases). OMT-2 tait trs spcialise pour lanalyse de linformation sur les donnes des systmes. Booch93 tait spcialise et expressive pour le dessin et la construction des phases de projets Cest dans les annes 1995 que Grady Booch et John Rumbaugh ont termin leurs travaux dunification de leurs mthodes respectivement OMT et Booch93. Aussi cest fin 1995 que Ivar Jacobson sest joint eux, fusionnant avec eux la mthode OOSE. Ils ont trouv quil tait ncessaire de crer un standard plutt que dvoluer chacun de son cot. Ainsi, par ces fusions de mthodes est n le langage unifi, cest UML (Unified Modeling Language) [RAT1-97].
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

10

En 1996, il apparat clairement que UML est un lment de base dans la stratgie de plusieurs grandes entreprises. Cest ainsi que se cre un consortium de partenaires pour travailler la dfinition de la version 1.0 dUML ; se regroupent notamment : DEC, HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI et Unisys. De cette collaboration nat la description dUML, version 1.0 remise lOMG le 17 Janvier 1997, en vue de sa standardisation durant l anne 1997 [RAT2-97]. Cest en Novembre 1997 que lOMG (Object Management Group) a normalis la version 1.1 de UML [MUL1-97] (voir figure 3.1-a). Il est intressant de noter quun des objectifs des auteurs de cette mthode unifie est de modliser des systmes et pas particulirement du logiciel. Et dautre part leur but tait de crer un langage de modlisation utilisable par les humains et aussi par les machines.

Figure 3.1-a : UML a t normalis par lOMG (Object Management Group) en Novembre 1997 [RAT3-97].

3.2

Nouveaux concepts

Strotypes Responsabilits Mcanismes dextension : strotypes, valeurs mots cls (tagged value),
contraintes Thread et process Distribution et concurrence (pour modliser ActiveX/DCOM et CORBA) Patterns/collaborations Diagrammes dactivit (pour le reengineering de processus) Sparation claire de types, de classes et dinstances
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

11

Raffinement (refinement) Interfaces et composants

4. UML UN LANGAGE GRAPHIQUE


UML exprime ses concepts travers diffrents diagrammes graphiques qui correspondent des vues particulires du systme : la vue logique. Elle fait rfrence aux diagrammes de classes (class diagrams). Cest au niveau de cette approche que lon va utiliser la plupart des concepts objets ; la vue des cas dutilisation qui fait rfrence aux diagrammes des cas dutilisation (use cases diagrams) et des acteurs. On va sintresser aux fonctionnalits du systme ; la vue des composants (components view). Elle reprsente lensemble des composants logiciels ainsi que les tches ; la vue de dploiement (deployment view). Elle dcrit les diffrentes ressources matrielles et limplantation du logiciel dans ces ressources. Si on procde par classification, on a les diagrammes suivants : les cas dutilisations, les diagrammes de classes, les diagrammes de comportement : diagrammes dtats-transitions, diagrammes dactivits, diagrammes de squence, diagrammes de collaboration. Les diagrammes dimplmentation : diagramme de composants, diagrammes de dploiement.

4.1

Diagrammes des cas dutilisation

4.1.1 Origine Les diagrammes des cas dutilisation sont similaires en apparence avec ceux de OOSE (Object Oriented Software Engineering) de Ivar Jacobson [RAT4-97].

4.1.2 Dfinition Les diagrammes de cas dutilisation se composent dacteurs (reprsents par des silhouettes) et des cas dutilisation (reprsents par des ellipses). Les traits entre les cas dutilisation et les acteurs reprsentent les interactions. Ces diagrammes montrent les relations qui existent entre des acteurs et des fonctionnalits du systme.
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

12

4.1.3 Exemple de diagramme de cas dutilisation Cas dun guichet bancaire (voir figure 4.1.3-a et figure en annexe)

Guichetier

Retirer des francs Saisir le cours devise Retirer des devises

Responsable devises

Emprunter

Systme central Directeur Faire le bilan

Figure 4.1.3-a : Quelques cas dutilisation dune application bancaire. Les fonctionnalits dcrites sont vues travers diffrents acteurs [LOP1-97]. Le cas dutilisation Retirer des francs par exemple pourra tre dcrit comme suit : - le guichetier valide le compte du client auprs du systme ; - le guichetier saisit le montant du retrait ; - le systme demande au systme central si le compte est suffisamment approvisionn ; - le systme notifie au guichetier quil p eut dlivrer le montant demand.

4.1.4 Intrts des diagrammes des cas dutilisation Les intrts des diagrammes des cas dutilisation sont dabord et avant tout de : modliser le systme; de dterminer les fonctionnalits du systme travers une vue dun acteur et de les reprsenter. Les cas dutilisation permettent de forcer lutilisateur ou lexpert dfinir ce quil attend du systme.

4.2 Diagramme de classes


4.2.1 Origine Le diagramme de classes provient principalement de OMT RUMBAUGH et de OOD BOOCH [RAT4-97].

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

13

4.2.2 Dfinition Cest un diagramme qui montre une collection dlments statiques (classes), leur contenu et les relations entre eux. On distingue (voir figure 4.2.3-a, figure 4.2.3-b, figure 4.2.3-c, figure 4.2.4-a) : les entits formes de trois parties : les classes. Les classes se dsignent par un nom (1re partie), contiennent des attributs (2me partie) et des mthodes associes (3me partie) : les attributs sont des proprits caractristiques de la classe. Les attributs peuvent tre privs, publics, protgs. Ils sont le plus souvent privs. Les classes respectent le principe dencapsulation des donnes (voir les concepts objets Cf. 1.2) ; les mthodes sont des procdures spcifiques une classe. Elles sont le plus souvent publiques. Elles peuvent tre prives : on parle dans ce cas de mthodes dimplmentation (voir les concepts objets Cf. 1.2). les relations interclasses : Elles sont appeles associations. On a dfini diffrents types dassociations : association simple, agrgation, hritage (spcialisation, gnralisation), dpendance. les noms de rle : ceux sont les noms des relations interclasses ; les multiplicits : associes aux associations, les multiplicits permettent de dterminer le nombre doccurrence dune classe par rapport une autre classe en utilisant le nom de rle ; la navigation : cest le sens de lecture du nom de rle dune association donne. Lassociation est symbolise par une ligne qui lie deux classes. La navigation est symbolise par une flche qui indique le sens de lecture du nom de rle. 4.2.3 Exemples de diagrammes de classes On a choisi plusieurs diagrammes de classes. Le premier traite des classes ncessaires pour reprsenter les inscriptions du CNAM (Conservatoire National des Arts et Mtiers), ainsi que la validation du choix des cours. Le deuxime traite en partie des documents emprunter dans une mdiathque [LOP2-97]. Le troisime traite des uvres non interprtes dans une mdiathque.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi Support d' oeuvre Nom

14

Livre

Cassette audio

CDAudio

CassetteVido

Figure 4.2.3-b : Supports de la mdiathque : Illustration de lhritage. La classe de gnralisation est Support, les classes de spcialisation sont Livre, CassetteAudio, CDAudio, CassetteVido. On peut dire : Un Livre est une sorte de Support, une CassetteAudio est une sorte de Support etc. La classe Livre hrite de NomOeuvre, la classe CassetteAudio hrite de NomOeuvre etc.
Formulaire d'inscription Saisir par 0..* 1 AjouterUnAuditeur (Cours, InfoAuditeur) Personne enregistre Nom 1 Cours Numro Nom Nombred'inscrits Ouvrir () AjouterUnAuditeur (InfoAuditeur) 1 1..* 0..* Secrtariat des inscriptions Direction des programmes

Professeur Statut 0..1 0..* Lieu

Auditeur NomDuCursus 1..* 1..* Cours effectif

AjouterUnAuditeur (InfoAuditeur) Ouvrir ()

Figure 4.2.3-a : Les inscriptions et la validation des cours au CNAM. On distingue les diffrentes associations (un cadenas signifie priv et un tir rose, public) : agrgation entre Cours et Cours effectif. On peut dire que lensemble des cours est compos de cours effectifs (chaque fois que lon peut dire est compos de, on a affaire un relation dagrgation). hritage simple entre Personne enregistre et Professeur ainsi quentre Personne enregistre et Auditeur. On peut dire quune personne enregistre est une sorte de Professeur ou une sorte d Auditeur (chaque fois que lon peut dire est une sorte de, on a affaire une relation dhritage). simple entre Formulaire dinscription et Secrtariat des inscriptions.
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

15

On peut galement voir les liens entre classes (qui reprsentent des associations) et le sens de ces liens symboliss par une flche qui s appelle la navigation. (Suite de la lgende de la figure 4.2.3-a) On a donn comme nom de rle Saisir par la relation entre Formulaire dinscription et Secrtariat des inscriptions . Il existe un autre type de lien faible entre classes dit lien de dpendance. Celui-ci est reprsent par une ligne pointille termine par une flche. Les multiplicits se prsentent sous forme de nombre suivi de deux points suivi dun autre nombre et se lisent par exemple : Le secrtariat des inscriptions enregistre 0 N Cours (symbolis par 0..N) etc.
OeuvreNonInterprte

Ouvrage 1 0..1

Bibliographie

Figure 4.2.3-c : uvre non interprte : Illustration de lhritage et de lagrgation. Une Ouvrage est une sorte d uvre non interprte : Hritage. Une Bibliographie est compose d Ouvrage : Agrgation. Une Bibliographie est un et un seul Ouvrage : Association avec multiplicit 1 etc.

4.2.4 Intrts des diagrammes de classes Dans UML les diagrammes des classes constituent la vue logique (car normalement indpendante du langage de programmation cible) du systme. Les intrts des diagrammes de classes sont de : rassembler les donnes utilises par le systme dans des entits encapsules : les classes (collections dobjets dattributs communs) ; dfinir les oprations qui permettent de manipuler ces donnes (uniquement que lorsque quelles sont ncessaires), celles-ci seront intgres aux classes ; de raliser une vision des lments statiques du systme, cest dire de recenser les parties des structures qui ne se modifieront pas avec le temps (par opposition aux diagrammes dynamiques qui sont les diagrammes dtatstransitions ou les diagrammes dactivits que lon abordera plus tard) ; mettre en uvre les concepts objets (en particulier lhritage, qui permet la rutilisation du code). Remarque : On notera la similitude, en partie, entre les diagrammes de classes et les modles entits-associations ou encore les modles conceptuels des donnes [TAR1-83].

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

16

4.3 Diagrammes de comportement (Behavior diagrams)


On distingue : les diagrammes dtats-transitions, les diagrammes dactivit, les diagrammes de squence, les diagrammes de collaboration.

Graphe

Sommet NomDuSommet

Arte Sommet_de_dpart Sommet_d' arrive

Figure 4.2.4-a : Dfinition dun graphe en utilisant les agrgations : un graphe est compos de Sommet et d Arte.

4.3.1 Diagrammes dtats-transitions ( State diagrams ) 4.3.1.1 Origine Les diagrammes dtats-transitions proviennent des Statecharts de David Harel [HAR1-84] avec des modifications mineures [RAT4-97].

4.3.1.2 Dfinition Les diagrammes dtats-transitions dcrivent les squences dtats quun objet peut prendre au cours de sa vie en rponse un stimulus [RAT5-97]. On associe souvent un diagramme dtats-transitions une classe. On distingue dans ces diagrammes (voir figure 4.3.3-a) : les vnements externes qui causent une transition dun tat lautre, les vnements internes qui induisent une action sans changer dtat. les actions qui rsultent dun changement dtat, les actions en sortie dtat, les activits pendant ltat.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

17

Etat 1 Entry /action en entre dtat Do : activit pendant ltat Evnement 1 / action 1 Evnement 2 / action 2 Exit / action en sortie dtat

Evnement (attributs) [gardien] /action

Etat 2

Figure 4.3.1.2-a : Les tats, une transition et la description dtaille des oprations. (Les gardiens sont des fonctions boolennes. Une transition contenant des gardiens ne peut tre accomplie que si et seulement si les conditions ou gardiens sont vrifies. Les attributs sont des informations ou des paramtres ports par des vnements) [LOP3-97].

4.3.1.3

Exemple de diagramme dtats-transitions

Voir figure 4.3.1.4-a.

4.3.1.4 Intrts des diagrammes dtats-transitions Les intrts de la modlisation par les diagrammes dtats-transitions sont de : donner vie aux objets (sils sy prtent) reprsents jusqu prsent de manire statique comme des occurrences de classes quon peut gnraliser par les classes ; mieux visualiser le systme en diminuant sa complexit (parce que lon va dtailler); tenir compte des tats lors de limplmentation (en effet la traduction des tats peut tre faite simplement, la plupart des langages le permettent); reprsenter un aspect du modle dynamique, lautre tant illustr par les diagrammes dactivits, les diagrammes de collaborations et les diagrammes de squences ; pouvoir dcrire les changements dtats des automates [LAI1-97] .

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi Dbut Ajouter un auditeur[ Compteur < 5 ]

18

Initialisation do: Cours initial

Ouvert Ajouter un auditeur / Compteur = 0 Annuler [ Compteur = 5 ] entry: Auditeur enregistr exit: Compteur incrment

Annuler

Annul do: Notifier les auditeurs enregistrs Annuler

Ferm do: Finaliser le cours

Fin

Figure 4.3.1.4-a : Reprsentation dynamique par diagramme dtats-transitions dun cours pour quil devienne effectif (pour quil fasse partie des cours enseigns). Le cours sera effectif si on atteint un nombre de 5 inscrits (pour les oprations voir figure 4.2.3-a).

4.3.2 Les diagrammes dactivit (Activity diagrams) 4.3.2.1 Origine Les diagrammes dactivit proviennent des workflow diagrams dcrits dans de nombreuses anciennes mthodes [RAT4-97]. 4.3.2.2 Dfinition Un diagramme dactivit est un cas spcial de diagramme dtat dans lequel tous (ou la plupart) des tats sont des tats daction dans lesquels toutes (ou la plupart) des transitions sont dclenches par achvement des actions dans les tats sources. Le diagramme entier est rattach une classe, limplmentation dune opration ou dun cas dutilisation [RAT6-97]. Le but de ce diagramme est de visualiser les flux conduits par des processus internes.

4.3.2.3 Exemples de diagramme dactivit On prsente ici un schma de diagramme dactivit afin de montrer la notation, ainsi que les tapes avec transitions ou non (lorsque cest la fin de laction). Dans chaque case reprsentant une tape il y a un verbe qui signifie une action. Entre deux tapes il peut y avoir une condition de transition (garde : fonction boolenne). Voir figure 4.3.2.3-a et figure en annexe.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi


C h o i s i r la b o is s o n 1 1 ) [C a f c h o is i] [P a s d e c a f ] 4 [P a s d e C o la ]

19

D but but

[C o la c h o is i]

M e tt r e d u c a f d a n s l e f il t r e

A jo u t e r d e l e a u d a n s le r s e rv o ir

S e p ro c u re r u n g o b e le t

M e tt r e le f il t r e d a n s la m a c h in e

S e p ro c u re r un can d e c o la 1

M e tt r e la m a c h in e e n m a rc h e ^ c a f e t i r e .m a r c h e F il t r e r l e c a f 3

L e v o y a n t s t e i n t V e rs e r le c a f

B o ire

P e rs o n n e : :P r e p a r e r B o is s o n

F in

Figure 4.3.2.3-a : Diagramme dactivit de lopration prparer boisson de la classe personne (Personne : :PreparerBoisson). On distingue des synchronisations (1), les tats : initial et final, des gardes (2), une transition (3), une dcision (4), les tapes avec leur action [RAT7 -97].

4.3.2.4 Intrts des diagrammes dactivit Les intrts des diagrammes dactivit sont : de modliser le comportement interne, dune classe, dun cas dutil isation ou dune opration sous forme dune succession dactions ; de reprsenter une succession dtats synchrones (alors quon prfrera les diagrammes dtats-transitions pour reprsenter une suite dtats asynchrones) ; de pas ncessiter lexistence dvnements de transition pour avoir un changement dtat. Cest dire que les changements dtats pourront seffectuer simplement la fin des actions. Remarque : On peut trouver une certaine analogie entre les diagrammes dactivits et les organigrammes, ou encore avec plus prcisment le modle conceptuel des traitements [TAR1-83].
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

20

4.3.3 Les diagrammes de squence 4.3.3.1 Origine Les diagrammes de squences proviennent de nombreuses mthodes orientes objets sous des noms diffrents (interactions, trac des messages et trac des vnements) et remontent aux premires mthodes orientes objets [RAT4-97]. Un auteur [MUL2-97] dit quils proviendraient des Object Message Sequence Chart du Siemens Pattern Group [WIL1-96].

4.3.3.2 Dfinition Les diagrammes de squence montrent les interactions qui surviennent dans une squence de temps. En particulier ils montrent la participation dobjets dans les interactions et les messages quils changent dans une intervalle de temps. Ils ne montrent pas les associations entre les objets [RAT8-97]. 4.3.3.3 Exemple de diagrammes de squences Un diagramme de squence a les caractristiques suivantes : Une dimension verticale qui reprsente le temps, une dimension horizontale qui reprsente diffrents objets [RAT8-97]. Les objets se poursuivent verticalement par une ligne pointille que lon appelle ligne de vie. Le temps scoule de haut en bas et de gauche droite. Les messages changs entre objets sont reprsents horizontalement par une ligne termine par une flche. Voir figure 4.3.3.3-a et figure en annexe.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

21

: Auditeur

Formulaire d' inscription

Secrtariat des inscriptions

cours rseaux C3

1: Remplir le formulaire

2: Soumettre sa candidature 3: Ajouter un cours(Dupont, Rseaux C3) 4: Le cours est-il ouvert ?

5: Inscrire Dupont

Figure 4.3.3.3-a : Inscription dun auditeur du CNAM au cours Rseaux C3 . Les messages permettent de dterminer les liens entre objets du diagramme de classes (en effet si il y a un lien entre deux objets cest quil existe une relation entre objets) ainsi que les oprations relatives une classe.

4.3.3.4 Intrts des diagrammes de squences Les diagrammes de squences prsentent les intrts suivants : permettre de mieux comprendre le fonctionnement du systme ; modliser la vie des objets dans le temps et leur chronologie ; reprsenter les interactions, les communications (par messages) entre objets : messages asynchrones (traits horizontaux avec une demi-flche, messages synchrones (traits horizontaux avec une flche entire) ; dtre trs utiles dans la description des cas derreur et des cas limites dutilisation du systme [LOP4-97] ; dtre une aide prcieuse pour documenter les mthodes des classes.

4.3.4 Les diagrammes de collaboration 4.3.4.1 Origine

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

22

Les diagrammes de collaboration proviennent dune adaptation des diagrammes dobjet de Booch (object diagram), des graphes dinteraction dobjet de Fusion (object interaction graph) et dautres sources.

4.3.4.2 Dfinition Les diagrammes de collaboration montrent les interactions et les liens entre objets. Contrairement au diagrammes de squence les diagrammes de collaboration montrent les relations entre objets mais pas la dure de vie des interactions. Ils ont en commun le fait de tenir compte de la chronologie des interactions. Les diagrammes de collaboration comme les diagrammes de squence expriment la mme information, mais le montrent par des chemins diffrents [RAT9-97].

4.3.4.3 Exemples de diagrammes de collaboration On reprsente principalement dans les diagrammes de collaboration (voir figure 4.4-a et dans lannexe) : les structures statiques : les objets; les liens entre objets (comme dans les diagrammes de classes); les interactions qui sont une suite de messages (structure dynamique) changs (petites flches) que lon va numroter permettant ainsi de les lire dune manire chronologique ; On peut faire figurer aussi des contraintes, la synchronisation des squences, des arguments de message, des strotypes, etc. [MUL3-97]

4.3.4.4 Intrts des diagrammes de collaboration Les intrts des diagrammes de collaborations sont : de faire coexister les descriptions dynamiques et statiques. Ce qui donne une vision globale du systme ; de pouvoir dcrire des mthodes ou la ralisation de cas dutilisation (par exemple une suite de messages va permettre de visualiser la ralisation dune opration) et dobserver leurs effets externes ; de reprsenter un moyen indispensable de vrifier la cohrence globale dune analyse objet [LOP5-97] ; de visualiser le comportement particulier dun systme travers un acteur ;

4.4 Les diagrammes dimplmentation


On distingue les diagrammes de composants qui montrent la structure du code et les diagrammes de dploiement qui montrent la structure du systme lors de son excution.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

23

1: Etablir les connaissances sur un cours 2: Traitement

formulaire de cours : Formulaire de cours

3: Ajouter un cours : Secrtariat des inscriptions

directeur : Directeur des programmes

un cours : Cours 4: Nouveau cours

Figure 4.4-a : Diagramme de collaboration : Ouverture dun cours . On distingue : - les messages sont symboliss par des flches courtes, - les objets : rectangles dont les noms commencent par des minuscules ; - des liens inter-objets.

4.4.1 Les diagrammes de composants 4.4.1.1 Origine Les diagrammes de composants proviennent diagrammes de processus [RAT4-97]. des modules de Booch et des

4.4.1.2 Dfinition Les diagrammes de composants sont des graphes de composants connects par des relations de dpendance. Les composants sont des composants logiciels. On distingue les composants de code source, de code binaire, et les composants excutables. Un module logiciel peut tre reprsent comme un type de composant. Certains composants existent lors de la compilation, ldition des liens, et dautres lors de lexcution [RAT10-97].

4.4.1.3 Exemple de diagramme de composants Les composants sont des entits interconnectes par des liens de dpendance (voir figure 4.4.1.3-a).

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

24

Registre.exe

Registre.cpp

Personne.dll

Cours.dll

Figure 4.4.1.3-a : Diagramme de composants du projet Inscriptions au CNAM. On distingue : - un programme source : Registre.ccp, - un programme excutable : Registre.exe, - des librairies dynamiques : Personne.dll et Cours.dll. (Pour plus de dtails sur les composants comme : strotypes, tches, programmes principaux, sous-programmes, sous-systmes, etc. consulter P.A. Muller [MUL4-97]).

4.4.1.4 Intrts des diagrammes de composants Les diagrammes de composants permettent de : spcifier larchitecture logicielle du projet, dfinir les choix des composants pour le dveloppeur.

4.4.2 Diagrammes de dploiement 4.4.2.1 Origine Les diagrammes de dploiement proviennent des modules de Booch et des diagrammes de processus, mais ils sont plus centrs composants [RAT4-97].

4.4.2.2 Dfinition Les diagrammes de dploiement montrent la configuration des lments de traitement excuts et des composants logiciels, traitements, et les objets qui sont impliqus. Les instances de composants logiciels reprsentent les manifestations lors de lexcution des units de code [RAT11-97].

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

25

4.4.2.3 Exemple de diagramme de dploiement Un diagramme de dploiement est un graphe de nuds connects par des associations qui signifient la communication (voir figure 4.4.2.3-a et figure en annexe). Les nuds peuvent contenir des instances de composant ; ceci pour indiquer que le composant vit et sexcute dans le nud. Les composants peuvent contenir des objets ; cest dire que lobjet est une partie du composant. Les composants sont connects les uns aux autres par des lignes en pointill indiquant la dpendance [RAT12-97].

Enregistrement

Base de donnes

Programme principal

Rseau

Librairie

Figure 4.4.2.3-a : Inscriptions au CNAM . Les composants systmes et matriels.

4.4.2.4 Intrts des diagrammes de dploiement Les diagrammes de dploiement possdent les intrts suivants : de visualiser le ct systme en mme temps que le systme logiciel ; daffiner les spcifications de linterconnexion matrielle et logicielle.

5. GENIE LOGICIEL, CONDUITE DE PROJET AVEC UML 5.1 Dmarche fonctionnelle et dmarche objet
Les techniques et les mthodes objets se rpandent de plus en plus, mais le principal obstacle leur usage dans le sens dapplication de leurs concepts est le fait que notre esprit veut toujours nous amener une dmarche cartsienne base sur des dcompositions en fonctions et sous-fonctions : On parle de dmarche fonctionnelle.

5.1.1 La dmarche fonctionnelle

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

26

La dmarche fonctionnelle est celle que lon fait naturellement et elle reprsente une pense trs rpandue. La dmarche fonctionnelle est descendante : le point de dpart est plus abstrait (peu dinformation) que le point darrive (information dtaille). Les expressions verbales sont prpondrantes sur les expressions nominales. On fera toujours un programme principal avec un algorithme et un appel de sousprogrammes correspondant aux algorithmes associs aux sous-fonctions. On aura une dcomposition hirarchique fonctionnelle exprimant la dpendance fonctionnelle entre fonctions et sous-fonctions. Les donnes ont un comportement statique. Lutilisation et la comprhension dune procdure seffectuent avant tout par lintermdiaire de son nom et ses paramtres. Les volutions des systmes sont souvent coteuses en temps et en moyens. La qualit en cas dvolution risque de se dgrader. Plus des modifications sont faites plus il est difficile den faire des nouvelles. Les cots des contrles et des tests peuvent devenir prohibitifs. La certitude de labsence de tout effet de bord aux consquences imprvisibles est rarement obtenue. Dans la situation de concurrence du march, il est ncessaire que les socits puissent faire voluer leur systme dinformation le plus rapidement possible. Ce nest pas le cas avec une dmarche fonctionnelle et algorithmique.

5.1.2 La dmarche objet Elle est base sur le concept de lobjet cest dire unification des donnes et des traitements. Contrairement la dmarche fonctionnelle, la dmarche objet part dune modlisation constitue de modles objets (les classes) et vise construire, par assemblage, des structures de plus en plus complexes (dmarche ascendante). Un traitement particulier ne se dcompose pas en sous-traitements. Par contre, les services offerts par des objets peuvent tre combins pour offrir de nouveaux services. Les objets doivent respecter le principe de responsabilit. Cest dire que les objets sont responsables des donnes quils contiennent. Ou encore que seuls les objets connaissent la structure physique interne de leurs donnes. La modification et lutilisation des donnes ne peuvent tre effectues que grce des oprations mises au service de lobjet. Un objet peut faire appel des services dun autre objet en lui envoyant des messages. La difficult penser objet vient du fait que lon doit obtenir les mmes rsultats quavec une dmarche fonctionnelle. Les solutions obtenues par la dmarche fonctionnelle ou la dmarche objet ne diffrent que par lorganisation des traitements vis vis des donnes manipules. Dans un cas, un programme utilise dautres sous-programmes sans se proccuper particulirement des donnes. Dans lautre, un objet envoie un message un autre objet en sachant que le message envoy est fortement coupl aux donnes de lobjet rcepteur.
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

27

La modlisation objet seffectue suivant deux axes complmentaires indissociables : la modlisation statique (structurelle) et la modlisation dynamique (comportementale). Lutilisation de lobjet permet une rutilisabilit accrue. Sans dire que lajout de nouveaux objets diminue la complexit du systme, il est possible daffirmer quavec lobjet lajout de nouvelles fonctionnalits peut seffectuer plus facilement. Mais surtout on peut dire que ce qui fonctionnait avant lajout de nouvelles fonctionnalits fonctionne toujours, car les modifications peuvent tre faites indpendamment des parties existantes. La cohrence du systme est maintenue sans avoir passer des quantits de tests phnomnaux. La complexit dun systme objet crot de manire linaire (avec une pente assez rduite) avec le nombre de classes introduites, tandis que celle dun systme dvelopp partir de procdures crot de manire exponentielle avec un point de discontinuit o le systme ne peut plus saccrotre sans risque de scrouler.

5.1.3 Comparaisons des approches fonctionnelles et objets Sur le plan de lalgorithmique, les deux dmarches fournissent les mmes rsultats. La dmarche fonctionnelle ne se proccupe que des traitements et suit une dmarche imprative. La dmarche objet associe des points de vue statiques et dynamiques une dmarche ascendante. Les scnarios sont construits partir des interfaces des classes considres. La dmarche procdurale cre des entits non localisables, alors que lobjet permet de regrouper naturellement des oprations, plus facilement localisables car associes un nom d' objet connu. Labstraction en objet introduit plus de simplicit. Cela permet dunifier des concepts. La modularit naturelle lobjet et labstraction des dfinitions des interfaces entranent plus de rutilisation et de facilit pour maintenir (volutions) un systme objet comportant de nombreuses classes [LAI2-97].

5.2 Proposition dun processus dtude


1 - Ltude du projet dbute directement par lanalyse du besoin. Ceux-ci sont dtermins par linformation recueillie lors de linterview du superviseur du futur systme ou des utilisateurs de lancien systme manuel ou informatis. Ces besoins sont exprims sous la forme de cas dutilisation, dans un langage trs proche de lutilisateur. 2 - Ltude des cas dutilisation se fait un niveau de prcision forte granularit des informations reprsentes dans les interactions. Chaque cas dutilisation regroupe plusieurs scnarios dcrits dabord de manire gnrale, du niveau acteur, puis reprsents de manire plus informatique ce qui permet aussi dvaluer les cots de ralisation de lapplication. 3 - La structure statique sexprime par les relations entre les classes des objets qui participent aux collaborations. Elle est reprsente dans des bauches de
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

28

diagrammes de classes, puis finalise dans un diagramme de classes qui reprsente les abstractions cls du domaine et leurs relations. 4 - Analyse du domaine. On va constituer dfinitivement les diagrammes de classes (par AGL). 5 - Analyse de lexistant. Il tudie les caractristiques matrielles (par exemple dun lecteur de carte magntique). 6 - Les tudes se terminent par la description de larchitecture logicielle et matrielle de lapplication [MUL5-97].

5.3 Cycle de vie itratif


Le cycle de vie itratif repose sur une ide trs simple : lorsquun systme est trop complexe pour tre compris, conu ou ralis du premier coup, voire les trois la fois, il vaut mieux le raliser en plusieurs fois par volutions. Dans la nature, les systmes complexes qui fonctionnent sont toujours des volutions de systmes plus simples. La mise en uvre de cette ide nest pas aussi simple que cela dans le monde de linformatique : le logiciel ne se prte pas spontanment lvolution. Au contraire, le logiciel se rvle souvent extrmement fragile en face dun changement ou dune modification. Ceci est directement li la forme interne des programmes et au couplage qui existe entre les diffrents constituants. Leffet dune modification locale peut se propager dans lensemble de lapplication et, la limite, le basculement dun seul bit suffit pour compltement faire scrouler une application qui fonctionnait correctement auparavant. Avant de parler de dveloppement par volution, il faut sattacher rendre les logiciels plus stables et moins enclins leffondrement face lvolution. Le gnie logiciel nous apprend que pour rendre un programme plus robuste, il faut segmenter lespace des tats possibles, rduire le couplage au moyen de niveaux dabstraction et sparer les spcifications des ralisations. Lapproche objet est btie autour de concepts comme lencapsulation et la modularit qui encouragent un style de programmation dfensif : par nature, les programmes objet prsentent une rsistance plus grande face aux changements et aux surprises. Lapproche objet, de ce point de vue, favorise le dveloppement de programmes selon une dmarche itrative [MUL6-97]. Les grandes illusions : il ne faut pas croire que traditionnellement on russit le dveloppement dun projet du premier coup. Il est trs souvent possible que lon fasse des retours en arrire du dveloppement la spcification. Le dveloppement itratif ladmet et essaye de matriser la complexit, par itrations successives. 5.3.1 Approche du cycle de vie itratif
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

29

Ce nest pas : Redessiner la mme chose jusqu que cela soit parfait, une excuse pour ne pas planifier et manager un projet, quelque chose qui affecte seulement les dveloppeurs sur un projet. Cest : planifier et manager, prvoir, harmoniser les changements en exigences avec moins de dispersion, se baser sur des prototypes excutables, pas uniquement de la documentation, pousser lutilisateur/ consommateur simpliquer dans le projet, matriser les risques.

5.3.2 Trois lments importants dans lapproche itrative Intgration continue : Non fabriqu en une seule fois pour la date de livraison. Fabrication plus frquente de versions excutables : Des versions usage interne, des versions livres. Diminuer les risques travers des progrs dmontrables : Les progrs sont mesurs grce lexistence de produits (prototypes qui samliorent).

5.3.3 Bnfices rsultants La cration de nouvelles versions stimule et conduit lquipe de dveloppement achever le cycle de production intervalles rguliers : On ne peut pas avoir 90% fabriqu et 90% jeter. Cela permet dincorporer de nouveaux problmes, des solutions, des changements dans un nouveau cycle ditration sans rompre la chane de production en cours. Les personnes impliques dans le projet (testeurs, programmeurs, etc.) peuvent mieux planifier leur travail.

5.3.4 Profil de risque dun dveloppement itratif


Voir figure 5.3.4-a.

5.3.5 Management du risque phases par phases Dbut : Mettre entre parenthse les risques du projet en construisant une preuve de concept. Elaboration :
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

30

Dvelopper une comprhension commune de ltendue du projet et du comportement du projet en explorant les scnarios avec les utilisateurs finaux, et les experts du domaine ; tablir larchitecture du systme, dessiner les mcanismes communs que lon peut trouver dans le systme. Construction : Raffiner larchitecture, itration pour matriser le risque, intgration continue. Transition : Faciliter la validation par lutilisateur, mesurer la satisfaction de lutilisateur. Cycle de post-dploiement : Continuer lapproche de lvolution du produit, Prserver lintgrit architecturale.

Figure 5.3.4-a : Courbe de dcroissance du risque dans un dveloppement itratif compare celle du cycle en cascade [MUL7-97].

5.3.6 La rduction des risques conduit aux itrations Voir figure 5.3.6-a. Les risques [MUL9-97] sont: Les risques commerciaux : la concurrence peut-elle capturer le march avant que le produit ne soit prt ? Vaut-il mieux sortir une livraison minimale pour occuper le terrain ?

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

31

Les risques financiers : lentreprise dispose-t-elle de capacits financires suffisantes pour mener le projet son terme ? Les risques techniques : la base technologique est-elle solide et prouve ? Les risques de dveloppement : lquipe est-elle suffisamment exprimente et matrise-t-elle les technologies mises en uvre ?

Figure 5.3.6 : Processus ditration avec phase dlimination des risques [MUL897].

5.3.7 Phase dlaboration et itration Dans la phase dlaboration on va procder plusieurs itrations (voir figure 5.3.7a).
Dbut Elaboration Construction Transition

Itration 1

Itration 2

Itration 3

Processus en mini-cascade

Figure 5.3.7-a : Chaque itration correspond un cycle de vie en mini-cascade.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

32

5.3.8 Le cycle de vie par itration : processus en mini-cascade Voir figure 5.3.8-a. 5.3.9 Cycle de vie itrations dtailles Planning ditration : - Avant que litration commence, les objectifs gnraux de litration devront tre Etablis. Ils sont bass sur : Les rsultats des itrations prcdentes, La mise jour de l valuation des risques pour le projet. - dtermination du critre dvaluation pour cette itration, - prparation du plan dtaill ditrations pour linclure dans le plan de dveloppement.

. Rsultats des itrations prcdentes . Mise jour de lvaluation des risques . Librairies des modles contrles, code et tests

Planning ditration Recensement des exigences Analyse et dessins Implmentation Tests Nouvelle version
. Description de la version . Mise jour des risques . Librairies vrifies

Figure 5.3.8-a : Le cycle de vie en mini-cascade est appliqu chaque itration.

Recensement des exigences : - Slectionner et dfinir les cas dutilisation qui doivent tre implments dans cette itration, - mettre jour le modle objet pour y ajouter des classes sil y a lieu et de nouvelles associations dcouvertes, - dvelopper un plan de tests pour cette itration. Implmentation : - Gnrer automatiquement du code partir du modle dessin (par un AGL), - gnrer manuellement du code pour les oprations, - complter les procdures de tests, - dcrire et procder aux tests dintgration.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

33

Tests : - Intgrer et tester le code dvelopp, - enregistrer les rsultats des tests, - valuer les rsultats des tests par rapport aux critres dvaluations, - conduire une valuation de litration. Prparer la description de la nouvelle version : - Synchroniser le code et les modles graphiques, - placer les produits de litration dans des librairies dj vrifies.

5.3.10 Travail effectuer dans une itration Le travail effectuer dans une itration est : - Les cas dutilisation doivent tre implments, - le travail de modification / correction / ajout doit tre termin. Les paquetages (packages) doivent tre accessibles aux dveloppeurs : - Les paquetages de hauts niveaux doivent tre donns lquipe, - les paquetages de bas niveaux doivent tre donns aux dveloppeurs individuellement. Les cas dutilisation doivent tre accessibles pour les tests et pour les quipes qui doivent amliorer leur comprhension. Les paquetages sont utiles pour dterminer la granularit, laquelle sappliquera la dtermination de la configuration.

5.3.11 Evaluation de litration Evaluer litration rsulte des critres dvaluation tablis dans le planning ditration : - Fonctionnalit, - performance, - capacit, - mesures de qualit. On tiens compte des changements qui sont arrivs pendant litration : Par exemple, changement dans, les exigences, dans les besoins des utilisateurs, dans les projets des concurrents. Dterminer quoi refaire si ncessaire et le prvoir dans les prochaines itrations.

5.3.12 Choisir le nombre ditrations

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

34

Combien a-t-on besoin ditrations ? - Pour un projet de 18 mois environ, prvoir 3 6 itrations. Les itrations pour un projet ont-ils la mme longueur ? - Habituellement oui. - Les itrations peuvent varier par phases. Par exemple, les itrations dlaboration peuvent tre plus courtes que les itrations de construction.

5.3.13 La premire itration La premire itration est souvent la plus dure : - Elle ncessite un environnement de dveloppement complet et les quipes de dveloppement doivent tre prtes (bien organises).

Les quipes de dveloppement nouvelles, par rapport un dveloppement


itratif ne sont pas gnralement optimistes.

5.3.14 Pourquoi le cycle itratif ?

Retenir la principale raison pour laquelle on utilise un cycle de vie itratif :


Parce que lon a pas forcement toutes les informations dont on a besoin, les choses peuvent changer pendant la priode de dveloppement.

On peut sattendre ce que : - Des risques ne seront pas limins mme si on a planifi, - on va dcouvrir de nouveaux risques, - on va refaire des choses et on va jeter quelques lignes de code, lors dune itration, - les exigences et les besoins du logiciel peuvent changer au cours du temps.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

35

6. ANNEXE
Diagramme dactivits Diagramme de cas dutilisation Diagramme de collaboration Diagramme de dploiement Diagramme dobjets Diagramme de squence Paquetage Strotypes

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

36

Diagramme dactivits

Enseignant
Enseigner

Auditeur

Jury

Apprendre

Contrler les connaissances

Composer

Evaluer

Exemple de partition dun diagramme dactivits en couloirs dactivits (Voir P.A. Muller)

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

37

Diagramme de cas dutilisation

Liste des cours faire


Demander les

Professeur

S' inscrire cours un Auditeur

programmes des cours faire

Etablir les emplois du temps Secrtariat des inscriptions

Etablir son calendrier des cours Systme de facturation

Etablir la liste des cours ouvrir

Directeur des inscriptions

Dfinir les cours

Exemple de cas dutilisation : Projet Inscriptions et gestion des cours au CNAM. Les cas dutilisation (ellipses) dcrivent les fonctionnalits du systme travers les acteurs (silhouettes)

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

38

Diagramme de collaboration
faitPartie 2:rechercherCandidats(unPoste) Meunier : Personne estCandidat Conseil Recrutement : CabinetRecrutement

3:proposerCandidats(desCandidats, unPoste) 4:convoquer(unPoste)

signer 5:passerEntrevue()

estClient

1:proposerPoste(unPoste)

<<New>> ct1 : Contrat Travail signer 7:embaucher(unPoste) SSII : OOSoft : Socit

6:effectuerBilan()

Recrutement via un cabinet spcialis : - lobjet Personne est en relation avec lobjet CabinetRecrutement par le lien estCandidat, etc. - les message sont numrots chronologiquement ; - le strotype new indique que lobjet ct1 est cr pendant le processus de recrutement. La granularit dun diagramme de collaboration est plus ou moins fine, selon quil dcrit une simple opration dfinie dans un classe ou bien un ensemble doprations utilises dans lexcution dune fonction (Voir N. Lopez et Al).

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

39

Diagramme de dploiement

Diagramme de dploiement dun systme de gestion des accs dun btiment. Cet exemple montre lexistence de classes de nuds dans ce type diagramme. Le diagramme montre que les systme est constitu : - dun serveur avec des PC (10 maximum) commandant louverture et fermeture dune porte, relis par RNIS ; - un PC peut tre matre de 10 portes au maximum ; - dun serveur (TX) sur lequel sont donns les ordres, etc. (Voir P.A. Muller)

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

40

Diagrammes dobjets

:Vlomoteur

:Moteur

:Roue

:Roue

Exemple de diagramme dobjets. Le diagramme objet montre une partie de la structure gnrale de Vlomoteur. Un Vlomoteur est constitu dun moteur et deux roues. Ce diagramme est une instance du diagramme de classes suivant :

Vlomoteur

Moteur

2 Roue

Un vlomoteur contient un et un seul moteur (un moteur appartient un seul vlomoteur) et un vlomoteur possde deux roues (une roue appartient un seul vlomoteur). (Pour des dtails supplmentaires sur les diagrammes objets voir P. A. Muller)

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

41

Diagramme de squences

usager 2

:Ascenseur

usager 1

1: appel de l' ascenceur tage (RdC) a 2: bouton d' appel allume s' b-a < 300 ms b

3: ouverture des portes tage (RdC)

4: choix de l' tage (3) 5: bouton d' tage ((3) allume) s'

c
< 300 ms

6: appel de l' ascenceur tage (2)

7: bouton d' appel allume s'

d
8: ouverture des portes tage (2)

9: ouverture des portes tage (3) 10: ouverture des portes tage (3)

Deux usagers situs deux tages diffrents empruntent le mme ascenseur pour se rendre un troisime tage.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

42

Paquetage ( Package )

Auditeur CNAM

Auditeur 1..40 Choisir Cours 1..3

Paquetage Auditeur CNAM. Un paquetage est un dossier qui peut contenir diffrentes entits. En particulier il peut contenir des classes avec ou non dautres paquetages. Les paquetages peuvent tre dpendants dautres paquetages (on fera figurer une ligne pointille entre les deux paquetages), etc.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

43

Exemples de strotypes
Les strotypes peuvent tre utiliss pour tendre les lments de notation en UML. Les strotypes peuvent tre utiliss pour classer et tendre les associations, les relations dhritages, les classes et les composants. On peut avoir : - des strotypes de classes : limites, contrles, entits, utilitaires, exceptions, - strotypes dhritages : utilisations et extensions, - strotypes de composants : sous-systmes.

On prendra comme exemple des strotypes de classe suivants : signal, une occurrence remarquable qui dclenche une transaction dans un automate ; interface, une description des oprations visibles ; mtaclasse, la classe dun classe, comme en SmallTalk ; utilitaire, une classe rduite au concept de module et qui ne peut pas tre instancie. Un strotype peut tre aussi un critre de classement : module achat. Notation :

Vhicule
utilitaire

On peut suspecter dans un cet exemple une gnralisation (classe abstraite).

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

44

7. GLOSSAIRE UML

Traduit daprs UML 1.0 Glossary, 13 January 1997

1. INTRODUCTION Ce glossaire dfinit les termes employs dans la description du Langage Unifi de Modlisation.

-Aabstraction Les caractristiques essentielles d' une entit qui la distinguent de toutes les autres sortes d' entits. Une abstraction dfinit une limite relative du point de vue de l' observateur. action Un calcul ou un algorithme. activation L' excution d' une action. Autre dfinition: activation [OMA]. acteur [classe] Un strotype de type prdfini qui dsigne une entit hors du systme qui interagit avec les . cas d' utilisation activit d' analyse Activit ralise pendant la phase d' analyse de la dmarche dveloppement du de logiciel. Voir: conception, activit de modlisation. agrgat [classe] Une classe qui reprsente un " tout " dans une relation d' agrgation. Voir: agrgation. agrgation Une forme spciale d' association qui spcifie une relation "tout -partie" entre l' agrgat (le tout) et une partie. Par opposition: composition. agrgation composite
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

45

Synonyme: composition. analyse La partie de la dmarche de dveloppement du logiciel dont le but premier est de formuler un modle du domaine du problme. L' analyse montre ce qu' il faut faire et la conception montre la manire de le faire. Voir: conception. architecture L' organisation structurante d' un systme. Une architecture peut tre rcursivement dcompose en parties qui interagissent par l' inter mdiaire d' interfaces, de relations pour la connexion des parties et de contraintes pour l' assemblage de ces parties. argument Une valeur spcifique qui correspond un paramtre. Synonyme: paramtre effectif. Par opposition: paramtre. artefact Une information qui est utilise ou produite par une dmarche de dveloppement de logiciel. Un artefact peut tre un modle, une description ou un logiciel. aspect comportemental du modle Un aspect du modle qui insiste sur le comportement des objets dans un systme, incluant leurs mthodes, leurs interactions, leurs collaborations et l' historique de leurs tats. aspect structurel du modle Un aspect du modle qui met l' accent sur la structure des objets dans un systme, incluant leurs types, classes, relations, attributs et oprations. aspect du modle Une dimension de modlisation qui met l' accent sur des qualits particulires du mtamodle. Par exemple: l' aspect structurel du modle met l' accent sur les qualits structurelles du mtamodle. association Une relation qui dcrit un ensemble de liens. association binaire Une association entre deux classes. Un cas particulier d' une association n-aire. association de communication Dans un diagramme de dploiement, une association entre les n uds qui implique une communication. Voir: diagramme de dploiement. association n-aire Une association parmi 3 classes ou plus. Chaque instance de l' association est un n-tuple de valeurs des classes respectives. Par opposition: association binaire.
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

46

attribut Une proprit nomme d' un type. Synonyme: attribut [ONMI automate Un comportement qui spcifie les squences d' tats traverses par un objet ou une interaction en rponse des vnements, accompagns des rponses et des actions.

-Bbesoin Une caractristique, une proprit, ou un comportement dsir pour un systme. boolen Une numration dont les valeurs sont vrai ou faux.

-Ccardinalit Le nombre d' lments d' un ensemble. Par opposition: multiplicit. cas d' utilisation [classe] Une classe qui dfinie un ensemble d' instances de cas dutilisation . chane Une squence de caractres. Les dtails de reprsentation d' une chane dpendent de sa ralisation et peuvent comprendre des caractres internationaux et graphiques. classe Une description d' un ensembl d' objets qui partage les mmes attributs, e oprations, mthodes, relations et contraintes. Une classe ralise un type. Synonyme: classe [OMA]. Voir: type, ralisation. classe abstraite Une classe qui ne peut pas tre instantie directement. Par opposition: classe concrte. classe active Une classe dont les instances sont des objets actifs. Voir: objet actif. classe-association Un lment de modlisation qui possde la fois des proprits d' association et de classe. Une classe-association peut tre vue comme une association qui a galement des proprits de classe, ou comme une classe qui a galement des proprits d' association.
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

47

classe concrte Une classe qui peut tre instantie directement. Par opposition: classe abstraite. classe paramtrable Le descripteur d' une classe avec un ou plusieurs paramtres non limits. Synonyme: modle. classification dynamique Une variation smantique de gnralisation dans laquelle un objet peut changer de type ou de rle. Par opposition: classification statique. classification multiple Une variation smantique de gnralisation dans laquelle un objet peut directement appartenir plus d' une classe. Voir: classification dynamique. classification statique Une variation smantique de gnralisation dans laquelle un objet ne peut pas changer de type et de rle. Par opposition: classification dynamique. client Un type, une classe, ou un composant qui requiert un service d' un autre type, d' une autre classe ou d' un autre composant. Synonyme: objet client [OMA], Pa r opposition: fournisseur. collaboration Un contexte qui permet un ensemble d' interactions. Voir: interaction. compilation Compilation d' un module du logiciel. Voir: modlisation, excution. comportement Les effets observables d' une opration ou d' unvnement, incluant ses rsultats. Synonyme: comportement [OMA]. composant Un module du logiciel excutable avec une identit et une interface bien dfinies. Autre dfinition: composant[OMA]. composite [classe] Une classe relie une ou plusieurs classe s par une relation de composition. Voir: composition. composition Une forme d' agrgation qui exprime une forte proprit entre le tout et les parties, ainsi qu' une subordination entre l' existence des parties et du tout. Les parties, dont la multiplicit est non fige, peuvent tre cres aprs le composite lui-mme, mais une fois cres, elles vivent et meurent avec lui (c. --d elles partagent sa dure de vie). De telles parties peuvent galement tre explicitement retires avant la mort
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

48

du composite. La composition peut tre rcursive. Synonyme: agrgation composite. conception Activit ralise pendant la phase de conception dans le dveloppement du logiciel. Voir: modlisation. Par opposition: analyse. condition de garde Une condition qui doit tre satisfaite pour valider le dclenchement de la transition qui lui est associe. conteneur 1. Un objet qui contient d' autres objets, et qui fournit les oprations pour accder son contenu. Par exemple des tableaux, des ensembles, des dictionnaires. 2. Un composant qui contient d' autres composants. contexte Une vue d' un ensemble d' lments de modlisation mis en relation dans un but particulier, comme la spcification d' une opration. contrainte Une condition smantique ou restriction. Certaines contraintes sont prdfinies dans le langage UML, d' autres peuvent tre dfinies par l' utilisateur. Les contraintes constituent un des trois mcanismes d' extension du langage UML. Voir: tiquette, strotype. Par opposition: note. couche Un moyen spcifique de grouper les paquetages de mme niveau d' abstraction dans un modle. couloir Une partition des diagrammes d' interaction pour organiser les responsabilits des actions. Ces partitions correspondent souvent aux units organisationnelles dans un modle d' entrepris. e

-Ddclenchement Provoque une transition. Voir: transition. dmarche de dveloppement Un ensemble d' tapes partiellement ordonnes excutes dans un but donn pendant le dveloppement de logiciels, comme la construction ou la ralisation de modles.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

49

destinataire [objet] L' objet qui traite un message transmis par un objet metteur. Par opposition: metteur. diagramme Une reprsentation graphique d' une collection d' lments de modlisation, le plus souvent visualise comme un graphe d' arcs (relat ions) et de sommets (autres lments de modlisation). Le langage UML offre les diagrammes suivants: diagramme de classes, diagramme d' objets diagramme de cas d' utilisation, , diagramme de squence, diagramme de collaboration, diagramme d' tats transitoires, diagramme d' activits diagramme de composants et diagramme de , dploiement. diagramme d' activits Un cas particulier de diagramme d' tats transitoires dans lequel tous les tats (ou presque) sont des tats avec action, et dans lequel toutes les transitions (ou presque) sont dclenches par l' achvement d' actions dans les tats sources. Par . opposition: diagramme d' tats transitoires diagramme de cas d' utilisation Un diagramme qui montre les relations entre acteurs et cas d' utilisationdans un systme. diagramme de classes Un diagramme qui montre un ensemble d' lments de modlisation dclaratifs (statiques), comme les classes, les types, avec leurs contenus et relations. diagramme de collaboration Un diagramme qui montre les interactions entre objets par une reprsentation des objets et des liens qui les relient. A la diffrence d' un diagramme de squence, le diagramme de collaboration montre les relations entre les objets. Les diagrammes de squence, et les diagrammes de collaboration montrent des informations similaires, selon des points de vue diffrents mais de manires diffrentes. diagramme de composants Un diagramme qui montre les dpendances entre les composants. diagramme d' tats transitoires Un diagramme qui montre un automate. Voir: automate. diagramme de squence Un diagramme qui montre les interactions d' objet d' un point de vue temporel. Il montre, en particulier, les objets participant l' interaction et la squence des messages changs. Contrairement un diagramme de collaboration, un diagramme de squence inclut des squences temporelles mais ne montre pas de liens entre objets. Un diagramme de squence peut exister sous une forme gnrique (qui dcrit tous les scnarios possibles) et sous une forme d' instance (qui dcrit un scnar io
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

50

particulier). Les diagrammes de squence et les diagrammes de collaboration expriment la mme information mais de manires diffrentes. Voir: diagramme de collaboration. diagramme de dploiement uds de traitement et les Un diagramme qui montre la configuration des n composants, les processus et les objets qui les accompagnent. Les composants reprsentent les manifestations excutables des units de code. Voir: diagramme de composants. diagramme d'i nteraction Un terme gnrique qui s' applique diffrets types de diagrammes qui mettent n l' accent sur les interactions entre objets. Ceux comprennent: les diagrammes de -ci collaboration, les diagrammes de squence et les diagrammes d' activits. Voir: diagramme dactivit, diagramme de collaboration, diagramme de squence. diagramme d' objets Un diagramme qui englobe les objets et leurs liens un moment donn. Un diagramme d' objet peut tre considr comme un cas particulier d' un diagramme de classes ou d' un diagramme de collaboration. Voir: diagramme de classe, diagramme de collaboration. dlgation La capacit d' un objet mettre un message vers un autre objet en rponse un message. La dlgation peut tre utilise comme une alternative l' hritage. Synonyme: dlgation [OMA]. Par opposition: hritage. dmarche Un fil de contrle qui peut tre excut en parallle avec d' autres fils de contrle. dpendance Une relation entre deux lments de modlisation, par laquelle un changement dans un lment de modlisation (llment indpendant) va galement provoquer un changement dans lautre lment de modlisation (llment dpendant). domaine Un domaine de connaissances ou d' activits caractris par un ensemble de concepts et une technologie propre aux praticiens de ce domaine.

-Elment Un constituant atomique d' un modle. lment driv


Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

51

Un lment de modlisation qui peut tre calcul partir d' un autre lment, mais qui est montr titre informatif ou qui est inclus dans des buts de conception bien qu' il n' ajoute pas d' information smanti que. lment de visualisation Un lment de visualisation est une projection textuelle ou/et graphique d' une collection d' lments d' un modle. lment du modle Une abstraction extraite du systme modlis. lment gnralisable Un lment de modlisation qui peut prendre part une relation de gnralisation. Voir: Gnralisation. metteur (objet) L' objet transmettant un message vers un objet rcepteur. Voir: destinataire. numration Une liste de valeurs nommes utilise comme domaine de dfinition d' un type d' attribut particulier. Par exemple: Couleur = {Rouge, Vert, Bleu} envoyer (un message) La transmission d' un message d' un objet metteur vers un objet rcepteur. Voir: destinataire metteur. espace de nom Une partie du modle dans lequel les noms peuvent tre dfinis et utiliss. Dans un espace de nom, chaque nom a une signification unique. Voir: nom. tat Une condition ou une situation qui intervient pendant la dure de vie d' un objet, et qui correspond la satisfaction d' une condition, laralisation d' une activit ou l' attente d' un vnement. Autre dfinition: tat [OMA]. tat avec action Un tat avec une action interne et une ou plusieurs transitions sortantes valides par l' achvement de l' action interne. tat composite Un tat qui contient des sous-tats. Par opposition: sous-tat. tiquette La dfinition explicite d' une proprit sous la forme d' un couple nom -valeur. Certaines tiquettes sont prdfinies dans le langage UML; d' autres peuvent tre dfinies par l' utilisateur. Les tiqettes constituent un des trois mcanismes u d' extension du langage UML. Voir: contrainte, strotype.
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

52

vnement Une occurrence significative. Un vnement est localis dans le temps et l' espace et peut avoir des paramtres. Dans le cas des diagrammes d' tattransitoires, un vnement est une occurrence qui peut dclencher une transition. vnement temporel Un vnement qui a lieu un moment particulier. Il peut tre exprim comme une expression temporelle. Voir: vnement. excution La priode pendant laquelle un programme s' excute. Voir: modlisation. export Dans le contexte des paquetages, sert rendre visible un lment en dehors de l' espace de nom qui le contient. Voir: visibilit. Autre dfinition: export [OMA]. Par opposition: import. expression Une chane qui renvoie une valeur d' un type particulier. Par exemple: l' expression (7+5 * 3) renvoie une valeur du type nombre. expression boolenne Une expression dont l' valuation donne une valeur boolenne. expression d' actions Une expression constitue d' une collection d' actions. expression de type Une expression qui fait rfrence un ou plusieurs types. expression temporelle Une expression qui renvoie une valeur de temps relative ou absolue. extensions Une relation entre un cas d' utilisatio et un autre, qui spcifie la manire dont le n comportement dfini pour le premier cas d' utilisation peut tre insr dans le comportement dfini pour le second cas d' utilisation.

-Ffil de contrle Un chemin unique d' excution dans un programme, un modle dynamique, ou une reprsentation de flux de contrle. Synonyme: fil de contrle. Voir: dmarche. fournisseur

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

53

Un type, une classe ou un composant qui fournit des services qui peuvent tre appels par d' autres types, classes ou composants. Synonyme: objet serveur[OMA]. Par opposition: client. framework Une micro-architecture qui fournit un schma extensible pour des applications dans un domaine spcifique.

-Ggnralisation Une relation taxonomique entre un lment plus gnral et un lment plus spcifique. L' lment le plus spcifique est entirement compatible avec l' lment le plus gnral et contient des informations supplmentaires. Une instance de l' lment le plus spcifique peut tre utilise l' endroit o l' utilisation de l' lment le plus gnral est autorise. Synonyme: gnralisation [OMA]. Voir: hritage.

-Hhritage Le mcanisme par lequel des lments plus spcifiques incorporent la structure et le comportement d' lments plus gnraux. Voir: gnralisation. Synonyme: hritage [OMA] hritage d'i nterface Hritage d' interface d' un lment plus gnral. N' inclut pas l' hritage de la ralisation. Synonyme: hritage d' interface [OMA]. Par opposition: hritage de ralisation. hritage de ralisation Hritage de ralisation d' unlment plus gnral. Inclut l' hritage de l' interface. Synonyme: hritage de ralisation [OMA]. Par opposition: hritage dinterface. hritage multiple Une variation smantique de la gnralisation par laquelle un type peut avoir plus d' un supertype.Par opposition: hritage simple. hritage simple Une variation smantique de la gnralisation par laquelle un type ne peut avoir qu' un seul supertype. Synonyme: hritage simple [OMA]. Par opposition:hritage multiple.

-ITout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

54

import Dans le contexte des paquetages, une relation de dpendance qui montre les paquetages dont les classes peuvent tre rfrences dans un paquetage donn (y compris les paquetages embots de faon rcursive). Autre dfinition: import [OMA]. Par opposition: export. instance Un membre individuel dcrit par un type ou une classe. Note d' usage: selon une stricte interprtation du mtamodle, un membre individuel d' un type est une instance et un membre individuel d' une classe est un objet. Dans un usage moins formel, il est accept de faire rfrence un membre d' une classe comme un objet ou une instance. Voir: type. Par opposition: objet. instance de cas d' utilisation Une squence d' actions produite par un systme qui procure un rsultat. Habituellement, les scnarios illustrent les instances des cas d' utilisation caractre de prototypes. Une instance d' une classe de cas d' utilisation. Voir: classe de cas d' utilisation . interaction Une spcification du comportement qui comprend un ensemble d' changes de message parmi un ensemble d' objets dans un contexte particulier ddi une cause spcifique. Une interaction peut tre illustre par un ou plusieurs scnarios. interface L' utilisation d' un type pour dcrire le comportement visible de l' extrieur d' une classe, d' un objet ou d une autre entit. Dans le cas d' une classe vu de l' extrieur ' ou d' un objet, l' interface comprend les signatures des oprations. Synonyme: interface [OMA]. Voir: type.

-Llien Une connexion smantique parmi un tuple d' objets. Une instance d' une association. Synonyme: lien [OMA]. Voir: association.

ligne de vie d' un objet Une ligne dans un diagramme de squence qui reprsente l' existence d' un objet pendant un temps donn. Voir: diagramme de squence. liste Un conteneur dont les lments sont ordonns,

-MTout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

55

marque temporelle Une dnotation du moment auquel a lieu un vnement ou un message. Les marques temporelles peuvent tre utilises dans les contraintes. membre Une partie d' un type ou d' une classe qui indique un attribut ou une opration. message Une communication entre objets qui transporte de l' information dans le but de dclencher une action en retour. La rception du message est normalement considre comme un vnement. message asynchrone Un message ou l' objet metteur n' attend pas la rp onse. Synonyme: requte asynchrone [0MA]. Par opposition: message synchrone. message synchrone Un message dans lequel l' metteur la rponse. Synonyme: requte synchronise [OMA]. Par opposition: message asynchrone. mtaclasse Une classes dont les instances sont des classes. En rgle gnrale, les mtaclasses sont utilises pour construire des mtamodles. mta-mtamodle Un modle qui dfinit le langage pour exprimer un mtamodle. La relation entre un mta-mtamodle et un mtamodle est analogue celle entre un mtamodle et un modle. mtamodle Modle qui dfini le langage pour exprimer un modle. Une instance de mtamtamodle. mtaobjet Un terme gnrique pour toutes les mtaentits dans un langage de mtamodlisation. Par exemple: mtatypes, mtaclasses, mtaattributs, mtaassociations. Synonyme: mtaobjet [OMA]. mtatype Un type dont les instances sont des types. En rgle gnrale, les mtatypes sont utiliss pour construire des mtamodles. mthode La ralisation d' une opration. L' algorithme la procdure qui donne le rsultat ou d' une opration. Synonyme: mthode [OMA]. modle Synonyme: classe paramtrable.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

56

modle Une abstraction d' un systme ferme smantiquement. Voir: Systme. modle de cas d' utilisation Un modle qui dcrit les besoins fonctionnels d' un systme en termes decas d' utilisation . modlisation Activit ralise pendant la phase de modlisation de la dmarche de dveloppement du logiciel. Elle inclut l' analyse et la conception. Note d' usage: il est important de faire la diffrence entre la phase de modlisation et la phase d' excution. Voir: analyse, conception. Par opposition: excution. module Une unit logicielle de stockage et de manipulation. Les modules comprennent les modules de code source, les modules de code binaire, et les modules de code excutable. Voir: composant. multiplicit Une spcification des valeurs de cardinalit admissibles pour un ensemble. Les spcifications de la multiplicit peuvent tre donnes pour des rles au sein des associations, pour des parties des composites, pour des rptitions, ou dans d' autres buts. Une multiplicit est un sous -ensemble (ventuellement infini) d' entiers naturels. Par opposition: cardinalit.

-Nnom Une chane utilise pour identifier un lment du modle. non interprt Une place rserve un type ou aux types dont la ralisation n' est pas spcifie par le langage UML. Chaque valeur non interprte possde une reprsentation sous la forme d' une chaine de caractres. Voir: any [CORBA]. nud Un n est un objet ph ysique d' excution qui reprsente une ressource de ud calcul, possdant gnralement de la mmoire et offrant une capacit de traitement. Les objets d' excution et les composants peuvent rsider sur les n uds. note Un commentaire attach un lment ou une collection d' lments. Une note n' a pas de smantique. Par opposition: contrainte.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

57

-Oobjet Une entit avec une limite et une identit bien dfinies qui encapsule de l' tat et du comportement. L' tat est reprsent par des attributs et des relations, le comportement est reprsent par des oprations et des mthodes. Un objet est une instance d' une classe. Synonyme: objet [OMA]. Voir:classe, instance. objet actif Un objet qui possde un fil de contrle et qui peut dclencher une interaction. Une instance de classe active. Voir: classe active. objet persistant Un objet qui continu d' exister aprs la mort du processus qui l' a cr. Synonyme: objet persistant [OMA]. objet transitoire Un objet qui n' existe que durant l' excution du processus ou du filedcontrle qui lui a donn naissance. Synonyme: objet transitoire [OMA]. opration Un service qui peut tre requis par un objet pour agir sur le comportement. Une opration a une signature, qui peut restreindre les paramtres effectifs possibles. Synonyme: opration [OMA].

-Ppaquetage Un mcanisme universel pour grouper des lments. Les paquetages peuvent tre embots les uns dans les autres. Un systme peut tre vu comme un seul paquetage abstrait qui contient tout le reste. paralllisme Le droulement de deux ou plusieurs activits pendant le mme intervalle de temps. Voir: fil de contrle. paramtre La spcification d' une variable qui peut tre change, transmise, ou retourne. Un paramtre peut inclure un nom, un type, et une direction. Les paramtres sont utiliss par les oprations, les messages et les vnements. Synonymes: paramtres [OMA], paramtre formel. Par opposition: argument. paramtre effectif Synonyme: argument. paramtre formel
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

58

Synonyme: paramtre. participe Une relation qui indique le rle que joue une instance dans un lment de modlisation. Par exemple, une chane participe une association, un acteur un cas d' utilisation. Autre dfinition participe [OMA]. priode d' activit Un symbole dans un diagramme de squence qui montre la priode durant laquelle un objet ralise une action, soit directement soit par l' intermdiaire d' une procdure subordonne. phase de conception La partie du dveloppement du logiciel dont le but premier est de dcider comment le systme va tre ralis. Pendant la phase de conception, les dcisions stratgiques et tactiques sont prises pour satisfaire les besoins (fonctions, niveau de qualit) dun systme. phase d' excution La priode pendant modlisation.

laquelle

un

programme

s' excute.

Par

opposition:

point de variation smantique Un point de variation dans la smantique d' un mtamodle. Il fournit un degr de libert intentionnel pour l' interprtation de la smantique du mtamodle. Voir: variation smantique. post-condition Une contrainte qui doit tre vrifie aprs l' excution d' une opration. powertype Un mtatype dont les instances sont des sous-types d' un autre type. Par exemple, Sorte_d_Arbres est un powertype de type Arbre. Les sous types (i. e., Frne, Bouleau, Cerisier) sont alors leurs instances de Sorte_d_Arbres. prcondition Une contrainte qui doit tre vrifie quand une opration est appele. produit Les artefacts de dveloppement, comme les modles, le code, la documentation ou les plans de dveloppement. projection Relation qui extrait un sous-ensemble d' un ensemble. projection visuelle Une projection d' lments de modlisation vers des lments de visualisation. Une projection visuelle fournit un emplacement et un style pour chaque lment de visualisation.
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

59

proprit Une valeur nomme qui dnote la caractristique d' un lment. Une proprit a un impact smantique. Certaines proprits sont prdfinies dans le langage UML, d' autres peuvent tre dfinies par l' utilisateur. Voir: tiquette. Synonyme: proprit [0MA]. pseudo-tat Un sommet dans un automate qui a la forme d' un tat, mais qui ne se comporte pas comme un tat. Les pseudo-tats comportent les tats initiaux, finaux et l' historique.

-Rraffinement Une relation qui reprsente les spcifications plus compltes d' un lment dj spcifi un certain niveau de dtail. Par exemple, une classe de conception est un raffinement d' une classe d' analyse. ralisation Manire dont quelque chose est construit ou calcul. Par exemple, une classe est une ralisation d' un type, une mthode est une ralisation d' une opration. Synonyme: ralisation [OMA]. rception (d' un message) Le traitement d' un message transmis par un objet metteur. Voir: metteur, destinataire. rfrence Une dnotation d' un lment de modlisat ion. relation Une connexion smantique entre les lments de modlisation. Les relations comprennent les associations et les gnralisations. responsabilit Un contrat ou une obligation d' un type ou d' une classe. restriction Un attribut ou un tuple d' at tributs dont les valeurs partitionnent l' ensemble des objets dnots par une association. rutilisation L' utilisation d' un artefact prexistant. rle
Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

60

Le nommage d' un comportement spcifique d' une entit participant dans un contexte particulier. Un rle peut tre statique (comme un rle d' association) ou dynamique (comme un rle de collaboration). rle (d' association) Le rle que joue un type ou une classe dans une association. rle du lien . Une instance d' un rle d' association. Voir: (d' association) rle

-Sscnario Une squence spcifique d' actions qui illustre des comportements. Un scnario peut tre utilis pour illustrer une interaction. Voir: interaction. signal Un vnement nomm qui peut tre explicitement invoqu (" lev "). Les signaux peuvent avoir des paramtres. Un signal peut tre diffus ou dirig vers un objet unique ou un ensemble d' objets. signature Le nom et les paramtres d' une opration, d' un message ou d' un vnement. Les paramtres peuvent comporter un paramtre de retour optionnel. Synonyme: signature [OMA]. sommet Une source ou une cible pour une transition dans un automate. Un sommet peut tre soit un tat soit un pseudo tat. Voir: tat, pseudo-tat. sous-classe La spcialisation d' une autre classe, la super -classe, dans une relation de gnralisation. Voir: gnralisation. Par opposition: superclasse. sous-tat Un tat qui appartient un tat composite. Un sous -tat peut tre soit un sous-tat parallle ou un sous-tat disjoint. Voir: tat parallle, tat disjoint. sous-tat disjoint Un sous-tat qui ne peut pas tre actif simultanment avec d' autres sous -tats contenus dans le mme tat composite. Voir: tat composite. Par opposition: soustat parallle. sous-tat parallle

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

61

Un sous-tat qui peut tre actif en mme temps que d' autres sous -tats contenus dans le mme tat composite. Voir: tat composite. Par opposition: sous-tat disjoint. sous-systme Un systme subalterne d' un systme plus important. Dans le langage UML, un sous-systme est modlis comme un paquetage de composants. Par opposition: systme. sous-type La spcialisation d' un autre type, le super -type, dans une relation de gnralisation. Voir: gnralisation. Par opposition: supertype. spcification Une dclarative de ce qu' une entit est ou fait. Par opposition: ralisation. strotype Un nouveau type d' lment de modlisation qui tend la smantique du mtamodle. Les strotypes doivent tre bass sur certains types ou classes existants dans le mtamodle. Les strotypes peuvent tendre la smantique, mais pas la structure des types et des classes prexistants. Certains strotypes sont prdfinis dans le langage UML, d' autres peuvent tre dfinis par l' utilisateur. Les strotypes constituent un des trois mcanismes d' extension du langage UML. Voir: contrainte, tiquette. superclasse La gnralisation d' une autre classe, la sous -classe, dans une relation de gnralisation. Voir: gnralisation. Par opposition: sous-classe. supertype La gnralisation d' un autre type, le sous -type, dans une relation de gnralisation. Synonyme: supertype [OMA]. Voir: gnralisation. Par opposition: sous-type. systme Une collection d' units connectes qui sont organises afin d' atteindre un but spcifique. Un systme peut tre dcrit par un ou plusieurs modles ventuellement selon diffrents points de vue.

-Ttemps Une valeur reprsentant un moment relatif ou absolu dans le temps. transition

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

62

Une relation entre deux tats qui indique qu' un objet dans le premier tat ralisera certaines actions spcifiques et passera dans le second tat quand un vnement prcis aura eu lieu et quand des conditions donnes auront t satisfaites. Un tel changement d' tat est appel dclenchement d' une transition. type Une description d' un ensemble d' instances qui part agent les mmes oprations, les mmes attributs abstraits, les mmes relations et les mmes contraintes. Un type peut dfinir la spcification d' une opration (comme une signature) mais pas la ralisation d' une opration (comme une mthode). Note d' usage: terme le type est parfois utilis comme un synonyme du mot interface, mais ce ne sont pas des termes quivalents. Synonyme: type [OMA]. Voir: classe, instance. Par opposition: interface. type primitif Un type de base prdfini comme un entier ou une chane.

-Uunit de distribution Un ensemble d' objets ou de composants qui sont allous en une fois un processus ou un processeur. Dans le langage UML, une unit de distribution peut tre reprsente par un composite d' excution ou un agrgat. utilise Une relation entre un cas d' utilisation concret et un cas d' utilisation abstrait par laquelle le comportement dfini dans le cas d' utilisation concret utilise le comportement dfini dans le cas d' utilisation abstrait. utilitaire Un strotype de type qui groupe les variables globales et procdures sous la forme d' une dclaration de classe. Les attributs et les oprations utilitaires deviennent respectivement des variables et des procdures globales. Un utilitaire n' est pas une construction de modlisatio fondamentale mais une commodit de n programmation.

-Vvaleur Un lment d' un domaine de type. Par opposition: valeur [OMA]. variation smantique Un choix d' interprtation particulier pour un point de variation smantique. Voir: point de variation

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

63

visibilit Une numration dont la valeur (publique, protge, prive, ou de ralisation) dnote la faon dont l' lment de modlisation, auquel elle fait rfrence, est vue en dehors de son espace de nom. vue Une projection d' un modle qui est vue selon une perspective donne et qui omet les entits qui ne relvent pas de cette perspective. __________________

Divers
CORBA Architecture : Architecture de systme ouvert objets rpartis dcrite et normalise par lOMG. Common Object Request Broker OMA Object Management Architecture Modle dfini et normalis pour CORBA par lOMG.

__________________

Glossaire UML . Version 1.0. Juin 1997 Traduction Eric Schatz, Herv Gissinger, Pierre-Alain Muller - ESSAIM. Ecole Suprieure des Sciences Appliques pour lIngnieur Mulhouse http://www.essaim.univ-mulhouse.fr Complments du Glossaire : Laurent Gouthire

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

64

8. BIBLIOGRAPHIE
[HAR1-84] D. Harel, Statecharts : A visual approach to complex systems, CS84-05, Departement of Applied Mathematics, The Weizmann Institut of Science, 1984. [LAI1-97] M. Lai, La notation unifie de modlisation objet, Les machines dtats finis, p 171, InterEditions, 1997. [LAI2-97] M. Lai, La notation unifie de modlisation objet, Lapproche fonctionnelle et lapproche objet, p 159-170, InterEditions, 1997. [LOP1-97] N. Lopez, J. Migueis, E. Pichon, Intgrer UML dans vos projets, p 74, Eyrolles, 1997. [LOP2-97] N. Lopez, J. Migueis, E. Pichon, Intgrer UML dans vos projets, p 235, Eyrolles, 1997. [LOP3-97] N. Lopez, J. Migueis, E. Pichon, Intgrer UML dans vos projets, p 122123, Eyrolles, 1997. [LOP4-97] N. Lopez, J. Migueis, E. Pichon, Intgrer UML dans vos projets, p 122128, Eyrolles, 1997. [LOP5-97] N. Lopez, J. Migueis, E. Pichon, Intgrer UML dans vos projets, p 130, Eyrolles, 1997. [MUL1-97] P.A. Muller, Modlisation avec UML, p 11, Eyrolles, 1997. [MUL2-97] P.A. Muller, Modlisation avec UML, p 148, Eyrolles, 1997. [MUL3-97] P.A. Muller, Modlisation avec UML, p 139-146, Eyrolles, 1997. [MUL4-97] P.A. Muller, Modlisation avec UML, p 182-188, Eyrolles, 1997. [MUL5-97] P.A. Muller, Modlisation avec UML, p 281-347, Eyrolles, 1997. [MUL6-97] P.A. Muller, Modlisation avec UML, p 232-233, Eyrolles, 1997. [MUL7-97] P.A. Muller, Modlisation avec UML, p 256, Eyrolles, 1997. [MUL8-97] P.A. Muller, Modlisation avec UML, p 255, Eyrolles, 1997. [MUL9-97] P.A. Muller, Modlisation avec UML, p 254, Eyrolles, 1997. [RAT1-97] Rational Software, UML Summary, version 1.0, 13 January 1997, p 2, www.rational.com/uml/, 1997.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

65

[RAT2-97] Rational Software, UML Summary, version 1.0, 13 January 1997, p 4, www.rational.com/uml/, 1997. [RAT3-97] Rational Software, www.rational.com/uml/, 1997. Analysis end Design with UML, p 10,

[RAT4-97] Rational Software, UML Summary version 1.0, 13 January 1997, p 9, www.rational.com/uml/, 1997. [RAT5-97] Rational Software, UML Notation guide version 1.0, 13 January 1997, p 90, www.rational.com/uml/, 1997. [RAT6-97] Rational Software, UML Notation guide version 1.0, 13 January 1997, p 106, www.rational.com/uml/, 1997. [RAT7-97] Rational Software, UML Notation guide version 1.0, 13 January 1997, p 107, www.rational.com/uml/, 1997. [RAT8-97] Rational Software, UML Notation guide version 1.0, 13 January 1997, p 66, www.rational.com/uml/, 1997. [RAT9-97] Rational Software, UML Notation guide version 1.0, 13 January 1997, p 73, www.rational.com/uml/, 1997. [RAT10-97] Rational Software, UML Notation guide version 1.0, 13 January 1997, p 114, www.rational.com/uml/, 1997. [RAT11-97] Rational Software, UML Notation guide version 1.0, 13 January 1997, p 115-116, www.rational.com/uml/, 1997. [RAT12-97] Rational Software, UML Notation guide version 1.0, 13 January 1997, p 115-120, www.rational.com/uml/, 1997. [RUM1-96] J. Rumbaugh et al., OMT 1. Modlisation et conception orientes objet, Masson, 1996. [TAR1-83] H. Tardieu, A. Rochfeld, R. Coletti, M. Vahe, La mthode Merise, Editions dOrganisation, 1983. [WIL1-96] Wiley, Pattern-Oriented Software Architecture : A System of Patterns, ISBN 047195897, 1996.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

66

9. REFERENCES

Scott W. Ambler, How the UML Models Fit Together, http://sdmagazine.com/uml/, 1998. * Grady Booch, Object Oriented Analysis and Design with Applications, 2e dition, Addison and Wesley, 1994. Agusti Canals, UML-Cisi : un processus de conception pour le langage de modlisation UML, Cisi, 13, rue Villet, ZI du Palays BP4042, 31029 Toulouse Cedex 4, France, http://www.essaim.univ-mulhouse.fr, 1998. * Martin Folder, Why Use the UML ?, http://www.sdmagazine.com/uml/, 1998. * Ivar Jacobson, M. Christerson, P. Jonsson, G. Overgaard, Object Oriented Software Engineering : A Use Case Driven Approach, Addison and Wesley, 1992. Michel Lai, UML La notation unifie de modlisation objet. Applications en Java, InterEditions, ISBN : 2-7296-0659-9, Juillet 1997. * Nathalie Lopez, Jorge Migueis, Emmanuel Pichon, Intgrer UML dans vos projets, Eyrolles, ISBN : 2-212-08952-X, Octobre 1997. * Pierre-Alain Muller, Modlisation avec UML, Eyrolles, ISBN : 2-212-08966-X, Septembre 1997. * Rational Software Corporation, Analysis and design with UML, 2800 San Tomas Expressway Santa Clara CA 95051-0951, http://www.rational.com, 1997. * Rational Software Corporation, UML Notation Guide, version 1.0, 13 January 1997, 2800 San Tomas Expressway Santa Clara CA 95051-0951, http://www.rational.com, Janvier 1997. * Rational Software Corporation, UML Process-Specific Extensions, version 1.0, 13 January 1997, 2800 San Tomas Expressway Santa Clara CA 95051-0951, http://www.rational.com, Janvier 1997. * Rational Software Corporation, UML Semantics, version 1.0, 13 January 1997, 2800 San Tomas Expressway Santa Clara CA 95051-0951, http://www.rational.com, Janvier 1997. * Rational Software Corporation, UML Semantics Appendix M1 - UML Glossary, version 1.0, 13 January 1997, 2800 San Tomas Expressway Santa Clara CA 95051-0951, http://www.rational.com, Janvier 1997. *

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

67

Rational Software Corporation, UML Summary, version 1.0, 13 January 1997, 2800 San Tomas Expressway Santa Clara CA 95051-0951, http://www.rational.com, Janvier 1997. * Doug Rosenberg, UML Applied : Nine Tips to Incorporating UML into Your Project, http://sdmagazine.com/uml/, 1998. * James Rumbaugh et al., OMT 1. Modlisation et conception orientes objet, Masson Prentice Hall, ISBN : 2-225-84684-7, Novembre 1996. * James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen, OMT 2. Solution des exercices, Masson Prentice Hall, ISBN : 2-22585138-7, Mars 1996. *

(*) Ouvrages consults pour la ralisation de ce document. Les autres sont des livres ou des articles auxquels on pourra se rfrer pour complments dinformation.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

68

10. ADRESSES INTERNET

Le site de Rational Software Corporation o lon peut trouver : la documentation sur UML version 1.0 et 1.1; lAGL Rose 98 gratuit dure limite dun mois : http://rational.com Des articles sur UML et un forum de discussion : http://sdmagazine.com/uml Informations gnrales sur UML. Ecole Suprieur des Sciences Appliques pour lIngnieur - Mulhouse : http://www.essaim.univ-mulhouse.fr Description de diffrentes normes objets par lOMG (Object Management Group) : http://www.omg.org

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Mthode UML : Le langage de modlisation objet unifi

69

RESUME
UML signifie Unified Modeling Language. On parle de langage de modlisation plutt que de mthode, car UML possde un vocabulaire, une syntaxe et u ne smantique. UML provient de la fusion des principales mthodes objet comme OMT (Object Modeling Technique), Booch (du nom de son auteur), OOSE (Object Oriented Software Engineering) et dautres etc. UML a ralli pour sa normalisation un consortium dentreprises comme HP, ORACLE, MICROSOFT, IBM, DIGITAL, UNISYS, RATIONAL SOFTWARE, etc., qui ont dcid que ce langage fera partie de leur stratgie. La version 1.1 a t normalise en Novembre 1997 par lOMG (Object Management Group). Les ides dans UML viennent des ides communes dveloppes par diffrentes personnes dans le domaine de lOrient Objet. Les dveloppeurs dUML nont pas invent la plupart des ides ; plutt leur rle a t de slectionner et dintgrer des ides provenant des meilleurs mthodes Orientes Objet et des techniques scientifiques pratiques en Informatique qui ont fait leur preuve. Les diffrents concepts dUML sexpriment travers des reprsentations graphiques comme les diffrents diagrammes de modlisation que lon abordera ici. UML est un nouveau langage mais aussi une nouvelle pratique associe au Gnie Logiciel et on verra quon lui j oint un nouveau cycle de vie : le cycle de vie itratif. Enfin un glossaire est inclus en fin douvrage afin de trouver les dfinitions des termes employs en Orient Objet avec UML. Mots cls : UML, mthodologie, mthode, objet

ABSTRACT
UML is the Unified Modeling Language. We say language not a method, because UML has a vocabulary, a syntax and a semantic. UML come from the melting of the essential object-oriented methods as OMT (Object Modeling Technique), Booch (its author), OOSE (Object-Oriented Software Engineering) and others. It became clear that several organizations saw UML as strategic to their business. A UML Partners consortium was established with several organizations willing to dedicate ressources to work toward a strong definition. Those contributing to the UML 1.1 definition included HP, ORACLE, MICROSOFT, IBM, DIGITAL, UNISYS, RATIONAL SOFTWARE, etc. The 1.1 Unified Language version then was normalized in November of 1997 by the OMG (Object Management Group). The ideas in the UML come from the community of ideas developed by many different people in the object-oriented field. The UML developers did not invent most of these ideas ; rather their role was to select and integrate ideas from the best OrientedObject and computer science pratices. Different concepts of UML are graphical as graphical diagrams that we will see in this report. UML is a new language but also a new pratice added to Sofware Engineering and we will see that it will process with a new life cycle : the iterative life cycle. A glossary of UML Oriented-Object vocabulary is added at the end of this report.

Tout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.

Vous aimerez peut-être aussi