proprié-tés qu’il désire vérifier afin de tester le comportement de la composition. Dans le cas où CADP indique qu’une propriété n’est pas vérifiée, c’est à dire évaluée comme fausse, alors cela signifie qu’il y a une erreur de conception. CADP fournit alors un contre-exemple qui aide généralement le développeur à trouver ce qui ne va pas dans son modèle. Cette étape permet donc au développeur de corriger et de raffiner ses modèles UML-S jusqu’à ce qu’ils soient prouvés corrects grâce à la vérification formelle.
e) Transformation des modèles en code
Une fois les modèles UML-S corrigés, raffinés et vérifiés formellement, ceux-ci peuvent alors être transformés automatiquement en code. La génération automatique de code permet de réduire le temps et les coûts de développement tout en réduisant les risques de bogues. Les modèles UML-S étant des modèles PIM indépendants de la technologie d’implémentation et fidèlement aux principes du MDA, différents types de codes peuvent être générés à partir de ces modèles. Nous fournirons cependant des règles de transfor-mation vers BPEL dans la section 4.4 car il s’agit du langage d’exécution le plus utilisé actuellement dans l’industrie. Il convient de noter qu’à la différence d’un approche MDA classique, notre approche ne nécessite pas le passage par un modèle spécifique à la pla-teforme (PSM) et le code peut être généré directement depuis le modèle PIM. L’autre qualité d’une approche MDA est qu’il est possible de générer différentes catégories de code. Ceci est ici très utile car il est ainsi possible d’obtenir à partir des mêmes modèles à la fois la description du service composé en WSDL [CCMW01] et son code exécutable en BPEL.
4.2 Diagramme de classes
Le diagramme de classes UML est un diagramme permettant de décrire la structure statique d’un système logiciel. Il modélise les différentes parties d’un système sous forme de classes et leurs relations sous forme d’héritage, d’associations ou d’agrégation. Chaque classe du diagramme est caractérisée par un nom, un ensemble d’attributs et un ensemble de méthodes ou opérations. Le diagramme de classes est traditionnellement utilisé pour la modélisation orientée objet afin de représenter les différentes classes d’objets et les liens
entre ces classes. On obtient ainsi une vue statique de la structure du système logiciel. Nous allons d’abord présenter dans la sous-section 4.2.1 l’utilisation du diagramme de classes dans le contexte de la composition de services avec UML-S. Nous expliquerons en-suite la structure d’un document WSDL dans la sous-section 4.2.2. Enfin, nous étudierons la procédure de transformation d’un document WSDL en diagramme de classes UML-S dans la sous-section 4.2.3.
4.2.1 Utilisation du diagramme de classes
A la différence de l’approche objet, les composants d’un architecture orientée services (SOA) ne sont plus des classes mais des services. Chaque service est un composant logiciel indépendant qui se suffit à lui-même et qui est caractérisé par une interface à laquelle les autres composants logiciels doivent se conformer afin d’en faire usage. Dans le contexte de SOA, il apparaît donc intuitif et logique d’utiliser le diagramme de classes UML afin de représenter les services et plus précisément leur interface. S’agissant d’un diagramme pour la modélisation de structures statiques, celui-ci ne sera en revanche pas utilisé pour dé-crire les interactions entre les services. Nous verrons dans la section 4.3 que le diagramme d’activité UML est plus adapté à cette problématique. Nous nous contentons donc de représenter la partie statique de la composition, c’est à dire les services impliqués, leurs interfaces et les types de données manipulés. Dans le contexte de la composition de ser-vices, une classe peut donc être assimilée à un service propre aux architectures SOA ou à un type de donnée de manière similaire à l’approche objet. Une différence importante réside dans le fait qu’une classe de service comporte des opérations mais pas de propriétés alors qu’une classe représentant un type de donnée ne stipule que des attributs, appelés également propriétés. Afin d’accentuer visuellement la différence conceptuelle entre ces deux types de classe, le profil UML-S introduit le stéréotype « WebService ». Ce stéréo-type apparaît sur le diagramme au dessus du nom des classes représentant des services Web. UML-S définit également pour ce stéréotype une valeur étiquetée ou en anglais tag-ged value nommée WSDL_URL. Dans le cas où les services modélisés existent déjà, cette valeur contient l’URL vers leur description au format WSDL. Le développeur n’a pas besoin de fournir d’informations supplémentaires concernant ces services puisque toutes les propriétés importantes peuvent être récupérées à partir du WSDL.
4.2. Diagramme de classes 77 Etant donné qu’un document WSDL est conçu pour décrire l’interface et les types de données manipulées par un service Web, le diagramme de classe UML-S peut être considéré comme une représentation graphique du WSDL. Le document WSDL contient cependant plus d’informations que le diagramme UML-S, telles que le type de protocole de communication utilisé et le point d’accès du service. Ces informations sont utiles à l’implémentation mais ne présentent que peu d’intérêt pour le développeur à l’étape de spécification. C’est la raison pour laquelle UML-S ne cherche pas à représenter de manière exhaustive le contenu du document WSDL. Ceci permet d’obtenir une représentation visuelle plus compacte, plus facile à comprendre et donc à manipuler. Un document WSDL peut être transformé en diagramme de classes UML-S de manière directe, en utilisant les règles de transformation définies dans la suite de cette section. Nous considérons ici la version 1.1 de WSDL [CCMW01], bien que la version 2.0 [CW04] existe désormais. Nous choisissons la version 1.1 car elle est encore la plus utilisée et c’est par ailleurs la seule qui soit prise en charge par la version actuelle de BPEL, c’est à dire WS-BPEL 2.0 [OAS07].
4.2.2 Structure d’un document WSDL
Un document WSDL 1.1 est composé de six principales parties. La partie nommée types définit les types de données utilisés dans la description des messages échangés par le service. Pour assurer l’intéropérabilité et l’indépendance vis à vis de la plateforme, les types sont décris au format XML Schema [FW+01]. Le XML Schema est une recomman-dation du W3C parfois abréviée XSD. Tous les types de données sont donc décrits dans la partie types en XML à l’aide de XSD. Les parties message fournissent une définition abstraite des données transmises sous forme de messages. Les différentes parties des mes-sages y sont ainsi définies ainsi que leur type. Celui-ci peut être élémentaire ou complexe, auquel cas une référence sera faite à sa définition dans la partie types. Une opération de service Web à double-sens (two-way operation) prend exactement un message en entrée et en retourne un en sortie. La partie portType contient un ensemble nommé d’opérations abstraites ainsi que le nom des messages qu’elles manipulent en entrée ou en sortie. C’est dans cette partie que sont donc définies les opérations mises à disposition publiquement par le service Web. Le prototype de chacune de ces opérations est fourni, c’est à dire son nom, le nom du message qu’elle prend en entrée et le nom du message qu’elle retourne. Chaque nom de message fait ainsi référence à une partie message du même nom. La ou les parties binding décrivent le format des messages et le protocole utilisé pour les
opé-rations d’un portType donné. Il est possible d’avoir plusieurs parties binding pour un seul portType lorsque les opérations de ce portType sont interrogeables selon différentes manières. Les messages sont le plus souvent formatés en SOAP [GHM+03] et transportés à l’aide du protocole HTTP [FGM+98]. La ou les parties port définissent un point d’accès individuel en spécifiant une adresse pour chaque binding. Dans le cas habituel où le pro-tocole HTTP est utilisé pour le transport, le port fournie généralement une adresse URL et l’associe à un binding donné. Les parties port sont incluses dans la partie service. Cette partie définit un nom pour le service Web et agrège un ensemble de ports indiquant les points d’accès du service. Cette structure de document WSDL 1.1 est illustrée dans la figure 4.3.
4.2.3 Transformation du WSDL en diagramme de classes
definitions types portType service - name element operation - name - input - output Document WSDL 1.1 name
op(inName: inType): outType complexType <<WebService>> Diagramme de classes UML-S complex type - attribute_1 - attribute_2 port - binding binding - type message part - element
Figure 4.3 – Transformation de WSDL 1.1 vers diagramme de classes UML-S La figure 4.3 fournit également l’équivalence entre les sections d’un document WSDL sur la gauche et les éléments d’un diagramme de classes UML-S sur la droite. Dans la suite de cette section, nous expliquons l’approche à adopter pour transformer un document WSDL en UML-S. Cette procédure est normalement automatisée et nous expliquons ces étapes simplement à titre indicatif. La première partie du document WSDL à inspecter est la partie service qui indique le nom du service. Il est donc d’ores et déjà possible
4.3. Diagramme d’activité 79