UML 2

De l'apprentissage à la pratique


précédentsommairesuivant

8. Chapitre 8 Diagrammes de composants (Component diagram) et Diagrammes de déploiement (Deployment diagram)

8-1. Introduction

Les diagrammes de composants et les diagrammes de déploiement sont les deux derniers types de vues statiques en UML. Les premiers décrivent le système modélisé sous forme de composants réutilisables et mettent en évidence leurs relations de dépendance. Les seconds se rapprochent encore plus de la réalité physique, puisqu'ils identifient les éléments matériels (PC, Modem, Station de travail, Serveur, etc.), leur disposition physique (connexions) et la disposition des exécutables (représentés par des composants) sur ces éléments matériels.

8-2. Diagrammes de composants

8-2-1. Pourquoi des composants ?

Dans la section 1.1.4Notion de qualité pour un logiciel , parmi tous les facteurs qui concourent à la qualité d'un logiciel, nous avons introduit la notion de réutilisabilité comme étant l'aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applications. Or, la notion de classe, de par sa faible granularité et ses connexions figées (les associations avec les autres classes matérialisent des liens structurels), ne constitue pas une réponse adaptée à la problématique de la réutilisation.

Pour faire face à ce problème, les notions de patrons et de canevas d'applications ont percé dans les années 1990 pour ensuite laisser la place à un concept plus générique et fédérateur : celui de composant. La programmation par composants constitue une évolution technologique soutenue par de nombreuses plateformes (composants EJB, CORBA, .Net, WSDL…). Ce type de programmation met l'accent sur la réutilisation du composant et l'indépendance de son évolution vis-à-vis des applications qui l'utilisent.

La programmation orientée composant s'intègre très bien dans le contexte de la programmation orientée objet puisqu'il ne s'agit, finalement, que d'un facteur d'échelle. En effet, l'utilisation de composants est assimilable à une approche objet, non pas au niveau du code, mais au niveau de l'architecture générale du logiciel.

Image non disponible
Figure 8.1 : Représentation d'un composant et de ses interfaces requises ou offertes sous la forme d'un classeur structuré stéréotypé « component ». Au lieu ou en plus du mot-clef, on peut faire figurer une icône de composant (petit rectangle équipé de deux rectangles plus petits dépassant sur son côté gauche) dans l'angle supérieur droit (comme sur la figure de droite).
Image non disponible
Figure 8.2 : Représentation d'un composant accompagnée de la représentation explicite de ses interfaces requise et offerte.
Image non disponible
Figure 8.3 : Représentation classique d'un composant et de ses interfaces requise (représenté par un demi-cercle) et offerte (représentée par un cercle). Cette représentation est souvent utilisée dans les diagrammes de composants (cf. figure 8.5). Sur la figure du bas, le stéréotype « component » est rendu inutile par la représentation même du composant.
Image non disponible
Figure 8.4 : Représentation d'un composant et de ses interfaces requise et offerte avec la représentation explicite de leur port correspondant.
Image non disponible
Figure 8.5 : Représentation de l'implémentation d'un composant complexe contenant des sous-composants.

8-2-2. Notion de composant

Un composant doit fournir un service bien précis. Les fonctionnalités qu'il encapsule doivent être cohérentes entre elles et génériques (par opposition à spécialisées) puisque sa vocation est d'être réutilisable.

Un composant est une unité autonome représentée par un classeur structuré, stéréotypé « component », comportant une ou plusieurs interfaces requises ou offertes. Son comportement interne, généralement réalisé par un ensemble de classes, est totalement masqué : seules ses interfaces sont visibles. La seule contrainte pour pouvoir substituer un composant par un autre est de respecter les interfaces requises et offertes.

Les figures 8.1, 8.2, 8.3 et 8.4 illustrent différentes façons de représenter un composant.

Un composant étant un classeur structuré, on peut en décrire la structure interne. L'implémentation d'un composant peut être réalisée par d'autres composants, des classes ou des artefacts (cf. section 8.3.3Notion d'artefact (artifact)). Les éléments d'un composant peuvent être représentés dans le symbole du composant (cf. figure 8.5), ou à côté en les reliant au composant par une relation de dépendance.

Pour montrer les instances des composants, un diagramme de déploiement doit être utilisé (cf. section 8.3Diagramme de déploiement).

8-2-3. Notion de port

Un port est un point de connexion entre un classeur et son environnement.

Graphiquement, un port est représenté par un petit carré à cheval sur la bordure du contour du classeur. On peut faire figurer le nom du port à proximité de sa représentation.

Généralement, un port est associé à une interface requise ou offerte (cf. figure 8.4). Parfois, il est relié directement à un autre port situé sur la limite du composant englobant (cf. figure 8.5) par une flèche en trait plein, pouvant être stéréotypé « delegate », et appelé connecteur de délégation.

L'utilisation des ports permet de modifier la structure interne d'un classeur sans affecter les clients externes.

8-2-4. Diagramme de composants

Image non disponible
Figure 8.6 : Exemple de diagramme montrant les dépendances entre composants.

La relation de dépendance est utilisée dans les diagrammes de composants pour indiquer qu'un élément de l'implémentation d'un composant fait appel aux services offerts par les éléments d'implémentation d'un autre composant (cf. figure 8.6).

Lorsqu'un composant utilise l'interface d'un autre composant, on peut utiliser la représentation de la figure 8.3 en imbriquant le demi-cercle d'une interface requise dans le cercle de l'interface offerte correspondante (cf. figure 8.5).

8-3. Diagramme de déploiement

8-3-1. Objectif du diagramme de déploiement

Un diagramme de déploiement décrit la disposition physique des ressources matérielles qui composent le système et montre la répartition des composants sur ces matériels. Chaque ressource étant matérialisée par un nœud, le diagramme de déploiement précise comment les composants sont répartis sur les nœuds et quelles sont les connexions entre les composants ou les nœuds. Les diagrammes de déploiement existent sous deux formes : spécification et instance.

8-3-2. Représentation des nœuds

Image non disponible
Figure 8.7 : Représentation d'un nœud (à gauche) et d'une instance de nœud (à droite).

Chaque ressource est matérialisée par un nœud représenté par un cube comportant un nom (cf. figure 8.7). Un nœud est un classeur et peut posséder des attributs (quantité de mémoire, vitesse du processeur…).

Image non disponible
Figure 8.8 : Deux possibilités pour représenter l'affectation d'un composant à un nœud.

Pour montrer qu'un composant est affecté à un nœud, il faut soit placer le composant dans le nœud, soit les relier par une relation de dépendance stéréotypée « support » orientée du composant vers le nœud (cf. figure 8.8).

8-3-3. Notion d'artefact (artifact)

Image non disponible
Figure 8.9 : Représentation du déploiement de deux artefacts dans un nœud. La dépendance entre les deux artefacts est également représentée.
Image non disponible
Figure 8.10 : Représentation du déploiement de deux artefacts dans un nœud utilisant la relation de dépendance stéréotypée « deploy ».
Image non disponible
Figure 8.11 : Représentation du déploiement dans un nœud d'un artefact manifestant un composant.

Un artefact correspond à un élément concret existant dans le monde réel (document, exécutable, fichier, tables de bases de données, script…). Il se représente comme un classeur par un rectangle contenant le mot-clef « artifact » suivi du nom de l'artefact (cf. figures 8.9 et 8.9).

L'implémentation des modèles (classes…) se fait sous la forme de jeu d'artefacts. On dit qu'un artefact peut manifester, c'est-à-dire résulter et implémenter, un ensemble d'éléments de modèle. On appelle manifestation la relation entre un élément de modèle et l'artefact qui l'implémente. Graphiquement, une manifestation se représente par une relation de dépendance stéréotypée « manifest » (cf. figure 8.11).

Une instance d'un artefact se déploie sur une instance de nœud. Graphiquement, on utilise une relation de dépendance (flèche en trait pointillé) stéréotypée « deploy » pointant vers le nœud en question (cf. figure 8.10). L'artefact peut aussi être inclus directement dans le cube représentant le nœud (cf. figure 8.9). En toute rigueur, seuls des artefacts doivent être déployés sur des nœuds. Un composant doit donc être manifesté par un artefact qui, lui-même, peut être déployé sur un nœud.

8-3-4. Diagramme de déploiement

Image non disponible
Figure 8.12 : Exemple de diagramme de déploiement illustrant la communication entre plusieurs nœuds.

Dans un diagramme de déploiement, les associations entre nœuds sont des chemins de communication qui permettent l'échange d'informations (cf. figure 8.12).


précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

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 © 2013 Laurent AUDIBERT. 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.