1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.
-
Upload
agace-leriche -
Category
Documents
-
view
108 -
download
0
Transcript of 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.
![Page 1: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/1.jpg)
1
![Page 2: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/2.jpg)
2
U.M.L.Unified Modeling Language
(1ère partie)
Françoise Schlienger
4ème année 2004-2005
Département Informatique
![Page 3: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/3.jpg)
3
Plan de la première partie
• Les méthodes d’analyse de 1960 à 1990 5
• Les méthodes Objet 9
• UML : généralités 16
• Les diagrammes d ’UML 17
• Les mécanismes communs 19
• Les diagrammes de classes 31
• Les diagrammes d ’objets 61
![Page 4: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/4.jpg)
4
Booch
Unified MethodUnified Method0.8
etc...
OOSE(Jacobson et al.)
UML 0.9UML 0.9
1996
etc.ROOMCatalysis
OMGOMG
UML 1.1UML 1.1
Nov. 1997Nov. 1997
UML 1.3UML 1.3
UML 1.4UML 1.4
UML 2.0UML 2.0
Juin 1999Juin 1999
FinFin 200 20011
……
HOOD
OMT (Rumbaugh et al.)
1995
RationalRational
ROOM
Classe-Relation
Fusion
OOSE
Booch
OMT
Fin 1990
![Page 5: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/5.jpg)
5
Méthodes d ’analyse (60-80)
MERISE(1962)
PETRI(1962)
HIPO(1970)
SD(1974)
Idef-0(1974)
LCS(1974)
HDM(1979)
SADT(1976)
SA(1978)
E-R(1976)
SDS(1977)
HOS(1975)
MACH(1980)
DREAM(1978)SARA
(1978)
IA-NIAM(1975)
1960-1974
1975-1980
![Page 6: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/6.jpg)
6
Méthodes d’analyse (60-80)
1960 - 1974
• HIPO : Hierarchy plus Input Process Output (IBM/USA).
• PETRI : les réseaux de Petri ; outil pour la synchronisation (Allemagne)
• LCS : Lois de Construction de Systèmes (Warnier - France).
• SD : Structured Design (IBM : Stevens, Myer, Constantine, USA).
• Idef-0 : Icam definition-0 (DoD, US air force).
1975 - 1980
• IA-NIAM : Niijsen Information Analysis Methodologie, modèle relationnel binaire (Pays Bas).
• E-R : Entity-Relationship model (P. Chen, USA).
• SADT : Structured Analysis Design Technique (D.T. Ross, USA).
• SA : Structured Analysis (F. Yourdon, T. Demarco, USA).
• MERISE : méthode mise au point dans le cadre du ministère de l'industrie (Tardieu, Rochfeld ...)
![Page 7: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/7.jpg)
7
Méthodes d ’analyse (80-90)
HOOD(1987)
OOD-86(1986)
SA-RT-2(1986)
OOA (C&Y)(1989) TOCATTA
(1987)
MASCOT3(1986)STATEMATE1
(1987)
MACH-2(1987)
1985-1990
JSD(1981)
SASD(1981)
MAIA(1984)
OOD-83(1983) SA-RT-1
(1984) CORE(1983)
AXIAL(1984)
SSADM(1982)
1981-1985
![Page 8: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/8.jpg)
8
Méthodes d’analyse (80-90)
1981 - 1985• JSD : Jackson System Development (Michael Jackson, USA).• SASD : Structured Analysis and Structured Design (L. Constantine, USA).• SSADM : Structured Systems Analysis and Design Method (UK)• OOD-83 : Object Oriented Design (G. Booch, USA).• SA-RT-1 : Structured Analysis Real Time (P. Ward, S. Mellor, USA).• AXIAL : (P. Pellaumail, IBM-France).
1985 - 1990• OOA : Object Oriented Analysis (P. Coad, E. Yourdon, USA).• SA-RT-2 : Structured Analysis Real Time (D. Hatley, I. Pirbaï, USA).• HOOD : Hierarchical Object Oriented Design (Agence spatiale européenne).• TOCCATA : Techniques d'Organisation de la Conception par Comportements Abstraits
et Types Abstraits (CGE Alsthom, France).
![Page 9: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/9.jpg)
9
Les méthodes objet
OBJECTORY(1992)
FUSION(1994)
CLASSERELATION
(1991)
OOA(S&M)(1991)
OMT(1991)
G. BOOCH(1991)
OOM(1991)
OBJETSNATURELS
(1991)
MERISE 2(1993)
EUROMETHODE
UML
MERISE +
1990-1995
Actuellement
?
UML 2
![Page 10: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/10.jpg)
10
OOA : Coad et Yourdon* Analyse orientée objets (version 2) P. Coad et E. Yourdon, Masson 1993* Conception orientée objets P. Coad et E. Yourdon, Masson 1993
OOA : Shlaer et Mellor* Object-Oriented Systems Analysis : Modeling the World in Data
S. Shlaer et S. Mellor, Yourdon Press 1988* Object-Lifecycles : Modeling the World in States
S. Shlaer et S. Mellor, Yourdon Press 1992
Grady Booch : méthode orientée Ada 1991* Conception orientée objets et applications
Grady Booch, Addison-Wesley 1992
OOSE : version simplifiée d'Objectory (intéressant pour les aspects USE-CASE)* Le génie logiciel orienté objet
Ivar Jacobson, Christerson, Jonsson, Övergaard, Addison-Wesley 1993
Les méthodes objet (1)
![Page 11: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/11.jpg)
11
Les méthodes objet (2)
Méthode classe-relation
* Ingénierie des objets, Approche classe-relation, application à C++
P. Desfray (version 2), Masson 1993
La méthode FUSION* Object Oriented Development : the FUSION method
D. Colemen, P. Arnold, S. Bodoff, Prentice-Hall, Englewood Cliffs, NJ, 1994
Évolution de Merise Merise/2
* MERISE/2 : modèles et techniques MERISE avancésG. Panet, R. Letouche, Éditions d'organisation 1994
OOM : Orientation Objet pour Merise* De Merise à OOM. Pourquoi changer ?
M. Bouzegoub, A. Rochfeld, Édition Hermès 1996
![Page 12: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/12.jpg)
12
OMT : Rumbaugh et al. * premier livre en 1991, première conférence en France : 1993
* O.M.T. : Modélisation et conception orientées objet (édition française revue et augmentée) Rumbaugh et al., Masson 1995 * O.M.T. : Solution des exercices Rumbaugh et al., Masson 1996
Les méthodes objet (3)
![Page 13: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/13.jpg)
13
UML : Unified Modeling Language
• octobre 94 : Grady Booch (Méthode Booch) et James Rumbaugh (OMT) commencent à unifier leurs 2 méthodes.
--> Unified Method 0.8
• fin 1995 : Ivar Jacobson introduit certains concepts de sa méthode (OOSE)
Langage de modélisation unifié avec pour objectifs de :
- ne plus faire évoluer les méthodes de manière indépendante les unes des autres,
- unifier la sémantique et les notations et amener ainsi une stabilité sur le marché "orienté-objet "
- rassembler leurs efforts pour résoudre des problèmes qu'aucune des trois méthodes ne peut bien résoudre.
![Page 14: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/14.jpg)
14
UML : Unified Modeling Language
• octobre 1996 : UML 0.9 (Unified Modeling Language)diffusion au sein de la "communauté informatique" et intégration des remarques.
• 16 janvier 1997 : le document UML a été soumis à l'OMG (Object Management Group). .
• 14 novembre 1997 : adoption d'UML 1.1 comme standard par l'OMG.• Novembre 1998 : UML 1.3• 2000 : UML 1.4• 2004 : UML 2
Sites officiels : www.omg.orgwww.uml.org
![Page 15: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/15.jpg)
15
Bibliographie
• Modélisation objet avec UML Pierre-Alain Muller, Eyrolles 1997, Eyrolles 2000Pierre-Alain Muller, Nathalie Gaertner, Eyrolles 2003• Intégrer UML dans vos projetsN. Lopez, J. Migueis, E. Pichon, Eyrolles 1997• UML pour l'analyse d'un système d'informationChantal Morley, Jean Hugues, Bernard Leblanc , Dunod 2000
• Le guide de l'Utilisateur UMLGrady Booch, James Rumbaugh, Ivar Jacobson, Eyrolles 2000
nouvelle version prévue pour UML 2 en mai 2005 (en anglais)• Le processus unifié de développement logiciel Grady Booch, James Rumbaugh, Ivar Jacobson, Eyrolles 2000
![Page 16: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/16.jpg)
16
UML : Unified Modeling Language
UML propose :
• des éléments de modélisation qui représentent les abstractions du système en cours de modélisation
• des éléments de visualisation qui procurent des projections textuelles ou graphiques permettant la manipulation des éléments de modélisation
![Page 17: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/17.jpg)
17
Diagrammes d ’UML
• les diagrammes de cas d'utilisation qui représentent les fonctions du système du point de vue de l'utilisateur,
• les diagrammes de classes qui représentent la structure statique en termes de classes et de relations,
• les diagrammes d'objets qui représentent les objets et leurs relations.
• les diagrammes d'états-transitions qui représentent le comportement des classes en termes d'états,
• les diagrammes de séquence qui sont une représentation temporelle des interactions entre les objets.
• les diagrammes de collaboration qui sont une représentation spatiale des objets et de leurs interactions.
![Page 18: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/18.jpg)
18
Diagrammes d ’UML
• les diagrammes d'activités qui représentent le comportement d'une opération en termes d'actions (proches des organigrammes).
• les diagrammes de composants qui représentent les composants physiques d'une application.
• les diagrammes de déploiement qui représentent le déploiement des composants sur des dispositifs matériels.
![Page 19: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/19.jpg)
19
Les mécanismes communs
Sont applicables sur chaque modèle :
• les notes
• les étiquettes
• les contraintes
• les relations de dépendances
• les stéréotypes
![Page 20: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/20.jpg)
20
Les notes
Elles permettent d’ajouter des informations à un modèle comme des commentaires (sans contenu sémantique) mais aussi des exigences, des observations, des révisions ou des explications.
Ceci est une note qui peut être reliée à tout élément de modélisation par des pointillés.
![Page 21: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/21.jpg)
21
Les étiquettes
Nommées également « Tagged values », elles permettent la création de nouvelles informations dans la spécification d’un élément. Elles se présentent sous la forme de paires {nom, valeur}
{version , 3.2} peut être ajouté sur un modèle
Dans les AGL, elles sont souvent utilisées pour indiquer des propriétés relatives à la génération de code.
![Page 22: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/22.jpg)
22
Les contraintes
Elles permettent d’étendre la sémantique d’un élément d’UML en ajoutant de nouvelles règles ou en modifiant celles qui existent déjà.
Elles sont placées entre accolades sans syntaxe particulière.
{ la femme d'une personne est de genre 'féminin'}
{ la mari d'une personne est de genre 'masculin'}
Souhaits de spécialités dans l'ordre de préférence:
ETUDIANT
Nom : string
SPECIALITE
Libellé : string
sesSpé
*
{ordonné}
*
0..1SaFemme
PERSONNE
-Nom-Genre
SonMari0..1
![Page 23: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/23.jpg)
23
Limite des contraintes informelles
PERSONNE
-Nom-Genre
0..1SaFemme
SonMari0..1 P1:PERSONNE
Nom = ‘Paul’Genre = ‘Masculin’
P2:PERSONNE
Nom = ‘Marie’Genre =‘Féminin’
P3:PERSONNE
Nom = ‘Anne’Genre =‘Féminin’
P4:PERSONNE
Nom = ‘Pierre’Genre = ‘Masculin’
SonMari
SonMari
SaFemme
SaFemme
Il faudrait ajouter :Si une personne est mariée, l’épouse du mari de cette personne est elle-même.Si une personne est mariée, l’époux de la femme de cette personne est lui-même.
Besoin de contraintes formelles : OCL
![Page 24: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/24.jpg)
24
Les relations de dépendances (1)
Une dépendance est une relation sémantique entre deux éléments tels qu’un changement
apporté à l’un (élément source) peut affecter la sémantique de l’autre (élément cible).
Elle est représentée par une ligne en pointillés avec une flèche du coté de l’élément cible.
Elle peut être stéréotypée à l'aide d'un stéréotype standard.
E1:ENSEIGNANT
nom = ‘Dupont’
M1:MATIERE
libellé = ‘Génie logiciel’
MATIERE
libellé : string
enseigne >* 1..*
ENSEIGNANT
nom : string
« instantiates » « instantiates »
![Page 25: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/25.jpg)
25
Les relations de dépendances (2)
PERSONNE PROJET
Participe
Responsable
{sous-ensemble}
Une contrainte peut être associée à plusieurs éléments par une relation de dépendance.
1 0..2
* *
- nom- prénom- e-mail
- nom- durée- dateDébut
![Page 26: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/26.jpg)
26
Les stéréotypes
Ce sont des mécanismes d’extensibilité, permettant aux utilisateurs d’ajouter de nouveaux éléments de modélisation.
Les noms des stéréotypes sont mis entre « …. »
Dans une définition de classe on peut préciser
les constructeurs « create » et les destructeur « destroy »,
pour distinguer les différents types d’opérations.
Lorsqu’un stéréotype est utilisé fréquemment, on peut lui associer une notation particulière.
Client
<<actor>>
Client
<<actor>>
Client
CLIENT
<<create>>CLIENT()<<destroy>>Détruire()
![Page 27: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/27.jpg)
27
Le stéréotype paquetage (« package »)
Les packages permettent de regrouper des classes, des associations et éventuellement d’autres packages.
On parle de PRODUIT :: Article
PRODUIT
ARTICLE LOCALISATION
FABRICANT1..*
* 1
*
![Page 28: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/28.jpg)
28
Interface (1)
• Une interface est un ensemble d’opérations utilisées pour décrire un service d ’une classe.
• Contrairement à une classe, elle ne décrit aucune structure (elle ne peut donc pas inclure d’attributs) ni aucune implémentation (elle ne peut donc pas inclure de méthodes qui fournissent l’implémentation d’une opération).
• Une interface est en général liée (liaison de réalisation) à la classe qui la réalise.
• Une interface est représentée par un cercle et son nom. Le nom d’une interface commence généralement par un I.
PERSONNEI-PERSONNE
![Page 29: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/29.jpg)
29
• On peut également représenter une interface par une classe stéréotypée, en indiquant les opérations qu ’elle fournit.
• Quand un objet joue un rôle spécifique, il présente un aspect particulier et les clients attendent un certain comportement.
Interface (2)
PERSONNE«interface»
I-PERSONNE
getHistoEmploi()getRémunération()getPrestation()
« realize »
![Page 30: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/30.jpg)
30
Le stéréotype « interface »
Une interface
Une classe« use »
Une classe
« interface »Vue A
Un utilisateur X
« interface »Vue B
Un utilisateur Y
« use » « use »
« use » caractérise une relation de dépendance
« realize » « realize »
![Page 31: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/31.jpg)
31
Diagrammes de classes / Diagrammes d’objets
![Page 32: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/32.jpg)
32
Il existe plusieurs niveaux de notation :
a) niveau sans détail
PERSONNE
PERSONNE
NomPrénomAdresse
ModifierAdresse
b) niveau détail d'analyse
On y précise : le type des variables (integer, string, date …) les valeurs par défaut les signatures des opérations éventuellement, le niveau de visibilité : + public(accessible par tout utilisateur) par défaut
- privé(accessible seulement par la classe elle-même) # protégé(accessible par les descendants)
c) niveau de détail de conception
Notation des classes
![Page 33: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/33.jpg)
33
• Attribut [ visibilité ] NomAttribut [: type] [= <valeur par défaut>]
•Opération[ visibilité ] NomOpération [(liste Paramètres)] [: typeRetour]
Paramètre[direction] Nom : type[ = valeur par défaut]
direction : in | out | inout (par défaut : in)
Notation des attributs et opérations
NOMDECLASSE
Opération()
Attributs
+EstSur(in p :POINT): boolean
-Longueur :integer =5
SEGMENT
![Page 34: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/34.jpg)
34
Opérations / méthodes
• Une opération définit un service qui peut être demandé à n’importe quel objet de la classe.
• Une méthode est une implémentation d’une opération.
• La méthode associée à une opération fournit un algorithme exécutable. Cet algorithme est donné dans un langage de programmation ou dans du texte structuré.
![Page 35: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/35.jpg)
35
Classe-1 Classe-2
Nom d’association
rôle-1 rôle-2
PERSONNE EstEnfantDe
Mère
Fils
PERSONNE APPARTEMENTLoue >
SonPropriétaire SesPropriétés
Propose >
SonLocataire SaLocation
Association entre classes
^
![Page 36: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/36.jpg)
36
Exactement 1 1Exactement n nPlusieurs (0 ou plus) *Au plus 1 0..11 ou plus 1..*Cardinalité spécifiée 1..2 4
Nombre de propriétaires Nombre d ’appartements proposés
Cardinalité d’une association
PERSONNE APPARTEMENTPropose >1 *
![Page 37: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/37.jpg)
37
Association : un exemple (1)
Un appartement n’a qu’un propriétaire et une personne peut proposer à la location plusieurs appartements (sous-entendu, elle peut aussi ne pas proposer d’appartement).
Remarque : on précisera toujours les noms des rôles. Le nom de l ’association est facultatif.
PERSONNE APPARTEMENT
Propose >1 0..*
SonPropriétaire SesPropriétés
![Page 38: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/38.jpg)
38
Association : un exemple (2)
PERSONNE APPARTEMENT
Propose >1 0..*
SonPropriétaire SesPropriétés
-Code-Adresse-Surface-MontantLoyer
APPARTEMENT a un attribut implicite SonPropriétaire : PERSONNE
Un constructeur « complet » d’appartement doit avoir en paramètres le Code, l ’Adresse, la Surface, le MontantLoyer d ’un nouvel appartement mais aussi une instance de la classe PERSONNE.
![Page 39: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/39.jpg)
39
Un qualificatif est un attribut dont les valeurs permettent de partitionner l’ensemble des objets reliés par la même association à un autre objet. Il permet de réduire la multiplicité effective d’une association
Ex1 : à un nom de fichier dans un répertoire ne correspond qu'un fichier
Les associations qualifiées (1)
REPERTOIRE NomFichier FICHIER11
1
REPERTOIRE **1 FICHIER
NomFichier
![Page 40: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/40.jpg)
40
Ex2 : dans un cabinet médical, chaque médecin peut effectuer des actes de 3 types : visite,consultation, petite chirurgie.
On peut représenter le problème de 2 manières :
Les associations qualifiées (2)
Les actes médicaux sont rattachés au médecin par type.
MEDECIN CodeType ACTE-MEDICAL
MEDECIN * ACTE-MEDICAL1
CodeType
1*
![Page 41: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/41.jpg)
41
Un attribut dérivé est un attribut calculé. Cela signifie qu’il peut être calculé à partir d ’autres informations du système à n’importe quel moment.
(et non pas qu’il a été calculé à un moment donné).
Exemple : pour une personne, l’attribut Age est un attribut calculé à condition que sa DateDeNaissance ait été enregistrée.Un attribut calculé est noté /Attribut
Par contre : si on met à jour une QuantitéEnStock par ajout ou suppression, sans conservertout l’historique des mouvements, alors QuantitéEnStock n’est pas une rubrique calculée.
L’attribut QuantitéEnStock est dit « modifiable » (par défaut tout attribut est « modifiable »)
« gelé » (« frozen ») est réservé aux attributs qui, une fois initialisés, ne peuvent être modifiés.
Attribut dérivé
![Page 42: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/42.jpg)
42
Une association dérivée est une association déduite d’une autre.
Une association dérivée ne se justifie que pour faciliter des traitements.
Association dérivée
ENTREPRISE SERVICE EMPLOYESesServices SesEmployés
SesEmployés
SonService
/Emploi
Le nom de l’association est précédé d’un /
![Page 43: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/43.jpg)
43
Contrairement à Merise, UML autorise :
• Une classe avec une seule instance et des attributs multivalués.
• Les attributs calculés (attributs dérivés) précédés par un / On précise alors, dans une note, la règle de calcul.
• Les associations dérivées (stéréotype « derive ») qui faciliteront un traitement.
Les identificateurs explicites (identifiants) ne sont pas indispensables. Ils ne sont pas soulignés (seuls les attributs de classe sont soulignés).
On peut les préciser à l’aide d’une note.
On peut représenter des « paramètres » (Merise) par le biais de variables de classe.
Remarques sur les classes
{identifier}
![Page 44: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/44.jpg)
44
Contrairement à Merise ...
Exemple
Emploie>
ENTREPRISE
-Nom-Adresse
+ModifierAdresse()+AjouterPersonne()
1
PERSONNE
-Nom-Prénoms-Adresse-DateDeNaissance/-Age
+CréerPersonne()+GetCoordonnées()+CalculerAge
0..*
SesEmployés SonEntreprise
. {Age=DateCourante - DateNaissance}
+AjouterPersonne(in P : PERSONNE)
![Page 45: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/45.jpg)
45
C ’est un type particulier d ’association "composé-composant" ou "partie de"
Agrégation (par référence) : 0..1
EQUIPE SPORT JOUEUR
Un joueur peut faire partie de plusieurs équipes
EQUIPE SPORT JOUEUR
Agrégation-Composition
SesParticipantsSonEquipe
*
SesParticipantsSesEquipes
**
Un objet peut faire partie de plusieurs composites à la fois.
![Page 46: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/46.jpg)
46
Agrégation-Composition
La destruction du composite entraîne la destruction des composants.Un objet ne fait partie que d’un seul composite à la fois.
Composition (par valeur)
1 *
SaCommande SesLignesCOMMANDE LIGNE-COM
La durée de vie d’une ligne (de commande) est incluse dans celle de sa commande
Commande
Ligne annulée
Ligne ajoutée
Ligne non modifiée
Temps
![Page 47: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/47.jpg)
47
Exercice
Réaliser un diagramme de classes permettant :• de représenter un train composé d’un ensemble de
wagons • de représenter les sièges répartis dans les différents
wagons
![Page 48: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/48.jpg)
48
APPARTEMENTPropose >
Classe-Association (Classe associative)
AGENCE0..* 0..*
LOCATIONPrix : realSetPrix(P:real)GetPrix() : real
AGENCE 1
LOCATIONPrix : realSetPrix(P:real)GetPrix() : real
APPARTEMENT0..*0..* 1
![Page 49: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/49.jpg)
49
Elles permettent de regrouper des opérations et des attributs communsà une ou plusieurs classes données et de préciser que les classes les plus spécifiqueshéritent des classes les plus générales.
COMPTE-BANCAIRE-Crédit : integer-Débit : integer….
+Déposer(S:integer)+Retirer(S:integer)+GetSolde()
COMPTE-EPARGNE-Taux : float
+CalculerIntérêts()
Généralisation Spécialisation
Relations de généralisation-spécialisation
![Page 50: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/50.jpg)
50
Qualité d’une association qui permet le passage d’une classe vers une autre.En général, on peut naviguer dans les 2 sens. On peut cependant limiter la navigabilité :
Exemple :CLASSE-1 CLASSE-2
Nom d’association
Il doit être facile de passer directement d’un produit à son fabriquant.La commande d’un produit fait référence à l ’adresse de « SonRéalisateur »
Il y a demande de service (GetAdresse) de PRODUIT à FABRIQUANT.
Navigabilité d’une association
1..* 1SonRéalisateurSesProduits
FABRIQUANT
-Adresse
+GetAdresse()
PRODUIT
-QttéRéappro
+Commander()
![Page 51: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/51.jpg)
51
Un attribut de classe décrit une valeur commune à une classe d'objets dans son ensemble.
Une opération de classe est une opération sur la classe elle- même. La plus commune est celle destinée à créer des nouvelles instances de classe.
Attributs et opérations de classe sont soulignés. (Attention : ne pas les confondre avec les identifiants de Merise.)
ARTICLE
-Référence-PrixHT-NbInstances
+CalculerPrixTTC()+Créer()+CompterInstances()
Attributs et opérations de classes
![Page 52: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/52.jpg)
52
Un ‘ singleton ’ permet de référencer l’instance d ’une classe, unique par construction.
Forme générique d ’une classe implémentant un singleton.
L ’opération getInstance() est chargéede rapporter à l’appelant la référencede l objet unique.
Utilisation fréquente dans le cas d ’objets centralisateurs tels que‘superviseur’, ‘contrôleur’,
Application au design pattern ‘ singleton ’
SINGLETON
Instance : SINGLETON = null
getInstance() : SINGLETON
if (instance == null)instance := newSingleton()
return instance;
Le singleton se charge de construirel’objet lors du premier appel.
![Page 53: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/53.jpg)
53
Classe et Opération abstraites / Polymorphisme
• Classe qui ne peut avoir aucune instance directe ; on écrit son nom en italique.
• Une opération abstraite ne fournit d’implémentation qu’au travers d’une instance d’une classe fille de celle qui la contient.
• Remarque : les noms des éléments abstraits sont écrits en italique ou préfixés par Abs.
FORME
-Nom : string
+CalcSurface()+GetNom()
![Page 54: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/54.jpg)
54
RECTANGLE
- Long : float- Larg : float
+CalcSurface() + Type()
CERCLE
- Rayon : float
+CalcSurface()+ Type()
Opérationspolymorphes
Classe et Opération abstraites / Polymorphisme
FORME
-Couleur : string
+CalcSurface()+Type()
return ’rectangle’ return ’cercle’return Long * Larg
return PI * Rayon * Rayon
![Page 55: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/55.jpg)
55
Attributs et opérations implicites (1)
ETUDIANT
Nom : string
Pour chaque attribut on ajouteimplicitement :
Ces opérations ne sont pas obligatoirement publiques. SetNom peut ne pas exister.
ETUDIANT
Nom : string
<constructeur>Etudiant ()<destructeur>~Etudiant()
<sélecteur ou accesseur>GetNom () : string<modificateur>SetNom (N:string) : bool
Pour la classe on ajoute implicitement :
![Page 56: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/56.jpg)
56
Attributs et opérations implicites (2)
ETUDIANT
Nom : string
ETUDIANT
Nom : stringSonGroupe : GROUPE
<sélecteur ou accesseur>GetSonGroupe () :GROUPE<modificateur>SetSonGroupe(G:GROUPE)RetirerSonGroupe() … si le minimum est à 0
GROUPE
Numéro : int
SonGroupe
0..1
Pour chaque association navigable
de cardinalité 0..1, 1..1 on ajoute :
un attribut
… et les opérations correspondantes
![Page 57: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/57.jpg)
57
Remarque concernant la navigation
ETUDIANT
Nom : string
GROUPE
Numéro : integer
SonGroupe
0..1
Pour un étudiant on peut obtenir son groupe, mais il n’est pas prévud’obtenir la liste des étudiants à partir du groupe.
SesEtudiants
0..*
![Page 58: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/58.jpg)
58
Attributs et opérations implicites (3)
ETUDIANT
Nom : string
ETUDIANT
Nom : stringSesOptions : ensemble(OPTION)
<modificateur>AjouterOption(O:OPTION):boolRetirerOption(O:OPTION):boolGetSesOptions() : ensemble(OPTION)
OPTION
Libellé : string
SesOptions
0..*
Pour chaque association navigable
de cardinalité 0..*, 1..* on ajoute : un attribut de type ensemble,
… et les opérations
pour gérer ce type ensemble.
![Page 59: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/59.jpg)
59
Remarque concernant la navigation
ETUDIANT
Nom : string
OPTION
Libellé : string
SesEtudiants SesOptions
0..* 0..*
Nouvelle hypothèse :
Pour un étudiant on peut obtenir ses options et on veut pouvoir obtenir la liste des étudiants à partir d’une option.
En ajoutant une flèche vers SesEtudiants, on ajoute implicitement SesEtudiants : ensemble (ETUDIANT) dans OPTION et les opérations correspondantes.
![Page 60: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/60.jpg)
60
Attributs et opérations implicites (4)
REPERTOIRE NomFichier FICHIER11
1
Dans répertoire on trouvera une opération :
Chercher (NomFichier : string) : FICHIER
![Page 61: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/61.jpg)
61
Diagrammes d’objets
• Ils modélisent les instances d’éléments qui apparaissent sur les diagrammes de classe.
• Ils montrent un ensemble d ’objets et leurs relations à un moment donné.
– Instances nommées
– Instances anonymes
– Instances avec valeurs d ’attributs
Bouton2:RECTANGLE
Longueur : float = 13.5Nom : string = “bouton-poussoir”
Largeur : float = 3.2
:CERCLE
Bouton1:RECTANGLENomInstance:NOMCLASSE
:NOMCLASSE
![Page 62: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/62.jpg)
62
MATIERE
libellé : string
Diagramme d’objets (exemple)
E1:ENSEIGNANT
nom = ‘Dupont’
E2:ENSEIGNANT
nom = ‘Martin’
E3:ENSEIGNANT
nom = ‘Duval’
M3:MATIERE
libellé = ‘Système’
M1:MATIERE
libellé = ‘Génie logiciel’
M2:MATIERE
libellé = ‘Réseau’
enseigne >* 1..*
ENSEIGNANT
nom : string
![Page 63: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/63.jpg)
63
MATIERE
libellé : string
Diagramme d’objets (nécessité de préciser l’association)
enseigne
enseigne
enseigne
enseigne >* 1..*
ENSEIGNANT
nom : string0..1 *
estResponsable >
estResponsable >
estResponsable >
E1:ENSEIGNANT
nom = ‘Dupont’
E2:ENSEIGNANT
nom = ‘Martin’
E3:ENSEIGNANT
nom = ‘Duval’
M3:MATIERE
libellé = ‘Système’
M1:MATIERE
libellé = ‘Génie logiciel’
M2:MATIERE
libellé = ‘Réseau’
![Page 64: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/64.jpg)
64
![Page 65: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/65.jpg)
65
![Page 66: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/66.jpg)
66
U.M.L.Unified Modeling Language
(2ème partie)
Françoise Schlienger
4ème année 2004-2005
Département Informatique
![Page 67: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/67.jpg)
67
Plan de la deuxième partie
• Les diagrammes de cas d’utilisation (Use-Case) 69
• Les diagrammes d’interactions 82
• Les diagrammes de séquences 84
• Les diagrammes de collaboration 102
• Les diagrammes d’états 105
• Les diagrammes d’activités 134
• Les diagrammes de composants 143
• Les diagrammes de déploiement 147
![Page 68: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/68.jpg)
68
Booch
Unified MethodUnified Method0.8
etc...
OOSE(Jacobson et al.)
UML 0.9UML 0.9
1996
etc.ROOMCatalysis
OMGOMG
UML 1.1UML 1.1
Nov. 1997Nov. 1997
UML 1.3UML 1.3
UML 1.4UML 1.4
UML 2.0UML 2.0
Juin 1999Juin 1999
FinFin 200 20011
……
HOOD
OMT (Rumbaugh et al.)
1995
RationalRational
ROOM
Classe-Relation
Fusion
OOSE
Booch
OMT
Fin 1990
![Page 69: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/69.jpg)
69
Les cas d ’utilisation (1)
Un cas d'utilisation indique une fonctionnalité du système déclenchée par un acteur externe au système.
L'acteur représente un rôle joué par une personne (ou un autre système) qui interagit avec le système en cours de modélisation.
• La même personne physique peut jouer le rôle de plusieurs acteurs (enseignant, responsable)
• Plusieurs personnes peuvent également jouer le même rôle, et donc agir comme le même acteur (tous les clients)
ActeurCas d'utilisation
![Page 70: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/70.jpg)
70
Les cas d'utilisations permettent d'exprimer les désirs des utilisateurs du logiciel en cours de modélisation.
Les cas d ’utilisation décrivent le comportement du système, du point de vue d'un utilisateur, sous la forme d'une séquence d'actions et de réactions.
On peut préciser le comportement d’un cas d’utilisation en décrivant les flots d ’événements à l’aide d’un texte. Puis au fur et à mesure que l’on affine sa compréhension des exigences du système, on utilise des diagrammes d’interaction pour préciser graphiquement ces flots.
Les cas d ’utilisation (2)
![Page 71: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/71.jpg)
71
Achat sur site Internet
Les acteurs : propriétés
Une relation de généralisation/spécialisation peut être appliquée aux acteurs.
Internaute
Consulter info.
Client Acheter livre
![Page 72: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/72.jpg)
72
Un cas d’utilisation modélise un ensemble de séquences dans lequel chaque séquence représente une variation possible d’un même type d’interaction.
Chaque séquence est un scénario.
–Scénario : cas d’utilisation spécifique(exemple : « Le client Pierre retire 100 euros avec sa carte VISA à partir du distributeur installé 5 rue du château »)
–Cas d’utilisation : modélise le cas général, donne une vision synthétique de scénarios similaires.(exemple : « un client retire de l’argent à partir d’un distributeur »)
flot d’événements principal
On peut avoir d’autres scénarios : carte VISA périmée flot d’événements exceptionnel
Cas d ’utilisation et scénarios
![Page 73: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/73.jpg)
73
Le système voiture
Garagiste Conducteur
Se déplacer
Écouter de la musique
Faire la vidange
Réparer
Exemple de cas d ’utilisation
![Page 74: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/74.jpg)
74
Relation d’inclusion « include »
Le système voiture
Garagiste
Faire la vidange
Réparer
<<include>>
Activer pont élévateur
<<include>>
Permet d’incorporer le comportement d’un autre cas d’utilisation. Le cas d’utilisation inclus
n’est jamais exécuté seul, mais seulement en tant que partie d’un cas de base plus vaste.
![Page 75: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/75.jpg)
75
Relation d’extension « extend »
Le système voiture
Garagiste
Faire la vidange
Réparer
Commander pièce
<<extend>>
Permet de modéliser la partie d’un cas d’utilisation considérée comme conditionnelle dans le comportement du système.
![Page 76: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/76.jpg)
76
Spécialisation
Le système voiture
Garagiste
Réparer
Réparer Diesel
Les cas d’utilisation peuvent être hiérarchisés par généralisation/spécialisation. Les cas d’utilisation descendants héritent de la sémantique de leurs parents. Ils peuvent comprendre des interactions spécifiques supplémentaires ou modifier des interactions héritées.
Réparer essence
![Page 77: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/77.jpg)
77
Le cas d’une coopérative de libraires
Pour chacun des cas d'utilisation, on fournira une spécification sous forme de texte ou d'un diagramme d'interaction (séquence ou collaboration)
Créer Nouveau Client
Vérifier solvabilité client
EmployéPasser une commande
urgente
Enregistrer une commande
<<extend>>
<<include>>
Ce cas peut être considéré comme exceptionnel.
On peut factoriser des comportements
<<extend>>
![Page 78: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/78.jpg)
78
Spécification sous forme textuelle (rédigée avec l’aide de l ’utilisateur)
Système : coopérativeActeur primaire : l’employé de la coopérativeObjectif : enregistrer une commande « normale » de livresPrécondition : le libraire existeScénarios :
1 - vérification de sa solvabilité (à partir de son numéro)
Pour chaque livre :2 - vérification de l’existence du livre (à partir de l ’ISBN)
3 - précision de la quantité
Exception :1a - le libraire n’est pas solvable
(l ’employé est informé)2a - le livre n’existe pas
(l ’employé est informé)
![Page 79: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/79.jpg)
79
Diagramme de classe (version de base)
CATALOGUELIVRE
LIGNE-COMMANDE
COMMANDE-LIBLIBRAIRE
REGISTRE-LIBRAIRE -SesDemandes
-SesLignes
*1
-SesCommandes-SonDemandeur
-SonCatalogue-SesLivres
*1-SonLivre
1
-SesLibraires
1
*
-SonRegistre
-SaCommande
*
1
*
EDITEUR
-SesLivres
-SonEditeur
*
1
![Page 80: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/80.jpg)
80
Spécification sous forme textuelle (proposition technique)
Système : coopérativeActeur primaire : l ’employé de la coopérativeObjectif : enregistrer une commande de livresPrécondition : le libraire existeScénarios :
1 - vérification de la solvabilité du libraire (à partir de son numéro)
* une instance de commande est créée Pour chaque livre :
2 - vérification de l ’existence du livre* une instance de ligne de commande est créée
* l ’instance est reliée à la commande3 - précision de la quantité
* la quantité est ajoutée
Exceptions :1a - le libraire n ’est pas solvable * un message est renvoyé2a - le livre n ’existe pas * un message est renvoyé
![Page 81: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/81.jpg)
81
Diagramme de classe (version 2)
CATALOGUE
LIVRE
LIGNE-COMMANDE
COMMANDE-LIB
LIBRAIRE
REGISTRE-LIBRAIRE
-NumISBN : integer-Titre : string
-DateEdition : Date
-SesCommandes
+TrouverLibraire(In Numéro:integer):LIBRAIRE
+TrouverLivre(In numéro:integer):LIVRE
-SonRegistre1
-SonCatalogue -SesLivres
1 *
+Solvable?():boolean
-SonDemandeur
1-NumLib : integer-NomLib : string-AdresLib : string-Etat : string
-SesLibraires*
+Créer(In Lib:LIBRAIRE,In NumCom:integer, In DateCom:Date)
*
-NumCom : integer-DateCom : Date
-SaCommande1
+SetQuantité(In Nb:integer)
-Quantité : integer
-SesDemandes
-SonLivre
*
1
+Créer(In Liv:LIVRE ,In Com:COMMANDE-LIB ,In Quantité:integer)
*-SesLignes
EDITEUR
-Nom : string-Adresse : string
-SesLivres
-SonEditeur
*
1
![Page 82: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/82.jpg)
82
Diagrammes d’interaction
![Page 83: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/83.jpg)
83
Diagramme d’interaction
Les diagrammes d’interaction représentent les objets les uns par rapport aux autres et montrent comment ces objets communiquent au cours d’une interaction.
Il existe deux sortes de diagrammes d’interaction :
• les diagrammes de séquence qui sont une représentation temporelle des interactions entre les objets.
• les diagrammes de collaboration qui sont une représentation spatiale des objets et de leurs interactions.
![Page 84: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/84.jpg)
84
Diagramme de séquence
Un diagramme de séquence permet de décrire une simulation du fonctionnement d ’un cas d ’utilisation. Il met en jeu :
• un acteur
• un ensemble d ’objets
• la chronologie des échanges entre les objets (messages avec leurs paramètres et leur valeur de retour)
• les contraintes de temps.
![Page 85: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/85.jpg)
85
Diagrammes de séquence : principes généraux
nom2:Classe1
objet du diagramme de classes
ligne de vie (durée de l’interaction)activation
nom3:Classe2
message
nom (…)
retour
nom1:Acteur
nom(…)
acteur
![Page 86: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/86.jpg)
86
Diagramme de séquence : notation
Inst.1:Acteur
CallAction()
Inst.3:Class-BCréer()
CallAction()
Inst.4:CLASSE-C
Détruire()
CallAction()
Inst.2:CLASSE-A
![Page 87: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/87.jpg)
87
Diagramme de séquence « système »
Il permet de décrire le fonctionnement du système. C ’est une reformulation du texte du cas d ’utilisation.
Il met en jeu :
• un acteur
• l ’objet de la classe SYSTEME
• la chronologie des échanges entre les objets
• les contraintes de temps
![Page 88: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/88.jpg)
88
Diagramme de séquence « système » : exemple
Le système est traité comme une boîte noire.
Pour chaque livre commandéSolvableLibraire (num)
TrouverLivre (ISBN)
SetQuantité (n)
: Système
Livre
réponse
Ou réponse négative
![Page 89: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/89.jpg)
89
Diagramme de séquence : message avec retour
Monsieut TRUC:LeResponsable
Unlivre:LIVRE
GetTitre()
Titre
![Page 90: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/90.jpg)
90
Diagramme de séquence : création et message sans retour
UnLivre:LIVRECréer(NumISBN, Titre, DateEdition)
LeCatalogue:CATALOGUE
AjouterLivre(self)
Monsieut TRUC:LeResponsable
self ou this
![Page 91: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/91.jpg)
91
Ajouter un nouveau livre : autre manière
Monsieut TRUC:LeResponsable
L:LIVRECréer(Numéro, Titre, AnnéeEdition)
L
LeCatalogue:CATALOGUE
AjouterLivre(L)
![Page 92: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/92.jpg)
92
Ajouter un nouveau livre : solution préférable
LeCatalogue:CATALOGUE
NouveauLivre(NumISBN, Titre, DateEdition)
Monsieut TRUC:LeResponsable
UnLivre:LIVRECréer(NumISBN, Titre, DateEdition)
UnLivre
AjouterLivre (UnLivre)
![Page 93: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/93.jpg)
93
Ajouter un nouveau livre en lui attribuant un numéro
L:LIVRE
Monsieut TRUC:LeResponsable
LeCatalogue:CATALOGUE
NouveauLivre(Titre, AnnéeEdition)
Créer(Numéro, Titre, AnnéeEdition)L
AjouterLivre(L)
CalculerNuméro()
Numéro
Cela suppose que l’on conserve le dernier
numéro attribué
![Page 94: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/94.jpg)
94
Diagramme de séquence : branchement conditionnel(2 objets différents)
Instance:CLASSE1 Instance1:CLASSE2 Instance2:CLASSE3
[X] CallAction1()
[non X] CallAction2()
![Page 95: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/95.jpg)
95
Diagramme de séquence : branchement conditionnel(même objet)
Instance:CLASS1 Instance1:CLASSE
[X] CallAction1()
[non X] CallAction2()
![Page 96: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/96.jpg)
96
Diagramme de séquence (exemple)
Monsieut TRUC:Responsable
LeRegistre:REG-LIBRAIRE UnLibraire:LIBRAIRE
SolvableLibraire?
b
Solvable?()
b
TrouverLibraire
UnLibraire
Vérification de la solvabilité d’un libraire identifié par un numéro.
(numéro)
(numéro)
![Page 97: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/97.jpg)
97
Diagramme de séquence en escalier (décentralisé)
On parle aussi de délégation ou propagation des messages .
Instance:A Instance1:B Instance2:C Instance3:D Instance4:E
CallAction()
CallAction()
CallAction()
CallAction()
![Page 98: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/98.jpg)
98
Diagramme de séquence en fourche (centralisé)
On parle aussi de supervision (un objet envoie tous les messages)
Instance:A Instance1:B Instance2:EInstance3:C Instance4:D
CallAction()
CallAction()
CallAction()
CallAction()
CallAction()
![Page 99: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/99.jpg)
99
Monsieut TRUC:Responsable
UnLibraire:LIBRAIRE C :COMMANDE-LIB L:LIGNE-COMMANDE SonLivre:LIVRE
GetDétailCommandes()
{Date +{Titre,Quantité}}
GetDétailCommande()
Date +{Titre,Quantité}
GetInfoLigne()
Titre,Quantité
GetTitre()
Titre
GetDate()
Date
GetLivre()
SonLivre
GetSesLignes()
SesLignes
GetQuantité()
GetSesCommandes()
Spécification sous forme de diagramme de séquence
Pour chaque commande C prise dans SesCommandes
Pour chaque ligne L prise dans SesLignes
SesCommandes
![Page 100: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/100.jpg)
100
Monsieut TRUC:Responsable
UnLibraire:LIBRAIRE C :COMMANDE-LIB L:LIGNE-COMMANDE SonLivre:LIVRE
GetDétailCommandes()
GetDétailCommande()
GetInfoLigne()
Titre,Quantité
GetTitre()
Titre
Spécification sous forme de diagramme de séquence
Pour chaque commande C prise dans SesCommandes
Pour chaque ligne L prise dans SesLignes
Date +{Titre,Quantité}
{Date +{Titre,Quantité}}
![Page 101: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/101.jpg)
101
Spécification sous forme de diagramme de séquence(trop centralisé)
Monsieut TRUC:LeResponsable
C :COMMANDE-LIB L :LIGNE-COMMANDE unLivre:LIVREUnLibraire:LIBRAIRE
GetSesLignes()
GetQuantité()
Quantité
GetLivre()
unLivre
GetTitre()
Titre
GetDateCom()
Date
GetDétailCommandes()
GetSesCommandes()
SesCommandes
Pour chaque commande C prise dans SesCommandes
Pour chaque ligne prise dans SesLignes
SesLignes
{Date +{Titre,Quantité}}
![Page 102: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/102.jpg)
102
Diagramme de collaboration
Un diagramme de collaboration est une extension du diagramme d ’objets.
Il permet de décrire :
* un aspect structurel : un ensemble d ’objets, les liens entre ces objets, les rôles de ces objets dans la collaboration
* un aspect de communication : les messages et les numéros de séquence des échanges entre les objets de cette collaboration.
![Page 103: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/103.jpg)
103
Spécification sous forme de diagramme de collaboration
MonsieurTRUC: Responsable
UnLibraire: Libraire
C: CommandeLib
L: LigneCommande
SonLivre : Livre
2: GetSesCommandes ( )
4: GetDate ( )5: GetSesLignes ( )
7: GetLivre ( )9: GetQuantité ( )
1: GetDétailCommandes ( )
3: GetDétailCommande ( )
6: GetInfoLigne ( )
8: GetTitre ( )
![Page 104: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/104.jpg)
104
Diagramme de classe
CATALOGUE
LIVRE
LIGNE-COMMANDE
COMMANDE-LIB
LIBRAIRE
REGISTRE-LIBRAIRE
+Solvable?():boolean
-NumLib : integer-NomLib : string-AdresLib : string-Etat : string
+GetSesCommandes()+GetDétailCommandes()
-SesLivres
*
-NumCom : integer-SesCommandes
+SolvableLibraire?(In Numéro:integer):boolean
+GetSesLibraires()
SonCatalogue
1+TrouverLivre(In numéro:integer):LIVRE+AjouterLivre(In L:LIVRE)
+TrouverLibraire(In Numéro:integer):LIBRAIRE
*
SonRegistre
-SesLibraires
1
-SonDemandeur
1
-NumISBN : integer-Titre : string
-DateEdition : Date
+GetTitre():string
+Créer(In Numéro:integer ,In Titre:string ,In DateEdit:Date)+GetNumISBN():integer
-Quantité : integer
+MajQtté(In Nb:integer)+GetQuantité():integer
+GetInfoLigne()+GetSonLivre():LIVRE
-DateCom : Date
1
*
-SaCommande
-SesLignes
1
*
-SonLivre
-SesDemandes
+Créer(In Liv:LIVRE ,In Com:COMMANDE-LIB ,In Qtt:integer)
*
+Créer()
+GetDateCom():Date+GetDétailCommande()
+GetSesLignes(): Set (n)LIGNE-COMMANDE
+AjouterLigne(In L:LIGNE-COMMANDE)
EDITEUR
-Nom : string-Adresse : string
SesLivres
SonEditeur
*
1
![Page 105: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/105.jpg)
105
Diagrammes d’états
![Page 106: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/106.jpg)
106
Le diagramme d’états
Un diagramme d’état modélise l’existence (cycle de vie) d’un objet, que ce soit une instance de classe ou un système pris dans son ensemble.
Il repose sur différents concepts :
• les états
• les transitions
• les événements.
![Page 107: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/107.jpg)
107
Les états
Un état correspond à la manière d’être d’un objet pendant un intervalle de temps plus ou moins long.
Un état se compose de plusieurs parties :
• le nom
• les actions d’entrée/sortie : ce sont des actions effectuées au moment de l ’entrée ou de la sortie de l’état
• les activités
• les actions liées aux transitions internes ( ces transitions n’occasionnent aucun changement d’état).
![Page 108: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/108.jpg)
108
Transitions et Evénements
Une transition indique le passage d’un état (état source) dans un autre (état cible).
Elle est représentée par une flèche.
Un événement représente quelque chose qui arrive à un moment précis.
Il peut déclencher un changement d ’état.
Exemple : une télévision.
EtatTransition
Arrêtée En veilleMise sous tension
Evénement
![Page 109: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/109.jpg)
109
Activités - Actions
Une activité représente une opération qui nécessite un certain temps d ’exécution.Une activité peut être interrompue à chaque instant par un événement générant une
transition.Une activité est associée à un état. Un état peut ne pas avoir d ’activité.
Une action représente une opération instantanée ; sa durée est insignifiante. Une action est toujours intégralement réalisée.Une action est associée à un événement.Si aucune action ne résulte d’un événement qui se produit alors on peut mentionner
l’action : « defer ». Cela permet d’insister sur le fait que l’événement peut arriver mais qu’il est sans effet dans l’état où l ’objet se trouve. L’événement sera traité par le même objet, dans un autre état, sans avoir besoin de se reproduire.
![Page 110: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/110.jpg)
110
Forme générale d’un état
NOM D ’ETAT
entry / action-entréedo : activitéon Evénement-1/action-1…on Evénement-n / action-nexit / action-sortie
Début
Fin
![Page 111: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/111.jpg)
111
Forme générale d ’une transition
Etat1
entry/action-entrée1do : activité1on Event-11/action-11…on Event-1n /action-1nexit/action-sortie1
Etat2
entry / action-entrée2do : activité2on Event-21/action-21…on Event-2m/action2mexit/action-sortie2
Événement [garde] / action
Actions et activités sont exprimées avec des verbes.
Remarque : suivant les cas, événement, garde (condition), action peuvent être omis.
![Page 112: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/112.jpg)
112
Diagramme d’états : système d’alarme
EN-VEILLE
do : garder détecteur sous tension
EN-ALERTE
entry / mettre sonnerieDétection-Pb / envoyer message
poste de surveillance
Événement
Activité
Action
![Page 113: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/113.jpg)
113
Dans une bibliothèque on enregistre tous les nouveaux livres avant de les mettre à disposition des lecteurs.
Cas 1 : les livres enregistrés sont mis à disposition à 15h.
Dès qu’un livre est enregistré il est mis à disposition
Diagramme d’états
ENREGISTREMENT
do / enregistrer
A DISPOSITION
entry / placerWhen 15 heures
ENREGISTREMENT
do / enregistrer
A DISPOSITION
entry / placer
![Page 114: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/114.jpg)
114
États composés / Sous-états
Un sous-état est un état emboîté dans un autre état (état composé).
Forme générale :
Etat1 Etat2
Etat3 Etat4
Event-1
Event-5 Event- 3Event-2
Event-4
![Page 115: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/115.jpg)
115
Exemple d’états composés
Un magnétoscope peut être * en fonctionnement
* hors fonctionnement.
* en veille
En fonction, il peut être * en enregistrement
* en diffusion.
HORS FONCTION EN-ENREGISTREMENT
EN-DIFFUSIONEN VEILLE
Event-1
Event-5 Event- 3Event-2
Event-4
EN FONCTION
Event-6
Event-7
![Page 116: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/116.jpg)
116
États composés / Sous-états
Etat1 Etat2
Etat3 Etat4
Event-1
Event-5
Event- 3Event-2Event-4
Autre forme de modélisation équivalentePoint d ’entrée de l’état composé.
![Page 117: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/117.jpg)
117
États à historique
Un état à historique permet à un état composé qui contient des sous-états de se souvenir du dernier sous-état actif avant la transition réalisée depuis l’état
composé.
Etat1 Etat2
Etat3 Etat4
Event-1
Event-5
Event- 3Event-2
Event-4
H
Point d’entrée pour la première fois.
![Page 118: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/118.jpg)
118
États à historique (exemple)
Exemple : une machine à laver peut être arrêtée dans un état (lavage, rinçage, essorage). Elle redémarrera du même état.
Arrêtée
En lavage
En rinçage
En essorage
Mise en fonctionnement
H
Fin du cycle
Arrêt
![Page 119: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/119.jpg)
119
Diagramme d’états : exemple de la montre
Une montre digitale simple possède un cadran et 2 boutons que l’on nomme A et B, pour la mettre à l’heure. La montre a deux modes d’opération : affichage de l’heure et mise à l’heure.
Le mode de mise à l’heure a deux sous-modes, heures et minutes.
Le bouton A s’utilise pour les modes. A chaque fois que l’on appuie dessus le mode change suivant la séquence : affichage, configurer heures, configurer minutes, affichage, etc.
Dans un des 2 sous-modes ‘ configurer heures ’, ‘ configurer minutes ’, le bouton B s’emploie pour avancer les heures ou les minutes à chaque fois que l’on appuie dessus. Les boutons doivent être relâchés avant de pouvoir produire un autre événement.
![Page 120: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/120.jpg)
120
Diagramme d’états
EnAffichageHeureAppuyerA
AppuyerA
EnModificationH
on AppuyerB/IncrémenterH()
EnModificationM
on AppuyerB/IncrémenterM()
AppuyerA
EnModification
![Page 121: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/121.jpg)
121
La montre : diagramme de classes
MONTRE
-Heures : integer-Minutes : integer+AppuyerA()+AppuyerB()-IncrémenterH()-IncrémenterM()
![Page 122: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/122.jpg)
122
La montre : diagramme de classes
ModifierHeures
+ EtatSuivant()+avance()
Montre
-heures : Type-heure-minutes : Type-minute
+AppuyerA()+AppuyerB()+IncH()+IncM()
AffichageHeure
+ EtatSuivant()
ModifierMinutes
+ EtatSuivant()+avance()
EtatMontre
+EtatSuivant()
+avance()état
*1
AffichageHeure: EtatMontreModifierHeure: EtatMontreAffichageMinutes : EtatMontre
![Page 123: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/123.jpg)
123
Les événements « appel »
• Un événement « appel » est un événement interne (il survient entre les objets du système).
• Il représente le déclenchement d ’une opération.
• Un événement « appel » implique au moins 2 objets :
– celui qui invoque l’opération
– celui vers lequel l’événement est dirigé. Ce dernier devra contenir une opération de même nom que l’événement.
• Notation :
^objet-destinataire.événement-appel
![Page 124: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/124.jpg)
124
Les événements « appel » : exemple
• Autoradio :
• Voyant lumineux
EN FONCTIONEntry : ^Voyant.Allumerdo : DiffuserSon
HORS FONCTION
Entry : ^Voyant.Eteindre
MettreBouton (‘off ’)
MettreBouton (‘on’)
ALLUME
Entry : SetLumière(‘vrai’)
ETEINT
Entry : SetLumière(‘faux’)
Eteindre
Allumer
![Page 125: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/125.jpg)
125
Opérations publiques - Opérations privées
• Les opérations correspondant aux événements externes et aux événements appel correspondent à des opérations publiques (opérations déclenchées par un autre objet).
• Les opérations effectuées à l’intérieur d ’un état correspondent à des opérations privées (opérations d ’un objet sur lui-même).
![Page 126: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/126.jpg)
126
Opérations publiques - Opérations privées : exemple
• L’utilisateur peut activer MettreBouton(‘off ’), MettreBouton(‘on’) mais c’est l’autoradio qui active l’opération DiffuserSon() suivant l’état dans lequel il est.
• L’autoradio envoie un message Allumer(), Eteindre() au voyant mais c’est le voyant qui active l’opération setLumière en fonction de son état.
SonVoyant
SonAutoradio
VOYANT
-Lumière : booléen
+Allumer()
+Eteindre()
- SetLumière(b:bool)
AUTORADIO
+MettreBouton(e: string)
- DiffuserSon()
![Page 127: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/127.jpg)
127
Les événements temporels
• Les événements temporels sont causés par l’expiration d ’une temporisation. Ils peuvent être :
• absolus ( spécification d’une date ou d’une heure) et sont traduits par le mot clef when.
ex : when date = 1/01/02, pour indiquer le passage de l ’état où la monnaie était en francs à l ’état où la monnaie est en euros.
Monnaie en francs Monnaie en euroswhen date = 1/01/02
![Page 128: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/128.jpg)
128
Les événements temporels
• relatifs (spécification d’une durée par rapport à un état) et sont traduits par le mot clef after
ex : after 10 jours, pour indiquer le passage de l’état consommé à un état périmé dans le cas de produits qui se détériorent rapidement.
Médicament consommé Médicament périmé
Médicament consommable
Ouverture flacon
after 10 jours
when date du jour >= date limite
![Page 129: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/129.jpg)
129
Les événements « appel » : exemple
• Autoradio :
• Voyant lumineux
EN FONCTIONEntry : ^Voyant.Allumerdo : DiffuserSon
HORS FONCTION
Entry : ^Voyant.Eteindre
MettreBouton (‘off ’)
MettreBouton (‘on’)
ALLUME
Entry : SetLumière(‘vrai’)
ETEINT
Entry : SetLumière(‘faux’)
Eteindre
Allumer
![Page 130: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/130.jpg)
130
Opérations publiques - Opérations privées
• Les opérations correspondant aux événements externes et aux événements appel correspondent à des opérations publiques (opérations déclenchées par un autre objet).
• Les opérations effectuées à l’intérieur d ’un état correspondent à des opérations privées (opérations d ’un objet sur lui-même).
![Page 131: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/131.jpg)
131
Opérations publiques - Opérations privées : exemple
• L’utilisateur peut activer MettreBouton(‘off ’), MettreBouton(‘on’) mais c’est l’autoradio qui active l’opération DiffuserSon() suivant l’état dans lequel il est.
• L’autoradio envoie un message Allumer(), Eteindre() au voyant mais c’est le voyant qui active l’opération setLumière en fonction de son état.
SonVoyant
SonAutoradio
VOYANT
-Lumière : booléen
+Allumer()
+Eteindre()
- SetLumière(b:bool)
AUTORADIO
+MettreBouton(e: string)
- DiffuserSon()
![Page 132: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/132.jpg)
132
Petit rappel sur les relations
Il existe 4 types de relations dans UML :• la dépendance représentée par une ligne en pointillés, fléchée.
• L’association représentée par une ligne continue qui peut être fléchée (navigation).
L’agrégation est une association particulière.
• La généralisation représentée par une ligne continue fléchée avec une pointe creuse.
• La réalisation représentée par une ligne en pointillés fléchée avec une pointe creuse.
![Page 133: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/133.jpg)
133
Les diagrammes d ’activités
Un diagramme d’activités est essentiellement un organigramme qui représente l ’activité au cours du temps.
Il peut s’utiliser :
• pour préciser un cas d ’utilisation en indiquant les flux, les synchronisations, les conditions d’exécution des activités.
(on peut représenter éventuellement qui est responsable d’une activité)
• pour spécifier un algorithme associé à une opération.
![Page 134: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/134.jpg)
134
Les diagrammes d ’activités (formalisme)
– Activité (traitement)
– Transition
– Synchronisation
– Flots de données
– Flots de données dans un état particulier
– Production et consommation de flot de données
– Branchement conditionnel [garde]
Faire ...
objet:Classe
objet: [état]
[cond.1]
[cond.2]
![Page 135: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/135.jpg)
135
Commander produit
Traiter commande
Sortir article
Expédier commande
Recevoir commande
Facturer commande
Recevoir facture
Expédier facture
Payer facture
Clôturer commande
Recevoir paiement
![Page 136: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/136.jpg)
136
Les travées
Une travée permet de diviser les activités en groupes, chaque groupe représentant le département responsable de ces activités. (niveau organisationnel de Merise)
Dans un diagramme d’activité divisé en travées, chaque activité appartient à une seule travée, même si les transitions peuvent passer d’une travée à l’autre.
Les travées sont délimitées par des barres verticales. Chaque travée a un nom.
![Page 137: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/137.jpg)
137
Commander produit
Traiter commande
Sortir article
Expédier commande
Recevoir commande
Facturer commande
Recevoir facture
Expédier facture
Payer facture
Clôturer commande
Client Service ventes Entrepôt
Recevoir paiement
![Page 138: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/138.jpg)
138
Commander produit
Traiter commande
Sortir article
Expédier commande
Recevoir commande
Facturer commande
Recevoir facture
Expédier facture
Payer facture
Clôturer commande
Client Service ventes Entrepôt
f: facture[due]
f: facture[payée]Recevoir paiement
![Page 139: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/139.jpg)
139
Les composants (1)
Un composant est une partie physique remplaçable d’un système qui fournit la réalisation d’un ensemble d’interfaces. Un composant existe rarement indépendamment des autres. Un composant donné collabore avec d’autres composants.
Un composant est représenté par un rectangle avec des onglets :
Composant1
![Page 140: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/140.jpg)
140
Un composant représente en général le regroupement physique d’éléments habituellement logiques tels que les classes et leurs interfaces en tenant compte de leurs collaborations.
On peut préciser les classes qu’implémente un composant par une liaison :
Les composants (2)
Composant1
Class1 Class2
Composant1
Class1
Class2
![Page 141: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/141.jpg)
141
Les composants (3)
De la même manière que pour les classes on peut représenter les composants qui réalisent des interfaces, et les autres composants qui ont accès aux services à travers les interfaces.
Composant1Class
Composant
Lien de dépendance(accès au service)
Réalisation
Composant1<<interface>>
Class Composant
![Page 142: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/142.jpg)
142
Composants standards
UML définit 5 stéréotypes standard qui s’appliquent aux composants :
• « file » précise un composant qui représente un document contenant du code source ou des données
• « executable » précise un composant qui peut être exécuté
• « table » précise un composant qui représente une table de base de données
• « library » précise une bibliothèque objet statique ou dynamique
• « document » correspond à un document quelconque (fichier de données, d’installation, document d’aide …)
![Page 143: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/143.jpg)
143
Les diagrammes de composants
Ils montrent l’organisation et les dépendances au sein d’un groupe de composants.
En règle générale les diagrammes de composants contiennent
• des composants
• de interfaces
• des relations
– de dépendances
– de généralisation
– d’association
– de réalisation
![Page 144: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/144.jpg)
144
Les diagrammes de composants (exemple de fichiers)
signal.h {version = 3.5}
signal.h {version = 4.1}
signal.h {version = 4.0}
« parent » « parent »
irq.h
interp.cpp
device.cpp
signal.cpp {version = 4.1}
![Page 145: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/145.jpg)
145
Les nœuds
Un nœud est un élément physique qui intervient lors d’une phase d’exécution ; il représente une ressource de calcul et dispose généralement au moins d’un peu de mémoire et souvent d’une capacité de traitement.
Un nœud est en général représenté par un cube.
« mémoire »Disque
« processeur »PC
« dispositif »Modem
![Page 146: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/146.jpg)
146
Les nœuds
Les nœuds sont probablement les briques de base les plus stéréotypés en UML.
Des icônes sont souvent associées aux stéréotypes, pour fournir des repères visuels explicites pour le public auquel ils sont destinés.
![Page 147: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/147.jpg)
147
Les diagrammes de déploiement
Ils permettent de représenter l’architecture physique d’un système en visualisant les classes de nœuds (ou des instances de nœuds) et les relations de dépendances et d’associations entre ceux-ci.
Ils peuvent également comporter les composants qui doivent résider sur un nœud.
Remarque :
si on développe un logiciel sur une seule machine avec en interfaces des périphériques standards, on peut se passer de diagrammes de déploiement.
Nœud
Composant
Nœud
Composant
![Page 148: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/148.jpg)
148
Les diagrammes de déploiementavec des icônes
![Page 149: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/149.jpg)
149
Diagramme de déploiement : diagramme de spécification
Modélisation de la répartition des composants
kiosque
console
tour de disques RAID10-T Ethernet
RS-232
<<executable>>user
<<executable>>admin
<<executable>>config
10
20
1serveur
<<executable>>dbadmin
<<executable>>tktmstr
vitesseProcesseurmémoire
![Page 150: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/150.jpg)
150
Diagramme de déploiement : diagramme d’instances
s:Serveurk1:kiosque
k2:kiosque
c1:console
t:tour de disques RAID
vitesseProcesseur = 2Ghzmémoire=256Mo
![Page 151: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/151.jpg)
151
![Page 152: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/152.jpg)
152
![Page 153: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/153.jpg)
153
De l’analyse … à la conception
L’analyse des besoins est l’activité essentielle au début du processusde développement d’un logiciel.
Le futur utilisateur exprime ses besoins sous une forme textuelle informelle, parfois accompagnée de modèles d’IHM permettant de mieux préciser des souhaits.
Analyse des besoins
![Page 154: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/154.jpg)
154
Le cas bibliothèque.
La bibliothèque d’une école d’ingénieurs met à disposition des élèves et des enseignants des livres techniques qui peuvent être empruntés. Chaque emprunteur dispose d'un badge, comportant un numéro, son nom et son prénom, qu'il doit présenter pour accéder à la bibliothèque. Il peut emprunter autant de livres qu'il le désire.
La durée de l'emprunt n'est pas limitée.
Chaque livre est repéré par un numéro, un titre, le nom de l'auteur principal, l'année d'édition.
![Page 155: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/155.jpg)
155
Le cas bibliothèque.
On ne cherche pas à faire d'historique des emprunts. On veut seulement savoir quelle personne détient un livre de manière à pouvoir la contacter si une autre souhaite consulter l'ouvrage. Pour cela, on dispose pour chaque personne de son “ e- mail ”.
Il est nécessaire de pouvoir enregistrer un nouveau livre, un nouvelemprunteur. On voudrait pouvoir éditer des statistiques.
![Page 156: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/156.jpg)
156
Le cas bibliothèque : IHM - retour anonyme
Retour anonyme :
Entrer le numéro du livre : 1 2 3 4 5 (RC) Le génie logiciel orienté Objet
![Page 157: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/157.jpg)
157
Le cas bibliothèque : IHM - retour d’un étudiant
Retour d’un étudiant :
Retour d’ étudiantEntrer le numéro de l’emprunteur : 456 (RC)
Jean Dupuy
Livres empruntés : Le génie logiciel orienté Objet OCL pour les nuls
![Page 158: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/158.jpg)
158
Spécification globale
Le but de cette activité est d'établir une première description du futur système.
L’expression préliminaire des besoins donne lieu à une modélisation par des
Cas d’utilisation
et à une maquette d’IHM.Il faudra donc :
• identifier les acteurs• identifier les cas d’utilisation• ajouter si besoin des relations entre cas d’utilisation.
Il sera utile d’établir une priorité entre les cas d’utilisation de manièreà aider le chef de projet à planifier ses itérations (modèle de la spirale).
![Page 159: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/159.jpg)
159
Le cas bibliothèque : cas d’utilisation
Enregistrer Retour
Enregistrer EmpruntBibliothécaire
Enregistrer Nouveau Livre
Priorité 2
Enregistrer Nouvel Emprunteur
Éditer Statistiques
![Page 160: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/160.jpg)
160
EnregistrerRetourAnonyme
Enregistrer Retour
Bibliothécaire
Le cas bibliothèque : cas d’utilisation
EnregistrerRetourEtudiant
![Page 161: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/161.jpg)
161
Spécification globale (2)
Il s’agit ensuite de créer une représentation visuelle des objets du monde réel dans un domaine donné.Ils seront représentées dans un
Diagramme de classes d’analyse
ne mettant en évidence que peu d’opérations.
Par contre les attributs évoqués (caractéristiques d’un livre, d’un emprunteur, etc.) dans les cas d’utilisation ainsi quetoutes les associations suggérées (emprunt caractérisé comme une association entre LIVRE et PERSONNE) devront y figurer.
![Page 162: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/162.jpg)
162
Le cas bibliothèque : diagramme de classes d’analyse
1
*
SaBiblio
BIBLIOTHEQUE
SesLivresSaBiblio
*1
SesEmprunteurs
PERSONNE
LIVRE
SesEmprunts
NumeroNomPrénomE-mail
SonEmprunteur
0..1
*
Professeur
Numéro Titre AuteurAnnéeEdition
Dans la phase d’analyseil n’est pas indispensable de faire apparaître la classe du domaine.
![Page 163: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/163.jpg)
163
Spécification détaillée des exigences
Une fiche de description textuelle de chaque cas d’utilisation doit être fournie.Il est nécessaire de fournir :• le scénario qui permet de satisfaire les objectifs des acteurs par le chemin le plus direct de succès.• les extensions qui comprennent tous les scénarios de succès ou d’échec.Il faut également préciser :• les pré conditions qui définissent ce qui doit être vrai en amont ducas d’utilisation pour que celui-ci puisse démarrer.• Les post conditions qui définissent ce qui doit être vrai lorsque lecas d’utilisation se termine.
![Page 164: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/164.jpg)
164
Le cas bibliothèque : scénario
Système : la Bibliothèque
Acteur Primaire : un bibliothécaire
Objectif : enregistrer les retours de livres d'un étudiant qui présente sa carte.
Scénario :1 - Rechercher à partir d'un numéro de carte, le nom de l’étudiant et la liste des titres des livres qu’il a empruntés.2 - Pour chaque livre sélectionné, enregistrer le retour.
Exception :1a -le numéro saisi est inconnu --> demander de recommencer.
Pré condition : le livre retourné figure dans la liste des livres empruntés.
![Page 165: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/165.jpg)
165
Spécifications OCL
context EnregistrerEmprunt( NumL, NumP : integer) {signals echec}pre :Valide : boolean =
Il existe une instance de Livre avec numéro Numl.Cette instance n’est pas déjà empruntée.Il existe une instance de Personne avec numéro NumP.
post :not Valide implies echec.sent()Valide implies
L’instance de Livre avec numéro NumL a comme emprunteur la Personne avec numéro NumP.L’instance de Livre avec numéro NumL figure dans les emprunts de la Personne avec numéro NumP.
![Page 166: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/166.jpg)
166
Spécifications OCL
context EnregistrerEmprunt( NumL, NumP : integer) {signals echec}pre :Valide : boolean =
Livre.allInstances exists ( L | L.Numéro =NumL)Personne.allInstances exists ( P | P.Numéro =NumP)let L1 : Livre | L1.Numéro = NumL inL1.sonEmprunteur isEmpty()
post :not Valide implies echec.sent()Valide implies
let L1 : Livre | L1.Numéro = NumLP1 : Personne | P1.Numéro = NumP inL1.SonEmprunteur = P1P1.SesEmprunts = P1.SesEmprunts@pre including (L1)
![Page 167: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/167.jpg)
167
Spécifications OCL
context EnregistrerRetour( NumL : integer) {signals echec}pre :Valide : boolean =
Il existe une instance de Livre avec numéro Numl.Cette instance est empruntée par une Personne.
post :not Valide implies echec.sent()Valide implies
L’instance de Livre avec numéro NumL n’a pas d’emprunteurL’instance de Livre avec numéro NumL ne figure pas dans les emprunts de la Personne qui l’avait avant l’enregistrement de retour.
![Page 168: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/168.jpg)
168
Spécifications OCL
context EnregistrerRetour( NumL : integer) {signals echec}pre :Valide : boolean =
Livre.allInstances exists ( L | L.Numéro =NumL)let L1 : Livre | L1.Numéro = NumL inL1.sonEmprunteur notEmpty()
post :not Valide implies echec.sent()Valide implies
let L1 : Livre | L1.Numéro = NumLP1 : Personne | P1= L1.SonEmprunteur@pre inL1.SonEmprunteur isEmptyP1.SesEmprunts = P1.SesEmprunts@pre excluding (L1)
![Page 169: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/169.jpg)
169
Spécification détaillée des exigences
Les cas d’utilisation décrivent les interactions des acteurs avec lesystème.On peut représenter ces échanges à l’aide de
Diagrammes de séquence système.
Le comportement du système est décrit vu de l’extérieur, sanspréjuger de comment il sera réalisé.
![Page 170: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/170.jpg)
170
Le cas bibliothèque : diag de séquence système - retour étudiant
:LeSystème:Bibliothécaire
TrouverLivres(NumEtu)
NomEtu +{titre}
EnregistrerRetour(titre)
![Page 171: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/171.jpg)
171
Spécification détaillée (suite)
Il est nécessaire de contrôler la validité du texte des cas d’utilisationpar rapport aux informations définies dans le diagramme de classesconceptuelles.
Afin de pouvoir relier les diagrammes de cas d’utilisation audiagramme de classes conceptuelles, il est nécessaire d’identifierles principales classes d’IHM ainsi que les opérations qui vontmontrer la logique de l’application.
On va définir un diagramme supplémentaire appelé
Diagramme de classes de conception
![Page 172: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/172.jpg)
172
Typologie des classes de conception
• Les classes qui modélisent les interactions entre le système et les utilisateurs, appelées classes « dialogue ».
• Les classes qui représentent les processus, les ressources etl’organisation d’une entreprise, appelées classes « métier ».Elles sont souvent permanentes.
• Les classes qui contiennent la cinématique de l’application, appelées classes « contrôle ». Elles font la transition entre les classes dialogues et les classes métiers et contiennent les règles métiers.
![Page 173: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/173.jpg)
173
Les classes « métier »
Ce sont les classes étudiées jusqu’à présent. Celles-ci représentent en général des informations persistantes de l’application.
Métier MM
donnée1donnée2donnée3
opér1()opér2()
![Page 174: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/174.jpg)
174
Les classes « dialogue »
Elles possèdent des attributs et des opérations. Les attributs vont représenter des champs de saisie ou des résultats. Les résultats sont distingués en utilisant la notation de l’attribut dérivé.Les opérations représentent des actions de l’utilisateur sur l’ IHM, oudes actions de la classe de contrôle.
Dialogue DD
champ1champ2/résultat
action1()action2() saisir ou afficher
![Page 175: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/175.jpg)
175
Les classes « contrôle »
Elles possèdent uniquement des opérations.Elles montrent :
• la logique de l’application, • les règles métier, • les comportements du système informatique.
Contrôle CC
opération1()opération2()
![Page 176: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/176.jpg)
176
Règles de composition des diagrammes de classes de conception
• Les « dialogues » ne peuvent être reliés qu’aux « contrôles ».• Les « métiers » ne peuvent être reliées qu’aux « contrôles » ou autres « métiers ».• Les « contrôles » ont accès à tout type de classes, y comprisd’autres contrôles.
Contrôle CC
opération1()opération2()
Dialogue DD
champ1champ2/résultataction1()action2()
Métier MM
donnée1donnée2donnée3opér1()opér2()
![Page 177: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/177.jpg)
177
Un exemple simple
Écran de saisieNouveau Livre
CréerNouveau Livre
Livre
CtrCréation
créerLivre(titre, auteur)
Saisie Livre
titreauteur
saisir(titre, auteur)
Livre
numérotitreAuteur+Livre(titre, auteur)
- nouveauNuméro()
![Page 178: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/178.jpg)
178
RetourAnonyme
NumLivre
/titre+AfficherTitre()+ EnregRetour()
CtrRetourAnonyme
+EnregRetour (NumLivre)-AfficherTitre(NumLivre)-TrouverLivre (NumLivre)
Livre
-numéro-titre-auteur
+RetirerEmprunteur(P:Personne)
Le cas bibliothèque : diag de classes d’analyse - retour anonyme
Personne
-numéro-nom-prénom
+RetirerLivre(L:Livre)
SonEmprunteur
0..1
*
SesEmprunts
![Page 179: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/179.jpg)
179
RetourEtudiant
NumEtud/nom
+AfficherNom(N:string)+AffTitreLivre()
CtrRetourEtudiant
+AffTitreLivre(NumEtud)-AfficherNom(NumEtud)-AfficherTitre(T:sting)+EnregRetour (L:Livre)
Livre
-numéro-titre-auteur
Livre-Dialogue
/titre
+Créer()+sélectionner()
Le cas bibliothèque : diag de classes d’analyse - retour étudiant
Etudiant
-numéro-nom-prénom
SonEmprunteur
0..1
*
SesEmprunts
![Page 180: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/180.jpg)
180
La conception
Elle vise principalement à préciser le modèle d’analyse de telle sorte qu’il puisse être implémenté avec les éléments d’architecture dont ondispose.• Les classes deviennent plus précises, avec des attributs typés.• Au niveau des « ensembles », il est nécessaire de préciser s’ils serontimplémentés sous forme de listes, de tableaux …• Les opérations sont complètement qualifiées ; on précise leur visibilité.• La navigation doit être mentionnée.
Pour ces 2 derniers points, il est nécessaire de répartir les responsabilités entre les différents objets. On a recours aux diagrammes de séquence.
![Page 181: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/181.jpg)
181
Diagrammes de séquence.
:LeSystème
:Acteur
Action1()
retour
:Acteur
Action1()
retour
:Dialogue :Contrôle :Métier
Opération1()
GetDonnées()
![Page 182: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/182.jpg)
182
Le cas bibliothèque : diag de séquence - retour Anonyme
:Bibliothécaire
EnregistrerRetour(Num))
RetourAnonyme CtrRetourAnonyme L: Livre SonEmp:Personne
EnregistrerRetour(Num)
Afficher(Titre)
TrouverLivres(Num)
SupprimerEmprunt()
getTitre()
Titre
RetirerLivre(self)
RetirerEmprunteur()
L
![Page 183: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/183.jpg)
183
Le cas bibliothèque : diag de séquence - retour Étudiant
:Bibliothécaire
AffTitreLivre(num)
RetourEtudiant CtrRetourEtudiant P : Personne L:Livre
AffTitreLivre(Num)
TrouverEtud(num)
getNom()
getTitre()
Livre-dial
Titre
Nom
{Titre}
Afficher(Nom)
AffTitreLivre()
Créer(Titre)
Pour chaque livre L...
Pour chaque livre de la liste établie.
P
![Page 184: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/184.jpg)
184
Le cas bibliothèque : diag de séquence - retour Étudiant
:Bibliothécaire
Sélectionner(L:Livre)
CtrRetourEtudiant L: Livre SonEmp:Personne
Sélectionner()
Livre-dial
RetirerLivre(self)
RetirerEmprunteur()
SupprimerEmprunt()
![Page 185: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/185.jpg)
185
Quelques règles générales de présentation des diagrammes
• Disposer les éléments de façon à éviter que les lignes se croisent.
• Organiser les éléments de façon à ce que les éléments proches du point de vue sémantique soient également proches du point de vue physique.
• Ne JAMAIS présenter un diagramme et les commentaires s’y rapportant en recto-verso.
• Ne JAMAIS présenter des diagrammes se rapportant au même problème sur des pages recto-verso.
![Page 186: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/186.jpg)
186
Quelques règles de définition du diagramme de classes
• Nommer les attributs avec des noms courts ou des petites expressions nominales qui représentent une des propriétés de la classe.
• Nommer les opérations avec des verbes courts ou de petites expressions verbales qui représentent certains comportements de leur classe englobante.
• Les noms de classes sont notés en majuscules : PERSONNE.
• Les noms d’attributs, d’opérations, de rôles commencent par une majuscule et les noms composés sont accolés, chacun commençant par une majuscule : DateDeNaissance.
• En règle générale les attributs sont privés et les opérations publiques.
![Page 187: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/187.jpg)
187
Règles de définition du diagramme de classes (suite)
• Les opérations seront notées sous la forme :NomOpération(liste de paramètres) : type résultat
Ex : RechercherProduit(Code : integer) : PRODUITSauf consigne particulière on précisera paramètres et type de retour.
• On ne met JAMAIS en paramètre l’objet qui contient l’opération.
• Les opérations qui permettent d ’accéder aux attributs sont de la forme GetAttribut(). Ex : GetNom() : string (… mais CalcPrixTTC() : real )
• Les opérations qui permettent de modifier un attribut sont de la forme SetAttribut(paramètre). Ex : SetAdresse (A : string)
![Page 188: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/188.jpg)
188
Règles de définition du diagramme de classes (suite)
• Les noms des rôles avec cardinalité 0..1 ou 1 commencent par Son ou Sa (Ex : SonPropriétaire, SaForme).
• Les noms des rôles avec cardinalité 0..* ou 1..* commencent par Ses (Ex : SesPropriétés).
• La navigabilité sera explicitée (flèche dans un ou deux sens).
![Page 189: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/189.jpg)
189
Règles de définition des diagrammes de séquence
• Les opérations mises en évidence sur les diagrammes de séquence doivent figurer sur le diagramme de classes. On vérifiera que les paramètres sont cohérents entre les deux diagrammes.
• Les opérations seront précisées avec les paramètres (noms de variable plutôt que types de variables).
• Les messages de retour seront précisés dans la mesure du possible.
Notation : la répétition d ’information sera indiquée avec des accolades
{date + { titre + quantité }}
![Page 190: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/190.jpg)
190
Règles de définition des diagrammes de séquence (suite)
• Lorsqu’un message est adressé à plusieurs instances I d’une même classe, on le mentionne dans une note associée au message.
Cette note est de la forme :
‘ Pour chaque instance I prise dans l’ensemble des instances ’
et le message est adressé à une instance nommée I.
• On privilégie les diagrammes de séquence de type décentralisé ou en escalier.
• On évite les conditions ; si besoin on fait 2 diagrammes de séquence.
![Page 191: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/191.jpg)
191
Règles de définition des diagrammes d’états
• Les noms des événements de transition et les noms des événements internes (derrière le mot clef on ) sont des noms d’opérations publiques de l’objet pour lequel est fait le diagramme d’état.
• Les opérations effectuées en entrée ou en sortie d’un état, et les opérations effectuées au sein d’une activité sont des opérations privées de l’objet pour lequel est fait le diagramme d’état.
• Toutes ces opérations doivent figurer sur le diagramme de classes avec visibilité (public/privé) et paramètres cohérents entre les deux diagrammes.
![Page 192: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/192.jpg)
192
Attributs et opérations implicites (4)
ETUDIANT
Nom : string
ETUDIANT
Nom : stringSesVoeuxDOptions : liste(OPTION)
<modificateur>AjouterOption(OPTION):boolEnleverOption(OPTION):boolGetSesOptions() : liste(OPTION)
OPTION
Libellé : string
SesVoeuxDOptions
0..*{ordonné}
L’introduction de la contrainte{ordonné}
permet de traiter SesVoeuxDOptioncomme une liste
![Page 193: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/193.jpg)
193
Diagramme de déploiement : exemple des portes (diagramme de spécification)
Serveur
SGBD
PC
Pilote
Portes
TX
RNIS
1
*
TCP/IP
Console
3 1
Maître
1
1..10
Imprimante
1
1
![Page 194: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/194.jpg)
194
Diagramme de déploiement : exemple des portes (diagramme d’instances)
PC4 : PC
P2 :PorteP3 : Porte
P1 : Porte
Remarque : les instances sont soulignées.
![Page 195: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/195.jpg)
195
La CBM (Computer Books by Mail) est une sociétéde distribution d'ouvrages d'informatique qui agitcomme intermédiaire entre les librairies et leséditeurs. Elle prend des commandes en provenancedes libraires, s'approvisionne (à prix réduit) auprèsdes éditeurs concernés et livre ses clients à réceptiondes ouvrages. Il n'y a donc pas de stockage. Seulesles commandes des clients solvables sont prises encompte.
Exemple de base
![Page 196: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/196.jpg)
196
Le design pattern : State
ConcreteStateB
+Handle()
Context
+request(…)
ConcreteStateA
+Handle()
état
*
State
+Handle()1
![Page 197: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/197.jpg)
197
![Page 198: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/198.jpg)
198
![Page 199: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/199.jpg)
199
![Page 200: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/200.jpg)
200
U.M.L.
Unified Modeling Language
(3ème partie)
Françoise Schlienger
FIIFO4 2003-2004
![Page 201: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/201.jpg)
201
Plan de la troisième partie
• Les diagrammes d’activités 139
• Les diagrammes de composants 149
• Les diagrammes de déploiement 153
• De l’analyse … à la conception 159
![Page 202: 1. 2 U.M.L. Unified Modeling Language (1 ère partie) Françoise Schlienger 4 ème année 2004-2005.](https://reader036.fdocument.pub/reader036/viewer/2022062312/551d9d85497959293b8c04ff/html5/thumbnails/202.jpg)
202
Booch
Unified MethodUnified Method0.8
etc...
OOSE(Jacobson et al.)
UML 0.9UML 0.9
1996
etc.ROOMCatalysis
OMGOMG
UML 1.1UML 1.1
Nov. 1997Nov. 1997
UML 1.3UML 1.3
UML 1.4UML 1.4
UML 2.0UML 2.0
Juin 1999Juin 1999
FinFin 200 20011
……
HOOD
OMT (Rumbaugh et al.)
1995
RationalRational
ROOM
Classe-Relation
Fusion
OOSE
Booch
OMT
Fin 1990