Artefact: Spécification de service |
|
 |
Cet artefact est un élément de modèle qui fournit à la fois la spécification de la structure et du comportement d'une instance de service. Une spécification de service peut également identifier un ensemble de règles régissant l'accès à un service ou à l'utilisation de ce service. Cette spécification fait office de contrat entre le client du service et l'implémenteur de ce service ; le client comprend comment interagir avec un service et l'implémenteur comprend le comportement attendu pour cette implémentation. |
Types de produits: Elément de modèle |
|
Objet
Les personnes suivantes sont amenées à utiliser l'interface de service :
-
les implémenteurs des services, pour connaître l'interface fournie par le service, mais
également le comportement attendu par ses clients,
-
les implémenteurs de clients du service, pour connaître l'interface fournie par le service,
mais également la façon dont des éléments entreront en interaction avec le service,
-
les concepteurs de services, pour comprendre la relation entre les spécifications et celle
existant entre les services et les spécifications qu'ils implémentent,
-
les concepteurs de la version suivante du système, pour comprendre les fonctionnalités du modèle de services
,
-
les personnes qui testent les classes, pour planifier les tâches de test.
La spécification de service doit fournir au fournisseur (implémenteur) et au client d'un service une description
correcte et complète des aspects suivants :
-
Spécification de l'interface : définit l'ensemble d'opérations fourni par un service réalisant cette
spécification. Chaque opération reçoit un nom et fournit une signature composée de messages d'entrée, de sortie et
d'exception.
-
Spécification du comportement : définit le protocole entre le service et le client. Un service peut être lié
à un état (de façon explicite ou implicite - voir les instructions Gestion des états temporaires des services) ou le client peut répondre à
certaines exigences d'interactivité.
-
Spécification des règles : définit les contraintes et règles relatives au fonctionnement du service.
Exemples de règles : sécurité (voir Tâche : Identifier les patterns de sécurité), disponibilité, qualité du service,
etc. ; elles représentent également des exigences non fonctionnelles de la solution dans son ensemble.
-
Spécification de variabilité : définit comment le service est configuré pour le déploiement et
comment il peut prendre en charge des cas d'utilisation génériques par la variabilité de son comportement, à la
fois dynamiquement (messages en phase d'exécution) et statiquement (via des paramètres de configuration).
|
Relations
Artefact de conteneur |
|
Rôles | Responsable:
| Modifié par:
|
Tâches | Entrée vers:
| Sortie de:
|
Description
Description principale |
L'utilisation d'une interface indique l'existence d'un ensemble d'opérations fourni par un service. Un service peut
implémenter plusieurs interfaces. Par convention, il est possible d'attacher la machine d'état d'un protocole ou une
collaboration UML 2.0 à une telle spécification pour indiquer l'ordre d'appel des opérations dans une spécification de
service. Avec ce type de spécification de comportement, il est possible de valider tout service d'implémentation par
rapport à une spécification statique, mais aussi une spécification de sa structure et de son comportement.
L'utilisation d'une classe permet à une spécification d'indiquer directement un ensemble de fonctions requises et
fournies en tant qu'unité complète.
Notez que la spécification de service peut fournir uniquement des fonctions publiques. La possibilité d'inclure des
propriétés à une spécification de service permet la modélisation des ressources.
La spécification possède la propriété "status" qui est utilisée pour représenter un concept commun parmi les
méthodologies SOA : celui d'un cycle de vie distinct pour des descriptions de service. Dans le profil, une énumération
est utilisée pour capturer ces valeurs communes, comme indiqué ci-dessous.
-
Candidat (par défaut) : indique que la spécification de service a été créée à partir d'une tâche
d'identification mais ne doit pas encore être formellement acceptée. L'acceptation peut inclure la soumission à des
tests (SOMA), l'alignement avec le portefeuille de services de l'entreprise (RUP/SOA), etc.
-
Accepté : indique que l'état d'un service est passé de "candidat" à "accepté" ; cela signifie simplement que le
service va être développé, la portée du service restant à déterminer.
-
Exposé : indique que le service doit être exposé hors de la portée immédiate. Cela implique que le service doit
être mis à disposition pour réutilisation, cela n'indique pas la portée spécifique, cela ne doit pas être lu en
tant que "public sur Internet" par exemple.
En outre, la propriété "source" permet au concepteur d'indiquer quelle technique ou quel domaine source a été utilisé
pour identifier ce service. Voir Tâche :
Analyse de processus métier, Tâche
: Analyse de modèle de données, Tâche : Analyse des actifs existants, Tâche
: Analyse de règle métier et Tâche :
Analyse de cas d'utilisation métier (architecture SOA).
|
Personnalisation
Options de représentation | Représentation UML :
Interface ou classe stéréotypée en tant que <<Service Specification>>. Une spécification doit
également fournir une machine d'état ou une collaboration de protocole qui documente la spécification de son
comportement.
Propriétés :
-
status : SpecificationStatus : indique une spécification de service en tant que service candidat, c'est-à-dire un
service qui a été identifié mais qui n'a pas encore été qualifié pour le développement.
-
source : String : cette propriété permet de capturer la "méthode" ou la technique utilisée pour identifier la
spécification de service.
Lorsqu'une classe est utilisée en tant que représentation d'une spécification de service, la classe ne doit inclure
AUCUN comportement.
|
Plus d'informations
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|