Modélisation rigoureuse en SPEM de procédé de

Modélisation rigoureuse en SPEM
de procédé de développement
Benoît Combemale* — Xavier Crégut* — Alain Caplain**
Bernard Coulette**
* Laboratoire IRIT-LYRE
2, rue Charles Camichel, BP 7122
F-31071 Toulouse Cedex 7
{benoit.combemale, xavier.cregut}@enseeiht.fr
** Laboratoire GRIMM-ISYCOM
5, allée Antonio Machado
F-31058 Toulouse Cedex 9
{caplain, coulette}@univ-tlse2.fr
La maîtrise du procédé de développement est un élément important pour l’amélioration de la qualité des applications développées. L’OMG propose le méta-modèle SPEM pour
la modélisation des procédés. Cependant, cette proposition reste relativement abstraite et est
dépourvue d’une description formelle de sa sémantique ce qui la rend difficile à utiliser. Aussi,
nous en proposons une restriction qui permet d’en préciser les concepts et qui est complétée
par une formalisation en OCL des propriétés. Nous appliquons notre méta-modèle à la modélisation de la méthode d’analyse et conception orientée-objet MACAO. Ceci donne un exemple
de modélisation SPEM et montre la manière d’utiliser OCL et les limites identifiées.
RÉSUMÉ.
ABSTRACT. Mastering software process is a keypoint in the improvement of application quality.
OMG proposes the SPEM metamodel to model software processes. Unfortunately, it is a high
level specification which lacks a formal description of its semantics. It is thus difficult to use
SPEM. So, we propose a restriction of SPEM that clarifies its concepts and which is completed
with a formalization of its semantics using OCL. This metamodel has been used to model the
MACAO object-oriented analysis and design method. We thus show how to use SPEM and OCL
and their limits.
MOTS-CLÉS :
Ingénierie des procédés, Ingénierie des modèles, SPEM, OCL.
KEYWORDS:
Process engineering, Model engineering, SPEM, OCL.
136
LMO 2006
1. Introduction
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éveloppement. Pour améliorer la qualité
du produit développé, il est important de maîtriser son procédé de développement dont
la problématique s’apparente à celle du logiciel lui-même (Osterweil, 1987, Estublier,
2005).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é proposés.
Il s’agit alors de pouvoir piloter un développement réel en fonction d’un procédé de
développement défini dans un langage dédié (Belkhatir et al., 1994, Conradi et al.,
1994, Bandinelli et al., 1995, Crégut et al., 1997, Breton, 2002). À l’instar d’UML
pour les notations objets, la tendance actuelle est à l’unification des Langages de Description de Procédé (LDP). Citons par exemple SPEM (OMG 2005a), le méta-modèle
défini par l’OMG pour la modélisation des procédés de développement, ou les langages basés sur XML tels que XPDL (WfMC, 2005) proposé par le WfMC (Workflow Management Coalition) ou BPML (Arkin, 2002) 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.
Nos travaux s’appuient sur l’utilisation de SPEM pour la formalisation des procédés de développement. Ce langage offre une syntaxe graphique et une sémantique
décrite en langage naturel (entraînant donc certaines ambiguïtés) mais ne donne pas
de démarche pour l’élaboration d’un procédé de développement. Par ailleurs, le métamodèle proposé par l’OMG est très général et par conséquent n’offre pas de directive
sur le découpage d’un procédé ni sur les détails d’utilisation de certains concepts.
Ainsi nous proposons une spécialisation par restriction du méta-modèle SPEM dont
l’objectif est de clarifier les concepts utilisés (Combemale, 2005). Bien entendu, si
nous gagnons en rigueur, nous perdons en flexibilité puisque nous contraingnons les
utilisations possibles de SPEM. Après avoir rappelé les concepts principaux de SPEM
(section 2), nous présentons (section 3) une restriction du méta-modèle SPEM qui
en clarifie les concepts, son utilisation et complète la formalisation de sa sémantique
à l’aide du langage OCL (Object Constraint Language) (OMG 2005b). Nous proposons enfin la démarche que nous avons suivie pour la formalisation d’un procédé de
développement : le méta-procédé. Dans la section 4 nous illustrons l’utilisation de
SPEM en modélisant le procédé de développement de la Méthode d’Analyse et de
Conception d’Applications orientées-Objet (MACAO) (Crampes, 2002). Nous terminons (section 5) par un bilan de nos travaux sur la modélisation des procédés et sur les
perspectives qu’ils ouvrent.
2. Présentation de SPEM
SPEM est un langage de modélisation utilisé pour la spécification de procédés de
développement ou d’une famille de procédés de développement. Il offre une approche
Modélisation rigoureuse en SPEM
137
orientée objet et utilise la notation UML (OMG 2004). Issu des travaux de l’OMG,
SPEM s’inscrit doublement dans l’organisation de la pile de modélisation du MDA
(Model Driven Architecture) (Miller et al., 2003) : comme un méta-modèle conforme
au MOF (Meta Object Facility) (OMG 2002) et comme une extension d’UML sous la
forme d’un profil1 (Breton et al., 2001).
SPEM reprend d’UML une grande partie des diagrammes (packages, cas d’utilisation, classes, activités, séquences, états-transitions) mais exclut certains concepts
(node, component, ...) (OMG 2005a, §11.1) et ne permet donc pas, par exemple,
l’établissement de diagrammes d’implémentations2 . De nombreux stéréotypes ont par
ailleurs été ajoutés pour affiner la sémantique de certains éléments UML (Process,
ProcessRole, Activity, WorkProduct, Goal...)3 (OMG 2005a, §11).
Conceptuellement, le méta-modèle repose sur l’idée (fig. 1) qu’un procédé de développement de logiciel est une collaboration entre des entités actives et abstraites, les
rôles qui effectuent des opérations, les activités, sur des entités concrètes et réelles, les
produits. Les différents rôles agissent les uns sur les autres ou collaborent en échangeant des produits et en déclenchant l’exécution de certaines activités.
Figure 1. Modèle conceptuel de SPEM
Bien entendu, le méta-modèle SPEM est plus compliqué. Un extrait est donné
figure 2. SPEM définit la notion de définition de travail (WorkDefinition) qui peut
être décomposée réflexivement. Outre les activités, il existe d’autres spécialisations
(omises sur la figure 2) : cycle de vie (Lifecycle) qui est une séquence de phases
1. Un profil UML permet de spécialiser le langage pour un domaine particulier. Il est composé
de stéréotypes, de tagged value et de contraintes.
2. Le concept de noeud (Node) étant exclu, les diagrammes de déploiement ne peuvent pas
être établis. Il en est de même avec le concept de composant (Component) et le diagramme de
composant. Notons que le concept de composant de procédé présent dans SPEM (ProcessComponent) est une spécialisation du concept de paquetage (Package) et apparaitra donc dans un
diagramme de packages.
3. Par exemple, le concept de Goal présent dans SPEM et définissant l’objectif d’un travail, est
un stéréotype du concept UML Constraint dont la sémantique fut affinée pour préciser qu’il
s’agit d’une contrainte définissant une post-condition. La liste complète des stéréotypes est
donnée en (OMG 2005a, §11.4).
138
LMO 2006
Figure 2. Paquetage « Process_Structure » de SPEM
(Phase) et itération (Iteration) pour définir un travail composite. Une activité peut
être décomposée en étapes élémentaires (Step).
Chaque WorkDefinition est sous la responsabilité d’un unique rôle (ProcessPerformer). Dans le cas d’une activité, d’autres rôles (ProcessRole) peuvent également
l’assister. En SPEM, un rôle est une entité abstraite modélisant un ensemble de compétences. Un acteur concret (pas forcément humain) d’un procédé peut donc jouer un
ou plusieurs rôles en fonction de ses compétences. Réciproquement, un rôle peut être
joué par un ou plusieurs acteurs.
SPEM définit également la notion de composant de procédé (ProcessComponent),
élément de procédé réutilisable, spécialisée en procédé ou discipline (fig. 3). Un procédé (Process) correspond à la racine du modèle de procédé à partir duquel on peut
faire la fermeture transitive du procédé complet. Une discipline (Discipline) permet
de partitionner les activités d’un procédé selon un thème commun. Par exemple, la
méthode RUP (Booch et al., 2003) définit les disciplines modélisation métier, recueil
des exigences, analyse et conception... Les produits de sortie de chacune des activités
d’une discipline doivent être catégorisés sous ce même thème.
3. Méta-modélisation rigoureuse pour les procédés
Comme on le constate sur la figure 2, les éléments propres à SPEM sont définis
comme une spécialisation des concepts d’UML (le paquetage Core de SPEM correspond à un import des éléments d’UML). En conséquence, la syntaxe de SPEM
Modélisation rigoureuse en SPEM
139
Figure 3. Paquetage « Process_Components » de SPEM
est très générale et permet de construire de nombreux modèles qui peuvent être en
contradiction avec la sémantique exprimée en langage naturel dans sa spécification.
Par exemple, la relation de composition entre Namespace (espace de noms) et ModelElement du paquetage Process_Components (fig. 3) permet de définir une Discipline
comme un ensemble de Process puisque tous deux sont une spécialisation de Namespace et de ModelElement. Or ceci est contraire à la contrainte informelle (OMG
2005a, §8.4) : « Une discipline [...] divise les activités dans un procédé selon un thème
commun »).
Pour pallier le manque de précision et de formalisation de SPEM qui rendent
son utilisation difficile, nous proposons une spécialisation (par restriction) du métamodèle SPEM dans laquelle nous avons choisi de redéfinir les relations héritées
d’UML pour une meilleure clarté et compréhension de SPEM. Nous avons également précisé au sein de notre proposition un certain nombre d’informations données
informellement dans la spécification. Enfin, nous avons complété ce méta-modèle par
des contraintes OCL pour préciser la sémantique (et donc l’utilisation) de certains
concepts.
3.1. Restriction du méta-modèle SPEM
Nous proposons une modélisation du procédé dont les principaux concepts sont
organisés en une vue structurelle et une vue descriptive (fig. 4). La vue structurelle
permet de découper le procédé de manière hiérarchique. Nous avons redéfini la relation réflexive de décomposition d’une WorkDefinition pour chaque sous-concept (Lifecycle, Phase, Iteration et Activity) explicitant ainsi les relations possibles entre eux.
Pour cela le procédé (Process) est associé à un cycle de vie (Lifecycle) découpé en
phases (Phase), elles-mêmes composées d’itérations (Iteration) et/ou d’activités (Acti-
140
LMO 2006
vity). Les associations entre les méta-classes Lifecycle, Phase, Iteration et Activity correspondent à la redéfinition de la relation reflexive présente sur la méta-classe WorkDefinition du méta-modèle d’origine (fig. 2). Une multiplicité 1 du côté de la source
de ces relations donne la sémantique de la (dé)composition. Comme en SPEM, WorkDefinition n’est pas un concept abstrait. Ceci permet lors de la définition d’un modèle
de procédé d’instancier des WorkDefinitions qui devront ensuite, éventuellement lors
de l’exécution du procédé, être typées en l’une des sous-classes. La relation réflexive
a été conservée pour pouvoir décomposer une WorkDefinition non encore typée. Notons enfin que nous avons ajouté la contrainte {PartiallyOrdered} sur l’ensemble des
étapes élémentaires (Step) composant une activité (Activity). Cette contrainte traduit
l’ordonnancement des ActionState dans UML (OMG 2004, §4.12) que la méta-classe
Step spécialise (fig. 2).
La vue descriptive permet de spécifier une WorkDefinition en précisant ses objectifs (Goal), ses préconditions, le rôle qui en a la responsabilité (ProcessRole) et les
produits (WorkProduct) manipulés. Une discipline comprend un ensemble de rôles et,
par transitivité, les définitions de travail et les produits associés. Parce qu’elle n’a pas
une sémantique claire en SPEM (Bendraou et al., 2005), la notion de ProcessPerfor-
Figure 4. Vue partielle de notre restriction du méta-modèle SPEM
Modélisation rigoureuse en SPEM
141
mer (fig. 2) a été fusionnée dans notre proposition avec celle de ProcessRole4 . Elle
modélise les compétences requises pour réaliser une WorkDefinition.
À l’instar des relations entre les sous-méta-classes de WorkDefinition, nous avons
redéfini d’autres relations entre les concepts de SPEM pour les rendre plus évidentes
(le méta-modèle que nous proposons permet ainsi de manière autonome de montrer
les posssibilités et l’utilisation de SPEM à un concepteur). Ces relations étant des
redéfinitions de relations héritées d’UML, elles restent compatibles avec la version
officielle de SPEM. Ainsi, nous avons redéfini une relation réflexive sur WorkProduct
pour bien montrer que tout produit est potentiellement structuré. Cette relation est
déduite de Classifier.
De la même manière, nous avons souhaité expliciter les relations use et realize
entre WorkDefinition et WorkProduct car elles nous semblent essentielles pour bien
comprendre un procédé. Preuve en est le schéma conceptuel (fig. 1) présenté par
l’OMG. Ces relations correspondent, de manière formelle, à un héritage du paquetage
Core (fig. 5). Les multiplicités ont été reprises du méta-modèle initial et permettent
de prendre en compte toutes les particularités : produits qui ne sont pas réalisés au
cours d’une activité pour les documents initiaux (e.g. le cahier des charges), produits
jamais utilisés au sein d’une activité pour les produits finaux ou encore les activités
n’utilisant pas ou ne produisant pas de produit.
Enfin, la relation de composition entre ProcessRole et WorkDefinition (en fait ProcessPerformer) est un autre exemple d’ambiguïté dans SPEM car aucune sémantique
n’est associée à la contrainte {ordered}. Pour rester compatible, nous l’avons conservée mais en indiquant qu’elle pouvait être déduite, principalement des dépendances
de précédence (Precedes) qui peuvent être ajoutées entre les WorkDefinitions. Cette
dépendance permet d’indiquer un ordonnancement partiel début-à-début, fin-à-début
et fin-à-fin entre les WorkDefinitions. Notons que cet ordre doit être cohérent avec
les préconditions (Precondition) et objectifs (Goal) de chaque WorkDefinition impliquant, de manière implicite, leur ordonnancement au sein du procédé de développement. Cependant l’expression de ces contraintes n’étant pas formelle en SPEM, elles
ne peuvent pas être vérifiées au niveau méta-modèle.
4. Cette fusion sera formalisée à l’aide du langage OCL dans la section 3.2
Figure 5. Héritage du Package Core UML 1.4
142
LMO 2006
3.2. Précisions sémantiques du méta-modèle à l’aide d’OCL
Dans l’optique d’avoir un méta-modèle clair et facilement compréhensible, notre
proposition intègre de nombreux ajouts syntaxiques (au travers la redéfinition de relations pour l’essentiel). Ces redéfinitions auraient toutefois pu être décrites sémantiquement à l’aide de contraintes OCL (OMG 2005b). Par exemple, pour exprimer
qu’une Iteration est uniquement “composée” d’Iteration et d’Activity on peut utiliser
la contrainte OCL suivante :
context Iteration inv :
self.subWork→f orAll( wd : WorkDefinition |
wd.oclIsT ypeOf (Iteration) or wd.oclIsT ypeOf (Activity))
Cependant, augmenter la syntaxe du méta-modèle SPEM n’est pas suffisant pour
obtenir une description formelle complète du méta-modèle. Par exemple, on ne peut
pas capturer par un ajout syntaxique la propriété suivante de notre proposition : « un
rôle doit être responsable de l’ensemble des produits réalisés par les activités dont il a
la charge et réciproquement. »
Aussi, nous avons ajouté des contraintes limitant les instances valides de ce métamodèle. Comme le préconise l’OMG, nous avons utilisé le langage OCL. La propriété
précédente s’exprime alors comme suit.
context ProcessRole inv :
let productsActivities : Set{WorkProduct} =
– – Definition de l’ensemble des WorkProducts realisés par les
– – Activity dont le role (self) est responsable.
– – Attention : le transtypage (oclAsType) est obligatoire pour
– – pouvoir ensuite naviguer à partir de la meta-classe Activity.
self.work→ select(a :WorkDefinition |
a.oclIsT ypeOf (Activity)).oclAsT ype(Activity).
output→ asSet() – – Suppression des doublons
in
self.workProduct = productsActivities
Une autre propriété que nous avons ajoutée consiste à formaliser la fusion des
concepts ProcessPerformer et ProcessRole faite au sein de notre méta-modèle. Cette
contrainte interdit l’instanciation de la méta-classe ProcessPerformer présente dans le
standard SPEM :
context ProcessPerformer inv :
self.allInstances()− > size() = 0
D’autre contraintes ont été ajoutées : une activité (ou une itération) doit être obligatoirement associée soit à une phase soit à une itération mais pas les deux en même
temps ; la réalisation d’une activité ne peut pas être assistée par le rôle qui en a déjà la
responsabilité ; une activité doit utiliser ou réaliser au moins un produit, etc.
Modélisation rigoureuse en SPEM
143
Bien entendu, nous ne devons exprimer sur le méta-modèle que des propriétés
qui s’appliquent sur tous les modèles de procédé. Une propriété spécifique devra être
exprimée dans le modèle de procédé correspondant.
Les contraintes ajoutées ont été testées en utilisant l’outil OCLE5 afin de vérifier
et valider statiquement nos contraintes. Cet outil permet de valider la cohérence syntaxique de nos contraintes par rapport au méta-modèle (en particulier, la cohérence des
contraintes par rapport aux multiplicités des diagrammes). Notre choix s’est tourné
vers cet outil car il offre une ergonomie très avancée et permet la vérification statique
de contraintes aussi bien au niveau modèle que méta-modèle.
Malheureusement, si OCL est bien adapté pour exprimer des propriétés structurelles sur un modèle (ici un méta-modèle), il possède deux limites importantes.
La première est son incapacité à exprimer une sémantique opérationnelle puisqu’OCL est sans effet de bord. Ainsi, il n’est pas possible de décrire complètement la
sémantique de notre méta-modèle afin de permettre l’exécutabilité des modèles qui en
seront instances.
La seconde est l’expressivité limitée d’OCL sur un certain nombre de points. Prenons l’exemple de la propriété suivante : « Si l’on considère un arbre dont la racine
correspond à une phase et les nœuds aux itérations et activités qui composent réflexivement cette phase, l’ensemble des feuilles doivent être des activités ». Cette propriété
peut être traduite par deux invariants sur Iteration. Le premier indique que toutes itérations est effectivement décomposée (soit en itération, soit en activité). Le second
indique que la relation de décomposition itSubWork n’a pas de cycle, c’est-à-dire que
l’itération n’apparait pas dans sa décomposition (récursivement). Sachant que le modèle est fini, sa décomposition est aussi fini. Le premier invariant s’exprime simplement en OCL :
context Iteration inv :
(self.itSubWork→ size() + self.acSubWork→ size()) > 0
En revanche, le deuxième nécessite un opérateur de fermeture transitive qui n’est
pas offert par OCL. Il est donc nécessaire d’utiliser des extensions à ce langage telle
qu’OCL+ (Bodeveix et al., 2002) qui propose l’opérateur closure :
context Iteration inv :
Set{self}→ closure(i :Iteration | i.itSubWork)→ excludes(self)
Un autre manque d’OCL est la logique temporelle pour spécifier des contraintes
par rapport à un ou plusieurs enchaînements d’états souhaités ou interdits. Celle-ci est
prise en compte, entre autre, par TOCL (i.e. Temporal OCL) (Ziemann et al., 2002) et
OCL+.
5. http ://lci.cs.ubbcluj.ro/ocle/
144
LMO 2006
3.3. Démarche pour la formalisation d’un procédé
Le but d’un méta-procédé est de décrire comment construire un modèle de procédé
(Estublier, 2005). Sans offrir un méta-procédé complet, nous proposons une démarche
de formalisation associée à notre proposition de méta-modèle.
La description d’un procédé se fait à partir d’un ensemble de WorkDefinition très
général qui a pour objectif de décrire « grossièrement » les tâches à réaliser au cours
du procédé de développement et qui sont définies à partir d’une analyse de l’existant et des besoins. La démarche propose ensuite d’affiner par un processus itératif
la structure et la description du procédé de développement. Chaque WorkDefinition,
après avoir été sélectionnée à partir des définitions de travail déterminées initialement
ou issues d’une décomposition précédente, suit une succession d’étapes (ordre partiel)
au cours desquelles le modèle est complété (fig. 6). Ces étapes visent à décrire dans un
premier temps le WorkDefinition (type, rôle, préconditions, objectifs, produits) puis
à le structurer dans le cas où il s’agirait d’un WorkDefinition composite (Lifecycle,
Phase ou Iteration).
Figure 6. Démarche pour la formalisation d’un procédé
4. Application à une modélisation rigoureuse de procédés
Nous décrivons maintenant la modélisation réalisée avec la méthode MACAO. La
Méthode d’Analyse et de Conception d’Applications orientées-Objet (Crampes, 2002)
est une méthode complète de génie logiciel qui s’appuie sur UML. Actuellement enseignée dans plusieurs IUT et formations d’ingénieurs, elle commence à être adoptée
Modélisation rigoureuse en SPEM
145
par certaines SSII, en particulier Capgemini l’utilise sur le projet CARINS6 , dont le
maître d’ouvrage est la Direction des Lanceurs du CNES.
MACAO se base sur UP (Unified Process) et se place ainsi au même niveau que
le RUP (Rational Unified Process) proposé par IBM (Booch et al., 2003). Partant des
cas d’utilisation, MACAO offre une démarche itérative de conception-développement,
basée sur la réalisation de prototypes soumis aux utilisateurs pour validation (limitation des risques). MACAO propose une règle de non-régression des prototypes afin
de limiter les propagations de bugs liés à des modifications intempestives de prototypes déjà recettés. Enfin, MACAO insiste sur la spécification des IHM en proposant trois modèles d’IHM : le Schéma Navigationnel d’Interfaces (SNI) qui est raffiné
en Schéma d’Enchaînement des Fenêtres (SEF) pour les IHM de type fenêtre et le
Schéma d’Enchaînement des Pages (SEP) pour les IHM de type WEB. Des patrons
de conception de l’IHM s’appuyant sur le diagramme des classes métiers sont aussi
proposés.
L’ensemble de ces concepts sont définis dans un procédé de développement complet composé de quatre phases successives : l’analyse globale, la conception globale,
le développement et la finalisation (fig. 7). La phase de développement est elle-même
constituée d’un cycle de vie en spirale composé des phases de définition, de conception, de codage et d’intégration. La phase de béta-test se fait en parallèle avec la phase
de définition du prototype suivant. Chaque itération de ce cycle de vie donne lieu à
la création d’un prototype opérationnel recetté par le client. Cette démarche permet
d’avoir très rapidement un retour de la part des futurs utilisateurs et de pouvoir ainsi
rectifier très tôt les erreurs de conception.
4.1. Modélisation en SPEM de MACAO
L’ouvrage de référence (Crampes, 2002) fait explicitement ressortir la structure
hiérarchique du procédé. Il est ainsi facile de déterminer l’ensemble des phases, itérations, activités et étapes de MACAO. Sont également explicités les produits manipulés
au cours du procédé. Toutefois la méthode n’utilise pas la notion de discipline qui est
un élément essentiel de classification.
Aussi, en nous appuyant sur les travaux du laboratoire ICAR CNR (Cossentino et
al., 2003), nous avons associé une Discipline de même nom à chaque Phase (fig. 8,
partie gauche). Ceci ne permet pas une réelle classification des activités en fonction
de thèmes communs tel que cela est préconisé dans la sémantique de SPEM, mais
permet la modélisation de MACAO en SPEM. Une classification précise en fonction
de thèmes transversaux aux phases pourrait (et devrait) être envisagée pour affiner la
méthode MACAO.
Ce choix a des conséquences sur la modélisation de MACAO. En effet, comme
dans notre méta-modèle les rôles sont associés à des disciplines, nous ne pouvons plus
6. CAlcul de Réseaux en régime INStationnaire
146
LMO 2006
Figure 7. Procédé de développement MACAO
avoir un rôle inter-phase comme c’est le cas dans MACAO. Prenons l’exemple du
chef de projet qui a la responsabilité, entre autre, de valider chacune des phases. Ce
rôle doit donc être particularisé pour chaque espace de noms (Discipline) et nous obtenons donc les rôles AnalyseGlobale.valideur, ConceptionGlobale.valideur... Notons
que cette décomposition apparaît d’autant plus naturelle qu’il ne s’agit généralement
pas des mêmes compétences qui sont utilisées pour la validation de la phase d’analyse et celle de conception. La différence est encore plus nette pour la validation de
la phase de développement qui nécessite des compétences beaucoup plus techniques
que pour l’analyse qui nécessite principalement des compétences métiers.
Ces travaux préliminaires nous ont permis d’aborder facilement la méthode MACAO. Nous avons donc réalisé l’ensemble des modèles nécessaires pour une spécification cohérente et rigoureuse à l’aide de l’atelier Enterprise Architect7 . Un extrait
est donné figure 8. La partie gauche fait apparaître les disciplines et les rôles associés
sous la forme d’un diagramme de paquetage. La partie centrale (diagramme de cas
d’utilisation) correspond au cycle de vie principal. Enfin, la phase de développement
est décrite à droite à l’aide d’un diagramme d’activité, sous forme d’une itération. Par
manque de place, les autres modèles ont été omis.
7. http ://www.sparxsystems.com.au/.
Modélisation rigoureuse en SPEM
147
M2
<<instanceOf>>
<<instanceOf>> <<instanceOf>>
<<instanceOf>> <<instanceOf>><<instanceOf>>
M1
Figure 8. Modélisation en SPEM de MACAO
4.2. Formalisation des modèles de MACAO à l’aide d’OCL
En plus des propriétés exprimées sur le méta-modèle, il faut pouvoir exprimer les
propriétés spécifiques à un modèle de procédé particulier, en l’occurrence MACAO.
Nous avons utilisé pour cela des contraintes OCL mais nous retrouvons toutefois les
mêmes limites que pour le méta-modèle (section 3.2) : le manque d’expressivité principalement pour la sémantique opérationnelle (afin de pouvoir rendre totalement exécutable, et donc simulable, le modèle de procédé). Nous avons cependant rencontré
une difficulté supplémentaire. Il serait en effet souhaitable de disposer de l’introspection, c’est-à-dire de pouvoir accéder au concept du méta-modèle depuis les expressions OCL. Prenons un exemple concret. Nous souhaitons exprimer que, dans le cas
de MACAO, « les activités qui composent une phase (directement ou à travers des
itérations) doivent être classées dans la discipline de même nom ».
148
LMO 2006
Cette propriété pourrait être facilement appliquée au niveau du méta-modèle
comme un invariant de la méta-classe Phase. Cependant, cette propriété s’appliquerait
alors à tout modèle de procédé. Or cette propriété n’est vraie que pour MACAO en
raison du choix fait sur les disciplines. Il est donc nécessaire de l’exprimer au niveau
du modèle. Plutôt que d’exprimer cette contrainte sur chaque phase (analyse globale,
conception globale...), il serait plus judicieux de l’appliquer à chaque phase en faisant
référence à la méta-classe Phase. L’expression de cette contrainte nécessite donc de
pouvoir accéder aux éléments de modèles situés à différents niveaux d’abstraction : le
modèle (M1) et le méta-modèle (M2). Nous avons identifié d’autres besoins comme
manipuler des méta-éléments et des éléments dans la même contrainte, changer la
description d’un méta-élément à partir d’une instance, etc.
Pour valider les contraintes OCL, il est important de pouvoir les vérifier avant
l’exécution réelle du procédé pour détecter des anomalies. Cette validation nécessite de pouvoir jouer certains scénarios à l’aide d’un langage à effet de bord. Ceci
est impossible avec OCL. Aussi, nous avons utilisé l’outil USE (UML Specification
Environnement) (Richters et al., 2000) dont la tâche principale est de valider et de
vérifier la consistance d’un diagramme par rapport à des invariants et des pré- et postconditions en OCL. Il intègre ses propres commandes pour la génération de scénarios
(appelés snapshot dans l’outil). Notons que dans le cas d’un procédé, toutes les vérifications ne peuvent pas être faites avant l’exécution. Par exemple, comment garantir
a priori qu’une étape ne dépassera pas un certain délai alors que sa réalisation dépend
d’intervenants humains.
5. Conclusion
L’OMG a proposé SPEM pour la modélisation des procédés de développement.
Cependant cette spécification est très générale et peu directive. Aussi, nous en avons
proposé une spécialisation par restriction. Sans ajouter de nouveaux concepts, nous
avons précisé le sens d’un modèle SPEM en redéfinissant des relations sur le métamodèle d’une part et en définissant des contraintes au niveau du méta-modèle et du
modèle d’autre part. Cette restriction a été appliquée pour la formalisation de la méthode MACAO en suivant un méta-procédé expliquant comment construire les différents modèles. Pour saisir les modèles nous avons utilisé l’outil Enterprise Architect
sans pour autant spécialiser le profil SPEM qu’il propose. Spécialiser le profil permettrait à l’AGL de prendre en compte les précisions que nous avons faites.
Les contraintes OCL que nous avons exprimées au niveau du méta-modèle et des
modèles ont étaient vérifiées en utilisant les outils OCLE et USE. L’utilisation d’OCL
a mis en évidence certaines de ses limites, en particulier sur l’introspection, la transitivité et les propriétés temporelles. D’autre part, si OCL nous permet d’exprimer les
propriétés structurelles, il ne nous permet pas d’exprimer le comportement à l’exécution d’un procédé pourtant nécessaire pour animer un procédé et contrôler le développement réel. En conséquence, nous travaillons actuellement sur la possibilité de
Modélisation rigoureuse en SPEM
149
définir une sémantique opérationnelle pour SPEM et étudions pour cela les approches
existantes telles que Kermeta8 , Xion9 , xOCL10 ...
6. Bibliographie
Arkin A., Business Process Modeling Language, Business Process Management Initiative. novembre, 2002.
Bandinelli S., Fuggetta A., Lavazza L., Loi M., Picco G. P., « Modeling and Improving an
Industrial Software Process », IEEE Transactions on Software Engineering, vol. 21, n˚ 5,
p. 440-454, mai, 1995.
Belkhatir N., Estublier J., Melo W. L., « The ADELE-TEMPO experience : an environment
to support process modeling and enaction », Software Process Modelling and Technology,
Research Studies Press/John Wiley & Sons, p. 187-222, 1994.
Bendraou R., Gervais M.-P., Blanc X., « UML4SPM : A UML2.0-Based Metamodel for Software Process Modelling », MoDELS’05, vol. 3713, Springer-Verlag, p. 17-38, 2005.
Bodeveix J.-P., Millan T., Percebois C., Camus C. L., Bazex P., Feraud L., « Extending OCL
for verifying UML models consistency », UML’02, p. 75-90, 2002.
Booch G., Kroll P., Krutchten P., The Rational Unified Process Made Easy : A Practitioner’s
Guide to the RUP, Addison-Wesley Professional, avril, 2003.
Breton E., Contribution à la représentation de processus par des techniques de métamodélisation, PhD thesis, Université de Nantes, juin, 2002.
Breton E., Bézivin J., « Process-Centered Model Engineering », 5th IEEE International Enterprise Distributed Object Computing Conference, IEEE Computer Society, Seattle, Washington, USA, 2001.
Combemale B., « Spécification et Vérification de Modèles de Procédés de Développement »,
Master’s thesis, Université Toulouse II - INPT ENSEEIHT, Master SLCP, juin, 2005.
Conradi R., Hagaseth M., Larsen J.-O., Nguyên M. N., Munch B. P., Westby P. H., Weicheng
Z., Jaccheri L., Liu C., « Object-Oriented and Cooperative Process Modelling in EPOS »,
Software Process Modelling and Technology, Research Studies Press/John Wiley & Sons,
p. 33-70, 1994.
Cossentino M., Sabatucci L., Seidita V., SPEM description of the PASSI process rel. 0.3.6,
Technical report, ICAR CNR, décembre, 2003.
Crampes J.-B., Méthode orientée-objet intégrale MACAO, Démarche participative pour l’analyse,la conception et la réalisation de logiciels, Génie logiciel, ellipse edn, Technosup, décembre, 2002.
Crégut X., Coulette B., « PBOOL : an Object-Oriented Language for Definition and Reuse of
Enactable Processes », Software Concepts & Tools, juin, 1997.
Estublier J., « Software are Processes Too », Invited Paper at Software Process Workshop, Bejing, mai, 2005.
Miller J., Mukerji J., Model Driven Architecture 1.0.1 Guide, OMG, Inc. juin, 2003.
8. http://www.kermeta.org/
9. http://lglpc35.epfl.ch/objx/netsilon/xion/
10. http://xactium.com/
150
LMO 2006
OMG, Meta Object Facility (MOF) 1.4 Specification. avril, 2002.
OMG, Unified Modeling Language (UML) 1.4.2 Specification. juillet, 2004.
OMG, Software Process Engineering Metamodel (SPEM) 1.1. janvier, 2005a.
OMG, UML Object Constraint Language (OCL) 2.0 Specification. juin, 2005b.
Osterweil L. J., « Software Processes Are Software Too. », Proceedings of the 9th International
Conference on Software Engineering, Monterey, p. 2-13, mars, 1987.
Richters M., Gogolla M., « Validating UML Models and OCL Constraints », UML’00, vol. 1939
of LNCS, Springer Verlag, York, UK, p. 265-277, octobre, 2000.
WfMC, Process Definition interface – XML Process Definition Language v2.0. octobre, 2005.
Ziemann P., Gogolla M., « An Extension of OCL with Temporal Logic », in , J. Jürjens, , M. V.
Cengarle, , E. B. F. andBernhard Rumpe, , R. Sandner (eds), UML’02 workshop, Université
Technique de Munich, Institut d’Informatique, p. 53-62, 2002.
ANNEXE POUR LE SERVICE FABRICATION
A FOURNIR PAR LES AUTEURS AVEC UN EXEMPLAIRE PAPIER
DE LEUR ARTICLE ET LE COPYRIGHT SIGNE PAR COURRIER
LE FICHIER PDF CORRESPONDANT SERA ENVOYE PAR E-MAIL
1. A RTICLE POUR LES ACTES :
LMO 2006
2. AUTEURS :
Benoît Combemale* — Xavier Crégut* — Alain Caplain**
Bernard Coulette**
3. T ITRE DE L’ ARTICLE :
Modélisation rigoureuse en SPEM
de procédé de développement
4. T ITRE ABRÉGÉ POUR LE HAUT DE PAGE MOINS DE 40 SIGNES :
Modélisation rigoureuse en SPEM
5. DATE DE CETTE VERSION :
30 janvier 2006
6. C OORDONNÉES DES AUTEURS :
– adresse postale :
* Laboratoire IRIT-LYRE
2, rue Charles Camichel, BP 7122
F-31071 Toulouse Cedex 7
{benoit.combemale, xavier.cregut}@enseeiht.fr
** Laboratoire GRIMM-ISYCOM
5, allée Antonio Machado
F-31058 Toulouse Cedex 9
{caplain, coulette}@univ-tlse2.fr
– téléphone : 05 61 58 80 37
– télécopie : 05 61 58 83 06
– e-mail : [email protected]
7. L OGICIEL UTILISÉ POUR LA PRÉPARATION DE CET ARTICLE :
LATEX, avec le fichier de style article-hermes.cls,
version 1.2 du 03/03/2005.
8. F ORMULAIRE DE COPYRIGHT :
Retourner le formulaire de copyright signé par les auteurs, téléchargé sur :
http://www.revuesonline.com
S ERVICE ÉDITORIAL – H ERMES -L AVOISIER
14 rue de Provigny, F-94236 Cachan cedex
Tél : 01-47-40-67-67
E-mail : [email protected]