SPEM4MDE

Description de l’approche

Dans (Diaw et al., 2011), les auteurs proposent le m´eta-mod`ele SPEM4MDE, une extension d´edi´ee au support des processus d’Ing´enierie Dirig´ee par les Mod`eles (IDM). Cela permet aux concepteurs d’expliciter les aspects sp´ecifiques au d´eveloppement IDM, notamment les concepts de mod`eles, m´eta-mod`eles et transformations de mod`eles. SPEM4MDE propose ´egalement un langage d´edi´e `a la mod´elisation comportementale des processus IDM pour assister les d´eveloppeurs en leur fournissant `a tout moment l’´etat de leurs activit´es et les op´erateurs de mise en oeuvre applicables. Pour cela, SPEM4MDE r´eutilise le paquetage BehaviorStateMachines d’UML Superstructure (Object Management Group (OMG), 2007) d´ecrivant les machines `a ´

etats d’UML2.2. L’ex´ecutabilit´e des transformations est rendue possible en utilisant le stan-dard QVT (Object Management Group (OMG), 2016). Le m´eta-mod`ele de SPEM4MDE est compos´e de plusieurs paquetages : ”MDE ProcessStructure”, ”Model Relationship” et ”MDE Process Behavior”. Ce dernier, avec les paquetages ”BehaviorStateMachines” d’UML 2.2 et les paquetages MOF 2.0 de QVT permettent de d´ecrire le volet comportemental de SPEM4MDE. Ce volet comportemental concerne la description du comportement des ´el´ements d’un processus par le biais de machines `a ´etats. Ces machines `a ´etats d´ecrivent les comportements g´en´eriques des ´el´ements d’un processus. Ces comportements peuvent donc ˆetre adapt´es ou r´eutilis´es pour un processus sp´ecifique.

Discussion

Contrairement `a SPEM, SPEM4MDE explicite dans son m´etamod´ele les concepts centraux de l’approche IDM (mod`ele, m´eta-mod´ele, transformation). Un paquetage a ´et´e introduit dans SPEM4MDE pour d´ecrire les aspects comportementaux d’un processus IDM. Cependant, du point de vue de la flexibilit´e de l’ex´ecution, le processus d’ex´ecution est sp´ecifi´e d`es la mod´elisation ce qui n’est pas compatible avec l’aspect de flexibilit´e par sp´ecification incompl`ete. Par l’in-term´ediaire du standard QVT, SPEM4MDE introduit un m´ecanisme pour d´ecrire la s´emantique op´erationnelle des transformations. Avec les concepts de SPEM4MDE, il est possible de mod´eliser l’ensemble des variantes possibles dans le processus. Ainsi, avec le concept TransformationImpl, SPEM4MDE permet de d´ecrire plusieurs impl´ementations d’une mˆeme d´efinition de transfor-mation : r`egles (ATL, QVT), programme (Java), template.

Figure 2.22: Organisation en paquetages du m´eta-mod`ele SPEM4MDE (Diaw et al., 2011).

2.5.3.4 eSPEM

Description de l’approche

eSPEM (Ellner et al., 2010) est une autre extension de SPEM, bas´ee sur le m´eta-mod`ele UML, pour la mod´elisation fine du cycle de vie d’un processus. Il supporte l’ex´ecution automatique des processus de d´eveloppement. Le m´etamod´ele d’eSPEM a ´et´e propos´e pour pallier le fait que SPEM ne propose pas de mod`ele comportemental. Les auteurs proposent de combiner les avan-tages des fonctionnalit´es offertes par SPEM avec les concepts de mod´elisation du comportement du langage UML. Pour exprimer le comportement des concepts de SPEM, eSPEM propose un paquetage contenant des m´eta-classes et des associations permettant de lier des ”WorkDefini-tions” de SPEM `a un comportement. La Figure 2.23 illustre le concept Activit´e d’eSPEM et le mod`ele comportemental associ´e. Pour le contrˆole des ´etats et des transitions des ´el´ements durant l’ex´ecution, eSPEM utilise les machines `a ´etat d’UML. Toutefois, ces machines `a ´etat ne sont utilis´ees que pour le contrˆole du cycle de vie des produits (”WorkProduct Lifecycle” ). Discussion

Pour permettre de s’adapter aux changements se produisant durant l’ex´ecution, eSPEM propose la m´eta-classe ”TaskScheduler”. Un TaskScheduler est responsable de la planification des tˆaches qui peuvent ˆetre dynamiquement cr´e´ees durant l’ex´ecution du processus. Un TaskScheduler est

Figure 2.23: Extrait du m´eta-mod`ele d’eSPEM illutrant le concept Activity (Ellner et al., 2010).

li´e `a une activit´e ce qui donne lieu `a une ´evolution ad-hoc. De mˆeme, pour permettre des choix durant l’ex´ecution et r´eduire les efforts durant la mod´elisation, la m´eta-classe ”ProcessToMe-thodMapping” a ´et´e introduite. Elle permet, dans le cas o`u plusieurs m´ethodes sont adapt´ees pour l’ex´ecution d’une tˆache, d’en choisir une. Ces diff´erentes m´ethodes peuvent ˆetre consid´er´ees comme des constructions de mod`eles de processus ´etant donn´e que le chemin d’ex´ecution choisi peut diff´erer. Ces diff´erentes solutions permettent `a eSPEM de couvrir les crit`eres de variabilit´e et d’´evolution.

2.5.3.5 xSPEM

Description de l’approche

xSPEM pour ”eXecutable SPEM” (Bendraou et al., 2007a) est une approche propos´ee pour ´

etendre les concepts de SPEM 2.0 afin de prendre en charge l’ex´ecution de processus logi-ciels. Le principe fondamental est de permettre aux mod`eles de processus d’ˆetre valid´es par un mapping avec les r´eseaux de Petri et d’ˆetre contrˆol´es par une transformation en BPEL. Le m´eta-mod`ele xSPEM est compos´e de cinq paquetages, comme d´ecrit par la figure 2.24. Le paquetage ”xSPEM Core” contient les concepts de SPEM 2.0 li´es `a l’ex´ecution d’un processus. Dans le paquetage ”xSPEM ProjectCharacteristics”, qui ´etend le paquetage ”xSPEM Core”, sont d´efinis les ´el´ements permettant d’adapter un processus `a un projet d´efini. Ces ´el´ements sont les propri´et´es sp´ecifiques `a l’allocation de ressources et `a la planification des activit´es.

Dans (Bendraou et al., 2007a), les auteurs consid`erent les concepts de ”RoleUse” et de ”Work-ProductUse” comme des ressources n´ecessaires `a la r´ealisation d’une activit´e. L’ex´ecution d’un mod`ele de processus est g´er´e dans le paquetage ”xSPEM ProcessObservability”. Pour d´efinir la s´emantique d’un langage sp´ecifique `a un domaine, xSPEM r´eutilise une approche bas´ee sur les propri´et´es (Combemale et al., 2007). Pour l’ex´ecution du mod`ele de processus, BPEL est utilis´e via un mapping avec les concepts de xSPEM. Par exemple, ”WorkProductUse” de xSPEM est mapp´e avec ”BPEL Variable”.

Figure 2.24: M´eta-mod`ele de xSPEM (Bendraou et al., 2007a).

Discussion

Le mod`ele de processus d’ex´ecution avec xSPEM est obtenu apr`es la mod´elisation. Cela ne permet pas de satisfaire les diff´erents crit`eres de flexibilit´e par sp´ecification incompl`ete d´efinis dans la section 2.4.2. Avec l’utilisation de BPEL, le gestionnaire de processus peut toutefois ajouter des ´el´ements ou variables d’ex´ecution. Ces additions peuvent ˆetre apparent´ees `a des

variantes ´etant donn´e que le mod`ele d’ex´ecution obtenu avec BPEL va diff´erer du mod`ele de processus xSPEM.

2.5.3.6 Bilan des approches sur la flexibilit´e de l’ex´ecution des processus