Table des matières
1 Introduction 1
1.1 Objectif 1
1.2 Structure du document . 2
I Diagramme de classes 6
2 Eléments´ 7
2.1 Element 7
2.2 Namespace . . . . . . . 7
2.3 Named Element . . . . . 8
2.4 Comment . . . . . . . . 9
2.5 Multiplicity . . . . . . . 9
2.6 Value Specification and Expression . . . 10
2.7 Constraint . . . . . . . . 11
2.8 Keyword 11
2.9 Element Properties . . . 12
2.10 Instance Specification . . 13
2.11 Classifier 14
2.12 Class . . 14
2.13 Redefinable Element . . 15
2.14 Operation . . . . . . . . 16
2.14.1 Règles sur le méta-modèle . . . . 16
2.14.2 Règles impliquant les modèles . . 16
2.15 Property (au sens possession) . . . . . . 18
2.15.1 Règles générales . 19
2.15.2 Attribute . . . . 21
2.16 Data Type . . . . . . . . 22
2.17 Enumeration . . . . . . . 22
2.17.1 Déclaration . . . 22
2.17.2 Utilisation . . . . 22
2.18 Primitive Type . . . . . 23
2.19 Package 23
2.20 Model . 23
2.21 Interface 24
2.22 Signal . 24
2.23 Reception . . . . . . . . 25
2.24 Association Class . . . . 25
2.25 Parameterable Element . 26
2.26 Template Parameter . . 26
2.26.1 Règles générales . 26
2.26.2 Classificateur . . 27
2.26.3 Opération . . . . 27
2.27 Template Signature . . . 28
2.28 Templateable Element . 28
2.28.1 Règles générales . 28
2.28.2 Opération . . . . 29
2.29 Behaviored Classifier . . 29
2.30 Behavior 29
3 Relations 31
3.1 Element Import . . . . . 31
3.2 Package Import . . . . . 32
3.3 Generalization . . . . . . 33
3.3.1 Eléments mis en relation´ . . . . . 33
3.3.2 Generalization Set . . . . . . . . 33
3.3.3 Eléments abstraits´ . . . . . . . . 34
3.4 Dependency . . . . . . . 35
3.5 Abstraction . . . . . . . 36
3.5.1 Règles générales . 36
3.5.2 Derive Stereotype 36
3.5.3 Refine Stereotype 37
3.5.4 Trace Stereotype 37
3.6 Realization . . . . . . . 37
3.7 Substitution . . . . . . . 37
3.8 Usage . 38
3.8.1 Call Stereotype . 38
3.8.2 Create Stereotype 39
3.8.3 Instantiate Stereotype . . . . . . 39
3.8.4 Send Stereotype . 39
3.9 Association . . . . . . . 40
3.9.1 Règles communes à toutes les associations . . . . 40
3.9.2 Décorations des fins d’associations n-aires quand n>2 . . . . . . . 45
3.9.3 Association Binaire . . . . . . . . 46
3.9.4 Spécialisation d’association . . . . 47
3.10 Package Merge . . . . . 48
3.11 Template Binding . . . . 48
4 Diagrammes 50
4.1 Class Diagram . . . . . . 50
II Diagramme de composants 52
5 Eléments´ 53
5.1 Component . . . . . . . 53
6 Relations 55
6.1 Connector (Component Diagram) . . . . 55
6.1.1 Delegation connector . . . . . . . 55
6.1.2 Assembly Connector . . . . . . . 56
7 Diagrammes 57
7.1 Components Diagram . . 57
III Diagramme de structures composites 59
8 Eléments´ 60
8.1 Structured Classifier . . 60
8.2 Port . . 61
8.3 Property (Composite Structures Diagram) . . . . . . . . 62
8.4 Collaboration . . . . . . 64
8.5 Collaboration Occurrence . . . . . . . . 65
8.6 Parameter (Collaboration Diagram) . . . 66
8.7 Invocation Action . . . . 66
9 Relations 68
9.1 Role Binding . . . . . . 68
9.2 Connector (Composite Structures Diagram) . . . . . . . 69
9.2.1 Généralités . . . 69
9.2.2 Connector End . 70
9.3 Keyword « represents » . 71
10 Diagrammes 72
10.1 Composite Structures Diagram . . . . . 72
IV Diagramme de déploiement 73
11 Eléments´ 74
11.1 Artifact 74
11.2 Node . . 74
11.3 Device . 75
11.4 Execution Environment . 75
11.5 Deployment Target . . . 76
11.6 Deployed Artifact . . . . 76
11.7 Deployment Specification 77
12 Relations 78
12.1 Manifestation . . . . . . 78
12.2 Communication Path . . 79
12.3 Deployment . . . . . . . 79
13 Diagrammes 81
13.1 Deployment Diagram . . 81
V Diagramme d’activités 82
14 Eléments´ 83
14.1 Activity 83
14.2 Activity Node . . . . . . 84
14.3 Action . 85
14.4 Object Node . . . . . . . 85
14.5 Pin . . . 87
14.5.1 Règles générales . 87
14.5.2 Input Pin and Output Pin . . . . 88
14.5.3 Value Pin . . . . 88
14.6 Activity Parameter Node 88
14.7 Central Buffer Node . . 89
14.8 Data Store Node . . . . 89
14.9 Control Node . . . . . . 90
14.10Initial Node . . . . . . . 90
14.11Final Node, Activity Final Node and Flow Final Fode . . 91
14.12Merge Node . . . . . . . 91
14.13Decision Node . . . . . . 92
14.14Fork Node . . . . . . . . 93
14.15Join Node . . . . . . . . 94
14.16Activity Group . . . . . 94
14.17Activity Partition . . . . 95
14.18Interruptible Activity Region . . . . . . 96
14.19Executable Node . . . . 97
14.20Parameter (Activities Diagram) . . . . . 97
14.21Parameter Set . . . . . . 97
14.22Structured Activity Node 98
14.23Conditional Node . . . . 98
14.24Clause . 100
14.25Loop Node . . . . . . . . 100
14.26Expansion Region . . . 101
14.27Expansion Node . . . . . 102
14.28Variable (Activities Diagram) . . . . . . 103
15 Relations 104
15.1 ActivityEdge . . . . . . 104
15.2 Control Flow . . . . . . 105
15.3 Object Flow . . . . . . . 106
15.4 Exception Handler . . . 107
16 Diagramme 109
16.1 Activity Diagram . . . . 109
VI Diagramme d’interaction 112
17 Eléments´ 113
17.1 Combined Fragment . . 113
17.1.1 Règles générales . 114
17.1.2 Fragment combiné d’opérateur d’interaction alt . 114
17.1.3 Fragment combiné d’opérateur d’interaction opt . 114
17.1.4 Fragment combiné d’opérateur d’interaction break . . . . . . . . 115
17.1.5 Fragment combiné d’opérateur d’interaction par . 115
17.1.6 Fragment combiné d’opérateur d’interaction seq . 115
17.1.7 Fragment combiné d’opérateur d’interaction strict . . . . . . . . 116
17.1.8 Fragment combiné d’opérateur d’interaction neg . 116
17.1.9 Fragment combiné d’opérateur d’interaction critical . . . . . . 116
17.1.10Fragment combiné d’opérateur d’interaction ignore et consider . 116
17.1.11Fragment combiné d’opérateur d’interaction assert . . . . . . . . 117
17.2 Interaction . . . . . . . . 118
17.3 Interaction Constraint . 118
17.4 Interaction Operand . . 119
17.5 Interaction Occurrence . 119
17.6 Part Decomposition . . . 120
17.7 Continuation . . . . . . 121
17.8 Gate . . 122
17.9 Lifeline . 122
17.10Event Occurrence . . . . 123
17.11Stop . . 124
17.12Execution Occurrence . . 124
17.13State Invariant . . . . . 124
18 Relations 125
18.1 General Ordering . . . . 125
18.2 Messages 125
18.2.1 Eléments connectés´ . . . . . . . . 126
18.2.2 Différentes formes de messages . . 126
18.2.3 Messages et stimuli dans les diagrammes de communication . . . 128
19 Diagrammes 131
19.1 Diagramme de séquence 131
19.1.1 Messages d’appel synchrone d’une opération . . . 131
19.1.2 Messages asynchrones . . . . . . 131
19.1.3 Traces d’une interaction . . . . . 132
19.1.4 Eléments contenus´ . . . . . . . . 132
19.2 Diagramme de communication . . . . . . 133
19.3 Interaction Overview Diagram . . . . . . 134
19.4 Timing Diagram . . . . 134
VII Diagramme de machines à états 135
20 Eléments´ 136
20.1 State . . 136
20.1.1 Règles générales . 137
20.1.2 Activités internes 137
20.1.3 Transitions internes . . . . . . . . 138
20.1.4 Simple State . . . 138
20.1.5 Composite State 138
20.1.6 Etat sous-machine´ . . . . . . . . 139
20.2 Region . 140
20.3 Pseudo-state . . . . . . . 141
20.4 Final State . . . . . . . 143
20.5 Connection Point Reference . . . . . . . 143
21 Relations 145
21.1 Transition . . . . . . . . 145
21.1.1 Eléments connectés´ . . . . . . . . 145
21.1.2 Label des transitions . . . . . . . 146
21.2 Protocol Transition . . . 147
22 Diagrammes 149
22.1 State Machine Diagram . 149
22.1.1 Règles générales . 149
22.1.2 Extension de machines à état . . 150
22.1.3 Envoi de messages entre machines à état . . . . . 151
22.1.4 Utilisation des points d’entrée et de sortie pour un machine à état 151
22.1.5 Deferred events . 152
22.2 Protocol State Machine . 152
VIII Diagramme des cas d’utilisation 154
23 Eléments´ 155
23.1 Actor . . 155
23.2 Extension Point . . . . . 155
23.3 Use Case 156
24 Relations 157
24.1 Extend . 157
24.2 Include . 158
25 Diagrammes 159
25.1 Use Case Diagram . . . 159
IX Cohérence inter-diagrammes 160
26 Cohérence inter-diagrammes 161
26.1 Classes - Objets . . . . . 161
26.2 Classes - Structures composites . . . . . 161
26.3 Classes - Interactions . . 162
26.3.1 Règles générales . 162
26.3.2 Classes - Séquence . . . . . . . . 162
26.4 Classes - Machines à états . . . . . . . . 163
26.5 Classes - Activités . . . 163
26.6 Objets - Interactions . . 163
26.7 Composants - Machines à états . . . . . 164
26.8 Composants - Activités . 164
26.9 Composants - Séquence . 164
X Conclusion et annexes 165
27 Conclusion 166
A Eléments du méta-modèle´ 167
A.1 Classificateur . . . . . . 167
A.2 Dépendances . . . . . . 168
A.3 ConnectableElement . . 168
A.4 Namespace . . . . . . . 169
A.5 RedefinableElement . . . 169
A.6 PackageableElement . . 169
A.7 ParameterableElement . 170
A.8 TemplateableElement . . 171
A.9 EncapsulatedClassifier . 171
A.10 Object Node . . . . . . . 172
A.11 Control Node . . . . . . 172
B Mots prédéfinis du langage UML 174
B.1 Propriétés . . . . . . . . 174
B.2 Mots Clés . . . . . . . . 175
B.3 Contraintes Prédéfinies . 176
Lexique Francais Anglais 178
Bibliographie 181
Chapitre 1 Introduction
1.1 Objectif
Incohérences du langage UML 2.0
Les méthodes graphiques offrent un moyen prometteur pour maîtriser la complexité des logiciels en offrant une description en plusieurs ”vues”. La langage UML permet une telle description et est adopté comme un standard industriel de fait. Cependant, les vues de description d’un logiciel ne sont pas disjointes car elles contiennent des informations redondantes ou complémentaires et il est donc essentiel de s’assurer de leur cohérence. Dans la suite de notre document, une incohérence est définie par :
incohérence Une incohérence est la violation d’une propriété
associée au langage UML qui doit être respectée par tout modèle UML.
Une incohérence est la conséquence de constructions redondantes ou complémentaires incompatibles entre-elles. Les termes de la compatibilité sont exprimés par des « règles de cohérence ».
Le but de ce document est d’énumérer l’ensemble des règles de cohérence associées au langage UML et que doivent respecter tout modèle UML d’un système quelconque. Il se base sur la spécification d’UML 2.0 du 02/08/2003 (adopted specification) [7].
Remarquons que l’absence d’incohérence ne prouve pas le bon fonctionnement d’un système mais que la présence d’une incohérence a de grandes chances de déboucher sur un système défectueux. De plus, l’expérience montre que de très nombreuses fautes de modélisation sont perceptibles à travers la détection d’incohérences.
Les incohérences reposent sur la sémantique de vérification des constructions du langage UML, c’est-à-dire sur la bonne façon de constituer un modèle UML, et non sur leur sémantique opérationnelle, c’est-à-dire sur leurs apports descriptifs dans un modèle. Nous nous intéressons donc aux règles de cohérence de l’emploi d’une construction et non à la fonction qu’elle remplit.
Voici un exemple qui illustre la différence de ces sémantiques dans le cas d’une affectation écrite en langage ADA. La sémantique opérationnelle associée à l’instruction «A := B;» pourrait être « on copie la valeur de l’expression B dans la variable A » alors que la sémantique de vérification serait « le type de la variable A et le type de l’expression B doivent être identiques ». Cette propriété formule un usage cohérent de l’affectation vis-à-vis de la variable affectée et de l’expression dont la valeur sera affectée.
Ce document est une étude de la sémantique de vérification de chaque élément de base du langage UML, de chaque relation entre ces éléments, de chaque diagramme décrit par le langage UML et enfin d’un modèle dans son ensemble en tenant compte de la cohérence inter-diagramme.
Type des incohérences considérées
Nous nous plaçons dans le cadre de l’expression des modèles complets, par opposition aux vues incomplètes qui peuvent être utiles lors d’une itération du processus de développement.
La figure 1.1 tirée de [2] présente une classification des types d’incohérences. Dans cette classification, nos travaux se situent dans les couches 2 et 3, c’est-à-dire que nous ne traitons que des incohérences sur les éléments et les relations entre ces éléments (niveau 3) et sur les diagrammes et les relations entre diagrammes (niveau 2).
Fig. 1.1 – Type d’incohérences
Remarquons cependant que certaines des règles énoncées pourraient aussi être classées dans des relations entre modèles. C’est le cas de règles qui mettent en jeu des constructions décrivant le même système avec des niveaux de raffinement différents (cf. la règle 251 par exemple).
1.2 Structure du document
Structuration en diagramme
INSA - Toulouse 2
Les règles de cohérence que doivent respecter les modèles UML ont été structurées afin de faciliter leur utilisation lors d’analyse de modèles particuliers (par exemple par des revues). Les différentes parties abordent successivement les diagrammes suivants :
Une dernière partie aborde les aspects inter-diagrammes.
Structuration intra-diagramme
Chaque partie est composée de 3 chapitres qui traitent respectivement d’un point de vue sur les constituants du diagramme étudié :
Canevas pour chaque construction considérée
Chacun de ces chapitres est ensuite découpé en sections qui correspondent à un
élément, une relation ou un diagramme. Dans chacune de ces sections, nous adopterons le même canevas d’étude :
– en premier lieu, nous présenterons le « contexte », c’est-à-dire les circonstances dans lesquelles une erreur peut être commise lors de la modélisation UML;
– ensuite, nous définirons les «règles de cohérence» (consistency rules en anglais) qui expriment par intention la sémantique de vérification que l’élément doit respecter; il peut exister une ou plusieurs règles qui seront numérotées;
– lorsque cela sera possible, nous donnerons des « guides » de style pour faciliter la détection des erreurs;
– la rubrique « justification » apporte une justification pour chaque guide, les guides et les justifications sont numérotés ce qui permet de faire le lien entre un guide et sa justification.
Typologie des règles
Enfin, deux types d’informations sont associés aux règles :
– l’origine de la règle qui peut être :
p.XXX] suit la règle;
– le niveau de d’écriture et d’application de la règle :
utilisateur].
Un exemple avec le langage ada
Considérant que les langages de programmation sont mieux connus que ceux de mod-
élisation et afin de bien faire comprendre le contenu de chaque section de ce document, nous illustrons ici le canevas présenté précédemment pour une affectation d’une variable par une expression en langage ADA (A := B;).
Contexte Le langage ADA permet d’affecter la valeur d’une expression à une variable.
Règle de cohérence
Guide
Justification
Remarques finales
Certaines règles peuvent être difficiles à comprendre. Afin d’éviter au maximum toute mauvaise interprétation de ces règles, un travail d’illustration est en cours. Ce travail consiste pour chacune des règles à donner un modèle qui respecte et un modèle qui enfreint la règle considérée.
Un lexique Anglais/Français regroupe en fin de document l’ensemble des termes employés.
Des notes de bas de page présentes dans le texte ne doivent pas être considérées par le lecteur, mais sont des notes qui servent de base de réflexion aux auteurs.
Première partie Diagramme de classes
6
Chapitre 2
Eléments´
2.1 Element
Contexte Element est une méta-classe abstraite qui représente un constituant du modèle. En tant que tel, un élément a la capacité de contenir d’autres éléments.
Règles de cohérence
Remarque Tous les éléments d’UML doivent obligatoirement être contenus dans un autre élément sauf les paquetages.
2.2 Namespace
Contexte Un espace de nommage (namespace en anglais) est un élément qui peut contenir en ensemble d’éléments nommés pouvant être identifiés par leurs noms.
Un espace de nommage a la capacité d’importer des éléments individuels afin que ceux-ci puissent être référencés sans utilisation du nom qualifié à l’intérieur de l’espace de nommage importateur. Dans le cas de conflits de noms, il faut avoir recours aux alias.
L’annexe A.4 montre la hiérarchie d’héritage de la méta-classe Namespace et donc l’ensemble des éléments qui sont considérés comme étant des espaces de nommage.
Règles de cohérence
Remarque Par défaut, un élément A se distingue d’un élément B si A n’est pas du même type que B, un sous-type de B, ou, si A et B n’ont pas le même nom. Cette définition du qualificatif « distingué » peut être redéfinie, c’est notamment le cas pour les opérations qui sont distinguables en fonction de leur signature.
Remarque Dans la méta-modèle la relation de composition entre un élément nommé et un espace de nommage est spécifiée par le rôle ownedMember.
2.3 Named Element
Contexte1 Un élément nommé (named element en anglais) est un élément qui peut avoir un nom. Le nom est utilisé pour identifier l’élément. Un élément nommé peut avoir un nom qualifié (qualified name en anglais) qui lui permet d’être identifié de façon non ambigu¨e dans une hiérarchie d’espaces de nommage imbriqués.
Les éléments nommés peuvent être contenus dans un espace de nommage (cf. section
2.2).
Règles de cohérence
pas de visibilité. [[7] p.34] [Règle sur le méta-modèle]
Remarque Le nom qualifié est construit de la façon suivante : namespace1 :: ... :: namespaceN :: element-name
Remarque Les règles 9 à 11 s’appliquent lors de l’utilisation des noms qualifiés dans les modèles.
2
même temps.[Règle dérivée du méta-modèle]
Remarque La figure 2.1 montre un exemple de non respect de la règle 12. En effet, cette règle implique que tout paquetage ne peut être contenu que par un autre paquetage.
1faire une section namedElement dans la section template pour mettre les règles de la page 560 de la spec
2Guide de prévention : Le nom d’un élément ne doit pas correspondre à un mot prédéfini du langage UML. Remarque Les mots prédéfinis du langage sont les stéréotypes, les contraintes prédéfinies, les propriétés et les mots clés. Se référer à l’annexe B.2 pour avoir la liste de ces mots et l’élément du langage sur lequel ils peuvent s’appliquer.
Fig. 2.1 – Paquetage appartenant à plusieurs paquetages
2.4 Comment
Contexte Un commentaire (comment en anglais) est une annotation textuelle qui peut être attachée à un ensemble d’éléments.
Un commentaire n’ajoute pas forcément de sémantique aux éléments annotés. Dans ce cas, il représente des informations utiles aux lecteurs du modèle.
Règles de cohérence
Pas de règles supplémentaires.
2.5 Multiplicity
Contexte La multiplicité (multiplicity en anglais) spécifie les valeurs de cardinalité possibles pour un ensemble d’éléments. La cardinalité d’un ensemble est le nombre d’éléments contenus dans cet ensemble.
Règles de cohérence
multiplicity ::= [’{’’}’]
[’{’’}’]
multiplicity_range ::= [ lower .. ] upper lower ::= integer | value_specification
upper ::= unlimited_natural | * | value_specification
::= ordered | unordered
::= unique | nonunique
3REGLE 4 du doc commun : guide prévention? il est conseillé d’utiliser des caractères imprimables` pour nommer les éléments
ou` unlimited_natural doit être un entier naturel.
Remarque La syntaxe interdit d’associer à la même multiplicité les propriétés {ordered} et {unordered} et les propriétés {unique} et {nonunique}.
Remarque Le terme optionnel ’{’’}’ n’est pas présent dans la norme et a été rajouté.
spécification de valeur (cf. section 2.6) de type entier. [Nouvelle règle]
p.41] [Règle sur le méta-modèle]
p.41] [Règle sur le méta-modèle]
2.6 Value Specification and Expression
Contexte En UML, une spécification de valeur (value specification en anglais) peut
être évaluable ou non, dans ce dernier cas, on parle d’expression opaque (opaque expression en anglais).
Une expression est évaluée selon un structure arborescente ou` les nœuds sont des opérateurs et les branches des opérandes. L’évaluation d’une expression contenant une expression opaque (comme opérande) est laissée à la responsabilité de l’outil. Le langage dans lequel est écrit une expression opaque peut être spécifié. Les expressions OCL sont considérées comme des expressions opaques.
Règles de cohérence
Guide
Justification
2.7 Constraint
Contexte Une contrainte est une condition ou une restriction exprimée en langage naturel ou en langage compréhensible par l’AGL (Atelier de Génie Logciel) qui ajoute des informations sémantiques à l’élément.
Règles de cohérence
[Nouvelle règle]
Remarque Une liste des contraintes prédéfinies est disponible en annexe B.3.
2.8 Keyword
Contexte La notation UML fait usage de mots clefs (keywords en anglais) pour faire la distinction entre des variations d’un même motif graphique. Ceci permet de décrire différentes classes du méta-modèle avec le même motif graphique. En règle générale, la méta-classe d’un élément représentée avec un motif et un mot clé est une spécialisation de la méta-classe représentée avec uniquement le motif graphique.
Remarque « Keyword » ne fait pas partie des méta-classes du méta-modèle.
Règles de cohérence
[Nouvelle règle][Règle utilisateur]
Remarque La liste des mots clés prédéfinis ainsi que les éléments sur lesquels ils peuvent être utilisés se situe en annexe B.2.
Remarque Cette règle est valide seulement si l’élément ne dispose pas d’un motif graphique spécial. Dans ce cas et si la représentation graphique spéciale est utilisée le mot clé n’apparaît pas nécessairement.
2.9 Element Properties
Contexte Dans UML, chaque élément possède un ensemble de propriétés qui peut s’appliquer sur l’élément. Les propriétés servent à ajouter des informations supplémentaires aux éléments du modèle. Dans de nombreux cas, une propriété sert à exprimer la valeur d’un attribut du méta-modèle pour l’élément concerné.
Remarque « Element Properties » ne fait pas partie des méta-classes du métamodèle.
Règles de cohérence
property ::= {name [’=’ value]}
ou` :
– name est le nom de la propriété (le marqueur de la propriété);
– le symbole ’=’ est un séparateur;
– value est la valeur (celle du marqueur) à laquelle doit se trouver la propriété; ce champ est optionnel.
Remarque La liste des propriétés et des éléments sur lesquels elles peuvent s’appliquer est présentée en annexe B.1.
Remarque Par exemple pour une propriété booléenne la valeur doit être vrai ou faux.
Remarque Voici la liste des propriétés qui sont incompatibles lorsqu’elles s’appliquent sur le même élément :
– {subsets prop-name1} et {redefines prop-name2} si prop-name1=propname2;
– {unrestricted} et {readOnly};
– {ordered} et {bag};
– {sequence} (ou {seq}) et {bag};
– {property-name=value1} et {property-name=value2} si value16=value2. 4
