Rôle d’UML-S dans le développement

Le langage de modélisation défini par le profil UML-S joue un rôle important au sein de notre approche de développement puisqu’il est utilisé pour la spécification des modèles décrivant la composition de services. Ce langage permet ainsi au développeur de spécifier le comportement du service composé d’une manière abstraite, indépendante de la technologie d’implémentation.

La place d’UML-S dans le cycle de développement est illustrée dans la figure 4.2. Deux types de diagrammes UML-S existent afin de permettre la modélisation d’un service com-posé selon différents points de vue. Le diagramme de classes permet de modéliser l’aspect structurel du système, c’est à dire les interfaces des services et les types de données mani-pulés. Le diagramme d’activité modélise quant à lui l’aspect dynamique de la composition, c’est à dire les interactions entre les services. Le diagramme d’activité donne ainsi une représentation claire et précise du scénario de composition sous la forme d’un processus métier. Dans le reste de cette sous-section, nous allons décrire toutes les étapes du cycle de développement dans lesquelles le langage de modélisation UML-S est impliqué. Ces étapes sont dénotées sur la figure 4.2 par a-e).

Modèles UML-S b) Classes c) Activités Services existants Service composé d) Description formelle ^{Transformation} de modèles Légende : a) _e)

Figure 4.2 – La place d’UML-S dans le cycle de développement

a) Import des descriptions WSDL des services existants

Le développeur commence par sélectionner, généralement à l’aide d’un annuaire de services tel que UDDI [BCE+02], les services existants qu’il désire composer. Il récupère ainsi les adresses des descriptions de chaque service au format WSDL [CCMW01]. Ces do-cuments WSDL décrivent principalement l’interface des services, c’est à dire les opérations publiquement disponibles et les types de données manipulés. Dans notre méthodologie de type MDA, nous mettons en œuvre la transformation automatique de modèles. Celle-ci nous permet ici de transformer le code WSDL en modèle UML-S de haut niveau. Le modèle en question consiste en un diagramme de classes, représentant graphiquement les interfaces des services sélectionnés pour la composition. Chaque service est représenté

4.1. Profil UML-S 73 par une classe marquée du stéréotype « WebService » qui partage le même nom et dont les méthodes correspondent aux opérations mises à disposition par le service en ques-tion. Dans le cas où ces services manipulent des types données complexes, des classes sans stéréotypes sont créées pour les modéliser et des associations sont ajoutées entre les classes des services et les classes modélisant leurs données. La transformation automatique entre le code WSDL et le diagramme de classes UML-S sera présentée en détails dans la section 4.2.

b) Définition de l’interface du service composé

Au cours de l’étape précédente, le développeur a sélectionné un ensemble de services et obtenu un diagramme de classes les modélisant structurellement. L’étape suivante consiste à définir l’interface du service composé que le développeur désire créer. En effet, dans le cas de l’orchestration, un nouveau service dit composé résulte de la composition des services existants. C’est ce service qui va diriger la composition, tel un chef d’orchestre. La description de l’interface du service composé passe principalement par l’ajout d’une classe stéréotypée « WebService » au diagramme de classes. Le développeur assigne alors à cette nouvelle classe le nom du service composé et y ajoute des méthodes. Un service composé doit comporter au minimum une méthode. Dans le cas où les méthodes du service composé manipulent des données non élémentaires (c.à.d autres que int, float, string, ...) en entrée ou en sortie, il sera éventuellement nécessaire d’ajouter d’autres classes afin de définir ces types. Deux cas se présentent, soit le type de donnée utilisé apparaît déjà sur le diagramme car il est utilisé par un des services importés, soit le type de donnée est nouveau. Dans le cas le plus courant où le type de donnée est déjà spécifié sur le diagramme, il suffit d’ajouter une association entre les deux classes. Dans l’autre cas, il est nécessaire d’ajouter une nouvelle classe pour définir le type puis de l’associer à la classe du service composé. La modélisation structurelle est alors achevée, le développeur peut ensuite passer à la modélisation comportementale sur service composé.

c) Définition du comportement de chaque opération

Le développeur a indiqué lors de l’étape précédente un certain nombre de méthodes qui seront fournies par le service composé. Chacune de ces méthodes correspond à un

scénario de composition distinct dont le comportement doit être spécifié. Dans le cadre de la composition de services, la conversation entre les services est généralement modélisée sous la forme d’un workflow réalisant un processus métier. Cette étape de modélisation est couramment appelée en anglais le Business Process Management ou BPM. Plusieurs langages de BPM existent mais nous nous intéressons ici au diagramme d’activité qui fait partie du standard UML. Une fois le profil UML-S appliqué, le diagramme d’activité devient un outil de BPM efficace pour permettre au développeur de spécifier le comporte-ment de la composition. Le développeur doit ainsi construire un diagramme d’activité par opération (ou méthode) définie pour le service composé. Ces modèles sont principalement constitués d’appels aux services existants sélectionnés et de manipulations basiques de données entre ces appels. Une fois les modèles de composition réalisés, il est important de procéder à leur vérification avant de les transformer en code exécutable.

d) Vérification formelle de la composition

Lors de l’étape précédente, le développeur a construit un ou plusieurs modèles dyna-miques de composition. Certains scénarios de composition sont complexes et il est parfois difficile de s’assurer manuellement que la spécification est conforme vis à vis du compor-tement attendu. Certaines approches de vérification sont basées sur la simulation où le code exécutable est généré et où le développeur est chargé d’élaborer un ensemble de jeux de tests afin de vérifier chaque fonctionnalité. L’inconvénient de cette approche est qu’il est difficile de construire un jeu de tests permettant de tester chaque chemin d’exécution possible et il est peut donc arriver que certains problèmes ne soient pas identifiés lors de la simulation. Pour éviter ce type de problème, notre approche utilise les méthodes for-melles pour procéder à une vérification exhaustive de la spécification. La solution consiste à transformer de manière automatique les diagrammes d’activité UML-S en spécifications formelles décrites à l’aide du langage LOTOS. S’agissant de descriptions formelles, celles-ci pourront être compilées à l’aide des outils adéquats afin d’obtenir une représentation mathématique. Par exemple, la boîte à outils CADP [FGK+96] est capable de compiler les descriptions en LOTOS afin d’obtenir une représentation sous forme de systèmes de transitions labellisés (LTS) [Kat05]. CADP peut alors utiliser les LTS obtenus afin d’ex-plorer mathématiquement toutes les branches d’exécution possibles et prouver que des propriétés comportementales sont vérifiées. L’outil d’évaluation de CADP prend pour ce faire en entrée un ensemble de propriétés exprimées dans la logique temporelle linéaire

4.2. Diagramme de classes 75