Nouveautés UML 2.0 : Diagrammes de classes et Diagrammes d'architecture06/11/03
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. Avant-Propos 1. Signaux 1.1. Déclaration 1.2. Utilisation 2. Port 2.1. Déclaration 2.2. Utilisation 2.2.1. Port protocole 2.2.2. Port comportemental 3. Parts (ou Partie ?) 3.1. Déclaration 3.2. Utilisation 4. Connecteur 4.1. Déclaration 4.2. Exemple 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 Eve. 1. 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). 1.1. 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: 1.2. 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 :
2. Port
Un port permet de spécifier les points d'intéractions 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 ENTREES (in) alors que les interfaces "required" sont des SORTIES. Les ports sont typiquement indiqués sur les classes actives. 2.1. 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 : 2.2. 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 2.2.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. 2.2.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 : Hierarchie du modèle : machine à états 3. 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. 3.1. 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 : 3.2. 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.
4. 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). 4.1. 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. 4.2. Exemple
Dans le diagramme ci-dessus illustant l'utilisation
des parts, on identifie aff2ver et cai2ver
comme connecteurs.
Ce document est issu de http://www.developpez.com
et reste la propriété exclusive de son auteur.
La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur. |