Architecture soa (architecture orientée services)

2.6.4 Vue Technique ou la phase PSM de MDA : de la modélisation technique à la génération du code

2.6.4.1 Le BPEL

Ce langage d'exécution pour l'orchestration du processus. Il est constitué de balises dont l'une d'elles « <SEQUENCE> » permet de contenir des actions et leur structure. Il est directement issu du diagramme BPMN.

<sequence>

<receive createInstance="yes" name="Arrivée d&#39;un message" operation="dfltOperation" partner="" partnerLink="dfltPartnerLink" portType="dfltPortType" variable=""></receive>

<receive createInstance="no" name="Polling" operation="dfltOperation" partner="dfltPartner" partnerLink="dfltPartnerLink" portType="dfltPortType"></receive>

<invoke inputVariable="VQTIERS.xml" name="To_grc" operation="dfltOperation" outputVariable="GRC.xml" partner="dfltPartner" partnerLink="dfltPartnerLink" portType="dfltPortType"></invoke>

<switch name="Erreur ?">

<case condition="oui">

<invoke inputVariable="" name="Alerter" operation="dfltOperation" outputVariable="" partner="dfltPartner" partnerLink="dfltPartnerLink" portType="dfltPortType"></invoke>

<throw faultContainer="" faultName="" name="Erreur de transformation"></throw>

</case>

<otherwise>

<receive createInstance="no" name="FileTrigger" operation="dfltOperation" partner="dfltPartner" partnerLink="dfltPartnerLink" portType="dfltPortType"></receive>

<invoke inputVariable="GRC.XML" name="FtpTransfert" operation="dfltOperation" outputVariable="req_GRC.XML" partner="dfltPartner" partnerLink="dfltPartnerLink" portType="dfltPortType"></invoke>

<switch name="">

<case condition="ko">

<empty name="Ftp secouru"></empty>

<otherwise/>

<empty name="Archiver"></empty>

<invoke name="GRC%d.xml" operation="dfltOperation" partner="" partnerLink="dfltPartnerLink" portType="dfltPortType"></invoke>

</case>

</switch>

</otherwise>

</switch>

</sequence>

Illustration 118 : BPEL réalisé sous Magicdraw à partir d'un diagramme BPMN valide

2.6.4.2 Le document XSD du format Pivot

La sortie au format XMI du méta modèle UML s'obtient nativement par l'utilisation d'une fonctionnalité proposée par l'outil de modélisation (ici : MagicDraw V15). Ensuite il faut parser le document XMI afin de générer un fichier XSD. Le XMI peut aussi être utilisé pour transmettre ce travail de conception à un outil plus élaboré permettant de chaîner des opérations de transformation et de génération de code. Une autre solution, plus simple, consiste à profiter d'une fonctionnalité de transformation parfois offerte par les modeleur UML. Par exemple, il est possible de bénéficier d'une fonctionnalité de Transformation d'UML vers XML à partir de la version Enterprise de MagicDraw. Un mapping des primitives UML avec les primitives XML rend possible cette transformation du modèle UML vers le modèle XML (MOF uml). Un code d'ingénierie est alors créé et rend possible le déploiement des objets dans un des environnements supportés, tels que Java, C+, C#, Corba, DDL, XML, ou WSDL... Ce code ne constitue qu'une ossature, qu'un squelette qu'il faut ensuite habiller (préciser les occurrences minimum et maximum, l'ordre de regroupement des éléments ...)

Mécanisme de transformation entre le profile UML standard et le Profil Xml154(*)

L'attribut UML :

q Si sa multiplicité minimale = 0 alors il est optionnel, ce qui correspond à la valeur par défaut.

q Si sa multiplicité minimale = 1 alors il est obligatoire.

q Si sa multiplicité minimale > 1 alors il correspond à une liste dont le nombre de valeurs obligatoire correspond à la multiplicité minimale.

q Si sa multiplicité maximale = 1 alors il n'a qu'une seule valeur (valeur par défaut).

q Si sa multiplicité maximale > 1 alors il correspond à une liste de valeurs.

Un attribut UML est traduit en attribut (lorsqu'il est simple) ou un élément XML (lorsqu'il est multiple). Ces multiplicités sont exprimées en XML par les éléments minOccur et maxOccur. Le caractère optionnel d'un attribut XML se traduit par « use= « optional » » contrairement au caractère obligatoire « use = « required » » ou à l'appel d'une liste « use = « moyen_type ». Une liste XML peut être limitée en terme d'occurrences par « maxLength value = «n» » où « n » représente la longueur maximal de la liste (un critère « minLength » permet inversement de préciser la longueur minimale de la liste).

Et pour le reste de la transformation :

q La valeur par défaut UML se traduit par le critère « default » dans la représentation XML.

q Les annotations UML trouvent aussi leurs places dans la représentation XML grâce au critère « documentation ».

q Les types de données hérités par la classe sont de type primitif string.

q La contrainte {xor} définit une exclusion entre deux associations (l'une ou l'autre est vraie, mais pas les deux pour le même élément). Le critère XML « Choice » permet de gérer cette alternative

q La contrainte {Simultanéité} entre deux associations définit que l'activation d'une des deux associations entraîne l'activation de l'autre obligatoirement (par exemple dans notre cas, l'ouverture d'un accès internet ne se fait qu'à condition d'une adresse Email ouverte pour le tiers afin de lui communiquer les éléments de connexion). C'est le critère « Group » XML qui permet de prendre à charge de contrainte de représentation.

La limite de cette transformation assistée est probablement la notion d'ordre des éléments qui fait partie de la vérification des documents XML par les Schémas XML. Cette notion ne connaît pas d `équivalence dans le modèle UML dont l'ordre naturel correspond tout d'abord aux éléments de généralisation, aux attributs et aux associations. Cette contrainte fera ainsi l'objet d'une retouche manuelle du modèle XML. Pour résoudre ce problème, le critère « SequenceOrder » sera appliqué au modèle XML.

Illustration 119 : Diagramme XML réalisée à partir d'un diagramme de classes au profil UML standard

Les balises « use », permettant de définir le caractère obligatoire ou facultatif d'un élément, ne sont pas générées automatiquement par le modeleur utilisé. Aussi cette manipulation s'ajoute à celle concernant les balises d'occurrence, à l'ordre des séquences et aux annotations non répercutés dans le code.

Illustration 120 : Adaptations manuelles impactées au modèle XML

<?xml version='1.0' encoding='windows-1252'?>

<schema xmlns="http://www.w3.org/2001/XMLSchema">

<simpleType name="Moyen_type">

<restriction base="string">

<enumeration value="FTP"/>

<enumeration value="Telephone_mobile"/>

<enumeration value="Telephone_fixe1"/>

<enumeration value="Fax"/>

<enumeration value="URL"/>

<enumeration value="Email"/>

<enumeration value="Telephone_fixe2"/>

</restriction>

</simpleType>

<complexType name="Moyen_communication">

<sequence/>

<attribute default="Telephone_fixe1" name="Type_moyen" type="Moyen_type" use="optional"/>

<attribute name="Identifiant" type="string" use="optional"/>

</complexType>

</schema>

* ¹⁵⁴ Pour approfondir : A. LONJON « Modélisation XML » [LON-MXM].