Software Process Engineering Metamodel (SPEM)

SPEM est une norme de l’OMG dédiée à la description de procédés logiciels. SPEM propose un méta-modèle de langage de description de procédés basé sur UML. À ce jour, SPEM supporte la définition de modèles de procédé mais pas l’exécution de ces modèles.

Issu des travaux de l’OMG, SPEM s’inscrit doublement dans l’organisation de la pile de modélisation du MDA (Model Driven Architecture) : comme méta-modèle conforme au MOF (Meta Object Facility), et comme extension d’UML sous la forme d’un profil. Étant un méta-modèle MOF, SPEM peut étendre le méta-méta-modèle UML en ajoutant librement les concepts dédiés aux procédés logiciels. Étant un profil UML, SPEM peut profiter des notations standardisées et des diagrammes expressifs de UML sans redéfinir la syntaxe concrète.

Le modèle conceptuel de SPEM repose sur l’idée 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 I-19). Ce modèle conceptuel est la base du méta-modèle de SPEM.

Figure I-19. Modèle conceptuel de SPEM

La spécification de SPEM actuellement disponible est la version 1.1 de 2005 [SPEM05] et fait suite à la toute première version publiée en 2002. Une proposition pour la version 2.0 de SPEM [SPEM07] est en cours d’étude. Nous nous intéressons aux deux versions de SPEM, car la version 1.1 offre la standardisation alors que la nouvelle version intègre le concept de patron de procédé.

SPEM 1.1

SPEM 1.1 est structurée en deux paquetages : SPEM-Foundation qui est une extension d’un sous-ensemble d’UML 1.4 fournissant les concepts de base pour définir le méta-modèle SPEM, et SPEM-Extension qui décrit des concepts de base pour décrire les procédés logiciels. La Figure I-20 montre le méta-modèle de SPEM1.1.

Le concept central de SPEM 1.1 est WorkDefinition, une unité de travail de procédé réalisée par un responsable (ProcessPerformer) pour produire ou modifier des artéfacts (WorkProduct). Role * performs 1 * 1 isResponsibleFor * * Input uses * * Output produces Activity WorkProduct

Figure I-20. Méta-modèle de SPEM1.1 [SPEM05]

L’exécution d’une WorkDefinition ne peut commencer que quand ses pré-conditions (Precondition) sont remplies ; cette exécution doit satisfaire des objectifs (Goal), qui peuvent être vus comme des post-conditions de WorkDefinition. Ce concept est spécialisé en plusieurs sous-classes concrètes pour représenter des tâches de différentes granularités.

Une activité (Activity) est une spécialisation de WorkDefinition qui peut être assignée à

un rôle individuel (ProcessRole)1. Une activité peut être décomposée en plusieurs étapes

élémentaires (Step) définies dans le contexte de l’activité. Les autres spécialisations de WorkDefinition sont la phase (Phase), l’itération (Iteration) et le cycle de vie (Lifecycle).

SPEM 1.1 supporte l’organisation modulaire et la réutilisation de procédés via le concept de composant de procédé (ProcessComponent), qui est spécialisé en discipline (Discipline) et procédé (Process). Une discipline regroupe des activités ayant le même thème. Un procédé est considéré comme un composant de procédé autonome contenant un ensemble de WorkDefinition et est gouverné par un cycle de vie.

1 Ce concept se distingue de ProcessPerformer, une sorte de rôle abstrait responsable d’un ensemble de WorkDefinitions

+steps _{+governingLifecycle} precedes +parentWork +subWork {ordered} +feature + ^governed Processs +owner impacts {odered} +behavioralFeature +parameter 1 1 1 1 0..n 0..n 0..n 0..1 0..n 0..n 0..1 0..n 0..n 0..1 0..1 +type 1 +typedParameter +namespace 0..1 0..n +guidance 0..n 1 +ownedElement +annotatedElement ProcessRole ProcessPerformer Constraint body ModelElement WorkProduct isDeliverable Information Element Step Classifier Goal Precondition GeneralizableElement Package Discipline Guidance Namespace BehavioralFeature ActivityParameter hasWorkPerArtifact ProcessComponent WorkDefinition Process Feature

Activity Iteration Phase Lifecycle Parameter

SPEM 2.0

SPEM 1.1 a plusieurs points faibles, l’un d’eux étant l’insuffisance de flexibilité et de support de la réutilisation. Pour remédier à ces inconvénients, ainsi que pour aligner SPEM avec UML 2.0, l’appel pour une nouvelle version a été lancé en 2004 [SPEM04]. Nous présentons ici la proposition SPEM 2.0 d’IBM [SPEM07] en cours d’évaluation.

SPEM 2.0 applique le mécanisme de fusion de paquetage (package merge) de l'infrastructure d'UML 2.0 pour définir progressivement le méta-modèle. De plus, SPEM 2.0 fournit le mécanisme de «plug-in» pour faciliter l’extensibilité et la variabilité de procédés. Cela augmente considérablement la flexibilité de SPEM 2.0.

SPEM 2.0 sépare le contenu réutilisable d’une méthode de développement de son application dans les procédés. Le contenu d’un élément de méthode (MethodContent) fournit des explications décrivant la réalisation des buts spécifiques du développement de façon indépendante d’un cycle de vie concret. Un procédé, représenté par une activité (Activity), prend ces éléments de contenu de méthode et les relient selon l’ordre d’exécution adapté aux besoins d’un type de projet spécifique. Cela permet à SPEM 2.0 de mieux supporter la réutilisation de procédés.

SPEM 2.0 propose d’une part la notion de composant de procédé (ProcessComponent) remplaçable et réutilisable selon le principe de l’encapsulation (composant boite noire), d’autre part le concept de patron de procédé (ProcessPattern) pour la capitalisation des bonnes pratiques et l’assemblage rapide de nouveaux procédés. Nous nous intéressons en particulier au concept de patron de procédé de SPEM 2.0.

SPEM 2.0 ne définit pas de concepts spécialisés pour représenter les patrons de procédé. Un patron de procédé de SPEM 2.0 est simplement un procédé particulier qui décrit un ensemble d’activités réutilisables fournissant une solution de développement à un problème commun. Un patron est donc représenté comme un procédé ayant le type ProcessPattern.

La Figure I-21 montre un extrait du méta-modèle de SPEM 2.0 définissant le concept de patron de procédé.

Figure I-21. Extrait du méta-modèle de SPEM 2.0 (paquetage ProcessWithMethod)

ProcessElement

ProcessKind

DeliveryProcess ProcessPattern Process Planning Template ActivityKind

Process

Activity

BreakdownElement

III.3.5. Bilan

Tous les formalismes présentés ci-dessus considèrent un patron de procédé comme un ensemble d’activités de développement réutilisables. Ils sont tous liés à UML mais à différents niveaux : PROPEL, PROMENADE et SPEM sont des extensions du méta-modèle UML ; LivingProcess Framework préconise simplement d’utiliser les notations UML pour représenter l’aspect dynamique des procédés.

Parmi ces formalismes, PROPEL est le seul dédié au concept de patron de procédé. Ses avantages sont la description de la structure interne d’un patron et la définition des relations entre patrons. Un des points forts de PROMENADE est de rendre les patrons de procédé plus génériques en les définissant en tant que modèles de procédé paramétrés. L’avantage de Living Process Framework est la spécification flexible de produits qui permet un assemblage possible de patrons hétérogènes.

L’avantage de SPEM 1.1 est sans conteste le méta-modèle standardisé dédié aux procédés logiciels. Cependant, SPEM 1.0 n’intègre pas le concept de patron de procédé. SPEM 2.0 propose un méta-modèle générique et flexible qui couvre divers types de procédés. Il ne met pas l’accent spécialement sur le concept de patron de procédé, mais fournit les concepts et les mécanismes généraux pour réutiliser les procédés en séparant les méthodes et leurs applications dans les procédés.