Expression avec un autre formalisme du comportement des

Le standard SPEM2.0 n’offre pas de concept ou de formalisme pour exprimer le comportement ou l’exécution précise d’un procédé. Toutefois, prétendant à plus

de flexibilité, SPEM2.0 offre, à travers le paquetageProcessBehavior, le moyen d’associer aux éléments de procédé SPEM2.0 un comportement exprimé avec un autre formalisme. L’objectif est de ne pas imposer un modèle comportemental pré-cis mais de donner la possibilité, au concepteur des procédés, de choisir celui qui répond le mieux à ses besoins. Une activité SPEM2.0 peut, par exemple, être liée à un diagramme BPMN afin de représenter avec plus de détails les étapes de l’ac-tivité, le flot de contrôle, etc. Le moteur d’exécution BPMN est alors réutilisé.

Une traduction vers BPEL (Business Process Execution Language) est également envisageable afin de réutiliser un moteur d’exécution BPEL existant. Par ailleurs, un produit peut par exemple être lié à un diagramme de machine à états UML afin de décrire les différents états d’un produit et les transitions entre ces états.

Ici aussi, un moteur d’exécution de machines à états doit être intégré au moteur d’exécution du procédé. SPEM2.0 définit différents types de classe proxy (Acti-vity_ext, ControlFlow_ext, Transition_ext et State_ext) afin de lier aux éléments de procédé SPEM2.0 (c.-à-d.WorkProductUse,WorkDefinition,RoleUse,Activity etWorkSequence) un comportement externe. Le concepteur du procédé doit alors lier les éléments du procédé avec leurs équivalents dans le modèle comportemen-tal choisi. Puisqu’un modèle comportemencomportemen-tal peut ne pas être assez expressif pour tous les aspects comportementaux d’un processus, plusieurs formalismes peuvent être combinés.

Même si cette approche peut offrir plus de flexibilité dans la représentation des aspects comportementaux des procédés SPEM2.0, elle présente différents manques.

Le premier est que le standard n’est pas vraiment clair sur les moyens de lier les élé-ments de procédé avec un modèle comportemental. Il offre juste des classesproxy qui font référence à d’autres éléments dans un modèle comportemental externe.

Nous supposons que cette tâche est alors à la charge des outilleurs. Ils auront donc à définir un modèle comportemental spécifique qui sera engendré automatiquement à partir du modèle de procédé. C’est déjà le cas dans l’outil du projet Eclipse EPF² qui est défini comme une implémentation de SPEM2.0. Dans EPF, un diagramme d’activité propriétaire est partiellement généré à partir de la définition du procédé.

Il peut ensuite être raffiné afin d’offrir plus de détails sur les activités du procédé et leurs coordinations (flots de contrôle). Cependant, aucune exécution n’est fournie.

Le deuxième manque est que la traduction des éléments de procédé SPEM2.0 dans le modèle comportemental spécifique peut être différente d’une organisation à une autre, en fonction de l’interprétation du modeleur du procédé. Donc, un effort de standardisation est nécessaire afin d’harmoniser les règles de traduction entre les concepts de SPEM2.0 et un modèle comportemental. Nous citerons par exemple les travaux de Bendraouet al. [BSGB07] qui proposent une traduction vers BPEL.

Le troisième manque, qui est relatif au précédent, est que le plus souvent les concepts des modèles comportementaux sont plus riches que les concepts de SPEM2.0. Cela est dû au fait que la modélisation du comportement et de l’exécu-tion offre des concepts supplémentaires relatifs au support technique et l’exécul’exécu-tion

2. Eclipse Process FrameworkProject,❤tt♣✿✴✴✇✇✇✳❡❝❧✐♣s❡✳♦r❣✴❡♣❢

3.4. DISCUSSION ET SYNTHÈSE 53 du procédé tandis que SPEM2.0 se concentre sur les préoccupations « métiers » des procédés ou méthodologies de développement (c.-à-d.,Roles,Activities, Gui-dance, etc.). En conséquence, une génération complète du code exécutable à partir de SPEM2.0 n’est pas possible sans des étapes préalables de raffinement. Ceci pose alors le problème de la traçabilité et de comment ces raffinements (changements) peuvent être répercutés dans le modèle de procédé SPEM2.0.

3.4 Discussion et synthèse

Nous avons présenté dans ce chapitre les concepts principaux de l’ingénierie des procédés de développement, plus particulièrement à travers le PML SPEM, proposé par l’OMG. Celui-ci s’inscrit dans l’IDM grâce à sa définition sous la forme d’un métamodèle (tel que nous l’avons présenté dans le chapitre2).

L’étude détaillée de ce standard nous amène à souligner les manques actuels afin de pouvoir exécuter un modèle SPEM, par exemple pour étudier très tôt la fai-sabilité d’un projet, estimer les ressources, etc. Il nous semble pour cela important d’intégrer au standard les informations pour permettre d’appréhender dans le mo-dèle son exécution, régie par une sémantique comportementale précise et explicite.

A ce titre, cette problématique correspond plus généralement à celle de l’exécutabi-lité des modèles, et donc celle de la sémantique comportementale des DSML ainsi que de leur outillage. C’est pourquoi nous avons choisi d’utiliser ce domaine d’ap-plication de manière académiquetout au long de cette thèse, pour appliquer nos travaux plus génériques visant à offrir une démarche outillée de métamodélisation.

Pour cela, nous présentons tout d’abord dans le chapitre4 des expérimentations avec les outils actuels pour exécuter des modèles décrits à partir du PML SIM

-PLEPDL présenté dans le chapitre2. Nous présentons ensuite, dans le chapitre5, une extension de SPEM2.0,XSPEM, dont les modèles supportent l’exécution du procédé pour un projet particulier. Les chapitres6et7présentent respectivement la définition des outils de vérification formelle et de simulation pourXSPEM. En-fin, le chapitre8 présente un cadre formel pour la définition de DSML, et nous montrons la formalisation possible deXSPEM.

Nous évaluons la généricité de notre approche au sein du chapitre9en l’appli-quant à d’autres domaines comme celui des systèmes embarqués critiques.

Chapitre 4

Définition de la sémantique d’exécution d’un DSML

L’IDM a permis d’établir une nouvelle approche, plus abstraite, pour le déve-loppement de systèmes complexes. Un système peut être décrit par différents mo-dèles liés les uns aux autres. L’idée phare est d’utiliser autant de momo-dèles différents que les aspects chronologiques ou technologiques du développement du système le nécessitent. La principale différence avec un programme est qu’un modèle pri-vilégie la syntaxe abstraite alors qu’un programme favorise la syntaxe concrète. La syntaxe abstraite se focalise sur les concepts fondamentaux du domaine et laisse ap-paraître une sémantique à travers le vocabulaire choisi pour nommer les concepts et les relations ainsi que la structure de graphe établie par les relations. Cette syntaxe abstraite est suffisante pour offrir une représentation homogène du système. Elle facilite l’interopérabilité entre les outils en permettant de traduire les données utili-sées par un outil dans la syntaxe utilisée par un autre outil. Cependant, lorsque l’on souhaite comprendre précisément la signification du modèle et la manière de l’in-terpréter sans ambiguïté, il est indispensable de définir la sémantique pour chaque langage de modélisation (chaque DSML dans notre cas). Ceci est particulièrement le cas pour les modèles utilisés dans le cadre de systèmes critiques (temps réel, em-barqués, fiables, redondants, performants...) qui imposent de valider les solutions envisagées au plus tôt dans le processus de développement. Le projetTOPCASED

se place dans ce contexte : les modèles construits à partir des différents DSML de l’atelier doivent pouvoir être simulés et vérifiés.

Il y a différents moyens d’exprimer la sémantique d’un langage. Toutefois, qu’il s’agisse d’un langage informatique ou du langage naturel, la définition du sens des concepts se rapporte à la définition d’unmappingvers un domaine sémantique comme nous l’avons décrit dans le chapitre2. Pour le langage naturel, il se ramène à un mapping vers la connaissance et l’expérience que l’on a du concept dans le monde qui nous entoure et le plus souvent dans notre langue maternelle.

Pour les langages de modélisation, la sémantique comportementale est géné-ralement décrite de manière ad-hoc pour chaque langage. Elle nécessite un tel

55

effort que seuls les langages les plus populaires sont pris en compte. C’est par exemple le cas pour UML, pour lequel de nombreuses machines virtuelles ont été définies (p. ex. OxUML [JZM07a], xtUML [Men07], iUML [xUM07, iUM07], XIS-xModels [LdS04], Rhapsody [GHP02] et ExecutableUML [MBB02]) avec pour la plupart un langage d’action (p. ex. OCL4X [JZM07b] dans OxUML). Il existe aussi de nombreux générateurs de code, souvent basés sur UML. Ce type de solution a aussi été utilisée dans le cadre de l’ingénierie des procédés pour des formalismes généralement spécifiques. Nous citerons par exemple les travaux de Bendraou [Ben07] proposant une spécialisation d’UML dédiée aux procédés de développement permettant d’exécuter un modèle de procédé à partir d’un compor-tement décrit en Java. Toutes ces solutions définissent précisément la sémantique du langage considéré mais celles-ci restent le plus souvent implicites, parfois même incompatibles entre différents outils supportant le même langage, et sans capitali-sation entre les différents travaux. Elles ont également toutes recours à l’ingénierie de la programmation pour exprimer la sémantique et ne profite donc pas de l’abs-traction offerte par les langages de modélisation.

Plus récemment, des travaux ont proposé des langages d’action plus abstraits permettant de définir une sémantique d’exécution pour un DSML donné. Ces lan-gages ne sont alors plus spécifiques à un DSML particulier, mais s’appuient sur les concepts plus abstraits de la métamodélisation (cf. figure2.5). Ce gain d’abstrac-tion permet d’offrir des outils génériques (machine virtuelle, générateur de code) qui s’appliquent à n’importe quelle syntaxe abstraite et qui interprètent le compor-tement défini à l’aide du langage d’action.

De nombreux projets s’appuyant sur l’IDM sont en cours de réalisation pour la validation de systèmes complexes et/ou critiques. C’est par exemple le cas dans les projets TOPCASED¹, SPACIFY², GENEAUTO³, SPICES⁴, OPENEMBEDD⁵, MODELWARE⁶et MODELPLEX⁷. L’expression de la sémantique est un point ma-jeur de ces différentes initiatives avec des solutions différentes. Il devient important de capitaliser les solutions proposées pour construire une ingénierie de la séman-tique en(méta)modélisation. Cette problématique est d’ailleurs au centre des dis-cussions qui ont lieues dans le cadre de l’atelier SéMo (Sémantique des (meta) Modèles) que nous avons fondé et dont les deux premières éditions ont eu lieu en 2007⁸à Toulouse et en 2008⁹ à Mulhouse conjointement à la conférence franco-phone IDM¹⁰.

1. cf.❤tt♣✿✴✴✇✇✇✳t♦♣❝❛s❡❞✳♦r❣

2. cf.❤tt♣✿✴✴s♣❛❝✐❢②✳❣❢♦r❣❡✳❡♥s❡❡✐❤t✳❢r 3. cf.❤tt♣✿✴✴❣❡♥❡❛✉t♦✳❣❢♦r❣❡✳❡♥s❡❡✐❤t✳❢r 4. cf.❤tt♣✿✴✴✇✇✇✳s♣✐❝❡s✲✐t❡❛✳♦r❣

5. cf.❤tt♣✿✴✴♦♣❡♥❡♠❜❡❞❞✳✐♥r✐❛✳❢r 6. cf.❤tt♣✿✴✴✇✇✇✳♠♦❞❡❧✇❛r❡✲✐st✳♦r❣

7. cf.❤tt♣✿✴✴✇✇✇✳♠♦❞❡❧♣❧❡①✲✐st✳♦r❣

8. cf.❤tt♣✿✴✴s❡♠♦✷✵✵✼✳❡♥s❡❡✐❤t✳❢ret compte rendu dans l’article [CCMP07].

9. cf.❤tt♣✿✴✴s❡♠♦✷✵✵✽✳❡♥s❡❡✐❤t✳❢r.

10. Ingénierie Dirigée par les Modèles, cf. ❤tt♣✿✴✴♠❡❣❛♣❧❛♥❡t✳♦r❣✴✐❞♠✵✼ et ❤tt♣✿✴✴

♠❡❣❛♣❧❛♥❡t✳♦r❣✴✐❞♠✵✽.

4.1. TAXONOMIE DES SÉMANTIQUES DANS L’IDM 57