Analyse et modélisation Objet UML _______________________________________________________

UML
Analyse et modélisation en Programmation Orientée Objets

Tarek EZZAT

__________________________________________________________________________ Tarek EZZAT - UML Page 1

Analyse et modélisation Objet UML _______________________________________________________

Analyse et modélisation Objet avec UML
1. DÉFINITION D'UML..................................................................................................5 2. LE DIAGRAMME DE DÉPLOIEMENT...................................................................12 3. LE DIAGRAMME DE CONTEXTE..........................................................................13 4. LES CAS D’UTILISATION......................................................................................13 5. DIAGRAMMES D’INSTANCES (OU D'OBJETS)..................................................18 6. DIAGRAMME DE CLASSES..................................................................................19 7. DIAGRAMMES D’ACTIVITÉ...................................................................................27 8. DIAGRAMMES D'INTERACTION, DÉFINITION DES OPÉRATIONS..................31 9. LES DIAGRAMMES ÉTATS - TRANSITIONS.......................................................40 10. DIAGRAMME DE PACKAGES.............................................................................45 11. RÉCAPITULATION...............................................................................................46 Par quoi commencer même réduit à l'essentiel, UML reste vaste pour commencer votre 1ère analyse, vous pouvez peut-être vous limiter à lire  le chapitre 1 Définition d'UML  le début du chapitre 4 Les cas d'utilisation, paragraphes 1 et 2  le début du chapitre 6 Diagramme de classes, paragraphes 1 à 3  le début du chapitre 7 Diagramme d'activités, paragraphes 1 à 3  le début du chapitre 9 Diagramme d'états, paragraphes 1 et 2 jetez un coup d'oeil aux chapitres 2 (Diagramme de déploiement) et 5 (Les diagrammes d'instances) qui sont très courts gardez le reste pour plus tard… Bibliographie pour commencer pour de bons conseils sur la façon d'utiliser UML UML2.0, Fowler, Campus Press UML2 en action, Roques et Vallée, Eyrolles pour des exercices d'utilisation UML2 par la pratique, Roques, Eyrolles pour une présentation plus complète des modèles Modélisation objet avec UML, Muller et Gaertner, Eyrolles

__________________________________________________________________________ Tarek EZZAT - UML Page 2

Analyse et modélisation Objet UML _______________________________________________________
Table détaillée 1. DÉFINITION 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 présent support...............................................................................................6 1.4. UML en fait trop.........................................................................................................................................7 1.5. UML ne fait pas tout...................................................................................................................................7 1.6. Références, outils.........................................................................................................................................7 1.7. Première définition des principaux modèles.............................................................................................7 1.8. L'enchaînement des principaux diagrammes..........................................................................................11

2. LE DIAGRAMME DE DÉPLOIEMENT...................................................................12 3. LE DIAGRAMME DE CONTEXTE..........................................................................13 4. LES CAS D’UTILISATION......................................................................................13
4.1. Concepts et construction...........................................................................................................................13 4.2. Documentation...........................................................................................................................................15 4.3. Enrichissements possibles.........................................................................................................................15 4.4. Rôle et place des cas d'utilisation.............................................................................................................16 4.5. Pièges et conseils........................................................................................................................................17

5. DIAGRAMMES D’INSTANCES (OU D'OBJETS)..................................................18
5.1. Concepts et construction...........................................................................................................................18 5.2. Rôle et place des diagrammes d'instance................................................................................................18

6. DIAGRAMME DE CLASSES..................................................................................19
6.1. Première définition d'une classe...............................................................................................................19 6.2. L'ébauche du diagramme de classes........................................................................................................20 6.2.1. Règles et étapes de construction..........................................................................................................20 6.2.1.1. Première définition des associations............................................................................................21 6.3. Pièges 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. Compléments sur les associations........................................................................................................24

__________________________________________________________________________ Tarek EZZAT - UML Page 3

Analyse et modélisation Objet UML _______________________________________________________
6.5.2.1. L’agrégation.................................................................................................................................24 6.5.2.2. Attributs d’associations................................................................................................................24 6.5.2.3. Multiplicités.................................................................................................................................25 6.5.3. L'héritage.............................................................................................................................................26 6.6. Plusieurs diagrammes de classe................................................................................................................26

7. DIAGRAMMES D’ACTIVITÉ...................................................................................27
7.1. Rôle et place des diagrammes d’activité..................................................................................................27 7.2. Concepts de base du diagramme d’activité.............................................................................................27 7.3. Diagramme d'activité pour représenter un algorithme.........................................................................27 7.4. Diagramme d'activités à couloirs d'activités...........................................................................................28 7.5. Représentation avec les objets utilisés.....................................................................................................29 7.6. Quelques précisions...................................................................................................................................30 7.6.1. Activité ou état?...................................................................................................................................30 7.6.2. Synchronisation...................................................................................................................................30

8. DIAGRAMMES D'INTERACTION, DÉFINITION DES OPÉRATIONS..................31
8.1. Deux formes de diagrammes d’interaction.............................................................................................31 8.2. Diagrammes de séquence (scénarios).......................................................................................................32 8.2.1. Premiers concepts et construction.......................................................................................................32 8.2.2. Passage des messages aux opérations..................................................................................................34 8.2.2.1. Enrichissement du diagrammes de classes...................................................................................35 8.2.3. Naissance et disparition d’un objet......................................................................................................35 8.2.4. Documentation des opérations.............................................................................................................36 8.3. Diagrammes de collaboration...................................................................................................................37 8.4. Pièges et conseils........................................................................................................................................38 8.4.1. "bons" et "mauvais" scénarios.............................................................................................................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 éléments de modélisation complémentaires............................................................................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. Rôle et place des diagrammes d'états......................................................................................................43 9.6. Pièges et conseils........................................................................................................................................44

__________________________________________________________________________ Tarek EZZAT - UML Page 4

Analyse et modélisation Objet UML _______________________________________________________
10. DIAGRAMME DE PACKAGES.............................................................................45 11. RÉCAPITULATION...............................................................................................46

__________________________________________________________________________ Tarek EZZAT - UML Page 5

apporte quelques améliorations aux modèles existants Extensions: les "profils" sont destinés à adapter UML à un contexte spécifique UML Real Time UML pour les services web 1.UML Page 6 . mentionné dans la bibliographie __________________________________________________________________________ Tarek EZZAT . est limitée aux points qui nécessitent une clarification  dans une approche intermédiaire.Analyse et modélisation Objet UML _______________________________________________________ 1.1. UML (s'il est utilisé) ne servira qu'à clarifier quelques points difficiles du projet approche du RAD (Rapid Application Development) et des méthodes "agiles" (par exemple Extreme Programming) la modélisation. UML sert à réaliser le dossier d'analyse et de conception. sans prétendre modéliser tous les détails c'est l'approche présentée par exemple dans "UML en action". 1.définit de nouveaux modèles . Objectif et place d'UML dans un projet logiciel L'objectif et la place d'UML dépendent de la méthode de conduite de projet adoptée  à l'extrême la plus ambitieuse. Définition d'UML Qu'est-ce qu'UML UML : Unified Modeling Language né en 1995 définie comme norme par l’OMG (Object Management Group) UML est une méthode de modélisation: ⇒ UML définit comment représenter visuellement un logiciel comment dessiner un modèle et surtout quoi représenter sur chaque modèle ⇒ UML ne définit pas quand ni pourquoi modéliser cela est le rôle de la méthode de conduite de projet Version courante: UML2 (adoptée en 2004) . UML modélise tous les détails du futur logiciel approche MOA (Model Driven Architecture) approche actuellement à un stade expérimental  à l'extrême la plus modeste.2. lorsqu'elle est utilisée.

dans la conception technique détaillée (les objets) L'enchaînement 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 définition des termes étude de besoins dans l'approche traditionnelle.3. on va voir l'utilisation d'UML . bases de données. etc. dits aussi "objets du domain" .part de la définition des besoins fonctionnels . répartition physique du logiciel.dans l'analyse métier .Analyse et modélisation Objet UML _______________________________________________________ 1. c'est ce qui est destiné à formaliser les besoins et à suivre leur prise en compte et leur évolution ("requirement management") analyse métier (analysis en anglais) en général .) La conception technique conception technique générale (system design en anglais) définit les choix d'architecture: langage(s) utilisé(s).ignore les contraintes techniques et l'environnement d'exécution en conception objet . choix d'outils d'implémentation … conception technique détaillée (object design en anglais) détaille l'implémentation des objets métier ajoute les objets techniques __________________________________________________________________________ Tarek EZZAT .se concentre sur les "objets métier".ignore les objets techniques (objets applicatifs. protocoles réseau. c'est ce qui aboutit au "cahier des charges" dans les approches modernes.UML Page 7 .dans la conception technique générale (l'architecture) .dans l'étude de besoins . Approche retenue dans le présent support C'est la 3ème approche qui est retenue dans le présent support Dans cette approche. objets d'IHM.

1. BPSS…) qu'en UML UML n'interdit pas d'utiliser d'autres modèles en complément. UML ne fait pas tout UML concerne seulement la modélisation.4. on l'a déjà dit.7.Analyse et modélisation Objet UML _______________________________________________________ 1. on peut en étudier les ancêtres : OMT: Object Modeling Technique (Rumbaugh) Booch Objectory ou OOSE (Jacobson) UML est né de la fusion de ces 3 méthodes et s'est inspirée de beaucoup d'autres (Schlaer et Mellor. et surtout leur enchaînement – la cinématique de l'IHM) • la représentation d'un document XML sous forme d'un arbre d'objets UML est bien moins lisible que sous la forme proposée par Altova (XMLSpy) • la représentation des données peut être plus lisible en modèle entités-associations (le modèle conceptuel de Merise) qu'en modèle relationnel • la représentation d'un processus est plus riche dans les modélisations spécialisées (BPMN. outils Si l'on veut mieux comprendre UMl. 8 ou 9 au maximum sont importants dans l'immédiat __________________________________________________________________________ Tarek EZZAT .UML Page 8 .5.6. Première définition des principaux modèles Rational Rose Poseidon Power designer et AMC designer Mega Together Argo UML… Sur les 13 types de diagrammes. Coad et Yourdon…) Quelques AGLs de conception objet et aussi les plugins des outils de développement (en particulier Eclipse) 1. mais UML ne contient pas tous les modèles qui peuvent être utiles par exemple • UML ne donne aucun outil pour modéliser une Interface Homme-Machine (le dessin des pages ou des écrans de l'IHM. Références. UML en fait trop L'objectif d'UML est d'aller jusqu'à la génération 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 modèles dans UML que ce qui est nécessaire dans la plupart des projets l'objectif n'est pas d'utiliser tous les modèles mais de choisir ceux qui sont utiles selon le type de projet 1.

mais. le reste est seulement mentionné en conclusion ( voir le cours "UML avancé" ) • Cas d’utilisation décrit les interactions entre le futur système et ses utilisateurs utilisateur un f utur annuaire enreg istrer adm inistrateur conf ig urer Journal AnnuairePrincipal • Classes représente les types d'objets qui existeront dans le système AnnuaireSecondaire • Diagramme d'activités décrit 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 ] __________________________________________________________________________ Tarek EZZAT . selon les pères de la méthode eux-mêmes.UML Page 9 . on peut analyser 80% des problèmes avec 20% de la norme Ce sont ces 20% qui sont détaillés ici.Analyse et modélisation Objet UML _______________________________________________________ Il y a beaucoup e choses dans la norme UML.

Analyse et modélisation Objet UML _______________________________________________________ • Etats-Transitions montre les états successfs d'un objet activé désactivé Serveur d' annuaire • Diagramme de déploiement représente les machines (ou les types de machines) sur lesquels le logiciel sera déployé s e rv e u r HTTPS c lie n t • diagramme d'instances (ou d'objets) annuaire_A : AnnuairePrincipal journal_A : Journal représente des instances d'objets qui existent à un moment donné dans le système retour sur les définitions: "objet" "classe" "instance" annuaire1 : AnnuaireSecondaire annuaire2 : AnnuaireSecondaire • Séquence ( appelés aussi scénarios) montre un enchaînement d'opérations entre des objets du système Paul: utilisateur adm inistrateur créer aj outer annuaire1 Annuaire : __________________________________________________________________________ Tarek EZZAT .UML Page 10 .

d'états... et la circulation des appels de méthodes 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 . qui représentent l’expression d'un comportement diagrammes de séquence.. • les modèles statiques. du point de vue des types de modèles • les modèles dynamiques..UML Page 11 . de déploiement. __________________________________________________________________________ Tarek EZZAT .Analyse et modélisation Objet UML _______________________________________________________ • Diagramme de communication (UML2) ou de collaboration (UML1) 1 . o u v r ir combine la représentation des objets (instances). de composants. Vocabulaire: on distingue souvent. qui représentent une structure diagrammes de classes. 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 même famille . de collaboration. celle de leur relation.

Analyse et modélisation Objet UML _______________________________________________________ 1.UML Page 12 . Les mêmes modèles se retrouveront en conception technique. Les diagrammes d'états représentent tous les états possibles des objets d'une classe donnée.) dans l'implémentation.. avec toutefois une importance relative différente. un point de départ pour l'analyse Le diagramme de classes représente l'autre point de départ.8. et le point d'arrivée Les diagrammes d'activités et de séquence représentent l'implémentation des cas d'utilisation et l'utilisation des objets..  les objets identifiés en analyse se retrouvent (avec d'autres ajoutés entre temps. L'enchaînement des principaux diagrammes A l'intérieur d'une phase de l'analyse (et aussi de la conception technique) on retrouve toujours le même enchaînement entre les modèles 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 d’utilisation représentent le lien avec les étapes qui ont précédé l'analyse. __________________________________________________________________________ Tarek EZZAT .

des multiplexeurs…) • • connexions: liens entre les processeurs et les devices protocoles: les principaux protocoles utilisés sur une connexion Un exemple de diagramme de déploiement: 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 appelés aussi nœuds des stéréotypes peuvent être utilisés pour définir 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 __________________________________________________________________________ Tarek EZZAT . Le diagramme de déploiement Il décrit l'implantation physique du logiciel il représente • les "processeurs": matériels sur lesquels sont implantées les différentes parties du logiciel • • process: les principaux programmes exécutés sur le processeur unités passives ("devices"): matériels qui n'hébergent pas le logiciel développé dans le projet (par exemple des routeurs.UML Page 13 .Analyse et modélisation Objet UML _______________________________________________________ 2.

qui seront vus plus loin. réunie en une transaction. 4. But: montrer en introduction au dossier d'analyse une vue très globale du rôle et de la place de l'application Contenu: on représente la future application comme une boite noire. en réponse à un évenement déclencheur venant d’un 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 é __________________________________________________________________________ Tarek EZZAT .UML Page 14 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 é . Les cas d’utilisation 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 définie par Jacobson Concepts Cas d’utilisation: un service (une fonctionnalité) attendu du système “ une fraction du comportement du système. et on représente les principaux échanges enter l'application et les utilisateurs (ou les autres applications) Exemple demande d'adh'ésion adhérent inscription à une activité cotisations reçues application comptable gestion des adhérents et activités défi nition des act ivit és tableaux de bord c lub 4. Le diagramme de contexte C'est une forme particulière des diagrammes de use cases ou des diagrammes de classes.Analyse et modélisation Objet UML _______________________________________________________ 3.1.

mais peut être une autre application Message ou événement le message en entrée déclenche un cas le message en sortie est le résultat du déroulement du cas Construction du diagramme => un cas d’utilisation comporte un acteur initiateur.Acteur: . il y a un ensemble d’événements qui peuvent survenir entre les acteurs participants et le système.c’est un objet extérieur au système . Analyse et modélisation Objet UML _______________________________________________________ __________________________________________________________________________ Tarek EZZAT . à partir de l’évenement déclencheur => le système est vu comme une boite noire pour chaque cas d’utilisation. et éventuellement un ou n acteurs participants ici Adhérer est initialisé par le (futur) adhérent => le cas d’utilisation figure l’ensemble des interactions qui peuvent survenir entre les acteurs et le système.c'est une entité physique (le service Comptabilité.UML Page 15 . le vérificateur) Noter: un acteur n'est pas forcément un acteur humain. le chef comptable) ou un rôle (le rédacteur.

Enrichissements possibles enregis trer une adhés ion relation "utilise" ("uses" ou "includes") < < inc lude> > __________________________________________________________________________ Tarek EZZAT ..le distributeur peut proposer plusieurs devises différentes Compléments. … Règles de gestion quelles sont les règles qui doivent être appliquées à ce cas par ex.3. entrer le code d'identification 3.: retirer de l'argent dans un distributeur automatique être classés par familles Acteur principal: celui qui initie la transaction. le chef de projet doit définir le mode de documentation choisi: ♦ documentation peu formelle une description informelle peut "raconter" en quelques phrases le déroulement 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 Catégorie les cas peuvent Par ex. "réserve de billets épuisée". ou le client suivant Exceptions quelles sont les erreurs qui peuvent être déclenchées? par ex. questions en attente… 4. déroulements (normaux) possibles autres que celui décrit. les cas doivent impérativement être décrits. etc. le distributeur est prêt à traiter la demande suivante du client. retirer de l'argent en choisissant la devise ou les coupures • variantes.UML Page 16 enr egis t rer un paiem ent . ici le porteur de la carte bancaire Acteurs secondaires: ceux qui participent à la réalisation du cas. ici.: limiter le montant distribué Préconditions dans quel état le système doit-il se trouver au début du cas? par ex. le distributeur a terminé le traitement du client précédent ou de l'opération précédente Postcondition dans quel état le système doit-il se trouver à la fin du cas? par ex. introduire la carte 2.Analyse et modélisation Objet UML _______________________________________________________ 4. observations. Documentation Le diagramme de cas d'utilisation ne suffit pas. questions en suspens commentaires. … 4.. par ex. le système central de gestion des cartes volées Description du cas décrire sous forme textuelle le déroulement du cas (de quelques lignes à une page ou plus) 1. Extensions et variantes • extensions (quels sont les cas qui étendent le cas décrit ici?). UML ne définit pas le mode de documentation des cas d'utilisation.: "transaction non autorisée". par ex.2. Si la démarche d'analyse attache de l'importance aux use cases.

UML Page 17 . à implémenter et à tester 2. on en tire la liste des scénarios à analyser. on définit une itération en termes de use cases implémentés par celle-ci 5.ou relation "étend" ("extends") un cas d’utilisation peut inclure (“ uses ”) d’autres cas Analyse et modélisation Objet UML _______________________________________________________ relation d'héritage un cas dérivé hérite de la signification et du contenu ( les opérations ) de son super-cas planifier une ac tivité planifier une ac tivité répétitive 4. analyser le ou les scénario(s) correspondant au déroulement normal du cas analyser les scénarios correspondant au déroulement anormal du cas 3. les cas listent les besoins à analyser. on s'en sert comme référence lors de la validation par les utilisateurs 4. on mesure l'avancement du projet en terme de nombre de use cases implémentés __________________________________________________________________________ Tarek EZZAT .4. on considère que les besoins ne peuvent pas être figés 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 méthodes font jouer un rôle d'organisation du projet aux cas d'utilisation ("use case driven analysis") dans cette approche 1. Rôle et place des cas d'utilisation Suivi de l'évolution des besoins dans certaines approches actuelles.

Analyse et modélisation Objet UML _______________________________________________________ 4.UML Page 18 . plutôt que les acteurs physiques ne pas définir comme acteurs des objets internes au système le temps peut-il être modélisé en tant qu'acteur? Ignorer les messages entre les acteurs externes Comment choisir les cas à analyser d'abord? commencer par les cas fréquents? ou par les cas difficiles? __________________________________________________________________________ Tarek EZZAT . Pièges et conseils Procéder par itérations Combien de cas d'utilisation? ne pas tomber dans un découpage trop fin (dit "découpage fonctionnel") Documenter chaque cas chaque acteur chaque message Les acteurs définir les acteurs logiques ou les rôles.5.

pour identifier les objets et ébaucher le diagramme de classes ...pour montrer les interactions entre les objets => diagramme de collaboration.. dont la classe n'est pas encore définie é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 dhérent 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 diplôm e : ..Analyse et modélisation Objet UML _______________________________________________________ 5. 5.) . plus loin dans ce chapitre.pour construire les diagrammes de séquence et d’interaction dans les étapes ultérieures . multiplicités.1. j udo : udo Act v Actiivititéé 5.UML Page 19 .pour valider le diagramme de classes (attributs.2. Diagrammes d’instances (ou d'objets) Concepts et construction Un objet est représenté par un rectangle qui contient soit le nom de la classe et celui de l'instance (séparés par un double point) soit le nom de la classe seulement soit le nom de l'objet. et dans la conception technique pour montrer la configuration d'un programme en conception technique et en rétroconception __________________________________________________________________________ Tarek EZZAT . Rôle et place des diagrammes d'instance dans l'étape d'initialisation de l'analyse .

distinction entre l'identifiant fonctionnel (n° de client. héritage. A dhér ent nom prénom num éroA dhérent ajouterA c tivité() c alc ulerCotis ation() habitudes d'écriture: majuscule au nom de classe Adherent minuscule au nom d'attribut nom. finalisation (multiplicités. Première définition d'une classe Chaque classe est représentée sous la forme d’un rectangle divisé en 3 compartiments. OID. ébauche du diagramme de classes trouver les classes que l'on utilisera pour construire les diagrammes de séquence 2.Analyse et modélisation Objet UML _______________________________________________________ 6. prenom minuscule et parenthèse pour d'une opération valider() majuscule à l'intérieur des noms composés calculerCotisation () Identifiants: . non entre les classes.1.un nom . ou "UML en action" (Roques et Vallée).UML Page 20 . n° de facture… connus des utilisateurs) et l'identifiant technique (adresse mémoire. etc. le second les attributs et le 3ème les opérations Une classe comporte . __________________________________________________________________________ Tarek EZZAT .éventuellement des règles ou contraintes.pas de formalisme pour représenter les identifiants.des comportements (les opérations) . Le 1er compartiment contient le nom de la classe. enrichissement à partir des diagrammes de séquence et des diagrammes d'état reporter les opérations et attributs découverts en construisant ces diagrammes 3.des attributs . ignorés pendant l'analyse) . il est construit par itérations pendant l'étape d'analyse 1.) l' "ébauche de diagramme de classes" est une notion de méthode définie par exemple dans OMT (Rumbaugh). unicité des noms d'attributs: à l'intérieur de la classe. Diagramme de classes Le diagramme de classes est le: diagramme central de la modélisation objet.l'identifiant fonctionnel est facultatif en conception objet . Une opération ou méthode implémente un comportement des objets de la classe. mais pas dans le guide d'utilidation d'UML 6. Un attribut: une information décrivant les objets de la classe.

elles vont être ajoutées dans la seconde phase de l'analyse.2. diagrammes de séquence…) Les contraintes liées aux outils ne sont pas prises en compte à ce stade la localisation physique des objets est ignorée les objets sont persistants autant que nécessaire pas de contraintes liées au langage Règles de simplification pour l'étape d'analyse __________________________________________________________________________ Tarek EZZAT . après avoir analysé les comportements (diagrammes d'activités. on ne représente généralement pas les opérations. et ignore les objets techniques les objets d'IHM (et les objets applicatifs en général) sont ignorés les objets techniques sont ignorés Dans un premier temps.2. Règles et étapes de construction Objets métier et objets techniques l'analyse doit être faite indépendamment des futurs choix techniques  l'analyse se limite donc aux objets métier.  L'ébauche du diagramme de classes Une ébauche de diagramme de classes Animateur nom emploie encadre Club propose activite utilise nom : String Adresse pratique possède adherent numero nom Salle numero : int 6.1. terme générique regroupant attribut ou opération Analyse et modélisation Objet UML _______________________________________________________ 6.UML Page 21 . Autre terme utilisés: propriété.Le même nom dans différentes classes doit (ou devrait) désigner la même nature d'opération (la même signification pour les utilisateurs du système).

. dans la même classe Un rôle décrit 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 __________________________________________________________________________ Tarek EZZAT . non à une action par ex.) mode d'implémentation des associations (pointeurs?.. "structurel" entre deux objets du point de vue technique une association est un chemin d’accès entre les instances d’une classe et les instances de l’autre Nommer les associations: ce n'est pas obligatoire si la signification est claire plusieurs associations (entre des paires d'objets différents) peuvent porter le même nom essayer de donner un nom qui se réfère à la durée.on fait des hypothèses simplificatrices concernant la manipulation des objets les attributs sont "publics en lecture" il est toujours possible d'accéder à 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 sûr abandonnées lors de la conception technique et des compléments seront ajoutés au modèle: visibilité des propriétés (privé... Première définition 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 adhérent est membre du club l'animateur encadre une activité un adhérent peut être l'enfant d'un autre adhérent (et cela a une importance pour notre analyse ) . plutôt que Adherent "s'inscrit à" Activité Il peut y avoir plusieurs associations différentes entre deux mêmes classes  vérifier au niveau des instances qu'il s'agit bien de deux associations différentes A ni m ateur enc adre p lanifie A c ti vi té Une association peut être réflexive d'une instance vers une autre.UML Page 22 .. public. Adherent "participe à" Activité.) etc..1.1. du point de vue de la signification ou du contenu ("sémantique") une assocoation est un lien durable.2.. Analyse et modélisation Objet UML _______________________________________________________ 6.

une classe peut être créée pour structurer des comportements. que pas assez pour éclater ensuite un objet en deux objets distincts Attention aux objets cachés Adhérent nom possède Adresse ou Adhérent nom adresse et aux associations cachées Adhérent nom activité pratiq uée __________________________________________________________________________ Tarek EZZAT . pour éliminer ensuite.. Quelques exemples de ternaires un véhicule appartient au titulaire de la carte grise plusieurs conducteurs habituels peuvent être déclarés pour un véhicule un véhicule est couvert par un contrat d'assurance. pour les "merisiens". qui doit couvrir tous les conducteurs habituels les développeurs sont affectés aux projets en cours les développeurs utilisent les AGLs pour réaliser les projets Adhérent pratiq ue Anim ateur Activ ité 6..Analyse et modélisation Objet UML _______________________________________________________ Associations ternaires: (ou n-aire): relie plus de deux classes. Candidats objets: plutôt trop de candidats objets.3.une entité peut se décomposer en plusieurs classes (classe Adhérent et classe Adresse) . ⇒ toujours vérifier si l'association ne peut pas être décomposée.une classe peut regrouper plusieurs entités (relation maitre-détail par exemple) . Pièges et conseils Découverte des objets un objet possède des états et des comportements Une classe est une abstraction qui regroupe les objets semblables tous les objets d’une classe partagent le même comportement et les mêmes attributs Par rapport aux entités. .UML Page 23 .

caractère.) __________________________________________________________________________ Tarek EZZAT .UML Page 24 .etc..on continue l'analyse avec les diagrammes d'activité.5.arbre d'agrégation . des interfaces (java). Le diagramme de classes finalisé Qu'est-ce qu'un diagramme de classes "finalisé"? • en fin d'analyse les attributs d'instance sont définis les opérations sont définies et documentées les associations sont définies.4.des classes abstraites.associations entre classes . on pourra générer le diagramme de classes complété à partir de ce qu'on aura codé (rétro-conception) . 6. des méthodes abstrtaites pures (C++) . de séquence puis on enrichit les classes à partir de ce qu'on a découvert en élaborant ces diagrammes 6. avec leurs attributs éventuels et les multiplicités héritages définis Question de présentation: on peut faire plusieurs diagrammes pour représenter plusieurs points de vue sur les classes: . à la base de données…) . Finalisation des attributs Les types des attributs: un type de base (numérique. d'états.5.des classes techniques (classes d'accès au réseau.arbre d'héritage des classes . l'acteur "utilisateur" et l'image de l'utilisateur dans le système.on génère les squelettes de classes à partir du diagramme de classes et on commence à coder plus tard. • en fin de conception technique on trouvera en plus . L'enrichissement du diagramme de classes L'enrichissement peut se faire de 2 façons ..1. 6.des attributs et méthodes statiques .liste des classes avec le détail de leurs propriétés .etc.Analyse et modélisation Objet UML _______________________________________________________ Ne pas confondre l'acteur et l'objet qui le représente: par ex.

Récursivité: une agrégation peut être récursive.2.un type défini pour les besoins du modèle une liste.: un véhicule. il est indispensable de donner un no de rôle à chaque extrémité de l'association 6. Dans ce cas.les propriétés des composés ont un sens pour les composants .* 1 anim e Activité Choix entre attributs de lien et attributs des objets liés: __________________________________________________________________________ Tarek EZZAT . un tableau. ici . les droits sont définis pour un type d'utilisateur et pour un type de fichier Anim ateur 1. .sa valeur par défaut par exemple: prix: décimal = 100 Attribut dérivé: attribut calculable à partir des autres attributs de l'objet.la durée de vie des composants est souvent dépendante de celle du composé. un ordinateur.1.. etc.2. Détail d'un attribut: .son type . PC L’agrégation Relation composé-composant entre des objets la classe d'assemblage contient les objets composés la classe de composant contient les objets composés.5.UML Page 25 .5.2.les opérations sur le composé affecteront souvent les composants. Par ex.2. clavier Par rapport à une association. Compléments sur les associations 6.. Attributs d’associations date début E lem e nt + c om pos ant c ontient + c om pos é Les attributs de lien décrivent l'association: exemple: Les utilisateurs manipulent des fichiers.. est composé d'éléments Parfois désignée par "has a" (par opposition à "is a" pour l'héritage).5. etc. Analyse et modélisation Objet UML _______________________________________________________ 6.

Symboles utilisés par la méthode unifiée: Anim ateur 0. ou que l'information dépend de l'association entre deux objets (ce sera un attribut de l'association) ⇒ la signification du modèle est différente si les droits sont un attribut du fichier et s'ils sont un attribut de l'association fichier <-> utilisateur 6...1 anim e Activ ité il y a 0 ou 1 animateur pour une activité Anim ateur 0..3.2 Activ ité __________________________________________________________________________ Tarek EZZAT . Multiplicités Analyse et modélisation Objet UML _______________________________________________________ Multiplicité: définit combien d'instances de la classe peuvent être connectées à une seule instance de la classe associée => la notation est placée à l'opposé de celle des cardinalités dans Merise.* anim e 1 Activ ité il y a 1 à n animateur(s) pour une activité.UML Page 26 ..3 anim e 1. et 1 à 2 activité(s) pour un animateur Anim ateur 1.5. et une seule activité pour un animateur il y a 1 à 3 animateur(s) pour une activité.* anim e Activ ité il y a 0 à n animateur(s) pour une activité Anim ateur 1.2.Attention : selon que l'information dépend de l'un des objets (ce sera un attribut de l'objet)..

nom.6.6. avec des particularités modifiant ou complétant ces propriétés.5. E nfant taux Réduc tion c alc ulerCotis ation() L'héritage multiple: cas où un objet appartient à plusieurs arbres d'héritage simultanément. prénom.et. en propre. parce qu'il hérite de Personne . état civil.UML Page 27 .  arborescence des classes (relations d'héritage) et opérations  les classes et leurs associations  l'ensemble des classes d'une catégorie  etc. Plusieurs diagrammes de classe Rôle 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.3. Plusieurs niveaux d'héritage sont possibles. L'héritage Définition: dépendance entre deux classes selon laquelle une classe (la sous-classe) possède les mêmes propriétés qu'une autre (la super-classe). 6. __________________________________________________________________________ Tarek EZZAT . comme les attributs et opérations Exemple un adhérent possède les attributs . ⇒ ne pas oublier: la relation d'héritage transmet les associations. un numéro un adhérent possède en plus un attribut taux de réduction la méthode calculerCotisation() figure dans Adhérent et dans Enfant ⇒ la méthode de calcul sera différente dans la super-classe (Adhérent) et dans la sous-classe Analyse et modélisation Objet UML _______________________________________________________ P ers onne nom pr énom ét atCi vi l m ajEt atCi vi l() Ad hérent num éroA dhérent c alc ulerCotis ation() ajouterA c tivité() partic ipe A c tivité nom des c ription Rappels: la généralisation/spécialisation est le mécanisme de conception par lequel on rattache une sous-classe à une super-classe.

1.pour décrire le déroulement d'un use case représentation des étapes d'exécution du use case et des différents enchaînements possibles .l’activité et est un traitement est interruptible enreg istrem ent adhésion - le début et la fin du processus enreg istrem ent adhésion données correctes? enreg istrem ent adhésion validation .Analyse et modélisation Objet UML _______________________________________________________ 7.dans la documentation d'une classe.BPM (business process modeling).pour représenter les activités parallèles et les synchronisations 7.pour représenter l'action du processus sur les objets .UML Page 28 . 7.3.les conditions : (appelées aussi gardes) avec le losange [ oui ] validation ou sans [ OK ] [ NOK ] [ non ] rej et validation 7.pour modéliser un processus administratif . Concepts de base du diagramme d’activité la transition est instantanée (pas de durée) est automatique (déclenchée par la fin de l'activité) .pour représenter le rôle des différents acteurs dans le processus (diagramme d'activités à couloirs d'activités) .représentation de l'organisation administrative actuelle ou future et de l'impact du projet sur l'organisation du travail des utilisateurs .2. Diagramme pour représenter un algorithme d'activité rej et c'est la forme la plus simple du diagramme d'activité __________________________________________________________________________ Tarek EZZAT . Diagrammes d’activité Rôle et place des diagrammes d’activité Rôle: un diagramme d'activité présente le déroulement logique et chronologique d'un processus (informatique ou non) Utilisation: les diagrammes d'activité peuvent être utilisés à des étapes diverses de l'analyse . pour expliciter l'algorithme d'une méthode complexe Les diagrammes d'activité peuvent prendre des formes variées .pour représenter un algorithme . BPR (business process reengineering) .

départements de l'entreprise…) qui interagissent avec le logiciel 2 couloirs peuvent représenter 2 parties de l'application qui dialoguent (le client et le serveur par exemple) chaque couloir peut aussi représenter un objet c'est une forme adapté à la représentation de l'organisation administrative et de l'impact du projet sur cette organisation __________________________________________________________________________ Tarek EZZAT .UML Page 29 . et les autres couloirs pour représenter les acteurs (utilisateurs. Diagramme d'activités à couloirs d'activités le c a ndida t : a dhé re nt : a c c ue il c lub : c om pta c lub dans la modélisation d'un processus .4. un couloir d'activité (swimlane) est souvent utilisé pour représenter un acteur responsable d'une activité établi r c hèqu e vérifier on peut utiliser un couloir m ettre à l'enc ais s em ent pour représenter le logiciel.Analyse et modélisation Objet UML _______________________________________________________  c'est la même chose qu'un ordinogramme  cela permet par exemple de dessiner l'algorithme d'un use case ou d'une opération Important: le diagramme d'activité est le seul modèle dynamique qui permette facilement de zoomer il permet de donner une vue d'ensemble d'un processus (avec des macro-activités) puis de détailler 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 séquences 7.

UML Page 30 . Représentation avec les objets utilisés comme dans le diagramme d'objets. lecture du contenu des objets) enregi strer les info s s ur l'adhér ent : A dhes ion [inc om plète] [ données inc om plètes ] : A dhes ion [c om plète] : Tarif [ ok ] c om pléter il n'est pas nécessaire de faire figurer tous les objets l'état des objets peut être précisé mo ntant s elon c atég ce peut être une préparation aux diagrammes de séquence et aussi une façon de commencer à analyser les états (que l'on va voir à l'étape suivante avec les diagrammes d'état-transition. les rectangles représentent des objets ou instances (pas des classes) les objets peuvent être des instances des "candidats objets" définis dans début de l'enregis trem ent l'ébauche du diagramme de classes les flèches continues représentent le "flot de contrôle" (la logique d'enchaînement des opérations) les flèches pointillées représentent les "flots de données" (création.5. c alc uler la c oti sat ion __________________________________________________________________________ Tarek EZZAT .Analyse et modélisation Objet UML _______________________________________________________ 7. modification.

2.6. un état a une durée [ ok ] [ données inc om pl ètes ] un état attente infos c om pléme ntai res do/ relanc er ex pir ation délai réc eption infos m anquantes c alc uler la c otis ation ab andon un état peut être actif: . Synchronisation appelées aussi "fork et "join".Analyse et modélisation Objet UML _______________________________________________________ 7.ou bien il peut être à l'écoute et réagir lorsqu'un événement se produit (par exemple un socket serveur.UML Page 31 . ils représentent des conditions "et" Ils peuvent servir . 7. à modéliser des processus administratifs qui s'exécutent simultanément . Quelques précisions 7. Activité ou état? une activité enregis trer les infos s ur l'adhérent une activité est instantanée (pas de durée. à représenter un programme multithread encaissem ent cotisation enreg istrem ent adhésion choix m ode de paiem ent calcul cotisation sélection activités __________________________________________________________________________ Tarek EZZAT . ou simplement la production d'un message ou événement en réponse.au niveau de la modélisation d'un programme.l'objet qui est dans cet état peut faire un traitement pendant le temps où il est dans l'état représenté (par exemple envoyer des messages périodiques pour savoir si une liaison n'est pas tombée) .6.au niveau de l'analyse des processus. à l'échelle de temps du logiciel modélisé) par opposition à une activité. en attente de demande de connexion par les clients) la réaction à l'événement peut être la sortie de l'état.1.6.

Analyse et modélisation Objet UML _______________________________________________________ 8. 8. il est sans doute préférable de commencer par les diagrammes d'activités. Diagrammes d'interaction. __________________________________________________________________________ Tarek EZZAT .1.UML Page 32 . et de réserver les diagrammes d'interaction à la fin de l'analyse ou à la conception technique. définition des opérations Deux formes de diagrammes d’interaction Objectif des diagrammes d’interaction: montrer les échanges de messages ou les appels de méthodes entre les objets Formes: chronologique: diagramme de séquence (ou scénario) => pour visualiser l’enchainement des événements à partir d’un événement déclencheur Un diagramme de séquence : A dherent toto : adhérent 1: dem ande de partic ipation ac tivité dem andée : A c tivite 2: pl ace dis ponible? 3: oui 4: dem ande ac c eptée 1: dem ande de partic ipation topologique: diagramme de collaboration => pour montrer la place et le rôle de chaque objet Un diagramme de collaboration : A dherent 4: dem ande ac c eptée toto : adhérent 3: oui ac tivité dem andée : A c tivite 2: plac e dis ponible? Place des diagrammes d'interaction Les diagrammes de séquence ou de communication sont plus difficiles à élaborer qu les diagrammes d'activités ils sont aussi moins intuitifs (me semble-t-il) ils supposent que les objets aient déjà été définis avec précision Pour toutes ces raisons.

Analyse et modélisation Objet UML _______________________________________________________ 8. __________________________________________________________________________ Tarek EZZAT . et les réponses du système  on ne prétend pas construire une liste exhaustive des scénarios toto : adhérent 1: dem ande de participation 2: place disponible? 3: oui 4: aj outer participant 5: dem ande acceptée : Adherent activité dem andée : Activite Un exemple (simplifié) : un adhérent demande à s'inscrire à une activité supplémentaire 8.UML Page 33 . Premiers concepts et construction Acteur extérieur et événement déclencheur un scénario est généralement déclenché par un acteur extérieur (voir les cas d’utilisation). il peut faire intervenir d'autres acteurs pendant son déroulement il peut se terminer par un envoi de réponse (ou plusieurs) aux acteurs Instances d’objets => un scénario représente des occurences d’objets. Diagrammes de séquence (scénarios) Le but des diagrammes de séquence: Un diagramme de séquence représente un déroulement possible d'un cas d'utilisation. pas des classes => une même classe peut être représentée par plusieurs instances Evénements (ou messages) l’acteur et les objets communiquent par une succession de messages Opération l'arrivée d'un message vers une instance d'objet déclenche une opération Chronologie le diagramme de séquence présente les événements dans leur ordre d’apparition. Le scénario représente une des séquences possibles à partir de l'événement déclencheur du cas d'utilisation.2.1.2.

une contrainte se représente par un texte {entre accolades} ou [entre crochets] __________________________________________________________________________ Tarek EZZAT . enddo et toutes les structures équivalentes Exemples de méthodes pour représenter des conditions ou des branchements: (seulement si c’est nécessaire à la bonne compréhension du modèle) une alternative (condition) exemple l'adhérent veut s'inscrire à une activitéselon qu'il y a de la place disponible ou non... else.UML Page 34 .Analyse et modélisation Objet UML _______________________________________________________ Structures de contrôle Les “ structure de contrôle ”: alternative: if. "demande de participation") par un trait continu et les réponses (par ex. endif répétititve: while... r é u n io n c o n v o c a tio n Valeurs retournées on peut distinguer les questions (par ex. 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 ... la suite est différente UML 2 propose d'utiliser des "cadres d'interaction" pour faire ressortir ainsi les choix (appelés "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 répétitive (boucle) P é ta n q u e : A c t iv it é :A d h é re n t envoyer une convocation à chaque adhérent pqui participe à l’activité noter la représentation de plusieurs instances d’Adhérent : A n im a t e u r : A d h é re n t c o n v o c .. "demande acceptée") par un trait pointillé Contraintes Dans tous les modèles... do.. then.

UML Page 35 . adresse 2. il faut définir les opérations déclenchées sur chaque classe  dans le cas le plus simple.. Retour sur le polymorphisme un événement peut comporter différentes séries de paramètres : par ex. adresse. év énem ent (param 1. chèque joint 3. Passage des messages aux opérations Définition des opérations Pour exploiter les diagrammes de séquence. avec nom. etc.) : résultat __________________________________________________________________________ Tarek EZZAT .8. date de naissance.2.2. il s'agit de remplacer les messages par les opérations déclenchées par ces messages  et de distinguer les messages déclencheurs d'opérations des messages retournés en résultat Analyse et modélisation Objet UML _______________________________________________________ Paramètres des opérations et valeur retournée Les paramètres décrivant l’événement peuvent être portés sur le diagramme Le nom et/ou la valeur du message en retour peuvent être ajoutés à l’événement envoyé. avec nom.. une demande d’adhésion 1. param 2.

2. terme2: réel) : réel . .les valeurs par défaut des arguments par exemple dessiner(CouleurFond: couleur = blanc.1. Analyse et modélisation Objet UML _______________________________________________________ Enrichissement du diagrammes de classes Une fois les opérations définies. l'enrichissement du diagramme de classes consiste à • reporter dans chaque classe les opérations définies • trouver les attributs nécessaires à l'exécution de ces opérations • valider le résultat.la suppression de l’appel de cotisation correspondant : P aiem ent im puter (Paiem ent ) supprim er ( ) __________________________________________________________________________ Tarek EZZAT .8. du point de vue des classes et non plus des scénarios Notation dans le diagramme de classes le détail d'une opération (appelé sa signature) peut comporter . CouleurTrait: couleur = noir) : booléen => permet des appels à la même méthode avec un nombre variable d’arguments.la création d’une instance de paiement enreg istrem ent paiem ent .3.2.2.les arguments attendus et le type de la valeur retournée par exemple ajouter(terme1: réel. dateEffet : Date) : boolean 8. Naissance et disparition d’un objet le diagramme peut représenter la durée de vie de l’objet (du début d’une ligne verticale à sa fin) l’arrivée du paiement de l’adhérent provoque adhérent toto : Adhérent : Appel de cotis.UML Page 36 . Une classe avec l'affichage des opérations et de leur signature Adherent numéroAdhérent calculerCotisation(dateEffet : Date) : int ajouterActivité(nouvelleActivite : Activite) : boolean ajouterActivité(nouvelleActivité : Activite.

UML Page 37 . Forme da la documentation: un commentaire attaché au scénario ou un commentaire attaché à l'opération dans le diagramme de classes l'AGL peut créer la documentation du code généré à partir de ce commentaire ou le pseudo-code de l'opération ou un diagramme d'activités toto : Adhérent adhérent enreg istrem ent paiem ent Analyse et modélisation Objet UML _______________________________________________________ : P aiem ent im puter (Paiem ent ) vérif ier les réf érences (n° et date ) par rapport à l' appel de cotisation - __________________________________________________________________________ Tarek EZZAT .2. il faut documenter chaque opération.4. Documentation des opérations Les diagrammes de séquence ne donnent que le squelette d’une séquence d’opérations.8.

UML Page 38 .se basent sur la représentation des instances d’objets (les diagrammes d’instances) .Analyse et modélisation Objet UML _______________________________________________________ 8. Cependant une notation est prévue (à consommer avec modération : on préférera pour cela les diagrammes de séquence ) Représentation générale des contraintes Une contrainte peut être représentée par un texte libre entre accolades. adhérent dm de inscrip activ ité un Adherent une Activité inscription dm de supplém ent cotis ation paiem ent dm de inscrip activ ité paiem ent adhérent un Adherent inscription  un scénario peut être facilement transformé en diagramme de collaboration dm de supplém ent cotisation une Activité  un diagramme de collaboration montre le flot des messages entre les instances d’objets  plusieurs messages peuvent figurer sur un lien entre deux objets Remarques Représentation de la chronologie ce n’est en principe pas le but du diagramme de collaboration. . Diagrammes de collaboration Diagrammes de séquence et diagrammes de collaboration sont équivalents: les deux types de diagrammes représentent la même information.3. comme les diagrammes de séquence. comme dans les autres modèles Création et destruction d’instances d’objets: la création ou la destruction d’une nouvelle instance d’objet est notée comme une contrainte __________________________________________________________________________ Tarek EZZAT .et représentent les évenements ou messages entre ces objets. Les diagrammes de collaboration.

4.1.UML Page 39 . Pièges et conseils Jusqu'à quel niveau détailler les scénarios? Faire des variantes d'un scénario. "bons" et "mauvais" scénarios Il y a plusieurs façons de traiter le même cas d'utilisation Le but: fabriquer des objets utilisables Exemple enregistrement d'une demande d'adhésion : Club : adhérent 1: dem ande d'adhés ion : Adh erent : A dherent : adhérent ou 1: c réer 2: affec ter num éro 2: rec herc he proc hain num éro 3: c réer 4: num éro attribué 3: num éro attribué  placer les opérations sur les bons objets  il y a probablement des diagrammes plus justes que d’autres __________________________________________________________________________ Tarek EZZAT . ou utiliser les structures de contrôle (si… sinon…) dans un scénario unique? Comment montrer l'appel d'un scénario par un autre? 8.Analyse et modélisation Objet UML _______________________________________________________ 8.4.

UML Page 40 . Comparaison de deux solutions plus globales Analyse et modélisation Objet UML _______________________________________________________ un scénario “ centralisateur ” un Paiement un Appel de cotisat.4. rég lée enreg . compte Trésorerie un Adhérent adhérent paiem ent cotis.8. paiem ent cotis. cotis. encaissem ent accusé de réception un scénario “ décentralisateur ” un Paiement un Appel de cotisat. annuelle enreg . annuelle identif ication Adh. crédit accusé de réception __________________________________________________________________________ Tarek EZZAT . un Adhérent compte Trésorerie adhérent paiem ent cotis. rég lée enreg .2.

Les diagrammes états . selon qu'il est membre actif ou résilié Une transition rés i liat ion la matérialisation d'un état: la valeur d'un attribut.transitions Premiers concepts et construction Définition: le modèle dynamique représente les modifications des objets dans le temps Un diagramme appartient à une classe et une seule  définit les états possibles pour les instances de la classe le diagramme peut représenter aussi les interactions entre les objets de classes différentes. ou d'un ensemble d'attributs.Analyse et modélisation Objet UML _______________________________________________________ 9.1. selon que son contenu a été ac tif modifié ou non .demander la fermeture d'une fenêtre. Création d'une instance de m ande d'a dhés ion Un événement ac tif Suppression d'une instance rés ilié c l ôtur e exerc ic e __________________________________________________________________________ Tarek EZZAT . 9. Concepts utilisés Etat: configuration d'un objet.renouveler l'adhésion d'un membre du club à l'échéance annuelle. conditionnant le type de réponse de l'objet à un certain événement exemples .UML Page 41 . en fait permanent jusqu'à l'arrivée d'un nouvel événement. la présence ou le contenu d'une association rés ilié Un état Transition: passage d'un état à un autre Evénement: modification intervenue dans l'environnement et que l'objet doit prendre en compte L'événement déclenche la transition durée: un événement est "instantané" un état est durable.

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 définit pas une séquence unique  il peut y avoir des boucles. plusieurs circuits.UML Page 42 .2.Analyse et modélisation Objet UML _______________________________________________________ 9. La logique et la signification du diagramme d'états états de l'Adhérent demande d'adhésion un exemple: les états possibles d'un adhérent résiliation actif radiation résilié complément d'info demande incomplète demande de suspension suspend u réactivation clôture exercice en instance noter: abandon • les transitions sont orientées (des flèches. plusieurs points de création et / ou suppression des instances  il n'y a pas toujours des points de création et / ou suppression des instances un diagramme d'états représente tous les états possibles des instances de la classe  toutes les instances ne passeront pas par tous les états • __________________________________________________________________________ Tarek EZZAT .

l'objet peut être dans deux ou plusieurs sous-états  le super-état définit une partie du comportement  le sous-état précise ce comportement La transition peut se faire de ou vers le super-état.3. Quelques éléments de modélisation complémentaires 9.2. Transition sans changement d'état Si cela éclaire l'analyse. Sous-états A l'intérieur d'un état. ou bien de ou vers le sous-état ouverte ouverte non planif iée créer planif ier planif iée ouvrir suspendre suspendue suspendue supprim er 9.3.3.1.Analyse et modélisation Objet UML _______________________________________________________ 9.3.3.UML Page 43 . Condition sur une transition Un même événement peut déclencher deux transitions différentes en fonction d'une condition  la condition est notée sur la transition (transition gardée) actif complément d'info[ délai respecté ] en instance complément d'info[ délai non respecté ] 9. on peut noter des transitions d'un état vers lui-même faute[ moins de 3 ] dehors à la troisième faute: surle t errain faute[ troisième ] sur la touche __________________________________________________________________________ Tarek EZZAT .

combinaison d'attributs . les états successifs d'une facture. pour un processus de facturation et d'encaissement  modéliser ces états tôt dans l'analyse  le diagramme d'états peut servir à structurer le reste de l'analyse __________________________________________________________________________ Tarek EZZAT . les objets de toutes les classes possèdent des états .valeur d'une association .5.Analyse et modélisation Objet UML _______________________________________________________ 9. Enrichissement du diagramme de classes Conséquence des états sur la définition des opérations deux états  deux comportements  une condition dans la définition d'une opération Conséquence sur la définition des attributs l'état doit être matérialisé: .ils peuvent être discutés avec les utilisateurs (pour les objets que ces derniers connaissent) .en théorie.4.UML Page 44 .ils servent au moins à vérifier l'exhaustivité et la cohérence de l'analyse ils peuvent avoir un rôle de découverte et de structuration: certains objets ont des états connus des utilisateurs.code état 9.plage de valeurs d'un attribut .en pratique seules les classes où au moins 3 états sont identifiables méritent un diagramme Quand faire les diagrammes d'états? les diagrammes d'états ont un rôle de validation: . états qui servent même à organiser le travail (le "workflow"). par ex. Rôle et place des diagrammes d'états Quels diagrammes d'états faut-il faire? .

et gros domestique / client étranger? L'héritage du diagramme d'états n'est pas automatique les états des objets de la sous-classe ne sont pas forcément ceux de la super-classe les états sont implémentés dabs les opérations. les objets de la sous-classe héritent des opérations de la super-classe. ou deux sous-classes de la même classe? par ex. Pièges et conseils Jusqu'où aller dans la modélisation des états? il y a beaucoup de choses qui peuvent être représentées dans un diagramme d'état  se limiter à ce qui est nécessaire pour le but recherché  et à ce qui est compréhensible de tous Pas (ou pas toujours ) de "code état" pour représenter les états d'un objet Limite entre les états et l'héritage: le même objet dans deux états. dans l'implémentation.Analyse et modélisation Objet UML _______________________________________________________ 9.6. et.UML Page 45 . sauf si on les surcharge  en pratique.bon client / client douteux : deux états ou deux sous-classes avec des règles de gestion différentes ? . . les états sont hérités par défaut __________________________________________________________________________ Tarek EZZAT .

regrouper les cas d'utilisation par exemple les regrouper selon l'utilisateur principal concerné.stocks s to c k s f o u r n is s e u r s . Diagramme de packages Les packages servent à regrouper les éléments par famille quand le projet grossit .regrouper les classes par problème 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 hiérarchisés: ici logistique logistique.Analyse et modélisation Objet UML _______________________________________________________ 10. ⇒ les packages dépendent d'autres packages (ils utilisent les éléments définis dans d'autres packages ici stocks utilise fournisseurs __________________________________________________________________________ Tarek EZZAT . .UML Page 46 . ou par domaine .

étude de faisabilité et/ou d'opportunité on peut utiliser pour cette étape un diagramme de contexte pour dessiner le périmètre du projet UML dans la conception technique générale on précise dans cette étape les choix techniques (langages. Récapitulation On essaie ici de récapituler l'utilisation d'UML dans chaque phase du projet Ceci est largement une question d'opinion personnelle Ceci dépend aussi beaucoup de la nature du projet Dans la définition des besoins et l'étude préalable Définition des besoins UML intervient peu à ce stade son rôle se limite la plupart du temps au diagramme de cas d'utilisation on peut aussi utiliser un outil pour répertorier les besoins ⇒ une feuille de tableur suffira la plupart du temps pour lister les besoins. on rentre là dans l'utilisation avancée d'UML __________________________________________________________________________ Tarek EZZAT .définition du domaine (définition du périmètre du projet) .Analyse et modélisation Objet UML _______________________________________________________ 11. leur statut actuel.UML Page 47 . de séquence…) pour présenter ces standards. la référence des documents de description il existe aussi des outils spécialisés (par exempleRequisite Pro de Rational) Etude préalable: . conceptions génériques du 2 tracks process…) on pourra utiliser des diagrammes (de classes. modèles de conception –design patterns-. d'activité. modes de stockage…) on définit l'implantation physique dans un diagramme de déploiement on peut montrer le découpage 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.

pour définir les classes le diagramme de use cases et la documentation des use cases les diagrammes d'activité et/ou les diagrammes de séquence les diagrammes d'états Les phases de l'analyse L'analyse est en général un processus itératif.UML Page 48 . on va prendre une vue générale • des modèles utilisés pour l'analyse • des phases de l'analyse et de l'enchaînement entre ces modèles à l'intérieur d'une phase Les diagrammes que l'on utilisera le plus souvent seront le diagramme de classes. qui synthétise 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 ière ébauche ] cas d'utilisation premiers diag ramme d'états premiers diag ramme de séq uence (scénarios) découverte des interactions diag ramme de classes [ avec opérations et attributs ] autres diag ramme d'états autres diag ramme de séq uence finalisation de l'analyse diag ramme de classes [ f inalisé ] __________________________________________________________________________ Tarek EZZAT . ceci est particulièrement vrai en conception objet et avec UML: L'analyse centrée sur l'élaboration et l'enrichissement progressif d'un diagramme de classes.Analyse et modélisation Objet UML _______________________________________________________ UML dans l'analyse métier Avant d'entrer dans le détail de la démarche d'analyse avec UML. impérativement.

ou par des diagrammes d'activité.dessiner un diagramme d'activité (si le cas est complexe.les besoins fonctionnels sont répertoriés .vérifier que les opérations définies (probablement dans les diagrammes de séquences) implémentent bien toutes les transitions figurant sur le diagramme d'états __________________________________________________________________________ Tarek EZZAT . attributs) à travers la réalisation de chaque use case sous la forme d'un scénario Comment? Dans une approche formalisée (type méthode Unified Process) .) et/ou des diagrammes de séquences (un par enchaînement possible) .on ne découvre plus de nouveaux use cases .UML Page 49 .prendre une à une toutes les classes pour chaque classe qui semble posséder plus de 2 états: . etc.prendre un à un tous les cas d'utilisation pour chaque cas d'utilisation: . etc.Analyse et modélisation Objet UML _______________________________________________________ L'initialisation de l'analyse Quand? lorsque les objectifs sont clairs .) Quoi? définir la responsabilité et le contenu de chaque classe (opérations.définir le diagramme d'états .les use cases sont compris et décrits (textuellement.le périmètre du projet est défini et lorsque la phase d'étude de faisabilité / d'opportunité apparaît terminée: le projet est réalisable (dans les enveloppes de temps et de budget) et rentable Quoi? donner une première description des fonctionnalités prévues et des objets qui y concourront Comment? en définissant les cas d'utilisation éventuellement en décrivant ces cas dans des diagrammes d'activités en recherchant les classes métier possibles (ébauche du diagramme de classes) Les itérations d'analyse Quand? lorsque la phase d'initialisation apparaît terminée: . comporte des variantes.

décrire la réalisation de ces use cases . en croisant les doigts.Dans les approches agiles on codera directement à partir des squelettes de classes. .construire les diagrammes de séquence (scénarios) pour .on choisira une solution d'implémentation (si possible un design pattern éprouvé) ceci sera abordé dans le cours UML avancé Dans notre approche intermédiaire .les modèles dynamiques doivent reprendre les cascades d’événements définies dans les scénarios.on fera si nécessaire une maquette d'architecture .on définira les responsabilités des objets .enrichir le diagramme de classes à partir des scénarios La finalisation de l'analyse Quand? lorsque le cycle d'analyse apparaît terminée: Quoi? vérifier la cohérence de l'analyse compléter la définition des classes et des associations définir les relations d'héritage compléter la documentation du dossier Comment? pas de nouveaux diagrammes mais une révision générale Cohérence entre les diagrammes Principe de la cohérence: .aval: les événements émis par le modèle à destination d’autres objets sont-ils repris dans le modèle dynamique des objets concernés? __________________________________________________________________________ Tarek EZZAT . ou les attributs de leurs objets associés) Vérifications: . ou bien .la spécification des opérations doit être cohérente avec les contraintes découlant du diagramme d’états .choisir les use cases à analyser en priorité .UML Page 50 Analyse et modélisation Objet UML _______________________________________________________ .les états doivent être décrits par les attributs des objets (ou leurs associations.amont: où sont générés les événements qui provoquent les transitions décrites dans le modèle en cours d’examen? .

__________________________________________________________________________ Tarek EZZAT . on établit le diagramme de classes finalisé On peut l'établir en ajoutant des détails au modèle d'analyse.UML Page 51 . pendant l'implémentation Certains outils permettent de synchroniser automatiquement le code que l'on développe et le diagramme que l'on enrichit. avant de générer les squelettes de classes On peut aussi l'établir par rétro-conception à partir du code.Cohérence entre diagrammes de séquence et diagrammes d'états Représentent deux vues de la vie des objets  doivent s'appuyer sur la même logique. le même enchaînement Les événements des diagrammes d'états doivent se retrouver dans les diagrammes de séquences Les conditions posées au déroulement des opérations dans les diagrammes d'états doivent se retrouver dans la documentation des opérations exemple FenetrePrincipale Analyse et modélisation Objet UML _______________________________________________________ :Fenêtre P rincipale fermer ( ) fermer ( ) :FenêtreFille Fenetre fenetreFii l le fermer ( ) FenetreFille OK / nonOK f erm er ( ) : booleen m odif iée sauvegarder non m odif iée entrer données UML dans la conception technique détaillée et la réalisation Dans la conception technique détaillée.

Sign up to vote on this title
UsefulNot useful