Cours avancé sur les règles de cohérence UML
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
- 1.12Fragment combiné d’opérateur d’interaction loop 118
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 :
- diagramme de classes,
- diagramme de structures composites,
- diagramme de déploiements,
- diagramme d’activités,
- diagramme d’interactions,
- diagramme de machines à états, 8. diagramme des cas d’utilisation.
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é :
- Les éléments de base exprimés dans le diagramme et donc les règles qu’ils doivent respecter en les considérant séparément les uns des autres.
- Les relations couplant ces éléments de base exprimées dans le diagramme et donc les règles que ces relations doivent respecter.
- Les règles concernant globalement le diagramme étudié qui expriment des contraintes sur les usages conjoints de plusieurs éléments et de plusieurs relations dans ce diagramme.
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 :
- une contrainte directement tirée de la norme auquel cas le marqueur [[7]
p.XXX] suit la règle;
- directement déduite du méta-modèle auquel cas le marqueur [Re`gle dérivée du me´ta-modèle] suit la règle;
- une nouvelle règle, auquel cas le marqueur [Nouvelle règle] suit la règle;
- une règle tirée de la littérature auquel cas la référence du document et une page éventuelle suit la règle (marqueur de type [tireé de [7] p.XXX]), ce marqueur est également utilisé pour les règles provenant de la spécification d’UML 2.0 mais qui n’y apparaissent pas en tant que contrainte.
– le niveau de d’écriture et d’application de la règle :
- le premier niveau correspond aux règles pouvant être écrites au niveau langage (ou méta-modèle) et s’appliquant sur le méta-modèle uniquement, ces règles sont marquées par [Règle sur le méta-modèle];
- le deuxième niveau correspond aux règles pouvant être écrites au niveau langage et qui contraignent les modèles, ces règles sont les plus intéressantes et les plus nombreuses c’est pourquoi aucun marqueur ne leur est associé;
- le dernier niveau correspond aux règles ne pouvant pas être écrites au niveau méta, ceci est duˆ au fait qu’aucune méta-classe ne correspond à l’élément graphique sur lequel s’applique la règle, ces règles sont identifiées par [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
- Regle 1 :` Le type de la variable A et le type de l’expression B doivent être identiques.
Guide
- Guide 1 : Nous conseillons de créer des types différents pour chaque concept et en particulier de ne pas utiliser les types prédéfinis mais de les redéfinir (opérateur new).
Justification
- Justification 1 : Ceci permet de détecter toute affectation involontaire entre éléments qui expriment des notions différentes. Par exemple, ceci permettrait de détecter une affectation entre une expression qui exprime une température et une variable qui représente une vitesse même si ces deux éléments sont codés par des flottants.
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
- Regle 2 :` Un élément ne peut pas directement ou indirectement se contenir luimême. [[7] p.30]
- Regle 3 :` Tous les éléments excepté les paquetages doivent avoir un possesseur. [[7] p.30]
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
- Regle 4 :` Tous les membres d’un espace de nommage doivent pouvoir être distingués. [[7] p.36]
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.
- Regle 5 :` Les membres importés d’un espace de nommage dérivent des relations d’importation d’éléments (cf. section 3.1) et d’importation de paquetage (cf. section 3.2). [[7] p.36] [Règle sur le méta-modèle]
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
- Regle 6 :` Si un élément nommé n’est pas inclus dans un espace de nommage il n’a
pas de visibilité. [[7] p.34] [Règle sur le méta-modèle]
- Regle 7 :` Si un élément nommé n’a pas de nom ou qu’au moins un de ses espaces de nommage qui le contient n’a pas de nom, alors l’élément n’a pas de nom qualifié. [[7] p.34] [Règle sur le méta-modèle]
- Regle 8 :` Quand l’élément et tous les espaces de nommage qui le contiennent sont nommés, le nom qualifié est construit à partir des noms des espaces de nommage successifs. [[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.
- Regle 9 :` Soit namespace1 : : ... : : namespaceN : : element-name un nom qualifié, l’espace de nommage namespace1 doit être l’espace de nommage le plus général contenant indirectement (ou non) element-name.[Règle dérivée du méta-modèle]
- Regle 10 :` Soit namespace1 : : ... : : namespaceN : : element-name un nom qualifié, pour tout P appartenant à 2..N, namespaceP doit être inclus dans namespaceP-1. [Règle dérivée du méta-modèle]
- Regle 11 :` Soit namespace1 : : ... : : namespaceN : : element-name un nom qualifié, l’élément element-name doit appartenir à l’espace de nommage namespaceN. [Règle dérivée du méta-modèle]
2
- Regle 12 :` Un élément ne peut appartenir qu’à un seul espace de nommage en
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
- Regle 13 :` L’expression d’une multiplicité doit suivre la syntaxe :[[7] p.43]
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é.
- Regle 14 :` Le champ value_specification doit être évaluable et être un
spécification de valeur (cf. section 2.6) de type entier. [Nouvelle règle]
- Regle 15 :` Une multiplicité doit définir au moins une cardinalité valide (c’est-à-dire que upper>0). [[7] p.41]
- Regle 16 :` La borne inférieure doit être un entier non négatif. [[7] p.41]
- Regle 17 :` La borne supérieure doit être supérieure ou égale à la borne inférieure. [[7] p.41]
- Regle 18 :` Si des valeurs non littérales sont utilisées pour décrire les bornes des multiplicités, leur évaluation ne doit pas avoir d’effet de bord. [[7] p.41]
- Regle 19 :` Si des valeurs non littérales sont utilisées pour décrire les bornes des multiplicités, alors leurs spécifications doivent être des constantes. [[7] p.41]
- Regle 20 :` Le méta-attribut dérivé lower doit être égal à la borne inférieure. [[7]
p.41] [Règle sur le méta-modèle]
- Regle 21 :` Le méta-attribut dérivé upper doit être égal à la borne supérieure. [[7]
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
- Regle 22 :` Dans le cas ou` aucune expression opaque n’apparaît dans la formulation de l’expression, l’expression doit être syntaxiquement correcte. [Nouvelle règle]
Guide
- Guide 2 : Nous conseillons de ne pas utiliser d’expression opaque quand cela est possible.
Justification
- Justification 2 : Lorsque le guide 2 est suivi, la règle 22 peut être totalement vérifiée.
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
- • Regle 23 :` L’expression d’une contrainte doit suivre la syntaxe suivante :[[7] p.55] constraint ::= ’{’[’:’] ’}’
- • Regle 24 :` Les valeurs spécifiées par une contrainte doivent être évaluées à vrai. [[7] p.54]
- • Regle 25 :` L’évaluation d’une contrainte ne doit pas avoir d’effets de bord. [[7] p.54]
- • Regle 26 :` Une contrainte ne peut pas s’appliquer à elle-même. [[7] p.54]
- • Regle 27 :` Une contrainte doit s’appliquer à l’élément pour lequel elle a été définie.
[Nouvelle règle]
Remarque Une liste des contraintes prédéfinies est disponible en annexe B.3.
- • Regle 28 :` L’élément qui contient la contrainte doit avoir accès aux éléments mis en jeu par la contrainte. [tirée de [7] p.54]
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
- Regle 29 :` Toute utilisation de mot clé suppose que le mot clé soit prédéfini.
[Nouvelle règle][Règle utilisateur]
- Regle 30 :` Toute utilisation d’un mot clé prédéfini doit être réalisée sur l’élément adéquat. [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.
- Regle 31 :` Lorsqu’un mot clé est associé à un élément n’ayant pas de motif graphique spécial, le mot clé doit figurer à toutes les apparitions de l’élément dans le modèle. [Nouvelle règle][Règle utilisateur]
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
- Regle 32 :` Excepté les propriétés subsets et redefines, les propriétés doivent respecter la syntaxe : [Nouvelle règle]
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.
- Regle 33 :` Le champ name doit correspondre à une propriété prédéfinie du langage UML. [Nouvelle règle][Règle utilisateur]
- Regle 34 :` Toute propriété doit s’appliquer sur un élément pour lequel elle a été définie. [Nouvelle règle][Règle utilisateur]
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.
- Regle 35 :` Si le champ value est présent, celui-ci doit exprimer une valeur qui est compatible avec les valeurs que peut prendre la propriété. [Nouvelle règle][Règle utilisateur]
Remarque Par exemple pour une propriété booléenne la valeur doit être vrai ou faux.
- Regle 36 :` Lorsque le champ value n’est pas présent celui-ci est pris par défaut à vrai. Il faut donc que la propriété soit de type booléen. [Nouvelle règle][Règle utilisateur]
- Regle 37 :` Chaque propriété associée à un élément du modèle doit être compatible avec les autres propriétés associées à cet élément. [Nouvelle règle][Règle utilisateur]
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