Cours UML

ISTA-TAZA
TDI 2me Anne
Module : Analyse et conception oriente objet
UML :
Langage de modlisation objet unifi
Formateur : Abdelmajid LAMKADAM
ISTA TAZA
TDI 2me Anne
Sommaire
1. Introduction 2. Prsentation d'UML

Dfinition Les mthodes objet et la gense d'UML
Rle dUML
Avantages et inconvnients d'UML
3. Modliser avec UML

Qu'est-ce-qu'un modle ? Comment modliser avec UML ? Une dmarche itrative et incrmentale Une dmarche pilote par les besoins des utilisateurs
4. Modliser les Vues d'un systme

Vues statiques Vues dynamiques
5. Modliser les Aspects d'un systme

Aspect statique Aspect dynamique Aspect fonctionnel
6. Modliser les Diagrammes d'un systme

Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme du cas dutilisation de squences de collaboration de classes dobjets dtats transition dactivits de composants de dploiement
7. Synthse et conclusion
Formateur : LAMKADAM Abdelmajid
ISTA TAZA
TDI 2me Anne
1. Introduction :
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. 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 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, l'OMG propose UML.
ISTA TAZA
TDI 2me Anne
2. Prsentation dUML :
Dfinition :
UML (Unified Modeling Language), qui se traduit par : "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. 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. 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. 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.
Les mthodes objet et la gense d'UML :

Les premires mthodes d'analyse : (annes 70) o Dcoupe cartsienne (fonctionnelle et hirarchique) d'un systme. Modlisation des donnes + modlisation des traitements (Merise, Axial, IE...).
L'approche systmique : (annes 80) o L'mergence des mthodes objet : (1990-1995) o 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) ? o Plus de 50 mthodes objet sont apparues durant cette priode (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) ! o Aucune mthode ne s'est rellement impose. Les premiers consensus : (1995) o OMT (James Rumbaugh) : vues statiques, dynamiques et fonctionnelles d'un systme Issue du centre de R&D de General Electric. Notation graphique riche et lisible. o OOD (Grady Booch) : vues logiques et physiques du systme Dfinie pour le DOD, afin de rationaliser de dveloppement d'applications ADA, puis C++. Ne couvre pas la phase d'analyse dans ses 1res versions (prconise SADT). Introduit le concept de package (lment d'organisation des modles). o OOSE (Ivar Jacobson) : couvre tout le cycle de dveloppement Issue d'un centre de dveloppement d'Ericsson, en Sude. La mthodologie repose sur l'analyse des besoins des utilisateurs.
L'unification et la normalisation des mthodes : (1995-1997)
ISTA TAZA
TDI 2me Anne
UML (Unified Modeling Langage), la fusion et synthse des mthodes dominantes :
UML aujourd'hui est un standard incontournable: o UML est le rsultat d'un large consensus (industriels, mthodologistes...). o UML est le fruit d'un travail d'experts reconnus. o UML est issu du terrain. o UML est riche (il couvre toutes les phases d'un cycle de dveloppement). o UML est ouvert (il est indpendant du domaine d'application et des langages d'implmentation). o 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...). o XML (format d'change standard de modles UML). UML volue mais reste stable: o L'OMG RTF centralise et normalise les volutions d'UML au niveau international. o Les groupes d'utilisateurs UML favorisent le partage des expriences. o De version en version, UML gagne en maturit et prcision, tout en restant stable. o UML inclut des mcanismes standards d'auto-extension. o La description du mtamodle d'UML est standardise (OMG-MOF).
Note : UML n'est pas une mode, c'est un investissement fiable !
Le rle dUML :
UML n'est pas une mthode ou un processus ! o Si l'on parle de mthode objet pour UML, c'est par abus de langage ! o Ce constat vaut aussi pour OMT ou d'autres techniques / langages de modlisation. o Propose aussi un processus, qui rgit l'enchanement des activits de production d'une entreprise. o UML a t pens pour permettre de modliser les activits de l'entreprise, pas pour les rgir. o Un processus de dveloppement logiciel universel est une utopie : Impossible de prendre en compte toutes les organisations et cultures d'entreprises. Un processus est adapt (donc trs li) au domaine d'activit de l'entreprise. Mme si un processus constitue un cadre gnral, il faut l'adapter de manire prcise au contexte de l'entreprise. UML est un langage pseudo-formel : o UML est fond sur un mtamodle, qui dfinit : les lments de modlisation (les concepts manipuls par le langage), la smantique de ces lments (leur dfinition et le sens de leur utilisation). o Un mtamodle est une description trs formelle de tous les concepts d'un langage. Il limite les ambiguts et encourage la construction d'outils.
ISTA TAZA
TDI 2me Anne
o o o o
Le mtamodle d'UML permet de classer les concepts du langage (selon leur niveau d'abstraction ou domaine d'application) et expose sa structure. Le mtamodle UML est lui-mme dcrit par un mta-mtamodle (OMG-MOF). UML propose aussi une notation, qui permet de reprsenter graphiquement les lments de modlisation du mtamodle. Cette notation graphique est le support du langage UML.
UML cadre l'analyse objet, en offrant : o diffrentes vues complmentaires d'un systme, qui guident l'utilisation des concepts objets, o plusieurs niveaux d'abstraction, qui permettent de mieux contrler la complexit dans l'expression des solutions objets.
UML est un support de communication o Sa notation graphique permet d'exprimer visuellement une solution objet. o L'aspect formel de sa notation limite les ambiguts et les incomprhensions. o Son aspect visuel facilite la comparaison et l'valuation de solutions. UML est le chemin vers lunification des processus : o Grce au principe d'laboration des modles, UML permet de mieux matriser la part d'inconnu et d'incertitudes qui caractrisent les systmes complexes. o Mais cet aspect mthodologique d'UML ne doit pas vous induire en erreur. o 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. o 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 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 cadre de 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 : 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 processus est une cl de la russite d'un projet : (non couvert par UML) 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. UML est un langage universel et visuel : Son indpendance par rapport aux langages d'implmentation, domaine d'application, processus... en font un langage universel. Avant tout est un support de communication performant, qui facilite la reprsentation et la comprhension de
ISTA TAZA
TDI 2me Anne
solutions objet : 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. Son indpendance par rapport aux langages de programmation, aux domaines d'application et aux processus, en fait un langage universel. 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. 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 peut-tre 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.
Les points forts d'UML :

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

La mise en pratique d'UML ncessite un apprentissage et passe par une priode d'adaptation. Mme si l'Espranto est une utopie, la ncessit de s'accorder sur des modes d'expression communs est vitale en informatique. UML nest 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.
ISTA TAZA
TDI 2me Anne
3. Modliser avec UML :

3.1. Qu'est-ce qu'un modle ?
Un modle est une abstraction de la ralit : L'abstraction est un des piliers de l'approche objet. o Il s'agit d'un processus qui consiste identifier les caractristiques intressantes d'une entit, en vue d'une utilisation prcise. o 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 : o 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. o 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 : o Modle mtorologique : partir de donnes d'observation (satellite ...), permet de prvoir les conditions climatiques pour les jours venir. o 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...). o 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,... Caractristiques fondamentales des modles : Le caractre abstrait d'un modle doit notamment permettre : o de faciliter la comprhension du systme tudi --> Un modle rduit la complexit du systme tudi. o de simuler le systme tudi reprsent par un modle qui 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
3.2. Comment modliser avec UML ?

UML est un langage qui permet de reprsenter des modles, sans dfinir le processus qui les laborer. Cependant, dans le cadre de la modlisation d'une application informatique, les auteurs d'UML prconisent d'utiliser une dmarche : o Itrative et incrmentale, o Guide par les besoins des utilisateurs du systme, o Centre sur l'architecture logicielle. D'aprs les auteurs d'UML, un processus de dveloppement possde ces qualits doit favoriser la russite d'un projet.
3.3. Une dmarche itrative et incrmentale:

L'ide est simple : pour modliser (comprendre et reprsenter) un systme complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son analyse par tapes. Cette dmarche doit 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.
3.4. Une dmarche pilote par les besoins des utilisateurs :

Avec UML, ce sont les utilisateurs qui guident la dfinition des modles : o Le primtre du systme modliser est dfini par les besoins des utilisateurs (les utilisateurs dfinissent ce que doit tre le systme). o 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
ISTA TAZA
TDI 2me Anne
incrmental) : o A chaque itration de la phase d'analyse, on clarifie, affine et valide les besoins des utilisateurs. o A chaque itration de la phase de conception et de ralisation, on veille la prise en compte des besoins des utilisateurs. o A chaque itration de la phase de test, on vrifie que les besoins des utilisateurs sont satisfaits.
4. Modliser les VUES d'UML :

4.1. Une dmarche centre sur l'architecture :
Une architecture adapte est la cl de vote du succs d'un dveloppement: Elle dcrit des choix stratgiques qui dterminent en grande partie les qualits du logiciel (adaptabilit, performances, fiabilit...). Ph. Kruchten propose diffrentes perspectives, indpendantes et complmentaires, qui permettent de dfinir un modle d'architecture (publication IEEE, 1995). Cette vue ("4+1") a fortement inspir UML :
Les 4+1 vues permettent de mettre en vidence les diffrents aspects du logiciel raliser. -La vue des cas dutilisation:Traite les spcifications fonctionnels du logiciel : (guide et justifie les autres vues). -La vue logique : Modlise les lments structurs du systme (les classes). -La vue des composants : Dcrit lorganisation des composants physique du logiciel (Fichiers sources, BD, DLL, etc). -La vue des processus:Traite les aspects multitches et concurrents du logiciel. -La vue de dploiement : Rpartition des composants physiques sur le matriel.
4.2. Vues Statiques :

o o o o o o o Conceptualisation et les cas d'utilisation Structuration des modles (paquetages, collaboration) les objets, le diagramme d'objets et les classes le diagramme de classes les strotypes le diagramme de composants le diagramme de dploiement
4.3. Vues Dynamiques :

o o o o o o le diagramme de collaboration synchronisation des messages les objets actifs le diagramme de squence le diagramme d'tats-transitions le diagramme d'activits
ISTA TAZA
TDI 2me Anne
5. Modliser les aspects dUML:

5.1. Aspect statique :
Dcrit laspect structurel du logiciel, c--d les classes, les objets constituant le systme et les relations entre eux.
5.2. Aspect dynamique :

Dcrit le comportement des objets lintrieur du systme c'est--dire changement dtat des objets en rponse certains vnements.
5.3. Aspect fonctionnel :

Dcrit les fonctionnalits ralises par les objets du systme par lintermdiaire de leurs oprations.
6. Modliser les Diagrammes UML :

6.1. Diagramme du cas d'utilisation
-La conceptualisation : (rappel)
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 : o dfinissent le contour du systme modliser (ils prcisent le but atteindre), o 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.
-Cas d'utilisation (use cases) : Il s'agit de la solution UML pour reprsenter le modle conceptuel. Ils 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 la traabilit des exigences d'un systme dans un processus de dveloppement intgrant UML.
-Le modle conceptuel : 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 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
10
ISTA TAZA
TDI 2me Anne
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. 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 ? Jacobson identifie les caractristiques suivantes pour les modles : 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. Notes : Il faut clarifier et organiser les besoins des clients (les modliser). Ils ne doivent pas chercher l'exhaustivit, mais clarifier, filtrer et organiser les besoins. Les use cases, permettent de modliser les besoins des clients d'un systme et doivent aussi possder ces caractristiques. Les use cases ne doivent donc en aucun cas dcrire des solutions d'implmentation. Leur but est justement d'viter de tomber dans la drive d'une approche fonctionnelle, o l'on liste une litanie de fonctions que le systme doit raliser.
Une fois identifis et structurs, ces besoins : dfinissent le contour du systme modliser (ils prcisent le but atteindre), permettent d'identifier les fonctionnalits principales (critiques) du systme. 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". 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. Elments de base des cas d'utilisation : Acteur : entit externe qui agit sur le systme (oprateur, autre systme...). o o o L'acteur peut consulter ou modifier l'tat du systme. En rponse l'action d'un acteur, le systme fournit un service qui correspond son besoin. Les acteurs peuvent tre classs (hirarchiss).
Use case : ensemble d'actions ralises par le systme, en rponse une action d'un acteur. o o o Les uses cases peuvent tre structurs. Les uses cases peuvent tre organiss en paquetages (packages). L'ensemble des use cases dcrit les objectifs (le but) du systme.
11
ISTA TAZA
TDI 2me Anne
Exemples : Cas d'utilisation standard
Relation d'utilisation :
12
ISTA TAZA
TDI 2me Anne
Relation d'extension :
Les paquetages : (packages) -Dfinition :

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.
-Relations entre paquetages :
13
ISTA TAZA
TDI 2me Anne
Paquetages : interfaces
Paquetages : strotypes
La collaboration : Symbole de modlisation "collaboration"

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 confondre pas l'lment de modlisation "collaboration" avec le diagramme de collaboration, qui reprsente des interactions entre instances de classes.
14
ISTA TAZA
TDI 2me Anne
6.2. Diagramme de squence :

Smantique : 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:
15
ISTA TAZA
TDI 2me Anne
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) : 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.
Activation d'un objet : 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 : 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).
16
ISTA TAZA
TDI 2me Anne
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.
Exemple : 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).
17
ISTA TAZA
TDI 2me Anne
6.3. Diagramme de collaboration :

Smantique : 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 :
Synchronisation des messages : 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 : o les clauses qui conditionnent son envoi, o son rang (son numro d'ordre par rapport aux autres messages), o sa rcurrence, o ses arguments. La syntaxe d'un message est la suivante :
[pr "/"] [["["cond"]"] [sq] ["*"["||"]["["iter"]"]] ":"] [r ":="] msg"("[par]")"

o 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). o cond : garde, expression boolenne. Permet de conditionner l'envoi du message, l'aide d'une clause exprime en langage naturel. 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 : Lenvoi du message 1.3.5 suit immdiatement celui du message 1.3.4 et ces deux messages font partie du flot o
18
ISTA TAZA
TDI 2me Anne
(famille de messages) 1.3. Pour reprsenter l'envoi simultan de deux messages, il suffit de les indexer par une lettre. Exemple : Lenvoi des messages 1.3.a et 1.3.b est simultan. o 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 "*||"). o 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.
o o
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. Objets actifs: (threads) 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.
19
ISTA TAZA
TDI 2me Anne
6.4. Diagramme de classes :

Smantique : 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 : o les classes qui participent un cas d'utilisation (cf. collaboration), o les classes associes dans la ralisation d'un scnario prcis, o les classes qui composent un paquetage, o la structure hirarchique d'un ensemble de classes. o Pour reprsenter un contexte prcis, un diagramme de classes peut tre instanci en diagrammes d'objets. Notation et smantique des classes: 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 :
20
ISTA TAZA
TDI 2me Anne
Attributs multivalus et drivs : Exemples :
Types de classes : 1. Classe abstraite : Exemple :
2. Template: (classe paramtrable) Exemple :
21
ISTA TAZA
TDI 2me Anne
Associations entre classes : 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.
Documentation d'une association : 1. Association en forme verbale active : prcise le sens de lecture principal d'une association. Voir aussi : association navigabilit restreinte.
2. Rles : spcifie la fonction d'une classe pour une association donne (indispensable pour les associations rflexives).
Remarques :
-Nom : forme verbale, sens de lecture avec flche -Rles : forme nominale, identification extrmit association
22
ISTA TAZA
TDI 2me Anne
3. Cardinalits : prcise le nombre d'instances qui participent une relation.
Expression des cardinalits d'une relation en UML : k : Exactement "k" (k, entier naturel > 0) k..j : De "k" "j" (entiers naturels ou variables, j > k) * : Plusieurs (quivalent "0..k" et "0..*") k..* : "k" ou plus (k, entier naturel ou variable)
exemples : "1", "7" exemples : "0..1", "3..k", "1..31" exemples : "0..*", "5..*"
Types d'associations : 1. 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).
2. 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.
3. 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.
23
ISTA TAZA
TDI 2me Anne
4. Classe d'association : il s'agit d'une classe qui ralise la navigation entre les instances d'autres classes.
5. Qualification : permet de slectionner un sous-ensemble d'objets, parmi l'ensemble qui participent une association. La restriction de l'association est dfinie par une cl, qui permet de slectionner les objets cibls.
6. Hritage : Les hirarchies de classes permettent de grer la complexit, en ordonnant les objets au sein d'arborescences de classes, d'abstraction croissante. Spcialisation : o Dmarche descendante, qui consiste capturer les particularits d'un ensemble d'objets, non discrimins par les classes dj identifies. o Consiste tendre les proprits d'une classe, sous forme de sous-classes, plus spcifiques (permet l'extension du modle par rutilisation). Gnralisation : o Dmarche ascendante, qui consiste capturer les particularits communes d'un ensemble d'objets, issus de classes diffrentes. o Consiste factoriser les proprits d'un ensemble de classes, sous forme d'une super-classe, plus abstraite (permet de gagner en gnricit). Classification : o L'hritage (spcialisation et gnralisation) permet la classification des objets. o Une bonne classification est stable et extensible : ne classifiez pas les objets
24
ISTA TAZA
TDI 2me Anne
o o
selon des critres instables (selon ce qui caractrise leur tat) ou trop vagues (car cela gnre trop de sous-classes). Les critres de classification sont subjectifs. 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." o Si Y hrite de X, cela signifie que "Y est une sorte de X" (analogies entre classification et thorie des ensembles).
7. Agrgation : 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 : o qu'une classe (un "lment") fait partie d'une autre ("l'agrgat"), o qu'un changement d'tat d'une classe, entrane un changement d'tat d'une autre, o 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.
25
ISTA TAZA
TDI 2me Anne
8. Composition : 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.
9. Agrgation et composition : 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" 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 ! 10. Interfaces : 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.
26
ISTA TAZA
TDI 2me Anne
11. Association drive : 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).
27
ISTA TAZA
TDI 2me Anne
Contrainte sur une association : 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.
Strotypes : 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).
28
ISTA TAZA
TDI 2me Anne
6.5. Diagramme d'objets (Instances):

Objet : unit atomique forme de lunion dun tat et dun comportement Etat dun objet: valeurs instantanes de tous ses attributs (ltat dun objet un moment donn est la consquence des comportements passs). Visibilit et porte des attributs et des oprations : o o o Public : llment est visible pour tous les clients de la classe Protg: llment est visible pour les sous-classes de la classe Priv: llment est visible pour la classe seule
Liens et relations : o Possibilit de communication entre objets : Interactions entre objets Relation entre classes o 3 grands types : (Voir relations entre classes) Agrgation : Objets Agrgat / Objets Agrg Association non symtrique : Une des extrmits joue un rle prdominant par rapport lautre Exemple : un train est compos de wagons Composition : Agrgation forte Destruction du composite (x est une partie de y?) => Destruction automatique de tous ses composants ("Fait partie de") : objets composites / Objets composants Cas particulier dagrgation : contenance physique Si destruction objet compos destruction des composants Exemple : un train est compos de moteurs Gnralisation : Relation de classification entre un lment plus gnral et un lment plus spcifique ("Est une sorte de") : hritage entre objets Regroupement, est un , sorte-de Exemple : un chat est une sorte danimal Spcialisation : (Symtrique gnralisation): raffinement de classe - par extension de proprits (ajouter un attribut) - par restriction de domaines de valeurs dattributs Associations : ("Est produit par", "est affili ", "se trouve ", "est conduit par") : Dpendance entre classes, communication entre objets Exemple : un lecteur lit un livre (forme verbale) Connexion bidirectionnelle entre classes Associations qualifies :
+Restrictions : slection dun sous-ensemble dobjets qui participent lassociation laide dune cl.
29
ISTA TAZA
TDI 2me Anne
Exemple :
Remarque : Le rle dun qualificateur est de rduire la cardinalit dune association et joue le rle dans une BDR. Lhritage : Moyen de raliser la classification ou lorganisation en classes Vocabulaire rserver limplantation
semblable une cl primaire
Principe de substitution : toutes les proprits de la classe parent doivent tre valables pour les classes enfant Hritages: simple / multiple +Hritage multiple : Problme : conflits dhritage (un attribut vitesse_max en km/h, en Nuds quhriter ?) En gnral, trs difficile utiliser : certains langages ngligent lhritage multiple Exemples d'instances :
Objets composites :
30
ISTA TAZA
TDI 2me Anne
Diagramme d'objets : 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. Liens entre objets / relations entre classes
Exemple :
31
ISTA TAZA
TDI 2me Anne
6.6. Diagramme d'etats-transitions :

Smantique : 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 :
Super-Etat, historique et souches : 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).
32
ISTA TAZA
TDI 2me Anne
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 ci-dessous.
Actions dans un tat : 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.
33
ISTA TAZA
TDI 2me Anne
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 : o entry / action : action excute l'entre de l'tat o exit / action : action excute la sortie de l'tat o on vnement / action : action excute chaque fois que l'vnement cit survient o 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, reprsentez l'arrive d'un vnement rflexif, comme suit :
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]").
34
ISTA TAZA
TDI 2me Anne
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" 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. On ne franchit une barre de synchronisation qu'aprs ralisation de toutes les transitions qui s'y rattachent.
Evnement paramtr : UML permet aussi de paramtrer les vnements, comme dans l'exemple suivant :
Note : Il est aussi possible de reprsenter l'change de messages entre automates dans un diagramme d'tats-transitions.
35
ISTA TAZA
TDI 2me Anne
6.7. Diagramme d'activits :

Smantique : 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 :
Synchronisation : Il est possible de synchroniser les transitions l'aide des "barres de synchronisation" (comme dans les diagrammes d'tats-transitions). Une barre de synchronisation permet d'ouvrir et de fermer des branches parallles au sein d'un flot d'excution : 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 :
36
ISTA TAZA
TDI 2me Anne
Couloirs d'activits : 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.
37
ISTA TAZA
TDI 2me Anne
6.8. Diagrammes de composants :

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. Les 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)
Exemple:
38
ISTA TAZA
TDI 2me Anne
6.9. Diagramme de dploiement :

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").
39
ISTA TAZA
TDI 2me Anne
7. Synthes et conclusion :
-Programmer objet :
Programmer en C++ n'est pas "concevoir objet" : o Seule une analyse objet conduit une solution objet (il faut respecter les concepts de base de l'approche o objet). Le langage de programmation est un moyen d'implmentation, il ne garantit pas le respect des concepts
objet. Le langage de programmation JAVA est un langage orient objet pure.
Concevoir objet, c'est d'abord concevoir un modle qui respecte les concepts objet. Le langage et UML ne sont que des outils.
-Utiliser UML :
UML n'est qu'un support de communication : o L'utilisation d'UML ne garantit pas le respect des concepts objet : vous de vous en servir bon escient. Multipliez les vues sur vos modles : o Un diagramme n'offre qu'une vue trs partielle et prcise d'un modle. o Croisez les vues complmentaires (dynamiques / statiques). Restez simple : o Utilisez les niveaux d'abstraction pour synthtiser vos modles (ne vous limitez pas aux vues d'implmentation). o Ne surchargez pas vos diagrammes. o Commentez vos diagrammes (notes, texte...).
Utilisez des outils appropris pour raliser vos modles : 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.
Pour toute remarque, question, suggestion, concernant ce document, envoyez un message l'adresse suivante : Majidxy@Yahoo.fr
40

Cours UML

Transféré par

Droits d'auteur :

Formats disponibles

Vous aimerez peut-être aussi

Cours UML

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours UML

Transféré par

Droits d'auteur :

Formats disponibles

ISTA-TAZA

TDI 2me Anne

Module : Analyse et conception oriente objet

Langage de modlisation objet unifi

Formateur : Abdelmajid LAMKADAM

TDI 2me Anne

1. Introduction 2. Prsentation d'UML

3. Modliser avec UML

4. Modliser les Vues d'un systme

5. Modliser les Aspects d'un systme

6. Modliser les Diagrammes d'un systme

Module : Analyse et conception oriente objet

Formateur : LAMKADAM Abdelmajid

TDI 2me Anne

Module : Analyse et conception oriente objet

Formateur : LAMKADAM Abdelmajid

TDI 2me Anne

Les mthodes objet et la gense d'UML :

L'unification et la normalisation des mthodes : (1995-1997)

Module : Analyse et conception oriente objet

Formateur : LAMKADAM Abdelmajid

TDI 2me Anne

UML (Unified Modeling Langage), la fusion et synthse des mthodes dominantes :

Note : UML n'est pas une mode, c'est un investissement fiable !

Module : Analyse et conception oriente objet

Formateur : LAMKADAM Abdelmajid

TDI 2me Anne

Formateur : LAMKADAM Abdelmajid

TDI 2me Anne

Les points forts d'UML :

Les points faibles d'UML :

Module : Analyse et conception oriente objet

Formateur : LAMKADAM Abdelmajid

TDI 2me Anne

3. Modliser avec UML :

3.2. Comment modliser avec UML ?

3.3. Une dmarche itrative et incrmentale:

3.4. Une dmarche pilote par les besoins des utilisateurs :

Module : Analyse et conception oriente objet

Formateur : LAMKADAM Abdelmajid

TDI 2me Anne

4. Modliser les VUES d'UML :

4.2. Vues Statiques :

4.3. Vues Dynamiques :

Module : Analyse et conception oriente objet

Formateur : LAMKADAM Abdelmajid

TDI 2me Anne

5. Modliser les aspects dUML:

5.2. Aspect dynamique :

5.3. Aspect fonctionnel :

6. Modliser les Diagrammes UML :

Formateur : LAMKADAM Abdelmajid

TDI 2me Anne

Module : Analyse et conception oriente objet

Formateur : LAMKADAM Abdelmajid

TDI 2me Anne

Exemples : Cas d'utilisation standard

Module : Analyse et conception oriente objet

Formateur : LAMKADAM Abdelmajid