Cnam - La Méthode Uml

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

2

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


3

TABLE DES MATIERES1. 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).................................................................164.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.24.3.2.1 4.3.2.2 4.3.2.3 4.3.2.4

Les diagrammes dactivit (Activity diagrams).....................................................................18Origine........................................................................................................................................... 18 Dfinition....................................................................................................................................... 18 Exemples de diagramme dactivit ................................................................................................. 18 Intrts des diagrammes dactivit .................................................................................................. 19

4.3.34.3.3.1 4.3.3.2 4.3.3.3 4.3.3.4

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

4.3.44.3.4.1 4.3.4.2 4.3.4.3 4.3.4.4

Les diagrammes de collaboration ........................................................................................21Origine........................................................................................................................................... 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 ...........................................................................................234.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.24.4.2.1 4.4.2.2

Diagrammes de dploiement ................................................................................................24Origine........................................................................................................................................... 24 Dfinition....................................................................................................................................... 24


Mthode UML : Le langage de modlisation objet unifi4.4.2.3 4.4.2.4

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



5

1. PRINCIPES ET CONCEPTS OBJETSOn 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.


6

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.


7

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



8

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.


9

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.


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 dinstancesTout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.


11

Raffinement (refinement) Interfaces et composants

4. UML UN LANGAGE GRAPHIQUEUML 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.


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 classes4.2.1 Origine Le diagramme de classes provient principalement de OMT RUMBAUGH et de OOD BOOCH [RAT4-97].



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.


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.

-

-


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].



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.



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] .


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.


Mthode UML : Le langage de modlisation objet unifiC 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

2

[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.


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.



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



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 dimplmentationOn 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.



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).



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].



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 objetLes 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



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.


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 dtude1 - 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 deTout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.


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 itratifLe 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 itratifTout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.


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 itratifVoir 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.


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 ?



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.



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.



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



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 dveloppementitratif 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.



35

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



36

Diagramme dactivits

EnseignantEnseigner

Auditeur

Jury

Apprendre

Contrler les connaissances

Composer

Evaluer

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



37

Diagramme de cas dutilisation

Liste des cours faireDemander 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)



38

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

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

signer 5:passerEntrevue()

estClient

1:proposerPoste(unPoste)

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).



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)



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

1

1

Moteur

1

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)



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'

d8: 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.



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.



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 :

Vhiculeutilitaire

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



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 compositeTout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.


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.


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.


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 mortTout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.


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.



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 ioTout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.


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 drivTout droits de diffusion collective, sous quelque forme que soit, sont rservs par lauteur.


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.


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



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.


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 int

Cnam - La Méthode Uml

Documents

Transcript of Cnam - La Méthode Uml