Cours UML

UML en franais
visiteurs sont dj passs par ici...
UML (Unified Modeling Language, traduisez "langage de modlisation objet unifi") est n de la fusion des trois mthodes qui ont le plus influenc la modlisation objet au milieu des annes 90 : OMT, Booch et OOSE. Issu "du terrain" et fruit d'un travail d'experts reconnus, UML est le rsultat d'un large consensus. De trs nombreux acteurs industriels de renom ont adopt UML et participent son dveloppement. En l'espace d'une poigne d'annes seulement, UML est devenu un standard incontournable. La presse spcialise foisonne d'articles exalts et en croire certains, utiliser les technologies objet sans UML relve de l'hrsie. Lorsqu'on possde un esprit un tant soit peu critique, on est en droit de s'interroger sur les raisons qui expliquent un engouement si soudain et massif ! UML est-il rvolutionnaire ? L'approche objet est pourtant loin d'tre une ide rcente. Simula, premier langage de programmation implmenter le concept de type abstrait l'aide de classes, date de 1967 ! En 1976 dj, Smalltalk implmente les concepts fondateurs de l'approche objet : encapsulation, agrgation, hritage. Les premiers compilateurs C++ datent du dbut des annes 80 et de nombreux langages orients objets "acadmiques" ont tays les concepts objets (Eiffel, Objective C, Loops...). Il y donc dj longtemps que l'approche objet est devenue une ralit. Les concepts de base de l'approche objet sont stables et largement prouvs. De nos jours, programmer "objet", c'est bnficier d'une panoplie d'outils et de langages performants. L'approche objet est une solution technologique incontournable. Ce n'est plus une mode, mais un rflexe quasi-automatique ds lors qu'on cherche concevoir des logiciels complexes qui doivent "rsister" des volutions incessantes.
http://uml.free.fr/intro/uml_free_fr_intro.html (1 sur 10) [09/04/2004 12:09:48]
UML en franais
Oui, mais... Tout n'est pas si rose. Beaucoup on cd aux sirnes de l'orient objet et leur aveuglement a fait couler bien des projets... Premier hic : l'approche objet est moins intuitive que l'approche fonctionnelle. Malgr les apparences, il est plus naturel pour l'esprit humain de dcomposer un problme informatique sous forme d'une hirarchie de fonctions atomiques et de donnes, qu'en terme d'objets et d'interaction entre ces objets. Or, rien dans les concepts de base de l'approche objet ne dicte comment modliser la structure objet d'un systme de manire pertinente. Quels moyens doit-on alors utiliser pour mener une analyse qui respecte les concepts objet ? Sans un cadre mthodologique appropri, la drive fonctionnelle de la conception est invitable... Beaucoup l'ont appris leurs dpens. Autre problme critique : l'application des concepts objet ncessite une trs grande rigueur. Le vocabulaire prcis est un facteur d'chec important dans la mise en oeuvre d'une approche objet (risques d'ambiguts et d'incomprhensions). Beaucoup de dveloppeurs (mme expriments) ne pensent souvent objet qu' travers un langage de programmation. Or les langages orients objet ne sont que des outils qui proposent une manire particulire d'implmenter certains concepts objet. Ils ne valident en rien l'utilisation de ces moyens techniques pour concevoir un systme conforme la philosophie objet. Connatre C++ ou Java n'est donc pas une fin en soi, il faut aussi savoir se servir de ces langages bon escient. La question est donc de savoir "qui va nous guider dans l'utilisation des concepts objet, si ce ne sont pas les langages orients objet ?". Pour finir : comment comparer deux solutions de dcoupe objet d'un systme si l'on ne dispose pas d'un moyen de reprsentation adquat ? Il est trs simple de dcrire le rsultat d'une analyse fonctionnelle, mais qu'en est-il d'une dcoupe objet ?
Pour remdier ces inconvnients majeurs de l'approche objet, il nous faut donc : 1) un langage (pour s'exprimer clairement l'aide des concepts objets), qui doit permettre de
q
reprsenter des concepts abstraits (graphiquement par exemple),
limiter les ambiguts (parler un langage commun, au vocabulaire prcis, indpendant des langages orients objet),
faciliter l'analyse (simplifier la comparaison et l'valuation de solutions).
UML en franais
2) une dmarche d'analyse et de conception objet, pour

q
ne pas effectuer une analyse fonctionnelle et se contenter d'une implmentation objet, mais penser objet ds le dpart,
dfinir les vues qui permettent de dcrire tous les aspects d'un systme avec des concepts objets.
En d'autres termes : il faut disposer d'un outil qui donne une dimension mthodologique l'approche objet et qui permette de mieux matriser sa richesse. La prise de conscience de l'importance d'une mthode spcifiquement objet ("comment structurer un systme sans centrer l'analyse uniquement sur les donnes ou uniquement sur les traitements, mais sur les deux"), ne date pas d'hier. Plus de 50 mthodes objet sont apparues durant le milieu des annes 90 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...). Aucune ne s'est rellement impose. L'absence de consensus sur une mthode d'analyse objet a longtemps frein l'essor des technologies objet. Ce n'est que rcemment que les grands acteurs du monde informatique ont pris conscience de ce problme. L'unification et la normalisation des mthodes objet dominantes (OMT, Booch et OOSE) ne datent que de 1995. UML est le fruit de cette fusion. UML, ainsi que les mthodes dont il est issu, s'accordent sur un point : une analyse objet passe par une modlisation objet. Modlisation, modle ? Un modle est une abstraction de la ralit. L'abstraction est un des piliers de l'approche objet. Il s'agit d'un processus qui consiste identifier les caractristiques intressantes d'une entit en vue d'une utilisation prcise. L'abstraction dsigne aussi le rsultat de ce processus, c'est--dire l'ensemble des caractristiques essentielles d'une entit, retenues par un observateur. Un modle est une vue subjective, mais pertinente de la ralit. Un modle dfinit une frontire entre la ralit et la perspective de l'observateur. Ce n'est pas "la ralit", mais une vue trs subjective de la ralit. Bien qu'un modle ne reprsente pas une ralit absolue, un modle reflte des aspects importants de la ralit, il en donne donc une vue juste et pertinente. Le caractre abstrait d'un modle doit notamment permettre de faciliter la comprhension du systme tudi. Il rduit la complexit du systme tudi, permet de simuler le systme, le reprsente et reproduit ses comportements. Concrtement, un modle rduit (dcompose) la ralit, dans le but de disposer d'lments de travail exploitables par des moyens mathmatiques ou informatiques.
UML en franais
UML permet donc de modliser une application selon une vision objet. Mais plus concrtement, qu'est UML ? UML possde plusieurs facettes. C'est une norme, un langage de modlisation objet, un support de communication, un cadre mthodologique. UML est tout cela la fois, ce qui semble d'ailleurs engendrer quelques confusions... Je vous invite maintenant dcouvrir ces diffrents visages d'UML et par l mme, vous forger votre propre opinion...
UML, OMG, OMA et cie.
Fin 1997, UML est devenu une norme OMG (Object Management Group). Cela vous semble certainement sans importance, mais pourtant... L'OMG est un organisme but non lucratif, cr en 1989 l'initiative de grandes socits (HP, Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'OMG fdre plus de 850 acteurs du monde informatique. Son rle est de promouvoir des standards qui garantissent l'interoprabilit entre applications orientes objet, dveloppes sur des rseaux htrognes. L'OMG propose notamment l'architecture CORBA (Common Object Request Broker Architecture), un modle standard pour la construction d'applications objets distribus (rpartis sur un rseau). Pour rester simple, on peut considrer CORBA comme une gnralisation de l'architecture clients/serveurs aux objets. Au centre de l'architecture CORBA, un routeur de messages (ORB : Object Request Broker) permet des objets clients d'envoyer des requtes et de recevoir des rponses, sans avoir se proccuper des dtails techniques propres l'infrastructure du rseau. L'ORB se charge de transmettre les requtes aux objets concerns, o qu'ils se trouvent (dans le mme processus, dans un autre, sur un autre noeud du rseau...). Le bus CORBA (dont l'ORB est le composant central) permet d'assurer la transparence des invocations de mthodes ; les requtes aux objets semblent toujours tre locales. De plus, l'ORB assure une coopration entre objets qui est indpendante des langages de programmation. Le modle CORBA permet en effet de se focaliser sur les interfaces des objets, qu'on exprime en IDL (Interface Definition Language). L'IDL dcrit de manire standard l'interface d'un objet, en faisant abstraction des dtails qui relvent de son d'implmentation. Avec CORBA, il n'est donc pas ncessaire de savoir comment les objets sont cods pour utiliser leurs services. L'utilisation d'IDL comme langage pivot dans la construction d'une architecture, permet de grer l'htrognit. Cette approche, qui consiste masquer les couches techniques du rseau
UML en franais
(systme d'exploitation, processeur, langage de programmation...), permet d'assurer l'interoprabilit de toute application objets distribus, conforme au modle CORBA. CORBA fait partie d'une vision globale de la construction d'applications rparties, appele OMA (Object Management Architecture) et dfinie par l'OMG. Sans rentrer dans les dtails, on peut rsumer cette vision par la volont de favoriser l'essor industriel des technologies objet, en offrant un ensemble de solutions technologiques non propritaires, qui suppriment les clivages techniques. UML a t adopt (normalis) par l'OMG et intgr l'OMA, car il participe cette vision et parce qu'il rpond la "philosophie" OMG.
Penser objet avec UML, pour concevoir objet.
Pour penser et concevoir objet, il faut savoir "prendre de la hauteur", jongler avec des concepts abstraits, indpendants des langages d'implmentation et des contraintes purement techniques. Les langages de programmation ne sont pas un support d'analyse adquat pour "concevoir objet". Ils ne permettent pas de dcrire des solutions en terme de concepts abstraits et constituent un cadre trop rigide pour mener une analyse itrative. Pour conduire une analyse objet cohrente, il ne faut pas directement penser en terme de pointeurs, d'attributs et de tableaux, mais en terme d'association, de proprits et de cardinalits... Utiliser le langage de programmation comme support de conception ne revient bien souvent qu' juxtaposer de manire fonctionnelle un ensemble de mcanismes d'implmentation, pour rsoudre un problme qui ncessite en ralit une modlisation objet. Au risque d'en dcourager certains et d'en dcevoir d'autres, l'approche objet ncessite une analyse rflchie, qui passe par diffrentes phases exploratoires ! Bien que raisonner en terme d'objets semble naturel, l'approche fonctionnelle reste la plus intuitive pour nos esprits cartsiens... Voil pourquoi il ne faut pas se contenter d'une implmentation objet, mais se discipliner "penser objet" au cours d'une phase d'analyse pralable. Toutes les drives fonctionnelles de code objet ont pour origine le non respect des concepts de base de l'approche objet (encapsulation...) ou une utilisation dtourne de ces concepts (hritage sans classification...). Ces drives ne sont pas dues de mauvaises techniques de programmation ; la racine du mal est bien plus profonde ! Bref, programmer en C++ ou en Java n'implique pas forcment concevoir objet... Les difficults de mise en oeuvre d'une approche "rellement objet" ont engendr bien souvent des dceptions, ce qui a longtemps constitu un obstacle important l'essor des technologies objet. Beaucoup ont cd au leurre des langages de
UML en franais
programmation orients objet et oubli que le code n'est qu'un "moyen". Le respect des concepts fondamentaux de l'approche objet prime sur la manire dont on les implmente. Ne penser qu' travers un langage de programmation objet est un mirage qui vous dtourne de l'essentiel. Pour sortir les technologies objet de cette impasse fatale, l'OMG propose UML. UML comble une lacune importante des technologies objet. Il permet d'exprimer et d'laborer des modles objet, indpendamment de tout langage de programmation. Il a t pens pour servir de support une analyse base sur les concepts objet. Mais UML offre bien plus encore ! C'est un langage formel, dfini par un mtamodle. Le mtamodle d'UML dcrit de manire trs prcise tous les lments de modlisation (les concepts vhiculs et manipuls par le langage) et la smantique de ces lments (leur dfinition et le sens de leur utilisation). En d'autres termes : UML normalise les concepts objet. Un mtamodle permet de limiter les ambiguts et encourage la construction d'outils. Il permet aussi de classer les diffrents concepts du langage (selon leur niveau d'abstraction ou leur domaine d'application) et expose ainsi clairement sa structure. Enfin, on peut noter que le mtamodle d'UML est lui-mme dcrit par un mta-mtamodle de manire standardise, l'aide de MOF (Meta Object Facility : norme OMG de description des mtamodles). Cela vous semble peuttre anecdotique, mais prouve si ncessaire le soin apport par l'OMG pour dfinir UML. Vritable cl de vote de l'OMA, UML est donc un outil indispensable pour tous ceux qui ont compris que programmer objet, c'est d'abord concevoir objet. UML n'est pas l'origine des concepts objets, mais il en constitue une tape majeure, car il unifie les diffrentes approches et en donne une dfinition plus formelle.
Un langage universel et visuel.
UML est avant tout un support de communication performant, qui facilite la reprsentation et la comprhension de solutions objet :
q
Sa notation graphique permet d'exprimer visuellement une solution objet, ce qui facilite la comparaison et l'valuation de solutions.
L'aspect formel de sa notation, limite les ambiguts et les incomprhensions.
UML en franais
Son indpendance par rapport aux langages de programmation, aux domaines d'application et aux processus, en font un langage universel.
Petit apart : La notation graphique d'UML n'est que le support du langage. La vritable force d'UML, c'est qu'il repose sur un mtamodle. En d'autres termes : la puissance et l'intrt d'UML, c'est qu'il normalise la smantique des concepts qu'il vhicule ! Qu'une association d'hritage entre deux classes soit reprsente par une flche termine par un triangle ou un cercle, n'a que peu d'importance par rapport au sens que cela donne votre modle. La notation graphique est essentiellement guide par des considrations esthtiques, mme si elle a t pense dans ses moindres dtails. Par contre, utiliser une relation d'hritage, reflte l'intention de donner votre modle un sens particulier. Un "bon" langage de modlisation doit permettre n'importe qui de dchiffrer cette intention de manire non quivoque ! Il est donc primordial de s'accorder sur la smantique des lments de modlisation, bien avant de s'intresser la manire de les reprsenter. Le mtamodle UML apporte une solution ce problme fondamental. UML est donc bien plus qu'un simple outil qui permet de "dessiner" des reprsentations mentales... Il permet de parler un langage commun, normalis mais accessible, car visuel. Il reprsente un juste milieu entre langage mathmatique et naturel, pas trop complexe mais suffisamment rigoureux, car bas sur un mtamodle.
UML comme cadre d'une analyse objet.

Une autre caractristique importante d'UML, est qu'il cadre l'analyse. UML permet de reprsenter un systme selon diffrentes vues complmentaires : les diagrammes. Un diagramme UML est une reprsentation graphique, qui s'intresse un aspect prcis du modle ; c'est une perspective du modle. Chaque type de diagramme UML possde une structure (les types des lments de modlisation qui le composent sont prdfinis) et vhicule une smantique prcise (il offre toujours la mme vue d'un systme).
UML en franais
Combins, les diffrents types de diagrammes UML offrent une vue complte des aspects statiques et dynamiques d'un systme. Les diagrammes permettent donc d'inspecter un modle selon diffrentes perspectives et guident l'utilisation des lments de modlisation (les concepts objet), car ils possdent une structure. Une caractristique importante des diagrammes UML, est qu'ils supportent l'abstraction. Cela permet de mieux contrler la complexit dans l'expression et l'laboration des solutions objet. UML opte en effet pour l'laboration des modles, plutt que pour une approche qui impose une barrire stricte entre analyse et conception. Les modles d'analyse et de conception ne diffrent que par leur niveau de dtail, il n'y a pas de diffrence dans les concepts utiliss. UML n'introduit pas d'lments de modlisation propres une activit (analyse, conception...) ; le langage reste le mme tous les niveaux d'abstraction. Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction. L'laboration encourage une approche non linaire, les "retours en arrire" entre niveaux d'abstraction diffrents sont facilits et la traabilit entre modles de niveaux diffrents est assure par l'unicit du langage. UML favorise donc le prototypage, et c'est l une de ses forces. En effet, modliser une application n'est pas une activit linaire. Il s'agit d'une tche trs complexe, qui ncessite une approche itrative, car il est plus efficace de construire et valider par tapes, ce qui est difficile cerner et matriser. UML permet donc non seulement de reprsenter et de manipuler les concepts objet, il sous-entend une dmarche d'analyse qui permet de concevoir une solution objet de manire itrative, grce aux diagrammes, qui supportent l'abstraction.
UML : le chemin vers lunification des processus.
Grce au principe d'laboration des modles, UML permet de mieux matriser la part d'inconnu et d'incertitudes qui caractrisent les systmes complexes. Mais cet aspect mthodologique d'UML ne doit pas vous induire en erreur. UML est un langage qui permet de reprsenter des modles, mais il ne dfinit pas le processus d'laboration des modles ! Qualifier UML de "mthode objet" n'est donc pas tout fait appropri. Une mthode propose aussi un processus, qui rgit notamment l'enchanement des activits de production d'une entreprise. Or UML n'a pas t pens pour rgir les activits de l'entreprise ; ce n'est pas DOD-STD-2167A ou CMM. Les auteurs d'UML sont tout fait conscients de l'importance du processus, mais ce sujet a t intentionnellement exclu des travaux de l'OMG. Comment prendre
UML en franais
en compte toutes les organisations et cultures d'entreprises ? Un processus est adapt (donc trs li) au domaine d'activit de l'entreprise ; mme s'il constitue un cadre gnral, il faut l'adapter au contexte de l'entreprise. Bref, amliorer un processus est une discipline part entire, c'est un objectif qui dpasse trs largement le cadrede l'OMA. Cependant, mme si pour l'OMG, l'acceptabilit industrielle de la modlisation objet passe d'abord par la disponibilit d'un langage d'analyse objet performant et standard, les auteurs d'UML prconisent d'utiliser une dmarche :
q
guide par les besoins des utilisateurs du systme,
centre sur l'architecture logicielle,
itrative et incrmentale.
D'aprs les auteurs d'UML, un processus de dveloppement qui possde ces qualits fondamentales "devrait" favoriser la russite d'un projet. Une source frquente de malentendus sur UML a pour origine la facult d'UML de modliser un processus, pour le documenter et l'optimiser par exemple. En fin de compte, qu'est-ce qu'un processus ? Un ensemble d'activits coordonnes et rgules, en partie ordonnes, dont le but est de crer un produit (matriel ou intellectuel). UML permet tout fait de modliser les activits (c'est--dire la dynamique) d'un processus, de dcrire le rle des acteurs du processus, la structure des lments manipuls et produits, etc... Une extension d'UML ("UML extension for business modeling") propose d'ailleurs un certain nombre de strotypes standards (extensions du mtamodle) pour mieux dcrire les processus. Le RUP ("Rational Unified Process"), processus de dveloppement "cl en main", propos par Rational Software, est lui aussi modlis (document) avec UML. Il offre un cadre mthodologique gnrique qui repose sur UML et la suite d'outils Rational. Plus rcemment, VALtech propose le 2TUP ("2 Tracks Unified Process", cf. "UML en action", ed. Eyrolles), un processus unifi (cest--dire construit sur UML, itratif, centr sur larchitecture et conduit par les cas dutilisation), qui apporte une rponse aux contraintes de changement continuel imposes aux systmes dinformations des entreprises. Laxiome fondateur du 2TUP a t le constat que toute volution impose au systme dinformation peut se dcomposer et se traiter paralllement, suivant un axe fonctionnel et un axe technique. A lissue des volutions du modle fonctionnel et de larchitecture technique, la ralisation du systme consiste fusionner les rsultats de ces deux branches du processus. Bien quun processus universel soit une utopie, la capitalisation des meilleures
UML en franais
pratiques, travers une famille de processus unifis (tels que le RUP et le 2TUP), devient donc une ralit.
Conclusion.
Comme UML n'impose pas de mthode de travail particulire, il peut tre intgr n'importe quel processus de dveloppement logiciel de manire transparente. UML est une sorte de bote outils, qui permet d'amliorer progressivement vos mthodes de travail, tout en prservant vos modes de fonctionnement. Intgrer UML par tapes dans un processus, de manire pragmatique, est tout fait possible. La facult d'UML de se fondre dans le processus courant, tout en vhiculant une dmarche mthodologique, facilite son intgration et limite de nombreux risques (rejet des utilisateurs, cots...). Intgrer UML dans un processus ne signifie donc pas rvolutionner ses mthodes de travail, mais cela devrait tre loccasion de se remettre en question, en sinspirant des meilleures pratiques, capitalises travers les processus unifis (RUP et 2TUP).
uml@free.fr
vers les cours UML
UML en franais
UML, le langage de modlisation objet unifi

uml@free.fr - tous droits rservs
visiteurs sont dj passs par ici...
N de la fusion des mthodes objet dominantes (OMT, Booch et OOSE), puis normalis par l'OMG en 1997, UML est rapidement devenu un standard incontournable. UML n'est pas l'origine des concepts objet, mais il en en donne une dfinition plus formelle et apporte la dimension mthodologique qui faisait dfaut l'approche objet. Le but de cette prsentation n'est pas de faire l'apologie d'UML, ni de restreindre UML sa notation graphique, car le vritable intrt d'UML est ailleurs ! En effet, matriser la notation graphique d'UML n'est pas une fin en soi. Ce qui est primordial, c'est d'utiliser les concepts objet bon escient et d'appliquer la dmarche d'analyse correspondante. Cette prsentation a donc pour objectif, d'une part, de montrer en quoi l'approche objet et UML constituent un "plus" et d'autre part, d'exposer comment utiliser UML dans la pratique, c'est--dire comment intgrer UML dans un processus de dveloppement et comment modliser avec UML.
Avertissement : Les textes qui composent la prsentation sont (volontairement) trs synthtiques, la manire de transparents qu'on projette au cours d'une formation. Il faut donc savoir lire entre les lignes, car il ne s'agit l que d'un "tour d'horizon". Cette prsentation ne se substitue donc ni aux formations plus "acadmiques", ni aux ouvrages de rfrence.
http://uml.free.fr/cours/uml_free_fr_cours.html (1 sur 3) [09/04/2004 12:11:18]
UML en franais
PLAN DE LA PRESENTATION
cliquez sur le chapitre de votre choix pour accder la prsentation
PRESENTATION D'UML
q
Un peu d'Histoire... Les mthodes objet et la gense d'UML Avantages et inconvnients d'UML
MODELISER AVEC UML

q
Qu'est-ce-qu'un modle ? Comment modliser avec UML ? Modliser les vues statiques d'un systme
r r r r r r r r
la conceptualisation et les cas d'utilisation structurer ses modles (paquetages, collaboration) les objets, le diagramme d'objets et les classes le diagramme de classes OCL les strotypes le diagramme de composants le diagramme de dploiement
Modliser les vues dynamiques d'un systme
r r
le diagramme de collaboration synchronisation des messages
UML en franais
r r r r
les objets actifs le diagramme de squence le diagramme d'tats-transitions le diagramme d'activits
Synthse et conclusion
vers la norme UML
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
Cliquez ici pour accder la page UML en franais !
Un peu d'Histoire...
Approche fonctionnelle vs. approche objet
q La dcoupe fonctionnelle d'un problme informatique : une approche intuitive

Exemple de dcoupe fonctionnelle d'un logiciel ddi la gestion d'une bibliothque :
http://uml.free.fr/cours/i-p1.html (1 sur 3) [09/04/2004 12:12:14]
UML en franais
Le logiciel est compos d'une hirarchie de fonctions, qui ensemble, fournissent les services dsirs, ainsi que de donnes qui reprsentent les lments manipuls (livres, etc). Logique, cohrent et intuitif.
q Le "plus" de l'approche fonctionnelle : la factorisation des comportements

Une dcoupe fonctionnelle "intelligente" consiste factoriser certains comportements communs du logiciel. En d'autres termes : pour raliser une fonction du logiciel, on peut utiliser un ensemble d'autres fonctions, dj disponibles, pour peu qu'on rende ces dernires un tant soit peu gnriques. Gnial !
q Le revers de la mdaille : maintenance complexe en cas d'volution
UML en franais
Factoriser les comportements n'a malheureusement pas que des avantages. Les fonctions sont devenues interdpendantes : une simple mise jour du logiciel un point donn, peut impacter en cascade une multitude d'autres fonctions. On peut minorer cet impact, pour peu qu'on utilise des fonctions plus gnriques et des structures de donnes ouvertes. Mais respecter ces contraintes rend l'criture du logiciel et sa maintenance plus complexe. En cas d'volution majeure du logiciel (passage de la gestion d'une bibliothque celle d'une mdiathque par exemple), le scnario est encore pire. Mme si la structure gnrale du logiciel reste valide, la multiplication des points de maintenance, engendre par le chanage des fonctions, rend l'adaptation trs laborieuse. Le logiciel doit tre retouch dans sa globalit :
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
Approche fonctionnelle vs. approche objet (suite...)
q La sparation des donnes et des traitements : le pige !

Examinons le problme de l'volution de code fonctionnel plus en dtail... Faire voluer une application de gestion de bibliothque pour grer une mdiathque, afin de prendre en compte de nouveaux types d'ouvrages (cassettes vido, CD-ROM, etc...), ncessite :
q
de faire voluer les structures de donnes qui sont manipules par les fonctions, d'adapter les traitements, qui ne manipulaient l'origine qu'un seul type de document (des livres).
Il faudra donc modifier toutes les portions de code qui utilisent la base documentaire, pour grer les donnes et les actions propres aux diffrents types de documents. Il faudra par exemple modifier la fonction qui ralise l'dition des "lettres de rappel" (une lettre de rappel est une mise en demeure, qu'on envoie automatiquement aux personnes qui tardent rendre un ouvrage emprunt). Si l'on dsire que le dlai avant rappel varie selon le type de document emprunt, il faut prvoir une rgle de calcul pour chaque type de document. En fait, c'est la quasi-totalit de l'application qui devra tre adapte, pour grer les nouvelles donnes et raliser les traitements correspondants. Et cela, chaque fois qu'on dcidera de grer un nouveau type de document !
UML en franais
struct Document { char nom_doc[50]; Type_doc type; Bool est_emprunte; char emprunteur[50]; struct tm date_emprunt; } DOC[MAX_DOCS]; void lettres_de_rappel() void mettre_a_jour(int { ref) /* ... */ { for (i = 0; i < NB_DOCS; /* ... */ i++) switch(DOC[ref].type) { { if case LIVRE: (DOC[i].est_emprunte) { maj_livre(DOC[ref]); switch(DOC[i].type) break; { case CASSETTE_VIDEO: case LIVRE: maj_k7(DOC[ref]); delai_avant_rappel break; = 20; case CD_ROM: break; maj_cd(DOC[ref]); case CASSETTE_VIDEO: break; delai_avant_rappel } = 7; /* ... */ break; } case CD_ROM: delai_avant_rappel = 5; break; } } } /* ... */ }
q 1re amlioration : rassembler les valeurs qui caractrisent un type, dans le type
UML en franais
Une solution relativement lgante la multiplication des branches conditionnelles et des redondances dans le code (consquence logique d'une trop grande ouverture des donnes), consiste tout simplement centraliser dans les structures de donnes, les valeurs qui leurs sont propres :
struct Document { char nom_doc[50]; Type_doc type; Bool est_emprunte; char emprunteur[50]; struct tm date_emprunt; int delai_avant_rappel; } DOC[MAX_DOCS]; void lettres_de_rappel() { /* ... */ for (i = 0; i < NB_DOCS; i++) { if (DOC[i].est_emprunte) /* SI LE DOC EST EMPRUNTE */ { /* IMPRIME UNE LETTRE SI SON DELAI DE RAPPEL EST DEPASSE */ if (date() >= (DOC[i].date_emprunt + DOC[i].delai_avant_rappel)) imprimer_rappel(DOC[i]); } } }
Quoi de plus logique ? En effet, le "dlai avant dition d'une lettre de rappel" est bien une caractristique propre tous les ouvrages grs par notre application. Mais cette solution n'est pas encore optimale !
q 2me amlioration : centraliser les traitements associs un type, auprs du type
UML en franais
Pourquoi ne pas aussi rassembler dans une mme unit physique les types de donnes et tous les traitements associs ? Que se passerait-il par exemple si l'on centralisait dans un mme fichier, la structure de donnes qui dcrit les documents et la fonction de calcul du dlai avant rappel ? Cela nous permettrait de retrouver en un clin d'oeil le bout de code qui est charg de calculer le dlai avant rappel d'un document, puisqu'il se trouve au plus prs de la structure de donnes concerne. Ainsi, si notre mdiathque devait grer un nouveau type d'ouvrage, il suffirait de modifier une seule fonction (qu'on sait retrouver instannment), pour assurer la prise en compte de ce nouveau type de document dans le calcul du dlai avant rappel. Plus besoin de fouiller partout dans le code...
struct Document { char nom_doc[50]; Type_doc type; Bool est_emprunte; char emprunteur[50]; struct tm date_emprunt; int delai_avant_rappel; } DOC[MAX_DOCS];
int calculer_delai_rappel(Type_doc type) { switch(type) { case LIVRE: return 20; case CASSETTE_VIDEO: return 7; case CD_ROM: return 5; /* autres "case" bienvenus ici ! */ } }
Ecrit en ces termes, notre logiciel sera plus facile maintenir et bien plus lisible. Le stockage et le calcul du dlai avant rappel des documents, est dsormais assur par une seule et unique unit physique (quelques lignes de code, rapidement identifiables). Pour accder la caractristique "dlai avant rappel" d'un document, il suffit de rcuprer la valeur correspondante parmi les champs qui dcrivent le document. Pour assurer la prise en compte d'un nouveau type de document dans le calcul du dlai avant rappel, il suffit de modifier une seule fonction, situe au mme endroit que la structure de donnes qui dcrit les documents :
UML en franais
void ajouter_document(int ref) { DOC[ref].est_emprunte = FAUX; DOC[ref].nom_doc = saisir_nom(); DOC[ref].type = saisir_type(); DOC[ref].delai_avant_rappel = calculer_delai_rappel(DOC[ref].type); } void afficher_document(int ref) { printf("Nom du document: %s\n",DOC[ref].nom_doc); /* ... */ printf("Delai avant rappel: %d jours\n",DOC[ref].delai_avant_rappel); /* ... */ }
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
q Rcapitulons...
En rsum : centraliser les donnes d'un type et les traitements associs, dans une mme unit physique, permet de limiter les points de maintenance dans le code et facilite l'accs l'information en cas d'volution du logiciel :
q Objet ?
UML en franais
Les modifications que nous avons apport notre logiciel de gestion de mdiathque, nous ont amen transformer ce qui tait l'origine une structure de donnes, manipule par des fonctions, en une entit autonome, qui regroupe un ensemble de proprits cohrentes et de traitements associs. Une telle entit s'appelle... un objet et constitue le concept fondateur de l'approche du mme nom !
q q q q q
Un objet est une entit aux frontires prcises qui possde une identit (un nom). Un ensemble d'attributs caractrise l'tat de l'objet. Un ensemble d'oprations (mthodes) en dfinissent le comportement. Un objet est une instance de classe (une occurrence d'un type abstrait). Une classe est un type de donnes abstrait, caractris par des proprits (attributs et mthodes) communes des objets et permettant de crer des objets possdant ces proprits.
Exemple :
Quels sont les autres concepts importants de l'approche objet ?
q Encapsulation
UML en franais
q q
Consiste masquer les dtails d'implmentation d'un objet, en dfinissant une interface. L'interface est la vue externe d'un objet, elle dfinit les services accessibles (offerts) aux utilisateurs de l'objet. L'encapsulation facilite l'volution d'une application car elle stabilise l'utilisation des objets : on peut modifier l'implmentation des attributs d'un objet sans modifier son interface. L'encapsulation garantit l'intgrit des donnes, car elle permet d'interdire l'accs direct aux attributs des objets (utilisation d'accesseurs).
q Hritage (et polymorphisme)
q q
L'hritage est un mcanisme de transmission des proprits d'une classe (ses attributs et mthodes) vers une sous-classe. Une classe peut tre spcialise en d'autres classes, afin d'y ajouter des caractristiques spcifiques ou d'en adapter certaines. Plusieurs classes peuvent tre gnralises en une classe qui les factorise, afin de regrouper les caractristiques communes d'un ensemble de classes. La spcialisation et la gnralisation permettent de construire des hirarchies de classes. L'hritage peut tre simple ou multiple. L'hritage vite la duplication et encourage la rutilisation. Le polymorphisme reprsente la facult d'une mthode pouvoir s'appliquer des objets de classes diffrentes. Le polymorphisme augmente la gnricit du code.
Exemple d'une hirarchie de classes :
UML en franais
Polymorphisme, exemple :
Vehicule convoi[3] = { Train("TGV"), Voiture("twingo"), Bateau("Titanic") }; for (int i = 0; i < 3; i++) { convoi[i].seDeplacer(); }
q Agrgation
Il s'agit d'une relation entre deux classes, spcifiant que les objets d'une classe sont des composants de l'autre classe. Une relation d'agrgation permet donc de dfinir des objets composs d'autres objets. L'agrgation permet d'assembler des objets de base, afin de construire des objets plus complexes.
Agrgation, exemple :
page prcdente
sommaire
page suivante

UML en franais
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
q Rsum sur les concepts fondateurs de l'approche objet

q q q q
la notion d'objet et de classe (d'objets) l'encapsulation (les interfaces des objets) l'hritage (les hirarchies d'objets) l'agrgation (la construction d'objets l'aide d'objets)
Remarque : Les langages orients objet fournissent de nombreux autres mcanismes qui affinent ces concepts de base, favorisent la gnricit du code ou amliorent sa robustesse.
q L'approche objet, hier et aujourd'hui
UML en franais
q
Les concepts objet sont stables et prouvs (issus du terrain)

r
Simula, 1er langage de programmation implmenter le concept de type abstrait ( l'aide de classes), date de 1967 ! En 1976 dj, Smalltalk implmente les concepts fondateurs de l'approche objet (encapsulation, agrgation, hritage) l'aide de : s classes s associations entre classes s hirarchies de classes s messages entre objets er compilateur C++ date de 1980, et C++ est normalis par Le 1 l'ANSI. De nombreux langages orients objets acadmiques ont tays les concepts objets : Eiffel, Objective C, Loops...
Les concepts objet sont anciens, mais ils n'ont jamais t autant d'actualit
r
L'approche fonctionnelle n'est pas adapte au dveloppement d'applications qui voluent sans cesse et dont la complexit croit continuellement. L'approche objet a t invente pour faciliter l'volution d'applications complexes.
De nos jours, les outils orients objet sont fiables et performants

r r
Les compilateurs C++ produisent un code robuste et optimis. De trs nombreux outils facilitent le dveloppement d'applications C++ : s gnrateurs d'IHM (Ilog Views, TeleUse...) s bibliothques (STL, USL, Rogue Wave, MFC...) s environnements de dveloppement intgrs (Developper Studio, Sniff+...) s outils de qualimtrie et de tests (Cantata++, Insure++, Logiscope...) s bases de donnes orientes objet (O2, ObjectStore, Versant...)
q L'approche objet : une solution parfaite ?
UML en franais
q
En rsum, l'approche objet c'est :

r r r
Un ensemble de concepts stables, prouvs et normaliss. Une solution destine faciliter l'volution d'applications complexes. Une panoplie d'outils et de langages performants pour le dveloppement.
Oui, MAIS... Malgr les apparences, il est plus naturel pour nos esprits cartsiens, de dcomposer un problme informatique sous forme d'une hirarchie de fonctions atomiques et de donnes, qu'en terme d'objets et d'interaction entre ces objets. De plus, le vocabulaire prcis est un facteur d'chec important dans la mise en oeuvre d'une approche objet.
r
L'approche objet est moins intuitive que l'approche fonctionnelle ! s Quels moyens utiliser pour faciliter l'analyse objet ? s Quels critres identifient une conception objet pertinente ? s Comment comparer deux solutions de dcoupe objet d'un systme ? L'application des concepts objets ncessite une grande rigueur ! s Le vocabulaire est prcis (risques d'ambiguts, d'incomprhensions). s Comment dcrire la structure objet d'un systme de manire pertinente ?
q Quels sont les remdes aux inconvnients de l'approche objet ?

q
Un langage pour exprimer les concepts objet qu'on utilise, afin de pouvoir :
r r r
Reprsenter des concepts abstraits (graphiquement par exemple). Limiter les ambiguts (parler un langage commun). Faciliter l'analyse (simplifier la comparaison et l'valuation de solutions).
Une dmarche d'analyse et de conception objet, pour :

r
Ne pas effectuer une analyse fonctionnelle et se contenter d'une implmentation objet, mais penser objet ds le dpart. Dfinir les vues qui permettent de couvrir tous les aspects d'un systme, avec des concepts objets.
Bref : il nous faut un outil qui apporte une dimension mthodologique

UML en franais
l'approche objet, afin de mieux matriser sa richesse et sa complexit.
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL COURS UML LA NORME BIBLIOGRAPHIE LIENS WEB FORUMS
Les mthodes objet et la gense d'UML
q Mthodes ?
q
Les premires mthodes d'analyse (annes 70)

r
Dcoupe cartsienne (fonctionnelle et hirarchique) d'un systme.
L'approche systmique (annes 80)

r
Modlisation des donnes + modlisation des traitements (Merise, Axial, IE...).
L'mergence des mthodes objet (1990-1995)

r
Prise de conscience de l'importance d'une mthode spcifiquement objet : comment structurer un systme sans centrer l'analyse uniquement sur les donnes ou uniquement sur les traitements (mais sur les deux) ? Plus de 50 mthodes objet sont apparues durant cette priode (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) ! Aucun mthode ne s'est rellement impose.
Les premiers consensus (1995)

r
OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un systme s Issue du centre de R&D de General Electric. s Notation graphique riche et lisible. OOD (Grady Booch) : vues logiques et physiques du systme s Dfinie pour le DOD, afin de rationaliser de dveloppement d'applications ADA, puis C++. s Ne couvre pas la phase d'analyse dans ses 1res versions (prconise SADT). s Introduit le concept de package (lment d'organisation des modles). OOSE (Ivar Jacobson) : couvre tout le cycle de dveloppement s Issue d'un centre de dveloppement d'Ericsson, en Sude. s La mthodologie repose sur l'analyse des besoins des utilisateurs.
L'unification et la normalisation des mthodes (1995-1997)

r
UML (Unified Modeling Langage), la fusion et synthse des mthodes dominantes :
UML en franais
UML aujourd'hui : un standard incontournable

r r r r r r
UML est le rsultat d'un large consensus (industriels, mthodologistes...). UML est le fruit d'un travail d'experts reconnus. UML est issu du terrain. UML est riche (il couvre toutes les phases d'un cycle de dveloppement). UML est ouvert (il est indpendant du domaine d'application et des langages d'implmentation). Aprs l'unification et la standardisation, bientt l'industrialisation d'UML : les outils qui supportent UML se multiplient (GDPro, ObjectTeam, Objecteering, OpenTool, Rational Rose, Rhapsody, STP, Visio, Visual Modeler, WithClass...). XMI (format d'change standard de modles UML).
UML volue mais reste stable !

r r r r r
L'OMG RTF (nombreux acteurs industriels) centralise et normalise les volutions d'UML au niveau international. Les groupes d'utilisateurs UML favorisent le partage des expriences. De version en version, UML gagne en maturit et prcision, tout en restant stable. UML inclut des mcanismes standards d'auto-extension. La description du mtamodle d'UML est standardise (OMG-MOF).
>>> UML n'est pas une mode, c'est un investissement fiable !
q A quoi sert UML ?

q
UML n'est pas une mthode ou un processus !

r r r r r
Si l'on parle de mthode objet pour UML, c'est par abus de langage ! Ce constat vaut aussi pour OMT ou d'autres techniques / langages de modlisation. Une mthode propose aussi un processus, qui rgit notamment l'enchanement des activits de production d'une entreprise. UML a t pens pour permettre de modliser les activits de l'entreprise, pas pour les rgir (ce n'est pas CMM ou SPICE). Un processus de dveloppement logiciel universel est une utopie : s Impossible de prendre en compte toutes les organisations et cultures d'entreprises. s Un processus est adapt (donc trs li) au domaine d'activit de l'entreprise. s Mme si un processus constitue un cadre gnral, il faut l'adapter de manire prcise au contexte de l'entreprise.
UML est un langage pseudo-formel

r
r r
UML est fond sur un mtamodle, qui dfinit : s les lments de modlisation (les concepts manipuls par le langage), s la smantique de ces lments (leur dfinition et le sens de leur utilisation). Un mtamodle est une description trs formelle de tous les concepts d'un langage. Il limite les ambiguts et encourage la construction d'outils. Le mtamodle d'UML permet de classer les concepts du langage (selon leur niveau d'abstraction ou domaine d'application) et expose sa structure. Le mtamodle UML est lui-mme dcrit par un mta-mtamodle (OMG-MOF). UML propose aussi une notation, qui permet de reprsenter graphiquement les lments de modlisation du mtamodle.
UML en franais
r
Cette notation graphique est le support du langage UML.
UML cadre l'analyse objet, en offrant :

r r
diffrentes vues (perspectives) complmentaires d'un systme, qui guident l'utilisation des concept objets, plusieurs niveaux d'abstraction, qui permettent de mieux contrler la complexit dans l'expression des solutions objets.
UML est un support de communication

r r r r
Sa notation graphique permet d'exprimer visuellement une solution objet. L'aspect formel de sa notation limite les ambiguts et les incomprhensions. Son aspect visuel facilite la comparaison et l'valuation de solutions. Son indpendance (par rapport aux langages d'implmentation, domaine d'application, processus...) en font un langage universel.
q Les points forts d'UML

q
UML est un langage formel et normalis

r r r
gain de prcision gage de stabilit encourage l'utilisation d'outils
UML est un support de communication performant

r r r
Il cadre l'analyse. Il facilite la comprhension de reprsentations abstraites complexes. Son caractre polyvalent et sa souplesse en font un langage universel.
q Les points faibles d'UML

q
La mise en pratique d'UML ncessite un apprentissage et passe par une priode d'adaptation. Mme si l'Espranto est une utopie, la ncessit de s'accorder sur des modes d'expression communs est vitale en informatique. UML n 'est pas l'origine des concepts objets, mais en constitue une tape majeure, car il unifie les diffrentes approches et en donne une dfinition plus formelle.
Le processus (non couvert par UML) est une autre cl de la russite d'un projet. Or, l'intgration d'UML dans un processus n'est pas triviale et amliorer un processus est un tche complexe et longue. Les auteurs d'UML sont tout fait conscients de l'importance du processus, mais l'acceptabilit industrielle de la modlisation objet passe d'abord par la disponibilit d'un langage d'analyse objet performant et standard.
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
Modliser avec UML
q Qu'est-ce qu'un modle ?
UML en franais
q
Un modle est une abstraction de la ralit L'abstraction est un des piliers de l'approche objet.
r
Il s'agit d'un processus qui consiste identifier les caractristiques intressantes d'une entit, en vue d'une utilisation prcise. L'abstraction dsigne aussi le rsultat de ce processus, c'est--dire l'ensemble des caractristiques essentielles d'une entit, retenues par un observateur.
Un modle est une vue subjective mais pertinente de la ralit

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

r
Modle mtorologique : partir de donnes d'observation (satellite ...), permet de prvoir les conditions climatiques pour les jours venir. Modle conomique : peut par exemple permettre de simuler l'volution de cours boursiers en fonction d'hypothses macro-conomiques (volution du chmage, taux de croissance...). Modle dmographique : dfinit la composition d'un panel d'une population et son comportement, dans le but de fiabiliser des tudes statistiques, d'augmenter l'impact de dmarches commerciales, etc...
Caractristiques fondamentales des modles Le caractre abstrait d'un modle doit notamment permettre :
r
de faciliter la comprhension du systme tudi > Un modle rduit la complexit du systme tudi. de simuler le systme tudi > Un modle reprsente le systme tudi et reproduit ses comportements.
Un modle rduit (dcompose) la ralit, dans le but de disposer d'lments de travail exploitables par des moyens mathmatiques ou informatiques : modle / ralit ~ digital / analogique
q Comment modliser avec UML ?

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

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

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

q
Une architecture adapte est la cl de vote du succs d'un dveloppement. Elle dcrit des choix stratgiques qui dterminent en grande partie les qualits du logiciel (adaptabilit, performances, fiabilit...).
Ph. Kruchten propose diffrentes perspectives, indpendantes et complmentaires, qui permettent de dfinir un modle d'architecture (publication IEEE, 1995). Cette vue ("4+1") a fortement inspir UML :
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
Modliser avec UML (suite...)
q Dfinir une architecture avec UML (dtail de la "vue 4+1")

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

UML opte pour l'laboration des modles, plutt que pour une approche qui impose une barrire stricte entre analyse et conception :
q
Les modles d'analyse et de conception ne diffrent que par leur niveau de dtail, il n'y a pas de diffrence dans les concepts utiliss. UML n'introduit pas d'lments de modlisation propres une activit (analyse, conception...) ; le langage reste le mme tous les niveaux d'abstraction.
Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction.

q
L'laboration encourage une approche non linaire (les "retours en arrire" entre niveaux d'abstraction diffrents sont facilits). La traabilit entre modles de niveaux diffrents est assure par l'unicit du langage.
UML en franais
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
Modliser avec UML (suite...)
q Dtail des diffrents niveaux d'abstraction

(phases du macro-processus)
q
Conceptualisation
r
L'entre de l'analyse ce niveau, est le dossier d'expression des besoins client. A ce niveau d'abstraction, on doit capturer les besoins principaux des utilisateurs. Il ne faut pas chercher l'exhaustivit, mais clarifier, filtrer et organiser les besoins ! Le but de la conceptualisation est : s de dfinir le contour du systme modliser (de spcifier le "quoi"), s de capturer les fonctionnalits principales du systme, afin d'en fournir une meilleure comprhension (le modle produit sert d'interface entre les acteurs du projet), s de fournir une base la planification du projet.
Analyse du domaine
r
L'entre de l'analyse ce niveau, est le modle des besoins clients (les "cas d'utilisation" UML). Il s'agit de modliser les lments et mcanismes principaux du
UML en franais
systme. On identifie les lments du domaine, ainsi que les relations et interactions entre ces lments : s les lments du domaine sont lis au(x) mtier(s) de l'entreprise, s ils sont indispensables la mission du systme, s ils gagnent tre rutiliss (ils reprsentent un savoir-faire). A ce stade, on organise aussi (selon des critres purement logiques), les lments du domaine en "catgories" : s pour rpartir les tches dans les quipes, s regrouper ce qui peut tre gnrique, etc...
Analyse applicative
r
r r
A ce niveau, on modlise les aspects informatiques du systme, sans pour autant rentrer dans les dtails d'implmentation. Les interfaces des lments de modlisation sont dfinis (cf. encapsulation). Les relations entre les lments des modles sont dfinies. Les lments de modlisation utiliss peuvent tre propres une version du systme.
Conception
r
On y modlise tous les rouages d'implmentation et on dtaille tous les lments de modlisation issus des niveaux suprieurs. Les modles sont optimiss, car destins tre implments.
q Activits des micro-processus d'analyse

(niveau d'abstraction constant)
q
A chaque niveau d'abstraction, un micro-processus rgit la construction des modles. UML ne rgit pas les activits des micro-processus, c'est le principe d'abstraction qui permet l'laboration itrative et incrmentale des modles. Exemple de micro-processus de construction d'un modle :
r
identifiez les classes (d'objets) : s recherchez les classes candidates (diffrentes suivant le niveau d'abstraction) l'aide de diagrammes d'objets (bauches), s filtrez les classes redondantes, trop spcifiques ou vagues, qui ne reprsentent qu'une opration ou un attribut, s documentez les caractristiques des classes retenues
UML en franais
(persistances, nombre maximum d'instances, etc.).

r
identifiez les associations entre classes / interactions entre objets (instances) : s recherchez les connexions smantiques et les relations d'utilisation, s documentez les relations (nom, cardinalits, contraintes, rles des classes...), s en spcification, filtrez les relations instables ou d'implmentation, s dfinissez la dynamique des relations entre objets (les interactions entre instances de classes et les activits associes). identifiez les attributs et les oprations des classes : s recherchez les attributs dans les modles dynamiques (recherchez les donnes qui caractrisent les tats des objets), s filtrez les attributs complexes (faites-en des objets) et au niveau spcification, ne reprsentez pas les valeurs internes propres aux mcanismes d'implmentation, s recherchez les oprations parmi les activits et actions des objets (ne pas rentrer dans le dtail au niveau spcification). optimisez les modles : s choisissez vos critres d'optimisation (gnricit, volutivit, prcision, lisibilit, simplicit...), s utilisez la gnralisation et la spcialisation (classification), s documentez et dtaillez vos modles, encapsulez. validez les modles : s vrifiez la cohrence, la compltude et l'homognit des modles, s confrontez les modles la critique (comit de relecture...).
q Synthse de la dmarche
UML en franais
Modliser une application n'est pas une activit linaire. Il s'agit d'une tche trs complexe, qui ncessite une approche :
q
itrative et incrmentale (grce aux niveaux d'abstraction), car il est plus efficace de construire et valider par tapes, ce qui est difficile cerner et matriser, centre sur l'architecture (dfinie par la vue "4+1"), car il s'agit de la cl de vote qui conditionne la plupart des qualits d'une application informatique, guide par la prise en compte des besoins des utilisateurs ( l'aide des cas d'utilisation), car ce qui motive l'existence mme du systme concevoir, c'est la satisfaction des besoins de ses utilisateurs.
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
Les diagrammes UML
OK pour la dmarche d'laboration d'un modle, mais...
q Comment "rdiger" un modle avec UML ?

q
UML permet de dfinir et de visualiser un modle, l'aide de diagrammes. Un diagramme UML est une reprsentation graphique, qui s'intresse un aspect prcis du modle ; c'est une perspective du modle, pas "le modle". Chaque type de diagramme UML possde une structure (les types des lments de modlisation qui le composent sont prdfinis). Un type de diagramme UML vhicule une smantique prcise (un type de diagramme offre toujours la mme vue d'un systme). Combins, les diffrents types de diagrammes UML offrent une vue complte des aspects statiques et dynamiques d'un systme. Par extension et abus de langage, un diagramme UML est aussi un modle (un diagramme modlise un aspect du modle global).
UML en franais
q Quelques caractristiques des diagrammes UML

q
Les diagrammes UML supportent l'abstraction. Leur niveau de dtail caractrise le niveau d'abstraction du modle. La structure des diagrammes UML et la notation graphique des lments de modlisation est normalise (document "UML notation guide"). Rappel : la smantique des lments de modlisation et de leur utilisation est dfinie par le mtamodle UML (document "UML semantics").
Le recours des outils appropris est un gage de productivit pour la rdaction des diagrammes UML, car : r ils facilitent la navigation entre les diffrentes vues, r ils permettent de centraliser, organiser, partager, synchroniser et versionner les diagrammes (indispensable avec un processus itratif), r facilitent l'abstraction, par des filtres visuels, r simplifient la production de documents et autorisent (dans certaines limites) la gnration de code.
q Les diffrents types de diagrammes UML

q
Vues statiques du systme :

r r r r r
diagrammes de cas d'utilisation diagrammes d'objets diagrammes de classes diagrammes de composants diagrammes de dploiement
Vues dynamiques du systme :

r r r r
diagrammes de collaboration diagrammes de squence diagrammes d'tats-transitions diagrammes d'activits
UML en franais
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
Les vues statiques d'UML
LES CAS D'UTILISATION
q La conceptualisation : rappel
q
Le but de la conceptualisation est de comprendre et structurer les besoins du client. Il ne faut pas chercher l'exhaustivit, mais clarifier, filtrer et organiser les besoins ! Une fois identifis et structurs, ces besoins : r dfinissent le contour du systme modliser (ils prcisent le but atteindre), r permettent d'identifier les fonctionnalits principales (critiques) du systme. Le modle conceptuel doit permettre une meilleure comprhension du systme. Le modle conceptuel doit servir d'interface entre tous les acteurs du projet. Les besoins des clients sont des lments de traabilit dans un processus intgrant UML.
Le modle conceptuel joue un rle central, il est capital de bien le dfinir !
q Cas d'utilisation (use cases)
UML en franais
q
Il s'agit de la solution UML pour reprsenter le modle conceptuel. Les use cases permettent de structurer les besoins des utilisateurs et les objectifs correspondants d'un systme. Ils centrent l'expression des exigences du systme sur ses utilisateurs : ils partent du principe que les objectifs du systme sont tous motivs. Ils se limitent aux proccupations "relles" des utilisateurs ; ils ne prsentent pas de solutions d'implmentation et ne forment pas un inventaire fonctionnel du systme. Ils identifient les utilisateurs du systme (acteurs) et leur interaction avec le systme. Ils permettent de classer les acteurs et structurer les objectifs du systme. Ils servent de base la traabilit des exigences d'un systme dans un processus de dveloppement intgrant UML.
Il tait une fois... Le modle conceptuel est le type de diagramme UML qui possde la notation la plus simple ; mais paradoxalement c'est aussi celui qui est le plus mal compris ! Au dbut des annes 90, Ivar Jacobson (inventeur de OOSE, une des mthodes fondatrices d'UML) a t nomm chef d'un norme projet informatique chez Ericsson. Le hic, c'est que ce projet tait rapidement devenu ingrable, les ingnieurs d'Ericsson avaient accouch d'un monstre. Personne ne savait vraiment quelles taient les fonctionnalits du produit, ni comment elles taient assures, ni comment les faire voluer... Classique lorsque les commerciaux promettent monts et merveilles tous les clients qu'ils dmarchent, sans se soucier des contraintes techniques, que les clients ne savent pas exprimer leurs besoins et que les ingnieurs n'ont pas les ressources pour dvelopper le mouton cinq pattes qui rsulte de ce chaos. Pour viter de foncer droit dans un mur et mener bien ce projet critique pour Ericsson, Jacobson a eu une ide. Plutt que de continuer construire une tour de Babel, pourquoi ne pas remettre plat les objectifs rels du projet ? En d'autres termes : quels sont les besoins rels des clients, ceux qui conditionneront la russite du projet ? Ces besoins critiques, une fois identifis et structurs, permettront enfin de cerner "ce qui est important pour la russite du projet". Le bnfice de cette dmarche simplificatrice est double. D'une part, tous les acteurs du projet ont une meilleure comprhension du systme dvelopper, d'autre part, les besoins des utilisateurs, une fois clarifis, serviront de fil rouge, tout au long du cycle de dveloppement. A chaque itration de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs ; chaque itration de la phase de conception et de ralisation, on veille la prise en compte des besoins des utilisateurs et chaque itration de la phase de test, on vrifie que les besoins des utilisateurs sont satisfaits. Simple mais gnial. Pour la petite histoire, sachez que grce cette dmarche initie par Jacobson, Ericsson a russi mener bien son projet et a gagn une notorit internationale dans le march de la commutation. Morale de cette histoire : La dtermination et la comprhension des besoins sont souvent difficiles car les intervenants sont noys sous de trop grandes quantits d'informations. Or, comment mener bien un projet si l'on ne sait pas o l'on va ? Conclusion : il faut clarifier et organiser les besoins des clients (les modliser). Jacobson identifie les caractristiques suivantes pour les modles :
q q q
Un modle est une simplification de la ralit. Il permet de mieux comprendre le systme qu'on doit dvelopper. Les meilleurs modles sont proches de la ralit.
Les use cases, permettent de modliser les besoins des clients d'un systme et doivent aussi possder ces caractristiques. Ils ne doivent pas chercher l'exhaustivit, mais clarifier, filtrer et organiser les besoins ! Une fois identifis et structurs, ces besoins :
q q
dfinissent le contour du systme modliser (ils prcisent le but atteindre), permettent d'identifier les fonctionnalits principales (critiques) du systme.
Les use cases ne doivent donc en aucun cas dcrire des solutions d'implmentation. Leur but est justement d'viter de tomber dans la
UML en franais
drive d'une approche fonctionnelle, o l'on liste une litanie de fonctions que le systme doit raliser. Bien entendu, rien n'interdit de grer l'aide d'outils (Doors, Requisite Pro, etc...) les exigences systmes un niveau plus fin et d'en assurer la traabilit, bien au contraire. Mais un modle conceptuel qui identifie les besoins avec un plus grand niveau d'abstraction reste indispensable. Avec des systmes complexes, filtrer l'information, la simplifier et mieux l'organiser, c'est rendre l'information exploitable. Produisez de l'information phmre, complexe et confuse, vous obtiendrez un joyeux "dsordre" (pour rester poli). Dernire remarque : Utilisez les use cases tels qu'ils ont t pens par leurs crateurs ! UML est issu du terrain. Si vous utilisez les use cases sans avoir en tte la dmarche sous-jacente, vous n'en tirerez aucun bnfice.
q Elments de base des cas d'utilisation

q
Acteur : entit externe qui agit sur le systme (oprateur, autre systme...). r L'acteur peut consulter ou modifier l'tat du systme. r En rponse l'action d'un acteur, le systme fournit un service qui correspond son besoin. r Les acteurs peuvent tre classs (hirarchiss). Use case : ensemble d'actions ralises par le systme, en rponse une action d'un acteur. r Les uses cases peuvent tre structurs. r Les uses cases peuvent tre organiss en paquetages (packages). r L'ensemble des use cases dcrit les objectifs (le but) du systme.
q Exemples
Cas d'utilisation standard :
UML en franais
Relation d'utilisation :
Relation d'extension :
page prcdente
sommaire
page suivante
UML en franais
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
Les vues statiques d'UML (suite...)
LES PAQUETAGES
q Paquetages (packages)
q
Les paquetages sont des lments d'organisation des modles. Ils regroupent des lments de modlisation, selon des critres purement logiques. Ils permettent d'encapsuler des lments de modlisation (ils possdent une interface). Ils permettent de structurer un systme en catgories (vue logique) et sous-systmes (vue des composants). Ils servent de "briques" de base dans la construction d'une architecture. Ils reprsentent le bon niveau de granularit pour la rutilisation. Les paquetages sont aussi des espaces de noms.
q Paquetages : relations entre paquetages
UML en franais
q Paquetages : interfaces
q Paquetages : strotypes
UML en franais
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
LA COLLABORATION
q Symbole de modlisation "collaboration"

q
Les collaborations sont des interactions entre objets, dont le but est de raliser un objectif du systme (c'est--dire aussi de rpondre un besoin d'un utilisateur). L'lment de modlisation UML "collaboration", reprsente les classes qui participent la ralisation d'un cas d'utilisation. Attention : ne confondez pas l'lment de modlisation "collaboration" avec le diagramme de collaboration, qui reprsente des interactions entre instances de classes.
UML en franais
INSTANCES ET DIAGRAMME D'OBJETS
q Exemples d'instances
q Objets composites
UML en franais
q Diagramme d'objets
q
Ce type de diagramme UML montre des objets (instances de classes dans un tat particulier) et des liens (relations smantiques) entre ces objets. Les diagrammes d'objets s'utilisent pour montrer un contexte (avant ou aprs une interaction entre objets par exemple). Ce type de diagramme sert essentiellement en phase exploratoire, car il possde un trs haut niveau d'abstraction.
Exemple :
UML en franais
page prcdente
sommaire
page suivante
UML en franais
LES CLASSES
q Classe : smantique et notation

q
Une classe est un type abstrait caractris par des proprits (attributs et mthodes) communes un ensemble d'objets et permettant de crer des objets ayant ces proprits. Classe = attributs + mthodes + instanciation
Ne pas reprsenter les attributs ou les mthodes d'une classe sur un diagramme, n'indique pas que cette classe n'en contient pas. Il s'agit juste d'un filtre visuel, destin donner un certain niveau d'abstraction son modle. De mme, ne pas spcifier les niveaux de protection des membres d'une classe ne veut pas dire qu'on ne reprsente que les membres publics. L aussi, il s'agit d'un filtre visuel.
Documentation d'une classe (niveaux d'abstraction), exemples :
UML en franais
Attributs multivalus et drivs, exemples :
Classe abstraite, exemple :
Template (classe paramtrable), exemple :
UML en franais
page prcdente
sommaire
page suivante
UML en franais
DIAGRAMME DE CLASSES
q Diagramme de classes : smantique

q
Un diagramme de classes est une collection d'lments de modlisation statiques (classes, paquetages...), qui montre la structure d'un modle. Un diagramme de classes fait abstraction des aspects dynamiques et temporels. Pour un modle complexe, plusieurs diagrammes de classes complmentaires doivent tre construits. On peut par exemple se focaliser sur : r les classes qui participent un cas d'utilisation (cf. collaboration), r les classes associes dans la ralisation d'un scnario prcis, r les classes qui composent un paquetage, r la structure hirarchique d'un ensemble de classes.
Pour reprsenter un contexte prcis, un diagramme de classes peut tre instanci en diagrammes d'objets.
q Associations entre classes

q
Une association exprime une connexion smantique bidirectionnelle entre deux classes. L'association est instanciable dans un diagramme d'objets ou de collaboration, sous forme de liens entre objets issus de classes associes.
UML en franais
q Documentation d'une association et types d'associations

q
Association en forme verbale active : prcise le sens de lecture principal d'une association. Voir aussi : association navigabilit restreinte.
Rles : spcifie la fonction d'une classe pour une association donne (indispensable pour les associations rflexives).
Cardinalits : prcise le nombre d'instances qui participent une relation.
UML en franais
Expression des cardinalits d'une relation en UML :
n : exactement "n" (n, entier naturel > 0)

exemples : "1", "7"
n..m : de "n" "m" (entiers naturels ou variables, m > n)

exemples : "0..1", "3..n", "1..31"
* : plusieurs (quivalent "0..n" et "0..*") n..* : "n" ou plus (n, entier naturel ou variable)
exemples : "0..*", "5..*"
Relation de dpendance : relation d'utilisation unidirectionnelle et d'obsolescence (une modification de l'lment dont on dpend, peut ncessiter une mise jour de l'lment dpendant).
Association navigabilit restreinte Par dfaut, une association est navigable dans les deux sens. La rduction de la porte de l'association est souvent ralise en phase d'implmentation, mais peut aussi tre exprime dans un modle pour indiquer que les instances d'une classe ne "connaissent" pas les instances d'une autre.
Association n-aire : il s'agit d'une association qui relie plus de deux classes... Note : de telles associations sont difficiles dchiffrer et peuvent induire en erreur. Il vaut mieux limiter leur utilisation, en dfinissant de nouvelles catgories d'associations.
Classe d'association : il s'agit d'une classe qui ralise la navigation entre les instances d'autres classes.
UML en franais
Qualification : permet de slectionner un sous-ensemble d'objets, parmi l'ensemble des objets qui participent une association. La restriction de l'association est dfinie par une cl, qui permet de slectionner les objets cibls.
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
DIAGRAMME DE CLASSES (suite...)
q Hritage
Les hirarchies de classes permettent de grer la complexit, en ordonnant les objets au sein d'arborescences de classes, d'abstraction croissante.
q
Spcialisation r Dmarche descendante, qui consiste capturer les particularits d'un ensemble d'objets, non discrimins par les classes dj identifies. r Consiste tendre les proprits d'une classe, sous forme de sous-classes, plus spcifiques (permet l'extension du modle par rutilisation). Gnralisation r Dmarche ascendante, qui consiste capturer les particularits communes d'un ensemble d'objets, issus de classes diffrentes. r Consiste factoriser les proprits d'un ensemble de classes, sous forme d'une super-classe, plus abstraite (permet de gagner en gnricit). Classification r L'hritage (spcialisation et gnralisation) permet la classification des objets. r Une bonne classification est stable et extensible : ne classifiez pas les objets selon des critres instables (selon ce qui caractrise leur tat) ou trop vagues (car cela gnre trop de sous-classes). r Les critres de classification sont subjectifs. r Le principe de substitution (Liksow, 1987) permet de dterminer si une relation d'hritage est bien employe pour la classification : "Il doit tre possible de substituer n'importe quel instance d'une super-classe, par n'importe quel instance d'une de ses sous-classes, sans que la smantique d'un programme crit dans les termes de la super-classe n'en soit affecte." r Si Y hrite de X, cela signifie que "Y est une sorte de X" (analogies entre classification et thorie des ensembles).
UML en franais
q Agrgation
q
L'agrgation est une association non symtrique, qui exprime un couplage fort et une relation de subordination. Elle reprsente une relation de type "ensemble / lment". UML ne dfinit pas ce qu'est une relation de type "ensemble / lment", mais il permet cependant d'exprimer cette vue subjective de manire explicite. Une agrgation peut notamment (mais pas ncessairement) exprimer : r qu'une classe (un "lment") fait partie d'une autre ("l'agrgat"), r qu'un changement d'tat d'une classe, entrane un changement d'tat d'une autre, r qu'une action sur une classe, entrane une action sur une autre. A un mme moment, une instance d'lment agrg peut tre lie plusieurs instances d'autres classes (l'lment agrg peut tre partag). Une instance d'lment agrg peut exister sans agrgat (et inversement) : les cycles de vies de l'agrgat et de ses lments agrgs peuvent tre indpendants.
q Composition
UML en franais
q
La composition est une agrgation forte (agrgation par valeur). Les cycles de vies des lments (les "composants") et de l'agrgat sont lis : si l'agrgat est dtruit (ou copi), ses composants le sont aussi. A un mme moment, une instance de composant ne peut tre lie qu' un seul agrgat. Les "objets composites" sont des instances de classes composes.
q Agrgation et composition : rappel

q
L'agrgation et la composition sont des vues subjectives. Lorsqu'on reprsente (avec UML) qu'une molcule est "compose" d'atomes, on sous-entend que la destruction d'une instance de la classe "Molcule", implique la destruction de ses composants, instances de la classe "Atome" (cf. proprits de la composition). Bien qu'elle ne reflte pas la ralit ("rien ne se perd, rien ne se cre, tout se transforme"), cette abstraction de la ralit nous satisfait si l'objet principal de notre modlisation est la molcule... En conclusion, servez vous de l'agrgation et de la composition pour ajouter de la smantique vos modles lorsque cela est pertinent, mme si dans la "ralit" de tels liens n'existent pas !
q Interfaces
q
Une interface fournit une vue totale ou partielle d'un ensemble de services offerts par une classe, un paquetage ou un composant. Les lments qui utilisent l'interface peuvent exploiter tout ou partie de l'interface. Dans un modle UML, le symbole "interface" sert identifier de manire explicite et symbolique les services offerts par un lment et l'utilisation qui en est faite par les autres lments.
UML en franais
page prcdente
sommaire
page suivante
UML en franais
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
DIAGRAMME DE CLASSES (suite...)
q Association drive
q
Les associations drives sont des associations redondantes, qu'on peut dduire d'une autre association ou d'un ensemble d'autres associations. Elles permettent d'indiquer des chemins de navigation "calculs", sur un diagramme de classes. Elles servent beaucoup la comprhension de la navigation (comment joindre telles instances d'une classe partir d'une autre).
UML en franais
q Contrainte sur une association

q
Les contraintes sont des expressions qui prcisent le rle ou la porte d'un lment de modlisation (elles permettent d'tendre ou prciser sa smantique). Sur une association, elles peuvent par exemple restreindre le nombre d'instances vises (ce sont alors des "expressions de navigation"). Les contraintes peuvent s'exprimer en langage naturel. Graphiquement, il s'agit d'un texte encadr d'accolades.
UML en franais
q OCL
q
UML formalise l'expression des contraintes avec OCL (Object Constraint Language). OCL est une contribution d'IBM UML 1.1. Ce langage formel est volontairement simple d'accs et possde une grammaire lmentaire (OCL peut tre interprt par des outils). Il reprsente un juste milieu, entre langage naturel et langage mathmatique. OCL permet ainsi de limiter les ambiguts, tout en restant accessible. OCL permet de dcrire des invariants dans un modle, sous forme de pseudo-code : r pr et post-conditions pour une opration, r expressions de navigation, r expressions boolennes, etc... OCL est largement utilis dans la dfinition du mtamodle UML.
Nous allons nous baser sur une tude de cas, pour introduire brivement OCL. Monsieur Formulain, directeur d'une chane d'htels, vous demande de concevoir une application de gestion pour ses htels. Voici ce que vous devez modliser : Un htel Formulain est constitu d'un certain nombre de chambres. Un responsable de l'htel gre la location des chambres. Chaque chambre se loue un prix donn (suivant ses prestations). L'accs aux salles de bain est compris dans le prix de la location d'une chambre. Certaines chambres comportent une salle de bain, mais pas toutes. Les htes de chambres sans salle de bain peuvent utiliser une salle de bain sur le palier. Ces dernires peuvent tre utilises par plusieurs htes. Les pices de l'htel qui ne sont ni des chambres, ni des salles de bain (hall d'accueil, cuisine...) ne font pas partie de l'tude (hors sujet). Des personnes peuvent louer une ou plusieurs chambres de l'htel, afin d'y rsider. En d'autre termes : l'htel hberge un certain nombre de personnes, ses htes (il s'agit des personnes qui louent au moins une chambre de l'htel...). Le diagramme UML ci-dessous prsente les classes qui interviennent dans la modlisation d'un htel Formulain, ainsi que les relations entre ces classes.
UML en franais
Attention : le modle a t rduit une vue purement statique. La dynamique de l'interaction entre instances n'est pas donne ici, pour simplifier l'exemple. Lors d'une modlisation complte, les vues dynamiques complmentaires ne devraient pas tre omises (tout comme la conceptualisation pralable par des use cases)... Remarque : cet exemple est inspir d'un article paru dans JOOP (Journal of Object Oriented Programming), en mai 99.
OCL permet d'enrichir ce diagramme, en dcrivant toutes les contraintes et tous les invariants du modle prsent, de manire normalise et explicite ( l'intrieur d'une note rattache un lment de modlisation du diagramme). Voici quelques exemples de contraintes qu'on pourrait dfinir sur ce diagramme, avec la syntaxe OCL correspondante. Attention ! Les exemples de syntaxe OCL ci-dessous ne sont pas dtaills, rfrez-vous au document de la norme UML adquat ("OCL spcification"). Il ne s'agit l que d'un trs rapide aperu du pouvoir d'abstraction d'OCL... Un htel Formulain ne contient jamais d'tage numro 13 (superstition oblige).
context Chambre inv: self._tage <> 13 context SalleDeBain inv: self._tage <> 13
Le nombre de personnes par chambre doit tre infrieur ou gal au nombre de lits dans la chambre loue. Les enfants (accompagns) de moins de 4 ans ne "comptent pas" dans cette rgle de calcul ( hauteur d'un enfant de moins de 4 ans maximum par chambre).
context Chambre inv: client->size <= _nbDeLits or (client->size = _nbDeLits + 1 and client->exists(p : Personne | p._ge < 4))
L'tage de chaque chambre est compris entre le premier et le dernier tage de l'htel.
context Htel inv: self.chambre->forAll(c : Chambre | c._tage <= self._tageMax and c._tage >= self._tageMin)
Chaque tage possde au moins une chambre (sauf l'tage 13, qui n'existe pas...).
context Htel inv: Sequence{_tageMin.._tageMax}->forAll(i : Integer | if i <> 13 then

UML en franais
self.chambre->select(c : Chambre | c._tage = i)->notEmpty) endif)

On ne peut repeindre une chambre que si elle n'est pas loue. Une fois repeinte, une chambre cote 10% de plus.
context Chambre::repeindre(c : Couleur) pre: client->isEmpty post: _prix = _prix@pre * 1.1

Une salle de bain privative ne peut tre utilise que par les personnes qui louent la chambre contenant la salle de bain et une salle de bain sur le palier ne peut tre utilise que par les clients qui logent sur le mme palier.
context SalleDeBain::utiliser(p : Personne) pre: if chambre->notEmpty then chambre.client->includes(p) else p.chambre._tage = self._tage endif post: _nbUtilisateurs = _nbUtilisateurs@pre + 1
Le loyer de l'htel est gal la somme du prix de toutes les chambres loues.
context Htel::calculerLoyer() : rel pre: post: result = self.chambre->select(client->notEmpty)._prix->sum
q Strotypes
q
Les strotypes permettent d'tendre la smantique des lments de modlisation : il s'agit d'un mcanisme d'extensibilit du mtamodle d'UML. Les strotypes permettent de dfinir de nouvelles classes d'lments de modlisation, en plus du noyau prdfini par UML. Utilisez les strotypes avec modration et de manire concerte (notez aussi qu'UML propose de nombreux strotypes standards).
UML en franais
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
DIAGRAMMES DE COMPOSANTS ET DE DEPLOIEMENT
q Diagramme de composants
q
Les diagrammes de composants permettent de dcrire l'architecture physique et statique d'une application en terme de modules : fichiers sources, librairies, excutables, etc. Ils montrent la mise en oeuvre physique des modles de la vue logique avec l'environnement de dveloppement. Les dpendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en vidence la rutilisation de composants. Le composants peuvent tre organiss en paquetages, qui dfinissent des sous-systmes. Les sous-systmes organisent la vue des composants (de ralisation) d'un systme. Ils permettent de grer la complexit, par encapsulation des dtails d'implmentation.
Modules (notation) :
Diagramme de composants (exemple) :
UML en franais
q Diagramme de dploiement
q
Les diagrammes de dploiement montrent la disposition physique des matriels qui composent le systme et la rpartition des composants sur ces matriels. Les ressources matrielles sont reprsentes sous forme de noeuds. Les noeuds sont connects entre eux, l'aide d'un support de communication. La nature des lignes de communication et leurs caractristiques peuvent tre prcises. Les diagrammes de dploiement peuvent montrer des instances de noeuds (un matriel prcis), ou des classes de noeuds. Les diagrammes de dploiement correspondent la vue de dploiement d'une architecture logicielle (vue "4+1").
UML en franais
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
Les vues dynamiques d'UML
COLLABORATION ET MESSAGES
q Diagramme de collaboration
q
Les diagrammes de collaboration montrent des interactions entre objets (instances de classes et acteurs). Ils permettent de reprsenter le contexte d'une interaction, car on peut y prciser les tats des objets qui interagissent.
Exemples :
UML en franais
q Synchronisation des messages

q
UML permet de spcifier de manire trs prcise l'ordre et les conditions d'envoi des messages sur un diagramme dynamique. Pour chaque message, il est possible d'indiquer : r les clauses qui conditionnent son envoi, r son rang (son numro d'ordre par rapport aux autres messages), r sa rcurrence, r ses arguments. La syntaxe d'un message est la suivante :
[pr "/"] [["["cond"]"] [sq] ["*"["||"]["["iter"]"]] ":"] [r ":="] msg"("[par]")"

r
pr : prdcesseurs (liste de numros de squence de messages spars par une virgule ; voir aussi "sq"). Indique que le message courant ne sera envoy que lorsque tous ses prdcesseurs le seront aussi (permet de synchroniser l'envoi de messages). cond : garde, expression boolenne.
Permet de conditionner l'envoi du message, l'aide d'une clause exprime en langage naturel.
UML en franais
sq : numro de squence du message. Indique le rang du message, c'est--dire son numro d'ordre par rapport aux autres messages. Les messages sont numrots la faon de chapitres dans un document, l'aide de chiffres spars par des points. Ainsi, il est possible de reprsenter le niveau d'embotement des messages et leur prcdence. Exemple : l'envoi du message 1.3.5 suit immdiatement celui du message 1.3.4 et ces deux messages font partie du flot (de la famille de messages) 1.3. Pour reprsenter l'envoi simultan de deux messages, il suffit de les indexer par une lettre. Exemple : l'envoi des messages 1.3.a et 1.3.b est simultan. iter : rcurrence du message.
Permet de spcifier en langage naturel l'envoi squentiel (ou en parallle, avec "||") de messages. Notez qu'il est aussi possible de spcifier qu'un message est rcurrent en omettant la clause d'itration (en n'utilisant que "*" ou "*||").
r : valeur de retour du message. Permet d'affecter la valeur de retour d'un message, pour par exemple la retransmettre dans un autre message, en tant que paramtre. msg : nom du message. par : paramtres (optionnels) du message.
Exemples :
3 : bonjour()
Ce message a pour numro de squence "3".
[heure = midi] 1 : manger()

Ce message n'est envoy que s'il est midi.
1.3.6 * : ouvrir()
Ce message est envoy de manire squentielle un certain nombre de fois.
3 / *||[i := 1..5] : fermer()

Reprsente l'envoi en parallle de 5 messages. Ces messages ne seront envoys qu'aprs l'envoi du message 3.
1.3,2.1 / [t < 10s] 2.5 : age := demanderAge(nom,prenom)

Ce message (numro 2.5) ne sera envoy qu'aprs les messages 1.3 et 2.1, et que si "t < 10s".
1.3 / [disk full] 1.7.a * : deleteTempFiles() 1.3 / [disk full] 1.7.b : reduceSwapFile(20%)
Ces messages ne seront envoys qu'aprs l'envoi du message 1.3 et si la condition "disk full" est ralise. Si cela est le cas, les messages 1.7.a et 1.7.b seront envoys simultanment. Plusieurs messages 1.7.a peuvent tre envoys.
q Objets actifs (threads)
UML en franais
q
UML permet de reprsenter des communications entre objets actifs de manire concurrente. Cette extension des diagrammes de collaboration permet notamment de reprsenter des communications entre processus ou l'excution de threads.
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
Les vues dynamiques d'UML (suite...)
DIAGRAMME DE SEQUENCE
q Diagramme de squence : smantique

q
Les diagrammes de squences permettent de reprsenter des collaborations entre objets selon un point de vue temporel, on y met l'accent sur la chronologie des envois de messages. Contrairement au diagramme de collaboration, on n'y dcrit pas le contexte ou l'tat des objets, la reprsentation se concentre sur l'expression des interactions. Les diagrammes de squences peuvent servir illustrer un cas d'utilisation. L'ordre d'envoi d'un message est dtermin par sa position sur l'axe vertical du diagramme ; le temps s'coule "de haut en bas" de cet axe. La disposition des objets sur l'axe horizontal n'a pas de consquence pour la smantique du diagramme. Les diagrammes de squences et les diagrammes d'tat-transitions sont les vues dynamiques les plus importantes d'UML.
Exemple :
UML en franais
q Types de messages
Comme vous pouvez le voir dans l'exemple ci-dessus, UML propose un certain nombre de strotypes graphiques pour dcrire la nature du message (ces strotypes graphiques s'appliquent galement aux messages des diagrammes de collaborations) :
q
message simple Message dont on ne spcifie aucune caractristique d'envoi ou de rception particulire. message minut (timeout) Bloque l'expditeur pendant un temps donn (qui peut tre spcifi dans une contrainte), en attendant la prise en compte du message par le rcepteur. L'expditeur est libr si la prise en compte n'a pas eu lieu pendant le dlai spcifi. message synchrone Bloque l'expditeur jusqu' prise en compte du message par le destinataire. Le flot de contrle passe de l'metteur au rcepteur (l'metteur devient passif et le rcepteur actif) la prise en compte du message. message asynchrone N'interrompt pas l'excution de l'expditeur. Le message envoy peut tre pris en compte par le rcepteur tout moment ou ignor (jamais trait). message drobant N'interrompt pas l'excution de l'expditeur et ne dclenche une opration chez le rcepteur que s'il s'est pralablement mis en attente de ce message.
q Activation d'un objet
UML en franais
Sur un diagramme de squence, il est aussi possible de reprsenter de manire explicite les diffrentes priodes d'activit d'un objet au moyen d'une bande rectangulaire superpose la ligne de vie de l'objet. On peut aussi reprsenter des messages rcursifs, en ddoublant la bande d'activation de l'objet concern. Pour reprsenter de manire graphique une excution conditionnelle d'un message, on peut documenter un diagramme de squence avec du pseudo-code et reprsenter des bandes d'activation conditionnelles.
Exemple :
Commentaires :
q
Ne confondez la priode d'activation d'un objet avec sa cration ou sa destruction. Un objet peut tre actif plusieurs fois au cours de son existence (voir exemple ci-dessus). Le pseudo-code peut aussi tre utilis pour indiquer des itrations (avec incrmentation d'un paramtre d'un message par exemple). Le retour des messages asynchrones devrait toujours tre matrialis, lorsqu'il existe. Notez qu'il est fortement recommand de synchroniser vos messages, comme sur l'exemple qui suit... L'exemple qui suit prsente aussi une alternative intressante pour la reprsentation des branchements conditionnels. Cette notation est moins lourde que celle utilise dans l'exemple ci-dessus. Prfrez aussi l'utilisation de contraintes celle de pseudo-code, comme dans l'exemple qui suit.
q Exemple complet
UML en franais
Afin de mieux comprendre l'exemple ci-dessous, veuillez vous rfrer aux chapitres sur la synchronisation des messages. Notez aussi l'utilisation des contraintes pour documenter les conditions d'envoi de certains messages.
Commentaire : Un message rflexif ne reprsente pas l'envoi d'un message, il reprsente une activit interne l'objet (qui peut tre dtaille dans un diagramme d'activits) ou une abstraction d'une autre interaction (qu'on peut dtailler dans un autre diagramme de squence).
page prcdente
sommaire
page suivante

UML en franais
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
DIAGRAMME D'ETATS-TRANSITIONS
q Diagramme d'tats-transitions : smantique

q
Ce diagramme sert reprsenter des automates d'tats finis, sous forme de graphes d'tats, relis par des arcs orients qui dcrivent les transitions. Les diagrammes d'tats-transitions permettent de dcrire les changements d'tats d'un objet ou d'un composant, en rponse aux interactions avec d'autres objets/composants ou avec des acteurs. Un tat se caractrise par sa dure et sa stabilit, il reprsente une conjonction instantane des valeurs des attributs d'un objet. Une transition reprsente le passage instantan d'un tat vers un autre. Une transition est dclenche par un vnement. En d'autres termes : c'est l'arrive d'un vnement qui conditionne la transition. Les transitions peuvent aussi tre automatiques, lorsqu'on ne spcifie pas l'vnement qui la dclenche. En plus de spcifier un vnement prcis, il est aussi possible de conditionner une transition, l'aide de "gardes" : il s'agit d'expressions boolennes, exprimes en langage naturel (et encadres de crochets).
tats, transition et vnement, notation :
transition conditionnelle :
UML en franais
q Super-Etat, historique et souches

q
Un super-tat est un lment de structuration des diagrammes d'tats-transitions (il s'agit d'un tat qui englobe d'autres tats et transitions). Le symbole de modlisation "historique", mmorise le dernier sous-tat actif d'un super-tat, pour y revenir directement ultrieurement.
Exemple : Le diagramme d'tats-transitions ci-dessous, montre les diffrents tats par lesquels passe une machine laver les voitures. En phase de lustrage ou de lavage, le client peut appuyer sur le bouton d'arrt d'urgence. S'il appuie sur ce bouton, la machine se met en attente. Il a alors deux minutes pour reprendre le lavage ou le lustrage (la machine continue en phase de lavage ou de lustrage, suivant l'tat dans lequel elle a t interrompue), sans quoi la machine s'arrte. En phase de schage, le client peut aussi interrompre la machine. Mais dans ce cas, la machine s'arrtera dfinitivement (avant de reprendre un autre cycle entier).
souches : afin d'introduire plus d'abstraction dans un diagramme d'tats-transitions complexe, il est possible de rduire la charge d'information, tout en matrialisant la prsence de sous-tats, l'aide de souches, comme dans l'exemple cidessous.
UML en franais
q Actions dans un tat

q
On peut aussi associer une action l'vnement qui dclenche une transition. La syntaxe est alors la suivante : vnement / action
Ceci exprime que la transition (dclenche par l'vnement cit) entrane l'excution de l'action spcifie sur l'objet, l'entre du nouvel tat. Exemple : il pleut / ouvrir parapluie Une action correspond une opration disponible dans l'objet dont on reprsente les tats. Les actions propres un tat peuvent aussi tre documentes directement l'intrieur de l'tat. UML dfinit un certain nombre de champs qui permettent de dcrire les actions dans un tat : r entry / action : action excute l'entre de l'tat r exit / action : action excute la sortie de l'tat r on vnement / action : action excute chaque fois que l'vnement cit survient r do / action : action rcurrente ou significative, excute dans l'tat
Exemple :
Remarque : Attention, les actions attaches aux clauses "entry" et "exit" ne sont pas excutes si l'vnement spcifi dans la clause "on" survient. Pour indiquer qu'elles peuvent tre excutes plusieurs fois l'arrive d'un vnement,
UML en franais
reprsentez l'arrive d'un vnement rflexif, comme suit :
q Etats concurrents et barre de synchronisation

Pour reprsenter des tats concurrents sur un mme diagramme d'tats-transitions, on utilise la notation suivante :
Dans l'exemple ci-dessus, l'automate K est compos des sous-automates L et M. L et M s'activent simultanment et voluent en parallle. Au dpart, l'objet dont on modlise les tats par l'automate K est dans l'tat composite (E-L1, E-M1). Aprs l'vnement Tr1, K passe dans l'tat composite (E-L2, E-M2). Par la suite, si l'vnement Tr2 survient, K passe dans l'tat composite (E-L3, E-M2). Si c'est Tr4 qui survient, M ne passe pas dans l'tat E-M1, car cette transition est contrainte par l'tat de L ("[in E-L3]"). Dans l'tat composite (E-L3, E-M2), si Tr3 survient, K passe dans l'tat composite (E-L2, E-M2). Si c'est Tr4 qui survient, K passe dans l'tat composite (E-L3, E-M1). Et ainsi de suite... Attention : la numrotation des vnements n'est pas significative. Pour synchroniser les sous-automates d'une agrgation d'tats, il faut contraindre les transitions, comme dans l'exemple ci-dessus ("[in E-L3]"). On peut aussi utiliser un symbole spcial : "la barre de synchronisation".
q
La barre de synchronisation permet de reprsenter graphiquement des points de synchronisation. Les transitions automatiques qui partent d'une barre de synchronisation ont lieu en mme temps.
UML en franais
On ne franchit une barre de synchronisation qu'aprs ralisation de toutes les transitions qui s'y rattachent.
q Evnement paramtr
UML permet aussi de paramtrer les vnements, comme dans l'exemple suivant :
q Echange de messages entre automates

Il est aussi possible de reprsenter l'change de messages entre automates dans un diagramme d'tats-transitions. Cette notation particulire n'est pas prsente ici. Veuillez vous rfrer "l'UML notation guide".
UML en franais
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
DIAGRAMME D'ACTIVITES
q Diagramme d'activits : smantique

q
UML permet de reprsenter graphiquement le comportement d'une mthode ou le droulement d'un cas d'utilisation, l'aide de diagrammes d'activits (une variante des diagrammes d'tats-transitions). Une activit reprsente une excution d'un mcanisme, un droulement d'tapes squentielles. Le passage d'une activit vers une autre est matrialis par une transition. Les transitions sont dclenches par la fin d'une activit et provoquent le dbut immdiat d'une autre (elles sont automatiques). En thorie, tous les mcanismes dynamiques pourraient tre dcrits par un diagramme d'activits, mais seuls les mcanismes complexes ou intressants mritent d'tre reprsents.
activits et transition, notation :
Pour reprsenter des transitions conditionnelles, utilisez des gardes (expressions boolennes exprimes en langage naturel), comme dans l'exemple suivant :
UML en franais
q Synchronisation
Il est possible de synchroniser les transitions l'aide des "barres de synchronisation" (comme dans les diagrammes d'tatstransitions). Une barre de synchronisation permet d'ouvrir et de fermer des branches parallles au sein d'un flot d'excution :
q q
Les transitions qui partent d'une barre de synchronisation ont lieu en mme temps. On ne franchit une barre de synchronisation qu'aprs ralisation de toutes les transitions qui s'y rattachent.
L'exemple suivant illustre l'utilisation des barres de synchronisation :
q Couloirs d'activits
UML en franais
Afin d'organiser un diagramme d'activits selon les diffrents responsables des actions reprsentes, il est possible de dfinir des "couloirs d'activits". Il est mme possible d'identifier les objets principaux, qui sont manipuls d'activits en activits et de visualiser leur changement d'tat.
page prcdente
sommaire
page suivante
UML en franais
ACCUEIL
COURS UML
LA NORME
BIBLIOGRAPHIE
LIENS WEB
FORUMS
Conclusion
q Programmer objet ?
q
Programmer en C++ n'est pas "concevoir objet" !

r
Seule une analyse objet conduit une solution objet (il faut respecter les concepts de base de l'approche objet). Le langage de programmation est un moyen d'implmentation, il ne garantit pas le respect des concepts objet.
UML n'est qu'un support de communication !

r
L'utilisation d'UML ne garantit pas le respect des concepts objet : vous de vous en servir bon escient.
>> Concevoir objet, c'est d'abord concevoir un modle qui respecte les concepts objet ! >> Le langage et UML ne sont que des outils.
q Utiliser UML ?
UML en franais
q
Multipliez les vues sur vos modles !

r
Un diagramme n'offre qu'une vue trs partielle et prcise d'un modle. Croisez les vues complmentaires (dynamiques / statiques).
Restez simple !
r
Utilisez les niveaux d'abstraction pour synthtiser vos modles (ne vous limitez pas aux vues d'implmentation). Ne surchargez pas vos diagrammes. Commentez vos diagrammes (notes, texte...).
Utilisez des outils appropris pour raliser vos modles !
page prcdente
sommaire
premire page
UML en franais
James Rumbaugh, Grady Booch et Ivar Jacobson, sont les inventeurs d'OMT, Booch et Objectory/OOSE. Les "trois amigos", comme on les surnomme, sont donc les vritables "parents" d'UML. Ils travaillent tous trois Rational Software, ce qui semble logique, vu le rle moteur qu' jou Rational dans le processus d'unification des mthodes fondatrices d'UML. Rational a t un membre actif du noyau d'entreprises qui ont soumis UML l'OMG, anime des groupes d'utilisateurs et participe aux organismes de rvision d'UML. Vous pouvez retrouver l'ensemble des documents qui composent la norme UML sur le site de Rational (aux formats PDF, HTML, Word et Frame), ainsi que de nombreuses informations complmentaires (articles, copies de confrences, etc...).
Le site web de l'OMG est essentiellement ddi CORBA, car il s'agit de la principale vitrine de l'organisation. Mais vous y trouverez aussi l'ensemble des documents de la norme UML, qui est, rappelons-le, un standard OMG depuis sa version 1.1.
http://uml.free.fr/norme/uml_free_fr_norme.html (1 sur 4) [03/05/2004 18:42:11]
UML en franais
Le site de l'OMG contient aussi des documents, qui expliquent pourquoi et comment l'OMG a adopt UML, ainsi qu'une copie du communiqu publi par l'OMG le 17 novembre 1997, qui annonce l'intgration d'UML dans l'OMA.
ESSAIM
Le site web de l'ESSAIM (Ecole suprieure des sciences appliques pour l'ingnieur - Mulhouse) propose aussi une copie des documents de la norme UML. Les fichiers sont disponibles au format PDF (leur visualisation ncessite donc Acrobat Reader).
Si les temps de rponses sont trop longs pour les sites prcdents, essayez de tlcharger les copies des documents de la norme UML 1.1 et 1.3 depuis uml.free.fr. Sauvegardez les fichiers sur votre disque dur et visualisez-les avec Acrobat Reader.
documents UML UML proposal to the OMG (UML 1.1) Liste des documents UML prsents l'OMG pour normalisation (intrt purement historique).
fichier PDF zipp
uml_proposal.zip
89 Ko
UML en franais
UML summary (UML 1.1) Introduction (prsentation d'UML et des documents de la norme). UML semantics (UML 1.1) Le mtamodle UML : prsente les lments de modlisation d'UML et leur smantique. UML notation guide (UML 1.1) Prsente la notation graphique d'UML. UML extension for Objectory Process (UML 1.1) Quelques extensions du mtamodle UML pour Objectory (profil peu complet). Object Constraint Language Specification (UML 1.1) Prsente OCL, le langage de dfinition de contraintes d'UML. OA&D CORBAfacility Interface Definition (UML 1.1) Mapping MOF/IDL (interface CORBA du mtamodle UML). UML extension for Business Modeling (UML 1.1) Quelques extensions du mtamodle UML pour la modlisation des processus (profil UML). UML 1.3 La version 1.3 d'UML intgre et dfinit XMI (format d'change de modles UML entre AGL). La mise en page du document a aussi t amliore (la version PDF propose dsormais de nombreux liens hypertextes). Attention, ce fichier PDF doit tre sauvegard et visualis en local, car il est trop volumineux pour tre lu depuis un navigateur...
uml_summary.zip
75 Ko
uml_semantics.zip
493 Ko
uml_notation.zip
531 Ko
uml_objectory.zip
50 Ko
uml_ocl.zip
98 Ko
uml_idl.zip
272 Ko
uml_bm.zip
44 Ko
uml13.zip
2.7 Mo
UML en franais
vers la bibliographie

Cours UML

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cours UML

Uploaded by

Copyright:

Available Formats

UML en franais

visiteurs sont dj passs par ici...

reprsenter des concepts abstraits (graphiquement par exemple),

faciliter l'analyse (simplifier la comparaison et l'valuation de solutions).

http://uml.free.fr/intro/uml_free_fr_intro.html (2 sur 10) [09/04/2004 12:09:48]

2) une dmarche d'analyse et de conception objet, pour

http://uml.free.fr/intro/uml_free_fr_intro.html (3 sur 10) [09/04/2004 12:09:48]

UML, OMG, OMA et cie.

Penser objet avec UML, pour concevoir objet.

Un langage universel et visuel.

L'aspect formel de sa notation, limite les ambiguts et les incomprhensions.

http://uml.free.fr/intro/uml_free_fr_intro.html (6 sur 10) [09/04/2004 12:09:48]

UML comme cadre d'une analyse objet.

http://uml.free.fr/intro/uml_free_fr_intro.html (7 sur 10) [09/04/2004 12:09:48]

UML : le chemin vers lunification des processus.

guide par les besoins des utilisateurs du systme,

centre sur l'architecture logicielle,

vers les cours UML

http://uml.free.fr/intro/uml_free_fr_intro.html (10 sur 10) [09/04/2004 12:09:48]

UML, le langage de modlisation objet unifi

visiteurs sont dj passs par ici...

http://uml.free.fr/cours/uml_free_fr_cours.html (1 sur 3) [09/04/2004 12:11:18]

MODELISER AVEC UML

Modliser les vues dynamiques d'un systme

le diagramme de collaboration synchronisation des messages

http://uml.free.fr/cours/uml_free_fr_cours.html (2 sur 3) [09/04/2004 12:11:18]

les objets actifs le diagramme de squence le diagramme d'tats-transitions le diagramme d'activits

vers la norme UML

http://uml.free.fr/cours/uml_free_fr_cours.html (3 sur 3) [09/04/2004 12:11:18]

Cliquez ici pour accder la page UML en franais !

Approche fonctionnelle vs. approche objet

q La dcoupe fonctionnelle d'un problme informatique : une approche intuitive

http://uml.free.fr/cours/i-p1.html (1 sur 3) [09/04/2004 12:12:14]

q Le "plus" de l'approche fonctionnelle : la factorisation des comportements

q Le revers de la mdaille : maintenance complexe en cas d'volution

http://uml.free.fr/cours/i-p1.html (2 sur 3) [09/04/2004 12:12:14]

uml@free.fr - tous droits rservs

http://uml.free.fr/cours/i-p1.html (3 sur 3) [09/04/2004 12:12:14]

Cliquez ici pour accder la page UML en franais !

Approche fonctionnelle vs. approche objet (suite...)

q La sparation des donnes et des traitements : le pige !

http://uml.free.fr/cours/i-p2.html (2 sur 5) [09/04/2004 12:13:13]

q 2me amlioration : centraliser les traitements associs un type, auprs du type

http://uml.free.fr/cours/i-p2.html (3 sur 5) [09/04/2004 12:13:13]

http://uml.free.fr/cours/i-p2.html (4 sur 5) [09/04/2004 12:13:13]

uml@free.fr - tous droits rservs

http://uml.free.fr/cours/i-p2.html (5 sur 5) [09/04/2004 12:13:13]

Cliquez ici pour accder la page UML en franais !

Approche fonctionnelle vs. approche objet (suite...)

http://uml.free.fr/cours/i-p3.html (1 sur 5) [09/04/2004 12:15:02]

Quels sont les autres concepts importants de l'approche objet ?

http://uml.free.fr/cours/i-p3.html (2 sur 5) [09/04/2004 12:15:02]

q Hritage (et polymorphisme)

Exemple d'une hirarchie de classes :

http://uml.free.fr/cours/i-p3.html (3 sur 5) [09/04/2004 12:15:02]

uml@free.fr - tous droits rservs

http://uml.free.fr/cours/i-p3.html (5 sur 5) [09/04/2004 12:15:02]

Cliquez ici pour accder la page UML en franais !

Approche fonctionnelle vs. approche objet (suite...)

q Rsum sur les concepts fondateurs de l'approche objet

q L'approche objet, hier et aujourd'hui

http://uml.free.fr/cours/i-p4.html (1 sur 4) [09/04/2004 12:15:58]

Les concepts objet sont stables et prouvs (issus du terrain)

De nos jours, les outils orients objet sont fiables et performants