Différences
entre UML 1.x et UML 2.0
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 en UML 2.0 car une activité n'est plus une espèce d'automate à états, comme c'était le cas pour UML 1.x. Dans UML 2.0, les activités se divisent en 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 maintenant une sémantique semblable au réseau de Pétri, basée sur le flot de jetons, où l'exécution d'un noeud a une incidence sur l'exécution d'un autre par des connexions directes appelées des flots. 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 flots de sortie, de telle sorte que les noeuds en aval puissent commencer l'exécution. Les flots qui mettent les noeuds en connexion sont affinés davantage en flots de contrôle, d'objet ou de données, et en toute logique, les jetons de contrôle circulent dans des flots de contrôle et les jetons d'objet et de données circulent dans des flots 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 flots.
Modélisation de la 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 flots de jetons circulant entre les noeuds et les connecteurs de flot de l'activité. Ce qui veut dire que le modélisateur doit être vigilant quant à la concurrence critique et aux interactions. Voir aussi la rubrique Différences sémantiques ci-dessous pour avoir un autre exemple de l'effet de la sémantique du flot de jetons 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 flots 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 flot.
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 flots compris) est terminée. Le noeud de fin de flot termine uniquement le flot 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 flots ni détruire tous les jetons.
Noeud de contrôle flot 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 classifieur 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 flots 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 flots 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 flots d'objets de la version UML 1.x.
Notation de points autonome
Noeuds d'activité structurés
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 flots 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 flots, 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 flots 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 flots 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 flot et le modèle s'arrêtera car la jonction attend tous ses jetons sur tous ses flots 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 flot de traitement des bagages. On peut aussi placer des protections directement sur les flots concurrents, tant que l'on est sûr qu'il n'y a pas des jonctions en aval qui en dépendent.
Utiliser les noeuds de décision et de fusion au lieu du flot concurrent 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.
Les diagrammes de communication sont utilisés afin de modéliser des interactions qui seraient des représentations d'une 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. Voir Concepts :
Composant et Concepts :
Classe structurée pour plus d'informations.
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 afin de modéliser des sous-systèmes (voir Principes et conseils :
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 afin de dessiner le contenu interne des classes structurées (voir Concepts :
Classes structurées 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 flots 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 messages selon qu'une condition est satisfaite ou non :

Exemple : Diagramme de fonctionnement avec des branches, des boucles et des conditions
|