Rubriques
Cette page porte sur quelques différences entre UML 1.x et UML 2.0 qui sont pertinentes dans le contexte du RUP. Elle
ne décrit pas la globalité des spécificités de l'infrastructure et de la superstructure UML([UML04]), mais seulement les fonctionnalités UML les plus importantes. Voir également
[RUM05] et [ERI04] pour
plus d'informations.
Il convient de remarquer que UML 1.x fait référence aux versions UML 1.0 à UML 1.5.
Les changements les plus significatifs en matière de diagrammes dans UML 2.0 au niveau des paramétrages se situent dans
les diagrammes comportementaux, surtout pour le diagramme d'activité et pour l'ensemble des diagrammes d'interaction
(voir Diagramme d'activité , Diagramme de séquence et Diagramme de communication ci-dessous).
Les diagrammes de structure composite et les classes structurées sont des nouvelles fonctionnalités d'UML 2.0 (voir Diagramme de structure composite ci-dessous).
Introduction
La modélisation d'activités a été révisée complètement pour UML 2.0. A vrai dire, pour une utilisation courante, les
effets et l'apparence sont très similaires, même si en fonction de la formalité de modélisation en UML 1.5 (et versions
précédentes), il est possible qu'une interprétation stricte et le résultat d'exécution d'un modèle construit suivant
les règles d'UML 1.x ne soient pas identiques dans UML 2.0. Par conséquent, on avertit le modélisateur que même si un
modèle d'activité UML 1.x semble être acceptable dans UML 2.0 sans aucun changement, il se peut qu'il ne s'exécute pas
de la même façon - surtout dans le cas de modèles plus complexes qui concernent la simultanéité. Voir [UML04] pour plus d'informations.
Tel que défini par [UML04], une
activité (qui s'affiche dans un diagramme d'activité) est une spécification de comportement en tant
que séquencement coordonné des unités subordonnées dont les éléments individuels sont les actions. Auparavant,
on a pu faire référence à des étapes exécutables individuellement dans un diagramme d'activité UML 1.x en tant
qu'activités ou états d'activité ou, pour être plus exact, comme des états d'actions : ces étapes seront appelées
désormais dans une activité UML 2.0 des actions - et ces actions ne seront pas décomposées davantage pendant
l'activité. La notion d'état disparaît dans le langage UML 2.0 car une activité n'est plus une machine d'état comme
pour UML 1.x. Dans UML 2.0, les activités sont composées de trois sortes de noeuds et les actions en sont une
sorte ; les deux autres, décrites ci-dessous, sont les noeuds de contrôle et les noeuds d'objet.
Sémantique de flot
Les activités ont désormais une sémantique identique à celle du réseau Pétri, basée sur le flot de jetons, où
l'exécution d'un noeud affecte l'exécution d'un autre par le biais de connexions directes appelées des flux. Les
jetons, qui contiennent des objets ou un locus de contrôle, circulent parmi les noeuds via ces connexions. Un noeud
peut commencer l'exécution quand les conditions spécifiées au niveau de ses jetons d'entrée sont réunies. Quand il
finit l'exécution, il propose des jetons dans ses flux de sortie, de telle sorte que les noeuds en aval puissent
commencer l'exécution. Les flux qui mettent les noeuds en connexion sont affinés davantage en flux de contrôle, d'objet
ou de données, et en toute logique, les jetons de contrôle circulent dans des flux de contrôle et les jetons d'objet et
de données circulent dans des flux d'objets.
Ceci est différent de UML 1.x, où les noeuds étaient des états (ou des pseudo-états) avec des transitions entre eux, ce
qui limitait la modélisation des flux.
Modélisation de simultanéité
La fonctionnalité de modélisation de UML 2.0 permet le parallélisme sans restrictions : tandis qu'en UML 1.x,
l'automate à états (activité) réalisait une étape jusqu'à la finalisation, la fonctionnalité en UML 2.0, dans sa forme
complète, permet qu'une simple exécution gère de nombreux appels d'une activité avec de multiples flux de jetons
circulant entre les noeuds et les connecteurs de flux de l'activité. Ce qui veut dire que le modélisateur doit être
vigilant quant à la concurrence critique et aux interactions. Voir aussi la section sur les Différences
sémantiques ci-dessous pour avoir un autre exemple de l'effet du flux de jeton sur la modélisation de la
simultanéité.
Notation
Noeuds d'action et de contrôle
Le diagramme ci-dessous montre de nombreux éléments d'UML 2.0. Il est représenté dans son format courant pour UML 2.0,
avec un cadre rectangulaire et un nom dans une case en haut à gauche. Comparez ce diagramme avec celui de la version
UML 1.x qui est juste en dessous. Vous constaterez qu'ils sont similaires en apparence (si ce n'est la différence
d'orientation et les conventions de couleurs qui d'ailleurs n'ont aucune signification sémantique), et que ce modèle a
le même résultat d'exécution en UML 1.x qu'en UML 2.0. Vous remarquerez aussi que les noeuds de contrôle - décision,
fusion, embranchement, jonction, initial et final - ressemblent à leurs équivalents en UML 1.x, et que les flux de
contrôle apparaissent représentés par une ligne fléchée, qui est visuellement analogue à la flèche de transition de UML
1.x.
Exemple d'un diagramme d'activité en UML 2.0
Exemple de diagramme d'activité dans UML 1.x.
UML 2.0 a un noeud de contrôle supplémentaire appelé flot de fin (montré ci-dessous dans un diagramme tiré de
[UML04]) qui peut être utilisé comme une alternative au noeud de fin d'activité afin
de terminer un flux. Il est nécessaire car dans UML 2.0., quand le contrôle atteint n'importe quelle instance du noeud
de fin d'activité, l'activité entière (tous les flux compris) est terminée. Le noeud de fin de flux termine uniquement
le flux auquel il est attaché. Ce n'était pas le cas en UML 1.5 à cause de la sémantique de fonctionnement jusqu'à
l'achèvement, mais avec le parallélisme sans restrictions d'UML 2.0., le modélisateur peut ne pas vouloir arrêter tous
les flux ni détruire tous les jetons.
Noeud de contrôle flux de fin
Noeuds d'objet
L'activité de modélisation en UML 2.0 peut aussi prendre en charge des noeuds d'objet. Un noeud d'objet est un noeud
d'activité qui indique qu'une instance d'un discriminant donné, vraisemblablement à une étape particulière, pourrait
être disponible à un point donné de l'activité (par exemple, en tant que donnée de sortie à partir d'une action, ou en
tant que donnée d'entrée pour une action). Les noeuds d'objet se comportent comme des conteneurs à partir et vers
lesquels les objets d'un type donné (et potentiellement à un état donné) peuvent circuler. Une nouvelle notation,
appelée point, a été introduite pour les noeuds d'objets dans UML 2.0. Les points sont des données d'entrée
vers une action ou bien des données de sortie d'une action et ils sont représentés par des rectangles qui sont attachés
aux rectangles de l'action, comme montré ci-dessous.
Point de notation
Les flèches représentent des flux d'objets. Ce sont des traits pleins, contrairement aux traits tiretés utilisés pour
les transitions au départ et à l'arrivée des états des flux d'objets qui apparaissaient en UML 1.x. Si le point de
sortie d'une action a le même nom que celui du point d'entrée sur l'action connectée, les points d'entrée et de sortie
peuvent fusionner et former un seul point autonome. Ceci est aussi semblable visuellement aux flux d'objets de la
version UML 1.x.
Notation de points autonome
Noeuds d'activité structurée
Un noeud d'activité structuré est un noeud d'activité exécutable qui peut avoir une extension dans des noeuds
d'activité subordonnés. Les noeuds d'activité subordonnés appartiennent à un seul noeud d'activité structuré, mais ils
peuvent être imbriqués. Des flux de contrôle peuvent y être connectés et des points y être attachés. Un noeud
d'activité structuré est représenté par un rectangle tireté avec des coins arrondis renfermant ses noeuds et ses flux,
et par le mot-clé <<structuré>> au-dessus.
Partitions d'activité
Une partition d'activité est une façon de regrouper les noeuds et les flux d'une activités selon une
caractéristique commune. En UML 1.x, la notion de couloirs (qui étaient considérés comme des partitions) était utilisée
dans les diagrammes d'activité afin de regrouper des actions en fonction d'un critère - par exemple, en matière de
modélisation métier, par organisation. La version UML 2.0 étend cette fonctionnalité de partitionnement à des
dimensions multiples pour les diagrammes d'activité et fournit des notations supplémentaires de telle sorte que, par
exemple les actions individuelles peuvent être étiquetées avec le même nom que la partition à laquelle elles
appartiennent. Le diagramme ci-dessous propose un exemple de couloirs multidimensionnels tels qu'ils apparaîtraient en
UML 2.0, où les actions sont regroupées en fonction de la situation et de la responsabilité.
Exemple de partitions d'activité utilisant des couloirs bidimensionnels
Différences sémantiques
La sémantique autour des flux de jetons et le parallélisme sans restrictions des modèles d'activité de UML 2.0
nécessitent une attention particulière de la part du modélisateur habitué à la version UML 1.x. Par exemple, en matière
de construction de nouveaux modèles ou de conversion de modèles existants, il faudrait qu'il s'assure que les résultats
seront ceux qui sont attendus. Dans l'exemple du processPassenger ci-dessus, il se peut que le passager qui enregistre
ses bagages fasse partie des voyageurs fréquents et, dans ce cas-là, l'agent devra lui accorder ses miles de frequent
flyer, comme on peut le voir dans l'extrait du modèle UML 1.x ci-dessous.
Utiliser une transition concurrente protégée
En UML 1.x, si l'on place une protection au niveau de la transition concurrente en option, la transition ne commencera
pas, et cela aura pour effet que la transition se comporte comme si elle n'apparaissait pas sur le modèle ; et donc,
quand les deux autres transitions se terminent, l'exécution continue après leur jonction. En revanche, en UML 2.0, si
le passager n'est pas un voyageur fréquent, aucun jeton n'atteindra jamais l'union dans ce flux et le modèle s'arrêtera
car la jonction attend tous ses jetons sur tous ses flux avant de continuer. La construction du modèle doit être comme
indiquée ci-dessous, la condition étant traitée de la même manière que le flux de traitement des bagages. On peut aussi
placer des protections directement sur les flux simultanés, tant que l'on est sûr qu'il n'y a pas de jonctions en aval
qui en dépendent.
Utilisation de noeuds de décision et de fusion à la place d'un flux simultané protégé
Ce que l'on appelle en UML 1.x diagramme de collaboration s'appelle en ULM 2.0 diagrammes de communication. Il
n'y a pas de différences sémantiques par rapport aux versions précédentes. Le diagramme de communication est basé sur
l'ancien diagramme de collaboration et il constitue toujours une sorte de diagramme d'interaction.
Notation
Un diagramme de communication se base sur l'interaction entre les lignes de vie. Il est affiché comme un graphique dont
les noeuds sont des rectangles qui représentent des parties d'une classe structurée ou des rôles d'une collaboration.
Il y a aussi un cadre rectangulaire autour du diagramme avec le nom dans une case en haut à gauche, ce qui constitue un
changement de notation par rapport aux autres versions UML.
-
Les noeuds correspondent à des lignes de vie d'une interaction
-
Les lignes entre les parties sont des connecteurs qui constituent des chemins de communication.
-
Les multiplicités sont affichées dans ces connecteurs.
-
Les messages entre les parties sont affichés par des flèches étiquetées à proximité des lignes de connecteur.
Un diagramme de communication est utilisé pour modéliser les interactions qui représentent l'implémentation d'une
opération ou d'un cas d'utilisation.
Exemple de diagramme de communication :
Exemple de diagramme de communication pour un système d'achat
En UML 2.0, un composant est noté par un symbole de classe sans les deux rectangles saillants, comme défini en UML 1.4.
Un <<composant>> stéréotypé est utilisé à la place. Une icône de composant placée en haut à droite du
symbole du composant et qui est identique à l'icône de la version UML 1.4 peut toujours être utilisée (facultatif).
UML 2.0 définit un composant comme étant une classe structurée, ce qui fait que la collaboration entre les éléments au
niveau de leur structure interne (les parties) peut être modélisée afin de mieux décrire leur comportement. Les parties
sont connectées par des connecteurs. On peut utiliser des ports afin d'accroître le niveau d'encapsulation d'un
composant via les interfaces fournies et requises. Pour plus d'informations, consultez Concept : Composant et Concept : classe
structurée.
Les versions précédentes d'UML définissaient un élément de modélisation spécial appelé sous-système, qui était
modélisé en tant que package avec une interface. De même, les composants étaient utilisés afin de structurer le modèle
au niveau de l'architecture physique. En UML 2.0, les composants sont utilisés dans un sens plus large et pour toutes
les parties du modèle. De cette façon, un élément donné n'a plus besoin de modéliser des sous-systèmes. Les
compartiments séparés pour la réalisation de sous-systèmes et la spécification de sous-systèmes en UML 1.x sont devenus
deux stéréotypes séparés en UML 2.0(<<réalisation>> et <<spécification>>, respectivement)
appliqués à des composants. Il existe un autre composant stéréotypé nouveau, le <<sous-système>>, approprié
pour modéliser des composants volumineux.
Le processus RUP suggère l'utilisation des composants pour modéliser des sous-systèmes (voir aussi Instructions : sous-système de conception pour plus d'informations).
Les architectures peuvent avoir une collaboration spécifique entre leurs éléments, avec des parties et des connecteurs
qui n'étaient pas connus nécessairement au moment de leur conception. Un exemple de diagramme de classe classique
(ainsi que d'autres diagrammes statiques) ne suffirait pas à représenter clairement les rôles, les responsabilités et
les règles qui concernent ces éléments.
Pour traiter ces sujets, UML 2.0 a ajouté le diagramme de structure composite. Il peut décrire la structure interne
d'une classe structurée (ex : des composants ou des classes), y compris les points d'interaction de la classe
structurée à d'autres parties du système. Il montre la configuration des parties qui composent ensemble le comportement
de la globalité de la classe structurée.
Les diagrammes de structure composite sont utilisés pour dessiner le contenu interne des classes structurées (consultez
Concept : classe structurée pour obtenir plus de détails et des exemples de
diagramme de structure composite.
UML 2.0 possède plusieurs nouvelles fonctionnalités en matière de diagramme de séquence :
-
Les fragments fournissent une sémantique plus claire par rapport à la façon dont le comportement intervient dans un
diagramme de séquence. Un fragment combiné encapsule des portions de diagramme de séquence, où des flux séparés
peuvent être modélisés, tout en montrant comment les conditions conduisent à d'autres chemins d'exécution.
-
Les occurrences d'interaction permettent la décomposition des interactions en blocs réutilisables. C'est une façon
efficace de partager des portions d'une interaction donnée entre d'autres interactions différentes.
-
En UML 1.x, une représentation possible des boucles était l'utilisation d'une condition de boucle écrite dans une
note. La note était attachée au message ou à l'ensemble de messages à exécuter si la condition de boucle était
vraie. En UML 2.0, il existe une représentation spécifique pour les boucles.
-
En UML 2.0, les diagrammes de séquence peuvent montrer comment les objets sont créés et détruits.
-
L'exécution de l'occurrence montre la cible de contrôle qu'un objet exécute à un moment donné, lors de la réception
du message.
Avec les nouvelles fonctionnalités pour la représentation des fragments, des occurrences d'interaction et des boucles,
les diagrammes de séquence peuvent être utilisés sous deux formes :
-
Forme d'instance : décrit un scénario spécifique en détail, et documente une interaction possible, sans conditions,
branches, ou boucles. Cette forme est utilisée pour représenter un scénario de cas d'utilisation. Les scénarios
différents d'un même cas d'utilisation seront représentés par des diagrammes de séquence différents. Les outils de
modélisation qui prennent en charge la sémantique d'UML 1.x permettent seulement cette forme de
représentation.
-
Forme générique : décrit toutes les alternatives possibles dans un scénario, en utilisant les fonctionnalités
nouvelles d'UML 2.0 comme les conditions, les branches et les boucles. Cette forme peut être utilisée afin de
représenter plusieurs scénarios du même cas d'utilisation dans un seul diagramme de séquence, lorsque cela a un
sens.
L'illustration ci-dessous constitue un exemple de diagramme de séquence modélisant différents scénarios. Le fragment
alt montre deux alternatives possibles de séquencement de message selon si une condition est
satisfaite ou non :
Exemple : Diagramme de fonctionnement avec des branches, des boucles et des conditions
|