Introduction
En identifiant les éléments techniques et fonctionnels constitutifs d'un composant de service, nous avons délégué les
responsabilités fonctionnelles du sous-système à la fonctionnalité fournie par le composant de service. Les
composants fonctionnels offrent la fonctionnalité métier requise alors que les composants techniques fournissent une
fonctionnalité générique telle que l'authentification, le traitement des erreurs, l'audit, la consignation, etc. qui
sont des fonctions opérationnelles et non fonctionnelles.
Un modèle de services est un artefact produit lors de la phase de conception. En tant que tel, il n'est pas directement
lié à l'implémentation des services. Cependant, c'est la réalisation d'une spécification de service par un composant de
service qui implémente véritablement un service ou un ensemble de services. La spécification de service fournit le
contrat d'implémentation ; la/les technique(s) utilisée(s) pour implémenter le service n'ont pas d'importance tant que
ce contrat est rempli. Dans le concept Architecture orientée services, nous avons inséré l'image suivante pour
montrer la relation entre les services identifiés et les composants et objets qui réalisent leur implémentation.
Ainsi, nous pouvons voir comment le modèle
de conception RUP peut être utilisé pour enregistrer la conception des couches composant et objet, grâce à des
modèles et des artefacts d'implémentation qui enregistrent les détails de la couche objet, ainsi qu'à des artefacts de
déploiement et d'implémentation associés. La relation entre le modèle de service et le modèle de conception de composant possède
des caractéristiques importantes : l'ensemble des spécifications de service représente les contrats à remplir ; les
opérations identifiées sur les spécifications doivent être implémentées telles quelles ; enfin, les clients des
services utilisent ce même modèle pour comprendre l'interface et le comportement des services qu'ils prévoient
d'utiliser. Il existe ainsi une relation directe, et en général un-un, entre la spécification de service et un artefact
d'implémentation qui agit comme point d'entrée initial d'implémentation pour le service.
Considérons par exemple le diagramme suivant, représentant un fournisseur de services, qui illustre les détails des
éléments de modèle utilisés dans sa définition.
Il est primordial que le composant de service soit directement traçable depuis le modèle de services . Le procédé le
plus simple consiste à exploiter la nature de l'élément de spécification de service : il s'agit d'une interface UML
pouvant être réalisée par le composant de service, ce qui garantit sa conformité à la spécification structurelle. Le
résultat obtenu serait alors le suivant :
Il incombe maintenant à l'implémenteur de composants de définir un ensemble de composants et de classes qui établissent
le comportement du composant obtenu.
Types des composants de service
Composants fonctionnels
La constitution de ces composants fonctionnels en un composant de service à granularité plus élevée n'est pas
simplement structurelle ; elle implique également la définition d'un flux, c'est-à-dire, la collaboration des
composants fonctionnels afin de fournir une fonctionnalité prenant en charge les processus métier. Comme nous l'avons
vu plus haut, la fonctionnalité de ces composants métier est activée via les services (implémentés par l'objet de
niveau le plus faible du composant ou la structure de systèmes existante) définis.
Il est important de noter que cette étape inclut des activités OOAD traditionnelles. La conception d'objet cible un
cadre centré et correctement partitionné. La conception orientée objet traditionnelle tend à créer des graphiques
d'objet plus dépendants et plus grands alors que si l'analyse des sous-systèmes respecte l'identification des domaines
fonctionnels au sein de l'entreprise, il est possible de mettre l'accent et de diriger l'effort de conception vers un
cadre très clairement défini. L'on obtient alors un ensemble de modèles d'objet dont l'association est plus souple
(diagrammes de classe et diagrammes de séquence déclenchés par des cas d'utilisation système).
Composants techniques
La constitution des composants techniques en composants de service à
granularité plus élevée est identique à celle des composants fonctionnels. Les composants techniques tels que l'authentification, la consignation et la
génération de rapports, peuvent être utilisés sur les processus métier. Ces composants communs sont nécessaires pour former l'infrastructure prenant en
charge les composants fonctionnels. L'un des écarts clés des processus
métier est dû aux règles métier, comme indiqué dans la figure ci-dessous "Pattern de composant
d'entreprise". Ces écarts sont généralement capturés pendant la tâche
Conception orientée vers les écarts.
Patterns de composant de service
Nous avons indiqué que le composant de service réalisait simplement la spécification de service. Toutefois, cette
déclaration n'est pas d'une grande aide à l'implémenteur, lequel doit transformer une définition de service à
granularité grossière en un ensemble de classes d'implémentation et d'artefacts à granularité fine pour fournir le
comportement du service. Pour ce faire, il s'appuie généralement sur des patterns qui offrent une structure au
composant de service obtenu, en les utilisant soit comme infrastructure de départ, soit comme patterns spécifiques pour
traiter des exigences de règle particulières.
Choix du pattern, choix guidé par les exigences non fonctionnelles, architecture [plus]
Notez que les stéréotypes supplémentaires insérés ici sont décrits dans l'Artefact : Composant de service.
Pattern initial de composant de service
Lors de la définition de la structure initiale d'un service, le pattern suivant peut servir de point de départ en vue
d'être personnalisé et étoffé.
Les éléments du pattern sont les suivants :
-
Composant de façade : la façade réalise la même interface que le composant de service et offre des capacités
de base pour valider le message avant l'exécution d'une requête sur les composants spécifiques à une opération.
Pour des raisons de clarté, nous ajoutons alors le stéréotype <<facade>> à ce composant.
-
Composant spécifique à une opération : le plus souvent, étant donné la granularité des services, il s'avère
utile de disposer d'un composant ou d'une classe à part pour l'implémentation de chaque opération fournie par le
service.
Le diagramme suivant montre la vue de structure composite de ce pattern. En l'occurrence, le composant de service
délègue ses fonctions à la façade : les clients qui appellent des opérations sur le composant de service sont en
réalité servis par le composant de façade. Notez qu'il est également possible d'utiliser des ports UML 2.0 pour exposer
les interfaces et expliciter cette délégation à l'aide de connecteurs.
Pattern de composant de service à opération unique
Dans certains cas, lorsque les services identifiés dans le modèle de services comportent plusieurs opérations, il est
plus approprié d'implémenter les opérations une à une, en tant que services autonomes, en distinguant la vue de service
logique de la vue physique. Un tel pattern comporte plusieurs avantages (flexibilité de sourçage, bonne disponibilité,
meilleure gestion des versions, possibilités d'évolution), mais fait disparaître la notion d'ensemble d'opérations
associées, habituellement propre à l'interface d'un service.
La modélisation des composants de service selon ce pattern contient un seul <<Service Component>>
(Composant de service) ; celui-ci réalise une seule interface qui comporte une seule opération. Tous ces éléments sont
nommés selon les conventions usuelles et représentés ci-dessous.
Dans ce cas, comme nous l'avons déjà mentionné, aucun élément du pattern ci-dessus ne réalise directement la
spécification de service initiale. Par conséquent, il semble intéressant d'insérer dans le modèle un élément qui mette
en évidence le lien de traçabilité vers la spécification de service. Dans l'exemple ci-dessous, nous avons inséré un
composant qui comporte le stéréotype <<subsystem>>, et qui, selon la notation, implémente la spécification
de service et possède les éléments décrits ci-dessus.
Ce pattern n'inclut pas le composant <<facade>>, car ce sont les clients qui doivent identifier les
services qu'ils utilisent.
Pattern d'opération avec médiation
Lorsque la requête d'un client du service peut être acheminée pour exécution vers l'un des composants d'opération, il
est possible d'ajouter au pattern un médiateur qui acheminera ces messages, comme illustré ci-dessous. Notez que la
classe ou le composant ajouté comporte le stéréotype <<mediator>> pour plus de clarté. Le mécanisme exact
de la médiation est indéfini. Il se peut qu'un ensemble statique d'implémentations soit connu à l'avance, et qu'un
quelconque registre soit utilisé pour le mappage vers l'implémentation particulière en fonction du client, du contenu
du message de requête, etc. Ce pattern n'est pas destiné à être utilisé avec le pattern à opération unique illustré
ci-dessus.
Il affecte également la vue de structure composite du composant de service. Comme vous pouvez le constater ci-dessus,
le lien du médiateur part de la façade, qui l'utilise pour diriger les appels vers les composants d'opération.
Si un registre externe au médiateur est utilisé, il n'est pas toujours possible d'indiquer les dépendances statiques
d'utilisation depuis le médiateur vers les composants d'opération ou d'insérer des connecteurs entre les éléments du
diagramme de structure composite. Comment modéliser alors une dépendance du médiateur vers les composants d'opération ?
Dans le diagramme suivant, nous avons inséré une interface qui doit être implémentée par chaque composant d'opération.
Ainsi, nous pouvons modéliser l'utilisation du médiateur vers l'interface, comme indiqué ci-dessous.
Nous changeons également les relations dans le diagramme de structure composite, en ajoutant un nouvel élément saisi
par l'interface, et indiquons sur le connecteur la multiplicité entre le médiateur et les composants d'opération (voir
ci-dessous).
Composants d'accès aux données
Eventuellement, lorsque des opérations de service partagent des exigences de données communes, il peut s'avérer utile
de mettre en évidence les composants spécifiques qui offrent à l'implémentation des capacités de gestion de données.
Notez que la classe ou le composant concerné comporte le stéréotype <<data access>> pour plus de clarté.
Pattern de composants d'entreprise
Le pattern de composants d'entreprise ci-dessous montre le composant de service jouant le rôle de façade pour les
composants fonctionnels et techniques sous-jacents. Les services sont exposés à la limite du composant de service, sur
la façade du composant. Les demandes de services sur la façade sont transmises à un médiateur qui achemine alors le
message vers le composant fonctionnel ou technique approprié.
Pattern de composants d'entreprise
Les dépendances et les besoins entre les composants fonctionnels et les composants techniques, pour une agence de
location de véhicules par exemple, sont décrits ci-dessous.
Composant de service de réservation d'une agence de location de véhicules utilisant le
pattern de composants d'entreprise
La collection de modèles de composant de sous-système est rassemblée dans le modèle de composant fonctionnel qui montre
la dépendance des composants fonctionnels par rapport aux composants techniques et les relations existant entre les
composants fonctionnels. Les sous-processus au niveau noeud qui sont affectés à la façade du sous-système doivent être
spécifiés en tant que service qui seront fournis par le sous-système. Ces sous-processus sont pris en charge et
implémentés via un ensemble de cas d'utilisation système plus détaillé, encapsulé dans la structure du sous-système. La
réalisation des cas d'utilisation est dépendante des composants fonctionnels. A leur tour, les composants fonctionnels
dépendent des composants techniques et des utilitaires pour leurs besoins en infrastructure.
|