Uml

Dpartement Informatique de lInstitut Universitaire de Technologie de lUniversit Bordeaux 1
Olivier Guibert
Analyse et Conception des Systmes dInformation Mthodes Objet Le langage de modlisation objet UML
(Copyright de Rational Software Corporation) UML est le langage de modlisation de la technologie objet, standard adopt par les grands acteurs du march. Ce document (qui doit beaucoup aux ouvrages que je vous conseille fortement De MERISE UML de N. Kettani, D. Mignet, P. Par et C. Rosenthal-Sabroux et Modlisation objet avec UML de P.-A. Muller, tous deux parus aux ditions Eyrolles en 1998 et quelques recherches sur le Web) propose une prsentation rapide dUML (qui renvoie surtout des ouvrages et des sites Internet) et la description des modles dUML (illustrs de surcrot par lexemple jouet ).
1. Prsentation
UML, langage de modlisation objet, est rcent mais dj trs rfrenc (quil sagisse douvrages ou de sites Internet) et dispose de nombreux outils. Notez quUML est ouvert et nest la proprit de personne. Aprs avoir cit quelques mthodes objet, ce chapitre prsente succinctement UML : une dfinition, des gnralits, un court historique, une bibliographie et des outils (i.e. ateliers de gnie logiciel).
1.1. Quelques mthodes objet

Pas moins dune cinquantaine de mthodes objet ont t dnombres au milieu des annes 90. Les mthodes objet qui suivent sont cites par J. Delatour (LIGLOO) du LAAS de Toulouse (http://www.laas.fr/~delatour/Igloo/methodeOO_image_fr.html) ou documentes dans N. Kettani, D. Mignet, P. Par et C. Rosenthal-Sabroux, De MERISE UML, Eyrolles, 1998. Catalysis, D. D'Souza. D. D'Souza et A. Wills, Objects, Components, and Frameworks with UML: The Catalysis Approach, AddisonWesley, 1998, http://iconcomp.com/catalysis/catalysis-book/index.html. http://www.iconcomp.com/catalysis/ HOOD (Hierarchical Object Oriented Design), B. Delatte, M. Heitz et J.F. Muller, 1987. B. Delatte, M. Heitz et J.F. Muller, HOOD Reference manual 3.1, Masson, 1993. J.-P. Rosen, HOOD, An Industrial Approach for Software Design, dition HOOD User Group, http://perso.wanadoo.fr/adalog/hoodbook.htm. http://www.hood.be : site officiel de HOOD http://www.estec.esa.nl/wmwww/WME/oot/hood/ : site de l'ESA (Agence Spatiale Europenne) M2PO. D. R. C. Hill, Analyse oriente objets & modlisation par simulation, Addison-Wesley France, 1993. OMT (Object Modeling Technique), J. Rumbaugh, 1987-1989. J. Rumbaugh, M. Blaha, W. Premerlani et F. Eddy, OMT Modlisation et Conception Orientes Objet, Masson, 1996 (2nde d.). J. Rumbaugh et al., OMT Solution des exercices, Masson, 1996. http://www.csioo.com/cetusfr/oo_ooa_ood_methods.html#oo_meth_omt : Cetus http://www.rational.com/support/techpapers/omt/ : Rational Software Corporation http://www.rational.com/support/techpapers/omt/summary.html : J. Rumbaugh http://www.netinfo.fr/objectland/langages/n9.94/OMT.html : en franais (partie statique) OOA (Object Oriented Analysis), S. Shlaer & S. J. Mellors, 1979. S. Shlaer et S. J. Mellors, Object lifecycles: Modeling the world in states, Yourdon Press, Prentice Hall, 1988. OOA/OOD (Object Oriented Analysis/Object Oriented Design), P. Coad & E. Yourdon, 1991. P. Coad et E. Yourdon, Object Oriented Analysis, Yourdon Press, Prentice Hall, 1991 (2nde d.). OOD (Object Oriented Design), G. Booch, entre 1980 et 1983. G. Booch, Analyse et Conception Orientes Objet, Addison-Wesley France, 1994 (2nde d.). R. Martin, Designing Object Oriented C++ Applications using the Booch Method, Prentice Hall, 1995, http://www.oma.com/DOOCPPAUBM/bookFlier.html. http://www.csioo.com/cetusfr/oo_ooa_ood_methods.html#oo_meth_booch : Cetus http://www.iconcomp.com/papers/comp/comp_87.html : ICON Computing http://www.platinum.com/clrlake/para_30/oo_mthd/booch.htm : Platinium Technology http://www.itr.ch/courses/case/BoochReference/ : (par P. Schneider) Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04 Page 1 sur 44
http://arkhp1.kek.jp/~amako/amakoInfo.html : (par K. Amako) OOM (Orientaton Objet dans Merise), A. Rochfeld et M. Bouzeghoub, 1993. A. Rochfeld et M. Bouzeghoub, From Merise to OOM, revue ISI vol. 1 n 2, AFCET-Herms, Paris, 1993. OOSE (Object Oriented Software Engineering), I. Jacobson, 1980. I. Jacobson, M. Christerson, P. Jonson et G. vergaard, Object Oriented Software Engineering: A use case driven approach, Addison-Wesley, 1992. OPEN. Concurrent dUML, proposant en plus un processus de dveloppement. D. Firesmith, B. Henderson-Sellers et I. Graham, The OML Reference Manual, SIGS Books, NY, 1997 (ou chez Cambridge University Press). D.G. Firesmith, G. Hendley, S. Krutsch et M. Stowe, Documenting a Complete Java Application using OPEN, srie OPEN publie par Addison-Wesley. I. Graham, B. Henderson-Sellers et H. Younessi, The OPEN Process Specification, Addison-Wesley,1997. B. Henderson-Sellers,T. Simons et H. Younessi, The OPEN Toolbox of Techniques, Masson, Addison-Wesley, 1998. http://www.csse.swin.edu.au/cotar/OPEN/ http://www.csse.swin.edu.au/cotar/OPEN/OBJMAG/OBJMAG.html http://www.csse.swin.edu.au/cotar/OPEN/ROAD/ROAD.html ROOM. http://www.dmi.usherb.ca/~normand/memoire/index.html : (par M. Normandeau) Et quelques autres mthodes objet : Fusion, JSD (Jackson System Development) de M. Jackson, MACH_2 (Machine Abstraite de Conception Hirarchique oriente objet), Objectory, Octopus et SYS_P_O (Systems Project Object) de P. Jaulent.
1.2. Un langage unifi pour la modlisation objet

UML (Unified Modeling Language) est un langage unifi pour la modlisation objet. UML est un langage (de modlisation objet) et propose donc une notation et une smantique associe cette notation (i.e. des modles), mais pas de processus (i.e. de dmarche proposant un enchanement dtapes et dactivits qui mnent la rsolution dun problme pos) ; UML nest donc pas une mthode. UML unifie des mthodes objet, et plus particulirement les mthodes Booch93 de G. Booch, OMT-2 (Object Modeling Technique) de J. Rumbaugh et OOSE (Object-Oriented Software Engineering) dI. Jacobson. Actuellement, ces trois personnes (surnommes les trois amigos ) travaillent pour Rational Software Corporation. UML reprend en particulier les notions de partitions en sous-systmes de Booch93, de classes et dassociations dOMT-2, et dexpression des besoins par les interactions entre les utilisateurs et le systme dOOSE. UML a une approche entirement (i.e. couvrant tout le cycle de dveloppement : analyse, conception et ralisation) objet (et non fonctionnelle) : le systme est dcompos en objets collaborant (plutt quen tches dcomposes en fonctions plus simples raliser).
1.3. Quelques gnralits

UML est conu pour modliser divers types de systmes, de taille quelconque et pour tous les domaines dapplication (gestion, scientifique, temps rel, systme embarqu). UML permet de diviser le systme dinformation (dune organisation) en le systme mtier et le systme informatique. Le systme mtier modlise les aspects statiques et dynamiques de lactivit selon une vision externe et une vision interne (en ignorant limplmentation technique) tandis que le systme informatique recouvre la partie automatise du systme mtier concrtisant les choix effectus parmi les diffrentes technologies dactualit. Les concepts manipuls sont les mmes, chacun de ces deux niveaux dabstraction. UML est fortement inspir de lapproche 4+1 vues (logique, composants, processus, dploiement et cas dutilisation) indpendantes dfinies par P. Kruchten pour exprimer les diverses perspectives de larchitecture dun systme informatique. UML se compose dune part des lments de modlisation qui reprsentent toutes les proprits du langage et dautre part des diagrammes (de cas dutilisation, de classes, dobjets, dtats-transitions, dactivits, de squence, de collaboration, de composants et de dploiement) qui en constituent lexpression visuelle et graphique. UML nimpose pas de processus de dveloppement logiciel particulier, mme si celui sous-jacent est un processus itratif (prcisant chaque itration les degrs dabstraction), incrmental (i.e. en divisant le dveloppement en tapes aboutissant chacune la construction de tout ou partie du systme), centr sur larchitecture (au niveau de la modlisation comme de la production), conduit par les cas dutilisation (modlisant lapplication partir des modes dutilisation attendus par les utilisateurs), pilot par les risques (afin dcarter les causes majeures dchec) tel que le 2TUP (Two Tracks Unified Process) prsent notamment dans louvrage UML en action De lanalyse des besoins la conception en Java de P. Roques et F. Valle paru aux ditions Eyrolles en 2000. UML prend en compte de manire compltement intgre lingnierie des besoins (cas dutilisation). UML est automatisable pour gnrer du code partir des modles vers les langages et les environnements de programmation. UML est gnrique, extensible (en plus de couvrir les possibilits des diffrentes technologies objet existantes) et configurable. UML se veut intuitif, simple et cohrent.
Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04
Page 2 sur 44
1.4. Historique
UML est n en octobre 1994 chez Rational Software Corporation linitiative de G. Booch et de J. Rumbaugh. UML 1.1 a t standardis par lOMG (Object Management Group) le 17 novembre 1997 suite la demande manant de la collaboration de plusieurs entreprises (Hewlett-Packard, IBM, i-Logix, ICON Computing, IntelliCorp, MCI Systemhouse, Microsoft, ObjecTime, Oracle, Platinum Technology, Ptech, Rational Software Corporation, Reich Technologies, Softeam, Sterling Software, Taskon et Unisys). La version actuelle (depuis juin 1999) est UML 1.3 (la version 1.4 sera bientt prte, afin de prparer la prochaine version 2.0).
1.5. Bibliographie
La littrature est trs abondante (en langue franaise, et davantage encore en langue anglaise). Consultez aussi http://www.uml.db.informatik.uni-bremen.de/umlbib/. La documentation (808 pages au format pdf, en langue anglaise) est entirement disponible sur le site www.rational.com (uml13.zip, 2.7 Mo) de Rational Software Corporation. Tous les concepts dUML sont eux-mmes modliss en UML (mta-modle). En plus de la documentation accessible sur Internet, dautres sites et groupes de discussion (news) vous donneront de nombreuses informations.
1.5.1. Ouvrages en langue franaise

J. Gabay, Merise. Vers OMT et UML, Interditions, 1998. N. Kettani, D. Mignet, P. Par et C. Rosenthal-Sabroux, De MERISE UML, Eyrolles, 1998 : recommand ! M. Lai, Penser objet avec UML et Java, Interditions, 1998. M. Lai, UML : La notation unifie de modlisation objet De Java aux EJB, Dunod, 2000 N. Lopez, J. Migueis et E. Pichon, Intgrer UML dans vos projets, Eyrolles, 1997. C. Morley, B. Leblanc et J. Hugues, UML pour l'analyse d'un systme d'information Le cahier des charges du matre d'ouvrage, Dunod, 2000. P.-A. Muller, Modlisation objet avec UML, Eyrolles, 1998 : souvent cit et conseill ! P. Roques et F. Valle, UML en action De lanalyse des besoins la conception en Java, Eyrolles, 2000. C. Soutou, Objet-Relationnel sous Oracle8, Modlisation avec UML, Eyrolles, 1999.
1.5.2. Les rfrences (ouvrages et articles cits dans la documentation dUML 1.3)
C. Bock et J. Odell, A Foundation For Composition, Journal of Object-Oriented Programming, oct. 1994. G. Booch, J. Rumbaugh et I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999. S. Cook et J. Daniels, Designing Object Systems: Object-oriented Modelling with Syntropy, Prentice Hall Object-Oriented Series, 1994. D. DSouza et A. Wills, Objects, Components and Frameworks with UML: The Catalysis Approach, Addison-Wesley, 1999. M. Fowler avec K. Scott, UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, 1997. M. Griss, Domain Engineering And Variability In The Reuse-Driven Software Engineering Business, Object Magazine, dc. 1996. D. Harel, Statecharts: A Visual Formalism for Complex Systems, Science of Computer Programming 8, 1987, pp. 231274. D. Harel et E. Gery, Executable Object Modeling with Statecharts, Proc. 18th Int. Conf. Soft. Eng., Berlin, IEEE Press, mars 1996, pp. 246-257. D. Harel et A. Naamad, The STATEMATE Semantics of Statecharts, ACM Trans. Soft. Eng. Method 5:4, oct. 1996. I. Jacobson, G. Booch et J. Rumbaugh, The Unified Software Development Process, Addison-Wesley, 1999. R. Malan, D. Coleman, R. Letsinger et al., The Next Generation of Fusion, Fusion Newsletter, oct. 1996. J. Martin et J. Odell, Object-Oriented Methods, A Foundation, Prentice Hall, 1995. G. Ramackers et D. Clegg, Object Business Modelling, requirements and approach in Sutherland, J. and Patel, D. (eds.), Proceedings of the OOPSLA95 Workshop on Business Object Design and Implementation, Springer Verlag. G. Ramackers et D. Clegg, Extended Use Cases and Business Objects for BPR, ObjectWorld UK 96, Londres, 18-21 juin 1996. J. Rumbaugh, I. Jacobson et G. Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1999. B. Selic, G. Gullekson et P. Ward, Real-Time Object-Oriented Modeling, John Wiley & Sons, 1994. J. Warmer et A. Kleppe, The Object Constraint Language: Precise Modeling with UML, Addison-Wesley, 1999.
1.5.3. Sites Internet

Quelques sites de rfrence. www.omg.org : site de lOMG http://uml.shl.com : site de lOMG UML Revision Task Force http://www.rational.com/uml : site de Rational Software Corporation Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04 Page 3 sur 44
http://uml.free.fr/ : cours en franais (de L. Piechocki) Certaines des entreprises ayant particip au projet. www.ilogix.com : I-Logix (dont D. Harel) www.rational.com : Rational Software Corporation (dont G. Booch, J. Rumbaugh et I. Jacobson) www.softeam.fr : Softeam (dont P. Desfray) www.valtech.com : Valtech Sites universitaires (franais). http://www.enib.fr/~chevaill/Course/ModuleGL/UML/index.html : ENIB (cole Nationale d'Ingnieurs de Brest) (par P. Chevaillier) http://www.essaim.univ-mulhouse.fr/uml : ESSAIM (cole Suprieure des Sciences Appliques pour l'Ingnieur Mulhouse) http://www.iutc3.unicaen.fr/~moranb/cours/acsi/menucoo.htm : IUT de Caen (par B. Morand) http://www.laas.fr/~delatour/Igloo/index_image_fr.html : LAAS (Laboratoire d'Analyse et d'Architecture des Systmes) de Toulouse, LIGLOO (Liens sur le Gnie Logiciel Orient Objet) (par J. Delatour) http://lrim.sciences.univ-metz.fr/~lanuel/UML/Cours/sld001.htm : universit de Metz (par Y. Lanuel) http://www-igm.univ-mlv.fr/~dr/DESS/glossaireGraphique/GlossaireGraphique.htm : universit de Marne-la-Valle (par D. Revuz) http://www.unantes.univ-nantes.fr/~cerisier/uml/www.html : universit de Nantes, IAE, Laboratoire de Recherche en Sciences de Gestion (par F. Cerisier avec J. Bzivin) http://www.univ-pau.fr/~bruel/Recherche/SIC/sic99.html : universit de Pau et des Pays de lAdour (par J.-M. Bruel) http://perso.wanadoo.fr/alsoftware/french/formation/uml/uml.html : Lyce Diderot (2me anne du BTS Informatique Industrielle) de Paris Des sites en vrac (en franais) ! http://www.caminao.com/documentation.htm : le projet Caminao a pour ambition de crer une communaut pdagogique autour d'UML. http://medit.epfl.ch:4444/visitors/events/meetings/11fevrier/epfl2/index.htm : UML - application au projet http://www.esil.univ-mrs.fr/~salenson/projets/juml.htm : extension d'UML pour JAVA : J-UML http://www-edu.gel.usherb.ca/nkoj01/gei450/projet/Uml/survol.html : survol de la notation unifie UML Dautres sites en vrac. http://www.isg.de/people/marc/UmlDocCollection/UMLDocCollection.html http://jeffsutherland.org/ http://www.krumbach.de/home/jeckle/unified.htm http://www.objectnews.com/ http://iamwww.unibe.ch/~scg/OOinfo/ Et quelques sites sur lobjet. http://www.cetus-links.org/ : (The CETUS links) http://www.stm.tj/objet/ : (La bote objets)
1.5.4. Groupes de discussion

comp.objet comp.software-eng fr.comp.objet
1.6. Outils
Les outils (AGL) qui suivent sont cits par P. Roques de Valtech Toulouse (http://www.essaim.univmulhouse.fr/uml/outillage/outillage.html). Quelques outils. Argo/UML (http://argouml.tigris.org/index.html) de luniversit de Californie UCI (www.ics.uci.edu/pub/arch/uml) Prosa/om (www.prosa.fi/prosa.html) dInsoft Oy Objecteering (http://www.objecteering.com/) de Softeam (www.softeam.fr) Paradigm Plus (www.platinum.com/products/appdev/pplus_ps.htm) de Computer Associates Rhapsody (www.ilogix.com/fs_prod.htm) dI-Logix (www.ilogix.com) Rose 2000 (http://www.rosearchitect.com/) de Rational Software Corporation (www.rational.com) StP/UML (www.aonix.com/Products/SMS/core7.1.html) dAonix (www.aonix.fr) Visual UML (www.visualuml.com/products.htm) de Visual Object Modelers Dautres AGL. 4Keeps dA. D. Experts (www.adexperts.com) Bold for Delphi (www.boldsoft.com/products) de BoldSoft COOL:Jex (www.cool.sterling.com/products/Jex/index.htm) de Sterling Software Elixir CASE (www.elixirtech.com/ElixirCASE/index.html) dElixir Tech. Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04 Page 4 sur 44
Ensemble Suite (www.ensemble-systems.com/products.html) dEnsemble Systems Florist (www.qoses.com/products) de Qoses FrameWork de Ptech (www.ptechinc.com) Framework Studio (www.blueprint-technologies.com/products/index.html) de Blueprint Tech. GDPro dAdvanced Software Tech. (www.advancedsw.com) How de Riverton Software (www.riverton.com) Innovator (www.mid.de/e/innovato/index.htm) de Mid ISOA de Mega International (www.mega.com) JVision dObject Insight (www.objectinsight.com) MagicDraw UML de No Magic (www.nomagic.com) Mesa/Vista Enterprise (www.mesasys.com/vista/vista_family.html) de Mesa MetaEdit+ de Metacase (www.metacase.com) Model Prototyper dObjeXion (www.objexion.com) Object Domain dObject Domain Systems (www.objectdomain.com) ObjectGeode (www.verilogusa.com/products/geode.htm) de Verilog ObjectiF (www.microtool.de/obje.e) de MicroTOOL Opentool de TNI (www.tni.fr) ORCA (www.telelogic.com/solution/tools/orca.asp) de Telelogic Pragmatica de Pragmatix Software (www.pragsoft.com) Real-Time Studio Prof. dArtisan (www.artisansw.com) Rocase (www.cs.ubbcluj.ro/rocase) de luniversit de Roumanie Babes-Bolyai Rose RealTime de Rational Software Corporation (www.rational.com) RoZeLink dHeadway Software (www.headway-software.com) Select/Enterprise (www.princetonsoftech.com/products) de Princeton Softech Simply Objects (www.adaptive-arts.com/products.htm) dAdaptive SoftModeler/Business (www.softera.com/products.htm) de Softera Structure Builder de Tendril Software (www.tendril.com/) System Architect (www.popkin.com/products/sa2001/product.htm) de Popkin Together/Enterprise (www.togethersoft.com) dObject International UML Designer (www.software.ibm.com/ad/smalltalk/about/umldfact.html) dIBM Visual Modeler (msdn.microsoft.com/vstudio/prodinfo/new.asp) de Microsoft Visual Thought de Confluent (www.confluent.com) Win A&D dExcel Software (www.excelsoftware.com) WithClass de Microgold Software (www.microgold.com) Xtend:Specs (www.iconcomp.com/products/index.html) dICON Computing Et des sites pour en trouver davantage encore. http://www.krumbach.de/home/jeckle/unified.htm : page de M. Jeckle http://www.laas.fr/~delatour/Igloo/index_image_fr.html : page LIGLOO http://www.stm.tj/objet/ : (La bote objets)
2. Notions communes aux diffrents modles

Ce chapitre prsente toutes les notions communes aux modles, savoir des dfinitions gnrales (cycle de vie, etc.) et les lments de modlisation (nom, tiquette, expression, contrainte, proprit, commentaire, note, paquetage, sous-systme, modle, strotype, etc.).
2.1. Dfinitions gnrales

domaine (domain) : champ dapplication lment de modlisation (model element) : reprsentation dune abstraction issue du domaine du problme objet (object) : entit ayant une frontire et une identit bien dfinies qui encapsule un tat et un comportement classe (class) : description dun ensemble dobjets qui partagent les mmes caractristiques systme (system) : ensemble dobjets connects et organiss pour atteindre un but spcifique modle (model) : abstraction smantique ferme dun systme cycle de vie (life cycle) : tapes du dveloppement et ordonnancement de ces tapes analyse (analysis) : dtermination du quoi et du quoi faire dune application conception (conception) : dtermination du comment dune application
Page 5 sur 44
modlisation (modeling) : synonyme danalyse, et par extension, laboration des modles (y compris en conception) mta-modle (metamodel) : modle qui dcrit ses lments de modlisation mta-modlisation (metamodeling) : modlisation rcursive des lments de modlisation partir deux-mmes spcification (specification) : description exhaustive dun lment de modlisation interface (interface) : partie visible dune classe, dun groupe dobjets (parfois utilis comme synonyme de spcification) documentation (documentation) : reprsentation textuelle des modles diagramme (diagram) : reprsentation graphique dlments de modlisation notation (notation) : ensemble des signes et symboles qui composent le langage UML (i.e. ensemble des reprsentations graphiques et textuelles qui constituent les diagrammes) revue : rvision formelle dune documentation, dun modle test (test) : ensemble des mesures et des activits qui visent garantir le fonctionnement satisfaisant du logiciel couche : segmentation horizontale des modles vue (view) : projection des lments de modlisation dun (ou plusieurs) modle(s) selon une certaine perspective
2.2. lments de modlisation

chane (string) : suite de caractres Exemples de chanes :
BankAccount integrate (f: Function, from: Real, to: Real) { author = "Joe Smith", deadline = 31-March-1997, status = analysis }
nom (name) : chane utilise pour identifier un lment dun modle Exemples de noms :
BankAccount integrate controller abstract this_is_a_very_long_name_with_underscores
Exemple de chemin daccs (pathname) :

MathPak::Matrices::BandedMatrix
tiquette (label) : chane attache un symbole graphique Exemple dtiquette : ltiquette BankAccount est attache en tant contenue dans la bote (containment) tandis que ltiquette account est attache par adjacence (adjacency).
mot-cl (keyword) Format dun mot-cl : mot-cl expression (expression) : chane qui value une valeur (dun type particulier) Exemples dexpressions :
BankAccount BankAccount * (*) (Person*, int) array [1..20] of reference to range (-1.0..1.0) of Real [ i > j and self.size > i ]
Exemples du langage OCL (Object Constraint Language) :

flight.pilot.training_hours > flight.plane.minimum_hours company.employees->select (title = "Manager" and self.reports->size > 10)
collection (collection) : regroupement dobjets (terme gnrique qui ne prcise pas la nature du regroupement) cardinalit (cardinality) : nombre dlments dans une collection multiplicit (multiplicity) : spcification dchelle qui prcise les cardinalits autorises type primitif (primitive type) : type prdfini (boolen, expression, liste, chane, point, nom, multiplicit, temps, non interprt). contrainte (constraint) : relation smantique sur des lments de modlisation qui spcifie une proposition devant tre vrifie Format dune contrainte : { contrainte } 1er exemple de contrainte : le prsident de chaque comit doit tre lun des membres de ce comit ({subset}).
Page 6 sur 44
2nd exemple de contrainte : un employ et son chef doivent travailler dans la mme entreprise ({Person.employer=Person.boss.employer}).
proprit (property) : valeur nomme reprsentant une caractristique dun lment de modlisation Format dune proprit : nom proprit = valeur Exemples de proprits :
{ author = "Joe Smith", deadline = 31-March-1997, status = analysis } { abstract }
valeur marque (tagged value) : dfinition explicite dune proprit en prcisant ses nom/valeur commentaire (comment) : chane attache un lment de modlisation, mais sans smantique Exemples de commentaires :
flight.pilot.training_hours > flight.plane.minimum_hours company.employees->select (title = "Manager" and self.reports->size > 10)
note (note) : information textuelle (commentaire bien videmment mais aussi contrainte, valeur marque, corps dune mthode ou dautres chanes values) associe un (ou plusieurs) lment(s) dun modle Exemple de note :
dpendance (dependency) : relation dobsolescence (unidirectionnelle) entre deux lments de modlisation dichotomie type/instance (type-instance correspondence) : sparation de lessence de llment de modlisation (sa spcification) et de la manifestation avec ses valeurs (sa ralisation) de ce type ; cela concerne la sparation classe/objet, association/lien, paramtre/valeur, opration/appel, etc. Exemple de dichotomie classe/objet : la classe Point ( gauche) et deux objets p1:Point et :Point de cette classe ( droite).
dichotomie type/classe (type/class dichotomy) : sparation de la spcification dun lment de modlisation et de la ralisation de cette spcification sous-systme (subsystem) : ensemble dlments de modlisation groups qui constituent une spcification du comportement prsent par les autres lments du modle Format dun sous-systme, avec ses trois compartiments (tous facultatifs) pour les oprations (en haut gauche), les spcifications (en bas gauche) et la ralisation ( droite).
Page 7 sur 44
1er exemple de sous-systme : trois sous-systmes avec leurs interfaces et leurs dpendances.
2nd exemple de sous-systme : les trois compartiments sont prsents et montrent les liens quil y a entre eux.
modle (model) : abstraction (smantiquement ferme) dun systme (physique), contenant des lments de modlisation 1er exemple de modle : le modle systemModel se compose dun modle danalyse (Analysis) et dun modle de conception (Design).
2me et 3me exemple de modles : hirarchies de modles et de sous-systmes (bas gauche sur un modle et droite sur un sous-systme).
Page 8 sur 44
paquetage (package) : regroupement (avec encapsulation) dlments de modlisation, selon un critre logique (et non fonctionnel) 1er exemple de paquetage : plusieurs paquetages avec leurs relations daccs (access) et dimport (import).
2nd exemple de paquetage : le paquetage Editor est prsent sous la forme dun arbre (compos de trois autres paquetages).
strotype (stereotype) : extension de la smantique dun lment du mta-modle Format dun strotype : strotype (ou par une icne). 1er exemple de strotype : le strotype control ( gauche) permettant de reprsenter un stylo (PenTracker) peut tre simplifi soit en enlevant le texte control, soit en enlevant le symbole (cercle flch), soit en optant pour le dessin de droite.
2nd exemple de strotype : le strotype call (le gestionnaire de tches fait appel un planificateur).
Le systme est compos dune hirarchie de paquetages et dun rseau de dpendances entre ces paquetages. En effet, les paquetages fournissent un mcanisme gnral pour la partition et le regroupement des modles. Les trois mcanismes dextension sont : les strotypes, les valeurs marques et les contraintes.
Page 9 sur 44
3. La modlisation
Ce chapitre prsente les vues proposes par UML, les modles et quelques informations pour utiliser les modles selon le niveau dabstraction.
3.1. Les vues

UML propose diffrents modles pour reprsenter les diffrents points de vue de la modlisation. Les 4+1 vues sont : la vue logique (intgrit de conception) : perspective abstraite de la solution (classes, relations, machines tats-transitions, etc.) ; la vue des composants (intgrit de gestion du code) : perspective physique de lorganisation du code (modules, composants, concepts du langage ou de lenvironnement dimplmentation) ; la vue des processus (intgrit dexcution) : perspective sur les activits concurrentes et parallles (tches et processus) ; la vue de dploiement (intgrit de performance) : rpartition du systme (logiciel) travers un rseau ; la vue des cas dutilisation (intgrit de conception), qui guide et justifie les autres : moyen rigoureux et systmatique pour guider la modlisation (cas dutilisation, scnarios, collaborations dobjets, machines tats).
3.2. Les modles

Les 9 modles sont : diagramme de classes (class diagram) [Cf. OMT, Booch et autres mthodes objet] : structure statique (classes et associations) ; diagramme dobjets (object diagram) : instance du diagramme de classes (objets et liens) ; diagramme de cas dutilisation (use case diagram) [Cf. OOSE] : fonctions du systme du point de vue des utilisateurs ; diagrammes de comportement (behavior diagrams) : diagrammes dinteraction (interaction diagrams) : interactions entre les objets (scnarios et flots de messages) diagramme de squence (sequence diagram) [Cf. divers modles (interaction, message trace, event trace) danciennes mthodes non orientes objet] : aspect temporel des interactions entre les objets (squence dvnements) ; diagramme de collaboration (collaboration diagram) [Cf. notamment Booch (object diagram) et Fusion (object interaction graph)] : aspect spatial des interactions entre les objets (relativement leurs rles et aux liens quils ont entre-eux) ; diagramme dactivits (activity graph diagram) [Cf. diagrammes de flots de donnes (work flow diagrams) manant danciennes mthodes (objet ou non)] : comportement dune opration en terme dactions et dactivits ; diagramme dtats-transitions (statechart diagram) [Cf. travaux de D. Harel] : comportement dynamique des objets (changeant dtat en raction des vnements) ; diagrammes de ralisation (implementation diagram) [Cf. Booch (module et process diagram)] : units de travail diagramme de composants (component diagram) : composants logiciels ralisant lapplication (code source, bibliothques, dpendances, etc.) ; diagramme de dploiement (deployment diagram) : rpartition des composants logiciels sur des matriels. De plus, les strotypes [nouveaut dUML] fournissent lun des mcanismes dextension, utiliss notamment pour tendre la smantique du mta-modle, tandis que le langage dexpression de contrainte objet OCL (Object Constraint Language) [Cf. Syntropy ou Catalysis] est utilisable durant toutes les phases du cycle de dveloppement du logiciel, galement utilis par UML pour spcifier sa smantique.
3.3. Utilisation des modles

Rappelons qu'il faut dans un premier temps modliser le mtier de lorganisation tudie, en enchanant les tapes suivantes : tude du primtre et des intervenants extrieurs lorganisation, tude des processus de lorganisation, tude des travailleurs et des entits de lorganisation, tude des flots dvnements des processus, tude des structures organisationnelles. Un acteur est une abstraction extrieure au systme modliser (lorganisation lorsque lon modlise le mtier, le systme informatique dans un second temps) qui interagit avec lui. Il sagit de rles jous par des personnes, de logiciels, de matriels, etc. On dtermine un acteur principal en se demandant qui est destin le systme modliser ? . Un processus dune organisation est soit un processus mtier (visible de lextrieur du systme), soit un processus support (interne lorganisation et donc non visible de lextrieur, support aux processus mtier pour sexcuter), soit un processus de gestion (interne lorganisation et donc non visible de lextrieur, moyens de gestion des processus mtier). Un processus mtier est lensemble des activits internes dun mtier permettant de fournir un rsultat observable et mesurable pour un utilisateur individuel du mtier. Un processus mtier est reprsent par un cas dutilisation (i.e. dans un diagramme de cas dutilisation), et inversement.
Page 10 sur 44
Un diagramme de cas dutilisation est un graphe dacteurs, un ensemble de cas dutilisation englobs par la limite du systme, des relations (ou associations) de communication (participation) entre les acteurs et les cas dutilisation, et des gnralisations de ces cas dutilisation. Les relations de gnralisation/spcialisation entre acteurs permettent de dfinir des profils dacteurs. Les relations entre cas dutilisation sont soit utilise (uses) pour viter de dupliquer des processus communs plusieurs processus, soit tend (extends) pour dcrire sparment des parties alternatives ou optionnelles ou exceptionnelles de processus. Les relations entre acteurs et cas dutilisation indiquent les interactions. Un diagramme de cas dutilisation ne dtaille pas linteraction entre acteur et processus (uniquement la relation et le sens du stimulus sont indiqus) car cest lobjet de la description du cas dutilisation. Une organisation est un systme mtier dans lequel des travailleurs interagissent, communiquent et travaillent ensemble pour excuter les processus mtier. Ainsi, en utilisant les objets et les classes pour reprsenter les travailleurs du mtier, on dfinit une organisation oriente objet. Il existe trois strotypes prdfinis pour les classes dfinies lors de la modlisation du mtier : travailleur dinterface (interface worker) i.e. un travailleur dans le mtier visible du point de vue dun acteur, travailleur interne (internal worker) i.e. un travailleur dans le mtier non visible du point de vue dun acteur, et entit (entity) i.e. une entit manipule dans le mtier par les travailleurs (exemple : rglementation, procdure ; contre-exemple : matriel). La description (textuelle ou via un diagramme dtats-transitions) dun processus dtaille les activits internes du processus, i.e. son flux dvnements (workflow), afin dexpliquer aux intervenants leurs rles et activits ; la description textuelle comporte notamment une brve description du processus, un glossaire des termes du domaine, et une prsentation de chaque flux dvnements normal et de chaque flux dvnements alternatif. La description dun flux dvnements dun processus est utile pour montrer le dtail des interactions entre les travailleurs, identifier les protocoles des travailleurs et des entits, dcrire les parties complexes du processus, dcrire exactement une squence dactivits importantes, etc. La description complte dun flux dvnements dun processus ncessite plusieurs diagrammes. Ainsi, le flux dvnements gnral est divis en parties incompltes reprsentes chacune par un diagramme dinteraction (diagramme de squence et/ou diagramme de collaboration). Le diagramme de squence montre les interactions entre les objets, agences en squence dans le temps ; il montre en particulier les objets participant linteraction par leurs lignes de vie et les messages quils schangent ordonnancs dans le temps mais il ne montre pas les relations entre les objets. Le diagramme de collaboration montre les interactions entre les objets et leurs liens ; il montre en particulier les relations entre les objets mais il ne montre pas le temps. Les diagrammes de squence et de collaboration sont quivalents. Le diagramme dactivits doit quant lui dcrire les activits (des travailleurs) du mtier. Le diagramme de classes permet de reprsenter des classes et leurs relations. Aussi, outre des classes, il peut contenir des types, des paquetages, des relations, voire des instances (objets et liens). Diffrents types de relations peuvent tre exprimes dans un diagramme de classes, et notamment lassociation (relation bidirectionnelle entre plusieurs classes). Le diagramme de classes exprime la traabilit directe entre un processus, ses travailleurs et ses entits (i.e. entre le cas dutilisation et ses classes). En ce sens, il sagit dun diagramme structurel statique. Larchitecture mtier consiste, une fois les processus mtier compltement dcrits, regrouper les travailleurs et les entits en units organisationnelles par units de comptence ou par structures organisationnelles (donnes par lorganigramme de lorganisation). Un travailleur appartient un seul paquetage et, de mme, une entit appartient un seul paquetage ; par contre, une relation peut appartenir plusieurs paquetages. Les strotypes suivants sont utiliss pour les paquetages : organisation, entit externe et infrastructure. Le passage du mtier au systme informatique (comprenant les ressources humaines, les systmes informatiques et dautres ressources) se fait (plus ou moins) directement : les travailleurs mtier deviennent des acteurs, les activits des travailleurs mtier deviennent des cas dutilisation (i.e. processus informatiques), les entits deviennent des objets entits. En plus des besoins fonctionnels ainsi obtenus, le systme informatique devra considrer les besoins techniques, les aspects lis la maintenance, les contraintes technologiques et politiques. Aussi, dans un second temps, il faut modliser le systme informatique en enchanant les tapes suivantes : tude du primtre, des acteurs et des cas dutilisation, description et structuration des cas dutilisation, slection et description des scnarios, identification des objets candidats, description des scnarios avec des diagrammes dinteraction, description des classes et de leurs relations, description de la dynamique de certaines classes. Lobjectif de la capture des besoins consiste dterminer ce que le systme doit faire. Ces besoins sont formaliss par un modle de cas dutilisation reprsent par des acteurs et des cas dutilisation. Les activits danalyse et de conception doivent dcrire la manire dont le systme ralise les besoins (dcrits dans le modle de besoins) et ainsi dfinir rapidement une architecture stable. Ainsi, lanalyse et la conception dbouchent sur un modle de conception bas sur le modle de cas dutilisation et sur le guide dutilisation de lenvironnement de dveloppement. La conception contient la ralisation des cas dutilisation dcrite en terme de classes et dobjets participants.
Page 11 sur 44
Les perspectives considrer pour lanalyse et la conception sont les vues logique (classes importantes, organisation des classes en paquetages et en sous-systmes, organisation des sous-systmes en couches, ralisation des cas dutilisation), processus (tches impliques) et dploiement (nuds physiques avec leurs tches). Les activits danalyse et de conception couvrent trois aspects : architecture, cas dutilisation, et objets. Un mcanisme darchitecture est une (ou un ensemble de) classe(s) ou un pattern constituant une solution commune un problme commun ; cest un concept informatique et logiciel, et il nest donc pas ncessairement li au domaine. Les mcanismes darchitecture sont de trois types : analyse (non contraint par lenvironnement dimplmentation), conception (contraint par lenvironnement dimplmentation : langage de programmation, progiciel, base de donnes, technologie de communication), et implmentation des mcanismes de conception. Le primtre du systme informatique diffre de celui du mtier. Aussi, les acteurs du systme informatique sont les travailleurs du mtier mais pas les utilisateurs du mtier (sauf sils ont directement accs au systme informatique). On dtermine les acteurs du systme (informatique) en rpondant aux questions : Quels sont les utilisateurs qui ont besoin du systme pour raliser leur travail ? , Quels sont les utilisateurs qui excutent les fonctions principales du systme ? , Quels sont les utilisateurs qui excutent les fonctions secondaires (maintenance et administration) du systme ? , Est-ce que le systme interagit avec du matriel et dautres logiciels ? . Un cas dutilisation dfinit le comportement dun systme ou la smantique de toute autre entit en spcifiant une squence dactions (avec des variantes) que lactivit ralise en interagissant avec les acteurs de lentit. On dtermine flux dvnements permettant didentifier les cas dutilisation candidats en rpondant aux questions : Quelles sont les tches fondamentales que lacteur veut faire faire au systme ? , Est-ce que lacteur cre, modifie, supprime ou consulte des informations dans le systme ? , Est-ce que lacteur a besoin dinformer le systme de changements externes ? , Est-ce que lacteur a besoin dtre inform des occurrences survenues dans le systme ? , Est-ce que lacteur commande le dmarrage et larrt du systme ? . Un cas dutilisation englobe plusieurs fonctions du systme. La description dun cas dutilisation peut tre informelle (textuelle) ou plus formelle (diagramme dtats-transitions). Deux descriptions prsentent un cas dutilisation : externe (du point de vue de lacteur) et interne (du point de vue du systme). La description textuelle dun cas dutilisation comporte notamment une brve description et une prsentation (sous la forme dalgorithmes gnraux ou de pseudo-code) de chaque flux dvnements (normal ou alternatif). La structuration du modle de cas dutilisation consiste les regrouper en paquetages, dfinir les variantes (flux normal, flux alternatifs variantes, exceptions, cas derreurs , extensions des cas normaux), et dfinir des points communs (i.e. dcrire dans un cas dutilisation spar un sous-ensemble commun utilis par plusieurs cas dutilisation). La prsentation du modle de cas dutilisation peut comprendre un diagramme de cas dutilisation (acteurs, cas dutilisation et relations) pour les acteurs appartenant au mme paquetage de cas dutilisation, pour un acteur et tous les cas dutilisation avec lesquels il interagit, les cas dutilisation utiliss par le mme groupe dacteurs, pour les cas dutilisation souvent excuts en squence, pour un cas dutilisation avec ses variantes et ses sous-cas dutilisation, pour les cas dutilisation les plus importants. Un cas dutilisation est une abstraction de plusieurs chemins dexcution, et un scnario est une instance dun cas dutilisation. Une fois les cas dutilisation dcrits, il faut slectionner un ensemble de scnarios (pour chaque cas dutilisation) qui serviront qui serviront piloter litration en cours de dveloppement. Le choix repose sur llimination des risques (les plus importants) et donc commence par le plus difficile ! Les scnarios sont classs : principal (cas normal) ou secondaire (cas alternatif, exception, erreur). Les scnarios servent analyser et concevoir le systme, justifier a posteriori les choix darchitecture, et tester le logiciel. La description textuelle dun scnario (script) permet didentifier les objets candidats (et les interactions). Ensuite, le scnario peut tre reprsent graphiquement par un ou plusieurs diagrammes dinteraction (diagrammes de squence et/ou diagrammes de collaboration) bass sur les objets candidats prcdemment identifis ; il est cependant possible dintroduire de nouveaux objets (formulaire de saisie servant dinterface entre lacteur et le systme, objet englobant plusieurs rgles de gestion et soccupant de leur enchanement et de leur validation, etc.). Une classe est un ensemble dobjets possdant une structure, un comportement et des relations similaires. Une classe est statique (i.e. cest une description) contrairement un objet qui est actif. On construit plusieurs diagrammes de classe qui montrent les classes qui participent un cas dutilisation, les classes qui participent un scnario, les classes prives dun paquetage, les classes publiques dun paquetage, une hirarchie de paquetages, le dtail dune classe avec ses relations principales. Il existe trois strotypes prdfinis pour distinguer les objets informatiques dune classe : frontire (boundary) i.e. une classe dont les objets sont visibles par les acteurs du systme, entit (entity) qui reprsente des phnomnes internes au systme (souvent des objets persistants), et contrle (control) i.e. une classe interne au systme qui contrle le comportement dun ou plusieurs cas dutilisation (exemples : activit de contrle, rgle de gestion, superviseur, moyen de dcouplage entre objets, etc.). Le comportement dune classe est dcrit par lensemble de ses responsabilits qui sont elles-mmes mises en uvre par des oprations. Une opration possde une signature (type de retour et liste des paramtres avec le type de chacun), peut avoir des pr ou des post-conditions, etc. Les messages des diagrammes dinteraction qui arrivent sur une instance sont des candidats pour donner naissance des oprations. La difficult consiste trouver un quilibre, lors de leurs spcifications, entre oprations lmentaires ou complexes. Un attribut est une proprit nomme de classe qui porte un ensemble de valeurs que les objets vont prendre. Un attribut possde un type, une valeur initiale, et une multiplicit. Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04 Page 12 sur 44
Afin de protger la cohrences des donnes, il est conseill de rendre priv tous les attributs, et donc de fournir des oprations (publiques) daccs aux attributs. On distingue diffrents types de relations entre classes : lassociation (relation statique reliant plusieurs classes entre elles), lagrgation (variante de lassociation qui dfinit une relation partie de entre instances de classes), la gnralisation (relation statique de classification entre une classe plus spcifique qui contient par hritage tous les attributs, membres, relations dune classe plus gnrale), dpendance (relation unidirectionnelle entre deux classes qui ne requiert pas forcment des instances ; les diffrentes formes sont : la trace qui tablit une relation historique entre deux lments, le raffinement qui dcrit une drivation historique entre deux lments avec une transformation, et lutilisation), etc. Une classe-association est une association qui est en mme temps une classe. Les paquetages possdent les lments de modlisation. Un lment peut tre public ou priv. Les relations entre paquetages sont lappartenance stricte (imbrication des paquetages) et lutilisation. Quelques critres de regroupement techniques : grouper les classes smantiquement proches, organiser les paquetages en couches (i.e. quun paquetage nutilise que les paquetages de mme niveau ou de niveau infrieur), viter les couplages forts entre paquetages, etc. Les paquetages permettent de structurer le modle, la rutilisation, dorganiser lquipe de dveloppement (pour rpartir le travail et les responsabilits), de jeter les bases de la gestion de la configuration. Une interface est la dclaration dune collection doprations utilisables pour dfinir un service. Les relations sur les interfaces sont : la fourniture (une classe donne fournit linterface ses clients), lutilisation (toute classe cliente qui dsire utiliser linterface), et la ralisation (une classe fournit une implmentation des oprations dfinies dans une autre classe). Une machine tats est un comportement qui spcifie les suites dtats quun objet ou une interaction traverse durant sa vie en rponse des vnements, avec les rponses et les actions. Une machine tats est un automate fini, dterministe et connexe. Un tat est une situation stable dans laquelle un objet peut tre observ en train dexcuter une activit (ou attendre un vnement). Ltat initial (start) est obligatoire et unique tandis quil peut y avoir aucun, un ou plusieurs tats finaux (stop). Un vnement est une circonstance laquelle un objet est susceptible de ragir. Les types dvnements sont : appel (rception dun requte pour demander lexcution dune opration), changement (de valeur, dattribut ou dune relation), signal (en rception), et temporel (rsultat dune chance temporelle). Une transition est une relation entre un tat source et un tat cible, survenant soit suite un vnement, soit automatiquement. Une condition de garde permet de dfinir si la transition effectuer est valide ou non (i.e. que la transition est franchie uniquement si lexpression est vraie). Une action est un traitement atomique excut au cours dune transition. De plus, les vnements dentre (entry) dans un tat ou de sortie (exit) dun tat peuvent donner lieu une action. Une activit est un traitement effectu par un objet dans un tat. On peut crer une hirarchie dtats : un super-tat se dcompose en sous-tats (qui possdent leurs propres machines tats). Les diagrammes dtats-transitions sont des machines tats. On ne dfinit un diagramme dtats-transitions pour un classe que si sa dynamique est complexe. Le diagramme dactivit est une machine tats particulire dans laquelle les tats sont des activits reprsentant la ralisation doprations et o les transitions sont dclenches par la fin des oprations. Un diagramme dactivit est attach dans sa globalit une classe ou limplmentation dune opration ou encore un cas dutilisation. Un tat action est un tat qui contient une action interne et au moins une transition sortante. Un tat action peut dclencher plusieurs transitions qui doivent tre accompagnes chacune dune condition de garde toutes mutuellement exclusives (concept de dcision). Un diagramme dactivit peut tre dcoup en couloirs reprsentant chacun une responsabilit de lactivit et assigne un objet (concept de partition). Les strotypes introduisent une distinction dusage. Un strotype est associable tout lment de modlisation (classe, opration, attribut, relation, paquetage, composant, nud, etc.). Le langage dexpression de contraintes OCL permet de spcifier des invariants sur les classes dans le modle de classes, de spcifier des invariants pour les strotypes, de dcrire des pr et post-conditions sur les oprations, de dcrire des conditions de garde, de servir de langage de navigation, de spcifier les contraintes sur les oprations.
4. Lexemple jouet
Le jour de la rentre, le secrtariat de ltablissement avise les tudiants quils ont jusqu la fin de la semaine pour amener les originaux des diplmes quils ont obtenus, ceci permettant de complter les fiches des tudiants (qui figurent ci-aprs).
Page 13 sur 44
Numro INE de ltudiant : 2 Nom : LEROI Dpartement de naissance : 40 Diplmes obtenus par ltudiant : Intitul abrg Intitul complet
Voitures possdes par ltudiant : Numro dimmatriculation Couleur
Anne
BAC DEUG
Baccalaurat Diplme dtudes Universitaires Gnrales
1980 1982
Numro INE de ltudiant : 3 Nom : DUPOND Dpartement de naissance : 17 Diplmes obtenus par ltudiant : Intitul abrg Intitul complet
Anne
BAC DUT MIAGe
Baccalaurat Diplme Universitaire de Technologie Matrise des Mthodes Informatiques Appliques la Gestion des Entreprises
1981 1983 1985
Numro INE de ltudiant : 4 Nom : MARTIN Dpartement de naissance : 47 Diplmes obtenus par ltudiant : Intitul abrg Intitul complet
4747 LA 47
rouge
Anne
BAC DEUG MIAGe
Baccalaurat Diplme dtudes Universitaires Gnrales Matrise des Mthodes Informatiques Appliques la Gestion des Entreprises
1977 1980 1982
Numro INE de ltudiant : 5 Nom : DURAND Dpartement de naissance : 33 Diplmes obtenus par ltudiant : Intitul abrg Intitul complet
3333 BX 33 4040 NT 40
rouge jaune
Anne
BAC DUT
Baccalaurat Diplme Universitaire de Technologie
1981 1983
Numro INE de ltudiant : 7 Nom : LEROI Dpartement de naissance : 33 Diplmes obtenus par ltudiant : Intitul abrg Intitul complet
Anne
Page 14 sur 44
5. Les modles
Ce chapitre dcrit les neuf diagrammes dUML : de classes, dobjets, de cas dutilisation, de squence, de collaboration, dactivits, dtats-transitions, de composants et de dploiement.
5.1. Diagramme de classes

Un objet (object) est une entit ayant une frontire et une identit bien dfinie. Un attribut (attribute) est une caractristique dun objet. La syntaxe dun attribut : visibilit nom attribut [ multiplicit ] : type retour = valeur initiale { proprit } o la visibilit est soit + (public), soit # (protg), soit - (priv) et dont la multiplicit est de 1..1 par dfaut. Un attribut soulign correspond un attribut de classe. Exemples dattributs : lattribut size est public, de type Area dfinissant un carr de 100 de ct (non modifiable) ; lattribut colors doit prendre exactement trois valeurs ; lattribut name est facultatif (il peut prendre au plus une valeur).
+size: Area = (100,100) { frozen } #visibility: Boolean = invisible +default-size: Rectangle #maximum-size: Rectangle -xptr: XWindowPtr colors [3]: Color points [2..*]: Point name [0..1]: String
Une opration (operation) est un service dont un objet peut demander lexcution. La syntaxe dune opration : visibilit nom opration ( liste paramtres ) : type retour { proprit } o la visibilit est soit + (public), soit # (protg), soit - (priv) et un paramtre suit la syntaxe entre/sortie nom paramtre : type = valeur dfaut o lentre/sortie est soit in (par dfaut), soit out, soit inout. Exemples doprations : lopration attachXWindow est prive et requiert le paramtre xwin de type Xwindow*.
+create () +display (): Location -attachXWindow(xwin:Xwindow*)
Le corps dune opration peut tre montr dans une note attache lopration. Lexemple ci-dessous montre le corps if isTripped then station.alert(self) de lopration report.
Une classe (class) est la description dun ensemble dobjets ayant une structure (attributs), un comportement (oprations et mthodes) et des relations similaires. Une classe est gnralement reprsente par un rectangle ayant trois compartiments : le nom de la classe (avec ventuellement un strotype et des proprits), les attributs et les oprations. On peut simplifier la reprsentation en ne conservant que le premier compartiment. Inversement, on peut rajouter des compartiments (ventuellement nomms) pour les rgles de gestion (business rules), les responsabilits, les vnements, les exceptions, etc. On peut galement regrouper des listes dlments dun compartiment en leur appliquant un strotype. Lexemple ci-aprs illustre diffrentes reprsentations possibles de la classe Window : sans aucun dtail ( gauche), au niveau de lanalyse (au centre) et au niveau de limplmentation ( droite). Ainsi, comme lillustre le dessin du centre, la classe Window a deux attributs (size et visibility) et deux oprations (display et hide).
Page 15 sur 44
Lexemple ci-dessous illustre une classe (PenTracker) avec un strotype (controller et son symbole) et deux proprits (leaf et author).
Lexemple ci-dessous illustre ( gauche, classe Rectangle) des strotypes (constructor, query, update) appliqus des listes doprations et ( droite, classe Reservation) des compartiments nomms (operations, responsibilities, exceptions).
La gnralisation (generalization) concernant les classes est une relation de taxinomie (classification) entre une classe gnrale (le pre) et une classe spcifique (le fils) telle que dune part la classe spcifique est totalement cohrente avec la classe gnrale et dautre part la classe spcifique ajoute des informations la classe gnrale. Le symbole ... indique que dautres classes spcifiques existent dans le modle mais ne figurent pas sur le schma. Lexemple ci-dessous (les deux reprsentations sont quivalentes) montre que la classe gnrale Shape (forme) se spcialise en trois classes spcifiques Polygon, Ellipse et Spline.
Le discriminant (discriminator) permet de regrouper diffrentes classes spcifiques. Diffrentes contraintes peuvent tre appliques sur les classes gnrale/spcifiques : chevauchement ({overlapping}) i.e. quun objet de la classe gnrale peut donner lieu plusieurs objets des classes spcifiques, disjoint ({disjoint}) i.e. quun objet de la classe gnrale ne peut pas donner lieu plusieurs objets des classes spcifiques ;
Page 16 sur 44
complet ({complete}) i.e. que la liste de toutes les classes spcifiques est spcifie, incomplet ({incomplete}) i.e. quon sait que la liste de toutes les classes spcifiques nest pas entirement spcifie. Lexemple ci-dessous montre que Tree (arbre) se spcialise en trois (mais il y en a dautres) espces disjointes Oak (chne), Elm (orme) et Birch (bouleau).
Lexemple ci-aprs montre que les vhicules (Vehicle) sont discrimins selon la puissance (power) et selon le lieu dutilisation (venue). Pour les deux discriminants, le chevauchement est possible ; par exemple, et selon la puissance, un avion ultra lger motoris (ULM) peut voler soit grce au vent, soit avec son moteur. Quant au camion (Truck), cest un vhicule (Vehicle) terrestre (Land Vehicle) quip dun moteur (MotorPowered Vehicle).
Une interface (interface) est la spcification doprations dune classe visibles de lextrieur. Lexemple ci-dessous prsente deux interfaces (Hashable et Comparable) pour la classe String, toutes deux utilisables par la classe HashTable. De plus, la liste des oprations (isEqual et hash) de linterface Comparable est donne.
Un lien (link) est une connexion entre plusieurs objets. Une association (association) est une relation statique entre plusieurs classes. Une association binaire relie deux classes (ventuellement la mme). Une classe dassociation (association class) est une association ayant des proprits de classe ou une classe ayant des proprits dassociation. Lexemple ci-aprs montre lassociation binaire Job (emploi) qui relie les classes Company (les employeurs) et Person (les employs), lassociation Manages (dirige) qui est rflexive car elle relie deux fois la mme classe Job (pour avoir les chefs et leurs subordonns) et donc Job est une classe dassociation.
Page 17 sur 44
Un rle (role) prcise la signification de lentit proximit du rle dans lassociation. Une multiplicit (multiplicity) spcifie lensemble des cardinalits possibles (parmi les entiers naturels) sur un rle. On peut prciser un intervalle ( dbut .. fin ), une liste de valeurs (spares par des virgules), ne pas borner suprieurement (*). Exemples de multiplicits : 1 (un et un seul), 0..1 (un au plus : la valeur est facultative), 2..5 (de deux cinq), 0..* ou * (quelconque i.e. au moins zro), 1..* (au moins un), 2,5,7 (deux, cinq ou sept), 1,3..6,9..* (un, de trois six, ou au moins neuf). Les liens ne sont pas tris par dfaut (lorsque la multiplicit est strictement suprieure un !) : pour indiquer que ces liens doivent tre tris, on note la contrainte {ordered} sur le rle correspondant. Dautres contraintes peuvent tre exprimes comme par exemple une contrainte dexclusion (xor-constraint) entre associations indiquant que, pour chaque instance, une seule des associations concernes peut tre instancie un moment donn. Lexemple ci-dessous montre que chaque compte (Account) concerne soit une personne (Person), soit une socit commerciale (Corporation).
Lexemple ci-dessous montre que le prsident de chaque comit doit tre lun des membres de ce comit.
Lexemple ci-dessous montre quun employ et son chef doivent travailler dans la mme entreprise.
La navigabilit (navigability) indique que linformation ne peut tre accde via lassociation que dans un seul sens (de la classe source vers la classe cible qui est pointe) ; par dfaut, on peut accder une information dans nimporte quel sens. La visibilit (visibility) attache un rle peut tre publique (+ ou {public}), protge (# ou {protected}) ou prive (ou {private}). La variabilit (changeability) indique si des donnes peuvent tre mises jour (ajoutes, modifies, supprimes) ou non. Par dfaut, une donne peut tre mise jour. Par exemple, la contrainte {frozen} indique quune donne, une fois cre, ne peut plus tre mise jour tandis que la contrainte {addOnly} indique quon ne peut quajouter des donnes. Il existe de nombreuses variantes dassociations : lagrgation, la composition, la qualification. Lagrgation (aggregation) est une relation tout/partie entre le compos (ensemble, agrgat) et le composant (llment). La composition (composition) est une agrgation o la vie des composants est subordonne la vie de leurs composs. La qualification prcise un ensemble dattributs (qualifier) dont les valeurs partitionnent lensemble des instances associes. Lexemple ci-aprs montre deux associations : lagrgation Contains qui relie les classes Polygon et Point (un polygone est compos dune liste trie dau moins trois points ; les points sont visibles ; on ne peut pas partir dun point retrouver le polygone) tandis que lautre association est une composition.
Page 18 sur 44
Les deux exemples ci-dessous montre des associations qualifies. Sur lexemple de gauche, pour une banque et un numro de compte donns, il y a au plus une personne (tandis quune personne peut avoir aucun, un ou plusieurs comptes). Sur lexemple de droite, un chiquier et un rang et un fichier donns identifient une seule case.
Lexemple ci-dessous montre de trois faons (diffrentes mais quivalentes) la composition dune fentre en deux barres de dfilement, un titre et un corps.
Une association n-aire (n-ary association) relie plus de deux classes (n est au moins gal trois). Pour la multiplicit dassociations n-aires, il convient de se rfrer au 3.46.1 (p. 3-73) de la documentation : Multiplicity for n-ary associations may be specified, but is less obvious than binary multiplicity. ! Le modle entits-associations est de ce point de vue beaucoup plus clair et sans ambigut (nombre doccurrences n-1 valeurs associes pour 1 occurrence de lentit considre). Fort heureusement, lorsquune association n-aire est justifie, la cardinalit maximale est plusieurs . Lexemple ci-dessous illustre une association (avec ses responsabilits) ternaire Record (enregistrement) qui relie les classes Team (quipe), Year (anne) et Player (joueur) afin denregistrer que tel joueur tait le gardien de but de telle quipe lors de telle saison.
Un lment driv (derivated element) est un lment (attribut, association, etc.) calculable partir dautres lments. La syntaxe dun lment driv : / nom lment . Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04 Page 19 sur 44
Lexemple ci-dessous illustre un attribut driv : lge (age) est calcul partir de la date du jour (currentDate) et de la date de naissance (birthdate).
Lexemple ci-dessous illustre une association drive : on connat lentreprise pour laquelle une personne travaille (WorksForCompany) en passant par les deux associations reliant la classe des dpartements (Department) aux classes des personnes (Person) et des entreprises (Company).
Une dpendance (dependency) indique une relation entre deux classes (ou entre dautres lments de modlisation tel que les paquetages) o lorsquun changement intervient dans une classe, lautre classe est affecte. Lexemple ci-dessous illustre diffrentes sortes de dpendances (friend, call, instantiate, refine).
Un diagramme de classes (class diagram) montre la structure statique (et aucune information temporelle) dun systme. Un diagramme de classes est reprsent par un graphe dlments (classes, types, interfaces, paquetages, et mme instances) connects par des relations. Le diagramme de classes de lexemple jouet (ci-aprs).
Page 20 sur 44
< Possder * Voitures NImmatChiffres NImmatLettres NImmatDepart /NImmat Couleur

est possed par possde
1 Etudiants NINE NomEtu DepartNaissEtu DiplomesEnreg AvertirEtus SaisirDiplomes
1..*
a obtenu
* Diplomes
est obtenu par
IntitAbrege IntitComplet
AvoirObtenu Annee
{ unicit de NINE } { unicit de IntitAbrege } { unicit de NImmat } { unicit de IntitComplet }
{ NImmat = concatnation de NImmatChiffres,NImmatLettres,NImmatDepart }
Page 21 sur 44
5.2. Diagramme dobjets

Un objet (object) est une entit ayant une frontire et une identit bien dfinies qui encapsule un tat (attributs et relations) et un comportement (oprations, mthodes ou machines tats). Un objet peut tre reprsent par un rectangle ayant deux compartiments : le nom dobjet et les attributs. Plus gnralement, on simplifie la reprsentation en ne conservant que le premier compartiment. La syntaxe dun nom dobjet : nom objet : nom classe [ liste tats ] o la classe peut prciser les paquetages dimbrication successifs. La syntaxe dun attribut dobjet : nom attribut : type = valeur . Lexemple ci-dessous prsente des triangles (les objets) instances de la classe des polygones.
Lexemple ci-dessous illustre lutilisation de licne dun strotype pour lobjet scheduler.
Un objet composite (composite object) est un objet de haut niveau constitu de parties fortement lies. Lexemple ci-dessous illustre une fentre compose de deux barres de dfilement, dune surface et dun titre.
Une classe (class) est la description dun ensemble dobjets ayant une structure, un comportement et des relations similaires. Un objet est une instance dune classe. Linstanciation (instanceOf) montre la connexion entre une instance (instance) et son conteneur (classifier). Lexemple ci-dessous montre linstanciation de trois personnes.
Person
instanceOf
instanceOf
instanceOf
Jill:Person
Joe:Person
Chris:Person
Un lien (link) est une connexion entre plusieurs objets. Lexemple ci-aprs montre un club de descente ski (downhillSkiClub) compos de trois membres (Jill, Joe et Chris), et dont Jill est le trsorier (ou la trsorire) et Chris le prsident (ou la prsidente). Clairement, le diagramme de classe correspondant comporte les deux classes Club et Person relies par lassociation member et par lassociation officer qualifie par la fonction exerce au sein du bureau du club.
Page 22 sur 44
Une association (association) est une relation statique entre plusieurs classes. Un lien est une instance dune association. Un lien est une liste de rfrences dobjets (un couple de rfrences dans le cas dune association binaire). Un diagramme dobjets (object diagram) montre des instances compatibles avec un diagramme de classes, un moment donn. Un diagramme dobjets est reprsent par un graphe dinstances (objets et liens), avec les valeurs des donnes mais sans les classes. Le diagramme dobjets de lexemple jouet (ci-dessous). Les valeurs dattributs de quelques objets (la voiture 3333 BX 33, ltudiant 5, ltudiant 3 ayant obtenu le diplme DUT, le diplme BAC) sont entirement donns.
(5,DUT) : AvoirObtenu
3333 BX 33 : Voitures NImmatChiffres = 3333 NImmatLettres = BX NImmatDepart = 33 NImmat = 3333 BX 33 Couleur = rouge
5 : Etudiants NINE = 5 NomEtu = DURAND DepartNaissEtu = 33 DiplomeEnreg = vrai
DUT : Diplomes
(3,DUT) : AvoirObtenu Annee = 1983
3 : Etudiants 4040 NT 40 : Voitures 2 : Etudiants DEUG : Diplomes 4747 LA 47 : Voitures 4 : Etudiants MIAGe : Diplomes
7 : Etudiants (4,4747 LA 47) : Possder
BAC : Diplomes IntitAbrege = BAC IntitComplet = Baccalaurat
Page 23 sur 44
5.3. Diagramme de cas dutilisation

Un acteur (actor) est un ensemble cohrent de rles jous par des entits externes (utilisateur, dispositif matriel ou autre systme) qui interagissent avec le systme. Un acteur est reprsent par licne strotype standard dhomme bton (stick man) avec dessous le nom de lacteur, ou par une classe avec le mot-cl actor. Lexemple ci-dessous prsente lacteur Customer (client).
Un cas dutilisation (use case) reprsente une unit cohrente dune fonctionnalit fournie par un systme (ou sous-systme ou classe) spcifie par une squence dactions que le systme peut excuter en interagissant avec les acteurs du systme. Un cas dutilisation est reprsent par une ellipse avec dedans le nom du cas dutilisation, et ventuellement un strotype, des attributs, des oprations, et des points dextension. Lexemple ci-dessous prsente le cas dutilisation Fill orders (remplir les commandes).
Un point dextension (extension point) rfrence un endroit dans le cas dutilisation o la squence dactions dun autre cas dutilisation doit tre insre. Les relations entre acteur et cas dutilisation, entre acteurs, et entre cas dutilisation sont les suivantes : lassociation (association) exprimant la participation de lacteur au cas dutilisation ; la gnralisation (generalization) dun acteur A vers un acteur B indiquant quune instance de A peut communiquer avec les mmes cas dutilisation que les instances de B ; la gnralisation (generalization) dun cas dutilisation A vers un cas dutilisation B indiquant que A est une spcialisation de B ; lextension (extend) dun cas dutilisation A vers un cas dutilisation B indiquant quune instance de B peut tre augmente par le comportement spcifi dans A, lendroit dfini par le point dextension ; linclusion (include) dun cas dutilisation A vers un cas dutilisation B indiquant quune instance de A contiendra le comportement spcifi dans B un endroit dfini. Lexemple ci-dessous illustre notamment une association entre lacteur Salesperson (vendeur) et Place Order (classer la commande), une gnralisation de lacteur Supervisor (chef de rayon) vers lacteur Salesperson (vendeur), lextension du cas dutilisation Request Catalog (demander le catalogue) vers le cas dutilisation Place Order (classer la commande), linclusion du cas dutilisation Place Order (classer la commande) vers le cas dutilisation Order Product (commander le produit).
Un diagramme de cas dutilisation (use case diagram) montre les relations entre les acteurs et les cas dutilisation dun systme.
Page 24 sur 44
Un diagramme de cas dutilisation est reprsent par un graphe dacteurs, un ensemble de cas dutilisation, ventuellement des interfaces, et les relations entre ces lments. Lexemple ci-dessous prsente le diagramme de cas dutilisation Telephone Catalog (catalogue tlphonique) regroupant 4 acteurs et 4 cas dutilisation. Ainsi, lacteur Shipping Clerk (employ de bureau) est en relation (il sagit dune association) avec le cas dutilisation Fill orders (remplir les commandes).
Remarque : dans un diagramme de cas dutilisation, lencadrement des cas dutilisation (qui sert montrer la frontire du systme) est facultatif. Les diagrammes de cas dutilisation de lexemple jouet (ci-dessous), du mtier tout dabord et du systme informatique ensuite. Le travailleur dinterface Secrtariat utilise le cas dutilisation Grer les diplmes des tudiants qui concerne galement lacteur Etudiant.
Secrtariat
Grer les diplmes des tudiants
Etudiant
Secrtariat
(from Cas d'utili sati on mtier)
Grer les diplmes des tudiants

(from Cas d'utili sati on mtier)
Page 25 sur 44
5.4. Diagramme de squence

Un stimulus (stimulus) est une communication entre deux objets qui schangent de linformation dans lespoir quune action (exemples : invocation dune opration, dclenchement dun signal, cration dobjet, suppression dobjet) sensuivra. Un message (message) est la spcification dun stimulus, prcisant les rles auxquels lmetteur et le rcepteur doivent se conformer. Les diffrentes communications : appel de procdure (procedure call) ou flot de contrle imbriqu (nested flow of control) : reprsents par une flche dont la pointe est remplie (filled solid arrowhead) ; flot de contrle non imbriqu (flat flow of control) : reprsent par une flche dont la pointe nest pas remplie (stick arrowhead) ; stimulus asynchrone (asynchronous stimulus) ; reprsent par une flche dont la demi-pointe nest pas remplie (half stick arrowhead) :
retour de procdure (return from procedure call) : reprsent par une flche en pointill dont la pointe nest pas remplie (dashed arrow with stick arrowhead).
Une interaction (interaction) est une squence de communications i.e. un ensemble partiellement ordonn de messages. Un diagramme de squence (sequence diagram) montre une interaction arrange en squence dans le temps (i.e. montre la squence explicite des stimuli changs entre les objets). Un diagramme de squence a deux dimensions : la dimension verticale reprsente le temps et la dimension horizontale reprsente les objets ; les stimuli sont changs entre les objets. Une ligne de vie (lifeline) montre un objet jouant un rle spcifique. Un objet peut tre cr ou dtruit durant la priode dcrite par le diagramme de squence. Une activation (activation ou focus on control) montre la priode durant laquelle un objet est en train dexcuter une action (directement ou par un sous-programme). Lexemple ci-dessous prsente un diagramme de squence avec trois objets (caller, exchange, receiver) concurrents (car reprsents dans des botes avec un cadre pais).
Lexemple ci-aprs prsente un diagramme de squence avec diffrentes actions : activation, alternative, rcursion, cration et suppression. Lacteur dclenche lopration op() qui cre lobjet ob1, qui dclenche soit lopration foo(x) si x>0 en crant lobjet ob2 soit lopration bar(x) si x<0 en activant lobjet ob3, qui apple rcursivement lopration more() et qui dtruit lobjet ob1 avant de rendre la main lacteur. De plus, lorsque lobjet ob4 termine son action, il rend la main lobjet qui la appel (ob2 ou ob3).
Page 26 sur 44
Les diagrammes de squence de lexemple jouet , pour le scnario Avertir les tudiants tout dabord (ci-dessous) et pour le scnario Enregistrer les diplmes ensuite (ci-aprs) du cas dutilisation Grer les diplmes des tudiants.
: Secrtariat 1: diplmes originaux exigs diplmes enregistrs ? 2: AvertirEtus (<<create>>)
: Etudiant
Page 27 sur 44
diplmes enregistrs ?
: Secrtariat 1: diplmes originaux reus 2: Contrler les diplmes
: Etudiant
3: [valide] SaisirDiplomes 4: diplmes originaux rendus
Page 28 sur 44
5.5. Diagramme de collaboration

Un stimulus (stimulus) est une communication entre deux objets qui schangent de linformation dans lespoir quune action (exemples : invocation dune opration, dclenchement dun signal, cration dobjet, suppression dobjet) sensuivra. Un message (message) est la spcification dun stimulus, prcisant les rles auxquels lmetteur et le rcepteur doivent se conformer. Les diffrentes communications ou types de flots de contrle (control flow type) : appel de procdure (procedure call) ou flot de contrle imbriqu (nested flow of control) : reprsents par une flche dont la pointe est remplie (filled solid arrowhead) ; flot de contrle non imbriqu (flat flow of control) : reprsent par une flche dont la pointe nest pas remplie (stick arrowhead) ; stimulus asynchrone (asynchronous stimulus) ; reprsent par une flche dont la demi-pointe nest pas remplie (half stick arrowhead) :
retour de procdure (return from procedure call) : reprsent par une flche en pointill dont la pointe nest pas remplie (dashed arrow with stick arrowhead).
liste prdcesseurs / [ garde ] squence nom message ou stimulus liste arguments o les prdcesseurs sont reprsents
La syntaxe dune tiquette sur un flot de contrle :

valeur retour :=
par des nombres (spars par des virgules) et o la squence est reprsente par des termes (spars par des points) ; un terme a la forme entier ou nom rcurrence o la rcurrence peut tre [ condition ] (alternative), * [ itration ] (rptitive) ou *|| (traitement parallle). Exemples dtiquettes : 2: display(x,y) message simple 1.3.1: p:= find(specs) appels imbriqus avec une valeur retourne [x < 0] 4: inv(x,color) message conditionn A3,B4/ C3.1*: update() synchronisation avec dautres traitements (A3 et B4 doivent tre finis) et itration Une collaboration (collaboration) est une construction statique qui montre (uniquement) les objets et leurs relations impliqus dans laccomplissement dun objectif (ou dun ensemble dobjectifs lis) inclus dans un systme plus gnral (comportant dautres objectifs). Une collaboration permet de dcrire la ralisation dune opration, dun cas dutilisation, etc. Un nom dobjet dune collaboration est de la forme : nom objet / nom rle : nom classe ; par exemple, O:C pour un objet nomm O de la classe C sans prciser de rle. Un nom de rle dune collaboration est de la forme : / nom rle : nom classe ; par exemple, /R pour un rle nomm R sans prciser de classe. Une interaction (interaction) est une squence de communications i.e. un ensemble partiellement ordonn de messages. Une interaction est dfinie dans le contexte dune collaboration. Un diagramme de collaboration (collaboration diagram) montre une collaboration et peut galement prsenter une interaction (rappel : une collaboration ne montre pas les communications contrairement une interaction). Un diagramme de collaboration est un graphe dfini soit au niveau des spcifications, soit au niveau des instances. Au niveau des spcifications, un diagramme de collaboration montre les rles (classes et associations) dfinis dans une collaboration, et ventuellement les messages. Au niveau des instances, un diagramme de collaboration montre une collection dobjets et de liens, et ventuellement les stimuli qui de plus doit tre conforme au niveau des spcifications. Lexemple ci-dessous prsente un diagramme de collaboration au niveau des spcifications. Les enseignants (des personnes), membres dune facult, donnent des cours et des tudiants (des personnes) ; les tudiants ont un enseignant qui les tuteure.
Lexemple ci-aprs prsente un diagramme de collaboration au niveau des instances, avec des objets, des liens et des stimuli. Lacteur demande les enseignants des tudiants (studentTeachers()), cest dire les noms des enseignants (namesOfTeachers()) des tudiants qui suivent (lecturer()) des (pour i=1..n) cours (Course) assurs par des enseignants (le nom name() de lenseignant assurant le ime cours). Plusieurs objets (tutor et lecturer) jouent ici le mme rle (Teacher).
Page 29 sur 44
On peut exprimer des contraintes telles que la cration dobjets au cours de lexcution ({new}), la suppression dobjets au cours de lexcution ({destroyed}) ou encore la cration et la suppression dobjets au cours de lexcution ({transient}). Lexemple ci-dessous prsente un diagramme de collaboration au niveau des instances, avec la cration dobjets au cours de lexcution.
Lexemple ci-dessous montre lutilisation dune collaboration (Observer) dans un diagramme de classes.
Lexemple ci-dessous illustre la gnralisation/spcialisation dune collaboration (entre Supervisor et Observer).
Un multi-objet (multiobject) reprsente un ensemble dobjets. On se sert des multi-objets par exemple lorsquune opration sadresse lensemble entier des objets et non un seul des objets. Un multi-objet est reprsent par un second rectangle lgrement dcal vers le haut et droite. Lexemple ci-aprs montre un multi-objet (Server du haut).
Page 30 sur 44
Un objet actif (active object) est un objet qui possde un processus lger (thread) de contrle et qui peut initialiser lactivit de contrle. Un objet passif (passive object) est un objet qui possde des donnes mais pas un traitement de contrle. Lexemple ci-dessous illustre un objet actif composite. Le gestionnaire de lusine (factory manager) pilote le robot (robot) et le four (oven).
Les diagrammes de collaboration de lexemple jouet (ci-dessous), au niveau des spcifications (il sagit en fait dun diagramme de classes, les classes pouvant tre des entits, des travailleurs ou des acteurs) tout dabord (ci-dessous) et au niveau des instances ensuite pour le scnario Avertir les tudiants (ci-dessous) et pour le scnario Enregistrer les diplmes (ci-aprs) du cas dutilisation Grer les diplmes des tudiants.
Diplmes des tudiants
0..*
0..1
1..*
1..*
Grer les diplmes des tudiants Secrtariat Etudiant
1: diplmes originaux exigs diplmes enregistrs ?

[ enregistrer]
2: AvertirEtus (<<create>>) : Secrtariat : Etudiant
Page 31 sur 44
2: Contrler les diplmes
1: diplmes originaux reus diplmes enregistrs ?

[ enregistrer]
3: [valide] SaisirDiplomes 3.1: <<become>>
4: diplmes originaux rendus : Secrtariat : Etudiant
[enregistrs]
Page 32 sur 44
5.6. Diagramme dactivits

Un vnement (event) est une occurrence notable. Un tat (state) est une situation dans laquelle un objet ou une action satisfait certaines conditions, excute des actions ou attend des vnements. Une transition (transition) est une relation entre deux tats qui indique quun objet dans ltat source entrera dans ltat cible et excutera des actions spcifiques quand un vnement prcis surviendra et si certaines conditions sont satisfaites. Une machine tats est un comportement qui spcifie les suites dtats quun objet ou une interaction traverse durant sa vie en rponse des vnements, avec les rponses et les actions. Une machine tats est un automate fini, dterministe et connexe. Un tat action (action state) est un tat avec une action en entre et au moins une transition en sortie (qui fait suite la fin de laction dentre). Un tat action est reprsent par un rectangle aux cts arrondis vers lextrieur. Lexemple ci-dessous montre deux tats action : celui de gauche est exprim en langage naturel tandis que celui de droite est exprim dans un langage de programmation.
Un tat action de sous-activit (subactivity state) invoque un diagramme dactivit. Lexemple ci-dessous montre un tat action de sous-activit (on le sait grce au symbole figurant en bas droite dans ltat action).
Une transition automatique est une relation qui indique le passage dun tat action vers un autre tat action, ds la fin du traitement effectu par ltat action source. Il sagit dun flot de contrle. Une transition est reprsente par une flche. Une dcision (decision) permet dexprimer une condition de garde sur une transition. Lexemple ci-dessous illustre une dcision prendre (cost < $50 ou non) suite ltat action Calculate total cost et la fusion vers ltat action Charge customers account.
Lalgorithme quivalent :
Calculate total cost si cost $50 alors Get authorization Charge customers account
Un diagramme dactivits (activity diagram) est une variante des machines tats dans laquelle les tats correspondent lexcution dactions ou dactivits (i.e. sont des tats action) et o les transitions sont automatiques. Un diagramme dactivits sutilise pour montrer les vnements correspondant des actions internes (i.e. des flots de contrle de procdures). Un diagramme dactivit est attach dans sa globalit soit une classe, soit un cas dutilisation, soit un paquetage, soit limplmentation dune opration. Lexemple ci-aprs (en haut) illustre un diagramme dactivits pour une personne qui prpare une boisson (lordre de ses prfrences est le suivant : caf, cola, rien). Notez les synchronisations (laction Turn on Machine sexcute ds que les actions Put filter in Machine et Add Water to Reservoir sont toutes deux finies) et la paralllisation (une fois laction Find Beverage finie et si la condition de garde (found coffee) est vraie, les trois actions Put Coffee in Filter, Add Water to Reservoir et Get Cups peuvent tre ralises en parallle). Les couloirs (swimlanes) permettent dorganiser les responsabilits des actions et sous-activits selon la classe (le plus souvent, il sagira des units organisationnelles). Il est possible de reprsenter le flot dobjets (en entre ou en sortie dune ou plusieurs actions). Lexemple ci-aprs (en bas) illustre un diagramme dactivits montrant les responsabilits (les trois couloirs Customer, Sales et Stockroom) et les flots de lobjet Order (dans les tats placed, entered, filled et delivered) en plus des actions, des flots de contrle et des synchronisations.
Page 33 sur 44
Page 34 sur 44
On peut prciser graphiquement une action correspondant lenvoi ou la rception dun signal. Un vnement diffr (deferrable event) est un vnement qui nest pas consomm ds sa survenance mais qui est plac dans une file dattente (syntaxe : vnement / defer) pour tre utilis ultrieurement (syntaxe : vnement ). Lexemple ci-aprs illustre lenvoi (turnOn) et la rception (light goes out) dun signal ainsi quun vnement diffr (light goes out) qui nest pas immdiatement trait sil survient durant les actions Brew coffee et Get cups (light goes out / defer).
Un tat action de synchronisation permet de modliser une machine contenant des rgions concurrentes. Lexcution dun tat action peut tre rpte en prcisant la multiplicit dans le coin suprieur droit de cet tat action. On parle dinvocation dynamique car cette multiplicit peut tre value au cours de lexcution. Les diagrammes dactivits de lexemple jouet (ci-dessous), pour le scnario Avertir les tudiants tout dabord (ci-dessous) et pour le scnario Enregistrer les diplmes ensuite (ci-aprs) du cas dutilisation Grer les diplmes des tudiants.
AvertirEtus (<<create>>)
[ enregistrer]
Page 35 sur 44
Contrler les diplmes
[ enregistrer]
[valide]
[non valide]
SaisirDiplomes
[enregistrs]
Page 36 sur 44
5.7. Diagramme dtats-transitions

Un vnement (event) est une occurrence notable. Un vnement peut tre une condition passant de faux vrai, la rception dun signal, la rception dun appel de procdure, la fin dune priode de temps. Exemples dvnements faisant rfrence une priode de temps :
after ( 10 seconds since exit from state S ) when ( date = 1/1/2000 )
Les vnements surviennent un un. Un tat (state) est une situation dans laquelle un objet ou une action satisfait certaines conditions, excute des actions ou attend des vnements. Une transition simple (transition) est une relation entre deux tats qui indique quun objet dans ltat source entrera dans ltat cible et excutera des actions spcifiques quand un vnement prcis surviendra et si certaines conditions sont satisfaites. Une transition est reprsente par une flche sur laquelle sont ventuellement mentionns lvnement, la condition de garde et des actions ou activits. La syntaxe dune transition : vnement ( liste paramtres ) [ garde ] / suite actions ou activits o les paramtres (spars par des virgules) ont la forme paramtre : type . Quelques vnements sont prdfinis : entry (lors de lentre dans ltat), exit (lors de la sortie de ltat), do (activit excute quand lobjet ou linteraction est dans cet tat), include (pour identifier linvocation dune sous-machine). Lexemple ci-dessous montre une transition activable sur lvnement denfoncement du bouton droit de la souris (rightmouse-down), ayant comme paramtre la position (location), valide si la position est dans la fentre (location in window), et gnrant deux actions pour rcuprer lobjet (object := pick-object (location)) et le mettre en inversion vido (object.highlight ()).
right-mouse-down (location) [location in window] / object := pick-object (location); object.highlight ()
Un tat est simple ou composite. Un tat est reprsent par un rectangle aux coins arrondis compos dventuellement plusieurs compartiments. Les compartiments dcrivent le nom de ltat, les transitions internes (i.e. les actions ou les activits internes excutes lorsque lobjet ou linteraction est dans cet tat), une rgion graphique (pour un tat composite). Lexemple ci-dessous montre ltat Typing Password ragissant quatre vnements (entry, exit, character et help).
Si un vnement ne dclenche pas de transition (de ltat courant vers un autre tat, ou interne ltat courant), il est ignor et supprim. Un diagramme dtats-transitions (statechart diagram) reprsente le comportement dentits (objets, interactions, etc.) susceptibles dun comportement dynamique en spcifiant ses rponses (tats et actions) la rception des vnements intervenant au cours de sa vie. Cela concerne bien videmment les classes mais aussi les cas dutilisation, les acteurs, les soussystmes, les oprations, les mthodes. Une machine tats est un automate fini, dterministe et connexe. Un diagramme dtats-transitions est un graphe qui reprsente une machine tats (les sommets sont les tats ou pseudo-tats tandis que les arcs sont les transitions). Lexemple ci-aprs illustre un diagramme dtats-transitions dun appel tlphonique (lutilisateur vient de dcrocher son combin pour tlphoner). Le pseudo-tat initial place lobjet dans ltat DialTone, la frappe du premier chiffre (avant 15 secondes) fait passer dans ltat Dialing, la frappe dautres (du deuxime lavant-dernier) chiffres (avant 15 secondes) fait boucler dans ltat Dialing, la frappe du dernier chiffre fait tenter dtablir la connexion (/connect) et fait passer dans ltat Connecting si le numro compos est valide, etc.
Page 37 sur 44
Un tat composite (composite state) est un tat divis en rgions (regions) concurrentes. Chaque rgion doit avoir un pseudo-tat initial et un ou plusieurs pseudo-tats finaux. Une transition vers ltat composite (super-tat) dclenche une transition vers le pseudo-tat initial de chaque rgion. Une transition vers lun des pseudo-tats finaux dune rgion correspond la fin de lactivit de cette rgion. La fin des activits de toutes les rgions correspond la fin de lactivit du super-tat. Une transition depuis lextrieur de ltat composite vers un sous-tat dune rgion dclenche toutes les actions dentre, tous les niveaux dimbrication ; de mme, une transition depuis un sous-tat dune rgion vers lextrieur de ltat composite dclenche toutes les actions de sortie, tous les niveaux dimbrication. Une transition depuis ltat composite quivaut une transition applique chaque sous-tat de la rgion correspondante (et tous les niveaux dimbrication). Un seul vnement peut dclencher plusieurs transitions sil est applicable dans plusieurs rgions concurrentes. Lexemple ci-dessous montre un super-tat Dialing qui se dcompose en deux sous-tats squentiels (Start et Partial Dial).
Lexemple ci-aprs montre un tat composite Incomplete qui se dcompose en trois rgions. Lentre dans le super-tat Taking Class fait passer les rgions dans des tats Lab1, Term Project et Final Test. Supposons tout dabord que lvnement lab done survienne : la rgion du haut passe dans ltat Lab2. Supposons ensuite que lvnement project done survienne : la rgion de milieu est donc finie. Si maintenant lvnement fail survient, alors les trois rgions sont termines et ltat est Failed ; sinon (cest lvnement pass qui est survenu) la rgion du bas est donc finie et ds que lvnement project done surviendra, la rgion du haut sera finie et ltat sera finalement Passed.
Page 38 sur 44
Il est possible de masquer la dcomposition dun tat composite. Lexemple ci-dessous illustre un tat composite dont la dcomposition est masque (on le sait grce au symbole figurant en bas
droite dans ltat). Afin dviter de dessiner tous les tats imbriqus, on peut se restreindre au dessin de ltat le plus gnral et les transitions subsumes (subsumed transitions) peuvent tre remplaces par une souche (stub). Lexemple ci-dessous illustre deux diagrammes dtats-transitions, celui de gauche pouvant tre abstrait par celui de droite.
Une sous-machine tats (submachine state) reprsente linvocation dune machine tats dfinie ailleurs. Les transitions en entre et en sortie peuvent tre globales ou concerner nimporte quel sous-tat, tous les niveaux dimbrication. Lexemple ci-dessous illustre la sous-machine tats Handle Failure. Lvnement error1 fait entrer dans le sous-tat sub1, lvnement error2 fait entrer dans le sous-tat sub12 du sous-tat sub1, lvnement error3 fait entrer dans le pseudo-sous-tat initial de la sous-machine tats, lvnement fixed depuis le sous-tat subEnd fait sortir de la sousmachine tats, et larrive dans lun des pseudo-sous-tats finaux fait sortir de la sous-machine tats.
Un tat de synchronisation (synch state) permet de synchroniser des rgions concurrentes. Il est not par une barre. Lexemple ci-aprs illustre plusieurs tats de synchronisation. Avant dinstaller llectricit dans la charpente (Install Electricity In Frame), il faut que la charpente soit construite (Build Frame) et que llectricit soit installe dans les fondations (Install Electricity In Foundation). Par contre, ds que la charpente est construite (Build Frame), on peut simultanment poser le toit (Put On Roof) et, si llectricit a t installe dans les fondations (Install Electricity In Foundation), installer llectricit dans la charpente (Install Electricity In Frame).
Page 39 sur 44
Chaque rgion peut contenir un indicateur dtat historique (history state), not par la lettre H encercle, pseudo-tat ayant au
moins une transition en entre (depuis un tat extrieur) et au plus une transition en sortie (vers un tat de la rgion). Lexemple ci-aprs illustre un diagramme dtats-transitions avec un indicateur dtat historique. On peut imaginer le droulement suivant : lobjet est dans ltat A, franchit la transition A-A1 et passe dans ltat A1, franchit la transition interrupt et passe dans ltat C, franchit la transition resume et passe dans ltat A2, franchit la transition A2-A1 et passe dans ltat A1, franchit la transition ok et passe dans ltat A, franchit la transition A-A1ouA2 et passe dans ltat A1.
A-A1 ok A2-A1 A2-A A1-A2
A-A1ouA2
Une transition combine (compound transition) est une succession de traitements ( travers des pseudo-tats et des transitions) excuts comme une transition atomique. Un tel pseudo-tat peut tre un point de jonction (junction point) ou un point de choix dynamique (dynamic choice point), commun un ou plusieurs tats en entre comme en sortie. Lexemple ci-dessous illustre six transitions combines : deux transitions se rejoignent (merge) et se sparent (split) en trois transitions. Le point de jonction est commun aux deux transitions provenant des tats State0 et State1. Les trois transitions gardes sortant du point de jonction reprsentent un point de branchement statique (static branch point). Lvaluation des gardes de sortie dun point de jonction se fait avant demprunter la transition y entrant (ainsi, on ne peut pas rester dans un tel pseudo-tat).
Lalgorithme quivalent la transition combine allant de ltat State0 vers ltat State2 : si lobjet est dans ltat State0 et lvnement e2 survient et b<0 et a<0 alors lobjet passe dans ltat State2 sinon lobjet reste dans ltat State0 Lexemple ci-aprs illustre trois transitions combines : une transition se spare (split) en trois transitions. Les trois transitions gardes sortent du point de choix dynamique. Lvaluation des gardes de sortie dun point de choix dynamique se fait en y entrant (ainsi, on pourrait rester dans un tel pseudo-tat mais ce cas doit tre rendu impossible, grce aux conditions sur les gardes des transitions en sortie qui doivent imposer le passage dune et dune seule transition en sortie).
Page 40 sur 44
Lalgorithme quivalent : si lobjet est dans ltat State1 et lvnement e1 survient et b<0
alors a := f(m)
lobjet passe dans le pseudo-tat de choix dynamique

selon que a<0 : lobjet passe dans ltat State2 a=5 : lobjet passe dans ltat State3 sinon lobjet passe dans ltat State4 sinon lobjet reste dans ltat State1
Le diagramme dtats-transitions de lexemple jouet (ci-dessous), indiquant si les diplmes (pour chaque tudiant) ont t enregistrs.
/ AvertirEtus enregistrer entry: DiplomesEnreg = faux diplmes originaux reus [ valide ] / SaisirDiplomes enregistrs entry: DiplomesEnreg = vrai
Page 41 sur 44
5.8. Diagramme de composants

Un composant (component) reprsente une partie distribuable dun systme. Au niveau mtier, dans un systme humain, les composants comprennent les rgles de gestion et les documents ; au niveau informatique, les composants contiennent les programmes (sources, excutables). Lexemple ci-dessous reprsente (au niveau type) le composant Dictionary. De plus, il propose deux interfaces.
Un diagramme de composants (component diagram) montre les dpendances entre les composants (entre les informations dans un systme humain, ou pour le compilateur). Un diagramme de composants est reprsent par un graphe de composants connects par des relations de dpendance (et ventuellement par des relations de composition). Un composant ne peut tre reprsent quau niveau type (et non niveau des instances). Lexemple ci-dessous illustre un diagramme de composants ayant trois composants (Scheduler, Planner et GUI) et deux relations de dpendance (entre le composant Planner et linterface Reservations du composant Scheduler, et entre le composant GUI et linterface Update du composant Planner).
Le diagramme de composants de lexemple jouet (ci-dessous).
<<SGBD>> BD
* Grer les diplmes des tudiants
Page 42 sur 44
5.9. Diagramme de dploiement

Un composant (component) reprsente une partie distribuable dun systme. Il peut contenir des programmes (sources, excutables) ou, pour un systme humain, des documents de gestion notamment. Un composant peut tre reprsent soit au niveau type, soit au niveau des instances. Lexemple ci-dessous reprsente le composant Dictionary au niveau type. De plus, il propose deux interfaces.
Lexemple ci-dessous reprsente le composant mymailer au niveau des instances. De plus, il possde trois objets en cours dexcution.
Un nud (node) est un objet physique correspondant une ressource de traitement (mmoire et processeur). Il sagit dordinateurs, de ressources humaines, de traitements mcaniques. Un nud peut tre reprsent soit au niveau type, soit au niveau des instances. Lexemple ci-dessous reprsente (au niveau des instances) le nud Node1. De plus, il possde deux composants en cours dexcution.
Un diagramme de dploiement (deployment diagram) montre la configuration des organes de traitements (run-time processing element) ainsi que les composants logiciels, les traitements et les objets qui y vivent. Au niveau mtier, ces organes de traitements correspondent aux travailleurs et aux units organisationnelles tandis que les composants logiciels comprennent les procdures et les documents utiliss par ces travailleurs et ces units organisationnelles. Un diagramme de dploiement est reprsent par un graphe de nuds connects par des associations de communication. Un nud peut possder des instances de composants ; un composant peut possder des objets. Lexemple ci-dessous illustre un diagramme de dploiement ayant deux nuds (AdminServer:HostMachine et JoesMachine:PC), une relation de dpendance (entre le composant :Planner et linterface reservations du composant :Scheduler) et un objet (meetingsDB).
Le diagramme de dploiement de lexemple jouet (ci-aprs).
Page 43 sur 44
<<UNIX>> Serveur BD
<<LAN>> ethernet
* PC Secrtariat
Page 44 sur 44

Uml

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Uml

Hochgeladen von

Copyright:

Verfügbare Formate

Dpartement Informatique de lInstitut Universitaire de Technologie de lUniversit Bordeaux 1

1.1. Quelques mthodes objet

1.2. Un langage unifi pour la modlisation objet

1.3. Quelques gnralits

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

1.5.1. Ouvrages en langue franaise

1.5.3. Sites Internet

1.5.4. Groupes de discussion

2. Notions communes aux diffrents modles

2.1. Dfinitions gnrales

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

2.2. lments de modlisation

Exemple de chemin daccs (pathname) :

Exemples du langage OCL (Object Constraint Language) :

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

3.1. Les vues

3.2. Les modles

3.3. Utilisation des modles

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

Voitures possdes par ltudiant : Numro dimmatriculation Couleur

Baccalaurat Diplme dtudes Universitaires Gnrales

Voitures possdes par ltudiant : Numro dimmatriculation Couleur

BAC DUT MIAGe

1981 1983 1985

Voitures possdes par ltudiant : Numro dimmatriculation Couleur

BAC DEUG MIAGe

1977 1980 1982

Voitures possdes par ltudiant : Numro dimmatriculation Couleur

Baccalaurat Diplme Universitaire de Technologie

Voitures possdes par ltudiant : Numro dimmatriculation Couleur

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

5.1. Diagramme de classes

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

< Possder * Voitures NImmatChiffres NImmatLettres NImmatDepart /NImmat Couleur

1 Etudiants NINE NomEtu DepartNaissEtu DiplomesEnreg AvertirEtus SaisirDiplomes

{ unicit de NINE } { unicit de IntitAbrege } { unicit de NImmat } { unicit de IntitComplet }

{ NImmat = concatnation de NImmatChiffres,NImmatLettres,NImmatDepart }

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

5.2. Diagramme dobjets

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

5 : Etudiants NINE = 5 NomEtu = DURAND DepartNaissEtu = 33 DiplomeEnreg = vrai

(3,DUT) : AvoirObtenu Annee = 1983

7 : Etudiants (4,4747 LA 47) : Possder

BAC : Diplomes IntitAbrege = BAC IntitComplet = Baccalaurat

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

5.3. Diagramme de cas dutilisation

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

Grer les diplmes des tudiants

Grer les diplmes des tudiants

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

5.4. Diagramme de squence

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

: Secrtariat 1: diplmes originaux exigs diplmes enregistrs ? 2: AvertirEtus (<<create>>)

Modifi le 5/11/04 17:11 - dit le 6/4/10 15:04 - Imprim le 6/4/10 15:04

: Secrtariat 1: diplmes originaux reus 2: Contrler les diplmes