Profil UML 2.0 pour les services logiciels

Par Simon Johnston, Architecte, IBM Corporation.

Résumé

Ce document décrit un profil UML pour les services logiciels, à savoir le profil UML 2.0 qui permet de modéliser les services, les architectures orientées services et les solutions orientées services. L'objectif de ce profil est de fournir un langage commun pour la description de services, qui couvrira un certain nombre d'activités du cycle de développement, ainsi que de fournir des vues à différentes parties prenantes. Par exemple, le profil fournit des fonctions permettant à l'architecte de mapper des services dans les premiers stades du cycle de vie, en utilisant des partitions logiques pour décrire la totalité du portefeuille de services de l'entreprise. Cette vue est décrite plus en détail par les concepteurs qui développent les spécifications relatives à la structure et au comportement des services faisant office de contrat entre les clients des services et les implémenteurs. La vue de message permet aux concepteurs de réutiliser les modèles d'informations pour les définitions communes de données de service.

Le profil a été implémenté dans Rational Software Architect et utilisé avec succès pour le développement de modèles de scénarios client complexes et pour la formation sur les questions relatives au développement des solutions orientées services.

Présentation du profil UML pour les services logiciels

Modèle conceptuel

Le diagramme suivant représente un modèle montrant les concepts clés de la modélisation de services. Comme vous pouvez le constater, les concepts sont relativement peu nombreux et devraient normalement être connus de toute personne ayant travaillé sur des solutions orientées services. Bien que le profil soit une réalisation de ce modèle, un certain nombre de concepts ne sont pas des stéréotypes explicites dans le profil. Par exemple, il n'existe pas de stéréotype pour les opérations ou les protocoles puisque ce sont des notions existantes dans UML 2.0, que le profil réutilise sans ambiguïté ni contrainte supplémentaire.

Diagramme décrit dans le contenu textuel.

Sous-ensemble identifié d'UML 2.0

Le tableau ci-dessous énumère les éléments du métamodèle d'UML 2.0 utilisés en tant que métaclasses pour les stéréotypes dans le profil UML.

Métaclasse UML 2.0 Stéréotypes
Classe Message, Partition de service (Service Partition), Fournisseur de services (Service Provider)
Discriminant Client des services (Service Consumer)
Collaboration Collaboration de services (Service Collaboration)
Connecteur Canal de service (Service Channel)
Interface Spécification de service (Service Specification)
Port Service, Passerelle de service (Service Gateway)
Propriété Message en pièce jointe (Message Attachment)

Le profil

Le diagramme suivant (sur lequel vous pouvez cliquer) est un diagramme du profil UML 2.0. Il présente les détails réels du profil avec chaque stéréotype et ses métaclasses à l'aide de la notation d'extension (flèche à pointe pleine). Vous pouvez également voir certaines contraintes dans le modèle, en particulier les co-contraintes entre des éléments de profil.

Diagramme décrit dans le contenu textuel.

Message Partition de service Fournisseur de services Service Passerelle de service Message en pièce jointe Client des services Collaboration de services Canal de service Spécification de service

Les sections suivantes décrivent les éléments du profil UML 2.0 tel qu'il est actuellement défini. Chaque section décrit un stéréotype ; les détails présentés concernent la métaclasse, les propriétés et toute contrainte que l'on peut appliquer lors de l'utilisation du profil.

Le stéréotype Message

Etend

Classe

Sémantique

Un message représente le concept tel qu'il est défini dans la spécification WSDL, c'est-à-dire un conteneur de données réelles ayant une signification pour le service et le client. Un message peut ne pas contenir d'opérations, mais il peut avoir des propriétés et être associé à d'autres classes (on présume qu'il s'agit de classes d'un modèle de domaine). Un stéréotype message possède une propriété pour dénoter sa forme présumée de codage (c'est-à-dire SOAP-literal, SOAP-rpc, ASN.1, etc.).

L'utilisation de cet élément est facultative dans un outil pour deux raisons. Premièrement, il est possible que le modélisateur veuille directement utiliser ces éléments en tant que paramètres d'une opération à partir d'un modèle de domaine plutôt que de préciser un message. Deuxièmement, il est possible que le modélisateur veuille utiliser la convention consistant à spécifier un ensemble de messages d'entrée et de sortie sur une opération, auquel cas l'outil de modélisation doit construire des messages d'entrée et de sortie sur une opération qui correspondent aux paramètres lors de la génération des descriptions de services dans WSDL.

Propriétés

Genre Nom Type Description
Propriété Codage Chaîne Indique le mécanisme de codage de la plateforme à utiliser dans la génération de schéma du message. Exemple : SOAP-RPC, Doc-Literal, ASN.1, etc.

Notation

Notation du message

Contraintes

Stéréotype Message en pièce jointe

Etend

Propriété

Sémantique

Ce stéréotype sert à indiquer que certains composants du message sont une pièce jointe (par opposition à une partie interne du message lui-même). De manière générale, il est peu probable que cela soit beaucoup utilisé dans les activités de conception de niveau supérieur, mais, pour de nombreux processus, il est important de différencier les données attachées des données imbriquées dans le message. Par exemple, un service de catalogue peut renvoyer les détails principaux d'un produit en tant que partie du message structuré, mais les images en pièce jointe du message. Cela nous permet de dire que le codage des images est de type binaire (par opposition au codage en texte du message principal).

Propriétés

Genre Nom Type Description
Propriété Codage Chaîne Indique le mécanisme de codage de la plateforme à utiliser dans la génération de schéma du message. Exemple : SOAP-RPC, Doc-Literal, ASN.1, etc.

Notation

Notation du message en pièce jointe

Contraintes

Stéréotype Services

Etend

Port

Sémantique

L'élément de modèle de services fournit le noeud final pour l'interaction de services (dans la terminologie des services Web), tandis que les définitions de ces interactions font partie de la spécification de service. Dans le modèle, un service identifie l'interface fournie, mais il peut aussi identifier les interfaces requises (telles que les interfaces de rappel). Il comporte également une propriété supplémentaire qui indique la liaison à utiliser comme par exemple SOAP-HTTP, SOAP-JMS, etc.

Propriétés

Aucune.

Notation

Notation du service

Contraintes

Stéréotype Canal de service

Etend

Connecteur

Sémantique

Un canal représente la voie de communication entre deux services. Il est important de noter qu'une interaction peut avoir lieu dans un canal, mais qu'un canal ne représente aucune interaction particulière. Dans le domaine des services Web, chaque service indique la/les liaison(s) qui lui sont associées (afin qu'un client puisse y accéder). Dans un profil de modélisation, une liaison est indiquée au niveau de la communication entre services ou de la communication entre un service et les clients. Cela facilite la compréhension des exigences de liaison.

Propriétés

Genre Nom Type Description
Propriété Liaison Chaîne Indique le mécanisme de codage de la plateforme à utiliser dans la génération de liaison de services dans WSDL. Exemples : SOAP-RPC, SOAP-Doc, HTTP-Get, etc.

Notation

Notation du Canal de service

Contraintes

Stéréotype Collaboration de services

Collaboration

Etend

Sémantique

Une collaboration de services est un moyen de spécifier l'implémentation d'un service en tant que collaboration d'autres services. Au niveau des services Web, cela correspond à l'utilisation de BPEL4WS pour spécifier l'implémentation de services. En d'autres termes, une collaboration de services est utilisée en tant que comportement d'un service et, si elle a pour objectif de produire un langage tel que BPEL, il est possible qu'elle soit soumise à d'autres contraintes relatives à l'implémentation.

Propriétés

Genre Nom Type Description
Propriété Liaison Chaîne Indique le mécanisme de liaison de la plateforme à utiliser dans la génération de collaboration en tant que chorégraphie du processus. Exemples : "BPEL", "WSFL", etc.

Notation

Notation de la collaboration de services

Contraintes

Stéréotype Client des services

Discriminant

Etend

Sémantique

Tout discriminant (classe, composant, etc.) peut faire office de client d'un service, ce qui inclut un autre service. Bien que ce stéréotype soit absolument facultatif, il peut s'avérer utile pour identifier les éléments d'un modèle, qui ne sont pas des services eux-mêmes, en tant que clients des services. D'un autre côté, il peut être transparent et ne pas être utilisé.

Propriétés

Aucune.

Notation

Notation de Client des services

Contraintes

Aucune.

Stéréotype Passerelle de service

Etend

Port

Sémantique

Une passerelle de service ressemble à un service, mais elle ne peut être utilisée que pour les partitions, et non pour les fournisseurs de services. Elle fait office de service proxy et peut servir de lien entre protocoles ou indiquer l'interface servant pour une partition. Par exemple, on peut dire que, bien qu'un certain nombres de services soient implémentés au sein d'une partition, seuls certains peuvent être utilisés en dehors d'une partition ; des passerelles doivent donc être fournies pour ces services. Les autres services ou partitions ne peuvent alors pas communiquer avec les services n'étant pas exposés via une passerelle.

Propriétés

Aucune.

Notation

Notation de Passerelle de service

Contraintes

Stéréotype Partition de service

Etend

Classe

Sémantique

Une partition représente une frontière logique ou physique du système. La modélisation des partitions est facultative, mais s'avère utile. En effet, on peut les utiliser pour représenter les niveaux du Web, du métier et des données d'une application de niveau n classique. Elles permettent également d'indiquer davantage de frontières physiques (telles que mon centre de données principal, mon second site, mon site client, mes partenaires, etc.), auquel cas leur croisement peut être soumis à des contraintes particulières en terme de sécurité, de protocoles autorisés, de bande passante, etc.

Une partition peut avoir pour uniques propriétés celles qui représentent les parties imbriquées, qu'il s'agisse de services ou d'autres partitions. Remarque : il s'agit d'une contrainte - aucun autre élément ne peut actuellement être représenté dans une partition.

Une partition est également considérée comme "stricte", si elle indique que toute communication avec d'autres partitions doit se faire par le biais de passerelles qui ont été saisies ; on parle alors de partition stricte.

Propriétés

Genre Nom Type Description
Propriété Discriminant Chaîne Nom de classification, pour indiquer la portée de l'espace de nom de cette partition.

Notation

Notation de Partition de service

Contraintes

Stéréotype Fournisseur de services

Etend

Classe

Sémantique

Le fournisseur de services est un élément logiciel fournissant un ou plusieurs services. En terme de modélisation, on s'attendrait plutôt à voir un composant UML à cet endroit. Néanmoins, une telle restriction semble arbitraire et la métaclasse est alors notée en tant que classe pour plus de flexibilité. Un fournisseur de services possède une propriété qui enregistre les informations concernant son emplacement, bien que cela dépende de l'implémentation. Il est possible que la classe faisant office de fournisseur de services n'expose pas directement les attributs ou les opérations et que seuls les ports publics soient fournis (stéréotypés en tant que service) et saisis par les spécifications de service.

La propriété d'emplacement, bien que spécifique à l'implémentation/la plateforme, est utile pour générer les noms des noeuds finaux du service. Avec WSDL par exemple, l'emplacement peut être http://svc.myco.com/ et le service peut s'appeler InfoClient, auquel cas le nom du noeud final pour ce service peut être http://svc.myco.com/InfoClient.

Propriétés

Genre Nom Type Description
Propriété Liaisons_autorisées Chaîne Indique le mécanisme de liaison autorisée de la plateforme qu'un canal peut utiliser en se connectant au service. Exemple : SOAP-RPC, SOAP-Doc, HTTP-Get, etc.
Propriété Emplacement Chaîne Emplacement du fournisseur ; il peut être utilisé par les générateurs pour créer des noms de noeud final.

Notation

Notation de fournisseur de services

Contraintes

Stéréotype Spécification de service

Etend

Interface

Sémantique

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. Remarque : la spécification de service peut fournir uniquement des opérations publiques.

Propriétés

Genre Nom Type Description
Propriété Publié Booléen Cette propriété indique si un service est supposé être publié dans un référentiel du service. Il s'agit d'une notion différente des propriétés publiques/privées fournies par UML.

Notation

Notation de Spécification de service

Contraintes

© Copyright IBM Corp. 2005. All Rights Reserved.