Implémentation et administration d'un système d'information distribué pour le suivi des dossiers médicaux dans un hôpital

I.2. DIAGRAMME DE COMPOSANT

Diagrammes de composants illustrent les parties du logiciel, des contrôleurs intégrés, etc., qui feront partie d'un système. Un diagramme de composants a un niveau d'abstraction plus élevé qu'un Diagramme de Classes. D'habitude, un composant est mis en oeuvre par une ou plusieurs classes (ou objets) à l'exécution. Ils sont des composantes, donc un composant peut éventuellement englober une grande partie d'un système.

Le diagramme de composants permet de décrire les composants du système et les relations qui existent entre-eux.^13(*)

- Composant :

Les composants sont représentés comme un classificateur rectangulaire avec le mot-clé "composant". Éventuellement, le composant peut être affiché comme un rectangle avec une icône de composant dans le droit coin en haut.

En effet, un composant peut-être :

· Un programme

· Un logiciel regroupant un ensemble de programmes

· Un back office

· Un fichier binaire

· Un code source

· Une API

Figure 10.1: Représentation d'un composant

- Dépendances entre les composants :

Tout en restant à un niveau assez haut d'abstraction, il est possible de spécifier des relations de dépendance entre composants.

Figure 10.2 : Dépendance entre les composants

- Les interfaces

Les composants communiquent généralement entre en utilisant différentes sortes d'interfaces.

UML permet de représenter simplement ces interfaces, qui peuvent être :

· Des interfaces offertes (fournies par le composant)

· Des interfaces requises (dont le composant a besoin pour fonctionner)

Figure 11 : Représentation des interfaces

Présentation du diagramme des composants

Schéma 8 : Diagramme des composants

I.3. DIAGRAMME DE DEPLOIEMENT

Le diagramme de déploiement spécifie un ensemble de constructions qui peuvent être utilisées pour définir une architecture d'exécution. Celle-ci représente l'affectation de briques logicielles sur des noeuds. Les noeuds sont reliés entre eux par des chemins de communication créant ainsi un réseau d'un niveau de complexité variable selon les applications déployées.^14(*)

Les noeuds sont définis avec d'éventuelles imbrications et représentent soit des éléments matériels, soit des environnements d'exécution logiciels. Les artéfacts représentent des éléments physiques qui résultent du processus de développement.

Le diagramme de déploiement fournit un modèle qui est considéré comme suffisant dans la majorité des applications modernes. Là où des modèles plus élaborés sont requis, le diagramme peut être étendu au travers de profiles ou de méta-modèles spécifiques à certains environnements matériels ou logiciels.

1.3.1. Eléments d'un diagramme de déploiement^15(*)

- Artefact

Un artefact (artifact) est la spécification d'une partie d'information physique utilisée ou produite lors du processus de développement d'un logiciel.

Il représente par exemple des fichiers de modélisation, des fichiers sources, des scripts, etc... C'est un classificateur. Il peut avoir des instances qui sont déployées sur un noeud particulier. Il ne faut pas confondre les noeuds présents dans les diagrammes d'activités et les noeud présents dans les diagrammes de déploiement

Un artefact défini par l'utilisateur est un élément concret du monde physique. Il peut avoir des associations de composition avec d'autres artefacts qu'il contient. Il peut également avoir des attributs, des associations navigables et des opérations. Les stéréotypes suivants peuvent être appliqués aux artifacts: < script >, < document >, <exécutable>, < file >, < library >, < source >. Voici quelques artéfacts communs :

- Fichiers exécutables du type .exe ou .jar

- Fichiers de bibliothèque comme les fichiers .dll

- Fichiers sources, par exemple : .java ou .cpp

- Fichiers de configuration utilisés par le système comme les fichiers .xml, proprerties...

Un artefact se représente en général par un rectangle avec le stéréotype <<artifact>> et l'icône document en haut à droire.

Figure 12.1 : Un artefact

- Noeud

Un noeud est une ressource d'exécution sur laquelle des artefacts peuvent être déployés en vue d'être exécutés. Les noeuds peuvent être interconnectés via des chemins de communication (communication path en anglais).

C'est une ressource matérielle ou logicielle qui assure l'hébergement de logiciels ou de fichiers associés. Un noeud logiciel peut être vu comme un contexte applicatif. En général, il ne fit pas partie du logiciel en développement. C'est souvent un environnement tiers qui offre des services au logiciel développé.

Figure 12.2 : L'artefact Mon Programme.jar déployé sur un noeud PC de bureau

Lorsque l'on veut montrer la capacité d'un noeud à supporter un composant, il est conseillé de le faire en faisant figurer le mot clé < deploy > sur une relation de dépendance entre le composant et le noeud. Il est aussi possible de le faire en imbriquant les symboles des composants dans le symbole du noeud.

Figure 12.3: Autre manière de représenter le déploiement

On peut noter la liste des artefacts dans un noeud. Cela permet de synthétiser de façon claire le comportement du système. Cependant, la liste ne donne pas les relations de dépendance entre les différents artefacts. Pour cela, une autre représentation est possible, à l'aide d'une relation de dépendance.

Figure 13.1: Noeud avec liste des artefacts

Figure 13.2: Noeud avec des artefacts et leur relation de dépendance

- Noeuds et instances de noeuds

Un diagramme inclut parfois deux noeuds du même type. On peut alors passer de la représentation « noeud » à la représentation « instance de noeud ». Il s'agit comme c'est souvent le cas avec les diagrammes UML, de choisir la bonne granularité de représentation, c'est-à-dire celle qui clarifiera la représentation pour le client ou le donneur d'ordre.^16(*)

Figure 14: Une instance svr1 de Serveur Sun Blade

La figure suivante montre comment modéliser deux noeuds de même type pour représenter un système d'équilibrage de charge.

Figure 15: Exemple de deux instances desnoeuds de même type

- Sortes de noeuds et artefacts

Ø Support d'exécution

Un support d'exécution (device) est une sorte de noeud qui décrit une ressource physique de calcul sur laquelle des artefacts peuvent être déployés.

Ø Environnement d'exécution

Un environnement d'exécution (execution environment) est une sorte de noeud qui décrit un environnement d'exécution pour un type spécifique de composant. De manière générale, un environnement d'exécution est soit contenu par un autre environnement d'exécution soit par un support d'exécution.

Un environnement d'exécution est noté comme un noeud auquel on associe le mot clé <ExecutionEnvironment >.

Les environnements d'exécution n'existent pas seuls, ils s'exécutent sur du matériel. Par exemple, un système d'exploitation a besoin d'une machine pour fonctionner. On montre cette relation particulière par un emboîtement.

Figure 16: Imbrication d'un environnement d'exécution

Ø Cible de déploiement

Une cible de déploiement est la spécification d'un endroit où il est possible de déployer des artefacts. Il existe trois types de cibles de déploiement, les noeuds, les spécifications d'instances (si celle-ci est l'instance d'un noeud), les possessions (composite structure diagram), Les spécifications d'instances peuvent jouer le rôle de cible de déploiement afin de pouvoir spécifier des déploiements au niveau instance. Les possessions peuvent jouer le rôle d'une cible de déploiement.

Ø Artefact déployé

Un artefact déployé (deployed artifact ) est un artefact ou une instance d'artefact qui a été deployé sur une cible de déploiement.

- Relations

Ø Manifestation

Une manifestation (manifestation) est une relation qui montre qu'un élément du modèle est incorporé dans un artefact (qui est la spécification d'un élément physique). Une relation de manifestation est une spécialisation d'une dépendance d'abstraction. Lorsque l'on veut lier un artefact à l'élément empaquetable qu'il manifeste, il faut faire figurer explicitement le lien de dépendance de l'artifact avec le mot clé < manifest >

En UML, si un artefact est la représentation physique d'un composant, il constitue la manifestation de ce composant. La relation se représente par une flèche de dépendance allant de l'artefact au composant avec le stéréotype <<manifest>>. Les artefacts pouvant être affectés à des noeuds, la relation de dépendance <<manifest>> fournit le chainon manquant dans la modélisation de l'association entre les composants logiciels et le matériel.

Figure 17: Exemple de manifestation entre un artefact et un composant

Ø Chemin de communication

Un chemin de communication (Communication Path) est une association entre deux noeuds au travers de laquelle les noeuds peuvent communiquer par l'échange de messages et de signaux.

Pour effectuer son travail, un noeud peut avoir besoin de communiquer avec d'autres noeuds. Les chemins de communication servent à spécifier ces relations. Un chemin de communication est représenté par une ligne pleine connectant deux noeuds. Le type de communication est indiqué par un stéréotype sur le chemin.

Figure 18: Un PC de bureau et un serveur communiquant par TCP/IP

On peut aussi faire figurer des chemins de communication entre des noeuds d'environnement d'exécution. On obtient ainsi des représentations plus précises qu'avec des liens entre noeuds.

Ø Spécification de déploiement

Une spécification de déploiement (deployment specification) spécifie un ensemble de propriétés qui déterminent les paramètres d'exécution d'un artefact (représentant un composant) déployé sur un noeud. Une spécification de déploiement est notée avec le mot clé <deployment spec>. ^17(*)

C'est l'allocation d'un artefact ou d'une instance d'artefact sur une cible de déploiement. Il est possible de décrire un déploiement au niveau type et au niveau instance. Il est possible de décrire les propriétés qui paramètrent le déploiement et donc l'exécution d'un ou plusieurs artefacts.

En général, l'installation d'un logiciel ne se réduit pas à la copie d'un fichier sur une machine. Il est également nécessaire de spécifier un ensemble de paramètres de configuration qui seront utilisés au moment de l'exécution. Une spécification de déploiement est un artefact spécial décrivant le déploiement d'un autre artefact sur un noeud.

Les spécifications de déploiement sont représentées par un rectangle avec le stétéotype <<deployment spec>>.

1.3.2. Présentation du diagramme de déploiement

Schéma 9 : Diagramme de déploiement

* ¹³http://www.formation-uml.fr/langage/diagrammes-structurels/diagramme-de-composants/, consulté le 22/02/2020 à 10h17'.

* ¹⁴Hugues BERSINI, La programmation orientée objet, Bruxelles, Bruylant, 2011, p.79.

* ¹⁵ http://www.omg.org/technology/documents/formal/uml.htm, consulté le 23/02/2020 à 11h42'.

* ¹⁶Joseph GABAY et David GABAY, UML 2 : Analyse et conception, Paris, ENI, 2013, p.94.

* ¹⁷Claude BELLEIL, Le langage UML 2.0 : Diagramme de déploiement, Université de Nantes, 2011,cours Inédit.