Nous avons introduit dans ce chapitre les principes généraux de l’IDM, c’est-à-dire la métamodélisation d’une part et la transformation de modèle d’autre part.
Ces deux axes constituent les deux problématiques clé de l’IDM sur lesquelles la plupart des travaux de recherche se concentrent actuellement.
Les premiers résultats en métamodélisation ont permis d’établir les concepts (modèleetmétamodèle) et relations (représentationDeetconformeA) de base dans
2.4. DISCUSSION ET SYNTHÈSE 45 une architecture dirigée par les modèles. Malgré tout, les modèles sont actuelle-ment construits à partir de DSML décrits principaleactuelle-ment par leur structure. Nous avons vu que si la définition des syntaxes abstraites et concrètes était maîtrisée et outillée. Il est aussi possible de vérifier structurellement la conformité d’un modèle par rapport à son DSML. Cependant, nous n’avons pas abordé dans ce chapitre les aspects liés à la sémantique d’exécution qui font l’objet du chapitre4. Notons qu’il n’y a toutefois pas de consensus sur la portée de la relation conformeA, en par-ticulier si elle ne doit prendre en compte que la conformité structurelle (c.-à-d.
le modèle respecte les context conditions de la syntaxe) ou une conformité plus large incluant la sémantique et vérifiant aussi la cohérence comportementale du modèle. Une formalisation précise de cette relation n’est à ce jour pas définie et la description précise de la sémantique des DSML reste une étape déterminante pour le passage à une approche complètement dirigée par les modèles (c.-à-d. une ap-proche où les modèles seront nécessaires et suffisants pour décrire entièrement un système – logiciel par exemple – et dans laquelle, le recours à la programmation sera intégralement transparent pour le concepteur).
Les techniques de transformation de modèle, clé du succès de l’IDM afin de pouvoir rendre opérationnels les modèles, sont issues de principes qui sont bien antérieurs à l’IDM. Malgré tout, les travaux récents de normalisation et d’implanta-tion d’outils ainsi que les nouveaux principes de l’IDM ont permis de faire évoluer ces techniques. Les transformations s’expriment maintenant directement entre les syntaxes abstraites des différents DSML et permettent ainsi de se concentrer sur les concepts et de gagner alors en abstraction. Malgré tout, des travaux sont encore nécessaires afin de formaliser ces techniques et pouvoir ainsi valider et vérifier les transformations écrites. Par exemple, les transformations permettant de générer du code à partir d’un modèle sont assimilables à une compilation qu’il est indispen-sable dans certains cas de certifier. D’autre part, si QVT offre un cadre très large pour la description de transformation de modèle en couvrant une large partie des approches possibles, ce n’est généralement pas le cas des implantations actuelle-ment disponibles. En effet, la plupart des langages n’implantent qu’une partie du standard QVT, prévu grâce aux niveaux de conformité définis par l’OMG [OMG08,
§2].
Chapitre 3
État de l’art sur l’ingénierie des procédés de développement
Nous avons abordé dans le chapitre précédent les principaux concepts de l’IDM.
Nous montrons dans ce chapitre comment ils s’appliquent au domaine des procé-dés de développement (section3.1) et plus particulièrement au travers du standard SPEM de l’OMG (section 3.2). Nous soulignons et analysons plus particulière-ment les moyens proposés dans le standard pour exécuter un modèle de procédé (section3.3). Nous terminons ce chapitre par une discussion sur les manques ac-tuels et dégageons les objectifs de nos travaux pour participer à leurs résolutions (section3.4).
3.1 Historique des procédés de développement
Dans le domaine du génie logiciel, il est depuis longtemps reconnu qu’une application est un produit manufacturé complexe dont la réalisation doit s’inté-grer dans une démarche méthodologique : le procédé de développement1. Pour améliorer la qualité du produit développé, il est important de maîtriser son pro-cédé de développement dont la problématique s’apparente à celle du logiciel lui-même [Ost87,Est05]. Plusieurs cycles de vie du logiciel (Software Development Life Cycle– SDLC) ont été proposés comme le cycle en cascade [Roy87], en spi-rale [Boe86] ou incrémental. Cependant, la communauté de la modélisation des procédés logiciels n’a pas été satisfaite de l’utilisation de ces descriptions de cycles de vie. La granularité des SDLC n’est pas assez fine et ne permet pas de décrire les parties élémentaires du procédé [CKO92]. Rapidement, le besoin a émergé de décrire avec plus de détails les procédés actuellement suivis pour le développement ou la maintenance de logiciel. L’idée a été de détailler la description de ces SDLC par les informations qui fournissent plus d’aide pour exécuter un projet de
déve-1. Dans la suite de cette thèse, nous emploierons indifféremment les termes deprocédéet pro-cessus, qualifiant tous les deux une suite d’étapes réalisées dans un but donné [Ins90]
47
loppement logiciel. Ces travaux ont permis de faire apparaître la notion de modèle de procédé (Process Model– PM).
Dans les années 90, de nombreux travaux ont porté sur la modélisation de ce procédé à des fins de compréhension, d’évaluation, d’amélioration ou d’exécution.
De nombreux AGL-P, Ateliers de Génie Logiciel centré Procédé, ont été propo-sés. Il s’agit alors de piloter un développement réel en fonction d’un procédé de développement défini dans un langage dédié [BEM94,CHL+94a,BFL+95,CC97, Bre02].
Les procédés peuvent être exprimés sous la forme d’un modèle décrit selon un langage de modélisation de procédé (Process Modeling Language– PML). Un mo-dèle de procédé est une représentation des activités du monde réel. Le momo-dèle de procédé est développé, analysé, raffiné, transformé et/ou exécuté conformément au métamodèle du procédé. Les PML et leurs Environnements de Génie Logiciel Sen-sibles au Procédé (PSEE) peuvent être classés en trois catégories suivant l’élément central du modèle de procédé :
– LesPML centrés Produitsse concentrent surtout sur les données échangées, et ont développé d’importantes propriétés concernant ces données (données orientées objet, transactions, persistance, versionnement, etc.). Ces PML ont eu beaucoup de succès dans l’industrie, surtout dans le domaine de la gestion de configuration. Nous citons par exemple les systèmes ADELE [BEM94]
et EPOS [CHL+94b].
– LesPML centrés Rôlesmettent l’accent sur les rôles et leurs collaborations.
Ces PML ont surtout eu du succès dans le domaine du travail coopératif.
– Les PML centrés Activitéss’appuient sur les activités qui représentent les tâches à réaliser. Cette catégorie a eu beaucoup de succès dans le domaine de la recherche (p. ex. SPADE [BFGL94], MARVEL [KFP88], APEL [DEA98], etc.). Du côté industriel, la construction deworkflowsa commencé vers la fin des années 90, et ceci indépendamment de tous les travaux de recherche qui ont été faits sur les procédés. Lesworkflowssont des procédés exécutables, centrés activités et généralement simples.
3.2 SPEM, le standard de l’OMG pour la modélisation des procédés
À l’instar d’UML pour les notations objets, la tendance actuelle est à l’uni-fication des PML dans l’optique industrielle indispensable de la réutilisation. Ci-tons par exemple SPEM [OMG07a], le métamodèle défini par l’OMG pour la mo-délisation des procédés de développement, ou les langages basés sur XML tels que XPDL [WfM05] proposé par le WfMC (Workflow Management Coalition) ou BPML [Ark02] proposé par le BPMI (Business Process Management Initiative).
Ces approches constituent pour l’essentiel une unification des concepts mais leur sémantique reste décrite informellement.
SPEM (Software & Systems Process Engineering Metamodel) est le standard
3.2. SPEM, STANDARD POUR LA MODÉLISATION DES PROCÉDÉS 49