Extension possible à la méthodologie pour modéliser le proces-

La modélisation des éléments de processus externes peut conduire à des modèles qui ne sont pas conformes à leur métamodèle. En effet, comme les éléments de proces- sus externes sont modélisés indépendamment d’un processus, certains ne respectent pas toutes les contraintes imposées par leur métamodèle. Par exemple, le modèle de la figure4.8n’est pas conforme au métamodèle des diagrammes d’activité UML. En effet,

tous les flots de contrôle n’ont pas forcément à la fois une source et une cible, alors que le métamodèle des diagrammes d’activité UML l’impose. Puisque certains modeleurs de processus (par exemple, SPEM-Designer10) ne permettent pas de modéliser des éléments de processus invalides, l’application de la méthodologie que nous proposons pour définir le modèle de processus de base peut se révéler difficile. Nous proposons donc d’utiliser des approches (par exemple [RBJ07]) permettant de générer des élé- ments de modèles en fonction de contraintes prédéfinies afin de gérer ce cas. Il serait ainsi possible de générer les éléments de modèles que les modeleurs ne permettent pas de modéliser, et également de générer les éléments de modèles manquants pour les rendre valides. Ces éléments de modèle générés ne seraient bien entendu pas utilisés pour dériver des processus de la ligne de processus.

4.4

Synthèse

Nous avons proposé dans ce chapitre une approche permettant de gérer la varia- bilité des processus de développement logiciel en fonction des exigences des projets, et ce quel que soit le langage de modélisation de processus utilisé pour peu qu’il se conforme au MOF. Notre approche s’appuie sur CVL afin de spécifier et de résoudre la variabilité dans les processus. Nous avons fait le choix de CVL car il préserve la sépa- ration des préoccupations entre l’aspect gestion de la variabilité et l’aspect métier dont on souhaite gérer la variabilité. Il est donc possible de réutiliser les concepts et outils spécifiques à ces aspects, sans qu’ils soient impactés par des préoccupations externes. D’autre part, bien que CVL permette actuellement de dériver des modèles résolus invalides, il existe des solutions permettant de prévenir ce problème. Ces solutions ont également l’avantage de préserver l’indépendance vis-à-vis du domaine métier dont la variabilité est gérée. De plus, CVL permet de définir en intention les différents processus d’une famille. Il permet en effet, dans le modèle de processus de base, de ne définir qu’une seule fois les éléments de processus communs à plusieurs processus, et il fournit des mécanismes permettant d’intégrer ces éléments à un processus au mo- ment de la dérivation. Cela facilite la maintenance d’une famille de processus puisque les redondances entre les différents processus sont évitées. Cela facilite également la réutilisation des fragments de processus communs à plusieurs processus d’une famille. D’autre part, notre approche préserve la séparation entre exigences et processus et elle permet de refléter directement la variabilité des exigences sur les processus, plutôt que de passer par une couche intermédiaire définissant la variabilité des processus. Enfin, la méthodologie que nous proposons pour définir le modèle de processus de base a l’avantage d’expliciter le processus d’une famille qui est le plus souvent utilisé.

Création de composants

d’automatisation réutilisables

Nous avons vu au début de cette partie que la réutilisation des CA (Composants d’Automatisation, c’est-à-dire composants logiciels automatisant des TMR) était réa- lisée via la réutilisation des processus de développement logiciel auxquels ces CA sont liés. Chaque CA peut être lié à des processus différents ou à des unités de tra- vail différentes d’un même processus, constituant ainsi des cas d’utilisation différents d’un CA. Nous présentons donc dans ce chapitre notre méthodologie fournissant un support à la création de CA réutilisables à travers tous leurs cas d’utilisation. Nous commençons par introduire, dans la section5.1, l’exemple dont nous nous servirons pour illustrer cette méthodologie, qui est elle-même détaillée dans la section5.2. Nous discutons cette méthodologie dans la section5.3et nous en faisons la synthèse dans la section5.4.

Les travaux présentés dans ce chapitre ont fait l’objet d’une publication : Emmanuelle Rouillé, Benoît Combemale, Olivier Barais, Da- vid Touzet and Jean-Marc Jézéquel. Improving Reusability in Software Process Lines. In Proceedings of the 39th Euromicro Conference on Software Engineering and Advanced Applications, SEAA ’13, pages 90-94, 2013 [RCB+13a].

5.1

Exemple illustratif : automatisation de la configuration de

l’espace de travail local d’un développeur

Nous présentons dans cette section l’exemple dont nous nous servirons pour illus- trer la méthodologie fournissant un support à la création de CA réutilisables. Il s’agit d’un script PowerShell qui automatise la configuration de l’espace de travail local d’un

développeur. Ce script est utilisé pendant les projets de développement Java de l’en- treprise Sodifrance. Il est exécuté au début de l’activité de développement par chaque développeur du projet. Il est également exécuté à chaque fois qu’un nouveau déve- loppeur intègre un projet de développement Java dont l’activité de développement est déjà commencée. La figure5.1 montre un extrait de ce script PowerShell, sur lequel notre méthodologie n’a pas encore été appliquée (c’est-à-dire que le script est configuré pour être utilisé avec un projet particulier). Il prend en paramètre (ligne 1) le chemin de l’espace de travail local d’un développeur (wsPath), ainsi que les URL des dépôts contenant le code source de l’application en cours de développement (sourceUrl) et le code de build (buildUrl). Le code de build correspond à des ressources, autres que le code source, utiles à la configuration de l’espace de travail local d’un développeur. Le script automatise les étapes suivantes :

1. import, en utilisant SVN, du code source (ligne 10) et du code de build (ligne 13), 2. compilation Maven des projets Java et alimentation initiale du dépôt Maven local

si nécessaire (ligne 18),

3. configuration Maven des projets Eclipse (ligne 19),

4. configuration Maven de l’espace de travail Eclipse (ligne 20),

5. import Buckminster des projets dans l’espace de travail Eclipse (à partir de la ligne 23).