Analyse Et Ion UML

Analyse et modlisation Objet UML _______________________________________________________
UML
Analyse et modlisation en Programmation Oriente Objets
Tarek EZZAT
__________________________________________________________________________ Tarek EZZAT - UML Page 1
Analyse et modlisation Objet avec UML

1. DFINITION D'UML..................................................................................................5 2. LE DIAGRAMME DE DPLOIEMENT...................................................................12 3. LE DIAGRAMME DE CONTEXTE..........................................................................13 4. LES CAS DUTILISATION......................................................................................13 5. DIAGRAMMES DINSTANCES (OU D'OBJETS)..................................................18 6. DIAGRAMME DE CLASSES..................................................................................19 7. DIAGRAMMES DACTIVIT...................................................................................27 8. DIAGRAMMES D'INTERACTION, DFINITION DES OPRATIONS..................31 9. LES DIAGRAMMES TATS - TRANSITIONS.......................................................40 10. DIAGRAMME DE PACKAGES.............................................................................45 11. RCAPITULATION...............................................................................................46 Par quoi commencer mme rduit l'essentiel, UML reste vaste pour commencer votre 1re analyse, vous pouvez peut-tre vous limiter lire le chapitre 1 Dfinition d'UML le dbut du chapitre 4 Les cas d'utilisation, paragraphes 1 et 2 le dbut du chapitre 6 Diagramme de classes, paragraphes 1 3 le dbut du chapitre 7 Diagramme d'activits, paragraphes 1 3 le dbut du chapitre 9 Diagramme d'tats, paragraphes 1 et 2 jetez un coup d'oeil aux chapitres 2 (Diagramme de dploiement) et 5 (Les diagrammes d'instances) qui sont trs courts gardez le reste pour plus tard Bibliographie pour commencer pour de bons conseils sur la faon d'utiliser UML UML2.0, Fowler, Campus Press UML2 en action, Roques et Valle, Eyrolles pour des exercices d'utilisation UML2 par la pratique, Roques, Eyrolles pour une prsentation plus complte des modles Modlisation objet avec UML, Muller et Gaertner, Eyrolles

Table dtaille 1. DFINITION D'UML..................................................................................................5
1.1. Qu'est-ce qu'UML......................................................................................................................................5 1.2. Objectif et place d'UML dans un projet logiciel......................................................................................5 1.3. Approche retenue dans le prsent support...............................................................................................6 1.4. UML en fait trop.........................................................................................................................................7 1.5. UML ne fait pas tout...................................................................................................................................7 1.6. Rfrences, outils.........................................................................................................................................7 1.7. Premire dfinition des principaux modles.............................................................................................7 1.8. L'enchanement des principaux diagrammes..........................................................................................11
2. LE DIAGRAMME DE DPLOIEMENT...................................................................12 3. LE DIAGRAMME DE CONTEXTE..........................................................................13 4. LES CAS DUTILISATION......................................................................................13

4.1. Concepts et construction...........................................................................................................................13 4.2. Documentation...........................................................................................................................................15 4.3. Enrichissements possibles.........................................................................................................................15 4.4. Rle et place des cas d'utilisation.............................................................................................................16 4.5. Piges et conseils........................................................................................................................................17
5. DIAGRAMMES DINSTANCES (OU D'OBJETS)..................................................18

5.1. Concepts et construction...........................................................................................................................18 5.2. Rle et place des diagrammes d'instance................................................................................................18
6. DIAGRAMME DE CLASSES..................................................................................19
6.1. Premire dfinition d'une classe...............................................................................................................19 6.2. L'bauche du diagramme de classes........................................................................................................20 6.2.1. Rgles et tapes de construction..........................................................................................................20 6.2.1.1. Premire dfinition des associations............................................................................................21 6.3. Piges et conseils........................................................................................................................................22 6.4. L'enrichissement du diagramme de classes.............................................................................................23 6.5. Le diagramme de classes finalis..............................................................................................................23 6.5.1. Finalisation des attributs......................................................................................................................23 6.5.2. Complments sur les associations........................................................................................................24

6.5.2.1. Lagrgation.................................................................................................................................24 6.5.2.2. Attributs dassociations................................................................................................................24 6.5.2.3. Multiplicits.................................................................................................................................25 6.5.3. L'hritage.............................................................................................................................................26 6.6. Plusieurs diagrammes de classe................................................................................................................26
7. DIAGRAMMES DACTIVIT...................................................................................27
7.1. Rle et place des diagrammes dactivit..................................................................................................27 7.2. Concepts de base du diagramme dactivit.............................................................................................27 7.3. Diagramme d'activit pour reprsenter un algorithme.........................................................................27 7.4. Diagramme d'activits couloirs d'activits...........................................................................................28 7.5. Reprsentation avec les objets utiliss.....................................................................................................29 7.6. Quelques prcisions...................................................................................................................................30 7.6.1. Activit ou tat?...................................................................................................................................30 7.6.2. Synchronisation...................................................................................................................................30
8. DIAGRAMMES D'INTERACTION, DFINITION DES OPRATIONS..................31

8.1. Deux formes de diagrammes dinteraction.............................................................................................31 8.2. Diagrammes de squence (scnarios).......................................................................................................32 8.2.1. Premiers concepts et construction.......................................................................................................32 8.2.2. Passage des messages aux oprations..................................................................................................34 8.2.2.1. Enrichissement du diagrammes de classes...................................................................................35 8.2.3. Naissance et disparition dun objet......................................................................................................35 8.2.4. Documentation des oprations.............................................................................................................36 8.3. Diagrammes de collaboration...................................................................................................................37 8.4. Piges et conseils........................................................................................................................................38 8.4.1. "bons" et "mauvais" scnarios.............................................................................................................38 8.4.2. Comparaison de deux solutions plus globales.....................................................................................39
9. LES DIAGRAMMES TATS - TRANSITIONS.......................................................40

9.1. Premiers concepts et construction...........................................................................................................40 9.2. La logique et la signification du diagramme d'tats...............................................................................41 9.3. Quelques lments de modlisation complmentaires............................................................................42 9.3.1. Sous-tats............................................................................................................................................42 9.3.2. Condition sur une transition.................................................................................................................42 9.3.3. Transition sans changement d'tat.......................................................................................................42 9.4. Enrichissement du diagramme de classes................................................................................................43 9.5. Rle et place des diagrammes d'tats......................................................................................................43 9.6. Piges et conseils........................................................................................................................................44

10. DIAGRAMME DE PACKAGES.............................................................................45 11. RCAPITULATION...............................................................................................46
1.
1.1.
Dfinition d'UML
Qu'est-ce qu'UML
UML : Unified Modeling Language n en 1995 dfinie comme norme par lOMG (Object Management Group) UML est une mthode de modlisation: UML dfinit comment reprsenter visuellement un logiciel comment dessiner un modle et surtout quoi reprsenter sur chaque modle UML ne dfinit pas quand ni pourquoi modliser cela est le rle de la mthode de conduite de projet Version courante: UML2 (adopte en 2004) - dfinit de nouveaux modles - apporte quelques amliorations aux modles existants Extensions: les "profils" sont destins adapter UML un contexte spcifique UML Real Time UML pour les services web 1.2. Objectif et place d'UML dans un projet logiciel
L'objectif et la place d'UML dpendent de la mthode de conduite de projet adopte l'extrme la plus ambitieuse, UML modlise tous les dtails du futur logiciel approche MOA (Model Driven Architecture) approche actuellement un stade exprimental l'extrme la plus modeste, UML (s'il est utilis) ne servira qu' clarifier quelques points difficiles du projet approche du RAD (Rapid Application Development) et des mthodes "agiles" (par exemple Extreme Programming) la modlisation, lorsqu'elle est utilise, est limite aux points qui ncessitent une clarification dans une approche intermdiaire, UML sert raliser le dossier d'analyse et de conception, sans prtendre modliser tous les dtails c'est l'approche prsente par exemple dans "UML en action", mentionn dans la bibliographie

1.3. Approche retenue dans le prsent support C'est la 3me approche qui est retenue dans le prsent support Dans cette approche, on va voir l'utilisation d'UML - dans l'tude de besoins - dans l'analyse mtier - dans la conception technique gnrale (l'architecture) - dans la conception technique dtaille (les objets) L'enchanement des tapes sera probablement
c o n c e p tio n g n r a le
tu d e d e s b e s o in s
c o n c e p t io n d t a ill e
a n a ly s e m t ie r
dfinition des termes tude de besoins dans l'approche traditionnelle, c'est ce qui aboutit au "cahier des charges" dans les approches modernes, c'est ce qui est destin formaliser les besoins et suivre leur prise en compte et leur volution ("requirement management") analyse mtier (analysis en anglais) en gnral - part de la dfinition des besoins fonctionnels - ignore les contraintes techniques et l'environnement d'excution en conception objet - se concentre sur les "objets mtier", dits aussi "objets du domain" - ignore les objets techniques (objets applicatifs, objets d'IHM, etc.) La conception technique conception technique gnrale (system design en anglais) dfinit les choix d'architecture: langage(s) utilis(s), bases de donnes, protocoles rseau, rpartition physique du logiciel, choix d'outils d'implmentation conception technique dtaille (object design en anglais) dtaille l'implmentation des objets mtier ajoute les objets techniques

1.4. UML en fait trop L'objectif d'UML est d'aller jusqu' la gnration du code (MDA, vu plus haut) et de couvrir tous les types de projets logiciels UML propose 9 types de diagrammes UML2 en propose 13 il y a plus de modles dans UML que ce qui est ncessaire dans la plupart des projets l'objectif n'est pas d'utiliser tous les modles mais de choisir ceux qui sont utiles selon le type de projet
1.5.
UML ne fait pas tout
UML concerne seulement la modlisation, on l'a dj dit; mais UML ne contient pas tous les modles qui peuvent tre utiles par exemple UML ne donne aucun outil pour modliser une Interface Homme-Machine (le dessin des pages ou des crans de l'IHM, et surtout leur enchanement la cinmatique de l'IHM) la reprsentation d'un document XML sous forme d'un arbre d'objets UML est bien moins lisible que sous la forme propose par Altova (XMLSpy) la reprsentation des donnes peut tre plus lisible en modle entits-associations (le modle conceptuel de Merise) qu'en modle relationnel la reprsentation d'un processus est plus riche dans les modlisations spcialises (BPMN, BPSS) qu'en UML UML n'interdit pas d'utiliser d'autres modles en complment. 1.6. Rfrences, outils
Si l'on veut mieux comprendre UMl, on peut en tudier les anctres : OMT: Object Modeling Technique (Rumbaugh) Booch Objectory ou OOSE (Jacobson) UML est n de la fusion de ces 3 mthodes et s'est inspire de beaucoup d'autres (Schlaer et Mellor, Coad et Yourdon) Quelques AGLs de conception objet
et aussi les plugins des outils de dveloppement (en particulier Eclipse) 1.7. Premire dfinition des principaux modles
Rational Rose Poseidon Power designer et AMC designer Mega Together Argo UML
Sur les 13 types de diagrammes, 8 ou 9 au maximum sont importants dans l'immdiat __________________________________________________________________________ Tarek EZZAT - UML Page 8

Il y a beaucoup e choses dans la norme UML, mais, selon les pres de la mthode eux-mmes, on peut analyser 80% des problmes avec 20% de la norme Ce sont ces 20% qui sont dtaills ici; le reste est seulement mentionn en conclusion ( voir le cours "UML avanc" ) Cas dutilisation dcrit les interactions entre le futur systme et ses utilisateurs
utilisateur
un f utur annuaire
enreg istrer
adm inistrateur
conf ig urer
Journal AnnuairePrincipal
Classes reprsente les types d'objets qui existeront dans le systme
AnnuaireSecondaire
Diagramme d'activits
dcrit un algorithme de traitement ou un processus

la n c e m e n t
s e rv e u r_ A : S e r v e u r P r in c ip a l [ a c tiv ]
o u v e rtu re
jo u r n a l _ A : J o u rn a l [ o u v e rt ]

Etats-Transitions montre les tats successfs d'un objet
activ dsactiv
Serveur d' annuaire
Diagramme de dploiement reprsente les machines (ou les types de machines) sur lesquels le logiciel sera dploy
s e rv e u r
HTTPS
c lie n t
diagramme d'instances (ou d'objets)

annuaire_A : AnnuairePrincipal journal_A : Journal
reprsente des instances d'objets qui existent un moment donn dans le systme retour sur les dfinitions: "objet" "classe" "instance"
annuaire1 : AnnuaireSecondaire
annuaire2 : AnnuaireSecondaire
Squence ( appels aussi scnarios) montre un enchanement d'oprations entre des objets du systme
Paul: utilisateur adm inistrateur
crer aj outer
annuaire1 Annuaire

Diagramme de communication (UML2) ou de collaboration (UML1)
1 . o u v r ir
combine la reprsentation des objets (instances), celle de leur relation, et la circulation des appels de mthodes
s e rv e u r_ A : S e r v e u r P r in c ip a l
jo u r n a l_ A : J o u rn a l
2 . a c tu a lis e r s e rv e u r_ 1 : S e r v e u r S e c o n d a ir e
Packages
package1 package2
sert simplement regrouper des classes qui appartiennent une mme famille
.
Vocabulaire: on distingue souvent, du point de vue des types de modles les modles dynamiques, qui reprsentent lexpression d'un comportement diagrammes de squence, de collaboration, d'tats... les modles statiques, qui reprsentent une structure diagrammes de classes, de composants, de dploiement...

1.8. L'enchanement des principaux diagrammes
A l'intrieur d'une phase de l'analyse (et aussi de la conception technique) on retrouve toujours le mme enchanement entre les modles
d ia g r a m m e s de c la s s e s C la s s e cas d 'u t i l i s a t i o n C la s s e cas cas
C la s s e
C la s s e
ta ts t r a n s it io n s
ta t
d ia g r a m m e s d e s q u e n c e
d i a g r a m m e s d 'a c t i v i t
ta t ta t
Les cas dutilisation reprsentent le lien avec les tapes qui ont prcd l'analyse, un point de dpart pour l'analyse Le diagramme de classes reprsente l'autre point de dpart, et le point d'arrive Les diagrammes d'activits et de squence reprsentent l'implmentation des cas d'utilisation et l'utilisation des objets. Les diagrammes d'tats reprsentent tous les tats possibles des objets d'une classe donne. Les mmes modles se retrouveront en conception technique, avec toutefois une importance relative diffrente. les objets identifis en analyse se retrouvent (avec d'autres ajouts entre temps...) dans l'implmentation.
2.
Le diagramme de dploiement
Il dcrit l'implantation physique du logiciel il reprsente les "processeurs": matriels sur lesquels sont implantes les diffrentes parties du logiciel process: les principaux programmes excuts sur le processeur units passives ("devices"): matriels qui n'hbergent pas le logiciel dvelopp dans le projet (par exemple des routeurs, des multiplexeurs) connexions: liens entre les processeurs et les devices protocoles: les principaux protocoles utiliss sur une connexion
Un exemple de diagramme de dploiement:

s erveur w eb
se rvl e ts p a g e s JS P
< < dis que> s toc k age
processors et devices sont appels aussi nuds des strotypes peuvent tre utiliss pour dfinir des types particuliers de processeurs ou de devices
< < htt p> >
une c onfigur ati on bien c onnue
brow s er
j a va scri p t
3.
Le diagramme de contexte
C'est une forme particulire des diagrammes de use cases ou des diagrammes de classes, qui seront vus plus loin. But: montrer en introduction au dossier d'analyse une vue trs globale du rle et de la place de l'application Contenu: on reprsente la future application comme une boite noire, et on reprsente les principaux changes enter l'application et les utilisateurs (ou les autres applications) Exemple
demande d'adh'sion
adhrent inscription une activit
cotisations reues
application comptable
gestion des adhrents et activits
dfi nition des act ivit s tableaux de bord
c lub
4.
4.1.
Les cas dutilisation

Concepts et construction
dem ande d 'a d h s io n c a rte d 'a d h r e n t e n r e g is t r e r u n e a d h s io n
Notion dfinie par Jacobson Concepts Cas dutilisation: un service (une fonctionnalit) attendu du systme une fraction du comportement du systme, runie en une transaction, en rponse un venement dclencheur venant dun acteur
a d h re n t a c t iv it s o u h a it e a c c o rd o u re fu s
e n r e g is t r e r u n e a d h s io n d e g ro u p e
in s c r ir e u n e a c t iv it

a n im a t e u r d u c lu b p la n i f i e r u n e a c t i v it
Acteur: - cest un objet extrieur au systme - c'est une entit physique (le service Comptabilit, le chef comptable) ou un rle (le rdacteur, le vrificateur) Noter: un acteur n'est pas forcment un acteur humain, mais peut tre une autre application Message ou vnement le message en entre dclenche un cas le message en sortie est le rsultat du droulement du cas Construction du diagramme => un cas dutilisation comporte un acteur initiateur, et ventuellement un ou n acteurs participants ici Adhrer est initialis par le (futur) adhrent => le cas dutilisation figure lensemble des interactions qui peuvent survenir entre les acteurs et le systme, partir de lvenement dclencheur => le systme est vu comme une boite noire pour chaque cas dutilisation, il y a un ensemble dvnements qui peuvent survenir entre les acteurs participants et le systme.

4.2. Documentation
Le diagramme de cas d'utilisation ne suffit pas; les cas doivent imprativement tre dcrits. UML ne dfinit pas le mode de documentation des cas d'utilisation. Si la dmarche d'analyse attache de l'importance aux use cases, le chef de projet doit dfinir le mode de documentation choisi: documentation peu formelle une description informelle peut "raconter" en quelques phrases le droulement habituel du use case (voir l'exemple donn par Rumbaugh dans son livre sur OMT) fiche de cas certains proposent d'tablir une fiche de cas
Cas n xxx Libell du cas Catgorie les cas peuvent Par ex.: retirer de l'argent dans un distributeur automatique tre classs par familles Acteur principal: celui qui initie la transaction; ici le porteur de la carte bancaire Acteurs secondaires: ceux qui participent la ralisation du cas; ici, le systme central de gestion des cartes voles Description du cas dcrire sous forme textuelle le droulement du cas (de quelques lignes une page ou plus) 1. introduire la carte 2. entrer le code d'identification 3. 4. Rgles de gestion quelles sont les rgles qui doivent tre appliques ce cas par ex.: limiter le montant distribu Prconditions dans quel tat le systme doit-il se trouver au dbut du cas? par ex., le distributeur a termin le traitement du client prcdent ou de l'opration prcdente Postcondition dans quel tat le systme doit-il se trouver la fin du cas? par ex., le distributeur est prt traiter la demande suivante du client, ou le client suivant Exceptions quelles sont les erreurs qui peuvent tre dclenches? par ex.: "transaction non autorise", "rserve de billets puise", etc. Extensions et variantes extensions (quels sont les cas qui tendent le cas dcrit ici?); par ex. retirer de l'argent en choisissant la devise ou les coupures variantes; droulements (normaux) possibles autres que celui dcrit; par ex.le distributeur peut proposer plusieurs devises diffrentes Complments, questions en suspens commentaires, observations, questions en attente 4.3. Enrichissements possibles
enregis trer une adhs ion
relation "utilise" ("uses" ou "includes")
< < inc lude> >

enr egis t rer un paiem ent
ou relation "tend" ("extends") un cas dutilisation peut inclure ( uses ) dautres cas
relation d'hritage un cas driv hrite de la signification et du contenu ( les oprations ) de son super-cas
planifier une ac tivit
planifier une ac tivit rptitive
4.4.
Rle et place des cas d'utilisation
Suivi de l'volution des besoins dans certaines approches actuelles, on considre que les besoins ne peuvent pas tre figs l'inventaire des cas d'utilisation sert alors tenir jour la liste des besoins pris en compte et leur description (requirement management) Structuration de l'analyse par les cas d'utilisation certaines mthodes font jouer un rle d'organisation du projet aux cas d'utilisation ("use case driven analysis") dans cette approche 1. les cas listent les besoins analyser, implmenter et tester 2. on en tire la liste des scnarios analyser. analyser le ou les scnario(s) correspondant au droulement normal du cas analyser les scnarios correspondant au droulement anormal du cas 3. on s'en sert comme rfrence lors de la validation par les utilisateurs 4. on dfinit une itration en termes de use cases implments par celle-ci 5. on mesure l'avancement du projet en terme de nombre de use cases implments

4.5. Piges et conseils Procder par itrations Combien de cas d'utilisation? ne pas tomber dans un dcoupage trop fin (dit "dcoupage fonctionnel") Documenter chaque cas chaque acteur chaque message Les acteurs dfinir les acteurs logiques ou les rles, plutt que les acteurs physiques ne pas dfinir comme acteurs des objets internes au systme le temps peut-il tre modlis en tant qu'acteur? Ignorer les messages entre les acteurs externes Comment choisir les cas analyser d'abord? commencer par les cas frquents? ou par les cas difficiles?
5.
5.1.
Diagrammes dinstances (ou d'objets)

Concepts et construction
Un objet est reprsent par un rectangle qui contient soit le nom de la classe et celui de l'instance (spars par un double point) soit le nom de la classe seulement soit le nom de l'objet, dont la classe n'est pas encore dfinie
c hec s : A c tivit
Instance anonyme Classe anonyme
: Ac ti vit
judo
On peut faire figurer les relations entre objets

tot o : A dhrent prat iqu e judo : A c tivit
On peut faire figurer la multiplicit ("il y a plusieurs instances de Activit pour une de Animateur") et / ou les attributs significatifs
toto : Anim ateur

ag e : 27 diplm e : ...
j udo : udo Act v Actiivitit
5.2.
Rle et place des diagrammes d'instance
dans l'tape d'initialisation de l'analyse - pour identifier les objets et baucher le diagramme de classes - pour valider le diagramme de classes (attributs, multiplicits...) - pour construire les diagrammes de squence et dinteraction dans les tapes ultrieures - pour montrer les interactions entre les objets => diagramme de collaboration, plus loin dans ce chapitre, et dans la conception technique pour montrer la configuration d'un programme en conception technique et en rtroconception
6.
Diagramme de classes
Le diagramme de classes est le: diagramme central de la modlisation objet; il est construit par itrations pendant l'tape d'analyse 1. bauche du diagramme de classes trouver les classes que l'on utilisera pour construire les diagrammes de squence 2. enrichissement partir des diagrammes de squence et des diagrammes d'tat reporter les oprations et attributs dcouverts en construisant ces diagrammes 3. finalisation (multiplicits, hritage, etc.) l' "bauche de diagramme de classes" est une notion de mthode dfinie par exemple dans OMT (Rumbaugh), ou "UML en action" (Roques et Valle), mais pas dans le guide d'utilidation d'UML 6.1. Premire dfinition d'une classe
Chaque classe est reprsente sous la forme dun rectangle divis en 3 compartiments. Le 1er compartiment contient le nom de la classe, le second les attributs et le 3me les oprations Une classe comporte - un nom - des attributs - des comportements (les oprations) - ventuellement des rgles ou contraintes.
A dhr ent nom prnom num roA dhrent ajouterA c tivit() c alc ulerCotis ation()
habitudes d'criture: majuscule au nom de classe Adherent minuscule au nom d'attribut nom, prenom minuscule et parenthse pour d'une opration valider() majuscule l'intrieur des noms composs calculerCotisation () Identifiants: - distinction entre l'identifiant fonctionnel (n de client, n de facture connus des utilisateurs) et l'identifiant technique (adresse mmoire, OID, ignors pendant l'analyse) - l'identifiant fonctionnel est facultatif en conception objet - pas de formalisme pour reprsenter les identifiants. Un attribut: une information dcrivant les objets de la classe. unicit des noms d'attributs: l'intrieur de la classe, non entre les classes. Une opration ou mthode implmente un comportement des objets de la classe.
Le mme nom dans diffrentes classes doit (ou devrait) dsigner la mme nature d'opration (la mme signification pour les utilisateurs du systme). Autre terme utiliss: proprit, terme gnrique regroupant attribut ou opration
6.2.
L'bauche du diagramme de classes
Une bauche de diagramme de classes

Animateur nom emploie encadre Club propose activite utilise nom : String Adresse pratique possde adherent numero nom
Salle numero : int
6.2.1. Rgles et tapes de construction Objets mtier et objets techniques l'analyse doit tre faite indpendamment des futurs choix techniques l'analyse se limite donc aux objets mtier, et ignore les objets techniques les objets d'IHM (et les objets applicatifs en gnral) sont ignors les objets techniques sont ignors Dans un premier temps, on ne reprsente gnralement pas les oprations; elles vont tre ajoutes dans la seconde phase de l'analyse, aprs avoir analys les comportements (diagrammes d'activits, diagrammes de squence) Les contraintes lies aux outils ne sont pas prises en compte ce stade la localisation physique des objets est ignore les objets sont persistants autant que ncessaire pas de contraintes lies au langage Rgles de simplification pour l'tape d'analyse __________________________________________________________________________ Tarek EZZAT - UML Page 21
on fait des hypothses simplificatrices concernant la manipulation des objets les attributs sont "publics en lecture" il est toujours possible d'accder un objet par la valeur de ses attributs il est toujours possible de parcourir la liste des instances d'une classe, et de choisir dans cette liste toutes ces simplifications seront bien sr abandonnes lors de la conception technique et des complments seront ajouts au modle: visibilit des proprits (priv, public, ...) mode d'implmentation des associations (pointeurs?...) etc.
6.2.1.1.
Premire dfinition des associations
Association: m e m b re un lien entre les objets de deux classes: Ad h re n t C lu b un adhrent est membre du club l'animateur encadre une activit un adhrent peut tre l'enfant d'un autre adhrent (et cela a une importance pour notre analyse ) ... du point de vue de la signification ou du contenu ("smantique") une assocoation est un lien durable, "structurel" entre deux objets du point de vue technique une association est un chemin daccs entre les instances dune classe et les instances de lautre Nommer les associations: ce n'est pas obligatoire si la signification est claire plusieurs associations (entre des paires d'objets diffrents) peuvent porter le mme nom essayer de donner un nom qui se rfre la dure, non une action par ex. Adherent "participe " Activit, plutt que Adherent "s'inscrit " Activit Il peut y avoir plusieurs associations diffrentes entre deux mmes classes vrifier au niveau des instances qu'il s'agit bien de deux associations diffrentes
A ni m ateur
enc adre
p lanifie
A c ti vi t
Une association peut tre rflexive d'une instance vers une autre, dans la mme classe Un rle dcrit la part prise par une classe dans une association
Ad h e re n t n u m r o Adh r e n t + e nfa n t fa m ille
+ p a re n t

Associations ternaires: (ou n-aire): relie plus de deux classes. toujours vrifier si l'association ne peut pas tre dcompose. Quelques exemples de ternaires un vhicule appartient au titulaire de la carte grise plusieurs conducteurs habituels peuvent tre dclars pour un vhicule un vhicule est couvert par un contrat d'assurance, qui doit couvrir tous les conducteurs habituels les dveloppeurs sont affects aux projets en cours les dveloppeurs utilisent les AGLs pour raliser les projets
Adhrent
pratiq ue
Anim ateur
Activ it
6.3.
Piges et conseils
Dcouverte des objets un objet possde des tats et des comportements Une classe est une abstraction qui regroupe les objets semblables tous les objets dune classe partagent le mme comportement et les mmes attributs Par rapport aux entits, pour les "merisiens", - une entit peut se dcomposer en plusieurs classes (classe Adhrent et classe Adresse) - une classe peut regrouper plusieurs entits (relation maitre-dtail par exemple) - une classe peut tre cre pour structurer des comportements... Candidats objets: plutt trop de candidats objets, pour liminer ensuite, que pas assez pour clater ensuite un objet en deux objets distincts Attention aux objets cachs
Adhrent
nom
possde
Adresse
ou
Adhrent
nom adresse
et aux associations caches
Adhrent
nom activit pratiq ue
Ne pas confondre l'acteur et l'objet qui le reprsente: par ex. l'acteur "utilisateur" et l'image de l'utilisateur dans le systme.
6.4.
L'enrichissement du diagramme de classes
L'enrichissement peut se faire de 2 faons - on gnre les squelettes de classes partir du diagramme de classes et on commence coder plus tard, on pourra gnrer le diagramme de classes complt partir de ce qu'on aura cod (rtro-conception) - on continue l'analyse avec les diagrammes d'activit, d'tats, de squence puis on enrichit les classes partir de ce qu'on a dcouvert en laborant ces diagrammes
6.5.
Le diagramme de classes finalis
Qu'est-ce qu'un diagramme de classes "finalis"? en fin d'analyse les attributs d'instance sont dfinis les oprations sont dfinies et documentes les associations sont dfinies, avec leurs attributs ventuels et les multiplicits hritages dfinis Question de prsentation: on peut faire plusieurs diagrammes pour reprsenter plusieurs points de vue sur les classes: - arbre d'hritage des classes - associations entre classes - arbre d'agrgation - liste des classes avec le dtail de leurs proprits - etc. en fin de conception technique on trouvera en plus - des attributs et mthodes statiques - des classes abstraites, des interfaces (java), des mthodes abstrtaites pures (C++) - des classes techniques (classes d'accs au rseau, la base de donnes) - etc. 6.5.1. Finalisation des attributs Les types des attributs: un type de base (numrique, caractre...) __________________________________________________________________________ Tarek EZZAT - UML Page 24
un type dfini pour les besoins du modle une liste, un tableau... etc. Dtail d'un attribut: - son type - sa valeur par dfaut par exemple: prix: dcimal = 100 Attribut driv: attribut calculable partir des autres attributs de l'objet.
6.5.2. Complments sur les associations 6.5.2.1. PC Lagrgation Relation compos-composant entre des objets la classe d'assemblage contient les objets composs la classe de composant contient les objets composs. Par ex.: un vhicule, un ordinateur, etc. est compos d'lments Parfois dsigne par "has a" (par opposition "is a" pour l'hritage).
clavier
Par rapport une association, ici - la dure de vie des composants est souvent dpendante de celle du compos. - les proprits des composs ont un sens pour les composants - les oprations sur le compos affecteront souvent les composants. Rcursivit: une agrgation peut tre rcursive. Dans ce cas, il est indispensable de donner un no de rle chaque extrmit de l'association 6.5.2.2. Attributs dassociations
date dbut
E lem e nt + c om pos ant c ontient
+ c om pos
Les attributs de lien dcrivent l'association: exemple: Les utilisateurs manipulent des fichiers; les droits sont dfinis pour un type d'utilisateur et pour un type de fichier
Anim ateur
1..*
anim e
Activit
Choix entre attributs de lien et attributs des objets lis: __________________________________________________________________________ Tarek EZZAT - UML Page 25
Attention : selon que l'information dpend de l'un des objets (ce sera un attribut de l'objet), ou que l'information dpend de l'association entre deux objets (ce sera un attribut de l'association) la signification du modle est diffrente si les droits sont un attribut du fichier et s'ils sont un attribut de l'association fichier <-> utilisateur 6.5.2.3. Multiplicits
Multiplicit: dfinit combien d'instances de la classe peuvent tre connectes une seule instance de la classe associe => la notation est place l'oppos de celle des cardinalits dans Merise. Symboles utiliss par la mthode unifie:
Anim ateur
0..1
anim e
Activ it
il y a 0 ou 1 animateur pour une activit
Anim ateur
0..*
anim e
Activ it
il y a 0 n animateur(s) pour une activit
Anim ateur
1..*
anim e
Activ it
il y a 1 n animateur(s) pour une activit, et une seule activit pour un animateur il y a 1 3 animateur(s) pour une activit, et 1 2 activit(s) pour un animateur
Anim ateur
1..3
anim e
1..2
Activ it
6.5.3. L'hritage Dfinition: dpendance entre deux classes selon laquelle une classe (la sous-classe) possde les mmes proprits qu'une autre (la super-classe), avec des particularits modifiant ou compltant ces proprits. Plusieurs niveaux d'hritage sont possibles. ne pas oublier: la relation d'hritage transmet les associations, comme les attributs et oprations Exemple un adhrent possde les attributs - nom, prnom, tat civil, parce qu'il hrite de Personne - et, en propre, un numro un adhrent possde en plus un attribut taux de rduction la mthode calculerCotisation() figure dans Adhrent et dans Enfant la mthode de calcul sera diffrente dans la super-classe (Adhrent) et dans la sous-classe
P ers onne nom pr nom t atCi vi l m ajEt atCi vi l()
Ad hrent num roA dhrent c alc ulerCotis ation() ajouterA c tivit() partic ipe
A c tivit nom des c ription
Rappels: la gnralisation/spcialisation est le mcanisme de conception par lequel on rattache une sous-classe une super-classe.
E nfant taux Rduc tion c alc ulerCotis ation()
L'hritage multiple: cas o un objet appartient plusieurs arbres d'hritage simultanment.
6.6.
Plusieurs diagrammes de classe
Rle central: le diagramme de classes centralise toutes les informations il n'est pas question de montrer toutes les informations sur un seul diagramme on construira des diagrammes pour montrer un aspect ou un autre des classes. arborescence des classes (relations d'hritage) et oprations les classes et leurs associations l'ensemble des classes d'une catgorie etc.
7.
7.1.
Diagrammes dactivit
Rle et place des diagrammes dactivit
Rle: un diagramme d'activit prsente le droulement logique et chronologique d'un processus (informatique ou non) Utilisation: les diagrammes d'activit peuvent tre utiliss des tapes diverses de l'analyse - pour modliser un processus administratif - reprsentation de l'organisation administrative actuelle ou future et de l'impact du projet sur l'organisation du travail des utilisateurs - BPM (business process modeling), BPR (business process reengineering) - pour dcrire le droulement d'un use case reprsentation des tapes d'excution du use case et des diffrents enchanements possibles - dans la documentation d'une classe, pour expliciter l'algorithme d'une mthode complexe Les diagrammes d'activit peuvent prendre des formes varies - pour reprsenter un algorithme - pour reprsenter le rle des diffrents acteurs dans le processus (diagramme d'activits couloirs d'activits) - pour reprsenter l'action du processus sur les objets - pour reprsenter les activits parallles et les synchronisations 7.2. Concepts de base du diagramme dactivit la transition est instantane (pas de dure) est automatique (dclenche par la fin de l'activit)
- lactivit et est un traitement est interruptible
enreg istrem ent adhsion
le dbut et la fin du processus

enreg istrem ent adhsion donnes correctes? enreg istrem ent adhsion
validation
- les conditions : (appeles aussi gardes) avec le losange

[ oui ]
validation
ou sans
[ OK ] [ NOK ]
[ non ]
rej et validation
7.3.
Diagramme pour reprsenter un algorithme
d'activit
rej et
c'est la forme la plus simple du diagramme d'activit __________________________________________________________________________ Tarek EZZAT - UML Page 28

c'est la mme chose qu'un ordinogramme cela permet par exemple de dessiner l'algorithme d'un use case ou d'une opration
Important: le diagramme d'activit est le seul modle dynamique qui permette facilement de zoomer il permet de donner une vue d'ensemble d'un processus (avec des macro-activits) puis de dtailler chaque macro-activit dans un sous-diagramme Il est beaucoup plus difficile de donner une vue d'ensemble dans les diagrammes d'tats ou de squences
7.4.
Diagramme d'activits couloirs d'activits

le c a ndida t : a dh re nt : a c c ue il c lub : c om pta c lub
dans la modlisation d'un processus , un couloir d'activit (swimlane) est souvent utilis pour reprsenter un acteur responsable d'une activit
tabli r c hqu e
vrifier
on peut utiliser un couloir m ettre l'enc ais s em ent pour reprsenter le logiciel, et les autres couloirs pour reprsenter les acteurs (utilisateurs, dpartements de l'entreprise) qui interagissent avec le logiciel 2 couloirs peuvent reprsenter 2 parties de l'application qui dialoguent (le client et le serveur par exemple) chaque couloir peut aussi reprsenter un objet c'est une forme adapt la reprsentation de l'organisation administrative et de l'impact du projet sur cette organisation

7.5. Reprsentation avec les objets utiliss
comme dans le diagramme d'objets, les rectangles reprsentent des objets ou instances (pas des classes) les objets peuvent tre des instances des "candidats objets" dfinis dans dbut de l'enregis trem ent l'bauche du diagramme de classes les flches continues reprsentent le "flot de contrle" (la logique d'enchanement des oprations) les flches pointilles reprsentent les "flots de donnes" (cration, modification, lecture du contenu des objets)
enregi strer les info s s ur l'adhr ent
: A dhes ion [inc om plte] [ donnes inc om pltes ]
: A dhes ion [c om plte]
: Tarif [ ok ]
c om plter
il n'est pas ncessaire de faire figurer tous les objets l'tat des objets peut tre prcis
mo ntant s elon c atg
ce peut tre une prparation aux diagrammes de squence et aussi une faon de commencer analyser les tats (que l'on va voir l'tape suivante avec les diagrammes d'tat-transition.
c alc uler la c oti sat ion

7.6. Quelques prcisions
7.6.1. Activit ou tat? une activit
enregis trer les infos s ur l'adhrent
une activit est instantane (pas de dure, l'chelle de temps du logiciel modlis) par opposition une activit, un tat a une dure
[ ok ]
[ donnes inc om pl tes ]
un tat
attente infos c om plme ntai res do/ relanc er
ex pir ation dlai
rc eption infos m anquantes c alc uler la c otis ation
ab andon
un tat peut tre actif: - l'objet qui est dans cet tat peut faire un traitement pendant le temps o il est dans l'tat reprsent (par exemple envoyer des messages priodiques pour savoir si une liaison n'est pas tombe) - ou bien il peut tre l'coute et ragir lorsqu'un vnement se produit (par exemple un socket serveur, en attente de demande de connexion par les clients) la raction l'vnement peut tre la sortie de l'tat, ou simplement la production d'un message ou vnement en rponse. 7.6.2. Synchronisation appeles aussi "fork et "join", ils reprsentent des conditions "et" Ils peuvent servir - au niveau de l'analyse des processus, modliser des processus administratifs qui s'excutent simultanment - au niveau de la modlisation d'un programme, reprsenter un programme multithread
encaissem ent cotisation
enreg istrem ent adhsion
choix m ode de paiem ent
calcul cotisation
slection activits
8.
8.1.
Diagrammes d'interaction, dfinition des oprations

Deux formes de diagrammes dinteraction
Objectif des diagrammes dinteraction: montrer les changes de messages ou les appels de mthodes entre les objets
Formes: chronologique: diagramme de squence (ou scnario) => pour visualiser lenchainement des vnements partir dun vnement dclencheur Un diagramme de squence
: A dherent toto : adhrent 1: dem ande de partic ipation
ac tivit dem ande : A c tivite
2: pl ace dis ponible? 3: oui 4: dem ande ac c epte
1: dem ande de partic ipation
topologique: diagramme de collaboration => pour montrer la place et le rle de chaque objet Un diagramme de collaboration
: A dherent 4: dem ande ac c epte toto : adhrent
3: oui ac tivit dem ande : A c tivite 2: plac e dis ponible?
Place des diagrammes d'interaction Les diagrammes de squence ou de communication sont plus difficiles laborer qu les diagrammes d'activits ils sont aussi moins intuitifs (me semble-t-il) ils supposent que les objets aient dj t dfinis avec prcision Pour toutes ces raisons, il est sans doute prfrable de commencer par les diagrammes d'activits, et de rserver les diagrammes d'interaction la fin de l'analyse ou la conception technique.

8.2. Diagrammes de squence (scnarios) Le but des diagrammes de squence: Un diagramme de squence reprsente un droulement possible d'un cas d'utilisation. Le scnario reprsente une des squences possibles partir de l'vnement dclencheur du cas d'utilisation, et les rponses du systme on ne prtend pas construire une liste exhaustive des scnarios
toto : adhrent 1: dem ande de participation 2: place disponible? 3: oui 4: aj outer participant 5: dem ande accepte : Adherent activit dem ande : Activite
Un exemple (simplifi) : un adhrent demande s'inscrire une activit supplmentaire
8.2.1. Premiers concepts et construction Acteur extrieur et vnement dclencheur un scnario est gnralement dclench par un acteur extrieur (voir les cas dutilisation); il peut faire intervenir d'autres acteurs pendant son droulement il peut se terminer par un envoi de rponse (ou plusieurs) aux acteurs Instances dobjets => un scnario reprsente des occurences dobjets, pas des classes => une mme classe peut tre reprsente par plusieurs instances Evnements (ou messages) lacteur et les objets communiquent par une succession de messages Opration l'arrive d'un message vers une instance d'objet dclenche une opration Chronologie le diagramme de squence prsente les vnements dans leur ordre dapparition.

Structures de contrle Les structure de contrle : alternative: if... then... else... endif rptititve: while... do... enddo et toutes les structures quivalentes Exemples de mthodes pour reprsenter des conditions ou des branchements: (seulement si cest ncessaire la bonne comprhension du modle) une alternative (condition) exemple l'adhrent veut s'inscrire une activitselon qu'il y a de la place disponible ou non, la suite est diffrente UML 2 propose d'utiliser des "cadres d'interaction" pour faire ressortir ainsi les choix (appels "alt" pour alternative) et les boucles (loop)
: A d h e re n t to to : a d h re n t 1 : d e m a n d e d e p a r t i c i p a t io n 2 : p l a c e d i s p o n i b le ? a c t iv it d e m a n d e : A c t iv it e
si
5 : d e m a n d e a c c e p t e
4 : a j o u t e r p a r t ic ip a n t
5: dem ande
re je t e
une rptitive (boucle)

P ta n q u e : A c t iv it
:A d h re n t
envoyer une convocation chaque adhrent pqui participe lactivit noter la reprsentation de plusieurs instances dAdhrent
: A n im a t e u r
: A d h re n t
c o n v o c . r u n io n p ta n q u is t e s
lo o p : p o u r c h a q u e p ta n q u is te
c o n v o c . r u n io n
c o n v o c a tio n
Valeurs retournes on peut distinguer les questions (par ex. "demande de participation") par un trait continu et les rponses (par ex. "demande accepte") par un trait pointill Contraintes Dans tous les modles, une contrainte se reprsente par un texte {entre accolades} ou [entre crochets]
8.2.2. Passage des messages aux oprations Dfinition des oprations Pour exploiter les diagrammes de squence, il faut dfinir les oprations dclenches sur chaque classe dans le cas le plus simple, il s'agit de remplacer les messages par les oprations dclenches par ces messages et de distinguer les messages dclencheurs d'oprations des messages retourns en rsultat
Paramtres des oprations et valeur retourne Les paramtres dcrivant lvnement peuvent tre ports sur le diagramme Le nom et/ou la valeur du message en retour peuvent tre ajouts lvnement envoy. Retour sur le polymorphisme un vnement peut comporter diffrentes sries de paramtres : par ex. une demande dadhsion 1. avec nom, adresse 2. avec nom, adresse, date de naissance, chque joint 3. etc.
v nem ent (param 1, param 2...) : rsultat
8.2.2.1.

Enrichissement du diagrammes de classes
Une fois les oprations dfinies, l'enrichissement du diagramme de classes consiste reporter dans chaque classe les oprations dfinies trouver les attributs ncessaires l'excution de ces oprations valider le rsultat, du point de vue des classes et non plus des scnarios Notation dans le diagramme de classes le dtail d'une opration (appel sa signature) peut comporter - les arguments attendus et le type de la valeur retourne par exemple
ajouter(terme1: rel, terme2: rel) : rel
- les valeurs par dfaut des arguments par exemple
dessiner(CouleurFond: couleur = blanc, CouleurTrait: couleur = noir) : boolen
=> permet des appels la mme mthode avec un nombre variable darguments. Une classe avec l'affichage des oprations et de leur signature
Adherent numroAdhrent calculerCotisation(dateEffet : Date) : int ajouterActivit(nouvelleActivite : Activite) : boolean ajouterActivit(nouvelleActivit : Activite, dateEffet : Date) : boolean
8.2.3. Naissance et disparition dun objet le diagramme peut reprsenter la dure de vie de lobjet (du dbut dune ligne verticale sa fin) larrive du paiement de ladhrent provoque
adhrent toto : Adhrent : Appel de cotis.
- la cration dune instance de paiement

enreg istrem ent paiem ent
- la suppression de lappel de cotisation correspondant
: P aiem ent
im puter (Paiem ent ) supprim er ( )
8.2.4. Documentation des oprations Les diagrammes de squence ne donnent que le squelette dune squence doprations, il faut documenter chaque opration. Forme da la documentation: un commentaire attach au scnario ou un commentaire attach l'opration dans le diagramme de classes l'AGL peut crer la documentation du code gnr partir de ce commentaire ou le pseudo-code de l'opration ou un diagramme d'activits
toto : Adhrent adhrent
enreg istrem ent paiem ent
: P aiem ent
im puter (Paiem ent )
vrif ier les rf rences (n et date ) par rapport l' appel de cotisation

8.3. Diagrammes de collaboration
Diagrammes de squence et diagrammes de collaboration sont quivalents: les deux types de diagrammes reprsentent la mme information. Les diagrammes de collaboration, comme les diagrammes de squence, - se basent sur la reprsentation des instances dobjets (les diagrammes dinstances) - et reprsentent les venements ou messages entre ces objets.
adhrent
dm de inscrip activ it
un Adherent
une Activit
inscription dm de supplm ent cotis ation paiem ent
dm de inscrip activ it paiem ent
adhrent
un Adherent
inscription
un scnario peut tre facilement transform en diagramme de collaboration
dm de supplm ent cotisation
une Activit
un diagramme de collaboration montre le flot des messages entre les instances dobjets plusieurs messages peuvent figurer sur un lien entre deux objets
Remarques Reprsentation de la chronologie ce nest en principe pas le but du diagramme de collaboration. Cependant une notation est prvue ( consommer avec modration : on prfrera pour cela les diagrammes de squence ) Reprsentation gnrale des contraintes Une contrainte peut tre reprsente par un texte libre entre accolades, comme dans les autres modles Cration et destruction dinstances dobjets: la cration ou la destruction dune nouvelle instance dobjet est note comme une contrainte

8.4. Piges et conseils
Jusqu' quel niveau dtailler les scnarios? Faire des variantes d'un scnario, ou utiliser les structures de contrle (si sinon) dans un scnario unique? Comment montrer l'appel d'un scnario par un autre? 8.4.1. "bons" et "mauvais" scnarios Il y a plusieurs faons de traiter le mme cas d'utilisation Le but: fabriquer des objets utilisables Exemple enregistrement d'une demande d'adhsion
: Club : adhrent 1: dem ande d'adhs ion
: Adh erent
: A dherent : adhrent
ou
1: c rer 2: affec ter num ro
2: rec herc he proc hain num ro 3: c rer 4: num ro attribu
3: num ro attribu
placer les oprations sur les bons objets il y a probablement des diagrammes plus justes que dautres
8.4.2. Comparaison de deux solutions plus globales
un scnario centralisateur
un Paiement un Appel de cotisat.
un Adhrent
compte Trsorerie
adhrent
paiem ent cotis. annuelle enreg . paiem ent
cotis. rg le enreg . encaissem ent accus de rception
un scnario dcentralisateur
un Paiement un Appel de cotisat. compte Trsorerie
un Adhrent
adhrent
paiem ent cotis. annuelle identif ication Adh.
cotis. rg le enreg . crdit accus de rception
9.
9.1.
Les diagrammes tats - transitions

Premiers concepts et construction
Dfinition: le modle dynamique reprsente les modifications des objets dans le temps Un diagramme appartient une classe et une seule dfinit les tats possibles pour les instances de la classe le diagramme peut reprsenter aussi les interactions entre les objets de classes diffrentes. Concepts utiliss Etat: configuration d'un objet, conditionnant le type de rponse de l'objet un certain vnement exemples - demander la fermeture d'une fentre, selon que son contenu a t ac tif modifi ou non - renouveler l'adhsion d'un membre du club l'chance annuelle, selon qu'il est membre actif ou rsili Une transition rs i liat ion la matrialisation d'un tat: la valeur d'un attribut, ou d'un ensemble d'attributs, la prsence ou le contenu d'une association
rs ili
Un tat
Transition: passage d'un tat un autre Evnement: modification intervenue dans l'environnement et que l'objet doit prendre en compte L'vnement dclenche la transition dure: un vnement est "instantan" un tat est durable; en fait permanent jusqu' l'arrive d'un nouvel vnement. Cration d'une instance
de m ande d'a dhs ion
Un vnement
ac tif
Suppression d'une instance
rs ili
c l tur e exerc ic e

9.2. La logique et la signification du diagramme d'tats
tats de l'Adhrent demande d'adhsion
un exemple: les tats possibles d'un adhrent
rsiliation actif radiation rsili
complment d'info demande incomplte demande de suspension suspend u ractivation
clture exercice
en instance
noter: abandon les transitions sont orientes (des flches, non de simples traits): ce n'est pas parce que la transition est possible dans un sens qu'elle l'est dans l'autre un diagramme d'tats ne dfinit pas une squence unique il peut y avoir des boucles, plusieurs circuits, plusieurs points de cration et / ou suppression des instances il n'y a pas toujours des points de cration et / ou suppression des instances un diagramme d'tats reprsente tous les tats possibles des instances de la classe toutes les instances ne passeront pas par tous les tats

9.3. Quelques lments de modlisation complmentaires 9.3.1. Sous-tats A l'intrieur d'un tat, l'objet peut tre dans deux ou plusieurs sous-tats le super-tat dfinit une partie du comportement le sous-tat prcise ce comportement La transition peut se faire de ou vers le super-tat, ou bien de ou vers le sous-tat
ouverte ouverte
non planif ie
crer
planif ier planif ie ouvrir suspendre suspendue suspendue
supprim er
9.3.2. Condition sur une transition Un mme vnement peut dclencher deux transitions diffrentes en fonction d'une condition la condition est note sur la transition (transition garde)
actif
complment d'info[ dlai respect ] en instance complment d'info[ dlai non respect ]
9.3.3. Transition sans changement d'tat Si cela claire l'analyse, on peut noter des transitions d'un tat vers lui-mme
faute[ moins de 3 ]
dehors la troisime faute:

surle t errain faute[ troisime ] sur la touche

9.4. Enrichissement du diagramme de classes
Consquence des tats sur la dfinition des oprations deux tats deux comportements une condition dans la dfinition d'une opration Consquence sur la dfinition des attributs l'tat doit tre matrialis: - plage de valeurs d'un attribut - combinaison d'attributs - valeur d'une association - code tat
9.5.
Rle et place des diagrammes d'tats
Quels diagrammes d'tats faut-il faire? - en thorie, les objets de toutes les classes possdent des tats - en pratique seules les classes o au moins 3 tats sont identifiables mritent un diagramme Quand faire les diagrammes d'tats? les diagrammes d'tats ont un rle de validation: - ils peuvent tre discuts avec les utilisateurs (pour les objets que ces derniers connaissent) - ils servent au moins vrifier l'exhaustivit et la cohrence de l'analyse ils peuvent avoir un rle de dcouverte et de structuration: certains objets ont des tats connus des utilisateurs, tats qui servent mme organiser le travail (le "workflow"); par ex. les tats successifs d'une facture, pour un processus de facturation et d'encaissement modliser ces tats tt dans l'analyse le diagramme d'tats peut servir structurer le reste de l'analyse

9.6. Piges et conseils
Jusqu'o aller dans la modlisation des tats? il y a beaucoup de choses qui peuvent tre reprsentes dans un diagramme d'tat se limiter ce qui est ncessaire pour le but recherch et ce qui est comprhensible de tous Pas (ou pas toujours ) de "code tat" pour reprsenter les tats d'un objet Limite entre les tats et l'hritage: le mme objet dans deux tats, ou deux sous-classes de la mme classe? par ex. - bon client / client douteux : deux tats ou deux sous-classes avec des rgles de gestion diffrentes ? - et gros domestique / client tranger? L'hritage du diagramme d'tats n'est pas automatique les tats des objets de la sous-classe ne sont pas forcment ceux de la super-classe les tats sont implments dabs les oprations, et, dans l'implmentation, les objets de la sous-classe hritent des oprations de la super-classe, sauf si on les surcharge en pratique, les tats sont hrits par dfaut
10.
Diagramme de packages
Les packages servent regrouper les lments par famille quand le projet grossit - regrouper les cas d'utilisation par exemple les regrouper selon l'utilisateur principal concern, ou par domaine - regrouper les classes par problme trait voir l'usage des packages dans le JDK de java Exemple
lo g is t iq u e
les packages sont le plus souvent hirarchiss: ici logistique logistique.stocks
s to c k s
f o u r n is s e u r s
les packages dpendent d'autres packages (ils utilisent les lments dfinis dans d'autres packages ici stocks utilise fournisseurs
11.
Rcapitulation
On essaie ici de rcapituler l'utilisation d'UML dans chaque phase du projet Ceci est largement une question d'opinion personnelle Ceci dpend aussi beaucoup de la nature du projet Dans la dfinition des besoins et l'tude pralable Dfinition des besoins UML intervient peu ce stade son rle se limite la plupart du temps au diagramme de cas d'utilisation on peut aussi utiliser un outil pour rpertorier les besoins une feuille de tableur suffira la plupart du temps pour lister les besoins, leur statut actuel, la rfrence des documents de description il existe aussi des outils spcialiss (par exempleRequisite Pro de Rational)
Etude pralable: - dfinition du domaine (dfinition du primtre du projet) - tude de faisabilit et/ou d'opportunit on peut utiliser pour cette tape un diagramme de contexte pour dessiner le primtre du projet UML dans la conception technique gnrale on prcise dans cette tape les choix techniques (langages, modes de stockage) on dfinit l'implantation physique dans un diagramme de dploiement on peut montrer le dcoupage en domaines par des diagrammes de packages (packages de cas d'utilisations et/ou packages de classes) lorsqu'on utilisera des standards (frameworks d'objets, modles de conception design patterns-, conceptions gnriques du 2 tracks process) on pourra utiliser des diagrammes (de classes, d'activit, de squence) pour prsenter ces standards; on rentre l dans l'utilisation avance d'UML

UML dans l'analyse mtier Avant d'entrer dans le dtail de la dmarche d'analyse avec UML, on va prendre une vue gnrale des modles utiliss pour l'analyse des phases de l'analyse et de l'enchanement entre ces modles l'intrieur d'une phase Les diagrammes que l'on utilisera le plus souvent seront le diagramme de classes, imprativement, pour dfinir les classes le diagramme de use cases et la documentation des use cases les diagrammes d'activit et/ou les diagrammes de squence les diagrammes d'tats Les phases de l'analyse L'analyse est en gnral un processus itratif; ceci est particulirement vrai en conception objet et avec UML: L'analyse centre sur l'laboration et l'enrichissement progressif d'un diagramme de classes, qui synthtise l'essentiel du dossier d'analyse Dans un cycle d'analyse simple (un petit projet) on distinguera probablement trois tapes:
initialisation de l'analyse diag ramme de classes
[ prem ire bauche ]
cas d'utilisation
premiers diag ramme d'tats
premiers diag ramme de sq uence (scnarios)
dcouverte des interactions
diag ramme de classes

[ avec oprations et attributs ]
autres diag ramme d'tats
autres diag ramme de sq uence
finalisation de l'analyse
diag ramme de classes

[ f inalis ]

L'initialisation de l'analyse Quand? lorsque les objectifs sont clairs - les besoins fonctionnels sont rpertoris - le primtre du projet est dfini et lorsque la phase d'tude de faisabilit / d'opportunit apparat termine: le projet est ralisable (dans les enveloppes de temps et de budget) et rentable Quoi? donner une premire description des fonctionnalits prvues et des objets qui y concourront Comment? en dfinissant les cas d'utilisation ventuellement en dcrivant ces cas dans des diagrammes d'activits en recherchant les classes mtier possibles (bauche du diagramme de classes) Les itrations d'analyse Quand? lorsque la phase d'initialisation apparat termine: - on ne dcouvre plus de nouveaux use cases - les use cases sont compris et dcrits (textuellement, ou par des diagrammes d'activit, etc.) Quoi? dfinir la responsabilit et le contenu de chaque classe (oprations, attributs) travers la ralisation de chaque use case sous la forme d'un scnario Comment? Dans une approche formalise (type mthode Unified Process) - prendre un un tous les cas d'utilisation pour chaque cas d'utilisation: - dessiner un diagramme d'activit (si le cas est complexe, comporte des variantes, etc.) et/ou des diagrammes de squences (un par enchanement possible) - prendre une une toutes les classes pour chaque classe qui semble possder plus de 2 tats: - dfinir le diagramme d'tats - vrifier que les oprations dfinies (probablement dans les diagrammes de squences) implmentent bien toutes les transitions figurant sur le diagramme d'tats
Dans les approches agiles on codera directement partir des squelettes de classes, en croisant les doigts, ou bien - on dfinira les responsabilits des objets - on fera si ncessaire une maquette d'architecture - on choisira une solution d'implmentation (si possible un design pattern prouv) ceci sera abord dans le cours UML avanc Dans notre approche intermdiaire - choisir les use cases analyser en priorit - construire les diagrammes de squence (scnarios) pour - dcrire la ralisation de ces use cases - enrichir le diagramme de classes partir des scnarios La finalisation de l'analyse Quand? lorsque le cycle d'analyse apparat termine: Quoi? vrifier la cohrence de l'analyse complter la dfinition des classes et des associations dfinir les relations d'hritage complter la documentation du dossier Comment? pas de nouveaux diagrammes mais une rvision gnrale Cohrence entre les diagrammes Principe de la cohrence: - les modles dynamiques doivent reprendre les cascades dvnements dfinies dans les scnarios. - la spcification des oprations doit tre cohrente avec les contraintes dcoulant du diagramme dtats - les tats doivent tre dcrits par les attributs des objets (ou leurs associations, ou les attributs de leurs objets associs) Vrifications: - amont: o sont gnrs les vnements qui provoquent les transitions dcrites dans le modle en cours dexamen? - aval: les vnements mis par le modle destination dautres objets sont-ils repris dans le modle dynamique des objets concerns? __________________________________________________________________________ Tarek EZZAT - UML Page 50
Cohrence entre diagrammes de squence et diagrammes d'tats Reprsentent deux vues de la vie des objets doivent s'appuyer sur la mme logique, le mme enchanement Les vnements des diagrammes d'tats doivent se retrouver dans les diagrammes de squences Les conditions poses au droulement des oprations dans les diagrammes d'tats doivent se retrouver dans la documentation des oprations exemple
FenetrePrincipale
:Fentre P rincipale
fermer ( ) fermer ( )
:FentreFille
Fenetre fenetreFii l le fermer ( )
FenetreFille OK / nonOK
f erm er ( ) : booleen
m odif ie
sauvegarder
non m odif ie
entrer donnes
UML dans la conception technique dtaille et la ralisation Dans la conception technique dtaille, on tablit le diagramme de classes finalis On peut l'tablir en ajoutant des dtails au modle d'analyse, avant de gnrer les squelettes de classes On peut aussi l'tablir par rtro-conception partir du code, pendant l'implmentation Certains outils permettent de synchroniser automatiquement le code que l'on dveloppe et le diagramme que l'on enrichit.

Analyse Et Ion UML

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analyse Et Ion UML

Enviado por

Direitos autorais:

Formatos disponíveis

Analyse et modlisation Objet UML _______________________________________________________

__________________________________________________________________________ Tarek EZZAT - UML Page 1

Analyse et modlisation Objet UML _______________________________________________________

Analyse et modlisation Objet avec UML

__________________________________________________________________________ Tarek EZZAT - UML Page 2

Analyse et modlisation Objet UML _______________________________________________________

5. DIAGRAMMES DINSTANCES (OU D'OBJETS)..................................................18

__________________________________________________________________________ Tarek EZZAT - UML Page 3

Analyse et modlisation Objet UML _______________________________________________________

8. DIAGRAMMES D'INTERACTION, DFINITION DES OPRATIONS..................31

9. LES DIAGRAMMES TATS - TRANSITIONS.......................................................40

__________________________________________________________________________ Tarek EZZAT - UML Page 4

Analyse et modlisation Objet UML _______________________________________________________

__________________________________________________________________________ Tarek EZZAT - UML Page 5

Analyse et modlisation Objet UML _______________________________________________________

__________________________________________________________________________ Tarek EZZAT - UML Page 6

Analyse et modlisation Objet UML _______________________________________________________

__________________________________________________________________________ Tarek EZZAT - UML Page 7

Analyse et modlisation Objet UML _______________________________________________________

UML ne fait pas tout

Analyse et modlisation Objet UML _______________________________________________________

Classes reprsente les types d'objets qui existeront dans le systme

dcrit un algorithme de traitement ou un processus

__________________________________________________________________________ Tarek EZZAT - UML Page 9

Analyse et modlisation Objet UML _______________________________________________________

Serveur d' annuaire

diagramme d'instances (ou d'objets)

__________________________________________________________________________ Tarek EZZAT - UML Page 10

Analyse et modlisation Objet UML _______________________________________________________

__________________________________________________________________________ Tarek EZZAT - UML Page 11

Analyse et modlisation Objet UML _______________________________________________________

__________________________________________________________________________ Tarek EZZAT - UML Page 12

Analyse et modlisation Objet UML _______________________________________________________

Un exemple de diagramme de dploiement:

< < dis que> s toc k age

< < htt p> >

une c onfigur ati on bien c onnue

__________________________________________________________________________ Tarek EZZAT - UML Page 13

Analyse et modlisation Objet UML _______________________________________________________

adhrent inscription une activit

gestion des adhrents et activits

dfi nition des act ivit s tableaux de bord

Les cas dutilisation

__________________________________________________________________________ Tarek EZZAT - UML Page 14

Analyse et modlisation Objet UML _______________________________________________________

__________________________________________________________________________ Tarek EZZAT - UML Page 15

Analyse et modlisation Objet UML _______________________________________________________

relation "utilise" ("uses" ou "includes")

< < inc lude> >

__________________________________________________________________________ Tarek EZZAT - UML Page 16

Analyse et modlisation Objet UML _______________________________________________________

planifier une ac tivit rptitive

Rle et place des cas d'utilisation

__________________________________________________________________________ Tarek EZZAT - UML Page 17

Analyse et modlisation Objet UML _______________________________________________________

__________________________________________________________________________ Tarek EZZAT - UML Page 18

Analyse et modlisation Objet UML _______________________________________________________

Diagrammes dinstances (ou d'objets)

Instance anonyme Classe anonyme

On peut faire figurer les relations entre objets

toto : Anim ateur

j udo : udo Act v Actiivitit

Rle et place des diagrammes d'instance