Uml2 Déploiement

Transcription

Uml2 Déploiement
Claude Belleil
Université de Nantes
Le langage UML 2.0
Diagramme de Déploiement
1
Introduction
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
nœuds. Les nœuds 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.
Les nœuds 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ément 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.
2
Eléments
Le diagramme de déploiement se construit à partir de deux concepts de base : les éléments et les
relations entre éléments.
Les éléments :
1. artefacts
2. nœuds
3. sortes de nœuds et artefacts
a. supports d’exécution
b. environnement d’exécution
c. cible de déploiement
d. artefact déployé
Les relations entre éléments :
1. Manifestation
2. Chemin de communication
3. Spécification de déploiement
Les caractéristiques des ressources matérielles physiques et des supports de communication peuvent
être précisées par stéréotype.
2.1
Artefact
Un artefact (artifact) est la spécification d’une partie d’information physique utilisée ou produite lors du
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
1
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 nœud particulier. Il ne faut pas
confondre les nœuds présents dans les diagrammes d’activités et les nœud 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 >, < executable >, < 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 1: Représentation d'un artefact
============================================================================
«Artefact 1»
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure2»
• Un artefact est une sous-classe de la méta-classe Classifier et de ce fait
doit respecter les règles dérivées du méta-modèle.
• Un artifact doit être la manifestation d’un et un seul élément
empaquetable.[Règle dérivée du méta-modèle]
• Un artifact déployé doit s’exécuter sur au moins une instance de nœud
(possiblement plusieurs). [Nouvelle règle]
============================================================================
2.2
Nœud
Un nœud est une ressource d’exécution sur laquelle des artefacts peuvent être déployés en vue d’être
exécutés. Les nœuds 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 nœud 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 service au logiciel
développé.
1
Les paragraphes avec ce style (Courier New 8) sont des traductions d’extraits du document officiel de définition
du langage UML 2 dont vous trouverez la référence web ci-dessous.
2
http://www.omg.org/technology/documents/formal/uml.htm
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
2
Figure 2: Un noeud et une de ses instances
Figure 3: L'artefact Mon Programme.jar déployé sur un noeud PC de bureau
Lorsque l’on veut montrer la capacité d’un nœud à 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
nœud. Il est aussi possible de le faire en imbriquant les symboles des composants dans le symbole
du nœud.
Figure 4: 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 5: Noeud avec liste des artefacts
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
3
Figure 6: Noeud avec des artefacts et leur relation de dépendance
2.3
Nœuds et instances de nœuds
Un diagramme inclut parfois deux nœuds du même type. On peut alors passer de la représentation
« nœud » à la représentation « instance de nœud ». 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.
Figure 7: Une instance svr1 de Serveur Sun Blade
La figure suivante montre comment modéliser deux nœuds de même type pour représenter un
système d’équilibrage de charge.
" "# $
% &
!
Figure 8: Exemple de deux instances de noeuds de même type
============================================================================
«Noeud»
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure»
• Un nœud est une sous-classe de la méta-classe « Class », donc elle doit
respecter les règles (voir les règles de cohérence des composants du
diagramme de classes)
• La structure interne d’un nœud, si elle est définie, ne peut contenir que
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
4
d’autres nœuds. [p.196]. Lorsque des artefacts sont représentés dans les
nœuds, c’est pour indiquer une relation de déploiement.
• Les nœuds ne peuvent être associés que par deux types d’associations, des
associations de composition d’une part (dans lesquelles toutes les parties
sont des nœuds), et des chemins de communication d’autre part.
============================================================================
2.4
2.4.1
Sortes de nœuds et artefacts
Support d’exécution
Un support d’exécution (device) est une sorte de nœud qui décrit une ressource physique de calcul
sur laquelle des artefacts peuvent être déployés.
'
%
(
!""
Figure 9: Exemple de supports d'exécution
2.4.2
Environnement d’exécution
Un environnement d’exécution (execution environment) est une sorte de nœud qui décrit
environnement d’exécution pour un type spécifique de composant. De manière générale,
environnement d’exécution est soit contenu par un autre environnement d’exécution soit par
support d’exécution.
Un environnement d’exécution est noté comme un nœud auquel on associe le mot
<ExecutionEnvironment >.
un
un
un
clé
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 10: Imbrication d'un environnement d'exécution
============================================================================
«Environnement d’exécution»
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure»
• Un environnement d’exécution étant une sorte de nœud, un environnement
d’exécution doit respecter les règles énoncées dans les règles de cohérence
«Noeud».
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
5
• Un environnement d’exécution ne peut pas contenir de support d’exécution.
[Nouvelle règle]
============================================================================
2.4.3
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 nœuds,
les spécifications d’instances (si celle-ci est l’instance d’un nœud),
3
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.
============================================================================
«Cible de déploiement»
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure»
• Une spécification d’instance ne peut jouer le rôle d’une cible de
déploiement que si c’est une spécification d’instance d’un nœud et si elle
fonctionne comme une partie dans la structure interne du nœud englobant.
[p.194]
• Une possession ne peut être une cible de déploiement que si elle a pour
type un nœud et si elle fonctionne comme une partie dans la structure
interne du nœud englobant. [p.197]
============================================================================
2.4.4
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.
============================================================================
«Artefact déployé»
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure»
• Une spécification d’instance ne peut être un artefact déployé que si c’est
une spécification d’instance d’un artefact. [p.194]
============================================================================
3
3.1
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
3
voir le polycopié sur le diagramme de structure composite
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
6
composant avec le stéréotype <<manifest>>. Les artefacts pouvant être affectés à des nœuds, 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 11: Exemple de manifestation entre un artefact et un composant.
============================================================================
«manifestation»
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure»
• Une dépendance de manifestation doit avoir comme source un artefact et un
élément empaquetable comme cible. [Règle dérivée du méta modèle].Un artefact
peut être la manifestation de plusieurs éléments empaquetables.
• Une manifestation est une spécialisation d’une dépendance d’abstraction et
doit donc en respecter les règles4.
============================================================================
3.2
Chemin de communication
Un chemin de communication (Communication Path) est une association entre deux nœuds au
travers de laquelle les nœuds peuvent communiquer par l’échange de messages et de signaux.
Pour effectuer son travail, un nœud peut avoir besoin de communiquer avec d’autres nœuds. Les
chemins de communication servent à spécifier ces relations. Un chemin de communication est
représenté par une ligne pleine connectant deux nœuds. Le type de communication est indiqué par un
stéréotype sur le chemin.
) *
+
Figure 12: Un PC de bureau et un serveur communiquant par TCP/IP
On peut aussi faire figurer des chemins de communication entre des nœuds d’environnement
d’exécution. On obtient ainsi des représentations plus précises qu’avec des liens entre nœuds.
"
,-+
"
" #
"
"
$%
Figure 13: Deux environnements d'exécution communiquant par RMI5
4
5
Voir le polycopié « Classes »
RMI (Remote Method Invocation) est une API Java permettant de manipuler des objets distants de manière
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
7
============================================================================
«chemin de communication»
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure»
• Un chemin de communication est une sous-classe de la méta-classe
Association et de ce fait, il doit respecter les règles de cohérence de
cette méta classe
• Les fins d’associations d’un chemin de communication sont typés
exclusivement par des nœuds. [p.186]
• Les fins d’associations d’un chemin de communication doivent avoir leur
méta-attributs aggregation à la valeur none. [Nouvelle règle][Règle sur le
méta modèle]
• Un chemin de communication ne peut relier que deux nœuds, ou les
environnements d’exécution de deux nœuds. C’est une sorte d’association
binaire. [p.186]
============================================================================
3.3
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
nœud. Une spécification de déploiement est notée avec le mot clé <deployment spec>.
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 nœud.
Les spécifications de déploiement sont représentées par un rectangle avec
<<deployment spec>>.
le stétéotype
"
&
.
'
Figure 14: Spécification de déploiement associée à un déploiement
============================================================================
«Spécification de déploiement»
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure»
• La cible de déploiement d’une spécification de déploiement doit être un
environnement d’exécution. [p.190]
• Les éléments qui jouent le méta-rôle « deployedElements » d’une cible de
déploiement qui sont impliqués dans une relation de déploiement associée à
transparente pour l'
utilisateur, c'
est-à-dire de la même façon que si l'
objet était sur la machine virtuelle (JVM) de
la machine locale.
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
8
une spécification de déploiement doivent être de type composants. [p.190]
Cela signifie que lorsqu’un artefact est déployé en utilisant une
spécification de déploiement, si cet artefact est la manifestation
d’éléments, ces éléments doivent être des composants6.
============================================================================
4
Le diagramme de déploiement
Les diagrammes de déploiement (deployment diagrams) servent à définir l’architecture d’éxécution
d’un système. Cette architecture est représentée par l’affectation d’artefacts logiciels à des nœuds.
Les nœuds sont connectés via des chemins de communication pour créer des systèmes en réseau.
Les nœuds sont définis de manière encapsulée et représentent des cibles matérielles ou des
environnements d’exécution logiciels. Les artefacts représentent des morceaux d’information
résultants d’un processus de développement logiciel.
) *
+
!
'/
"
"
" #
,-+
"
"
$%
(
(
%
)
Figure 15: Exemple de diagramme de déploiement
============================================================================
«Le Diagramme de Déploiement7»
6
Voir le polycopié « Composants »
Les paragraphes avec ce style (Courier New 8) sont des traductions d’extraits du document officiel de définition
du langage UML 2 dont vous trouverez la référence web ci-dessous.
7
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
9
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure8»
• Les nœuds graphiques qui peuvent
déploiements sont : [p.198-199]9
apparaître
dans
un
diagramme
de
– des artefact ;
– des nœuds ;
– des spécifications de déploiements (avec éventuellement des propriétés et
leurs valeurs).
• Les chemins graphiques qui peuvent apparaître dans un diagramme de
déploiement sont : [p.199-200]
– des relations d’association ;
– des relations de dépendance ;
– des relations de généralisation ;
– des relations de déploiement ;
– des relations de manifestation.
============================================================================
5
Conclusion
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.
Ils sont utiles à toutes les phases d’un processus de conception. Ils représentent l’organisation
physique du système à déployer. Mais plus souvent encore, ils constituent la photographie de
l’organisation existante, c'
est-à-dire l’ensemble des contraintes matérielles dans lesquelles il faudra
insérer le futur développement.
Il doit contenir les détails du système qui sont importants pour la communication avec le client ou
l’équipe de développement. Si une fonctionnalité du système n’est pas déterminante, il est inutile de la
faire figurer. Elle risque d’encombrer le diagramme et de détourner l’attention des éléments
véritablement important.
8
9
http://www.omg.org/technology/documents/formal/uml.htm
Numéro de la page dans le document «UML2SuperStructure»
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
10
Index du texte :
1
2
Introduction....................................................................................................................................... 1
Eléments .......................................................................................................................................... 1
2.1 Artefact ....................................................................................................................................... 1
2.2 Nœud.......................................................................................................................................... 2
2.3 Nœuds et instances de nœuds .................................................................................................. 4
2.4 Sortes de nœuds et artefacts ..................................................................................................... 5
2.4.1
Support d’exécution ........................................................................................................... 5
2.4.2
Environnement d’exécution ............................................................................................... 5
2.4.3
Cible de déploiement ......................................................................................................... 6
2.4.4
Artefact déployé ................................................................................................................. 6
3 Relations .......................................................................................................................................... 6
3.1 Manifestation .............................................................................................................................. 6
3.2 Chemin de communication......................................................................................................... 7
3.3 Spécification de déploiement ..................................................................................................... 8
4 Le diagramme de déploiement......................................................................................................... 9
5 Conclusion...................................................................................................................................... 10
Index des figures
Figure 1: Représentation d'
un artefact .................................................................................................... 2
Figure 2: Un noeud et une de ses instances........................................................................................... 3
Figure 3: L'
artefact Mon Programme.jar déployé sur un noeud PC de bureau ...................................... 3
Figure 4: Autre manière de représenter le déploiement.......................................................................... 3
Figure 5: Noeud avec liste des artefacts ................................................................................................. 3
Figure 6: Noeud avec des artefacts et leur relation de dépendance ...................................................... 4
Figure 7: Une instance svr1 de Serveur Sun Blade ................................................................................ 4
Figure 8: Exemple de deux instances de noeuds de même type ........................................................... 4
Figure 9: Exemple de supports d'
exécution ............................................................................................ 5
Figure 10: Imbrication d'
un environnement d'
exécution.......................................................................... 5
Figure 11: Exemple de manifestation entre un artefact et un composant............................................... 7
Figure 12: Un PC de bureau et un serveur communiquant par TCP/IP.................................................. 7
Figure 13: Deux environnements d'
exécution communiquant par RMI .................................................. 7
Figure 14: Spécification de déploiement associée à un déploiement ..................................................... 8
Figure 15: Exemple de diagramme de déploiement ............................................................................... 9
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
11