Nouveautés UML 2.0

Diagrammes de classes et Diagrammes d'architecture

Cian

Cet article présente les nouveautés UML2.0 (noté également U2, UML2) en ce qui concerne le diagramme de classes et le diagramme d'architecture. Le diagramme d'architecture, aussi appelé diagramme structure composite, est un tout nouveau diagramme introduit par le standard UML2.0.
Cet article groupe les deux diagrammes, car certains concepts peuvent être utilisés dans les deux diagrammes. Les notions abordées dans cet article sur les nouveautés UML2.0 sont principalement les ports, les interfaces, les connecteurs, les parts.

- Titre : Nouveautés UML 2.0

- Auteur : Cian

- Parution : 6 novembre 2003

- Mise à jour : 3 juin 2020

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2012 Cian. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Avant-propos

- II. Signaux

- II-A. Déclaration

- II-B. Utilisation

- III. Port

- III-A. Déclaration

- III-B. Utilisation

- III-B-1. Port protocole

- III-B-2. Port comportemental

- IV. Parts (ou Partie ?)

- IV-A. Déclaration

- IV-B. Utilisation

- V. Connecteur

- V-A. Déclaration

- V-B. Exemple

I - Avant-propos

Avant de présenter les nouveaux concepts de ces deux diagrammes (classe, architecture), je vous propose quelques rappels.
Diagramme de classes
Un diagramme de classes donne une vue statique du système/logiciel. Il décrit les types et les objets du système/logiciel. Typiquement il met en relation des classes, mais aussi des interfaces, des types de données, des types énumérés…
Une classe
Une classe représente une entité, un groupe d'objets, qui partagent des propriétés (attributs), un comportement (méthodes), une structure et des interfaces communes. Une classe est instanciée pour créer un objet en particulier. Exemple classique : La classe Homme est instanciée en Adam. La classe Femme est instanciée en Ève.

II - Signaux

Un signal est un type de message pouvant être échangé entre deux objets. Il se distingue du concept d'opération : en effet, le signal est asynchrone. Un signal peut transporter des données : ces données sont spécifiées au moyen des paramètres du signal.
Le signal dispose donc de deux caractéristiques : son nom, ses attributs (ou paramètres).

II-A - Déclaration

Le signal est déclaré de la même manière qu'une opération, une classe, une interface. Sa déclaration se fait dans un diagramme de classe au moyen d'un symbole Classe stéréotypé « signal ».
Selon les outils, il pourra également être déclaré textuellement.
Les signaux peuvent être regroupés (non obligatoire) dans des Interfaces. Dans ce cas, leur nom est préfixé par le nom de l'interface (dans la représentation sous forme de classe). Cette construction permet d'une part d'augmenter la lisibilité des diagrammes et d'autre part de spécifier les interfaces des classes.

Déclaration du signal ordre :

Déclaration du signal estOK qui transporte une donnée booléenne :

Exemple de possibilité de déclaration textuelle :

Signaux faisant partie de l'interface Idemander :

II-B - Utilisation

Les signaux sont utilisés pour représenter les événements asynchrones. L'objet expéditeur n'est alors pas bloqué dans son flot d'exécution sur un retour du destinataire. Au contraire, l'objet expéditeur continue son activité.

Les signaux sont utilisés dans :

- - les diagrammes de séquences : pour représenter les interactions dynamiques entre objets ;

- - les diagrammes de classes : pour les déclarations et au travers des interfaces et des ports ;

- - les diagrammes d'architecture : pour représenter les interconnexions entre les instances de classe ;

- - les diagrammes d'états : pour représenter les déclencheurs de transitions.

III - Port

Un port permet de spécifier les points d'interactions d'un objet : soit entre l'objet et son environnement, soit entre l'objet et sa décomposition interne. Les ports sont reliés au moyen de connecteurs sur lesquels transitent les messages permettant de déclencher le comportement des objets.
Un port indique les interfaces proposées par l'objet (realized) ainsi que les interfaces requises (required). De manière simplifiée, on peut dire que les interfaces « realized » sont des ENTRÉES (in) alors que les interfaces « required » sont des SORTIES.
Les ports sont typiquement indiqués sur les classes actives.

III-A - Déclaration

Un port est déclaré sur une classe, en général, sur une classe active. Il porte un nom.
Il existe deux types de ports : les ports dits « protocole » et les ports dits « comportementaux ».

- Un port comportemental (Behaviour port) est directement associé à la machine à étatq de la classe active qui porte ce port. Tous les messages envoyés sur ce port sont consommés par la machine à étatq de la classe.

Notation d'un port comportemental :

- Un port protocole (Protocol port) sert à décrire la connectique interne et externe de la classe.

Notation d'un port protocole.

III-B - Utilisation

Les ports apparaissent essentiellement dans les diagrammes de classes et d'architecture. Un port peut être placé sur :
- une classe ;
- un part ;
- sur le pourtour (frame) d'un diagramme d'état d'une classe active ;
- sur le pourtour (frame) d'un diagramme d'architecture.

III-B-1 - Port protocole

Dans le schéma ci-dessous, le port client est typiquement un port protocole. En effet, il traduit le point d'entrée dans le système automateBillet pour les interfaces Client et comment ce point d'entrée se distribue sur les composants de l'automateBillet. Il n'a aucune signification comportementale (d'autant plus que la classe active AutomateBillet ne contient pas de diagramme d'état).

Premier niveau d'architecture : notez que les ports n'ont pas forcément besoin d'être reliés par des connecteurs. Dès l'instant où deux ports se complètent, « s'emboîtent », l'outil considère qu'ils sont connectés.

Décomposition de la classe active AutomateBillet : notez l'utilisation conjointe des notations avec/sans connecteurs.

III-B-2 - Port comportemental

Dans le schéma ci-dessous, le port DAB de la classe active Client est un port comportemental. Il traduit le point d'entrée de la classe, mais surtout indique que les interactions font vivre la machine à états qui décrit le comportement typique d'un client de distributeur automatique. La classe Client contient la description d'une machine à états.

Utilisation d'un port comportemental

Hiérarchie du modèle : machine à états

IV - Parts (ou Partie ?)

Un Part (appelons-le ainsi en attendant une traduction adéquate) désigne une ou plusieurs instances qui compose(nt) une classe.

IV-A - Déclaration

Un part est une instanciation d'une classe. Le terme de « déclaration » ne s'applique donc pas vraiment à un part.
Un part est représenté dans un diagramme d'architecture (nouveau diagramme proposé par UML2.0). Ce diagramme est également appelé diagramme structure composite.
Un part représente une ou plusieurs instances d'une classe grâce à des contraintes de multiplicité. Les multiplicités sont importantes à préciser d'abord dans un but descriptif, mais également pour avoir une simulation réaliste lorsque l'outil propose la fonctionnalité de simulation du modèle. Un part est considéré comme un attribut de la classe active qui le contient.
Ci-dessous l'exemple d'un part sans multiplicité. Dans ce cas, l'objet est construit dès que le part est construit.

Ci-dessous l'exemple d'un part avec multiplicité. La multiplicité s'exprime ainsi [ cardinalité_minimale..cardinalité_maximale ] / cardinalité_initiale. La cardinalité initiale représente le nombre d'instances créées automatiquement lors de la création de la classe contenant le part.

Exemple de Part - DAB est une instance de la classe active AutomateBillet :

Ci-dessous l'exemple d'une classe active contenant des parts :

IV-B - Utilisation

Les parts sont représentés dans les diagrammes d'architecture. Ils décrivent comment est stucturée une classe ainsi que les connexions entre les parts composants. Ils peuvent porter des ports reliés par des connecteurs.

V - Connecteur

Les connecteurs sont identifiés comme un nouveau concept. Mais cela peut facilement s'apparenter aux associations.
Ils indiquent un lien, une communication entre deux parts (au contraire des associations qui relient des classes).

V-A - Déclaration

Les connecteurs relient des parts : ils sont donc rattachés à la notion de diagramme d'architecture. Les connecteurs font transiter les messages, par exemple les signaux. Les connecteurs portent des noms.

V-B - Exemple

Dans le diagramme ci-dessus illustrant l'utilisation des parts, on identifie aff2ver et cai2ver comme connecteurs.