Cours Uml

Mthodologie UML - Cours du cycle B du Cnam.
doc ______________________________________________________________________________
DI GALLO Frdric
Mthodologie des systmes d'information - UML

Cours du Cycle Probatoire
UML UP
Cours dispens par Annick Lassus.
CNAM ANGOULEME 2000-2001 ___________________________________________________________________

DI GALLO Frdric Page 1 28/11/01
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________
METHODOLOGIES DES SYSTEMES D'INFORMATION :
UML
___________________________________________________________________
UP - LE PROCESSUS UNIFIE
I. LE PROCESSUS DE DEVELOPPEMENT : NOUVELLE APPROCHE ........................................5 II. LE PROCESSUS UNIFIE : CADRE GENERAL ......................................................................6 III.LE PROCESSUS UNIFIE EST PILOTE PAR LES CAS DUTILISATION ......................................6 3.1) Prsentation ............................................................................................................6 3.2) Exemple: guichet de banque ...................................................................................6 IV.LE PROCESSUS UNIFIE EST CENTRE SUR LARCHITECTURE ..............................................8 4.1) Liens entre cas dutilisation et architecture ? ........................................................8 4.2) Marche suivre : ....................................................................................................8 V. LE PROCESSUS UNIFIE EST ITERATIF ET INCREMENTAL..................................................8 5.1) Avantages dun processus itratif contrl.............................................................9 VI.LE CYCLE DE VIE DU PROCESSUS UNIFIE .........................................................................9 6.1) Prsentation du cycle de vie de UP ......................................................................10 6.2) Exemple sur les diffrents modles .......................................................................11 VII. CONCLUSION : UN PROCESSUS INTEGRE ......................................................................12
APPROCHE DU LANGAGE UML

LES METHODES OBJET ET LA GENESE D'UML .............................................................15 1.1) Mthodes ? ............................................................................................................15 1.2) A quoi sert UML ?.................................................................................................16 1.3) Les points forts d'UML..........................................................................................17 1.4) Les points faibles d'UML ......................................................................................17 II. CARACTERISTIQUES DE LA METHODE UML................................................................18 2.1) UML est bas sur un mta-modle .......................................................................18 2.2) UML: visualisation complte d'un systme...........................................................18 III.INTRODUCTION A LA NOTATION UML ..........................................................................19 3.1) La notion d'objet ...................................................................................................19 3.2) Les mthodes objet................................................................................................19 3.3) Intrt d'une mthode objet...................................................................................19 3.4) La normalisation OMG.........................................................................................20 IV.MODELISER AVEC UML ...............................................................................................21 4.1) Qu'est-ce qu'un modle ? ......................................................................................21 4.2) Comment modliser avec UML ?..........................................................................22 I.
___________________________________________________________________
INTRODUCTION AU LANGAGE UML

LES CAS DUTILISATION ..............................................................................................33 1.1) Objectifs des cas dutilisation...............................................................................33 1.2) lments constitutifs des cas dutilisation ............................................................34 1.3) Description des cas dutilisation ..........................................................................35 1.4) Structuration des cas dutilisation........................................................................36 1.6) Notion de paquetage .............................................................................................38 1.7) Exercice TVServices (parties I et II).....................................................................38 II. LE DIAGRAMME DE CLASSES .......................................................................................42 2.1) Les classes.............................................................................................................42 2.2) Les associations ....................................................................................................43 III. LE DIAGRAMME DE COLLABORATION .........................................................................48 3.1) Interaction.............................................................................................................48 3.2) De nouveaux strotypes de classe .......................................................................48 3.3) Les Messages : ......................................................................................................50 3.4) Exercice TVServices (parties III et IV) .................................................................51 3.5) TP de synthse: Cration d'un site Web ...............................................................54 I.
___________________________________________________________________
METHODOLOGIE CNAM ANGOULEME 2000-2001
UP - LE PROCESSUS UNIFIE
Comparaison des mthodologies UP et Merise: UP Cycle de vie itratif et incrmental Mthode gnrique MERISE Squentiel
I.
Le processus de dveloppement : nouvelle approche

Dans une dmarche traditionnelle, le processus de dveloppement tait caractris par : Un processus de type squentiel : dveloppement organis en phases qui regroupent des tapes, elles mmes dcomposes en tche. Les niveaux de dcoupage concident : la fin dune phase correspond la conclusion de ses tapes, qui elles mmes se terminent avec laccomplissement des tches qui les composent. Dans une approche objet tout change : Le processus est de type itratif ; Les dcoupages ne concident pas : les activits (taches, phases, tapes, etc) se droulent dans plusieurs dimensions.
La matrise des processus de dveloppement implique pourtant une organisation et un suivi des activits : cest ce quoi sattachent les diffrentes mthodes qui sappuient sur lutilisation du langage UML pour modliser un systme dinformation. UP (Unified Process) est une mthode gnrique de dveloppement de logiciel. Gnrique signifie qu'il est ncessaire d'adapter UP au contexte du projet, de l'quipe, du domaine et/ou de l'organisation (exemple: R.UP ou X.UP). C'est, entre parenthses, plus ou moins vrai pour toute mthode, qu'elle se dfinisse elle-mme comme gnrique ou pas. Il existe donc un certain nombre de mthodes issues de UP.
___________________________________________________________________
II. Le processus unifi : cadre gnral

Le processus unifi est un processus de dveloppement logiciel : il regroupe les activits mener pour transformer les besoins dun utilisateur en systme logiciel. Caractristiques essentielles du processus unifi : - Le processus unifi est base de composants, - Le processus unifi utilise le langage UML (ensemble d'outils et de diagramme), - Le processus unifi est pilot par les cas dutilisation, - Centr sur larchitecture, - Itratif et incrmental.
III. Le processus unifi est pilot par les cas dutilisation

3.1) Prsentation
Lobjectif principal dun systme logiciel est de rendre service ses utilisateurs ; il faut par consquent bien comprendre les dsirs et les besoins des futurs utilisateurs. Le processus de dveloppement sera donc centr sur l'utilisateur. Le terme utilisateur ne dsigne pas seulement les utilisateurs humains mais galement les autres systmes. Lutilisateur reprsente donc une personne ou une chose dialoguant avec le systme en cours de dveloppement. Ce type dinteraction est appel cas dutilisation.
Cas d'utilisation
Acteur
Les cas dutilisation font apparatre les besoins fonctionnels et leur ensemble constitue le modle des cas dutilisation qui dcrit les fonctionnalits compltes du systme.
3.2) Exemple: guichet de banque

retirer de l'argent dposer de l'argent virement entre comptes client de la banque mettre de l'argent
employ de la banque
On va se demander, en premier, quels sont les utilisateurs du systme (pas forcment des utilisateurs physiques, mais plutt des rles). Ici, l'employ est aussi un client de la banque. On a donc une personne physique pour deux rles. Nous ne sommes pas dans une approche de type fonctionnelle mais une approche pilote par des cas d'utilisation.
___________________________________________________________________
3.3) Stratgie des cas dutilisation

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

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

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

Larchitecte cre une bauche grossire de larchitecture, en partant de laspect qui nest pas propre aux cas dutilisation (plate forme..). Bien que cette partie de larchitecture soit indpendante des cas dutilisation. Larchitecte doit avoir une comprhension globale de ceux ci avant den esquisser larchitecture. Il travaille ensuite, sur un sous ensemble des cas dutilisations identifis, ceux qui reprsentent les fonctions essentielles du systme en cours de dveloppement. Larchitecture se dvoile peu peu, au rythme de la spcification et de la maturation des cas dutilisation, qui favorisent, leur tour, le dveloppement dun nombre croissant de cas dutilisation. Ce processus se poursuit jusqu ce que larchitecture soit juge stable.
V.
Le processus unifi est itratif et incrmental
Le dveloppement dun produit logiciel destin la commercialisation est une vaste entreprise qui peut stendre sur plusieurs mois. On ne va pas tout dvelopper dun coup. On peut dcouper le travail en plusieurs parties qui sont autant de mini projets. Chacun dentre eux reprsentant une itration qui donne lieu un incrment. Une itration dsigne la succession des tapes de lenchanement dactivits, tandis quun incrment correspond une avance dans les diffrents stades de dveloppement.
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ Le choix de ce qui doit tre implment au cours dune itration repose sur deux facteurs : Une itration prend en compte un certain nombre de cas dutilisation qui ensemble, amliorent lutilisabilit du produit un certain stade de dveloppement. Litration traite en priorit les risques majeurs. Un incrment constitue souvent un additif. A chaque itration, les dveloppeurs identifient et spcifient les cas dutilisations pertinents, crent une conception en se laissant guider par larchitecture choisie, implmentent cette conception sous forme de composants et vrifie que ceux ci sont conformes aux cas dutilisation. Ds quune itration rpond aux objectifs fixs le dveloppement passe litration suivante. Pour rentabiliser le dveloppement il faut slectionner les itrations ncessaires pour atteindre les objectifs du projet. Ces itrations devront se succder dans un ordre logique. Un projet russi suivra un droulement direct, tabli ds le dbut par les dveloppeurs et dont ils ne sloigneront que de faon trs marginale. Llimination des problmes imprvus fait partie des objectifs de rduction des risques.
5.1) Avantages dun processus itratif contrl

Permet de limiter les cots, en termes de risques, aux strictes dpenses lies une itration. Permet de limiter les risques de retard de mise sur le march du produit dvelopp (identification des problmes ds les premiers stades de dveloppement et non en phase de test comme avec lapproche classique ). Permet dacclrer le rythme de dveloppement grce des objectifs clairs et court terme. Permet de prendre en compte le fait que les besoins des utilisateurs et les exigences correspondantes ne peuvent tre intgralement dfinis lavance et se dgagent peu peu des itrations successives Larchitecture fournit la structure qui servira de cadre au travail effectu au cours des itrations, tandis que les cas dutilisation dfinissent les objectifs et orientent le travail de chaque itration. Il ne faut donc pas msestimer lun des trois concepts.
VI. Le cycle de vie du processus unifi

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

Cas du guichet de banque
a) Diagramme de cas d'utilisation:

retirer de l'argent dposer de l'argent virement entre comptes client de la banque
On va essayer de faire apparatre des cas nominaux (classiques) et des scnarios d'exception.
___________________________________________________________________
b) Modle d'analyse: ralisation d'un cas d'utilisation
c) Diagramme de collaboration
VII. Conclusion : un processus intgr

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

I. LES METHODES OBJET ET LA GENESE D'UML ............................................................... 1.1) Mthodes ? ........................................................................................................... 1.2) A quoi sert UML ?................................................................................................ 1.3) Les points forts d'UML......................................................................................... 1.4) Les points faibles d'UML ..................................................................................... II. CARACTERISTIQUES DE LA METHODE UML.................................................................. 2.1) UML est bas sur un mta-modle ...................................................................... 2.2) UML: visualisation complte d'un systme.......................................................... III. INTRODUCTION A LA NOTATION UML ....................................................................... 3.1) La notion d'objet .................................................................................................. 3.2) Les mthodes objet............................................................................................... 3.3) Intrt d'une mthode objet.................................................................................. 3.4) La normalisation OMG........................................................................................ IV. MODELISER AVEC UML ............................................................................................ 4.1) Qu'est-ce qu'un modle ? .....................................................................................
Un modle est une abstraction de la ralit ....................................................................... Un modle est une vue subjective mais pertinente de la ralit ......................................... Quelques exemples de modles........................................................................................... Caractristiques fondamentales des modles.....................................................................
15 15 16 17 17 18 18 18 19 19 19 19 20 21 21
21 21 21 21
4.2) Comment modliser avec UML ?......................................................................... 22

Une dmarche itrative et incrmentale ?.......................................................................... 22 Une dmarche pilote par les besoins des utilisateurs ?.................................................... 22 Une dmarche centre sur l'architecture ? ........................................................................ 22 Dfinir une architecture avec UML (dtail de la "vue 4+1") ............................................ 23 Rsumons la dmarche... .................................................................................................... 24 Dtail des diffrents niveaux d'abstraction (phases du macro-processus)......................... 25 Activits des micro-processus d'analyse (niveau d'abstraction constant) ................................................... 25 Synthse de la dmarche..................................................................................................... 26
4.3) Modlisation UML ............................................................................................... 26

Qu'est-ce qu'un modle ?.................................................................................................... La modlisation UML......................................................................................................... Les cas d'utilisation ............................................................................................................ Modlisation des classes et objets ...................................................................................... Modlisation d'une classe................................................................................................... La visibilit des attributs .................................................................................................... 26 26 27 27 29 29
___________________________________________________________________

I. Les mthodes objet et la gense d'UML
1.1) Mthodes ?
Les premires mthodes d'analyse (annes 70) Dcoupe cartsienne (fonctionnelle et hirarchique) d'un systme. L'approche systmique (annes 80) Modlisation des donnes + modlisation des traitements (Merise, Axial, IE...). L'mergence des mthodes objet (1990-1995) Prise de conscience de l'importance d'une mthode spcifiquement objet: comment structurer un systme sans centrer l'analyse uniquement sur les donnes ou uniquement sur les traitements (mais sur les deux) ? Plus de 50 mthodes objet sont apparues durant cette priode (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...)! Aucune mthode ne s'est rellement impose. Les premiers consensus (1995) OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un systme. Issue du centre de R&D de General Electric. Notation graphique riche et lisible. OOD (Grady Booch) : vues logiques et physiques du systme. Dfinie pour le DOD, afin de rationaliser de dveloppement d'applications ADA, puis C++. Ne couvre pas la phase d'analyse dans ses 1res versions (prconise SADT). Introduit le concept de package (lment d'organisation des modles). OOSE (Ivar Jacobson) : couvre tout le cycle de dveloppement. Issue d'un centre de dveloppement d'Ericsson, en Sude. La mthodologie repose sur l'analyse des besoins des utilisateurs. L'unification et la normalisation des mthodes (1995-1997) UML (Unified Modeling Langage), la fusion et synthse des mthodes dominantes :
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ UML aujourd'hui : un standard incontournable UML est le rsultat d'un large consensus (industriels, mthodologistes...). UML est le fruit d'un travail d'experts reconnus. UML est issu du terrain. UML est riche (il couvre toutes les phases d'un cycle de dveloppement). UML est ouvert (il est indpendant du domaine d'application et des langages d'implmentation). Aprs l'unification et la standardisation, bientt l'industrialisation d'UML : les outils qui supportent UML se multiplient (GDPro, ObjectTeam, Objecteering, OpenTool, Rational Rose, Rhapsody, STP, Visio, Visual Modeler, WithClass...). XMI (format d'change standard de modles UML). UML volue mais reste stable ! L'OMG RTF (nombreux acteurs industriels) centralise et normalise les volutions d'UML au niveau international. Les groupes d'utilisateurs UML favorisent le partage des expriences. De version en version, UML gagne en maturit et prcision, tout en restant stable. UML inclut des mcanismes standards d'auto-extension. La description du mtamodle d'UML est standardise (OMG-MOF). >>> UML n'est pas une mode, c'est un investissement fiable !
1.2) A quoi sert UML ?

UML n'est pas une mthode ou un processus ! Si l'on parle de mthode objet pour UML, c'est par abus de langage ! Ce constat vaut aussi pour OMT ou d'autres techniques / langages de modlisation. Une mthode propose aussi un processus, qui rgit notamment l'enchanement des activits de production d'une entreprise. UML a t pens pour permettre de modliser les activits de l'entreprise, pas pour les rgir (ce n'est pas CMM ou SPICE). Un processus de dveloppement logiciel universel est une utopie : - Impossible de prendre en compte toutes les organisations et cultures d'entreprises. - Un processus est adapt (donc trs li) au domaine d'activit de l'entreprise. - Mme si un processus constitue un cadre gnral, il faut l'adapter de manire prcise au contexte de l'entreprise. UML est un langage pseudo-formel UML est fond sur un mtamodle, qui dfinit : - les lments de modlisation (les concepts manipuls par le langage), - la smantique de ces lments (leur dfinition et le sens de leur utilisation). Un mtamodle est une description trs formelle de tous les concepts d'un langage. Il limite les ambiguts et encourage la construction d'outils. Le mtamodle d'UML permet de classer les concepts du langage (selon leur niveau d'abstraction ou domaine d'application) et expose sa structure. Le mtamodle UML est lui-mme dcrit par un mta-mtamodle (OMG-MOF). UML propose aussi une notation, qui permet de reprsenter graphiquement les lments de modlisation du mtamodle. Cette notation graphique est le support du langage UML.
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ UML cadre l'analyse objet, en offrant : diffrentes vues (perspectives) complmentaires d'un systme, qui guident l'utilisation des concept objets, plusieurs niveaux d'abstraction, qui permettent de mieux contrler la complexit dans l'expression des solutions objets. UML est un support de communication Sa notation graphique permet d'exprimer visuellement une solution objet. L'aspect formel de sa notation limite les ambiguts et les incomprhensions. Son aspect visuel facilite la comparaison et l'valuation de solutions. Son indpendance (par rapport aux langages d'implmentation, domaine d'application, processus...) en font un langage universel.
1.3) Les points forts d'UML

UML est un langage formel et normalis gain de prcision gage de stabilit encourage l'utilisation d'outils UML est un support de communication performant Il cadre l'analyse. Il facilite la comprhension de reprsentations abstraites complexes. Son caractre polyvalent et sa souplesse en font un langage universel.
1.4) Les points faibles d'UML

La mise en pratique d'UML ncessite un apprentissage et passe par une priode d'adaptation. Mme si l'Espranto est une utopie, la ncessit de s'accorder sur des modes d'expression communs est vitale en informatique. UML n 'est pas l'origine des concepts objets, mais en constitue une tape majeure, car il unifie les diffrentes approches et en donne une dfinition plus formelle. Le processus (non couvert par UML) est une autre cl de la russite d'un projet. Or, l'intgration d'UML dans un processus n'est pas triviale et amliorer un processus est un tche complexe et longue. Les auteurs d'UML sont tout fait conscients de l'importance du processus, mais l'acceptabilit industrielle de la modlisation objet passe d'abord par la disponibilit d'un langage d'analyse objet performant et standard.
___________________________________________________________________
II. Caractristiques de la mthode UML

2.1) UML est bas sur un mta-modle
UML est un moyen d'exprimer des modles objet en faisant abstraction de leur implmentation, c'est--dire que le modle fourni par UML est valable pour n'importe quel langage de programmation. UML est un langage qui s'appuie sur un mtamodle, un modle de plus haut niveau qui dfinit les lments d'UML (les concepts utilisables) et leur smantique (leur signification et leur mode d'utilisation). Le mtamodle permet de se placer un niveau d'abstraction suprieur car il est tudi pour tre plus gnrique que le modle qu'il permet de construire. Le mtamodle d'UML en fait un langage formel possdant les caractristiques suivantes: - un langage sans ambiguts - un langage universel pouvant servir de support pour tout langage orient objet - un moyen de dfinir la structure d'un programme - une reprsentation visuelle permettant la communication entre acteurs d'un mme projet - une notation graphique simple, comprhensible mme par des non informaticiens Le mtamodle permet de donner des bases solides et rigoureuses ce langage graphique, dont la reprsentations graphiques ne sont l que pour vhiculer des concepts de ralisation.
2.2) UML: visualisation complte d'un systme

UML offre une manire lgante de reprsenter le systme selon diffrentes vues complmentaires grce aux diagrammes. Lorsqu'une entreprise dsire un logiciel, elle le ralise parfois en interne, mais le fait plus gnralement raliser par une socit de services. Dans un cas comme dans l'autre il est ncessaire de dfinir l'ensemble des fonctionnalits que le logiciel doit possder. Le demandeur du logiciel n'a parfois pas de comptences particulires en informatique et exprime donc ses souhaits sous forme d'un CdCF (Cahier des Charges Fonctionnelles), c'est-dire un document dcrivant sous forme textuelle l'ensemble des particularits que le logiciel doit possder, les conditions qu'il doit remplir (systme(s) d'exploitation vis(s)), les cueils viter, ainsi que les dlais impartis, ventuellement des clauses sur le cot, les langages utiliser, ... Le CdCF est ainsi distribu diffrentes socits de services (dans le cas d'une soustraitance) sous forme d'un appel d'offre, auquel les socits vont rpondre par un cot, un dlai, ... Lorsqu'une socit obtient le march et qu'elle dcide (si elle a le choix) d'opter pour un langage orient objet, il lui faut dans un premier temps crer un modle (c'est l qu'intervient UML) afin: de prsenter au client la faon de laquelle elle compte dvelopper le logiciel d'accorder tous les acteurs du projet (une application de grande envergure est gnralement ralise par modules dvelopps par diffrentes quipes) Ainsi, si le modle ne convient pas au client, il sera "simple" modifier, contrairement une application directement implmente (qui aurait mobilis beaucoup plus de personnel, pendant une priode plus longue), ce qui signifie une perte d'argent beaucoup moins importante pour la socit de services, ainsi qu'une meilleure probabilit de rendre dans les temps (on parle gnralement de dead line) une application conforme aux exigences du client (si l'application se conforme au modle prsent au client, celui-ci peut difficilement contester la validit du logiciel).
___________________________________________________________________
III. Introduction la notation UML

UML (Unified Modeling Language, que l'on peut traduire par "langage de modlisation unifi) est une notation permettant de modliser un problme de faon standard. Ce langage est n de la fusion de plusieurs mthodes existant auparavant, et est devenu dsormais la rfrence en terme de modlisation objet, un tel point que sa connaissance est souvent ncessaire pour obtenir un poste de dveloppeur objet.
3.1) La notion d'objet

La programmation oriente objet consiste modliser informatiquement un ensemble d'lments d'une partie du monde rel (que l'on appelle domaine) en un ensemble d'entits informatiques. Ces entits informatiques sont appeles objet. Il s'agit de donnes informatiques regroupant les principales caractristiques des lments du monde rel (taille, la couleur, ...). La difficult de cette modlisation consiste crer une reprsentation abstraite, sous forme d'objets, d'entits ayant une existence matrielle (chien, voiture, ampoule, ...) ou bien virtuelle (scurit sociale, temps, ...).
3.2) Les mthodes objet

La modlisation objet consiste crer une reprsentation informatique des lments du monde rel auxquels on s'intresse, sans se proccuper de l'implmentation, ce qui signifie indpendamment d'un langage de programmation. Il s'agit donc de dterminer les objets prsents et d'isoler leurs donnes et les fonctions qui les utilisent.
Cette mthode reprsente un langage permettant de spcifier, reprsenter et construire les composantes dun systme informatique. Avec la mthode UML, un objet est par exemple reprsent de la faon suivante:
3.3) Intrt d'une mthode objet

Les langages orients objet constituent chacun une manire spcifique d'implmenter le paradigme objet. Ainsi, une mthode objet permet de dfinir le problme haut niveau sans rentrer dans les spcificits d'un langage. Il reprsente ainsi un outil permettant de dfinir un problme de faon graphique, afin par exemple de le prsenter tous les acteurs d'un projet (n'tant pas forcment des experts en un langage de programmation).
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ De plus, le fait de programmer l'aide d'un langage orient objet ne fait pas d'un programmer un concepteur objet. En effet il est tout fait possible de produire un code syntaxiquement juste sans pour autant adopter une approche objet. Ainsi la programmation oriente objet implique en premier lieu une conception abstraite d'un modle objet (c'est le rle de la mthode objet), en second plan l'implmentation l'aide d'un langage oriente objet (tel que C++/Java/...) Une mthode objet est donc d'une part une mthode d'analyse du problme (afin de couvrir toutes les facettes du problmes), d'autre part un langage permettant une reprsentation standard stricte des concepts abstraits (la modlisation) afin de constituer un langage commun.
3.4) La normalisation OMG

Ainsi, il est ncessaire qu'une mthode objet soit dfinie de manire rigoureuse et unique afin de lever les ambiguts. De nombreuses mthodes objet ont t dfinies, mais aucune n'a su s'imposer en raison du manque de standardisation. C'est pourquoi l'ensemble des acteurs du monde informatique a fond en 1989 l'OMG (Object Management Group), une organisation but non lucratif, dont le but est de mettre au point des standards garantissant la compatibilit entre des applications programmes l'aide de langages objet et fonctionnant sur des rseaux htrognes (de diffrents types). A partir de 1997, UML est devenue une norme de l'OMG, ce qui lui a permis de s'imposer en tant que mthode de dveloppement objet et tre reconnue et utilise par de nombreuses entreprises. L'OMG est un organisme but non lucratif, cr en 1989 l'initiative de grandes socits (HP, Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'OMG fdre plus de 850 acteurs du monde informatique. Son rle est de promouvoir des standards qui garantissent l'interoprabilit entre applications orientes objet, dveloppes sur des rseaux htrognes. L'OMG propose notamment l'architecture CORBA (Common Object Request Broker Architecture), un modle standard pour la construction d'applications objets distribus (rpartis sur un rseau). Pour rester simple, on peut considrer CORBA comme une gnralisation de l'architecture clients/serveurs aux objets. Au centre de l'architecture CORBA, un routeur de messages (ORB : Object Request Broker) permet des objets clients d'envoyer des requtes et de recevoir des rponses, sans avoir se proccuper des dtails techniques propres l'infrastructure du rseau. L'ORB se charge de transmettre les requtes aux objets concerns, o qu'ils se trouvent (dans le mme processus, dans un autre, sur un autre nud du rseau...). Le bus CORBA (dont l'ORB est le composant central) permet d'assurer la transparence des invocations de mthodes ; les requtes aux objets semblent toujours tre locales. De plus, l'ORB assure une coopration entre objets qui est indpendante des langages de programmation. Le modle CORBA permet en effet de se focaliser sur les interfaces des objets, qu'on exprime en IDL (Interface Definition Language). L'IDL dcrit de manire standard l'interface d'un objet, en faisant abstraction des dtails qui relvent de son d'implmentation. Avec CORBA, il n'est donc pas ncessaire de savoir comment les objets sont cods pour utiliser leurs services. L'utilisation d'IDL comme langage pivot dans la construction d'une architecture, permet de grer l'htrognit. Cette approche, qui consiste masquer les couches techniques du rseau (systme d'exploitation, processeur, langage de programmation...), permet d'assurer l'interoprabilit de toute application objets distribus, conforme au modle CORBA.
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ CORBA fait partie d'une vision globale de la construction d'applications rparties, appele OMA (Object Management Architecture) et dfinie par l'OMG. Sans rentrer dans les dtails, on peut rsumer cette vision par la volont de favoriser l'essor industriel des technologies objet, en offrant un ensemble de solutions technologiques non propritaires, qui suppriment les clivages techniques. UML a t adopt (normalis) par l'OMG et intgr l'OMA, car il participe cette vision et parce qu'il rpond la "philosophie" OMG.
IV. Modliser avec UML

4.1) Qu'est-ce qu'un modle ?
Un modle est une abstraction de la ralit
L'abstraction est un des piliers de l'approche objet. Il s'agit d'un processus qui consiste identifier les caractristiques intressantes d'une entit, en vue d'une utilisation prcise. L'abstraction dsigne aussi le rsultat de ce processus, c'est--dire l'ensemble des caractristiques essentielles d'une entit, retenues par un observateur.
Un modle est une vue subjective mais pertinente de la ralit

Un modle dfinit une frontire entre la ralit et la perspective de l'observateur. Ce n'est pas "la ralit", mais une vue trs subjective de la ralit. Bien qu'un modle ne reprsente pas une ralit absolue, un modle reflte des aspects importants de la ralit, il en donne donc une vue juste et pertinente.
Quelques exemples de modles

Modle mtorologique: partir de donnes d'observation (satellite ...), permet de prvoir les conditions climatiques pour les jours venir. Modle conomique: peut par exemple permettre de simuler l'volution de cours boursiers en fonction d'hypothses macro-conomiques (volution du chmage, taux de croissance...). Modle dmographique: dfinit la composition d'un panel d'une population et son comportement, dans le but de fiabiliser des tudes statistiques, d'augmenter l'impact de dmarches commerciales, etc...
Caractristiques fondamentales des modles

Le caractre abstrait d'un modle doit notamment permettre de faciliter la comprhension du systme tudi: un modle rduit la complexit du systme tudi. Il doit aussi permettre de simuler le systme tudi: un modle reprsente le systme tudi et reproduit ses comportements. Un modle rduit (dcompose) la ralit, dans le but de disposer d'lments de travail exploitables par des moyens mathmatiques ou informatiques: modle / ralit ~ digital / analogique.
___________________________________________________________________
4.2) Comment modliser avec UML ?

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

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

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

Une architecture adapte est la cl de vote du succs d'un dveloppement. Elle dcrit des choix stratgiques qui dterminent en grande partie les qualits du logiciel (adaptabilit, performances, fiabilit...). Ph. Kruchten propose diffrentes perspectives, indpendantes et complmentaires, qui permettent de dfinir un modle d'architecture (publication IEEE, 1995). Cette vue ("4+1") a fortement inspir UML :
___________________________________________________________________
Dfinir une architecture avec UML (dtail de la "vue 4+1")

La vue logique Cette vue de haut niveau se concentre sur l'abstraction et l'encapsulation, elle modlise les lments et mcanismes principaux du systme. Elle identifie les lments du domaine, ainsi que les relations et interactions entre ces lments : les lments du domaine sont lis au(x) mtier(s) de l'entreprise, ils sont indispensables la mission du systme, ils gagnent tre rutiliss (ils reprsentent un savoir-faire). Cette vue organise aussi (selon des critres purement logiques), les lments du domaine en "catgories" : pour rpartir les tches dans les quipes, regrouper ce qui peut tre gnrique, isoler ce qui est propre une version donne, etc... La vue des composants Cette vue de bas niveau (aussi appele "vue de ralisation"), montre : L'allocation des lments de modlisation dans des modules (fichiers sources, bibliothques dynamiques, bases de donnes, excutables, etc...). En d'autres termes, cette vue identifie les modules qui ralisent (physiquement) les classes de la vue logique. L'organisation des composants, c'est-dire la distribution du code en gestion de configuration, les dpendances entre les composants... Les contraintes de dveloppement (bibliothques externes...). La vue des composants montre aussi l'organisation des modules en "sous-systmes", les interfaces des sous-systmes et leurs dpendances (avec d'autres sous-systmes ou modules). La vue des processus Cette vue est trs importante dans les environnements multitches ; elle montre : La dcomposition du systme en terme de processus (tches); les interactions entre les processus (leur communication); la synchronisation et la communication des activits parallles (threads). La vue de dploiement Cette vue trs importante dans les environnements distribus, dcrit les ressources matrielles et la rpartition du logiciel dans ces ressources : la disposition et nature physique des matriels, ainsi que leurs performances, l'implantation des modules principaux sur les nuds du rseau, les exigences en terme de performances (temps de rponse, tolrance aux fautes et pannes...). La vue des besoins des utilisateurs Cette vue (dont le nom exact est "vue des cas d'utilisation"), guide toutes les autres. Dessiner le plan (l'architecture) d'un systme informatique n'est pas suffisant, il faut le justifier ! Cette vue dfinit les besoins des clients du systme et centre la dfinition de l'architecture du systme sur la satisfaction (la ralisation) de ces besoins. A l'aide de scnarios et de cas d'utilisation, cette vue conduit la dfinition d'un modle d'architecture pertinent et cohrent. Cette vue est la "colle" qui unifie les quatre autres vues de l'architecture. Elle motive les choix, permet d'identifier les interfaces critiques et force se concentrer sur les problmes importants.
___________________________________________________________________
Rsumons la dmarche...
Modliser une application ? Mais comme UML n'est pas un processus... Quelle dmarche utiliser ? Trouver un "bon" modle est une tche difficile mais capitale ! 1. Optez pour une approche itrative et incrmentale. 2. Centrez votre dmarche sur l'analyse des besoins des utilisateurs. 3. Prenez grand soin la dfinition de l'architecture de votre application (l'approche "4+1" permet de mieux la cerner). OK OK , mais en pratique ? ien qu'UML n'est pas un processus, il facilite une dmarche d'analyse itrative et incrmentale, base sur les niveaux d'abstraction. Les niveaux d'abstraction permettent de structurer les modles. Un micro-processus rgit les itrations niveau d'abstraction constant. Un macro-processus rgit le passage de niveau niveau. Une dmarche incrmentale consiste construire les modles de spcification et de conception en plusieurs tapes (cible = catgories). Le schma ci-dessous montre les niveaux d'abstraction principaux, qu'on peut identifier dans un processus de dveloppement logiciel :
Elaboration plutt que transformation

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

Conceptualisation L'entre de l'analyse ce niveau, est le dossier d'expression des besoins client. A ce niveau d'abstraction, on doit capturer les besoins principaux des utilisateurs. Il ne faut pas chercher l'exhaustivit, mais clarifier, filtrer et organiser les besoins ! Le but de la conceptualisation est de dfinir le contour du systme modliser (de spcifier le "quoi"), de capturer les fonctionnalits principales du systme, afin d'en fournir une meilleure comprhension (le modle produit sert d'interface entre les acteurs du projet), de fournir une base la planification du projet. Analyse du domaine L'entre de l'analyse ce niveau, est le modle des besoins clients (les "cas d'utilisation" UML). Il s'agit de modliser les lments et mcanismes principaux du systme. On identifie les lments du domaine, ainsi que les relations et interactions entre ces lments : les lments du domaine sont lis au(x) mtier(s) de l'entreprise, ils sont indispensables la mission du systme, ils gagnent tre rutiliss (ils reprsentent un savoir-faire). A ce stade, on organise aussi (selon des critres purement logiques), les lments du domaine en "catgories" : pour rpartir les tches dans les quipes, regrouper ce qui peut tre gnrique, etc... Analyse applicative A ce niveau, on modlise les aspects informatiques du systme, sans pour autant rentrer dans les dtails d'implmentation. Les interfaces des lments de modlisation sont dfinis (cf. encapsulation). Les relations entre les lments des modles sont dfinies. Les lments de modlisation utiliss peuvent tre propres une version du systme. Conception On y modlise tous les rouages d'implmentation et on dtaille tous les lments de modlisation issus des niveaux suprieurs. Les modles sont optimiss, car destins tre implments.
Activits des micro-processus d'abstraction constant)
d'analyse
(niveau
A chaque niveau d'abstraction, un micro-processus rgit la construction des modles. UML ne rgit pas les activits des micro-processus, c'est le principe d'abstraction qui permet l'laboration itrative et incrmentale des modles. Exemple de micro-processus de construction d'un modle : identifiez les classes (d'objets) : recherchez les classes candidates (diffrentes suivant le niveau d'abstraction) l'aide de diagrammes d'objets (bauches), filtrez les classes redondantes, trop spcifiques ou vagues, qui ne reprsentent qu'une opration ou un attribut, documentez les caractristiques des classes retenues (persistances, nombre maximum d'instances, etc.). identifiez les associations entre classes / interactions entre objets (instances) : recherchez les connexions smantiques et les relations d'utilisation, documentez les relations (nom, cardinalits, contraintes, rles des classes...), en spcification, filtrez les relations instables ou d'implmentation, dfinissez la dynamique des relations entre objets (les interactions entre instances de classes et les activits associes).
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ identifiez les attributs et les oprations des classes : recherchez les attributs dans les modles dynamiques (recherchez les donnes qui caractrisent les tats des objets), filtrez les attributs complexes (faites-en des objets) et au niveau spcification, ne reprsentez pas les valeurs internes propres aux mcanismes d'implmentation, recherchez les oprations parmi les activits et actions des objets (ne pas rentrer dans le dtail au niveau spcification). optimisez les modles : choisissez vos critres d'optimisation (gnricit, volutivit, prcision, lisibilit, simplicit...), utilisez la gnralisation et la spcialisation (classification), documentez et dtaillez vos modles, encapsulez. validez les modles : vrifiez la cohrence, la compltude et l'homognit des modles, confrontez les modles la critique (comit de relecture...).
Synthse de la dmarche
Modliser une application n'est pas une activit linaire. Il s'agit d'une tche trs complexe, qui ncessite une approche : itrative et incrmentale (grce aux niveaux d'abstraction), car il est plus efficace de construire et valider par tapes, ce qui est difficile cerner et matriser, centre sur l'architecture (dfinie par la vue "4+1"), car il s'agit de la cl de vote qui conditionne la plupart des qualits d'une application informatique, guide par la prise en compte des besoins des utilisateurs ( l'aide des cas d'utilisation), car ce qui motive l'existence mme du systme concevoir, c'est la satisfaction des besoins de ses utilisateurs.
4.3) Modlisation UML

Qu'est-ce qu'un modle ?
La modlisation consiste crer une reprsentation simplifie d'un problme: le modle. Grce au modle il es possible de reprsenter simplement un problme, un concept et le simuler. La modlisation comporte deux composantes: L'analyse, c'est--dire l'tude du problme la conception, soit la mise au point d'une solution au problme Le modle constitue ainsi une reprsentation possible du systme pour un point de vue donn.
La modlisation UML
Le mta-modle UML fournit une panoplie d'outils permettant de reprsenter l'ensemble des) lments du monde objet (classes, objets, ...) ainsi que les liens qui les relie. Toutefois, tant donn qu'une seule reprsentation est trop subjective, UML fournit un moyen astucieux permettant de reprsenter diverses projections d'une mme reprsentation grce aux vues. Une vue est constitu d'un ou plusieurs diagrammes.
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ On distingue deux types de vues: Les vues statiques, c'est--dire reprsentant le systme physiquement diagrammes d'objets diagrammes de classes diagrammes de cas d'utilisation diagrammes de composants diagrammes de dploiement Les vues dynamiques, montrant le fonctionnement du systme diagrammes de squence diagrammes de collaoration diagrammes d'tats-transitions diagrammes d'activits
Les cas d'utilisation

Les cas d'utilisation (en anglais use cases) permettent de reprsenter le fonctionnement du systme vis--vis de l'utilisateur, c'est donc une vue du systme dans son environnement extrieur.
Modlisation des classes et objets

Modlisation d'un objet La modlisation objet consiste crer une reprsentation abstraite, sous forme d'objets, d'entits ayant une existence matrielle (arbre, personne, tlphone, ...) ou bien virtuelle (scurit sociale, compte bancaire, ...). Un objet est caractris par plusieurs notions: Les attributs (on parle parfois de proprits): Il s'agit des donnes caractrisant l'objet. Ce sont des variables stockant des informations d'tat de l'objet Les mthodes (appeles parfois fonctions membres): Les mthodes d'un objet caractrisent son comportement, c'est--dire l'ensemble des actions (appeles oprations) que l'objet est mme de raliser. Ces oprations permettent de faire ragir l'objet aux sollicitations extrieures (ou d'agir sur les autres objets). De plus, les oprations sont troitement lies aux attributs, car leurs actions peuvent dpendre des valeurs des attributs, ou bien les modifier L'identit: L'objet possde une identit, qui permet de le distinguer des autres objets, indpendamment de son tat. On construit gnralement cette identit grce un identifiant dcoulant naturellement du problme (par exemple un produit pourra tre repr par un code, une voiture par un numro de srie, ...) UML propose une manire de reprsenter les objets de faon graphique, sous forme de rectangle, dans lequel le nom de l'objet est soulign.
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ Les attributs d'un objet Les attributs (proprits) d'un objet reprsentent ses caractristiques. L'ensemble des valeurs des attributs d'un objet constituent son tat. UML propose de reprsenter les attributs d'un objet et les valeurs associes de la manire suivante:
Les liens entre objets Dans l'approche objet, les objets ne sont pas des corps inertes isols. Bien au contraire, mme s'ils possdent leurs caractristiques propres par l'intermdiaire des valeurs de leurs attributs (ce qui constitue ce que l'on appelle l'tat), ils ont la possibilit d'interagir entre-eux grce leurs mthodes. UML propose de reprsenter les liens qui existent entre les objets grce un trait continu.
Un lien existe ds lors qu'un objet possde une visibilit vis--vis d'un autre, c'est--dire lorsqu'un objet a un rapport direct avec un autre (appartenance, utilisation, communication, ...). Il est de plus possible d'ajouter des commentaires sur le modle sous forme de notes. Une note est reprsente par un rectangle dont le coin suprieur droit est repli. Pour relier une note un objet il faut utiliser un trait discontinu (en pointills).
___________________________________________________________________
Modlisation d'une classe

On appelle classe la structure d'un objet, c'est--dire la dclaration de l'ensemble des entits qui composeront un objet. Un objet est donc "issu" d'une classe, c'est le produit qui sort d'un moule. En ralit on dit qu'un objet est une instanciation d'une classe, c'est la raison pour laquelle on pourra parler indifframment d'objet ou d'instance (ventuellement d'occurence). Une classe est compose: d'attributs: il s'agit des donnes, dont les valeurs reprsentent l'tat de l'objet Les mthodes : il s'agit des oprations applicables aux objets Si on dfinit la classe voiture, les objets Peugeot 406, Volkswagen Golf seront des instanciations de cette classe. Il pourra ventuellement exister plusieurs objets Peugeot 406, diffrencis par leur numro de srie. Mieux: deux instanciations de classes pourront avoir tous leurs attributs gaux sans pour autant tre un seul et mme objet (c'est la diffrence entre tat et identit). C'est le cas dans le monde rel, deux T-shirts peuvent tre strictement identique (avoir le mme tat) et pourtant ils sont distincts (ils ont chacun leur identit propre). D'ailleurs en les mlangeant il serait impossible de les distinguer... Une classe se reprsente avec UML sous forme d'un rectangle divis en trois sections. Le premier contient le nom donn la classe (non soulign). Les attributs d'une classe sont dfinis par un nom, un type (ventuellement une valeur par dfaut, c'est--dire une valeur affecte la proprit lors de l'instanciation) dans le second compartiment. Les oprations sont rpertories dans le troisime volet du rectangle.
La visibilit des attributs

L'un des principaux concepts du paradigme objet est l'encapsulation. L'encapsulation est un mcanisme consistant rassembler les donnes et les mthodes au sein d'une structure en cachant l'implmentation de l'objet, c'est--dire en empchant l'accs aux donnes par un autre moyen que les services proposs. L'encapsulation permet donc de garantir l'intgrit des donnes contenues dans l'objet. En effet, la programmation oriente objet permet de cacher l'implmentation dun objet en ne lui permettant d'accder aux attributs uniquement par l'intermdiaire de mthodes cres cet effet (on parle d'interface). Il est ainsi possible de dfinir des niveaux d'encapsulation, afin de dfinir le type de classe ayant accs aux attributs. On parle de niveau de visibilit des lments de la classe. Ces niveaux de visibilit dfinissent les droits d'accs aux donnes selon que l'on y accde par une mthode de la classe elle-mme, d'une classe hritire, ou bien d'une classe quelconque. Il existe trois niveaux de visibilit.
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ publique: Les fonctions de toutes les classes peuvent accder aux donnes ou aux mthodes d'une classe dfinie avec le niveau de visibilit public. Il s'agit du plus bas niveau de protection des donnes protge: l'accs aux donnes est rserv aux fonctions des classes hritires, c'est-dire par les fonctions membres de la classe ainsi que des classes drives prive: l'accs aux donnes est limit aux mthodes de la classe elle-mme. Il s'agit du niveau de protection des donnes le plus lev
La notation UML permet de reprsenter le niveau de visibilit des attributs de faon graphique en faisant prcder le nom de chaque attribut par un caractre reprsentant la visibilit: + dfini un attribut public # dfini un attribut protg - dfini un attribut priv
___________________________________________________________________
Introduction au langage UML
___________________________________________________________________

I. LES CAS DUTILISATION ................................................................................................ 33 1.1) Objectifs des cas dutilisation.............................................................................. 33 1.2) lments constitutifs des cas dutilisation ........................................................... 34
Exemple : Diagramme de cas dutilisation dun guichet automatique bancaire............... 34
1.3) Description des cas dutilisation ......................................................................... 35

a) Exemple : Cas dutilisation Retirer de largent ............................................................ 35 b) Exemple : scnario du cas dutilisation :Retirer de largent ; retrait autoris............. 35
1.4) Structuration des cas dutilisation....................................................................... 36

a) La relation dinclusion :................................................................................................. 36 b) La relation dextension................................................................................................... 37 c) Relation de gnralisation entre cas dutilisation.......................................................... 37
1.6) Notion de paquetage ............................................................................................ 38 1.7) Exercice TVServices (parties I et II).................................................................... 38

Partie 1: Diagramme de cas d'utilisation - vue de l'administrateur .................................. 38 Partie II: Diagramme de cas d'utilisation - vue de l'utilisateur ......................................... 40
II. LE DIAGRAMME DE CLASSES ......................................................................................... 42 2.1) Les classes............................................................................................................ 42

a) Dfinition........................................................................................................................ b) Reprsentation................................................................................................................ c) Syntaxe............................................................................................................................ d) Oprations...................................................................................................................... a) Arit des associations..................................................................................................... b) Rle ................................................................................................................................ c) Identification des associations ....................................................................................... d) Identification des rles ................................................................................................... e) Multiplicit des associations .......................................................................................... f) Les classes associations :................................................................................................ g) Agrgation...................................................................................................................... h) La composition ............................................................................................................... i) Gnralisation : .............................................................................................................. 42 42 43 43 44 44 44 44 45 46 46 47 47
2.2) Les associations ................................................................................................... 43
III. LE DIAGRAMME DE COLLABORATION ........................................................................ 3.1) Interaction............................................................................................................ 3.2) De nouveaux strotypes de classe ...................................................................... 3.3) Les Messages : ..................................................................................................... 3.4) Exercice TVServices (parties III et IV) ................................................................
48 48 48 50 51
Partie III: Diagramme de classe mtier pour le cas d'utilisation regarder ................. 52 Partie IV: Diagramme de collaboration d'un scnario du cas d'util. regarder ............. 53
3.5) TP de synthse: Cration d'un site Web .............................................................. 54

a) L'adhsion: ..................................................................................................................... 54 b) La publication des articles:............................................................................................ 54 c) La vente des ouvrages: ................................................................................................... 55
___________________________________________________________________

UML est un langage de modlisation avec plusieurs objectifs qui en font un vritable outil de communication: - Comprendre et dcrire les besoins, - Spcifier (un systme), - Etablir l'architecture logicielle. Les diagrammes d'UML vont mettre en place deux parties: Statique (structure) Diagramme de cas d'utilisation Diagramme de classe Diagramme objet Diagramme de composants Diagramme de dploiement Dynamique (comportement) Diagramme de collaboration Diagramme de squence Diagramme tat/ transition Diagramme d'activits
I.
Les cas dutilisation

1.1) Objectifs des cas dutilisation
Les cas dutilisation sont une technique de description du systme tudi privilgiant le point de vue de lutilisateur. Il sagit de la solution UML pour reprsenter le modle conceptuel. Les cas dutilisation dcrivent sous la forme dactions et de ractions, le comportement dun systme du point de vue dun utilisateur. Les cas dutilisation servent structurer les besoins des utilisateurs et les objectifs correspondants du systme. Un cas dutilisation est une manire spcifique dutiliser un systme. Cest limage dune fonctionnalit du systme, dclenche en rponse la stimulation dun acteur externe. Les cas dutilisation apportent une solution au problme de la dtermination et de la comprhension des besoins. En effet frquemment, des besoins se contredisent, des oublis et des imprcisions sont raliss et ainsi lanalyse du systme part sur de mauvaises bases. Les cas dutilisation recentrent lexpression des besoins sur les utilisateurs en partant du principe quun systme est avant tout construit pour ses utilisateurs. Les cas dutilisation permettent aux utilisateurs de structurer et darticuler leurs dsirs ; ils les obligent dfinir la manire dont ils voudraient interagir avec le systme, prciser quelles informations ils entendent changer et dcrire ce qui doit tre fait pour obtenir le rsultat escompt.
___________________________________________________________________
1.2) lments constitutifs des cas dutilisation

Cas d'utilisation Acteur Acteur : entit externe qui agit sur le systme ; Le terme acteur ne dsigne pas seulement les utilisateurs humains mais galement les autres systmes. les acteurs sont des classificateurs qui reprsentent des rles au travers d'une certaine utilisation (cas) et non pas des personnes physiques. Ce sont des acteurs types. Cas dutilisation : ensemble dactions ralises par le systme en rponse une action dun acteur. - les cas dutilisation peuvent tre structurs, - les cas dutilisation peuvent tre organiss en paquetages, - lensemble des cas dutilisation dcrit les objectifs du systme.
Exemple : Diagramme de cas dutilisation dun guichet automatique bancaire

guichet Retirer de l'argent Client de la banque Dposer de l'argent
effectuer des virements entre comptes Consulter solde compte
Employ de caisse
Ravitailler distributeur
Rparer le distributeur Agent de maintenance
___________________________________________________________________
1.3) Description des cas dutilisation

Un cas dutilisation spcifie une squence dinteractions, avec ses variantes, entre les acteurs et le systme, produisant un rsultat satisfaisant pour un acteur particulier. . On peut donc considrer un cas dutilisation comme une abstraction de plusieurs chemins dexcution dune utilisation du systme. Pour dcrire un cas dutilisation, il nous faut dcrire un maximum de chemins dexcution possibles pour la squence dactions correspondant ce cas. On tudiera donc un certain nombre de scnarios dun cas dutilisation. Un scnario est donc une instance de cas dutilisation, un flot d'vnement. A chaque fois quune instance dun acteur dclenche un cas dutilisation, un scnario est cr : ce scnario suivra un chemin particulier dans la description dun cas dutilisation. Un scnario ne contient pas de branche du type si la condition X est vraie alors faire Y , car pendant lexcution la condition est soit vraie, soit fausse mais elle aura toujours une valeur. Bien sr il est impossible de dcrire un cas dutilisation en crivant tous les scnarios, lexhaustivit est difficile atteindre, mais il faut rpertorier les scnarios les plus reprsentatifs afin de grer les risques. On recherchera donc le ou les scnarios nominaux et les principaux cas dexceptions. Nous aurons donc deux niveaux de description : - Description gnrale dun cas dutilisation reprenant les divers chemins pouvant tre runis en un mme cas. - Description des scnarios les plus pertinents.
a) Exemple : Cas dutilisation Retirer de largent

1234Le client de la banque sidentifie Le systme lui propose les diffrents comptes sur lesquels il peut effectuer un retrait Le client choisit le compte dbiter et spcifie le montant du retrait Le systme vrifie si le retrait est autoris, si oui il dduit le montant du compte et dlivre largent, sinon il renvoie un message de rejet de lopration
b) Exemple : scnario du cas dutilisation :Retirer de largent ; retrait autoris

Acteur dclencheur : M. Martin Ce scnario commence par 1- M. Martin sidentifie 2- Le systme lui propose les diffrents comptes sur lesquels il peut effectuer un retrait 3- M. Martin choisit son compte chque et demande 200F /*Le systme vrifie que le retrait est autoris*/ 4- Le systme dlivre deux billets de 100F et demande ce que M. Martin les saisisse. Ce scnario se termine par 5- M. Martin prend largent.
___________________________________________________________________
1.4) Structuration des cas dutilisation

Aprs avoir identifi les acteurs et les cas dutilisation, il est utile de restructurer lensemble des cas dutilisation que lon a fait apparatre afin de rechercher les comportements partags, les cas particuliers et les gnralisations. Les relations possibles entre cas dutilisation : UML dfinit trois types de relations standardises entre cas dutilisation, dtailles ci-aprs : - Une relation dinclusion : formalise par la dpendance include - Une relation dextension : formalise par la dpendance extend - Une relation de gnralisation / spcialisation Etapes de construction: 1. Les acteurs 2. Pour chaque acteur, recherche des cas d'utilisation, 3. Structuration des cas d'utilisation pour faire apparatre les comportements partags (relation d'inclusion), les cas particuliers ou options (relation d'extension), les gnralisations / spcialisations.
a) La relation dinclusion :
Lors de la description des cas dutilisation, il apparat quil existe des sous-ensembles communs plusieurs cas dutilisation, il convient donc de factoriser ces fonctionnalits en crant de nouveaux cas dutilisation qui seront utiliss par les cas dutilisation qui les avaient en commun. Un cas dutilisation A utilise un cas dutilisation B signifie que : - une instance de A va engendrer une instance de B et lexcuter, - A dpend de B, - B nexiste pas tout seul et A nexiste pas sans B Exemple : Retirer de largent include Dposer de largent include include include Consulter solde Les cas de base Dposer de largent , Retirer de largent , Effectuer des virements entre comptes et Consulter solde incorporent de faon explicite le cas dutilisation Sauthentifier , un endroit spcifi dans leurs enchanements. Sauthentifier
Effectuer des virements
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ Remarquez que dans une relation include , le cas dutilisation de base utilise systmatiquement les enchanements provenant du cas inclus. On utilise cette relation pour viter de dcrire plusieurs fois un mme enchanement dactions. Ainsi on est amen factoriser un comportement commun plusieurs cas dutilisation dans un cas dutilisation part.
b) La relation dextension
La relation strotype <<extend>> permet d'tendre les interactions et donc les fonctions dcrites par les interactions. Le cas de base peut fonctionner tout seul, mais il peut galement tre complt par un autre, sous certaines conditions, et uniquement certains points particuliers de son flot dvnements (point dinsertion). On utilise principalement cette relation pour sparer le comportement optionnel (les variantes) du comportement obligatoire. Considrons lexemple : le cas dutilisation B tend le cas dutilisation A signifie que : - Une instance de A va engendrer une instance de B et lexcuter sous certaines conditions, B sait o sinsrer dans A. - B connat A et non linverse, cest dire que B dpend de A - B nexiste pas tout seul et A existe sans B La relation <<extend>> montre une possibilit d'excution d'interactions qui augmenteront les fonctionnalits du cas tendu, mais de faon optionnelle, non obligatoire, alors que la relation <<include>> suppose une obligation dexcution des interactions. Exemple : extend Sauthentifier Retenir carte
c) Relation de gnralisation entre cas dutilisation

La relation d'hritage ou de gnralisation entre cas est plus subtile. La version 1.1 de UML ne distinguait d'ailleurs pas <<extend>> et gnralisation. Cette relation est prendre au sens classique de spcialisation, inhrent 'hritage. Ici, la gnralisation peut tre vue aussi comme un "polymorphisme" de cas. Exemple : Dans un systme dagence de voyage Rserver
Rserver voyage par tlphone DI GALLO Frdric Page 37
Rserver voyage par Internet 28/11/01
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ Dans un systme d'agence de voyage, un acteur touriste peut participer un cas de base qui est "Rserver voyage", qui suppose par exemple des interactions basiques au comptoir de l'agence. Une rservation peut aussi tre ralise par tlphone ou internet. On voit qu'il ne s'agit pas de relation <<extend>> car la rservation par Internet n'tend pas les interactions ni les fonctionnalits du cas 'Rserver voyage". Elle les traduit diffremment. Les interactions Internet ne sont pas une option des interactions comptoir. Par contre les deux cas "Rserver voyage" et "Rserver voyage par Internet" sont lis : la rservation par Internet est un cas particulier de rservation. De faon gnrale en objet, une situation de cas particulier se traduit par une relation de gnralisation. ATTENTION : On peut galement gnraliser les acteurs
1.6) Notion de paquetage

Les modles UML produits dans le cadre dun projet sont parfois dune superficie trop importante pour tre facilement utiliss. La notion de paquetage ou package est une technique qui permet de mettre en uvre ce partitionnement des modles tout en prservant la cohrence de lensemble. Un paquetage est un ensemble dlments de modlisation : des classes, des associations, des objets, des composants. Dans le cas du guichet bancaire on pourrait faire deux diagrammes de cas dutilisation, un pour le paquetage utilisation du guichet et un autre pour le paquetage maintenance.
1.7) Exercice TVServices (parties I et II)

TVServices est une socit qui met disposition de ses clients un ensemble de services relatifs la tlvision (accs des chanes thmatiques, contrle des utilisations et des utilisateurs, programme lectronique dtaill des chanes accessibles...). Ces services sont commercialiss sous le nom d' IntelliTl Chaque client dispose d'un botier lectronique situ entre l'antenne satellite et l'installation de tlvisualisation (crans, magntoscopes...). C'est cet quipement intermdiaire, appel ciaprs "botier 'NS", constamment en veille et reli au rseau tlphonique, qui permet au client: le paiement des services par carte bancaire, et le dcodage des images reues. Et TVServices, la diffusion automatique des programmes et magazines lectroniques (et des publicits ;-); en chargeant les mmoires des botiers avec les programmes et magazines, et l'autorisation d'accs aux services; TVS mmorise les informations relatives aux autorisations d'accs aux services (fonction des paiements reus) dans les botiers.
Partie 1: Diagramme de cas d'utilisation - vue de l'administrateur

Voici un extrait de la brochure commerciale proposant les contrats 'IntelliTl' Une fois le contrat sign et l'abonnement aux services de votre choix pay vous recevrez par l'intermdiaire d'un installateur agr, un "botier TVS" prprogramm avec les autorisations d'accs correspondant votre contrat. Lors de l'installation, un compte "administrateur" (typiquement, pour une installation familiale, un des parents) est cr qui aura pour tche de dclarer les futurs utilisateurs du systme (identificateur et mot de passe) ainsi que d'administrer leurs droits (types d'mission autoriss, plages horaires autorises, dure maximale hebdomadaire de visualisation autorise appele "crdit hebdomadaire").
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ Travail faire: I.l) Expliquer le diagramme ci-dessous par un texte dcrivant les informations qu'il contient en les contextualisant dans le cadre de TVServices (deux sens possibles, ambigut ).
Voici une description possible du diagramme propos: L'accs aux fonctions d'administration est protg, le contrle s'effectuant sur l'identificateur et le mot de passe de l'administrateur. Ce qui explique que l'excution du cas d'utilisation 'Administrer' ncessite celle du cas d'utilisation 'ContrleAccsUtil', dont l'excution ncessite celle du cas d'utilisation 'Identifier'. Le dcoupage fonctionnel de l'administration en cration des utilisateurs, contrle d'accs des utilisateurs... ne me semble pas pertinent ce niveau de description avec l'approche 'cas d'utilisation'. I.2) Quel peut-tre l'intrt de sparer les cas d'utilisation "ContrleAccsUtil" et "Identifier" du cas d'utilisation "Administrer"? Il peut y avoir intrt sparer les cas d'utilisation "ContrleAccsUtil" et "Identifier" du cas d'utilisation "Administrer" si les deux premiers sont utiliss par ('inclus dans') d'autres cas d'utilisation; on les a en quelque sorte factoriss. I.3) Reprsenter par un fragment de diagramme de cas d'utilisation le fait que parmi les acteurs sollicitant le systme, "Client" et "Administrateur" sont tous deux "Utilisateur".
Utilisateur
Client
Administrateur
___________________________________________________________________
Partie II: Diagramme de cas d'utilisation - vue de l'utilisateur

Voici un extrait de la description faite ci-dessous par un des premiers clients: Une "IntelliTl" est un tlviseur-enregistreur, elle (ou 'il' je ne sais pas... ) permet de regarder des missions tldiffuses, et aussi de les enregistrer. C'est un systme qui, via un rseau, connat les possibilits pour lesquelles on a pay. Par exemple, on peut acheter des droits de rception de certaines chanes payantes ou s'abonner un service qui envoie rgulirement une analyse dtaille des programmes des principales chanes. Pour utiliser une "IntelliTl", on dispose d'un terminal, comme une tlcommande, avec un petit cran tactile, qu'on manipule avec un stylet. Dans ce terminal on peut glisser si ncessaire une carte puce, par exemple pour payer un service. Pour pouvoir utiliser "l'IntelliTl", il faut s'identifier. Un utilisateur autoris dispose de droits ; c'est moi qui ai dfini les droits d'accs des enfants. Je leur ai interdit des plages horaires et certaines chanes. Il me reste interdire certains types de programme (je sais que c'est possible car ils disent que le botier connat la catgorie de chaque mission). Mais c'est vrai je ne vous ai pas encore parl du botier; tenez, voici la prsentation de TVServices, la socit qui commercialise "L'IntelliTl",... (Voir la partie I). Travail faire: En imaginant utiliser une IntelliTl comme vous le faites (peut-tre) de votre rcepteur TV/magntoscope, et en tenant compte de la description ci-dessus, produire un diagramme de cas d'utilisation de l'IntelliTl vu de l'utilisateur acteur gnrique comme dfini en 1.3. ciavant. Scnario du cas d'utilisation: Utiliser la TV; Enregistrement direct. Acteur dclencheur: Mr Martin Ce scnario commence par: 1. Mr Martin s'identifie /* Le systme lui donne l'autorisation d'accs */ 2. Mr Martin dcide d'enregistrer une mission sur M6 en direct Ce scnario se termine par 3. Mr Martin teint la TV Scnario du cas d'utilisation: Utiliser la TV; Accs une chane refuse. Acteur dclencheur: Mr Martin Ce scnario commence par: 1. Mr Martin s'identifie 2. Mr Martin dcide de regarder une mission d'informations sur France3 3. Le systme lui indique qu'il n'a pas les droits d'accs sur cette chane. Ce scnario se termine par 4. Mr Martin teint la TV Scnario du cas d'utilisation: Utiliser la TV; Crdit de temps restant de 5 minutes. Acteur dclencheur: La fille de Mr Martin Ce scnario commence par: 1. La fille de Mr Martin s'identifie 2. Le systme la reconnat et lui affiche qui ne lui reste que 5 minutes de crdit 3. Elle choisit de regarder un dessin anim 4. au bout de 5 minutes, la TV s'teint toute seule.
___________________________________________________________________
U M L_D IG A LLO
Contrler autorisation <<include>>
U tiliser U tilisateur
<<include>> Contrler A ccs
<<include>>
Identifier
<<include>> Regarder mission Consulter magaz ine Consulter liste immdiatement disp onible
Enregister mission
Consulter son comp te
<<include>> Consulter droits initiaux
<<extend>>
A dministrer
<<include>>
<<extend>> Consulter solde
Enregistrer en direct
Programmation enregistrement
___________________________________________________________________
II. Le diagramme de classes

Les diagrammes de classes expriment de manire gnrale la structure statique dun systme, en termes de classes et de relations entre ces classes. Une classe permet de dcrire un ensemble dobjets (attributs et comportement), tandis quune relation ou association permet de faire apparatre des liens entre ces objets. On peut donc dire : - un objet est une instance de classe, - un lien est une instance de relation Le diagramme de classe est un modle permettant de dcrire de manire abstraite et gnrale les liens entre objets. UML permet de dfinir trois types de strotypes pour les classes : a) les classes frontire (interface): classes qui servent modliser les interactions entre le systme et ses acteurs. b) les classes contrle : classes qui servent reprsenter la coordination, le squencement, les transactions et le contrle dautres objets. c) les classes entit : classes qui servent modliser les informations durables et persistantes. Dans un premier temps cest cette dernire catgorie de classes que nous allons nous intresser. Le diagramme de classe va tre un outil nous permettant de reprsenter le modle du domaine. Le modle du domaine saisit les lments les plus importants pour comprendre le contexte du systme : - les objets mtiers (mis en uvre dans une activit professionnelle tels que les commandes, les contrats..) , - les concepts du domaine modliser dont le systme doit garder une trace, - les vnements stant produits ou devant se produire qui dclencheront un certain comportement des objets.
2.1) Les classes

a) Dfinition
Description dun ensemble dobjets partageant la mme smantique, ainsi que les mmes attributs, oprations et relations.
b) Reprsentation
Nom de la classe Attributs Oprations
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ Exemple : VEHICULE Marque Modle Immatriculation Niveau du carburant .. Acclrer() Vidanger() Une classe correspond un concept global dinformation et se compose dun ensemble dinformations lmentaires, appeles attributs de la classe qui servent la dcrire. UML dfinit trois niveaux de visibilit pour les attributs et les oprations : Public qui rend llment visible tous les clients de la classe, Protg qui rend llment visible aux sous classes de la classe, Priv qui rend llment visible la classe seule. Un attribut est caractris par un nom et par un format.
c) Syntaxe
Nom_attribut : type_attribut = valeur_par_dfaut Dans un premier temps on ne retiendra comme attribut que des donnes non calcules, cependant par commodit de gestion on pourra garder des attributs pouvant tre construits partir dautres attributs (on rajoutera / devant lattribut dit driv).
d) Oprations
La dfinition dune classe est complte par lensemble des oprations quelle peut excuter. Une opration est une fonctionnalit assure par la classe. Le niveau de dtail retenir pour dcrire les oprations est fonction du niveau davancement de ltude.
2.2) Les associations

Une association reprsente une relation structurelle entre classes dobjets. La plupart des associations sont binaires, cest dire quelles connectent deux classes. On reprsente une association en traant une ligne entre les classes associes. A B
___________________________________________________________________
a) Arit des associations

On appelle arit dune association le nombre de classes qui participent lassociation. Il arrive en effet que linformation que lon veut reprsenter ncessite la mise en relation de plus de deux classes. Ces associations naires peuvent se reprsenter au moyen dun losange sur lequel arrivent les diffrents brins de lassociation. Exemple : ENSEIGNANT
ETUDIANT
SALLE
COURS DateDbut DateFin
b) Rle
Les extrmits dune association sont appeles rles et peuvent porter un nom. Le rle dcrit comment une classe voit une autre classe au travers dune association.
c) Identification des associations

Les associations peuvent tre nommes afin de faciliter la comprhension des modles. Il est dusage de nommer les associations par une forme verbale. On peut galement prciser le sens de lecture par le biais dun petit triangle dirig vers la classe dsigne par la forme verbale. CLIENT Passer > COMMANDE
d) Identification des rles

Un rle est nomm au moyen dune forme nominale. SOCIETE Employeur Employ On utilise rarement les deux modes de description dassociation simultanment, mais on cherche celui le plus adapt la situation dcrire. PERSONNE
___________________________________________________________________
e) Multiplicit des associations

Chaque rle peut porter une multiplicit montrant combien dobjets de la classe considre (celle qui joue ce rle) peuvent tre lis une instance de lautre classe par lassociation. La multiplicit est reprsente sous la forme dun couple de cardinalits. 1..1 not 1 0..1 0..* not * 1..* n..m Un et un seul Zro ou un De Zro n De un n De n m
Exercice 2 : Lecture de multiplicit
GARAGE LOCATAIRE 1 1
1..* louer BOX 1..* 1 Autoriser 0..2 VEHICULE 0..1
1..* CONTRAT
Travail faire : Faites une description de ce diagramme de classe en explicitant en une phrase chacune des multiplicits. Un box peut tre lou par au maximum un seul contrat ou peut rester non lou. Un contrat concerne la location d'un seul box la fois. Un box peut tre vide ou contenir au maximum 2 vhicule. Un vhicule est autoris aller dans un box (au minimum) ou plus. Un contrat ne concerne qu'un seul locataire. Un locataire peut souscrire plusieurs contrat mais doit en avoir souscrit au moins un.
___________________________________________________________________
f) Les classes associations :

Il peut arriver que lon ait besoin de garder des informations (attributs ou oprations) propres une association. Une classe de ce type est appele classe association. Exemple : COMMANDE 1..* 1..* PRODUIT
LIG-COM Quantit
1..*
LIVRAISON
Ici, NumCommande + RfProduit Quantit Une classe association est une classe comme une autre qui peut entretenir des relations avec dautres classes
g) Agrgation
Une agrgation est un type particulier dassociation. Elle traduit la volont de renforcer la dpendance entre les classes. Cest une association non symtrique dans laquelle une des extrmits joue un rle prdominant par rapport lautre extrmit. Les critres suivants impliquent une agrgation : - une classe fait partie dune autre classe, - une action sur une classe implique une action sur une autre classe, - les objets dune classe sont subordonns aux objets dune autre classe. Attention : linverse nest pas toujours vrai ; lagrgation nimplique pas ncessairement tous les critres ci-dessus. 1 1..*
GARAGE
BOX
Un agrgat peut tre multiple.
___________________________________________________________________
h) La composition
La composition est un cas particulier dagrgation dans laquelle la vie des composants est lie celle de lagrgat. Dans la composition, lagrgat ne peut tre multiple. La composition se reprsente par un losange noir.
C om m u n e
1
1..*
1..*
1..*
M ai ri e
C on se i l M u n i ci pal
S e rvi ce
Une composition est une association contraignante : la suppression dun objet agrgat entrane la suppression des objets agrgs.
i) Gnralisation :
UML emploie le terme de gnralisation pour dsigner la relation de classification entre un lment plus gnral et un lment plus spcifique. La relation de gnralisation signifie est un ou est une sorte de .
Instrument +Nom Instrument : undefined +Date fabrication : undefined
Instrument cordes +Nombre de cordes : undefined
Instrument vent +Nombre de pistons : undefined
La classe Instrument est une classe gnrique, elle porte les attributs communs tous les instruments. La classe Instrument cordes est une classe spcialise qui porte les attributs spcifiques ce type dinstrument. Une classe spcialise peut avoir des relations avec dautres classes.
___________________________________________________________________
III. Le diagramme de collaboration

Nous avons jusqu prsent tudi la statique (la structure) du systme modliser travers le diagramme des cas dutilisation et le diagramme de classe. Nous allons maintenant passer ltude de la dynamique (le comportement) du systme. Pour cela nous allons chercher mettre en vidence les interactions entre objets, ainsi que les messages changs. Le diagramme de collaboration permet de mettre en vidence les interactions entre les diffrents objets du systme tudi, ainsi que les messages quils changent entre eux.
3.1) Interaction
La squence dactions dun scnario dun cas dutilisation dbute lorsquun acteur invoque ce cas dutilisation en envoyant une forme quelconque de message au systme. En fait ce nest pas le systme dans son ensemble qui va recevoir le message mais un objet frontire (ou interface). Lobjet frontire va envoyer son tour un message un autre objet, de sorte que les objets concerns vont dialoguer pour raliser ce cas dutilisation ou plus prcisment un scnario de ce cas dutilisation. A laide du diagramme de collaboration, nous illustrons donc linteraction entre objets en crant des liens entre ces objets et en associant des messages ces liens. Le nom dun message doit voquer lintention de lobjet appelant lors de linteraction avec lobjet associ.
3.2) De nouveaux strotypes de classe

Ce diagramme de collaboration va nous permettre de complter le modle danalyse commenc avec le diagramme de classe en ajoutant de nouvelles classes. Dans une premire version du diagramme de classe nous nous sommes limits ltudes des classes entits. Nous allons voir laide du diagramme de collaboration quil est ncessaire davoir recours dautres types de classes pour grer les interactions entre objets du systme : - Les classes frontires (ou interfaces) : servent modliser les interactions entre le systme et ses acteurs ; - Les classes de contrle : ces classes encapsulent souvent le contrle li un cas dutilisation, ce qui implique quun objet de contrle est cr au dmarrage dune instance de cas dutilisation et prend fin lissue de ce scnario. Il y a nanmoins des exceptions : lorsquun objet de contrle participe la ralisation de plusieurs cas dutilisation, lorsque plusieurs objets de contrle (issus de diffrentes classes de contrle) participent la ralisation du cas dutilisation, et enfin lorsquune ralisation de cas dutilisation ne ncessite aucun objet de contrle. Un diagramme de collaboration permet de dcrire les interactions entre objets intervenant dans la ralisation dun scnario dun cas dutilisation.
___________________________________________________________________
Exemple : Utilisation dun diagramme de collaboration pour dcrire la ralisation du scnario retrait autoris du cas dutilisation retirer de largent
IntGuichet/:IGuichetAccueil
2:DemanderAutorisation(Code) Contrleur1/:CAutorisation
1:Identifier(Code) 4:AutoriserCration(ListeComptes) 5:ChoixCompteMontant(Compte,Montant) M. Martin/:Client de la banque 6:DemanderRetrait(Compte, Montant) CompteClient/:Compte 9:DlivrerArgent() 7:ValiderEtEffectuerRetrait() Contrleur2/:CRetrait Multi-objet IntChoixMontant/:IGuichetMontant 3:[ContrleOK]ObtenirListe() ComptesMartin/:Compte
8:AutoriserRetrait(montant) IntDistributeur/:Idistributeur
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ Le diagramme de collaboration peut tre complt par du texte dcrivant de quelle faon les objets dialoguent pour effectuer le scnario du cas dutilisation. Cest une description de scnario un peu plus prcise.
Exemple : scnario du cas dutilisation :Retirer de largent ; retrait autoris

Acteur dclencheur : M. Martin Ce scnario commence par 1. M. Martin active lobjet Interface Guichet et sidentifie 2. Linterface Guichet demande au contrleurAutorisation si le code est valide. Cest le cas, le contrleurAutorisation demande les comptes de M. Martin (le message est donc envoy plusieurs objets et non un seul.) Il demande ensuite la cration dune instance de linterface IguichetMontant IntChoixMontant prsentant la liste des comptes de M.Martin et demandant le montant. 3. M. Martin choisit son compte chque et demande 200F (message envoy lobjet IntChoixMontant) /*Le systme vrifie que le retrait est autoris*/ 4. LObjet IntChoixMontant transmet la demande de retrait du compte et du montant choisis par M. Martin un deuxime objet contrleur charg de vrifier que M. Martin peut retirer cet argent sur son compte. Lobjet contrleur2 confirme en demandant lobjet CompteClient de valider la requte et, si celle-ci est correcte, de dbiter le compte. Lobjet contrleur2 autorise ensuite lobjet IntDistributeur dlivrer le montant demand par M. Martin. Enfin M. Martin reoit le montant demand. Ce scnario se termine par 5. M. Martin prend largent.
3.3) Les Messages :

Les messages sont les seuls moyens de communication entre les objets. Ils sont donc positionns sur le lien entre deux objets. Un nom est associ au message pour faciliter son identification. La squence permet de prciser lordre dmission des messages. Un message peut tre complt par un ou plusieurs arguments :le message 5 ChoixCompteMontant a pour argument le compte et le montant choisis par le client. Certains messages peuvent solliciter un rsultat. On peut reprsenter ce cas par deux messages : le premier fait la demande, le second apporte la rponse. Toutefois, lorsque le message en retour est immdiatement attendu, pour simplifier les diagrammes on peut les omettre. Lmission dun message peut tre soumise une garde : .Le contrle doit tre OK pour demander la liste des comptes dun client.
___________________________________________________________________
3.4) Exercice TVServices (parties III et IV)

TvServices est une socit qui met disposition de ses clients un ensemble de services relatifs la tlvision (accs des chanes thmatiques, contrle des utilisations et des utilisateurs, programme lectronique dtaill des chanes accessibles...). Ces services sont commercialiss sous le nom d' IntelliTl Chaque client dispose d'un botier lectronique situ entre l'antenne satellite et l'installation de tlvisualisation (crans, magntoscopes...). C'est cet quipement intermdiaire, appel ci-aprs "botier TVS", constamment en veille et reli au rseau tlphonique, qui permet au client le paiement des services par carte bancaire, et le dcodage des images reues; et TvServices, la diffusion automatique des programmes et magazines lectroniques (et des publicits ;-); en chargeant les mmoires des botiers avec les programmes et magazines, et l'autorisation d'accs aux services; TVS mmorise les informations relatives aux autorisations d'accs aux services (fonction des paiements reus) dans les botiers. Voici le diagramme de cas d'utilisation rsultat de la partie II
___________________________________________________________________
Partie III: Diagramme de classe mtier pour le cas d'utilisation regarder

Dfinitions et contraintes compltant la description de l'installation donne en Partie I: Les chanes proposent des missions. Une mission peut tre l'objet de plusieurs diffusions. Une mission a une certaine dure. Une diffusion a une certaine date/heure de dbut. Une plage horaire est relative un certain jour de la semaine, elle commence et se termine des heures rondes. Une session est l'utilisation du systme par un utilisateur, d'une certaine date/heure de dbut une certaine date/heure de fin, au cours de laquelle il peut zapper d'une chane une autre. Une session n'est autorise que 51 l'utilisateur qui la dclenche est un utilisateur autoris pour le type d'mission, correspondant la diffusion regarde, Si l'heure de dbut de session appartient une plage horaire autorise pour cet utilisateur, et Si le crdit hebdomadaire de cet utilisateur n'est pas atteint. Proposer une premire version du diagramme de classe faisant apparatre les classes entits et les attributs ncessaires la vision statique de ce diagramme de classe.
D iffu sion
D at e : st ring H eure : s t ring
Em i ssi on
T it re : st ring D ure : s t ring 1..* Appartenir 1..* 1..* Pr opos er 1
C h ai n e
T ype d' m i ssi on

1..* 1..* Regar der
Uti li sate u rs S e ssi on

O uv r ir 1..* 1 N om : st ring M ot de p as se : s t ring D ureM axA ut orise : real 1..*
Pr ofiter 1..*
Pl age h orai re
J our de la semaine : st ring H eure de dbut : s t ring H eure de fin : s t ring
___________________________________________________________________
Partie IV: Diagramme de collaboration d'un scnario du cas d'util. regarder

Description du cas d'utilisation "Regarder" Ce cas d'utilisation commence par une demande d'ouverture de session faite par l'utilisateur. Le systme cre une session "en cours d'ouverture" et demande l'utilisateur de s'identifier et de donner son mot de passe. L'utilisateur saisit son identificateur et le mot de passe associ. Le systme contrle ces informations et vrifie que la plage courante est une plage autorise pour l'utilisateur; il autorise l'ouverture de session. Le systme propose parmi les chanes accessibles (fonction de l'abonnement) au client, parmi les missions en cours de diffusion, celles qui sont autorises l'utilisateur qui a dclench la session. L'utilisateur en choisit une. Le systme envoie les images correspondantes au tlviseur. L'utilisateur arrte le tlviseur. Le systme temporise 30 secondes; au bout des 30 secondes, le tlviseur restant arrt, le systme ferme la session. Ainsi se clt ce cas d'utilisation. IV.1) Ecrire un scnario nominal et un scnario d'exception du cas d'utilisation regarder. IV.2) Choisir un des 2 scnarios et raliser le diagramme de collaboration correspondant. IV.3) Modifier le diagramme de classes en faisant apparatre les classes entits et contrleurs ainsi que les attributs ncessaires la ralisation de ce cas d'utilisation.
___________________________________________________________________
3.5) TP de synthse: Cration d'un site Web

L'IWTS (International Waste Treatment Society), association internationale de chercheurs scientifiques, a pour objet de promouvoir des actions de recherche sur le traitement des dchets. Elle compte diffrents collges : celui des universitaires et des tudiants en doctorat, celui des ingnieurs des administrations, celui des laboratoires, celui des industriels producteurs... Pour amliorer sa communication et sa ractivit, cette association souhaite fonder une communaut virtuelle internationale, elle dsire donc mettre en place un site web orient vers tous ses partenaires et permettant d'effectuer des transactions.
a) L'adhsion:
La procdure d'adhsion d'un membre l'association doit se faire en ligne. Une personne peut demander devenir adhrente condition d'tre parraine par deux membres en place. Le demandeur connect la partie du site de l'IWTS accessible au public, remplit un formulaire de demande d'adhsion. La premire partie du formulaire demande une @dresse lectronique et les rfrences des deux parrains. Aprs contrle de l'identit des parrains une cl est fournie au demandeur (dans sa bote aux lettres lectronique) qui pourra ainsi accder au formulaire d'adhsion complet. L'association souhaite connatre; l'identit du demandeur, son adresse personnelle, son diplme le plus important, son adresse professionnelle, sa profession (par exemple ingnieur d'tudes) et sa fonction dans l'organisation (par exemple directeur de laboratoire), ses thmes prfrs de recherche et les rcompenses obtenues (par exemple Awards 2000 de la meilleure publication sur le thme du lagunage...). Le demandeur choisit les groupes thmatiques auquel il souhaite appartenir; il doit fournir galement sa photo numrise et les rfrences de deux articles dont il est l'auteur; ces articles doivent avoir paru dans des revues scientifiques rpertories, ou tre disponibles sur un site, auquel cas c'est l'adresse rticulaire (URL) des articles qu'il fournit.Un des membres du conseil (compos d'un prsident, d'un vice prsident, et d'un nombre de membres de chaque collge proportionnel au nombre d'adhrents de ce collge) qui dirige l'association examine la demande d'adhsion, notamment le contenu scientifique des deux articles cits par le demandeur et contrle le parrainage. Si le conseil apprcie le dossier du demandeur, un collge lui est propos et il peut devenir membre. S'il confirme sa demande, le demandeur (admis) signale le mode de paiement de l'adhsion qu'il souhaite. Le tarif dpend du collge du membre. Le membre admis peut, aprs s'tre acquitt du paiement de bnficier des informations prives de l'association. L'enregistrement du paiement est effectu par le secrtariat. Il fait alors partie de la liste de diffusion du groupe thmatique auquel il a choisi d'appartenir; il pourra dialoguer avec les autres membres lorsqu'il aura sign la charte dontologique des listes. Cela peut se faire tout moment notamment lors de la confirmation de demande d'adhsion.
b) La publication des articles:

La revue de l'association est publie pour ses membres sur le web tous les trois mois. Les membres ont deux mois entre chaque revue pour proposer des articles. Un article possde un titre, un thme et des mots clefs. La slection des articles est dcide par le conseil, aprs avis de deux lecteurs du groupe thmatique correspondant, choisis par le conseil. Un article peut tre accept, refus ou propos aprs amendements, pour une relecture. L'avis, aprs la deuxime lecture est dfinitif. L'auteur de l'article reoit une valuation de l'article o sont notes les remarques prcises des lecteurs, ceux ci restent anonymes. Un rsum de chaque article publi sera accessible sur la partie publique du site web, titre d'apritif, avec ses mots clefs.
___________________________________________________________________
c) La vente des ouvrages:

Les membres de l'association ralisent parfois1 des ouvrages spcifiques (CDROM de photos par exemple).Ces ouvrages sont dits par l'association condition qu'ils demeurent scientifiques et non publicitaires (le traitement de l'acceptation d'un ouvrage est le mme que celui d'un article sans que ne se pose le problme de dlai). Ces ouvrages sont alors mis en vente pour tout public sur le web (une rpartition des bnfices entre auteur et diteur est alors calcule). Travail faire: 1- A partir d'une lecture analytique du texte ci-dessus, produisez une premire version du diagramme des cas d'utilisation du systme "site web de l'IWTS". Veillez respecter les frontires du systme. Une des approches possibles consiste passer au crible les substantifs (ou groupes nominaux) ; ils sont candidats tre des objets du systme ou des acteurs extrieurs, utilisateurs du systme. Les verbes (formes verbales), quand eux, marquent un aspect dynamique, un lien entre objets, un comportement du systme ou un service qu'il rend. Pour produire le diagramme des cas d'utilisation, on slectionnera les acteurs et les services.
___________________________________________________________________
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ 2- crire une description du cas d'utilisation "Adhrer". Cas d'utilisation "Adhrer" ; acteur dclencheur : "Public"; acteurs participants: "Conseil" et "Secrtariat" Ce cas commence par La rception d'une demande d'adhsion manant d'un acteur "Public". Le serveur envoie un formulaire de demande d'adhsion, explicitant la procdure. Le demandeur expdie le formulaire rempli (nom & prnom, @dresse lectronique), nommant ses deux parrains.
/* Le serveur contrle l'identit des parrains et veille la non redondance du nom du demandeur. */
Le serveur expdie dans la bote (mail) du demandeur une cl valide. Le demandeur renouvelle sa demande d'adhsion. Le serveur envoie un formulaire d'adhsion en ligne.
/* Le demandeur complte le formulaire avec la cl d'authentification qui lui a t fournie, son adresse personnelle, son diplme le plus important, son adresse professionnelle, sa profession et sa fonction dans l'organisation dont il fait partie, ses thmes prfrs de recherche et les groupes thmatiques auxquels il souhaite appartenir. */
Le demandeur transmet le formulaire et un dossier comportant une photo (magntique) au format requis, et les rfrences de deux articles dont il est l'auteur parues dans une revue ou publies sur un site. Le "Conseil" (un membre autoris), demande accder au dossier Le serveur lui fournit le dossier. Le "Conseil" propose ou non l'adhsion un collge.
/* Le serveur enregistre l'avis du conseil. */
Le serveur signale l'avis du conseil au demandeur. Lorsque l'avis est positif, le demandeur peut confirmer sa demande d'adhsion au collge propos, signaler son mode de paiement de la cotisation correspondante, et s'il souhaite utiliser la liste de diffusion, en signer la charte. Le "Secrtariat" enregistre le paiement de la cotisation.
/* Le demandeur devient membre effectif. */
Ce cas se termine par l'enregistrement du paiement de l'adhsion (interaction 13), ou par le signalement au demandeur (interaction n0 11) du rejet de sa demande par le conseil. crire un scnario "Adhsion au collge des laboratoires", instance du cas d'utilisation "Adhrer". Scnario du cas d'utilisation adhrer: "adhsion au collge des laboratoires" L'acteur "Public" Pierre Aver (PA), connect au site, demande accder l'adhsion en ligne. Le serveur lui envoie un formulaire de demande d'adhsion, explicitant la procdure. P.A. s'identifie (Pierre Aver, Pierre.Aver@eigsi.fr), nomme ses deux parrains (Lagun Hadj et Hincine R.) et expdie le dbut du formulaire.
/* Le serveur contrle l'identit des parrains (0K) et veille la non redondance du nom du demandeur (0K). */
Le serveur expdie l'@ Pierre.Aver@eigsi.fr la cl LMU3288. PA renouvelle sa demande d'adhsion Le serveur lui envoie un formulaire d'adhsion en ligne. /* PA complte le formulaire avec la cl qui lui a t fournie (LMU3268), son adresse personnelle (18, Rue des Roses Trmires Dampierre sur Boutonne, France...), son diplme le plus important (Ph D en biologie), son adresse professionnelle (...), sa profession (ingnieur
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ d'tudes) et sa fonction dans l'organisation dont il fait partie (directeur du laboratoire de biologie applique), ses thmes prfrs de recherche (l'utilisation des algues dans le processus de lagunage et les groupes thmatiques auxquels il souhaite appartenir (dca ntation & traitements biologiques). */ PA transmet le formulaire incluant sa photo (magntique), et les rfrences de deux articles dont il est l'auteur publies sur le site des Techniques de l'Ingnieur. Le serveur met un message vers la bal du conseil. Georges Cerbre (GC), membre du conseil, demande accder au dossier. Le serveur lui fournit le dossier. GC propose l'adhsion au collge des laboratoires. /* Le serveur enregistre l'avis du conseil. */ Le serveur signale l'avis du conseil PA. PA confirme sa demande d'adhsion au collge des laboratoires, signale son mode de paiement de la cotisation par chque bancaire, et signe la charte afin d'utiliser les listes de diffusion relatives aux thmes qu'il a choisi. Le "Secrtariat" enregistre le paiement de la cotisation. /* PA devient membre effectif */ Travail faire: 1- En examinant en dtail le texte de description du cas d'utilisation adhrer , produire une premire version du diagramme de classe du domaine de cette application.
___________________________________________________________________
Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________ 3- Proposer un diagramme de collaboration du scnario "adhsion au collge des laboratoires"
___________________________________________________________________

Cours Uml

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cours Uml

Uploaded by

Copyright:

Available Formats

Mthodologie UML - Cours du cycle B du Cnam.

Mthodologie des systmes d'information - UML

Cours dispens par Annick Lassus.

CNAM ANGOULEME 2000-2001 ___________________________________________________________________

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

METHODOLOGIES DES SYSTEMES D'INFORMATION :

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

APPROCHE DU LANGAGE UML

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

INTRODUCTION AU LANGAGE UML

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

METHODOLOGIE CNAM ANGOULEME 2000-2001

Le processus de dveloppement : nouvelle approche

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

II. Le processus unifi : cadre gnral

III. Le processus unifi est pilot par les cas dutilisation

3.2) Exemple: guichet de banque

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

3.3) Stratgie des cas dutilisation

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

IV. Le processus unifi est centr sur larchitecture

4.1) Liens entre cas dutilisation et architecture ?

4.2) Marche suivre :

Le processus unifi est itratif et incrmental

5.1) Avantages dun processus itratif contrl

VI. Le cycle de vie du processus unifi

Modle dimplmentation Modle de dploiement Modle de test Reprsentation de larchitecture

6.1) Prsentation du cycle de vie de UP

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

6.2) Exemple sur les diffrents modles

a) Diagramme de cas d'utilisation:

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

b) Modle d'analyse: ralisation d'un cas d'utilisation

VII. Conclusion : un processus intgr

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

Approche du langage UML

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

APPROCHE DU LANGAGE UML

4.2) Comment modliser avec UML ?......................................................................... 22

4.3) Modlisation UML ............................................................................................... 26

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

METHODOLOGIE CNAM ANGOULEME 2000-2001

APPROCHE DU LANGAGE UML

1.2) A quoi sert UML ?

1.3) Les points forts d'UML

1.4) Les points faibles d'UML

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

II. Caractristiques de la mthode UML

2.2) UML: visualisation complte d'un systme

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

III. Introduction la notation UML

3.1) La notion d'objet

3.2) Les mthodes objet

3.3) Intrt d'une mthode objet

3.4) La normalisation OMG

IV. Modliser avec UML

Un modle est une vue subjective mais pertinente de la ralit

Quelques exemples de modles

Caractristiques fondamentales des modles

Mthodologie UML - Cours du cycle B du Cnam.doc ______________________________________________________________________________

4.2) Comment modliser avec UML ?

Une dmarche itrative et incrmentale ?

Une dmarche pilote par les besoins des utilisateurs ?