UML2 : Les diagrammes - PowerPoint PPT Presentation

1 / 201
About This Presentation
Title:

UML2 : Les diagrammes

Description:

Cette cr ation est mise disposition selon le Contrat Paternit ... Une d pendance traduit l'existence d'un lien fugitif entre deux classes, par exemple lors ... – PowerPoint PPT presentation

Number of Views:919
Avg rating:3.0/5.0
Slides: 202
Provided by: laurenth6
Category:
Tags: diagrammes | fugitif | les | uml2

less

Transcript and Presenter's Notes

Title: UML2 : Les diagrammes


1
UML2 Les diagrammes
  • Laurent Henocque
  • http//laurent.henocque.free.fr/
  • Enseignant Chercheur ESIL/INFO France
  • http//laurent.henocque.perso.esil.univmed.fr/
  • mis à jour en Novembre 2008

2
Licence Creative Commons
  • Cette création est mise à disposition selon le
    Contrat Paternité-Partage des Conditions
    Initiales à l'Identique 2.0 France disponible en
    ligne
  • http//creativecommons.org/licenses/by-sa/2.0/fr/
  • ou par courrier postal à Creative Commons, 559
    Nathan Abbott Way, Stanford, California 94305,
    USA.

3
Références Normatives
  • L'infrastructure UML
  • http//www.omg.org/cgi-bin/doc?formal/05-07-05
  • La superstructure UML
  • http//www.omg.org/cgi-bin/doc?formal/05-07-04
  • OCL
  • http//www.omg.org/cgi-bin/doc?ptc/05-06-06

4
Autres références
  • Ce support de cours s'appuie sur des exemples
    concrets mis à disposition librement sur internet
    par différentes sources
  • http//www.rational.com
  • http//www.visualuml.com
  • http//uml.free.fr
  • http//http//www.sparxsystems.com.au/resources/um
    l2_tutorial/index.html

5
Objectifs
  • Présenter les différents diagrammes UML2.0

6
UML Diagrammes de Classes
7
Préambule
  • UML propose des artéfacts particuliers pour les
    diagrammes.
  • Toutefois, ces propositions sont seulement
    suggérées, ne sont pas obligatoires, et ne font
    en aucun cas partie de la norme
  • Un diagramme à la mode OOA (nuages) peut donc
    constituer un document UML valide, selon des
    conventions prédéfinies

8
Diagrammes de Classes
  • les diagrammes de classes, ou de structure,
    définissent les constructions élémentaires d'un
    modèle types, classes, relations utiles pour le
    reste (pose des contraintes)

9
Elements graphiques des diagrammes statiques
10
Exemple
11
Exemples de Classes
12
Classes héritage
13
Classes associations
14
Classe notation simple
  • Une classe définit un "type", ensemble d'objets
    pouvant exister à l'exécution du programme

Voiture
Bateau
Véhicule
15
Encapsulation
16
Classe syntaxe détaillée
17
Attribut multivalué
18
Attribut dérivé
19
Classes Abstraites
20
Héritage
21
Heritage ??
22
Polymorphisme
23
Généralisation
Super-classe
Animal
Généralisation
Spécialisation
Chat
Chien
Raton laveur
COHERENCE
Sous-classe
24
Héritage multiple
MULTIPLE
Véhicule
Tapis
Super-classe
Super-classe
Aérien
Terrestre
Tapis volant
Fusion de plusieurs classes en une seule classe
Sous-classe
25
Généralisations Multiples
Véhicule
DISCRIMINANT
DISCRIMINANT
Motorisation
Milieu
A voile
Terrestre
A moteur
Marin
26
Obligation d'Héritage de toutes les dimensions
Véhicule
Motorisation
Milieu
Inclusif
A voile
Terrestre
A moteur
Marin
Pétrolette
Nécessaire
27
Exemple
28
Core Backbone Simplifié
29
Classification (Distilled)
30
Dérivation (Distilled)
31
Exemple Espresso Compilateur
  • http//types.bu.edu/Espresso/report/Espresso.html

32
Types fondamentaux
33
Exemple log4j
34
Stéréotypes et Variations
35
Instances
36
Stéréotypes dans les classes
37
Le stéréotype "utility"
38
Templates
39
SP CPP
40
UML Packages
41
Diagrammes de Packages
  • Utilisés pour séparer le modèle en conteneurs
    logiques, et décrire leurs interactions à un haut
    niveau

42
Exemple de Packages
43
Packages
44
Packages
45
Stéréotypes de Packages
46
(No Transcript)
47
Packages (Distilled)
48
UML Associations
49
Association
50
Lien
51
Nommage d'Association
52
Rôles
53
Nécessité des noms de Rôles
54
Cardinalités
55
Navigabilité
56
Agregation
57
Relation de Composition
58
Composition Vue Interne
59
Agrégation et composition (Distilled)
60
Associations qualifiées
61
Association qualifiée (Distilled)
62
Relation N-aire
63
Classe d'association
64
Classe d'association (Distilled)
65
Classe d'association 2
66
Association dérivée
67
Relation de dépendance
  • Une dépendance traduit lexistence dun lien
    fugitif entre deux classes, par exemple lors de
    la création dun objet, ou dun passage de
    paramètre

68
DernierDiagrammeClasses (Distilled)
69
UML Contraintes Exprimées dans le modèle
70
Contraintes
71
Contraintes
72
Contraintes
73
Contraintes Exercice tout peut être décrit
dans le modèle?
74
UML Interfaces
75
Interfaces
76
Interfaces
77
Réalisation d'Interfaces
78
Interfaces (Distilled)
79
Interfaces (Distilled)
80
UML Composants Déploiement
81
Diagrammes Objet (d'instances)
  • Les diagrammes objet illustrent les interactions
    concrètes entre instances de classes (les liens y
    sont des instances des relations)

82
Composants et Composites
83
Liens internes entre composants
84
Instances
  • Les instances ne sont pas utilisées dans les
    diagrammes de classes, mais apparaissent dans les
    cas d'utilisation, et les diagrammes de trace
    d'événements (activity diagrams)

85
Instances
86
Diagramme de collaboration
87
Exemple
88
Diagrammes de Structure Composite
  • Les diagrammes de structure composite donnent le
    moyen de stratifier la structure et de se
    concentrer sur des détails internes concernant
    les associations.
  • Un tel diagramme décrit la structure interne d'un
    classifieur.

89
Exemples
90
Collaborations
91
Diagrammes de Composants
  • Les diagrammes de composants sont utilisés pour
    modéliser des structures à plus haut niveau, ou
    plus complexes, qui déclarent des interfaces
    précises. La plupart du temps, un composant fait
    intervenir plusieurs classes

92
Exemples
93
Deployment Diagrams
  • Les diagrammes de déploiement décrivent la
    disposition concrète des éléments du modèle dans
    le monde physique

94
Exemples
95
Exemples
96
Modules
97
Composants
98
Ex Composants ArgoUML
99
Déploiement
100
Deploiement (Distilled)
101
UML Etats
102
Diagrammes de machines d'états finis
  • Les diagrammes d'état finis décrivent les états
    stables d'une classe, et les transitions quoi s'y
    appliquent

103
Exemple
104
Exemples
105
Exemples
106
Exemple
107
Exemple
108
Jonction
109
Historique
110
Concurrence
111
Diagrammes de Communication
  • Les diagrammes de communication décrivent le
    réseau et le séquencement de messages entre
    objets pendant l'exécution d'une collaboration

112
(No Transcript)
113
(No Transcript)
114
Transition
115
Transition Gardée
116
Etats Composites
117
Abstraction des Etats Composites
118
Entry / Exit / On / Do
119
Transitions Boucles
120
Parallélisme
121
Synchronisation
122
Exemple Etats
123
Etats (Distilled)
124
Etats (Distilled)
125
Etats (Distilled)
126
UML Activités
127
Activity Diagrams
  • Les diagrammes d'activité ont un large champ
    d'utilisation. A plus haut niveau, ils peuvent
    servir à capturer les points de décision et le
    contrôle dans un process. Ils peuvent aussi
    servir à documenter un algorithme.

128
Exemple
129
Exemple
130
Exemple
131
Exemple
132
Expansion regions
133
Exemple exceptions, régions interruptibles
134
Parameter sets
135
Transition entre Activités
136
Couloirs d'Activités
137
Transition Gardée
138
(No Transcript)
139
Machineà Café
140
Synchronisation
141
UML Séquences
142
Diagrammes de Séquence
  • Les diagrammes de séquence sont des diagrammes de
    communication dans lesquels la dimension
    verticale est utilisée pour matérialiser
    l'écoulement du temps

143
Exemples
144
Exemples
145
Temps concret
146
Boucles
147
Sections critiques
148
Décomposition
149
Invariants
150
Séquences
151
Activation
152
Messages de Séquences
153
Diagramme deSéquence
154
Sequence (Distilled)
155
Sequence (Distilled)
156
Sequence (Distilled)
157
UML Collaborations
158
Collaborations
159
Collaborations
160
Collaborations
161
Collaboration au Niveau Classe
162
Collaboration (Distilled)
163
Collaborations et Packages
164
UML Use Cases
165
Diagrammes de Cas d'Utilisation
  • Ces diagrammes modélisent des interactions entre
    les utilisateurs et le système. Ils définissent
    le comportement, les conditions et contraintes
    sous la forme de scripts ou de scénarios

166
Exemples
167
Exemples
168
Exemples
169
Use Cases dans l'analyse
170
Use Cases
171
Use Case
172
Use Case
173
Stéréotypes de Use Cases
174
Relations de Use Case (Distilled)
175
Use Case Points d'extension (Distilled)
176
UML Diagrammes de Timing
177
Timing Diagrams
  • Ces diagrammes combinent les diagrammes de
    séquence et d'état pour proposer un point de vue
    sur l'évolution de l'état d'un objet au fil du
    temps, et sur les messages qui modifient cet état.

178
(No Transcript)
179
(No Transcript)
180
UML Diagrammes d'"interaction overview"
181
Interaction Overview Diagrams
  • Ces diagrammes utilisent diagrammes d'activité et
    de séquence pour décrire comment des fragments
    d'interaction (décrits par des diagrammes de
    séquence) sont combinés par des points de
    décision et des flux

182
(No Transcript)
183
UML 2.0 Elements nouveaux
184
Métamodèle
  • Diagrammes de collaboration -gt diagrammes de
    communication
  • Diagrammes de d'interaction hybrides (overview of
    interaction)
  • Diagrammes temporels (timing diagrams)
  • Diagrammes de structure composite

185
Diagrammes de classe
  • Les attributs et les associations
    unidirectionnelles sont devenues deux notations
    équivalentes pour le même concept de "propriété"
    (property).
  • Les multiplicités discontinues ont été
    abandonnées (2,7)
  • Diverses propriétés et mots clef ont été
    abandonnées ("frozen", ltltparametergtgt, ltltlocalgtgt)

186
Diagrammes de séquence
  • Nouvelle notation dite de "cadre d'interaction"
    (interaction frame) pour les sections itératives,
    conditionnelles de l'exécution, et divers modes
    de contrôle
  • Cela permet de décrire des algorithmes de façon
    réaliste dans les diagrammes de séquence

187
Diagrammes de Séquence
188
Diagrammes de séquence (2)
  • Les marqueurs d'itération et les gardes des
    messages ont été supprimés (ils servaient
    précisément à décrire des algorithmes)
  • Les têtes de lignes de vie ne sont plus des
    instances, mais des "participants"

189
Diagrammes de classe
  • Les stéréotypes sont plus précisément définis.
    Les chaînes entre guillemets sont des "mots clef"
    (keyword), dont certains seulement sont des
    stéréotypes
  • La classification multiple utilise des ensembles
    de classification ("classification sets") pour
    grouper les généralisations

190
Interfaces
  • Les classes peuvent requérir des interfaces, et
    pas seulement les proposer

191
Diagrammes de composants
  • Les composants n'ont plus une icône spécifique,
    mais deviennent un stéréotype comme les autres
  • (la différence entre classe et composant n'avait
    jamais été claire)

192
Structure composite
  • La structure composite permet de décomposer
    récursivement une classe dans sa structure
    interne, notamment pour faire apparaître les
    éléments de la classe liés aux interfaces

193
Exemple de Structure Composite
194
Classe Active
  • Une classe active décrit des instances dont
    chacune possède son propre thread de contrôle.

195
Diagrammes d'état
  • UML 2.0 supprime la distinction entre actions et
    activités.
  • Une activité est simplement indiquée par une
    clause dans un état "do/"
  • (ou "do-activity/")

196
Diagrammes d'activité
  • Ces diagrammes ne sont plus un cas particulier
    des diagrammes d'état
  • Suppression de l'obligation de faire correspondre
    chaque "fork" à un "join"
  • Ces diagrammes sont mieux compris comme des
    diagrammes de flot de jetons (de type réseau de
    Petri)

197
Diagrammes d'activité
198
Diagrammes d'activité
  • Nombreuses nouvelles notations
  • signaux de temps et d'acceptation
  • paramètres
  • spécifications de join
  • pins (puces)
  • transformations de flot
  • rateaux de sous diagrammes (subdiagram rakes)
  • régions d'expansion
  • terminaisons de flots

199
Diagrammes d'activité
  • Les flots entrants multiples étaient traités
    comme un "merge" implicite en UML 1.x (sans
    synchronisation)
  • Ils deviennent un "join" implicite (avec
    synchronisation)
  • Recommandation utiliser des join ou merge
    explicites!

200
Diagrammes d'activité
  • Les lignes de vie (life lines ou swim lanes)
    devinennent multi dimensionnelles,
  • elles sont appelées des partitions

201
Fin du document
Write a Comment
User Comments (0)
About PowerShow.com