Suche senden
Hochladen
CoursUML-SlimMesfar-Total
âą
2 gefÀllt mir
âą
4,393 views
A
Ahmed Mekkaoui
Folgen
Melden
Teilen
Melden
Teilen
1 von 323
Jetzt herunterladen
Downloaden Sie, um offline zu lesen
Empfohlen
Tp3 - UML
Tp3 - UML
Lilia Sfaxi
Â
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de Conception
Lilia Sfaxi
Â
Chp3 - Diagramme de Classes
Chp3 - Diagramme de Classes
Lilia Sfaxi
Â
Chp2 - Diagramme des Cas d'Utilisation
Chp2 - Diagramme des Cas d'Utilisation
Lilia Sfaxi
Â
introduction à la modélisation objet
introduction à la modélisation objet
Amir Souissi
Â
Merise
Merise
basy15
Â
Chp5 - Diagramme d'Etat Transition
Chp5 - Diagramme d'Etat Transition
Lilia Sfaxi
Â
Cours uml
Cours uml
zimamouche1
Â
Empfohlen
Tp3 - UML
Tp3 - UML
Lilia Sfaxi
Â
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de Conception
Lilia Sfaxi
Â
Chp3 - Diagramme de Classes
Chp3 - Diagramme de Classes
Lilia Sfaxi
Â
Chp2 - Diagramme des Cas d'Utilisation
Chp2 - Diagramme des Cas d'Utilisation
Lilia Sfaxi
Â
introduction à la modélisation objet
introduction à la modélisation objet
Amir Souissi
Â
Merise
Merise
basy15
Â
Chp5 - Diagramme d'Etat Transition
Chp5 - Diagramme d'Etat Transition
Lilia Sfaxi
Â
Cours uml
Cours uml
zimamouche1
Â
diagramme de séquence UML
diagramme de séquence UML
Amir Souissi
Â
Chp4 - Diagramme de SĂ©quence
Chp4 - Diagramme de SĂ©quence
Lilia Sfaxi
Â
TD4-UML-Correction
TD4-UML-Correction
Lilia Sfaxi
Â
Présentation Projet de fin d'études
Présentation Projet de fin d'études
Salah Eddine BENTALBA (+15K Connections)
Â
TD2 - UML - Correction
TD2 - UML - Correction
Lilia Sfaxi
Â
Chap5 diagramme d'etats-transitions
Chap5 diagramme d'etats-transitions
Amir Souissi
Â
TD3-UML-Correction
TD3-UML-Correction
Lilia Sfaxi
Â
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouri
Mansouri Khalifa
Â
TP2-UML-Correction
TP2-UML-Correction
Lilia Sfaxi
Â
Conception et RĂ©alisation d'un Data Warehouse
Conception et RĂ©alisation d'un Data Warehouse
Abderrahmane Filali
Â
UML Diagrammes Statiques
UML Diagrammes Statiques
'Farouk' 'BEN GHARSSALLAH'
Â
Android-Tp3: fragments et menus
Android-Tp3: fragments et menus
Lilia Sfaxi
Â
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatique
Oussama Yoshiki
Â
Projet de fin d'etude sur le parc informatique
Projet de fin d'etude sur le parc informatique
Hicham Ben
Â
Presentation stage Tunisie Telecom
Presentation stage Tunisie Telecom
litayem bechir
Â
UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouri
Mansouri Khalifa
Â
TD4-UML
TD4-UML
Lilia Sfaxi
Â
Uml
Uml
Yassine Elfadili
Â
Architectures 3-tiers (Web)
Architectures 3-tiers (Web)
Heithem Abbes
Â
MĂ©thodologie 2 Track Unified Process
MĂ©thodologie 2 Track Unified Process
Zakaria Bouazza
Â
1iĂšres rencontres franco canadiennes dâintelligence compĂ©titive - 27-10-2011
1iĂšres rencontres franco canadiennes dâintelligence compĂ©titive - 27-10-2011
VedoShare
Â
E-Reputation : 10 erreurs à éviter, ou comment réussir son buzzmonitoring
E-Reputation : 10 erreurs à éviter, ou comment réussir son buzzmonitoring
HUB INSTITUTE
Â
Weitere Àhnliche Inhalte
Was ist angesagt?
diagramme de séquence UML
diagramme de séquence UML
Amir Souissi
Â
Chp4 - Diagramme de SĂ©quence
Chp4 - Diagramme de SĂ©quence
Lilia Sfaxi
Â
TD4-UML-Correction
TD4-UML-Correction
Lilia Sfaxi
Â
Présentation Projet de fin d'études
Présentation Projet de fin d'études
Salah Eddine BENTALBA (+15K Connections)
Â
TD2 - UML - Correction
TD2 - UML - Correction
Lilia Sfaxi
Â
Chap5 diagramme d'etats-transitions
Chap5 diagramme d'etats-transitions
Amir Souissi
Â
TD3-UML-Correction
TD3-UML-Correction
Lilia Sfaxi
Â
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouri
Mansouri Khalifa
Â
TP2-UML-Correction
TP2-UML-Correction
Lilia Sfaxi
Â
Conception et RĂ©alisation d'un Data Warehouse
Conception et RĂ©alisation d'un Data Warehouse
Abderrahmane Filali
Â
UML Diagrammes Statiques
UML Diagrammes Statiques
'Farouk' 'BEN GHARSSALLAH'
Â
Android-Tp3: fragments et menus
Android-Tp3: fragments et menus
Lilia Sfaxi
Â
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatique
Oussama Yoshiki
Â
Projet de fin d'etude sur le parc informatique
Projet de fin d'etude sur le parc informatique
Hicham Ben
Â
Presentation stage Tunisie Telecom
Presentation stage Tunisie Telecom
litayem bechir
Â
UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouri
Mansouri Khalifa
Â
TD4-UML
TD4-UML
Lilia Sfaxi
Â
Uml
Uml
Yassine Elfadili
Â
Architectures 3-tiers (Web)
Architectures 3-tiers (Web)
Heithem Abbes
Â
MĂ©thodologie 2 Track Unified Process
MĂ©thodologie 2 Track Unified Process
Zakaria Bouazza
Â
Was ist angesagt?
(20)
diagramme de séquence UML
diagramme de séquence UML
Â
Chp4 - Diagramme de SĂ©quence
Chp4 - Diagramme de SĂ©quence
Â
TD4-UML-Correction
TD4-UML-Correction
Â
Présentation Projet de fin d'études
Présentation Projet de fin d'études
Â
TD2 - UML - Correction
TD2 - UML - Correction
Â
Chap5 diagramme d'etats-transitions
Chap5 diagramme d'etats-transitions
Â
TD3-UML-Correction
TD3-UML-Correction
Â
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouri
Â
TP2-UML-Correction
TP2-UML-Correction
Â
Conception et RĂ©alisation d'un Data Warehouse
Conception et RĂ©alisation d'un Data Warehouse
Â
UML Diagrammes Statiques
UML Diagrammes Statiques
Â
Android-Tp3: fragments et menus
Android-Tp3: fragments et menus
Â
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatique
Â
Projet de fin d'etude sur le parc informatique
Projet de fin d'etude sur le parc informatique
Â
Presentation stage Tunisie Telecom
Presentation stage Tunisie Telecom
Â
UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouri
Â
TD4-UML
TD4-UML
Â
Uml
Uml
Â
Architectures 3-tiers (Web)
Architectures 3-tiers (Web)
Â
MĂ©thodologie 2 Track Unified Process
MĂ©thodologie 2 Track Unified Process
Â
Andere mochten auch
1iĂšres rencontres franco canadiennes dâintelligence compĂ©titive - 27-10-2011
1iĂšres rencontres franco canadiennes dâintelligence compĂ©titive - 27-10-2011
VedoShare
Â
E-Reputation : 10 erreurs à éviter, ou comment réussir son buzzmonitoring
E-Reputation : 10 erreurs à éviter, ou comment réussir son buzzmonitoring
HUB INSTITUTE
Â
Les horaires d'ouverture, quelle histoire !
Les horaires d'ouverture, quelle histoire !
Dominique Lahary
Â
Slides Paris Gamification Day
Slides Paris Gamification Day
servicesmobiles.fr
Â
Appretsupercap refait
Appretsupercap refait
ibndawood
Â
Données Ouvertes : mode d'emploi ?
Données Ouvertes : mode d'emploi ?
mondeca
Â
Placage de la lentille lunettes de soleil prada pas cher
Placage de la lentille lunettes de soleil prada pas cher
Joe Gowey
Â
Comparatif des adj et adv
Comparatif des adj et adv
MmeOnsdorff
Â
Description Physique
Description Physique
alejandraprofe
Â
Génie chimique - Nanomatériaux, Catalyse, Electrochimie - ULg
Génie chimique - Nanomatériaux, Catalyse, Electrochimie - ULg
Réseau LIEU (Liaison Entreprises-Universités)
Â
19
19
Abdelilah Sawab
Â
Tableau tp12
Tableau tp12
Jef Chouzier
Â
Lutter contre les bactéries à Gram négatif
Lutter contre les bactéries à Gram négatif
Biomin
Â
Cours Chromato2
Cours Chromato2
bio svi
Â
Comment les médicaments sont-ils mis au point?
Comment les médicaments sont-ils mis au point?
Xplore Health
Â
Nouveau microsoft word document
Nouveau microsoft word document
karimfpk
Â
01 fonction stockage_la_batterie
01 fonction stockage_la_batterie
Abdellah HILALI
Â
SĂ©minaire de formation - Introduction
SĂ©minaire de formation - Introduction
Groupe Managem
Â
Brochure Meca-19102016-bd
Brochure Meca-19102016-bd
Camille Volant
Â
Protection des métaux contre la corrosion
Protection des métaux contre la corrosion
CHTAOU Karim
Â
Andere mochten auch
(20)
1iĂšres rencontres franco canadiennes dâintelligence compĂ©titive - 27-10-2011
1iĂšres rencontres franco canadiennes dâintelligence compĂ©titive - 27-10-2011
Â
E-Reputation : 10 erreurs à éviter, ou comment réussir son buzzmonitoring
E-Reputation : 10 erreurs à éviter, ou comment réussir son buzzmonitoring
Â
Les horaires d'ouverture, quelle histoire !
Les horaires d'ouverture, quelle histoire !
Â
Slides Paris Gamification Day
Slides Paris Gamification Day
Â
Appretsupercap refait
Appretsupercap refait
Â
Données Ouvertes : mode d'emploi ?
Données Ouvertes : mode d'emploi ?
Â
Placage de la lentille lunettes de soleil prada pas cher
Placage de la lentille lunettes de soleil prada pas cher
Â
Comparatif des adj et adv
Comparatif des adj et adv
Â
Description Physique
Description Physique
Â
Génie chimique - Nanomatériaux, Catalyse, Electrochimie - ULg
Génie chimique - Nanomatériaux, Catalyse, Electrochimie - ULg
Â
19
19
Â
Tableau tp12
Tableau tp12
Â
Lutter contre les bactéries à Gram négatif
Lutter contre les bactéries à Gram négatif
Â
Cours Chromato2
Cours Chromato2
Â
Comment les médicaments sont-ils mis au point?
Comment les médicaments sont-ils mis au point?
Â
Nouveau microsoft word document
Nouveau microsoft word document
Â
01 fonction stockage_la_batterie
01 fonction stockage_la_batterie
Â
SĂ©minaire de formation - Introduction
SĂ©minaire de formation - Introduction
Â
Brochure Meca-19102016-bd
Brochure Meca-19102016-bd
Â
Protection des métaux contre la corrosion
Protection des métaux contre la corrosion
Â
Ăhnlich wie CoursUML-SlimMesfar-Total
PreÌsentation cours UML.pptx
PreÌsentation cours UML.pptx
PrinceLankoand
Â
Support de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdf
YasushiTsubakik
Â
Uml 2
Uml 2
Azaykou Karim
Â
Uml partie 1
Uml partie 1
Lamine Niane
Â
Rattrapage uml
Rattrapage uml
vangogue
Â
CM uml-intro
CM uml-intro
Yannick Prié (Enseignement)
Â
SysML (Valtech Days 2008)
SysML (Valtech Days 2008)
Pascal Roques
Â
UML Part1-Introduction Mansouri
UML Part1-Introduction Mansouri
Mansouri Khalifa
Â
Présentation UML.ppt
Présentation UML.ppt
NajiHita1
Â
Introduction Ă Sysml
Introduction Ă Sysml
Yassine SIDKI
Â
ppt sur Le langage de modélisation UML.pdf
ppt sur Le langage de modélisation UML.pdf
imenhamada17
Â
UML-jamil.pptx
UML-jamil.pptx
kdekde1
Â
Unified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VF
cifaf13039
Â
diagramme de cas d'utilisation
diagramme de cas d'utilisation
Kamel Eddine Heragmi
Â
7 diagramme de cas d'utilisation
7 diagramme de cas d'utilisation
Kamel Eddine Heragmi
Â
COURS UML INFORMATQIUE TELECOM2 2007.pdf
COURS UML INFORMATQIUE TELECOM2 2007.pdf
ssuserbd075f
Â
Uml upxp2
Uml upxp2
Joubi Aaziz
Â
Introduction à l'objet - DeuxiÚme année ISIMA
Introduction à l'objet - DeuxiÚme année ISIMA
Loic Yon
Â
Plasticitérecherche2017
Plasticitérecherche2017
Anne-Marie Pinna-Dery
Â
Introduction Ă NetLogo
Introduction Ă NetLogo
Alvaro Gil
Â
Ăhnlich wie CoursUML-SlimMesfar-Total
(20)
PreÌsentation cours UML.pptx
PreÌsentation cours UML.pptx
Â
Support de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdf
Â
Uml 2
Uml 2
Â
Uml partie 1
Uml partie 1
Â
Rattrapage uml
Rattrapage uml
Â
CM uml-intro
CM uml-intro
Â
SysML (Valtech Days 2008)
SysML (Valtech Days 2008)
Â
UML Part1-Introduction Mansouri
UML Part1-Introduction Mansouri
Â
Présentation UML.ppt
Présentation UML.ppt
Â
Introduction Ă Sysml
Introduction Ă Sysml
Â
ppt sur Le langage de modélisation UML.pdf
ppt sur Le langage de modélisation UML.pdf
Â
UML-jamil.pptx
UML-jamil.pptx
Â
Unified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VF
Â
diagramme de cas d'utilisation
diagramme de cas d'utilisation
Â
7 diagramme de cas d'utilisation
7 diagramme de cas d'utilisation
Â
COURS UML INFORMATQIUE TELECOM2 2007.pdf
COURS UML INFORMATQIUE TELECOM2 2007.pdf
Â
Uml upxp2
Uml upxp2
Â
Introduction à l'objet - DeuxiÚme année ISIMA
Introduction à l'objet - DeuxiÚme année ISIMA
Â
Plasticitérecherche2017
Plasticitérecherche2017
Â
Introduction Ă NetLogo
Introduction Ă NetLogo
Â
CoursUML-SlimMesfar-Total
1.
1 Conception des SystĂšmes
dâInformation Langage de modĂ©lisation UML Unified Modeling Language Dr. Slim Mesfar Mail : mesfarslim@yahoo.fr
2.
Ch1 : Introduction
ï· Notion de systĂšme dâinformation ï· PrĂ©sentation de UML2 ï· PrĂ©sentation des diffĂ©rentes Ă©tapes de dĂ©veloppement logiciel Chapitre 2 : Analyse fonctionnelle ï· Diag de contexte statique ï· Diag de CU avec description textuelle des CU Chapitre 3 : Analyse dynamique ï· Diag de contexte dynamique ï· Diag de sĂ©quence systĂšme ï· Diag d'activitĂ©s (modĂ©lisation processus mĂ©tier et CU) Chapitre 4 : Analyse statique ï· Diag de classes dâanalyse (+ contraintes, stĂ©rĂ©otypes) ï· Diag dâobjets ï· Diag de package Chapitre 5 : Conception ï· Diag de sĂ©quence objet (stĂ©rĂ©otypes de Jacobson) ï· Diag de classes de conception (navigabilitĂ©, traduction de lâanalyse) ï· Diag de communication / de collaboration ï· Diag Ă©tat transition ï· Diag de composants ï· Diag de dĂ©ploiement Chapitre 6 : ImplĂ©mentation ï· GĂ©nĂ©ration Ă partir dâun diagramme de classe : - Dâune base de donnĂ©es - Code source JAVA/C++⊠2 Plan du cours
3.
3 Les systĂšmes dâinformation âą
Des exemples de SI â Une application de gestion de stocks dâun supermarchĂ© â Un site web de vente en ligne â Une bibliothĂšque numĂ©rique â Un portail avec intranet pour une Ă©cole/ institut â ... Introduction gĂ©nĂ©rale
4.
4 Les systĂšmes dâinformation âą
Quâest ce quâun SI ? un SI est un ou plusieurs logiciels manipulant un ensemble dâinformations structurĂ©es et cohĂ©rentes. Par exemple : lâintra dâune Ă©cole supĂ©rieure : des cours, des Ă©lĂšves, des profs, des horaires, des projets, des groupes, des notes, etc. On peut les consulter, les crĂ©er, les modifier, les dĂ©truire. ïżœ Plus largement, aujourdâhui, tout logiciel peut ĂȘtre considĂ©rĂ© comme un systĂšme dâinformation. Introduction gĂ©nĂ©rale
5.
5 Les systĂšmes dâinformation âą
Autrement dit : un SI est un ensemble organisĂ© de ressources : matĂ©riel, logiciel, personnel, donnĂ©es, procĂ©dures⊠permettant dâacquĂ©rir, de traiter, de stocker des informations (sous formes de donnĂ©es, textes, images, sons, etc.) dans et entre des organisations. ïżœ NĂ©cessitĂ© de collaboration entre les intervenants pour garantir la bonne conduite du processus de dĂ©veloppement dâun SI ïżœ NĂ©cessitĂ© dâun langage de communication unifiĂ© Introduction gĂ©nĂ©rale
6.
6 Sommaire âą Historique âą La
ModĂ©lisation âą Les Diagrammes UML Chapitre 1 : Introduction et historique dâUML
7.
7 Historique
8.
8 BOOCH âą Pionnier de
lâOrientĂ©-Objet â Article en 1981: â Object Oriented Development â â Au dĂ©but, mĂ©thode pour le dĂ©veloppement dâapplications en Ada pour le â Department of Defense â â Etendue au C++ âą Distingue 2 niveaux: â Logique âą Diagrammes de classes âą Diagramme dâinstances âą Diagramme Ă©tats/transitions â Physique âą Diagrammes de modules (principe des packages) âą Diagramme de processus Les Principales MĂ©thodes Objet Grady Booch Historique
9.
9 OMT âą Object Modeling
Technique â Livre de James Rumbaugh (1991) âą 3 axes â Statique : identifie les propriĂ©tĂ©s des objets et leurs liaisons avec les autres objets â Dynamique : dĂ©finit le cycle de vie des objets : comportement des objets, les diffĂ©rents Ă©tats par lesquels ils passent, et les Ă©vĂ©nements dĂ©clanchant ces changements dâĂ©tats â Fonctionnel : prĂ©cise les fonctions rĂ©alisĂ©es par les objets par lâintermĂ©diaire des mĂ©thodes. James Rumbaugh Les Principales MĂ©thodes Objet Historique
10.
10 OOSE âą Object Oriented
Software Engineering â Souvent appelĂ©e Objectory âą 5 modĂšles â Description des besoins â Analyse â Conception â Implantation â Test âą 3 types d âobjets â entitĂ©s â contrĂŽles â interfaces âą Notion de Cas dâUtilisation: Use Cases Ivar Jacobson Les Principales MĂ©thodes Objet Historique
11.
11 MĂ©thodes Objets âą En
1994, plus de 50 mĂ©thodes OO â Fusion, Shlaer-Mellor, ROOM, Classe-Relation, Wirfs-Brock, Coad- Yourdon, MOSES, Syntropy, BOOM, OOSD, OSA, BON, Catalysis, COMMA, HOOD, Ooram, DOORS... âą Les notations graphiques sont toutes diffĂ©rentes âą Lâindustrie a besoin de standards Les Principales MĂ©thodes Objet Historique
12.
12 Naissance dâUML âą 1993-1994:
Boochâ93, OMT-2 â Les 2 mĂ©thodes sont leaders sur le marchĂ© â Elles sont de plus en plus proches âą Octobre 1994 â J. Rumbaugh (OMT) rejoint G. Booch â Annonce de lâunification des deux mĂ©thodes âą Octobre 1995: MĂ©thode UnifiĂ©e v0.8 âą Fin 1995: le fondateur d âObjectory, Ivar Jacoson, rejoint Ă son tour J. Rumbaugh et G. Booch âą Janvier 97 : Soumission Ă lâOMG de la version UML 1.0 â OMG: Object Management Group âą Organisme Ă but non lucratif fondĂ© en 1989 âą Plus de 700 entreprises y adhĂšrent âą Septembre 97 : UML 1.1 Historique
13.
13 Conclusion âą UML: Prendre
le meilleur de chacune des mĂ©thodes â OOSE (Jacobson): Use Cases â OMT (Rumbaugh): Analyse â Booch: Conception, Architecture âą Depuis 1997, UML est dans le domaine public âą A partir Juin 2004 : Version UML 2.x avec divers apports : â Plus de possibilitĂ©s de reprĂ©sentation, de prĂ©cision et de capacitĂ©s de modĂ©lisation (ex : diagrammes de sĂ©quence totalement refondus) â Meilleur support de lâingĂ©nierie des systĂšmes â PossibilitĂ© de dĂ©finir et de raffiner les systĂšmes jusquâaux couches logicielles â âŠ ïżœ Plus proche des MDAs âą Actuellement : Version UML 2.4.1 (depuis Aout 2011) La Convergence vers UML Historique
14.
14 La Modélisation
15.
15 UML ? âą Est
une notation, pas une mĂ©thode âą Est un langage de modĂ©lisation objet âą Convient Ă tous les langages objets â SmallTalk â C++ (HĂ©ritage multiple) â Java (Interface) DĂ©finition La ModĂ©lisation
16.
16 Un modĂšle permet
de : â mieux comprendre le systĂšme Ă dĂ©velopper, â visualiser le systĂšme comme il est ou comme il devrait l'ĂȘtre, â valider le modĂšle vis Ă vis des clients, â spĂ©cifier les structures de donnĂ©es et le comportement du systĂšme, â fournir un guide pour la construction du systĂšme, â documenter le systĂšme et les dĂ©cisions prises. La ModĂ©lisation A quoi sert la modĂ©lisation?
17.
17 Quâapporte la modĂ©lisation
objet? âą plus grande indĂ©pendance du modĂšle par rapport aux fonctionnalitĂ©s demandĂ©es âą des fonctionnalitĂ©s peuvent ĂȘtre rajoutĂ©es ou modifiĂ©es sans que le modĂšle objet change âą plus proche du monde rĂ©el La ModĂ©lisation A quoi sert la modĂ©lisation?
18.
18 La ModĂ©lisation Objectifs dâUML âąReprĂ©senter
des systĂšmes entiers, âąCrĂ©er un langage de modĂ©lisation utilisable Ă la fois par les humains et les machines, âąRechercher un langage commun qui est utilisable par toutes les mĂ©thodes et adaptĂ© Ă toutes les phases du dĂ©veloppement Pourquoi UML?
19.
19 La ModĂ©lisation UML ? ïżœUML
nâest pas une mĂ©thode ïżœUML est un langage de modĂ©lisation objet ïżœUML est adoptĂ© par toutes les mĂ©thodes objet ïżœUML est une norme dans le domaine public âąvisualiser âąspĂ©cifier âąconstruire âądocumenter âąS.I des entreprises âąBanques et les services financiers âąTĂ©lĂ©communications âąTransport âąDĂ©fense et aĂ©rospatiale âąScientifique âąApplications distribuĂ©es par le WEB UtilisĂ© pour UtilisĂ© dans
20.
20 Architecture 4+1 La ModĂ©lisation âą
Vue des cas d'utilisation : c'est la description du modÚle « vue » par les acteurs du systÚme. Elle correspond aux besoins attendus par chaque acteur (c'est le QUOI et le QUI).
21.
21 Architecture 4+1 La ModĂ©lisation âąVue
logique : c'est la dĂ©finition du systĂšme vu de l'intĂ©rieur. Elle explique comment peuvent ĂȘtre satisfaits les besoins des acteurs (c'est le COMMENT). âąVue d'implĂ©mentation : cette vue dĂ©finit les dĂ©pendances entre les modules. âąVue de comportement ou des processus : c'est la vue temporelle et technique, qui met en Ćuvre les notions de tĂąches concurrentes, stimuli, contrĂŽle, synchronisation, etc. âąVue de dĂ©ploiement : cette vue dĂ©crit la position gĂ©ographique et l'architecture physique de chaque Ă©lĂ©ment du systĂšme (c'est le OĂ).
22.
22 Axes de Modélisation
avec UML Statiques DynamiquesFonctionnels Diagramme de Classes Diagramme dâObjets Diagramme de Composants Diagramme de DĂ©ploiement Diagramme de paquetages Diagramme de structure composite (UML 2.x) Diagramme de Use Case Diagramme de SĂ©quence Diagramme de communication (UML 2.x) Diagramme global dâinteraction (UML 2.x) Diagramme de temps (UML 2.x) Diagramme d'Etats-Transitions Diagramme d'activitĂ©s Cycle de DĂ©veloppement La ModĂ©lisation
23.
23 ModĂ©lisation fonctionnelle La ModĂ©lisation âą
Diagramme des cas d'utilisation (use-cases) : il permet d'identifier les possibilités d'interaction entre le systÚme et les acteurs (intervenants extérieurs au systÚme), c'est-à -dire toutes les fonctionnalités que doit fournir le systÚme.
24.
24 ModĂ©lisation statique La ModĂ©lisation âąDiagramme
de classes : il reprĂ©sente les classes intervenant dans le systĂšme. âąDiagramme d'objets : il sert Ă reprĂ©senter les instances de classes (objets) utilisĂ©es dans le systĂšme. âąDiagramme de composants : il permet de montrer les composants du systĂšme d'un point de vue physique, tels qu'ils sont mis en Ćuvre (fichiers, bibliothĂšques, bases de donnĂ©es...) âąDiagramme de dĂ©ploiement : il sert Ă reprĂ©senter les Ă©lĂ©ments matĂ©riels (ordinateurs, pĂ©riphĂ©riques, rĂ©seaux, systĂšmes de stockage...) et la maniĂšre dont les composants du systĂšme sont rĂ©partis sur ces Ă©lĂ©ments matĂ©riels et interagissent entre eux.
25.
25 ModĂ©lisation statique La ModĂ©lisation âąDiagramme
des paquetages : un paquetage Ă©tant un conteneur logique permettant de regrouper et d'organiser les Ă©lĂ©ments dans le modĂšle UML, le Diagramme de paquetage sert Ă reprĂ©senter les dĂ©pendances entre paquetages, câest-Ă -dire les dĂ©pendances entre ensembles de dĂ©finitions. âąDiagramme de structure composite (UML 2.x) : permet de dĂ©crire sous forme de boĂźte blanche les relations entre composants d'une classe.
26.
26 ModĂ©lisation dynamique La ModĂ©lisation âąDiagramme
de sĂ©quence : reprĂ©sentation sĂ©quentielle du dĂ©roulement des traitements et des interactions entre les Ă©lĂ©ments du systĂšme et/ou de ses acteurs. âąDiagramme de communication (UML 2.x) : reprĂ©sentation simplifiĂ©e d'un diagramme de sĂ©quence se concentrant sur les Ă©changes de messages entre les objets. âąDiagramme global d'interaction (UML 2.x) : permet de dĂ©crire les enchaĂźnements possibles entre les scĂ©narios prĂ©alablement identifiĂ©s sous forme de diagrammes de sĂ©quences (variante du diagramme d'activitĂ©s).
27.
27 ModĂ©lisation dynamique La ModĂ©lisation âą
Diagramme de temps (UML 2.x) : permet de dĂ©crire les variations d'une donnĂ©e au cours du temps. âąDiagramme Ă©tats-transitions : permet de dĂ©crire sous forme de machine Ă Ă©tats finis le comportement du systĂšme ou de ses composants. âą Diagramme d'activitĂ©s : permet de dĂ©crire sous forme de flux ou d'enchaĂźnement d'activitĂ©s le comportement du systĂšme ou de ses composants.
28.
28 Cycle de développement
du logiciel
29.
ïżœ Expression des
besoins ïżœ SpĂ©cification ïżœ Analyse ïżœ Conception ïżœ ImplĂ©mentation ïżœ Validation ïżœ Tests de vĂ©rification ïżœ Maintenance et Ă©volution Les diffĂ©rentes Ă©tapes du dĂ©veloppement logiciel
30.
ïżœ Lâ Expression
des besoins - Interview de lâexpert mĂ©tier ïżœ La SpĂ©cification â Ce que le systĂšme doit ĂȘtre et comment il peut ĂȘtre utilisĂ©. ïżœ LâAnalyse â Lâobjectif est de dĂ©terminer les Ă©lĂ©ments intervenant dans le systĂšme Ă construire, ainsi que leur structure et leurs relations . Elle doit dĂ©crire chaque objet selon 3 axes : ï· Axe fonctionnel : savoir-faire de lâobjet. ï· Axe statique : structure de lâobjet. ï· Axe dynamique : cycle de vie de lâobjet au cours de lâapplication (Ătats et messages de lâobjet). Ces descriptions ne tiennent pas compte de contraintes techniques (informatique).
31.
ïżœ La Conception
: Elle consiste Ă apporter des solutions techniques aux descriptions dĂ©finies lors de lâanalyse : âą architecture technique âą performances et optimisation âą stratĂ©gie de programmation On y dĂ©finit les structures et les algorithmes. Cette phase sera validĂ©e lors des tests. ïżœ LâimplĂ©mentation Câest la rĂ©alisation de la programmation.
32.
ïżœ La Validation Le
dĂ©veloppement dâune application doit ĂȘtre liĂ© Ă un contrat ayant une forme dâun cahier des charges, oĂč doivent se trouver tous les besoins de lâutilisateur. Ce cahier des charges doit ĂȘtre rĂ©digĂ© avec la collaboration de lâutilisateur et peut ĂȘtre par ailleurs complĂ©tĂ© par la suite. Tout au long de ces Ă©tapes, il doit y avoir des validations en collaboration Ă©galement avec lâutilisateur. Une autre validation doit aussi ĂȘtre envisagĂ©e lors de lâachĂšvement du travail de dĂ©veloppement, une fois que la qualitĂ© technique du systĂšme est dĂ©montrĂ©e. Elle permettra de garantir la logique et la complĂ©tude du systĂšme.
33.
ïżœ Les tests
de vĂ©rification Ils permettent de rĂ©aliser des contrĂŽles pour la qualitĂ© technique du systĂšme. Il sâagit de relever les Ă©ventuels dĂ©fauts de conception et de programmation (revue de code, tests des composants,...). Il faut instaurer ces tests tout au long du cycle de dĂ©veloppement et non Ă la fin pour Ă©viter des reprises consĂ©quentes du travail (programmes de tests robustes ; Logiciels de tests).
34.
ïżœ Maintenance et
Ă©volution Deux sortes de maintenances sont Ă considĂ©rer : ï¶ Une maintenance corrective, qui consiste Ă traiter les âbuggs â. ï¶ Une maintenance Ă©volutive, qui permet au systĂšme dâintĂ©grer de nouveaux besoins ou des changements technologiques.
35.
Le dĂ©veloppement dâun
logiciel repose sur les activitĂ©s suivantes : ïżœ DĂ©termination des besoins (quel est le cahier des charges ?) ïżœ Analyse (que fera le logiciel ?) ïżœ Conception (comment le fera-t-il ?) ïżœ ImplĂ©mentation (quel code exĂ©cutera-t-il ?) ïżœ Test (sera-t-il conforme Ă lâanalyse et au cahier des charges ?) Une organisation de ces activitĂ©s forme un processus de dĂ©veloppement. RĂ©sumĂ© des diffĂ©rentes Ă©tapes du dĂ©veloppement logiciel
36.
36 Chap 2 : Analyse
fonctionnelle
37.
37 Analyse fonctionnelle Permet dâĂ©laborer
le cahier des charges ou le document de spĂ©cification des besoins du logiciel ïżœ permet de structurer les besoins des utilisateurs, les objectifs correspondants d'un systĂšme ïżœ On recense, l'ensemble des fonctionnalitĂ©s d'un systĂšme en examinant les besoins fonctionnels de chaque acteur.
38.
38 DĂ©termination des besoins Besoins
(« requirement ») = exigence de ce que le systĂšme devrait satisfaire ïżœ DĂ©termination des besoins attendus par chaque acteur : ïżœ le QUI ? ïżœ le QUOI ? Analyse fonctionnelle
39.
39 DĂ©termination des besoins âą
Besoins fonctionnels â Ă quoi sert le systĂšme â Ce que doit faire le systĂšme, les fonctions utiles â Description des donnĂ©es manipulĂ©es âą Besoins non fonctionnels : des restrictions ou des contraintes qui pĂšsent sur un service du systĂšme â description des contraintes, â Pour chaque fonction et pour le systĂšme global, il est possible dâexprimer diffĂ©rents types de contraintes. Exemple : portabilitĂ©, compatibilitĂ©, fiabilitĂ©, sĂ©curitĂ©, ⊠Les diffĂ©rents types de besoins
40.
40 Analyse fonctionnelle MĂ©thodologie : 1.
Identifier les acteurs, a. humains ou systĂšmes connexes b. principaux ou secondaires 2. Etablir le diagramme de contexte statique 3. Identifier les cas d'utilisation (UC) 4. Description des UC a. graphiquement b. textuellement
41.
41 2.1. Les diagrammes
de contexte statique
42.
42 Le diagramme de
contexte statique âą Le diagramme de contexte statique permet de positionner le systĂšme dans son environnement selon un point de vue matĂ©riel. âą Le systĂšme est donc dĂ©crit physiquement est non pas en termes de fonctionnalitĂ©s âą De plus, pour chaque type dâĂ©lĂ©ment matĂ©riel extĂ©rieur au systĂšme, il est prĂ©cisĂ© le nombre minimal et maximal, appelĂ©s cardinalitĂ©s, qui sont mis en jeu
43.
43 2.2. Les diagrammes
de cas dâutilisation
44.
âą Le diagramme
de cas dâutilisation dĂ©crit les fonctionnalitĂ©s dâun systĂšme dâun point de vue utilisateur, sous la forme dâactions et de rĂ©actions ; lâensemble des fonctionnalitĂ©s est dĂ©terminĂ© en examinant les besoins fonctionnels de tous les utilisateurs potentiels. âą Le but est dâidentifier : â les catĂ©gories dâutilisateurs : chacune dâentre elles, appelĂ©e acteur, est susceptible de mettre en oeuvre une ou plusieurs fonctionnalitĂ©s du systĂšme ; â les besoins du systĂšme : chaque fonctionnalitĂ©, appelĂ©e cas dâutilisation, doit rĂ©pondre Ă lâun des besoins nĂ©cessitĂ©s par une ou plusieurs catĂ©gories dâutilisateurs. 44 Le diagramme des cas dâutilisation (Use cases)
45.
âą Le diagramme
des cas dâutilisation se base sur le cahier des charges pour ĂȘtre construit ; il fait donc partie, en termes de gestion de projet, de la spĂ©cification du systĂšme. âą Processus de construction du diagramme de cas dâutilisation 45 Le diagramme des cas dâutilisation (Use cases)
46.
46 Le diagramme des
cas dâutilisation (Use cases) Les diagrammes UML
47.
47 1. Acteur :
entitĂ© (humain ou machine) externe qui agit sur le systĂšme (opĂ©rateur, composant interneâŠ) : Le diagramme des cas dâutilisation (Use cases) Identification des acteurs âąpermettant dâen dĂ©terminer les limites âąjouant un rĂŽle par rapport Ă lui âądĂ©clenchant un stimulus initial entraĂźnant une rĂ©action du systĂšme âąUn acteur est dĂ©crit prĂ©cisĂ©ment en quelques lignes :
48.
48 1. Acteur Le diagramme
des cas dâutilisation (Use cases) Identification des acteurs 4 catĂ©gories dâacteurs : âąacteurs principaux : personnes utilisant les fonctions principales du systĂšme. Dans le cas d'un distributeur de billets, il s'agit des clients. âąacteurs secondaires : personnes qui effectuent des tĂąches administratives ou de maintenance. Dans le cas d'un distributeur de billets, il s'agit de la personne qui recharge la caisse du distributeur. âąmatĂ©riel externe : dispositifs matĂ©riels autres que les ordinateurs comme les pĂ©riphĂ©riques. Dans le cas d'un distributeur de billets, il s'agit de l'imprimante, du lecteur de carte, de la trieuse de billets. âąautres systĂšmes : les systĂšmes avec lesquels le systĂšme interagit. Dans le cas d'un distributeur de billets, il s'agit du groupement bancaire qui gĂšre l'ordinateur central qui relie tous les distributeurs.
49.
49 Le diagramme des
cas dâutilisation (Use cases) La ModĂ©lisation des besoins en UML 2. Use case : ensemble dâactions rĂ©alisĂ©es par le systĂšme, en rĂ©ponse Ă une action dâun acteur. Lâensemble des uses cases dĂ©crit les objectifs (le but) du systĂšme. Exemple. identification, retrait de liquide. âą ScĂ©narios dâun CU SĂ©quence particuliĂšre de messages dans le CU pendant une interaction particuliĂšre (âcheminâ dans le cas dâutilisation),
50.
50 Description détaillée de
chaque cas dâutilisation ïżœ Chaque cas d âutilisation doit ĂȘtre dĂ©crit en dĂ©tail ïżœ Commencer par les CU prioritaires ïżœ Description utile pour la suite du dĂ©veloppement ïżœ Description dĂ©taillĂ©e plus ou moins formelle ïżœ langue naturelle mais structurĂ©e, ïżœ vocabulaire prĂ©cis, ïżœ ... Le diagramme des cas dâutilisation (Use case) La ModĂ©lisation des besoins en UML
51.
51 Informations Ă dĂ©crire ïżœ
Quand le CU commence, prĂ©-conditions ïżœ Quand le CU se termine, post-conditions ïżœ Le chemin correspondant au dĂ©roulement normal ïżœ Les variantes possibles et les cas dâerreurs (les points dâextensions) ïżœ Les interactions entre le systĂšme et les acteurs ïżœ Les informations Ă©changĂ©es ïżœ Les Ă©ventuels besoins non fonctionnels Le diagramme des cas dâutilisation (Use case) La ModĂ©lisation des besoins en UML
52.
52 Exemple de description
dĂ©taillĂ©e dâun CU PrĂ©condition : Le distributeur contient des billets, il est en attente d âune opĂ©ration, il nâest ni en panne, ni en maintenance DĂ©but : lorsquâun client introduit sa carte bancaire dans le distributeur. Fin : lorsque la carte bancaire et les billets sont sortis. Postcondition : Si de l âargent a pu ĂȘtre retirĂ©, la somme dâargent sur le compte est Ă©gale Ă la somme dâargent quâil y avait avant, moins le montant du retrait. Sinon la somme d âargent sur le compte est la mĂȘme quâavant. Retirer de lâArgent Retirer de lâArgent Le diagramme des cas dâutilisation (Use case) La ModĂ©lisation des besoins en UML
53.
53 Retirer de lâArgent ScĂ©nario nominal
: (1) le client introduit sa carte bancaire (2) le systĂšme lit la carte et vĂ©rifie si la carte est valide (3) le systĂšme demande au client de taper son code (4) le client tape son code confidentiel (5) le systĂšme vĂ©rifie que le code correspond Ă la carte (6) le client choisi une opĂ©ration de retrait (7) le systĂšme demande le montant Ă retirer ⊠Variantes : (A) Carte invalide : au cours de l âĂ©tape (2) si la carte est jugĂ©e invalide, le systĂšme affiche un message d âerreur, rejĂšte la carte et le cas d âutilisation se termine. (B) Code erronĂ© : au cours de l âĂ©tape (5) ... Le diagramme des cas dâutilisation (Use case) La ModĂ©lisation des besoins en UML Exemple de description dĂ©taillĂ©e dâun CU
54.
54 Contraintes non fonctionnelles
: (A) Performance : le systĂšme doit rĂ©agir dans un dĂ©lai infĂ©rieur Ă 4 secondes, quelque soit lâaction de l âutilisateur. (B) RĂ©sistance aux pannes : si une coupure de courant ou une autre dĂ©faillance survient au cours du cas d âutilisation, la transaction sera annulĂ©e, l âargent ne sera pas distribuĂ©. Le systĂšme doit pouvoir redĂ©marrer automatiquement dans un Ă©tat cohĂ©rent et sans intervention humaine. (C) RĂ©sistance Ă la charge : le systĂšme doit pouvoir gĂ©rer plus de 1000 retraits d âargent simultanĂ©ment ... Retirer de lâArgent Retirer de lâArgent Le diagramme des cas dâutilisation (Use case) La ModĂ©lisation des besoins en UML Exemple de description dĂ©taillĂ©e dâun CU
55.
55 Le diagramme des
cas dâutilisation (Use case) La ModĂ©lisation des besoins en UML âąRelations entre les cas dâutilisation -« utilise» ou « include »: dĂ©finit le fait quâun use case contient le comportement dĂ©fini dans un autre use case. Cas d'utilisation B << Utilise >> Cas d'utilisation A -« Ă©tend » ou « extend »: dĂ©finit le fait quâune instance dâun use case peut ĂȘtre augmentĂ©e avec un comportement quelconque dĂ©fini dans un use case Ă©tendu Cas d'utilisation A Cas d'utilisation B << Etend >> - « gĂ©nĂ©ralisation » Un cas A est une gĂ©nĂ©ralisation dâun cas B si B est un cas particulier de A.
56.
56 Le diagramme des
cas dâutilisation (Use case) La ModĂ©lisation des besoins en UML âąRelations entre les cas dâutilisation
57.
57 Le diagramme des
cas dâutilisation (Use case) La ModĂ©lisation des besoins en UML âąRelation dâhĂ©ritage entre les acteurs secrĂ©taire mĂ©decin Consulter fiche patient Remplir fiche consultation crĂ©er fiche patient
58.
Erreurs usuelles -
rĂŽles 58 Le diagramme des cas dâutilisation (Use case) La ModĂ©lisation des besoins en UML
59.
Erreurs usuelles -
factorisation 59 Le diagramme des cas dâutilisation (Use case) La ModĂ©lisation des besoins en UML GĂ©rer client
60.
60 Chap 3 : Analyse
dynamique
61.
61 3.1. Les diagrammes
de contexte dynamique
62.
62 Le diagramme de
contexte dynamique âą Le diagramme de contexte dynamique permet de positionner le systĂšme dans son environnement selon le point de vue des communications. âą Il reprend les Ă©lĂ©ments du contexte statique et prĂ©cise les Ă©changes dâinformations qui sont rĂ©alisĂ©s entre le systĂšme et les Ă©lĂ©ments matĂ©riels extĂ©rieurs au systĂšme. âą Le systĂšme est donc dĂ©crit physiquement et logiquement.
63.
63 3.2. Les diagrammes
de séquence systÚme
64.
64 Le diagramme de
sĂ©quence Les diagrammes UML Deux diffĂ©rents types de diagrammes de sĂ©quence : âą Diagramme de sĂ©quence systĂšme au niveau de lâanalyse dynamique ïżœreprĂ©sentation des diffĂ©rents scĂ©narios des cas dâutilisation ïżœ interaction entre les acteurs et le systĂšme (une boite noire) selon un ordre chronologique âąDiagramme de sĂ©quence dĂ©taillĂ© au niveau de la conception ïżœ reprĂ©sentation des collaborations entre des objets pour la rĂ©alisation dâun cas dâutilisation, selon un point de vue temporel. ïżœ reprĂ©sentation de la chronologie des envois de messages entre les objets. S. Mesfar
65.
65 Le diagramme de
séquence Les diagrammes UML Du diagramme de séquence systÚme à la conception S. Mesfar
66.
66 Le diagramme de
sĂ©quence Les diagrammes UML âą Il y a autant de diagrammes de sĂ©quence quâil y a de scĂ©narios âą Un ScĂ©nario montre une sĂ©quence particuliĂšre dâinteractions entre objets, dans un seul contexte dâexĂ©cution du systĂšme âą Un scĂ©nario peut ĂȘtre vu comme une rĂ©ponse Ă un besoin ou une partie dâun besoin du diagramme des Uses Cases. âą On y fait intervenir des objets / systĂšme complet, des messages et des Ă©vĂ©nements ReprĂ©sentation de ScĂ©narios objet1 : Classe objet2 : Classe Objets de type Classe S. Mesfar
67.
67 Le diagramme de
sĂ©quence Les diagrammes UML ïżœl'ordre d'envoi d'un message est dĂ©terminĂ© par sa position sur l'axe vertical du diagramme ; le temps s'Ă©coule "de haut en bas" de cet axe : La ligne de vie. La disposition des objets sur l'axe horizontal n'a pas de consĂ©quence particuliĂšre sur la sĂ©mantique du diagramme. S. Mesfar
68.
NumĂ©rotation des messages âą
Les messages peuvent ĂȘtre numĂ©rotĂ©s sĂ©quentiellement A B 1: Message A B 1: Message 1 C 1.1: message 2 Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 68
69.
DurĂ©e dâactivation(pĂ©riode dâactivation) â
correspond au temps pendant lequel un objet effectue une action â est reprĂ©sentĂ©e par une bande rectangulaire : âą Le long de la ligne de vie de lâobjet âą Dont les extrĂ©mitĂ©s reprĂ©sentent le dĂ©but et la fin de lâactivitĂ©. Un objet DurĂ©e dâactivation Objet 1 Objet 2 Remarque : souvent quand lâobjet est en activitĂ© continue, on nĂ©glige la reprĂ©sentation de cette pĂ©riode dâactivation Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 69
70.
70 Le diagramme de
séquence Les diagrammes UML Notation Graphique Objet S. Mesfar Appelant: Ligne téléphonique: Appelé: décroche() tonalité numérotation() indication sonnerie indication sonnerie() décroche
71.
Transmission de donnĂ©es âą
Les messages peuvent véhiculer des données entre les acteurs et le systÚme ou entre les objets A B 1: Message (donnee1, donnee2) Le diagramme de séquence Les diagrammes UML S. Mesfar 71
72.
72 Le diagramme de
séquence Les diagrammes UML Représentation graphique SystÚme comme une boite noire S. Mesfar
73.
73 Le diagramme de
sĂ©quence Les diagrammes UML âąSpĂ©cificitĂ©s des diagrammes de sĂ©quences ïżœun objet peut sâenvoyer un message, Un objet: Message rĂ©flexif S. Mesfar
74.
74 Le diagramme de
séquence Les diagrammes UML Représentation graphique enrichie S. Mesfar
75.
75 Le diagramme de
sĂ©quence Les diagrammes UML âąSpĂ©cificitĂ©s des diagrammes de sĂ©quences ïżœun message peut entraĂźner la crĂ©ation ou la destruction dâautres objets, CrĂ©er DĂ©truire Un objet: Un autre objet: S. Mesfar
76.
Les types de
messages Dans un diagramme de sĂ©quences trois principaux types de messages sont distinguĂ©s : âąmessage synchrone (flĂšche avec une extrĂ©mitĂ© pleine) Bloque lâĂ©metteur jusqu'Ă prise en compte du message par le destinataire. Le flot de contrĂŽle passe de l'Ă©metteur au rĂ©cepteur (l'Ă©metteur devient passif et le rĂ©cepteur actif) Ă la prise en compte du message. âąmessage asynchrone (flĂšche avec une extrĂ©mitĂ© non pleine) N'interrompt pas l'exĂ©cution de lâĂ©metteur. Le message envoyĂ© peut ĂȘtre pris en compte par le rĂ©cepteur Ă tout moment ou ignorĂ© (jamais traitĂ©). Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 76
77.
Les réponses aux
messages Dans le cas des envois synchrones, le retour peut ĂȘtre implicite en fin d'activitĂ©s et ne nĂ©cessitera pas de reprĂ©sentation particuliĂšre Dans le cas des envois asynchrones, le retour doit ĂȘtre explicite Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 77
78.
Les types de
messages Sd diagramme1 Objet1: Objet2: Objet3::client Message 1( ) Message 2( ) Message 3( ) Message 5( ) Message 6( ) Retour Message 3( ) Message synchrone Message asynchrone Message 4( ) Activation dâun objet Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 78
79.
Exemple Le diagramme de
séquence Les diagrammes UML S. Mesfar 79
80.
Comité de programme Comité d'organisation PAPIERAuteur RAPPORTLecteur Appel(
) Enregistrer le papier Papier enregistré Affecter_lecteur( ) Note( ) Rédiger( ) Envoi Enreg_papier(true) Evalué( ) Papier évalué Exemple2 Le diagramme de séquence Les diagrammes UML S. Mesfar 80
81.
Exemple3 Le diagramme de
séquence Les diagrammes UML S. Mesfar 81
82.
Autres types de
messages Dans un diagramme de sĂ©quence, il peut y avoir dâautres types de messages tels que: Le diagramme de sĂ©quence Les diagrammes UML âąmessage minutĂ© (timeout) : Bloque l'expĂ©diteur pendant un temps donnĂ© (qui peut ĂȘtre spĂ©cifiĂ© dans une contrainte), en attendant la prise en compte du message par le rĂ©cepteur. L'expĂ©diteur est libĂ©rĂ© si la prise en compte n'a pas eu lieu pendant le dĂ©lai spĂ©cifiĂ©. âą message dĂ©robant : Le message est mis en attente dans une liste d'attente de traitement chez le rĂ©cepteur. S. Mesfar 82
83.
S. Mesfar 83 Le
diagramme de sĂ©quence Les diagrammes UML Pseudo-code Lâajout de pseudo-code sur la partie gauche du diagramme permet la reprĂ©sentation des boucles et des branchements alternatifs ïżœ les diagrammes de sĂ©quence peuvent reprĂ©senter la forme gĂ©nĂ©rale dâune interaction , au-delĂ de la seule prise en compte dâun scĂ©nario particulier ïżœ
84.
S. Mesfar 84 Le
diagramme de sĂ©quence Les diagrammes UML Pseudo-code ïżœ
85.
Diagramme de séquences
: Fragment dâinteraction ou fragments combinĂ©s ï±Un fragment dâinteraction se reprĂ©sente globalement comme un diagramme de sĂ©quence dans un rectangle avec indication dans le coin Ă gauche du nom du fragment. ï±Un port dâentrĂ©e et un port de sortie peuvent ĂȘtre indiquĂ©s pour connaĂźtre la maniĂšre dont ce fragment peut ĂȘtre reliĂ© au reste du diagramme. Dans le cas oĂč aucun port nâest indiquĂ© câest lâensemble du fragment qui est appelĂ© pour exĂ©cution Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 85
86.
Fragment dâinteraction Le diagramme
de séquence Les diagrammes UML S. Mesfar 86
87.
ï±Un fragment dâinteraction
dit combinĂ© correspond Ă un ensemble dâinteractions auquel on applique un opĂ©rateur. ï±Un frag combinĂ© se reprĂ©sente globalement comme un diagramme de sĂ©quence avec indication dans le coin Ă gauche du nom de lâopĂ©rateur. ï±13 opĂ©rateurs ont Ă©tĂ© dĂ©finis dans UML : alt, opt, loop, par, strict/weak, break, ignore/consider, critical, negative, assertion et ref. Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 87
88.
ï±LâopĂ©rateur alt : correspond
Ă une instruction de test avec une ou plusieurs alternatives possibles. Il est aussi permis dâutiliser les clauses de type sinon. Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 88
89.
ï±LâopĂ©rateur opt : LâopĂ©rateur
opt (optional) correspond Ă une instruction de test sans alternative (sinon). Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 89
90.
ï±LâopĂ©rateur loop correspond Ă
une instruction de boucle qui permet dâexĂ©cuter une sĂ©quence dâinteraction tant quâune condition est satisfaite. Il est possible aussi dâutiliser une condition portant sur un nombre minimum et maximum dâexĂ©cution de la boucle en Ă©crivant : loop min, max. Dans ce cas, la boucle sâexĂ©cutera au minimum min fois et au maximum max fois Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 90
91.
ï±LâopĂ©rateur par LâopĂ©rateur par
(parallĂšle) permet de reprĂ©senter deux sĂ©ries dâinteractions qui se dĂ©roulent en parallĂšle. Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 91
92.
ï±Les opĂ©rateurs strict
et weak sequencing Les opĂ©rateurs strict et weak permettent de reprĂ©senter une sĂ©rie dâinteractions dont certaines sâopĂšrent sur des objets indĂ©pendants : ïżœ LâopĂ©rateur strict est utilisĂ© quand lâordre dâexĂ©cution des opĂ©rations doit ĂȘtre strictement respectĂ©. ïżœ LâopĂ©rateur weak est utilisĂ© quand lâordre dâexĂ©cution des opĂ©rations nâa pas dâimportance. Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 92
93.
ï±Les opĂ©rateurs strict
et weak sequencing Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 93
94.
ï±Les opĂ©rateurs break LâopĂ©rateur
break permet de reprĂ©senter une situation exceptionnelle correspondante Ă un scĂ©nario de rupture par rapport au scĂ©nario gĂ©nĂ©ral. Le scĂ©nario de rupture sâexĂ©cute si la condition de garde est satisfaite. Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 94
95.
ï±Les opĂ©rateurs ignore
et consider Les opĂ©rateurs ignore et consider sont utilisĂ©s pour des fragments dâinteractions dans lesquels on veut montrer que certains messages peuvent ĂȘtre soit absents sans avoir dâincidence sur le dĂ©roulement des interactions (ignore), soit obligatoirement prĂ©sents (consider). Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 95
96.
ï±Les opĂ©rateurs ignore
et consider Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 96
97.
ï±Les opĂ©rateurs critical LâopĂ©rateur
critical permet dâindiquer quâune sĂ©quence dâinteractions ne peut ĂȘtre interrompue compte tenu du caractĂšre critique des opĂ©rations traitĂ©es. On considĂšre que le traitement des interactions comprises dans la sĂ©quence critique est atomique. Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 97
98.
ï±LâopĂ©rateur critical Fragment dâinteraction Le
diagramme de séquence Les diagrammes UML S. Mesfar 98
99.
ï±Les opĂ©rateurs neg LâopĂ©rateur
neg (negative) permet dâindiquer quâune sĂ©quence dâinteractions est invalide. Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 99
100.
ï±Les opĂ©rateurs assert LâopĂ©rateur
assert (assertion) permet dâindiquer quâune sĂ©quence dâinteractions est lâunique sĂ©quence possible en considĂ©rant les messages Ă©changĂ©s dans le fragment. Toute autre configuration de message est invalide. Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 100
101.
ï±Les opĂ©rateurs ref LâopĂ©rateur
ref permet dâappeler une sĂ©quence dâinteractions dĂ©crite par ailleurs constituant ainsi une sorte de sous-diagramme de sĂ©quence. Fragment dâinteraction Le diagramme de sĂ©quence Les diagrammes UML S. Mesfar 101
102.
102 3.3. Les diagrammes d'activités
103.
Digramme d'activités UML permet
de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation, à l'aide de diagrammes d'activités (une variante des diagrammes d'états- transitions). ⹠Une activité représente une exécution d'un mécanisme, un déroulement d'étapes séquentielles. ⹠Le passage d'une activité vers une autre est matérialisé par une transition. ⹠Les transitions sont déclenchées par la fin d'une activité et provoquent le début immédiat d'une autre (elles sont automatiques). Le diagramme d'activités Les diagrammes UML
104.
Digramme d'activités En théorie,
tous les mĂ©canismes dynamiques pourraient ĂȘtre dĂ©crits par un diagramme d'activitĂ©s, mais seuls les mĂ©canismes complexes ou intĂ©ressants mĂ©ritent d'ĂȘtre reprĂ©sentĂ©s. âą Buts : 1. DĂ©crire le comportement gĂ©nĂ©rique dâun cas dâutilisation 2. DĂ©crire en dĂ©tail le comportement dâune opĂ©ration 3. ModĂ©liser les processus mĂ©tiers Le diagramme d'activitĂ©s Les diagrammes UML
105.
Le diagramme dâactivitĂ©s
est organisĂ©e par rapport aux actions et destinĂ©e Ă reprĂ©senter le comportement interne dâune opĂ©ration ou dâun cas d âutilisation. Mesurer tempĂ©rature Chauffer Refroidir AĂ©rerArrĂȘter chauffage [trop froid] [trop chaud] « synchronisation » Le diagramme d'activitĂ©s Les diagrammes UML
106.
âą Exemple de
Diagramme d'activités : Le diagramme d'activités Les diagrammes UML
107.
Le but du
diagramme d'activitĂ©s âą Diagramme d'activitĂ©s est utilisĂ© pour: â ModĂ©liser un workflow dans un use case ou entre plusieurs use cases. â SpĂ©cifier une opĂ©ration (dĂ©crire la logique dâune opĂ©ration) âą Le diagramme d'activitĂ©s est le plus appropriĂ© pour modĂ©liser la dynamique dâune tĂąche, dâun use case lorsque le diagramme de classe nâest pas encore stabilisĂ©. Le diagramme d'activitĂ©s Les diagrammes UML
108.
Notion du diagramme
d'activitĂ©s Diagramme d'activitĂ©s = âą ensemble d'activitĂ©s liĂ©s par: â Transition (sequentielle) â Transitions alternatives (conditionnelle) â Synchronisation (disjonction et conjonctions d'activitĂ©s) â ItĂ©ration âą + 2 Ă©tats: Ă©tat de dĂ©part et Ă©tat de terminaison âą Swimlanes: reprĂ©sente le lieu, le responsable des activitĂ©s. Le diagramme d'activitĂ©s Les diagrammes UML
109.
Notion du diagramme
d'activitĂ©s âąEtat de dĂ©part âąEtat de terminaison âąTransition âąTransition Alternative [ ] [ ] Le diagramme d'activitĂ©s Les diagrammes UML
110.
Notion du diagramme
d'activités Synchronisation disjonctive et conjonctive Le diagramme d'activités Les diagrammes UML
111.
Notion du diagramme
d'activités Itération Le diagramme d'activités Les diagrammes UML
112.
Exemple de Diagramme
d'activitĂ©s : Swimlanes / partitions Ou couloirs dâactivitĂ©s Le diagramme d'activitĂ©s Les diagrammes UML
113.
Le diagramme d'activités Les
diagrammes UML Exemple de Diagramme d'activités :
114.
Les nĆuds de
contrĂŽle âą Il existe plusieurs types de nĆuds de contrĂŽle: â nĆud initial(initial node); â nĆud de fin d'activitĂ©s(final node); â nĆud de dĂ©cision(decision node); â nĆud de fusion(merge node); â nĆud de bifurcation(fork node); â nĆud dâunion(join node). Le diagramme d'activitĂ©s Les diagrammes UML
115.
Le diagramme d'activités Les
diagrammes UML
116.
diagramme d'activités ⹠Partitions
/ swimlanes ou couloirs dâactivitĂ©s Le diagramme d'activitĂ©s Les diagrammes UML
117.
117 Chap 4 : Analyse
statique
118.
118 Analyse statique Lâanalyse statique
permet de reprĂ©senter lâensemble des classes, dâinterfaces et de paquetages ainsi que leurs relations. âą Une classe dĂ©crit un ensemble dâobjets (instances de la classe). âą Une association dĂ©crit un ensemble de liens (instances de lâassociation).
119.
119 4.1. Les diagrammes
de classes dâanalyse
120.
120 Le diagramme de
classes Les diagrammes UML Utilisation âą Lors de lâanalyse et de la conception: â DĂ©finitions formelles des objets qui composent le systĂšme Ă partir des cas dâutilisation et des diagrammes dâinteraction (sĂ©quence ou collaboration). â Bases conceptuelles pour les diagrammes dâĂ©tat-transition, de dĂ©ploiement, ... âą Lors de lâimplĂ©mentation : â GĂ©nĂ©ration automatique des structures statiques du systĂšme (classes, relations, ...).
121.
121 Le diagramme de
classes Les diagrammes UML ïżœLe plus important de la modĂ©lisation O.O. ïżœLe seul obligatoire lors dâune telle modĂ©lisation ïżœ fournit une reprĂ©sentation abstraite des objets du systĂšme qui vont interagir ensemble pour rĂ©aliser les cas dâutilisation ïżœVue statique : les Ă©lĂ©ments principaux sont : les classes et leurs relations
122.
122 Le diagramme de
classes Les diagrammes UML Notion de classe DĂ©finition : Une classe est une description dâun ensemble dâobjets ayant une sĂ©mantique, des attributs, des mĂ©thodes et des relations en commun. Un objet est une instance dâune classe. Objet de type VoitureClasse
123.
âą Une classe
est une description abstraite dâun ensemble dâobjets ayant : â des propriĂ©tĂ©s similaires, â un comportement commun, â des relations communes avec dâautres objets â des sĂ©mantiques communes âą Chaque classe possĂšde : â une composante «statique» : attributs ou champs possĂ©dant une valeur â une composante «dynamique» : mĂ©thodes qui reprĂ©sentent le comportement commun des objets de la classe Liste des attributs Liste des mĂ©thodes Nom de la classe 123S. Mesfar Le diagramme de classes : Quâest ce quâune classe ? Les diagrammes UML
124.
124 Le diagramme de
classes Les diagrammes UML Notion de classe Attribut = propriĂ©tĂ© nommĂ©e d âune classe la portĂ©e standard dâun attribut est limitĂ© Ă un objet âą Syntaxe â visibilitĂ© nom : type = valeur initiale âą VisibilitĂ© â + public : propriĂ©tĂ© ou classe visible partout â # protĂ©gĂ© : propriĂ©tĂ© ou classe visible dans la classe et par tous ses descendants â - privĂ© : propriĂ©tĂ© ou classe visible uniquement dans la classe â ~ package : propriĂ©tĂ© ou classe visible uniquement dans le paquetage oĂč la classe est dĂ©finie âą Attribut de classe â quand cette portĂ©e sâapplique Ă la classe elle mĂȘme, on parle dâattribut de classe (reprĂ©sentĂ© par le symbole $ ou soulignĂ©) âą Attribut dĂ©rivĂ© â attribut qui peut ĂȘtre dĂ©duit dâun ou plusieurs autres attributs (reprĂ©sentĂ© par le symbole /)
125.
125 Le diagramme de
classes Les diagrammes UML Notion de classe MĂ©thode = service que lâon peut demander Ă un objet pour rĂ©aliser un comportement âą Syntaxe â visibilitĂ© nom (paramĂštres) : type retour âą MĂȘmes notions que lâattribut â visibilitĂ© â mĂ©thode de classe
126.
126 Le diagramme de
classes Les diagrammes UML Notion de classe Notation ComplÚte Visibilité Static Dérivé ParamÚtre Retour Initialisation Nom de la Classe Fenetre + taille : Rectangle = 100,100 - visible : Boolean = true couleur : Color = blue #$ tailleMax : Rectangle #$ tailleMin : Rectangle /#$ tailleMoyenne : Rectangle + afficher() : Position + cacher() # setTaille(taille : Rectangle) } }Attributs Méthodes
127.
âą Un diagramme
de classes reprĂ©sente la structure du systĂšme sous la forme de classes et de relations entre ces classes âą Un diagramme dâobjets illustre les objets et les liens qui les unissent 127S. Mesfar Le diagramme de classes et le diagramme dâobjets Les diagrammes UML
128.
Le concept dâencapsulation âą
L'encapsulation est un mĂ©canisme consistant Ă rassembler les donnĂ©es et les mĂ©thodes au sein d'une structure en cachant l'implĂ©mentation de l'objet c-Ă -d en empĂȘchant l'accĂšs aux donnĂ©es par un autre moyen que les mĂ©thodes proposĂ©s pour la manipulation de lâobjet. ïżœ L'encapsulation permet donc de garantir l'intĂ©gritĂ© des donnĂ©es contenues dans l'objet. âą L'encapsulation permet de dĂ©finir des niveaux de visibilitĂ© des Ă©lĂ©ments de la classe. Ces niveaux de visibilitĂ© dĂ©finissent les droits d'accĂšs aux donnĂ©es selon que l'on y accĂšde par une mĂ©thode de la classe elle-mĂȘme, d'une classe hĂ©ritiĂšre, ou bien d'une classe quelconque. S. Mesfar 128 Le diagramme de classes Les diagrammes UML
129.
Le concept dâencapsulation â
Quatre niveaux de protection : âą Public (+) : accĂšs Ă partir de toute entitĂ© interne ou externe Ă la classe âą ProtĂ©gĂ© (#) : accĂšs Ă partir de la classe ou des sous- classes âą PrivĂ© (-) : accĂšs Ă partir des opĂ©rations de la classe âą Package (~ ou rien) : accĂšs Ă partir des classes du mĂȘme package 129S. Mesfar Le diagramme de classes Les diagrammes UML
130.
S. Mesfar 130 HĂ©ritage âą
HĂ©ritage â MĂ©canisme de transmission des propriĂ©tĂ©s (attributs, comportement) dâune classe vers ses sous classes â Ce qui est gĂ©nĂ©rique est dĂ©fini au niveau de la super-classe, ce qui est spĂ©cifique est dĂ©fini au niveau de la sous-classes âą GĂ©nĂ©ralisation/spĂ©cialisation â GĂ©nĂ©ralisation : mise en commun des propriĂ©tĂ©s communes entre diffĂ©rentes classes dans une super-classe. â SpĂ©cialisation : crĂ©ation dâune sous-classe par mise en avant de propriĂ©tĂ©s spĂ©cifiques non communes Ă toutes les classes de la super- classe Le diagramme de classes Les diagrammes UML
131.
S. Mesfar 131 HĂ©ritage
: exemple Généralisation Spécialisation personne étudiantpersonnel EnseignantAdministratif Le diagramme de classes Les diagrammes UML
132.
Exemple dâhĂ©ritage 132S. Mesfar Le
diagramme de classes Les diagrammes UML
133.
S. Mesfar 133 HĂ©ritage
multiple ïżœ une classe peut hĂ©riter des propriĂ©tĂ©s de plusieurs super-classes personne Ă©tudiantpersonnel EnseignantAdministratif Doctorant Le diagramme de classes Les diagrammes UML
134.
Exemple dâhĂ©ritage multiple 134S.
Mesfar Le diagramme de classes Les diagrammes UML
135.
Contraintes de gĂ©nĂ©ralisation âą
Une classe peut ĂȘtre spĂ©cialisĂ©e selon plusieurs critĂšres âą Certaines contraintes peuvent ĂȘtre posĂ©es sur les relations de gĂ©nĂ©ralisation âą Par dĂ©faut, la gĂ©nĂ©ralisation symbolise une dĂ©composition exclusive 135S. Mesfar Le diagramme de classes Les diagrammes UML
136.
Contraintes de généralisation {disjoint}
( = { exclusif } ) âą La contrainte {Disjoint} (ou {exclusif}) indique la participation exclusive dâun objet Ă lâune des collections spĂ©cialisĂ©es 136S. Mesfar Le diagramme de classes Les diagrammes UML
137.
Contraintes de généralisation {chevauchement}
(={ inclusif }) âą La contrainte {chevauchement} (ou {inclusif}) indique la participation possible dâun objet Ă plusieurs collections spĂ©cialisĂ©es 137S. Mesfar Le diagramme de classes Les diagrammes UML
138.
Contraintes de généralisation {ComplÚte}
â {IncomplĂšte} âą La contrainte {ComplĂšte} indique la gĂ©nĂ©ralisation est terminĂ©e : tout ajout de sous-classe est alors impossible âą Ă lâinverse, la contrainte {IncomplĂšte} indique une gĂ©nĂ©ralisation extensible 138S. Mesfar Le diagramme de classes Les diagrammes UML
139.
Le polymorphisme âą Alors
que l'hĂ©ritage concerne les classes (et leur hiĂ©rarchie), le polymorphisme est relatif aux mĂ©thodes des objets. âą On distingue gĂ©nĂ©ralement trois types de polymorphisme : 1. Le polymorphisme ad hoc (Ă©galement appelĂ© surcharge) : permet de dĂ©finir des opĂ©rateurs dont l'utilisation sera diffĂ©rente selon le type des paramĂštres qui leur sont passĂ©s ïżœ par exemple, il est possible de surcharger l'opĂ©rateur + et de lui faire rĂ©aliser des actions diffĂ©rentes selon qu'il s'agit d'une opĂ©ration entre deux entiers (addition) ou entre deux chaĂźnes de caractĂšres (concatĂ©nation) 2. Le polymorphisme paramĂ©trique (Ă©galement appelĂ© gĂ©nĂ©ricitĂ©) : reprĂ©sente la possibilitĂ© de dĂ©finir plusieurs fonctions de mĂȘme nom mais possĂ©dant des paramĂštres diffĂ©rents (en nombre et/ou en type) ïżœ Il rend ainsi possible le choix automatique de la bonne mĂ©thode Ă adopter en fonction du type de donnĂ©e passĂ©e en paramĂštre S. Mesfar 139 Le diagramme de classes Les diagrammes UML
140.
Le polymorphisme 3. Le
polymorphisme d'hĂ©ritage (Ă©galement appelĂ© redĂ©finition) : reprĂ©sente la possibilitĂ© de redĂ©finir une mĂ©thode dans des classes hĂ©ritant d'une classe de base. Il est alors possible d'appeler la mĂ©thode d'un objet sans se soucier de son type intrinsĂšque ïżœ faire abstraction des dĂ©tails des classes spĂ©cialisĂ©es d'une famille d'objet, en les masquant par une interface commune (qui est la classe de base). â Par exemple, un jeu d'Ă©chec comporte plusieurs objets roi, reine, fou, cavalier, tour, pion, hĂ©ritant chacun de l'objet piĂšce. La mĂ©thode mouvement() pourra, grĂące au polymorphisme d'hĂ©ritage, dâeffectuer le mouvement appropriĂ© en fonction de la classe de l'objet rĂ©fĂ©rencĂ© au moment de l'appel. Cela permettra notamment au programme dâappeler piĂšce.mouvement() sans avoir Ă se prĂ©occuper de la classe de la piĂšce. S. Mesfar 140 Le diagramme de classes Les diagrammes UML
141.
Exemple de polymorphisme
dâhĂ©ritage S. Mesfar 141 Le diagramme de classes Les diagrammes UML
142.
âą Une association
reprĂ©sente une relation entre les classes dâobjets Classe A Classe B SociĂ©tĂ© Personne Voiture Personne Classe A 142S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
143.
âą Une association
qui contient des attributs et qui ne participe pas Ă des relations avec dâautres classe est appelĂ©e classe attribuĂ©e. Classe A Classe B Classe C Attributs 143S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
144.
âą Une association
ternaire entre salle, étudiant et enseignant est réifiée comme une classe cours ayant deux attributs : début et fin Enseignant Salle Classe Cours Début Fin 144S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
145.
⹠Généralement, on
note les associations par une forme verbale, soit active, soit passive Classe A Classe B Société Personne Voiture Personne Forme verbale < travaille pour Est la propriÚté de > 145 S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
146.
Nommage des rĂŽles âą
Toute association binaire possĂšde 2 rĂŽles âą un rĂŽle dĂ©finit la maniĂšre dont une classe intervient dans une relation âą Le nommage des associations et le nommage des rĂŽles ne sont pas exclusifs lâun de lâautre âą IntĂ©rĂȘt des rĂŽles dans le cas oĂč plusieurs associations lient deux classes : distinction des concepts attachĂ©s aux associations SociĂ©tĂ© Personne< travaille pour employeur employĂ© Avion PersonnePilote Passagers 146S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
147.
Association réflexive ⹠Nommage
des rÎles indispensable à la clarté du diagramme Personne Enfants Parents 2 * 147S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
148.
MultiplicitĂ© des associations âą
La multiplicitĂ© est une information portĂ©e par le rĂŽle, qui quantifie le nombre de fois oĂč un objet participe Ă une instance de relation âą MultiplicitĂ© = indique le nombre dâinstances dâune classe qui peut ĂȘtre mise en relation avec une seul instance de la classe associĂ©e â 1 : obligatoire â 0..1 : optionnel â 0..* ou * : quelconque â 1..* : au moins 1 â 1..5, 10 : entre 1 et 5, ou 10 148S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
149.
MultiplicitĂ© des associations âą
1 : Chaque personne travaille pour une et une seule société (toutes les personnes ont un emploi) ⹠0 .. * : Une société emploie de zéro à plusieurs personnes Société Personne< travaille pour employeur employé 1 0..* 149S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
150.
Contraintes sur les
associations âą Contrainte dâassociation : porte sur une relation ou sur un groupe de relations (notĂ©e {contrainte }) âą Par exemple, placĂ©e sur un rĂŽle, la contrainte {ordonnĂ©e} dĂ©finit une relation dâordre entre les objets de la collection (les comptes) qui sont liĂ©s Ă une personne Personne ComptePropriĂ©taire {ordonnĂ©e}1 0..n 150S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
151.
Contraintes sur les
associations âą La contrainte {sous-ensemble} indique quâune collection est incluse dans une autre collection âą La contrainte {Ou-exclusif} prĂ©cise que, pour un objet donnĂ©, une seule association parmi un groupe dâassociations est valide Classe Personne UniversitĂ© Personne {Sous ensemble} Parents dâĂ©lĂšve DĂ©lĂ©guĂ©s * * {OU-exclusif} Enseignants Ătudiants * * 151 S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
152.
Restriction des associations âą
La restriction (dite qualification en UML) dâune association consiste Ă sĂ©lectionner un sous-ensemble dâobjets parmi lâensemble des objets qui participent Ă une association rĂ©alisĂ©e au moyen dâune clĂ©, ensemble dâattributs particuliers. âą Un objet qualifiĂ© et une valeur de qualificatif gĂ©nĂšrent un objet cible liĂ© unique 152S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
153.
Association particuliĂšre :
AgrĂ©gation âą Une agrĂ©gation est une association non symĂ©trique : lâune des extrĂ©mitĂ©s joue un rĂŽle prĂ©dominant par rapport Ă lâautre âą Elle se justifie lorsque une classe B « fait partie » intĂ©grante dâune classe A. âą Exemple: 153S. Mesfar Livre MotChapitre 1..* 1..*1..* 1..* Le diagramme de classes : Les associations Les diagrammes UML
154.
Agrégation particuliÚre :
Composition âą La composition est une forme particuliĂšre dâagrĂ©gation âą Le composant est « physiquement » contenu dans lâagrĂ©gat âą La composition implique une contrainte sur la valeur de la multiplicitĂ© du cotĂ© de lâagrĂ©gat : (0 ou 1) 154S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
155.
Agrégation particuliÚre :
Composition âą La composition peut ĂȘtre modĂ©lisĂ©e au moyen dâattributs âą La notation par composition doit ĂȘtre retenue lorsque dâun attribut participe Ă des relations 155S. Mesfar Le diagramme de classes : Les associations Les diagrammes UML
156.
156 Composition Le diagramme de
classes : Les associations Les diagrammes UML
157.
157 Le diagramme de
classes : Les associations Les diagrammes UML Une Université contient au moins un département. Des départements peuvent avoir différents professeurs. Détruire une université détruit ses départements, mais en aucun cas ne met fin à la vie des professeurs. En C++ : class Professeur; class Departement { ... private: // Agrégation Professeur* enseignants[5]; . .. }; class Universite { ... private: // Composition Departement facultes[20]; ... };
158.
158 4.2. Les diagrammes dâobjets
159.
Un diagramme de
dâobjets : âą ReprĂ©sente les liens structurels entre instances de classes âą Facilite la comprĂ©hension de structures complexes âą Trois reprĂ©sentations possibles des instances : 159S. Mesfar Le diagramme dâobjets Les diagrammes UML
160.
âą les valeurs
des attributs sont optionnelles ainsi que les liens entre objets 160S. Mesfar Le diagramme dâobjets Les diagrammes UML
161.
Diagramme dâobjets :
liens entre objets âą Les liens des associations rĂ©flexives peuvent relier un objet Ă lui mĂȘme 161S. Mesfar Le diagramme dâobjets Les diagrammes UML
162.
Diagramme dâobjets :
liens entre objets âą Les liens dâaritĂ© supĂ©rieure Ă 2 ou la multiplicitĂ© peuvent ĂȘtre reprĂ©sentĂ©s : 162S. Mesfar Le diagramme dâobjets Les diagrammes UML
163.
Diagramme dâobjets :
liens entre objets âą Les objets composĂ©s de sous-objets peuvent ĂȘtre visualisĂ©s : âą Les objets composites sont instances de classes composites : 163S. Mesfar Le diagramme dâobjets Les diagrammes UML
164.
Diagramme dâobjets :
structures complexes âą Les diagrammes dâobjets facilitent la comprĂ©hension et lâĂ©laboration dâun diagramme de classes : 164S. Mesfar Le diagramme dâobjets Les diagrammes UML
165.
165 Chap 5 : La
conception
166.
Rappel des concepts
de base âą Classe â attribut â mĂ©thode âą Association â rĂŽle â cardinalitĂ© â AgrĂ©g./Comp./Associative/QualifiĂ©e o1 o2 o1 o2 o3 o4 o5 o1 o2 o3 ïź Objet ïź Lien ïź Inclusion ensembliste ïź HĂ©ritage M1 M0 La conception Les diagrammes UML
167.
De quoi parle-t-on
? Analyse Objets du monde rĂ©el Objets du logiciel Algorithme du monde rĂ©el (scĂ©nario) Comment âlogiqueâ ? Conception Objets du langage Algorithme du logiciel (scĂ©nario) Comment âphysiqueâ ? Code ModĂšle conceptuel ModĂšle logique ModĂšle physique La conception Les diagrammes UML
168.
âą Deux niveaux
de conception : â Logique : indĂ©pendante de lâenvironnement de rĂ©alisation. â Physique : liĂ©e Ă des particularitĂ©s des langages de programmation ou de lâenvironnement dâexĂ©cution 168 La conception Les diagrammes UML
169.
169 ïżœ Un des
principaux soucis de lâactivitĂ© de conception est de dĂ©velopper un design qui facilite lâajustement du systĂšme aux changements. Pendant la conception: ïŹ Importante qualitĂ© logicielle en jeu ïżœ Ă©volutivitĂ© ïŹ anticipation du changement ïżœ Modularisation La phase de conception vise Ă : ï± dĂ©terminer quels seront les composants du logiciel Ă dĂ©velopper, ï± prĂ©ciser les caractĂ©ristiques de ces composants, ï± concevoir les algorithmes permettant Ă ces composants dâeffectuer les activitĂ©s dont ils sont responsables. La conception Les diagrammes UML
170.
170 5.1. Les diagrammes
de package
171.
Chapitre 9: Architecture
et conception de logiciel 171 DiffĂ©rentes façons de subdiviser un systĂšme â Un systĂšme distribuĂ© est divisĂ© en clients et serveurs â Un systĂšme est divisĂ© en sous-systĂšmes â Un sous-systĂšme peut ĂȘtre subdivisĂ© en paquetages â Un paquetage est composĂ© de classes â Une classe est composĂ©e de mĂ©thodes Le diagramme de package Les diagrammes UML
172.
Packages Le diagramme de
package Les diagrammes UML
173.
Soit le cas
ââRĂ©servation de vols dans une agence de voyagesââ 1° Des compagnies aĂ©riennes proposent diffĂ©rents vols. 2° Un vol est ouvert Ă la rĂ©servation et fermĂ© sur ordre de la compagnie. 3° Un client peut rĂ©server un ou plusieurs vols, pour des passagers diffĂ©rents. 4° Une rĂ©servation concerne un seul vol, et un seul passager. 5° Une rĂ©servation peut ĂȘtre annulĂ©e ou confirmĂ©e. 6° Un vol a un aĂ©roport de dĂ©part et un aĂ©roport dâarrivĂ©e. 7° Un vol a un jour et une heure de dĂ©part et un jour et une heure dâarrivĂ©e. 8° Un vol peut comporter des escales dans des aĂ©roports 9° Une escale a une heure dâarrivĂ©e et une heure de dĂ©part. 10° Chaque aĂ©roport dessert une ou plusieurs villes Le diagramme de package â Etude de cas Les diagrammes UML
174.
CompagnieAerienne VolPropose 1..* ïżœ ModĂ©lisation
de la phrase : 1° Des compagnies aĂ©riennes proposent diffĂ©rents vols. CompagnieAerienne et Vols sont 2 objets mĂ©tiers : 2 classes âą Un vol est rĂ©alisĂ© par une seule compagnie mais partagĂ© par plusieurs affrĂ©teurs CompagnieAerienne VolPropose 1..* affrĂ©teur 1..* Le diagramme de package â Etude de cas Les diagrammes UML
175.
ïżœ ModĂ©lisation de
la phrase : 2° Un vol est ouvert Ă la rĂ©servation et fermĂ© sur ordre de la compagnie. ïżœ Tout objet peut avoir un Ă©tat (diagramme dâĂ©tats). ïżœ Dans un diagramme de classes tout concept dynamique est modĂ©lisĂ© en opĂ©ration. ïżœ Il faut reprĂ©senter la 2° phrase par 2 opĂ©rations : ouvrirReservation( ) et fermerReservation( ) ïżœ Dans quelle classe ? ResponsabilitĂ© dâune classe CompagnieAerienne Propose 1..* affrĂ©teur 1..* Vol Ă©tat (ouvert, fermĂ©) CompagnieAerienne Propose 1..* affrĂ©teur 1..* Vol ouvrirVol( ) fermerVol( ) ïżœ Les opĂ©rations sont dĂ©clarĂ©es dans lâobjet dans lequel elles doivent sâexĂ©cuter ïżœ Les autres pourront dĂ©clencher ces opĂ©rations par envoi de messages ïżœ Le classe CompagnieAerienne a une association avec la classe vol. Le diagramme de package â Etude de cas Les diagrammes UML
176.
ïżœ ModĂ©lisation des
phrases : 7° Un vol a un jour et une heure de dĂ©part et un jour et une heure dâarrivĂ©e. ïżœ Les dates et les heures de dĂ©part et dâarrivĂ©e ne reprĂ©sentent que des valeurs : attributs. CompagnieAerienne Propose 1..* affrĂ©teur 1..* Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee ïżœ Pour savoir si un Ă©lĂ©ment doit ĂȘtre reprĂ©sentĂ© en attribut ou en objet : ïżœ Sâil nâ y a que sa valeur qui est intĂ©ressante : câest plutĂŽt un attribut. ïżœ Si plusieurs questions peuvent concerner lâĂ©lĂ©ment, alors il faut le reprĂ©senter en objet. Le diagramme de package â Etude de cas Les diagrammes UML
177.
ïżœ ModĂ©lisation des
phrases : 6° Un vol a un aĂ©roport de dĂ©part et un aĂ©roport dâarrivĂ©e. ïżœ ModĂ©lisation peu parlante. ïżœ Par quoi peut-on reprĂ©senter lâĂ©lĂ©ment ââAĂ©roportââ ? 3 rĂ©ponses sont envisageables : 1. Soit avec une classe et une association de multiplicitĂ© 2 { ordered} 2 Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee aeroportDepart aeroportArivvee AĂ©roport nom Le diagramme de package â Etude de cas Les diagrammes UML
178.
ïżœ ModĂ©lisation des
phrases : 6° Un vol a un aĂ©roport de dĂ©part et un aĂ©roport dâarrivĂ©e. ïżœ ModĂ©lisation non correcte. Tout aĂ©roport peut ĂȘtre de dĂ©part et dâarrivĂ©e. 2. Soit avec 2 classes 1 Vols ouvrirReservation() fermerReservation() dateDepart heureDepart dateArrivee heureArrivee aeroportDepartr aeroportArivvee AĂ©roport nom AeroportDepart AeroportArrivee1 Le diagramme de package â Etude de cas Les diagrammes UML
179.
ïżœ ModĂ©lisation des
phrases : 6° Un vol a un aĂ©roport de dĂ©part et un aĂ©roport dâarrivĂ©e. ïżœ Le rĂŽle de chaque association prĂ©cise son sens. 2. Soit avec 2 associations 1 Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee AĂ©roport Nom ⊠1 DĂ©part ArrivĂ©e Le diagramme de package â Etude de cas Les diagrammes UML
180.
ïżœ ModĂ©lisation des
phrases : 10° Chaque aĂ©roport dessert une ou plusieurs villes AĂ©roport dessert 1..* Ville 0..* ïżœ Si on considĂšre que desservir une ville signifie lâaĂ©roport le plus proche, il nâ en y a quâun : la multiplicitĂ© est de 1 ïżœ Si on considĂšre que desservir une ville signifie les aĂ©roports dans un rayon de 35 km : la multiplicitĂ© est de 0..* ïżœ On ne peut pas savoir la multiplicitĂ© de ââAĂ©roportââ Le diagramme de package â Etude de cas Les diagrammes UML
181.
ïżœ ModĂ©lisation des
phrases : 8° Un vol peut comporter des escales dans des aĂ©roports 9° Une escale a une heure dâarrivĂ©e et une heure de dĂ©part. Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee AĂ©roport nom1 1 Depart Arrivee Escale heureArrivee heureDepart 0..* ïżœ Une escale a les propriĂ©tĂ©s heure dâarrivĂ©e et heure de dĂ©part, câest donc un objet. ïżœ Quelles sont alors les multiplicitĂ©s entre ââVolsââ et ââEscaleââ, entre ââEscaleââ et ââAeroportââ et entre ââAeroportââ et âVolsââ ? 0..* 0..* 1 1 0..* Le diagramme de package â Etude de cas Les diagrammes UML
182.
ïżœ ModĂ©lisation des
phrases : 8° Un vol peut comporter des escales dans des aĂ©roports 9° Une escale a une heure dâarrivĂ©e et une heure de dĂ©part. ïżœ ââEscaleââ a peu dâinformations propres. Elle nâest quâune partie de ââVolââ . ïżœ On peut la reprĂ©senter comme une spĂ©cialisation de ââAĂ©roportââ . Mais elle nâest pas totalement un aĂ©roport. ïżœ La meilleure solution serait de la modĂ©liser comme une classe dâassociation entre et âVolsââ et ââAĂ©roportââ. Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee AĂ©roport nom 1 1 DĂ©part ArrivĂ©e Escale heureArrivee heureDepart Escale 0..*0..* 0..* 0..* {Ordered} Le diagramme de package â Etude de cas Les diagrammes UML
183.
ïżœ ModĂ©lisation des
phrases : 4° Une rĂ©servation concerne un seul vol, et un seul passager. 5° Une rĂ©servation peut ĂȘtre annulĂ©e ou confirmĂ©e. ïżœ La rĂ©servation et le passager sont 2 concepts mĂ©tier : 2 classes dâobjets ïżœ Un rĂ©servation concerne un seul vol et un seul passager: donc 2 associations entre ââVolââ et ââRĂ©servationââ et entre ââRĂ©servationââ et ââPassagerââ. ïżœ La 5° phrase se traduit par lâajout de 2 opĂ©rations annuler( ) et confirmer( ) dans ââReservationââ. Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee Passager 1 1 concerne RĂ©servation Annuler( ) Confirmer( ) concerne Le diagramme de package â Etude de cas Les diagrammes UML
184.
ïżœ ModĂ©lisation des
phrases : 3° Un client peut rĂ©server un ou plusieurs vols, pour des passagers diffĂ©rents. ïżœ Il faut discerner un client dâun passager a effectuĂ© 0..* 0..* 0..* Vol Passager 1 1 concerne RĂ©servation Annuler( ) Confirmer( ) concerne Client 1 Le diagramme de package â Etude de cas Les diagrammes UML
185.
ïżœ Le diagramme
des classe complet est : Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee AĂ©roport nom 1 1 dĂ©part arrivĂ©e InfosEscale heureArrivee heureDepart escale 0..*0..* 0..* 0..* {ordered} Ville 0..* Passager 1 concerne RĂ©servation Annuler( ) Confirmer( ) Client a effectuĂ© 0..* 1 0..* 1 concerne CompagnieAerinne Propose 1..* 1..* nom PrĂ©nom adresse tĂ©lĂ©phone e-mail nom nom PrĂ©nom nom date numĂ©ro Le diagramme de package â Etude de cas Les diagrammes UML
186.
ïżœ Diagramme des
classe complet et annotĂ© InfosEscale heureArrivee heureDepart Vol ouvrirVol( ) fermerVol( ) dateDepart heureDepart dateArrivee heureArrivee AĂ©roport nom 1 1 dĂ©part arrivĂ©e escale 0..*0..* 0..* 0..* {ordered} Ville 0..* Passager 1 concerne RĂ©servation Annuler( ) Confirmer( ) Client a effectuĂ© 0..* 1 0..* 1 concerne Propose 0..1 1..* nom PrĂ©nom adresse tĂ©l e-mail nom PrĂ©nom nom {frozen} {frozen} CompagnieAerinne nom numĂ©ro date numĂ©ro Le diagramme de package â Etude de cas Les diagrammes UML
187.
ïżœ Le diagramme
des classe complet devient : InfosEscale heureArrivĂ©e heureDĂ©part ââ mĂ©taclasse ââ VolGenerique ouvrirVol( ) fermerVol( ) jour heureDĂ©part heureArrivĂ©e /durĂ©e pĂ©riodevaliditĂ© AĂ©roport nom 1 1 dĂ©part arrivĂ©e escale 0..*0..* 0..* 0..* {ordered} Ville 0..* 1 concerne RĂ©servation Annuler( ) Confirmer( ) Client a effectuĂ© 0..* 1 0..* 1 concerne Propose 0..1 1 nom PrĂ©nom adresse tĂ©lĂ©phone e-mail Passager nom PrĂ©nom nom {frozen} {frozen} CompagnieAĂ©rienne nom numĂ©ro date numĂ©ro Vol ouvrirVol( ) fermerVol( ) dateDĂ©part dateArrivĂ©e {frozen}{AddOnly} dĂ©crit 0..* 1 1..* 0..* propose AffrĂ©teur Le diagramme de package â Etude de cas Les diagrammes UML
188.
ïżœ Le diagramme
des classes peut ĂȘtre rĂ©organisĂ© en packages InfosEscale heureArrivee heureDepart ââ metaclasse ââ VolGenerique ouvrirVol( ) fermerVol( ) jour heureDepart heureArrivee /durĂ©e periodevalidite AĂ©roport nom 1 1 dĂ©part arrivĂ©e escale 0..*0..* 0..* 0..* {ordered} Ville 0..* 1 concerne RĂ©servation Annuler( ) Confirmer( ) Client a effectuĂ© 0..* 1 0..* 1 concerne Propose 0..1 1..* nom PrĂ©nom adresse tĂ©Ă©phonel e-mail Passager nom PrĂ©nom nom {frozen} {frozen} CompagnieAerinne nom numĂ©ro date numero Vol ouvrirVol( ) fermerVol( ) dateDepart dateArrivee {frozen}{AddOnly} dĂ©crit 0..* 1 1..* 0..* propose AffrĂ©teur Le diagramme de package â Etude de cas Les diagrammes UML
189.
ïżœ RĂ©duire la
dĂ©pendance mutuelle afin dâaugmenter la modularitĂ© et lâĂ©volutivitĂ© dâune application 0..* 1 concerne {frozen} RĂ©servation Annuler( ) Confirmer( ) date numĂ©ro RĂ©servations Vol ouvrirVol( ) fermerVol( ) dateDepart dateArrivee Vol Le diagramme de package â Etude de cas Les diagrammes UML
190.
RĂ©servations RĂ©servation Annuler( ) Confirmer( ) Client a
effectuĂ© 0..* 1 0..* 1 concerne nom PrĂ©nom adresse tĂ©lĂ©phone e-mail Passager nom PrĂ©nom {frozen} date numĂ©ro Vol InfosEscale heureArrivee heureDepart ââ metaclasse ââ VolGenerique ouvrirVol( ) fermerVol( ) jour heureDepart heureArrivee /durĂ©e periodevalidite AĂ©roport nom 1 1 dĂ©part arrivĂ©e escale 0..*0..* 0..* 0..* {ordered} Ville Propose 0..1 1 nom CompagnieAerinne nom numĂ©ro Vol ouvrirVol( ) fermerVol( ) dateDepart dateArrivee {frozen}{AddOnly} decrit 0..* 1 1..* 0..* propose AffrĂ©teur 0..* 1 concerne {frozen} Le diagramme de package â Etude de cas Les diagrammes UML
191.
GĂ©nĂ©ralisation et rĂ©utilisation ïżœ
On veut Ă©largir ce domaine aux voyages par bus que des transporteurs assurent. ïżœ Un voyage en bus Ă une ville de dĂ©part et un ville dâarrivĂ©e avec des dates et des heures associĂ©es. ïżœ Un trajet peut comporter des arrĂȘts dans des villes intermĂ©diaires. ïżœ Un client peut rĂ©server un ou plusieurs voyages pour un ou plusieurs passagers VoyageEnBus OuvrirVoyage( ) fermerVoyage( ) dateDepart dateArrivee VoyagesBus ReservationsBus ReservationBus Annuler( ) Confirmer( ) date numĂ©ro 0..* 1 concerne {frozen} Le diagramme de package â Etude de cas Les diagrammes UML
192.
concerne VoyagesBus InfosArret heureArrivee heureDepart VoyageEnBus ouvrirVoyage( ) fermerVoyage() dateDepart heureDepart dateArrivee heureArrivee /durĂ©e 1 1 dĂ©part arrivĂ©e arrĂȘt 0..*0..* 0..* 0..* {ordered} Propose 0..1 1 Voyagiste nom rĂ©fĂ©rence Ville nom ReservationsBus 0..* 1..* concerne Client nom PrĂ©nom adresse tĂ©lĂ©phone e-mail Passager nom
PrĂ©nom {frozen} ReservationBus Annuler( ) Confirmer( ) date numĂ©ro a effectuĂ© 0..* 1 {frozen} Le diagramme de package â Etude de cas Les diagrammes UML
193.
Fusion des 2
modĂšles 1. Il faut isoler les classes communes dans des packages 2. Il faut factoriser les propriĂ©tĂ©s communes AVION Vols ReservationVols BUS ReservationBus VoyagesBus Lieux ïżœ Le diagramme de package â Etude de cas Les diagrammes UML
194.
Il faut isoler
les classes communes dans des packages ïżœ Vol (from Vols) ReservationVol (from ReservationsVols) ReservationBus (from ReservationsBus) VoyageEnBus (from VoyagesBus) concerne concerne {frozen} {frozen} 1 1 RĂ©servations 0..* 1 concerneClient nom PrĂ©nom adresse tĂ©l e-mail Passager nom PrĂ©nom RĂ©servation Annuler( ) Confirmer( ) date numĂ©ro {frozen} a effectuĂ© 0..*1 Classe abstraite Le diagramme de package â Etude de cas Les diagrammes UML
195.
VolsVoyagesBus LieuxPackage réutilisable ReservationsBus Réservations ReservationsVols Packages spécialisés Package
gĂ©nĂ©ralisĂ© Le diagramme de package â Etude de cas Les diagrammes UML
196.
196 5.2. Les diagrammes
de classes de conception
197.
StĂ©rĂ©otypes âą MĂ©canisme dâextensibilitĂ© âą
SĂ©mantique du concept est insuffisante ïżœ le stĂ©rĂ©otype permet la mĂ©taclassification ïżœAjouter de nouvelles classes sans perdre la sĂ©mantique ïżœ Faciliter lâunification des sous-systĂšmes et catĂ©gories Le diagramme de classe : de lâanalyse Ă conception Les diagrammes UML
198.
198 StĂ©rĂ©otype : dĂ©finition âą
Un stĂ©rĂ©otype permet dâĂ©tendre les classes dĂ©jĂ existantes en leur donnant une signification sĂ©mantique diffĂ©rente. âą Si la classe A est un stĂ©rĂ©otype de la classe B, alors A se comporte comme B tout en ayant une signification sĂ©mantique diffĂ©rente. âą ReprĂ©sentation UML: <<stĂ©rĂ©otype>> Nom de la Classe Le diagramme de classe : de lâanalyse Ă conception Les diagrammes UML
199.
199 Utilisation des stéréotypes Stéréotypes
prĂ©dĂ©finis pour les classes dâanalyse (proposĂ©s par Jacobson): âą Boundary ou frontiĂšre ou interface âą Control ou contrĂŽle âą Entity ou entitĂ© ReprĂ©sentation de Jacobson Nom du stĂ©rĂ©otype Le diagramme de classe : de lâanalyse Ă conception Les diagrammes UML
200.
200 StĂ©rĂ©otypes⊠: boundary âą
La classe stĂ©rĂ©otypĂ©e <<Boundary>> modĂ©lise la communication entre les acteurs et les composantes internes du systĂšme (les interfaces homme/machine, les interfaces des systĂšmes (protocole de communication,âŠ) , interfaces des matĂ©riels (Ă©cran, clavier, imprimante,âŠ)) <<boundary>> InterfaceRechercheSimple Auteur ISBN Titre Rechercher() Le diagramme de classe : de lâanalyse Ă conception Les diagrammes UML
201.
201 StĂ©rĂ©otypes⊠: Entity âą
La classe stĂ©rĂ©otypĂ©e <<Entity>> modĂ©lise les informations persistantes du systĂšme. Exemples : classes qui contiennent des informations dâun Ă©tudiant, dâun employĂ©, ⊠<<Entity>> Livre code :entier titre : chaĂźne ISBN : entier nbrexemplaires:entier Getcode() GetTitre() FindByISBN (ISBN:entier) setNbrexemp(nbreexemplaires:entier) Le diagramme de classe : de lâanalyse Ă conception Les diagrammes UML
202.
202 Stéréotypes⊠: control «Control
classes are generally used to represent coordination, sequencing, transactions, and control of other objects. And it is often used to encapsulate control related to a specific use case » [I. Jacobson, G.Booch, J.Rumbaugh,âThe Unified Software Development Processâ, Addison Wesley, 1999] Le diagramme de classe : de lâanalyse Ă conception Les diagrammes UML
203.
203 StĂ©rĂ©otypes⊠: control âą
La classe stĂ©rĂ©otypĂ©e <<control>> assure la coordination entre classes âą Elle contrĂŽle le sĂ©quencement, ou coordonne l'exĂ©cution des objets contrĂŽlĂ©s. âą Elle contrĂŽle la concurrence entre classes contrĂŽlĂ©es, âą Elle est l'implantation d'un objet intangible, âą Au dĂ©part , on crĂ©e une classe "control" pour chaque use-case; cette classe gĂšre le flot d'Ă©vĂšnements dans le use-case, âą Au fur et Ă mesure de l'avancement de l'analyse, les classes "control« peuvent ĂȘtre supprimĂ©es, dĂ©coupĂ©es ou regroupĂ©es. <<control>> CTRLrecherche rechercherLivres() Le diagramme de classe : de lâanalyse Ă conception Les diagrammes UML
204.
204 <<control>> CTRLrecherche rechercherLivres() ⹠Classes stéréotypées
en relation <<Entity>> Livre auteur :entier titre : chaĂźne ISBN : entier nbrexemplaires:entier Getcode() GetTitre() FindByISBN (ISBN:entier) setNbrexemp(nbreexemplaires:entier) <<boundary>> InterfaceRechercheSimple Auteur ISBN Titre Rechercher() 0..* 0..* <DĂ©clencherrech Le diagramme de classe : de lâanalyse Ă conception Les diagrammes UML
205.
205 âą Les associations
entre les classes stĂ©rĂ©otypĂ©es suivent des rĂšgles assez strictes : â Les « boundary » ne peuvent ĂȘtre reliĂ©es quâaux « control » â Les « control » ont accĂšs aux « boundary », aux « entity » et aux autres contrĂŽles â Les « entity » ont accĂšs aux autres « entity » et ne sont reliĂ©es quâaux « control » ïżœ Pour aller plus loin : utiliser des partons de conception (les design patterns) Le diagramme de classe : de lâanalyse Ă conception Les diagrammes UML
206.
206 Le diagramme de
classe : de lâanalyse Ă conception Les diagrammes UML
207.
Exemple de la
localisation dâun DAB 207 Le diagramme de classe : de lâanalyse Ă conception Les diagrammes UML
208.
Conception détaillée Deux niveaux
de conception : - une Ă©tape logique: indĂ©pendante de lâenvironnement de rĂ©alisation: âą Conception dĂ©taillĂ©e des classes: trouver la meilleure maniĂšre de concevoir les structure logique, âą Conception dĂ©taillĂ©e des associations (typage, portĂ©e, rĂ©manence/persistance): â assurer la gestion des liens â traiter les classes associatives â optimiser la navigation âą DĂ©lĂ©gation: dĂ©pendance des relations dâagrĂ©gation et de composition. âą Raffiner la gĂ©nĂ©ralisation/spĂ©cialisation (hĂ©ritage simple ou multiple): â propriĂ©tĂ©s structurelles â Interface â propriĂ©tĂ©s comportementales - une Ă©tape physique: liĂ©e Ă des particularitĂ©s des langages de programmation ou de lâenvironnement dâexĂ©cution Raffinementdesdiagrammesstructurels 208 Le diagramme de classe de conception Les diagrammes UML
209.
Conception détaillée des
classes âą DĂ©finir le type des attributs identifiĂ©s en analyse. â Type de base + composĂ© âą Structure âą EnumĂ©ration âą SpĂ©cifier les Structures de DonnĂ©es. âą SpĂ©cifier les visibilitĂ©s des attributs et mĂ©thodes + prise en compte des propriĂ©tĂ©s (ordered, addOnly, frozen) âą SpĂ©cifier les mĂ©thodes + celles spĂ©cifiques Ă lâimplantation âą Montrer les dĂ©pendances + Classes spĂ©cifiques Le diagramme de classe de conception Les diagrammes UML
210.
Structure â DĂ©finition :
Ensemble dâattributs pouvant ĂȘtre regroupĂ©s. <<structure>> Date jour mois annĂ©es <<structure>> Adresse numRue rue codePostal ville pays 210 Le diagramme de classe de conception Les diagrammes UML
211.
EnumĂ©ration â DĂ©finition :
Ensemble de littĂ©raux dâĂ©numĂ©ration, ordonnĂ©. <<enumeration>> Jour Lundi Mardi Mercredi Jeudi Vendredi Samedi Dimanche <<enumeration>> Titre Secretaire President Tresorier VicePresident Membre Le diagramme de classe de conception Les diagrammes UML
212.
VisibilitĂ© des Ă©lĂ©ments âą
Restreindre l'accĂšs aux Ă©lĂ©ments d'un modĂšle âą ContrĂŽler et Ă©viter les dĂ©pendances entre classes (et paquetages) + public visible Ă lâextĂ©rieur de la classe # protĂ©gĂ© visible que dans la classe et ses sous-classes ï privĂ© visible dans la classe uniquement ~ package visible dans la package uniquement $ Ă©lĂ©ment de classe Remarques: âą Utile lors de la conception et de l'implĂ©mentation, pas avant ! -N'a pas vraiment de sens dans le modĂšle dâanalyse- âą La sĂ©mantique exacte dĂ©pend du langage de programmation ! 212 Le diagramme de classe de conception Les diagrammes UML
213.
DĂ©claration d'attributs [/] [
visibilitĂ© ] nom [ : type ] [card ordre] [ = valeur-initiale ] [ { props... } ] exemples: age +age /age - solde : Integer = 0 # age : Integer [0..1] # numsecu : Integer {frozen} # motsClĂ©s : String [*] {addOnly} $nbPersonne : Integer ïź Adapter le niveau de dĂ©tail au niveau d'abstraction ïź La non prĂ©cision de visibilitĂ© ïżœ privĂ©e Le diagramme de classe de conception Les diagrammes UML
214.
Déclaration d'opérations [ visibilité
] nom [ ( params ) ] [ : type ] [ { props... } ] getAge() + getAge() : Integer - updateAge( in date : Date ) : Boolean # getName() : String [0..1] +getAge() : Integer +addProject() +$main( in args : String [*] {ordered} ) ïź Adapter le niveau de dĂ©tail au niveau d'abstraction ïź La non prĂ©cision de visibilitĂ© ïżœ public Le diagramme de classe de conception Les diagrammes UML
215.
Conception détaillée des
classes : classes spĂ©cifiques âą Classe utilitaire ïżœ Exemple: fonctions mathĂ©matiques dâune bibliothĂšque « Utilitaire » Math Math Le diagramme de classe de conception Les diagrammes UML
216.
217 Contraintes de gestion
de lâassociation Par exemple : âą { ordered } : les Ă©lĂ©ments de la collection sont ordonnĂ©s âą { frozen } : fixĂ© lors de la crĂ©ation de l âobjet, ne peut pas changer âą { addOnly } : impossible de supprimer un Ă©lĂ©ment RelevĂ©DeCompte Ligne OpĂ©ration *{ordered,addOnly} lignes Le diagramme de classe de conception Les diagrammes UML
217.
218 RĂŽle : traduction B * R A
B 1 A R bs rs * b 1 a rolea carda carda rolea Le diagramme de classe de conception Les diagrammes UML
218.
219 Classe associative: traduction B * A
B 1 A R bs * b 1 a as * * Le diagramme de classe de conception Les diagrammes UML R
219.
Relation ternaire: traduction Le
diagramme de classe de conception Les diagrammes UML
220.
B * {ordered} R Role ordonné : traduction
générale par index A B 1 A R bs rs ib : integer * b Pour tout a, tous les rs ont un indice ib différent et couvrant l'intervalle de 1 au nombre de bs. 1 a rolea carda carda rolea Le diagramme de classe de conception Les diagrammes UML
221.
Pour tout a,
tous les bs ont un indice iRb différent et couvrant l'intervalle de 1 au nombre de bs. B * {ordered} R RÎle ordonné 1 - * : traduction par index A B * A bs bsa a 1 iRb : integer 1 Le diagramme de classe de conception Les diagrammes UML
222.
224 NavigabilitĂ© dâune Association ïżœLa
navigabilitĂ© permet de spĂ©cifier dans quel(s) sens il est possible de traverser l'association Ă l'exĂ©cution. ïżœOn interdit la navigation par une croix (X) du cĂŽtĂ© qui n'est pas atteignable. ïżœOn peut reprĂ©senter les associations navigables dans un seul sens par des attributs. Les attributs sont toujours navigables. Le diagramme de classe de conception Les diagrammes UML
223.
exist getAll nb empty Spécifier les méthodes
pour la gestion des liens set get a b R M1 M0 0..10..1 Remarque : i. Les mĂ©thodes (ajout/suppression) doivent prĂ©server la cohĂ©rence des cardinalitĂ©s et les contraintes (exemple : AddOnly) ii. Les mĂ©thodes de navigation doivent ĂȘtre cohĂ©rentes avec le sens de navigation iii. En cas de cardinalitĂ© > 1 ïżœ possibilitĂ© de prĂ©voir un attribut de type collection (surtout Ă dĂ©finir lors de lâimplĂ©mentation !! ) remove removeAll removeIdx add setAll insert a b R M1 M0 0..*0..1 Le diagramme de classe de conception Les diagrammes UML
224.
Classes de conception Le
diagramme de classe de conception Les diagrammes UML
225.
Classes de conception Le
diagramme de classe de conception Les diagrammes UML
226.
Classes de conception Le
diagramme de classe de conception Les diagrammes UML
227.
Classes de conception Le
diagramme de classe de conception Les diagrammes UML
228.
Classes de conception Le
diagramme de classe de conception Les diagrammes UML
229.
232 5.3. Notions dâabstraction et
dâinterfaces
230.
233 Le diagramme de
classes Notion de classe abstraite Les diagrammes UML Une classe abstraite est une classe dont au moins une mĂ©thode est abstraite Une mĂ©thode abstraite est dĂ©finie uniquement par son intitulĂ© sans code abstract void calcul_long(); ï±Dans les classes dĂ©rivĂ©es, la mĂ©thode abstraite doit ĂȘtre dĂ©crite ï± La mĂ©thode abstraite ne peut pas ĂȘtre private ï±On ne peut pas crĂ©er un objet dâune classe abstraite ï±Une classe abstraite est un type, il est possible de dĂ©finir des variables ou paramĂštres de ce type; mais il faut affecter un objet dâune classe concrĂšte, descendante
231.
234 Le diagramme de
classes Notion de classe abstraite Les diagrammes UML But dâune classe abstraite Une classe abstraite permet de dĂ©finir les caractĂ©ristiques communes Ă plusieurs classes. Une classe abstraite permet Ă un dĂ©veloppeur : ï±de fournir Ă d'autres dĂ©veloppeurs une partie de l'implĂ©mentation d'une classe ï±de laisser aux autres dĂ©veloppeurs la maniĂšre d'implĂ©menter le reste de la classe ï±d'imposer aux autres dĂ©veloppeurs d'implĂ©menter certaines mĂ©thodes s'ils veulent pouvoir utiliser ses classes
232.
âą Exemple: deux
classes Cercle, Carre qui possĂšdent des mĂ©thodes communes: â float surface() â void afficheInfo() dont les implĂ©mentations sont trĂšs diffĂ©rentes 235 Le diagramme de classes Notion de classe abstraite Les diagrammes UML
233.
âą Solution : abstract
class Figure{ private String nom; public String getNom( ){ return nom; } public abstract void afficheinfos( ); public abstract float surface( ); } 236 Le diagramme de classes Notion de classe abstraite Les diagrammes UML
234.
âą Les rĂšgles
usuelles d'hĂ©ritage s'appliquent aux classes abstraites. âą Les classes dĂ©rivĂ©es de Figure peuvent implĂ©menter complĂštement, partiellement, ou pas du tout, les mĂ©thodes abstraites de Figure. âą Suite de la solution : Figure f; f = new Cercle (âŠ); f.surface( ); // utiliser la liaison dynamique ... 237 Le diagramme de classes Notion de classe abstraite Les diagrammes UML
235.
âą Si A
est déclarée comme classe abstraite alors on ne peut pas créer d'instance de la classe. ⹠En revanche, on peut (on devrait) déclarer des variables de type A, et les instancier par n'importe quel objet de n'importe quelle classe concrÚte (non abstraite) dérivée de A. 238 Le diagramme de classes Notion de classe abstraite Les diagrammes UML
236.
239 Le diagramme de
classes Notion dâinterface Les diagrammes UML Une interface est une classe abstraite ayant les caractĂ©ristiques suivants: ï±toutes les mĂ©thodes sont abstraites et public, alors quâune classe abstraite peut avoir des mĂ©thodes non abstraites ï±tous les attributs sont static, alors quâune classe abstraite peut avoir des attributs ordinaires ï±toute classe peut hĂ©riter de plusieurs interfaces ï±une interface peut hĂ©riter dâune ou plusieurs interfaces mais elle ne peut pas hĂ©riter dâune classe ï±il nâest pas nĂ©cessaire dâindiquer abstract pour les mĂ©thodes et static pour les attributs
237.
240 Le diagramme de
classes Notion dâinterface Les diagrammes UML « interface » NomInterface NomClasse ou NomClasse Une classe qui implĂ©mente une interface doit dĂ©finir le corps (les instructions) de toutes ses mĂ©thodes abstraites implĂ©mente
238.
interface Chapeau{ void ajoute(Object
o); Object tire(); boolean estVide(); } class ChapeauDoubleFond implements Chapeau{... } class ChapeauTripleFond implements Chapeau{... } class TourCartes{ ⊠public void ajouteChapeau(Chapeau c){... } } 241 Le diagramme de classes Notion dâinterface Les diagrammes UML
239.
âą Le code
de TourCartes n'est pas liĂ© Ă une implĂ©mentation particuliĂšre de Chapeau. TourCartes t=new TourCartes(); Chapeau c=new ChapeauDoubleFond(); t.ajouteChapeau(c); âą Le seul moment oĂč est mentionnĂ© le choix d'implĂ©mentation est lors de la construction de l'objet. 242 Le diagramme de classes Notion dâinterface Les diagrammes UML
240.
âą IntĂ©rĂȘt : â
SĂ©paration interface publique/implĂ©mentation â Permet une forme dâhĂ©ritage multiple : âą Par exemple, une classe C2 peut Ă©tendre une classe C1 et implĂ©menter une interface I âą RĂŽles : â rĂŽle des interfaces: dĂ©claration des mĂ©thodes publiques â rĂŽle des classes: implĂ©mentation de ces mĂ©thodes 243 Le diagramme de classes Notion dâinterface Les diagrammes UML
241.
Une démarche couramment
utilisĂ©e pour bĂątir un diagramme de classes consiste Ă : 1. Trouver les classes du domaine Ă©tudiĂ©. Cette Ă©tape empirique se fait gĂ©nĂ©ralement en collaboration avec un expert du domaine. Les classes correspondent gĂ©nĂ©ralement Ă des concepts ou des substantifs du domaine. 2. Trouver les associations entre classes. Les associations correspondent souvent Ă des verbes, ou des constructions verbales, mettant en relation plusieurs classes, comme << est composĂ© de >>, << pilote >>, << travaille pour >>. S. Mesfar 244 Etapes de lâĂ©laboration dâun diagramme de classes Les diagrammes UML
242.
3. Trouver les
attributs des classes. Les attributs correspondent souvent Ă des substantifs, ou des groupes nominaux, tels que << la masse dâune voiture >> ou << le montant dâune transaction >>. Les adjectifs et les valeurs correspondent souvent Ă des valeurs dâattributs. NB: Souvent, on ajoute des attributs Ă toutes les Ă©tapes du cycle de vie dâun projet (implĂ©mentation comprise). 4. Organiser et simplifier le modĂšle en Ă©liminant les classes redondantes et en utilisant lâhĂ©ritage. 5. ItĂ©rer et raffiner le modĂšle. Un modĂšle est rarement correct dĂšs sa premiĂšre construction. La modĂ©lisation objet est un processus non pas linĂ©aire mais itĂ©ratif. S. Mesfar 245 Etapes de lâĂ©laboration dâun diagramme de classes Les diagrammes UML
243.
246 5.4 : Les
Diagrammes de collaboration / communication S. Mesfar
244.
Notation âą Les diagrammes
de collaboration montrent des interactions entre objets, en insistant plus particuliĂšrement sur la structure spatiale statique qui permet la mise en collaboration dâun groupe dâobjets. âą Les diagrammes de collaboration expriment Ă la fois le contexte dâun groupe dâobjets (au travers des objets et des liens) et lâinteraction entre ces objets (par la reprĂ©sentation de lâenvoi de messages). ïżœ Les diagrammes de collaboration sont une extension des diagrammes dâobjet. S. Mesfar 247 Le diagramme de communication / collaboration Les diagrammes UML
245.
Notation âąLes diagrammes de
collaboration sont un recoupement des diagrammes dâobjets et des diagrammes de sĂ©quences. âąChaque objet intervient de la mĂȘme façon que dans les diagrammes de sĂ©quence âąLes messages sont obligatoirement numĂ©rotĂ©s S. Mesfar 248 Le diagramme de communication / collaboration Les diagrammes UML
246.
Notation Objet 1 Objet 2 Objet
3 1 : message 4 : message 2 : message 3 : message S. Mesfar 249 Le diagramme de communication / collaboration Les diagrammes UML
247.
Exemple S. Mesfar 250 Le
diagramme de communication / collaboration Les diagrammes UML
248.
RĂŽles et connecteurs Le
rĂŽle permet de dĂ©finir le contexte d'utilisation de l'interaction. ïżœSi la ligne de vie est un objet, celui-ci peut avoir plusieurs rĂŽles au cours de sa vie. Les relations entre les lignes de vie sont appelĂ©es connecteurs . ïżœUn connecteur se reprĂ©sente de la mĂȘme façon qu'une association mais la sĂ©mantique est plus large : un connecteur est souvent une association transitoire. S. Mesfar 251 Le diagramme de communication / collaboration Les diagrammes UML
249.
Notation (âŠ) La place
de lâutilisateur ïżœ La notation permet de faire figurer un acteur dans un diagramme de collaboration afin de reprĂ©senter le dĂ©clenchement des interactions par un Ă©lĂ©ment externe au systĂšme. GrĂące Ă cet artifice, lâinteraction peu ĂȘtre dĂ©crite de maniĂšre plus abstraite sans entrer dans les dĂ©tails des objets de lâinterface utilisateur. ïżœ Le premier message est envoyĂ© par lâacteur, reprĂ©sentĂ© par un symbole graphique (type bonhomme) semblable au modĂšle des cas dâutilisation, ou bien par un objet muni dâun stĂ©rĂ©otype qui prĂ©cise sa qualitĂ© dâacteur. S. Mesfar 252 Le diagramme de communication / collaboration Les diagrammes UML
250.
Représentation des messages Les
flÚches représentant les messages sont tracées à cÎté des connecteurs qui les supportent. Attention Bien faire la distinction entre les messages et les connecteurs : on pourrait avoir un connecteur sans message, mais jamais l'inverse. S. Mesfar 253 Le diagramme de communication / collaboration Les diagrammes UML
251.
Multiplicité Les connecteurs permettent
de rendre compte de la multiplicité. S. Mesfar 254 Le diagramme de communication / collaboration Les diagrammes UML
252.
Numéros de séquence
des messages Pour reprĂ©senter les aspects temporels, on adjoint des numĂ©ros de sĂ©quence aux messages. ïżœDes messages successifs sont ordonnĂ©s selon un numĂ©ro de sĂ©quence croissant (1, 2, 3, ... ou encore 3.1, 3.2, 3.3, ...). ïżœDes messages envoyĂ©s en cascade (ex : appel de mĂ©thode Ă l'intĂ©rieur d'une mĂ©thode) portent un numĂ©ro d'emboĂźtement avec une notation pointĂ©e âą1.1, 1.2, ... pour des messages appelĂ©s par une mĂ©thode dont l'appel portait le numĂ©ro 1 âą2.a.1, 2.a.2, ... pour des messages appelĂ©s par une mĂ©thode dont l'appel portait le numĂ©ro 2.a S. Mesfar 255 Le diagramme de communication / collaboration Les diagrammes UML
253.
Equivalence avec un
diagramme de séquence S. Mesfar 256 Le diagramme de communication / collaboration Les diagrammes UML
254.
Equivalence avec un
diagramme de séquence S. Mesfar 257 Le diagramme de communication / collaboration Les diagrammes UML
255.
Messages simultanés Lorsque des
messages sont envoyĂ©s en parallĂšle, on les numĂ©rote avec des lettres âą1.a, 1.b,... pour des messages simultanĂ©s envoyĂ©s en rĂ©ponse Ă un message dont l'envoi portait le numĂ©ro 1 S. Mesfar 258 Le diagramme de communication / collaboration Les diagrammes UML
256.
S. Mesfar 259 Classes Collaboration Le
diagramme de communication / collaboration Les diagrammes UML
257.
Opérateurs de choix
et de boucle Pas d'opĂ©rateurs combinĂ©s dans les diagrammes de communication âą*[<clauseItĂ©ration>] reprĂ©sente une itĂ©ration. ïżœLa clause d'itĂ©ration peut ĂȘtre exprimĂ©e dans le format i:=1..n âą[<clauseCondition>] reprĂ©sente un choix. La clause de condition est une condition boolĂ©enne. Elle reprĂ©sente la condition dâarrĂȘt S. Mesfar 261 Le diagramme de communication / collaboration Les diagrammes UML
258.
Syntaxe des messages ïżœSyntaxe
complĂšte des messages est : [<numeroSĂ©quence>][<expression>]:<message> ïżœÂ« message » a la mĂȘme forme que dans les diagrammes de sĂ©quence, « numĂ©roSĂ©quence » reprĂ©sente le numĂ©ro de sĂ©quencement des messages et « expression » prĂ©cise une itĂ©ration ou un branchement conditionnel. ïżœExemples : ïżœ2 : affiche(x,y) : message simple. ïżœ1.3.1 : trouve("Hadock") : appel emboĂźtĂ©. ïżœ4 [x < 0] : inverse(x,couleur) : conditionnel. ïżœ3.1 *[i:=1..10] : recommencer() : itĂ©ration. S. Mesfar 262 Le diagramme de communication / collaboration Les diagrammes UML
259.
Collaborations et interactions ïżœLes
collaborations donnent lieu Ă des interactions ïżœLes interactions documentent les collaborations ïżœLes collaborations organisent les interactions. ïżœLes interactions se reprĂ©sentent indiffĂ©remment par des diagrammes de communication ou de sĂ©quence S. Mesfar 263 Le diagramme de communication / collaboration Les diagrammes UML
260.
UML - Le
langage Objet unifiĂ© x : ClasseA y : ClasseB [ x ] 1: message message soumis Ă la condition x x : ClasseA y : ClasseB 1.a : message1 z : ClasseC1.b : message2 message1 et message 2 en parallĂšle x : ClasseA y : ClasseB 1.1 : message1 z : ClasseC1.2 : message2 message1.1 et message1.2 envoyĂ©s successivement vers y et z x : ClasseA y : ClasseB 1 : * [ 1..n ] message message envoyĂ© n fois x : ClasseA : ClasseB // 1: message message envoyĂ© en parallĂšle Ă plusieurs instances de la classe B x : ClasseA y : ClasseB 1.a, 2.c / 5: message message envoyĂ© Ă y lorsque 1.a et 2.c sont satisfaits (synchronisation) : Voir diag. dâactivitĂ©s x : ClasseA y : ClasseB 1 : a : = message a rĂ©cupĂšre la valeur renvoyĂ©e par lâexĂ©cution du message (rĂ©cupĂ©ration dâun rĂ©sultat)S. Mesfar Le diagramme de communication / collaboration Les diagrammes UML
261.
Buts : 1. DĂ©crire
lâinteraction des objets entre eux 2. Illustrer les scĂ©narios des use cases 3. Valider les choix dâanalyse et de conception (prototypage) 4. Aider au raffinement des diagrammes de classes de conception 265 S. Mesfar Le diagramme de communication / collaboration Les diagrammes UML
262.
266 5.5 : Les
Diagrammes Etats-transitions S. Mesfar
263.
Concepts liĂ©s Ă
la phase dâanalyse ïżœ Un Ă©tat rĂ©fĂšre lâensemble des valeurs qui dĂ©crit un objet Ă un moment spĂ©cifique. ïżœ En dâautres termes, lâĂ©tat dâun objet est dĂ©terminĂ© par les valeurs associĂ©es Ă ses attributs. ïżœ Quand les messages sont reçus, les opĂ©rations associĂ©es aux classes des objets considĂ©rĂ©s amĂšnent des modifications de ces valeurs. 267 Le diagramme Etats-Transitions Les diagrammes UML
Jetzt herunterladen