Le standards UML 2.0

Plan

Component

Un composant a des interfaces offertes et requises (via les ports).
Remplacer un composant par un autre n’est possible que si les interfaces offertes correspondent
La métaclasse Component est reliée à la métaclasse Realization par une méta-association qui précise qu’un composant peut être réalisé par une ou plusieurs realization.
La métaclasse Realization est reliée à la métaclasse Classifier par une méta-association qui précise qu’une realization se voit décrite par un classifier.
Autrement dit, un composant est une sorte d’abstraction, dont le comportement est réalisé par un ensemble de classifiers.
Ces classifiers correspondent à la vision interne du composant.
Les interfaces offertes par le composant sont donc soit implémentées directement par le composant, soit implémentées par les classifiers qui réalisent le comportement du composant.
Le lien entre la vision externe d’un composant et la vision interne est établi grâce aux ports du composant.
les ports d’un composant sont liés, d’une part, aux interfaces offertes et requises du composant et, d’autre part, aux parts du composant qui représentent la structure interne du composant.

Les métaclasses Component et Realization dans le métamodèle UML2.0 Superstructure

Le concept de connector spécifique des composants étend le concept de Connector en lui ajoutant les notions de delegation et d’assembly.
Un connector de délégation : lie un port d’un composant avec une de ses parts.
Un connector assembly lie deux composants via leur port ; il faut donc qu’un des composants requière une interface que l’autre offre.

La métaclasse Connector dans le métamodèle UML2.0 Superstructure

Le concept de realization permet d’identifier les classifiers qui réalisent le comportement du composant.

Exemple 1

Exemple 2

Le déploiement d’une application était déjà partiellement pris en compte dans la version UML1.4, mais il n’était pas réellement exploitable.
Avec UML2.0 et le support des composants, le déploiement est pleinement modélisé.
le métamodèle UML2.0 Superstructure contenait un package nommé Deployment.
Ce package comporte toutes les métaclasses nécessaires à l’élaboration de modèles de déploiement.
Le package Deployment constitué des trois sous-packages suivants :
1. Artifacts: Contient principalement la métaclasse Artifact, qui permet de représenter n'importe quelle information physique dont a besoin la plate-forme d’exécution sur laquelle l’application sera déployée. Un artefact peut représenter, par exemple, un fichier, un script ou un modèle
  Un artefact peut représenter, par exemple, un fichier, un script ou un modèle.
2. Nodes: Contient les métaclasses permettant de représenter la plate-forme d’exécution sur laquelle l’application sera déployée.
  Le package Nodes merge le package Artifacts.
3. ComponentDeployments: Contient les métaclasses permettant de modéliser concrètement le déploiement de l’application modélisée à l’aide de composants.
  Le package ComponentDeployments merge le package Node.
Sous-packages du package Deployment

Le package Artifacts définit les métaclasses Artifact et Manifestation.
Ces métaclasses permettent de modéliser les ressources qui seront utilisées par la plateforme d’exécution lors du déploiement de l’application.
Ces ressources peuvent être des fichiers JAR pour la plate-forme J2EE ou des fichiers PHP pour la plate-forme PHP.
La métaclasse Artifact hérite de la métaclasse Classifier. Cela signifie que, tout comme les classifiers.
les artefacts peuvent contenir des opérations et des propriétés et qu’il est possible de les relier grâce à des associations.
un artefact est la représentation dans le modèle d’une information représentée physiquement, sous forme de fichier, par exemple. Le nom de fichier (fileName) de l’artefact permet d’identifier la ressource physique.

Le package Artifacts
un artefact représente une ressource physique, laquelle dépend de plusieurs éléments du modèle.
Par exemple, une archive contenant les fichiers des codes source de plusieurs classes UML est représentée dans le modèle UML par un artefact.
Cet artefact peut être considéré comme une abstraction de l’ensemble des classes du modèle.

Le package Nodes contient les métaclasses Node, Device, ExecutionEnvironment et CommunicationPath .
Ces métaclasses permettent de modéliser les plates-formes d’exécution.

Le package Nodes
La métaclasse Node hérite de la métaclasse Class afin, d’une part, qu’il soit possible de lier les noeuds entre eux grâce à des communication paths, qui héritent de la métaclasse Association, et, d’autre part, qu’il soit possible de lier un noeud et un artefact.
La métaclasse Node est sous-classée par les métaclasses Device et ExecutionEnvironment.
Un noeud représente une ressource informatique (environnement d’exécution ou simple périphérique) pouvant être interconnectée avec d’autres ressources grâce à des communication paths.
Un noeud peut être constitué de plusieurs autres noeuds.
Le nœud représente l’entité sur laquelle les artefacts peuvent être déployés.

Le package ComponentDeployment contient les métaclasses:
DeploymentTarget.
Deployment et
DeployedArtifact.

Première partie du package ComponentDeployment
Un noeud est une entité sur laquelle les entités peuvent être déployées.
Un déploiement peut être vu comme une sorte de dépendance entre le noeud (DeploymentTarget) et l’artefact déployé (DeployedArtifact).
Le package ComponentDeployment, contient aussi la métaclasse DeploymentSpecification.

La seconde partie du package ComponentDeployment
la métaclasse DeploymentSpecification, possède deux attributs, nommés respectivement qui sont de type chaîne de caractères :
- deploymentSpecification
- executionSpecification
un déploiement peut être spécifié à l’aide d’une spécification de déploiement.
Cette spécification de déploiement est elle aussi considérée comme un artefact, et il faut donc la déployer.

Exemple de modèle de déploiement
On voit un serveur d’applications sur lequel sont déployés plusieurs artefacts.
essentiellement des fichiers de déploiement spécifiques de la plate-forme J2EE.
Il existe des relations de composition entre ces artefacts. Par exemple, l’artefact ShoppingApp.ear contient les artefacts Shopping Cart.jar et Order.jar.
Les artefacts ShoppingCart.jar et Order.jar sont spécifiés à l’aide des spécifications de déploiement ShoppingAppdes.xml et Orderdesc.xml, elles-mêmes considérées comme des artefacts et donc déployées sur le serveur d’applications.