1

Chapitre 7 : Construction de méthodes par composition

Jolita Ralyté, Rébecca Deneckère et Y. Jamoussi

Ce chapitre fait un état de l’art des différentes approches d’ingénierie de méthodes à base de composants réutilisables. Il introduit les différentes stratégies de composition proposées dans cet ouvrage. Les stratégies répertoriées sont intégrées dans un modèle générique d’ingénierie de méthodes à partir des composants.

La section suivante survole les travaux réalisés dans le domaine de l’ingénierie des méthodes situationnelles et propose une classification des approches proposées. La section 7.2 propose un modèle de processus générique pour la construction des méthodes par composition. Trois stratégies de ce modèle, par assemblage, par extension et par évolution, sont présentées et illustrées respectivement dans les sections 7.3, 7.4 et 7.5. Finalement, la section 7.6 résume ce chapitre.

7.1 Typologie des approches de construction de méthodes

Une des préoccupations majeures de la discipline d’ingénierie de méthodes (IM) consiste à proposer des approches et des outils pour la construction de nouvelles méthodes et l’adaptation des méthodes existantes. Les nombreux travaux proposés dans ce domaine offrent des techniques de construction de méthodes ayant des objectifs très variés : satisfaire les situations spécifiques des projets [Harmsen94, Harmsen97, Kumar92], adapter des méthodes existantes à des nouvelles conditions [Tolvanen98], les corriger ou les améliorer sur la base des expériences de leur utilisation dans divers projets [Tolvanen98], étendre des méthodes existantes avec des nouveaux concepts et propriétés [Denequère01], etc. En outre, les approches plus génériques proposent des métamodèles et des patrons de construction de méthodes génériques applicables dans différences techniques d’ingénierie de méthodes [Prakash02, Rolland96a, Rolland96b].

Sur la base de l’analyse de la littérature existante en la matière nous proposons une classification des approches d’IM en quatre catégories : Ad-Hoc, Par évolution, Par extension et Par assemblage, comme l’indique la Figure 1.

Figure 1. Typologie des approches d’ingénierie de méthodes par composition

Les approches Ad-Hoc correspondent à la construction de méthodes ‘à partir de rien’ et de manière intuitive. Le processus de construction est généralement basé sur la capitalisation de l'expérience acquise lors des développements de différents systèmes pour un domaine spécifique. L’apparition d’un domaine d’application nouveau est un autre exemple qui peut conduire à prendre la décision de construire une méthode entièrement nouvelle. Cette approche, très répandue à la naissance de la discipline de l’ingénierie des méthodes, est généralement remplacée par des approches plus formelles et plus systématiques.

Les approches d’ingénierie de méthodes Par évolution [Ralyté05, Ben Ayed05] visent à construire de nouvelles méthodes sur la base des méthodes, modèles ou métamodèles existants. Le modèle ou

2

métamodèle de départ est appelé un modèle paradigme ou modèle As-Is. Le processus de construction de nouvelles méthodes consiste à transformer celui-ci en un modèle souhaité appelé le modèle To-Be. Plusieurs types de transformation sont possibles. Par instanciation d’un modèle As-Is on obtient un nouveau modèle de niveau d’abstraction plus bas [Gupta01] et inversement, l’abstraction du modèle As-Is [Ralyté05, Ben Ayed05] permet d’obtenir un modèle To-Be plus abstrait. Le modèle As-Is peut également être adapté [Tolvanen98] en fonction de l’expérience d’utilisation de ce modèle dans différents projets et selon l’objectif de l’ingénierie de méthodes en cours. Dans le cas d’une adaptation, les modèles As-Is and To-Be sont au même niveau d’abstraction tandis que dans le cas d’une abstraction ou d’une instanciation ces deux modèles se présentent dans les niveaux d’abstraction différents.

Les approches d’ingénierie de méthodes Par extension proposent différents types d’extensions à réaliser sur une méthode existante. Leur objectif est d’enrichir une méthode existante avec des nouveaux concepts et / ou nouvelles propriétés [Deneckere02]. Par exemple, un modèle statique comme celui destiné à la construction d’un schéma E/R pourrait être étendu avec de nouveaux concepts permettant de représenter les classes d’acteurs intervenant dans le système à définir. Cette approche permet donc d’étendre une méthode existant préalablement pour lui permettre de prendre en compte de nouveaux concepts. La connaissance développée pour chaque extension est encapsulée dans un composant réutilisable appelé patron d’extension, stocké dans une bibliothèque de patrons. Ces patrons sont ensuite organisés dans un méta-patron d’extension spécifique à un domaine donné pour permettre à l’ingénieur de méthode d’être guidé lors de l’extension qu’il souhaite réaliser. L’ingénieur à donc la possibilité d’exécuter le patron de son choix pour réaliser une extension particulière ou de dérouler le méta-patron correspondant à un domaine particulier pour adapter sa méthode à ce besoin d’extension.

Finalement, les approches d’ingénierie de méthodes Par assemblage proposent de construire de nouvelles méthodes ou d’enrichir des méthodes existantes en réutilisant des parties de méthodes existantes. Le concept de base de ces approches est un composant réutilisable de méthode présenté au chapitre 4 de ce livre. Les approches par assemblage consistent à définir les besoins méthodologiques pour une situation du projet en cours, à sélectionner les composants de méthodes satisfaisant ces besoins et à assembler les composants sélectionnés. Deux types d’assemblages, association et intégration [Ralyté01a], peuvent être appliqués sur les composants sélectionnés. L’association concerne l’assemblage des composants ayant des objectifs différents et complémentaires dans le cycle de développement d’un système. Quant à l’intégration, elle est utilisée pour assembler les composants ayant le même objectif mais proposant des manières déférentes pour les atteindre. Les approches par assemblage nécessitent une base de composants réutilisables de méthodes construite préalablement. La notion de la base de composants de méthodes est présentée au chapitre 5 de ce livre.

7.2 Modèle de processus générique pour l’ingénierie de méthodes par composition

Les approches d’ingénierie de méthodes introduites à la section précédente ont un objectif commun : aider à construire une méthode la plus adaptée à la situation en cours en réutilisant les méthodes ou les parties de méthodes existantes. Chacune de ces approches propose une démarche méthodologique différente pour atteindre cet objectif. Le modèle de processus générique pour l’ingénierie de méthodes par composition regroupe toutes ces démarches dans un unique processus modélisé au moyen du formalisme MAP (voir le chapitre 3 de ce livre). La carte de plus haut niveau de l'approche générique met en évidence les intentions génériques d'ingénierie ; c'est-à-dire celles qui sont présentes dans toute démarche d'ingénierie de méthodes quelle que soit sa spécificité. Elle identifie des stratégies possibles pour atteindre ces intentions. Le recensement des stratégies n'est pas exhaustif mais le formalisme MAP permet d'en ajouter de nouvelles chaque fois qu'on le souhaite. L'approche générique est donc en perpétuelle adaptation. Par ailleurs, la sélection d'une démarche adaptée au cas spécifique d'un projet n'est pas simple et il est important d'aider l'ingénieur de méthodes à choisir celle qui correspond le mieux au profil du projet

3

qu'il traite. Cet objectif est réalisé en complétant la carte MAP par un ensemble de directives méthodologiques.

Enfin, dans certains cas il semble approprié de combiner plusieurs démarches d'ingénierie. Le choix de la représentation par MAP permet de guider l'ingénieur de méthodes dans la pratique d'une combinaison des différentes approches d’ingénierie de méthodes.

Pour résumer, l’objectif du modèle générique est triple :

• Intégrer dans un processus unique différentes approches d’ingénierie de méthodes par composition ;

• Guider les ingénieurs de méthode dans la sélection de l'approche la plus appropriée à la situation du projet en cours ;

• Permettre la combinaison de différentes approches d’ingénierie de méthodes.

7.2.1 La carte générique

L’approche générique d’ingénierie de méthodes par composition est synthétisée par la carte de la Figure 2, aussi appelée la carte générique. On considère ici que tout processus d’ingénierie de méthodes est basé sur deux activités principales : (1) la définition de l’objectif d’ingénierie de méthodes et (2) la construction d’une méthode permettant d’atteindre cet objectif. Dans la carte générique ces activités sont représentées par deux intentions génériques :

1. Définir l’objectif d’ingénierie de méthode

2. Construire une méthode

La première intention correspond à l'élucidation par l'ingénieur de méthodes du but qu'il fixe à l'approche d’ingénierie de méthodes. La seconde permet de construire une méthode qui correspond à ce but. Ces intentions sont les nœuds de la carte présentée à la Figure 2.

Figure 2. Processus générique de l’ingénierie de méthodes par composition

Comme le montre la Figure 2, le formalisme MAP permet de représenter plusieurs stratégies d'atteinte des deux buts. Par exemple, il y a deux stratégies pour atteindre la première intention, la stratégie A base de méthodes qui est applicable lorsque l'ingénieur est dans une situation de recherche d'adaptation d'une méthode connue et la stratégie From scratch lorsqu'il part 'de rien'. La sélection d’une des deux stratégies dépend de la situation du projet en cours. Si l’ingénieur de méthodes

4

considère qu’une méthode habituelle est appropriée pour le projet en cours mais nécessite une certaine adaptation il est conseillé d’appliquer la stratégie A base de méthodes. Tandis que, s’il est convaincu qu’aucune méthode disponible n’est adéquate pour le projet en question, et qu’il est nécessaire de construire une nouvelle méthode, il va choisir la stratégie From scratch.

Les trois stratégies qui permettent d'atteindre l'intention Construire une méthode correspondent à trois démarches d’ingénierie de méthodes déjà expérimentées dans des projets différents. La stratégie Par assemblage permet de construire une nouvelle méthode ou d’enrichir une méthode existante par assemblage de composants de méthodes stockés dans une base de méthodes [Ralyté01]. La stratégie Par extension consiste à étendre une méthode existante en appliquant des patrons d'extension [Deneckere98, Deneckere01]. Enfin, la stratégie Par évolution correspond à la réingénierie d'une méthode existante [Rolland02, Ben Ayed05]. Une nouvelle méthode est obtenue par abstraction d’un modèle ou instanciation d’un métamodèle.

Comme on l'imagine, la carte peut facilement être étendue par de nouvelles stratégies ajoutées au fur et à mesure de leur découverte.

Une fois la méthode construite, il est important de la valider. Pour cette raison, la carte générique propose la stratégie de Validation qui intègre différentes techniques de validation de méthodes.

Les sections suivantes de ce chapitre décrivent et illustre les trois stratégies de construction de méthodes, c’est à dire les stratégies par assemblage, par extension et par évolution.

7.2.2 Opérateurs d’ingénierie de méthodes par composition

Chaque approche d’ingénierie de méthodes intégrées dans l’approche générique est basée sur un ensemble d’opérateurs. Ce paragraphe présente une typologie des opérateurs générique d’IM et introduit un cadre de référence (Figure 3) pour la définition des opérateurs spécifiques à partir des opérateurs génériques ainsi que leur application.

Figure 3. Cadre de référence d'application des opérateurs génériques d'ingénierie de méthodes

Comme le montre la Figure 3, les opérateurs spécifiques de chaque approche d’IM sont obtenus par instanciation des opérateurs génériques en prenant en compte les besoins de l’approche d’IM sélectionnée. Ces opérateurs sont ensuite appliqués par le processus d’IM spécifique pour transformer un ou plusieurs modèles As-Is en un nouveau modèle To-Be. Dans les approches d’IM Par évolution il n’y a qu’un seul modèle As-Is tandis que dans les approches Par assemblage et Par extension deux ou plus modèles As-Is sont utilisés pour aboutir à un modèle To-Be.

5

Les opérateurs génériques sont appliqués sur les éléments génériques qui composent tout modèle participant au processus d’IM. Ces éléments sont définis dans le métamodèle générique d’IM, illustré à la Figure 4. Ce métamodèle a été créé pour mettre l’accent sur les différentes caractéristiques des modèles participant à l’activité de l’IM et également pour permettre l’identification des opérations fondamentales de construction et transformation qui pourraient être exécutées sur un modèle.

Figure 4. Métamodèle pour l'Ingénierie de Méthodes

Comme le montre la Figure 4, chaque modèle est composé d’Eléments. Chaque élément a un Nom et est décrit par un ensemble de Propriétés. Dans un modèle E/R par exemple, « Entité type », « Attribut », « Relation type » ainsi que la relation « Est-un » sont des Eléments tandis que le « Domaine » d’un « Attribut » est considéré comme une Propriété.

La relation Est-un entre les éléments signifie qu’un élément peut hériter des propriétés d’un autre élément. Les éléments sont classés en Simples et Composés. Un Elément Composé est une agrégation d’autres éléments simples ou composés tandis qu’un Elément Simple n’est pas décomposable. Par exemple, dans le modèle E/R une « Entité type » est un élément composé d’« Attribut » qui sont des éléments simples.

Le fait qu’un élément puisse faire partie de plusieurs modèles requiert l’introduction dans le métamodèle d’IM d’un concept nommé Elément de Modèle représentant le lien entre un élément et un modèle auquel il appartient. Par exemple, le concept « Scénario » existe dans le modèle L’Ecritoire [Rolland98b,c] et le modèle des Cas d’Utilisation [Jacobson92]. Lors du processus d’intégration des deux modèles mentionnés, il est important de connaître l’origine du « Scénario » que l’on est en train de manipuler car malgré le même nom la structure du « Scénario » varie d’un modèle à l’autre.

Le concept Elément de Modèle est également nécessaire pour la modélisation des relations entre les éléments des différents modèles. Selon le métamodèle de la Figure 4, il y a trois types de liens :

• le lien Abstraction de représente le fait qu’un élément d’un modèle peut représenter une Abstraction d’un élément appartenant à un autre modèle ;

• le lien Instance de représente le fait qu’un élément peut être obtenu par instanciation d’un élément appartenant à un autre modèle ;

• le lien Connexion est nécessaire pour connecter les éléments des différents modèles pour assembler ou étendre les modèles. Trois types de Connexion sont définies dans le métamodèle : Association, Composition et Est-un.

Tous les principaux concepts définis dans le métamodèle d’IM, c’est-à-dire Elément, Elément composé, Propriété et Elément de modèle, sont sujets aux changements durant le processus d’IM. Ces changements sont classés en trois catégories : changements de noms, changements d’éléments, changements structurels.

6

• Le changement du nom d’un élément est possible grâce à l’opérateur Renommer. Celui-ci s’appuie sur le glossaire de termes d’un domaine de modélisation et utilise les relations de synonymie, d’hyponymie et autres relations similaires entre les termes pour changer le nom d’un concept.

• Le changement d’élément concerne l’élément lui-même, son contenu, sa structure. Modification du « Domaine » d’un « Attribut » dans une « Entité type » est un exemple d’un tel changement. Trois opérateurs génériques, Modifier, Attribuer et Retirer, sont définis pour spécifier les changements d’élément.

• Les changements structurels sont les plus importants car ils représentent les modifications portées sur un ensemble d’éléments qui composent un modèle. Nous distinguons deux types de changements structurels :

− Les changements internes au modèle concernent les éléments d’un modèle donné. Il y en a onze : Ajouter, Supprimer, Fusionner, Fractionner, Remplacer, Généraliser, Spécialiser, Ajouter Composant, Supprimer Composant, Déplacer Composant. Par exemple, l’addition d’une nouvelle « Entité type » dans le modèle de produit To-Be par rapport au modèle As-Is est un exemple d’un tel changement, la fusion de deux étapes d’un modèle de processus As-Is dans le modèle de processus To-Be en est un autre.

− Les changements entre modèles consistent à établir des relations entre les éléments des différents modèles. Nous en définissons six : Connecter via spécialisation, Connecter via généralisation, Connecter via décomposition, Connecter via agrégation, Connecter via fusion et Connecter via association. Par exemple, la définition d’un ensemble ordonné de « Fragments de Besoins » de la méthode L’Ecritoire [Rolland98b,c] comme étant une spécialisation du concept « Cas d’Utilisation » provenant du modèle des Cas d’Utilisation [Jacobson92] représente une connexion entre les deux modèles.

Tous les opérateurs génériques sont résumés dans la Table 1.

Table 1. Les opérateurs génériques pour l’ingénierie de méthodes

Objet Opérateur Description

Elément Renommer Change le nom d’un élément.

Ajouter Ajoute un nouvel élément dans un modèle.

Supprimer Supprime un élément d’un modèle.

Fusionner Deux éléments distincts deviennent un seul élément.

Fractionner Un élément est décomposé en deux nouveaux éléments.

Remplacer Un élément est remplacé par un autre élément.

Généraliser Un élément est crée comme une généralisation de deux éléments.

Spécialiser Spécialise un élément en deux éléments plus spécifiques.

Elément composé

Ajouter composant Ajoute un composant dans un élément composé.

Supprimer composant Supprime un composant d’un élément composé.

Déplacer composant Un composant est repositionné dans la structure d’un élément composé.

Propriété Attribuer Ajoute une propriété à un élément.

Retirer Retire une propriété d’un élément.

Modifier Modifie la propriété d’un élément.

Retyper Change le type d’un élément.

Elément de modèle

Instancier Un élément du modèle To-Be est obtenu par instanciation d’un élément du modèle As-Is.

7

Abstraire Un élément du modèle To-Be est une abstraction d’un élément du modèle As-Is.

Connecter via spécialisation

Définit un élément d’un modèle comme une spécialisation d’un élément appartenant à un autre modèle. Le lien Est-un est créé entre les deux éléments.

Connecter via généralisation

Deux éléments appartenant aux modèles As-Is différents sont généralisés en un élément plus abstrait dans le modèle To-Be.

Connecter via composition

Un élément composé est créé dans le modèle To-Be à partir des éléments de différents modèles As-Is.

Connecter via décomposition

Un élément est considéré comme un composant d’un élément d’un autre modèle.

Connecter via association

Une association est créée entre deux éléments appartenant aux modèles différents.

Connecter via fusion Deux éléments similaires provenant des modèles As-Is différents deviennent un élément unique dans le modèle To-Be.

La typologie des opérateurs génériques d’IM offre plusieurs avantages :

• Elle sert de guide dans la définition des opérateurs pour une approche d’IM spécifique. Les opérateurs spécifiques sont obtenus par instanciation des opérateurs génériques.

• La complétude d’une typologie spécifique est assurée par celle de la typologie générique.

• Les typologies spécifiques sont consistantes entre elles car elles sont générées à partir du même moule ce qui est important si plusieurs typologies sont utilisées dans la même approche d’IM ou plusieurs approches d’IM sont combinées ensemble.

7.3 Construction de méthodes par d’assemblage de composants

L’objectif de l’approche d’ingénierie de méthodes situationnelles par assemblage de composants réutilisables est d’aider à la construction d’une méthode ‘à la volée’ satisfaisant le mieux possible la situation du projet en cours. Une telle approche doit :

• Guider l’ingénieur de méthodes dans la définition des besoins méthodologiques pour un projet spécifique.

• Aider l’ingénieur de méthodes à sélectionner les composants satisfaisant ces besoins.

• Aider l’ingénieur de méthodes à assembler les composants sélectionnés afin de construire une nouvelle méthode ou d’adapter une méthode existante.

7.3.1 Typologies d’assemblage

L’analyse des approches d’ingénierie de méthodes situationnelles proposées dans la littérature montre que l’assemblage des composants de méthodes est considéré comme un moyen rapide pour la construction des méthodes correspondant aux besoins spécifiques de chaque projet SI. Cependant, la plupart de tentatives de définition des processus d’assemblage [Brinkemper98, Punter96, Song95, Wistrand04] se limitent à l’assemblage des composants représentant des activités indépendantes dans le développement d’un SI. Il nous semble qu’il est également judicieux d’assembler des composants ayant le même objectif dans le processus d’ingénierie d’un SI mais proposant des stratégies différentes pour l’atteindre. Par conséquent, nous pouvons distinguer deux techniques d’assemblage :

1. assemblage par association et

2. assemblage par intégration.

8

Le processus d’assemblage par association est appliqué sur des composants qui n’ont pas d’éléments communs ni dans leurs modèles de produit ni dans leurs modèles de processus. Il est donc basé sur l’identification des liens ou des concepts permettant de faire la connexion entre les modèles de produits des deux composants et de déterminer l’ordre d’exécution de leurs modèles de processus. En général dans ce cas, le produit résultat de l’application du premier composant est utilisé ensuite en tant que produit source dans le deuxième composant. Par exemple, le composant qui produit le modèle des cas d'utilisation et le composant qui produit le schéma objet du système n'ont aucun élément commun. En assemblant ces deux composants on obtient une méthode dans laquelle le deuxième composant utilise le résultat obtenu en appliquant le premier.

Le processus d’assemblage suivant la technique d’intégration permet d’assembler des composants qui se recouvrent partiellement : qui ont des concepts similaires dans leurs parties de produit et des intentions similaires dans leurs modèles de processus. Il consiste à fusionner les éléments communs des modèles de produits des composants ainsi que ceux de leurs modèles de processus. Par exemple, le composant qui produit le modèle des cas d'utilisation selon [Jacobson92] pourrait être enrichi par des directives d’écriture des scénarios et d’identification des buts définies dans les composants de la méthode L’Ecritoire [Rolland98b,c].

Nous avons aussi remarqué que la plupart des approches d’assemblage [Brinkkemper99, Punter96] considèrent uniquement le cas de la construction d’une nouvelle méthode. Nous avons constaté que l’adaptation (l’extension, la complétude, la configuration) [Ralyté01] d’une méthode existante peut également être réalisée en appliquant la même technique d’assemblage.

7.3.2 Opérateurs d’assemblage

Les deux techniques d’assemblage introduites dans la section précédente utilisent des opérateurs d’assemblage des modèles de produit et de processus [Ralyté99a, Ralyté01] qui peuvent être obtenus par instanciation de la typologie des opérateurs génériques d’IM présentés à la section 7.2.2.

La Table 2 présente les opérateurs pour l’assemblage des modèles de processus sous forme de cartes (MAP). Etant donné que les éléments de base dans le modèle MAP sont Intention, Stratégie et Section, les opérateurs spécifiques sont obtenus par instanciation des opérateurs génériques sur ces trois éléments.

Seulement onze opérateurs ont été générés au lieu des vingt potentiels. En réalité, certains opérateurs génériques n’ont pas de sens dans le processus d’assemblage de cartes. Par exemple, les opérateurs Spécialiser et Généraliser ne peuvent pas être appliqués car il n’y a pas de lien Est-un entre les intentions, les stratégies et les sections d’une carte. Les trois opérateurs concernant un élément composé, Ajouter composant, Supprimer composant et Modifier composant, n’ont pas été instanciés car la structure du l’élément composé Section ne change pas. Finalement, le processus d’assemblage de cartes utilise deux opérateurs spécifiques : Connecter via fusion des intentions et Connecter via fusion des sections. Comme leurs noms indiquent, les deux opérateurs permettent d’assembler deux cartes distinctes en fusionnant les intentions et/ou les sections similaires. Par exemple, l’assemblage de la carte du modèle des Cas d’utilisation avec celle de l’approche L’Ecritoire se fait via la fusion des intentions « Découvrir un cas d’utilisation » provenant du premier modèle et « Découvrir un but » du deuxième modèle. Les deux intentions sont similaires et peuvent être fusionnées car toutes les deux représentent l’identification des objectifs des utilisateurs du système en construction. Toutefois, l’opérateur Modifier cible doit être appliqué sur une des intentions pour que leur fusion soit possible. Par exemple, l’intention « Découvrir un cas d’utilisation » peut être transformée en « Découvrir un but ».

Table 2. Les opérateurs pour l’assemblage des cartes de processus

Opérateur générique Opérateurs pour l’assemblage des cartes

Intention Stratégie Section

Renommer Renommer intention Renommer stratégie Renommer section

9

Ajouter Ajouter intention Ajouter stratégie Ajouter section

Supprimer Supprimer intention Supprimer stratégie Supprimer section

Fusionner Fusionner intention Fusionner stratégie Fusionner section

Fractionner Fractionner intention Fractionner stratégie Fractionner section

Remplacer Remplacer intention N/A N/A

Attribuer Attribuer verbe, Attribuer cible Attribuer paramètre

N/A Attribuer pre-condition Attribuer post-condition

Attribuer directive

Retirer Retirer verbe Retirer cible Retirer paramètre

N/A Retirer pre-condition Retirer post-condition Retirer directive

Modifier Modifier verbe, Modifier cible Modifier paramètre

N/A Modifier pre-condition Modifier post-condition Modifier directive

Retyper Retyper intention Retyper strategy N/A

Connecter via fusion Connecter via fusion des intentions

N/A Connecter via fusion des sections

Nous procédons de la même manière dans la définition des opérateurs d’assemblage des modèles de produit. Supposons que nous utilisons un modèle objet pour la représentation des modèles de produits de méthodes et que son métamodèle est celui représenté à la Figure 5. Ce dernier est une instance du métamodèle d’IM proposé à la Figure 4.

Figure 5. Métamodèle du modèle objet

Comme le montre la Figure 5, le modèle objet est composé des Classes qui sont des éléments composés d’Attributs. Une Classe est reliée à d’autres classes via Associations, liens Est-un et Composition. Une Association est aussi considérée comme un élément composé car elle peut posséder des attributs. Un Attribut possède une propriété Domaine tandis q’une Association a deux propriétés Cardinalité source et Cardinalité cible. La table présente les opérateurs agissant sur les éléments définit dans ce métamodèle.

A côté des opérateurs classiques de transformation de schémas tels que Renommer classe (attribut ou association), Ajouter classe (association, composition ou lien Est-un), etc., le processus d’assemblage des modèles objet utilise 6 opérateurs spécifiques : Connecter via spécialisation des classes, Connecter via généralisation des classes, Connecter via composition des classes, Connecter via décomposition des classes, Connecter via association des classes et Connecter via fusion des calasses. Par exemple, le « Scénario » du modèle des Cas d’utilisation n’a pas la même structure que le « Scénario » du modèle de produit de L’Ecritoire. Les deux types de scénarios peuvent être préservés

10

dans le modèle intégré grâce à l’opérateur Connecter via généralisation des classes qui crée dans le modèle intégré une classe « Scénario » comme une abstraction des deux classes initiales. Par contre, la classe « Acteur » du modèle des Cas d’utilisation peut être fusionné avec la classe « Agent » de L’Ecritoire.

Table 3. Les opérateurs pour assemblage de modèles objet

Opérateur générique

Opérateurs pour l’assemblage des modèles objet

Classe Attribut Association Composition Est-un

Renommer Renommer classe Renommer attribut Renommer association N/A N/A

Ajouter Ajouter classe N/A Ajouter association Ajouter comp. Ajouter Est-un

Supprimer Supprimer classe N/A Supprimer association Supprimer comp. Supprimer Est-un

Fusionner Fusionner classes Fusionner attributs N/A N/A N/A

Fractionner Fractionner classe Fractionner attribut N/A N/A N/A

Remplacer Remplacer classe Remplacer attribut N/A N/A N/A

Généraliser Généraliser classe N/A N/A N/A N/A

Spécialiser Spécialiser classe N/A N/A N/A N/A

Ajouter composant

N/A Ajouter attribut (classe, association)

N/A N/A N/A

Supprimer composant

N/A Supprimer attribut (classe, association)

N/A N/A N/A

Déplacer composant

N/A Déplacer attribut (classe, association)

N/A N/A N/A

Attribuer N/A Attribuer domaine Attribuer cardinalité N/A N/A

Retirer N/A Retirer domaine Retirer cardinalité N/A N/A

Modifier N/A Modifier domaine Modifier cardinalité N/A N/A

Retyper Retyper Class Retyper attribut Retyper association Retyper comp. Retyper Est-un

Connecter via spécialisation

Connecter via spécialisation de classes

N/A N/A N/A N/A

Connecter via généralisation

Connecter via généralisation de classes

N/A N/A N/A N/A

Connecter via composition

Connecter via composition de classes

N/A N/A N/A N/A

Connecter via décomposition

Connecter via décomposition de classes

N/A N/A N/A N/A

Connecter via Association

Connecter via Association de classes

N/A N/A N/A N/A

Connecter via fusion

Connecter via fusion de classes

N/A N/A N/A N/A

7.3.3 Mesures de similarité

L’application des opérateurs d’assemblage nécessite souvent de mesurer d’abord les similarités des éléments de différents modèles de produit et de processus. Nous proposons de mesurer la similarité des éléments de modèles en prenant en compte deux paramètres : leur sémantique et leur structure [Castano93], [Bianco99]. L'affinité sémantique entre éléments est basée sur les objets du monde réel qu’ils représentent tandis que l’affinité structurelle prend en compte la structure des éléments et leurs liens avec d’autres éléments du modèle.

Mesures de similarité des modèles de produit Les parties de produit de différents composants de méthode ont souvent des concepts de mêmes noms mais représentant des objets différents ou, inversement, représentant les mêmes objets du monde réel

11

et nommés différemment. La métrique affinité de noms (AN) permet de mesurer la similarité sémantique des concepts et de résoudre ces conflits de polysémie et de synonymie. L’application de cette métrique n’est possible que si tous les concepts utilisés dans les composants de méthodes concernés sont définis dans un thésaurus. De plus, les relations de synonymie (SYN) et d’hyperonymie (HYPER) doivent être définies entre les termes du thésaurus :

• SYN (Synonyme de) définit la relation de synonymie entre deux termes ti et tj où ti ≠ tj qui sont considérés comme des synonymes, par exemple, <But SYN Objectif>. SYN est une relation symétrique.

• HYPER (Hyperonyme de) définit la relation d’hyperonymie entre deux termes ti et tj où ti ≠ tj et le terme ti a un sens plus général que le terme tj. On dit que le terme ti est l’hyperonyme du ti. Par exemple, nous avons la relation d’hyperonymie <Scénario HYPER Scénario d’exception>. HYPER n’est pas une relation symétrique. La relation inverse à la relation HYPER est la relation d’hyponymie HYPO.

Le thésaurus des termes peut être vu comme un réseau où les termes sont des nœuds et les relations terminologiques sont des arcs entre les nœuds. Chaque relation terminologique R ∈{SYN , HYPER /HYPO } a un poids associé Rσ . Par exemple, 1=SYNσ et 8.0/ =HYPOHYPERσ .

Pour résumer, le coefficient d’affinité des noms des éléments de modèles de produit est calculé de la manière suivante :

⎪⎩

⎪⎨

⎧

→∗∗

><

= −

sinon 0

)n(e )n(e si ...

)n(e )n(esi 1

))n(e),n(e( klm

ij)1(1

klij

klij RmR

SYN

AN σσ

où )n(e )n(e klm

ij → indique que la longueur du chemin entre les termes eij et ekl dans le thésaurus est

m où m ≥ 1, σnR indique le poids de la n-ième relation terminologique dans )n(e )n(e klm

ij → .

Par exemple, le coefficient d’affinité des noms entre les concepts « But » et « Objectif » est égal à 1 (AN(But, Objectif) = 1) si ces deux termes sont définis comme des synonymes (<But SYN Objectif>) dans le thésaurus.

La similarité sémantique ne suffit pas à déterminer si deux concepts sont similaires car même si leur sémantique l’est, leur structure peut être différente selon le modèle auquel ils appartiennent. La comparaison structurelle des concepts est basée sur le calcul des propriétés communes et des liens communs avec d’autres concepts.

Le coefficient d’affinité structurelle de concepts (ASC) permet de mesurer la similarité des concepts par rapport à leurs propriétés structurelles en calculant quel est le pourcentage de propriétés qui leur sont communes. On appelle propriétés communes les propriétés ayant des noms similaires et des domaines de valeurs identiques ou compatibles. La formule d’évaluation est la suivante :

c du propriétés de Nombre

)cet c de communes propriétés de Nombre(2)c,ASC(c

i

2

1

2121

∑=

∗=

i

Le coefficient d’affinité d’adjacents de concepts (AAC) permet de mesurer la similarité structurelle des concepts par rapport à leurs adjacents communs. Les adjacents d’un concept sont les concepts qui sont associés à celui-ci par des liens d’association ou de composition.

∑=

∗=

2

1ii

2121

cau adjacents concepts de Nombre

)cet caux communs adjacents concepts de Nombre(2)c,AAC(c

12

Finalement, le coefficient d’affinité structurelle globale (ASG) permet de mesurer la similarité structurelle des concepts de manière générale. C’est une superposition des deux mesures précédentes :

2)c,AAC(c)c,ASC(c

)c,ASG(c 212121

+=

Mesures de similarité des modèles de processus Nous considérons ici que les modèles de processus des composants de méthodes sont représentés par des cartes. Les mesures de similarités des modèles de processus sont définies de la même manière que celles des produits ; elle prennent en compte les aspects sémantiques et les aspects structurels des cartes.

Etant donné que les deux types d’éléments importants pour l’intégration des cartes sont les intentions et les sections, deux types de mesures de similarité sémantique sont nécessaires : l’affinité sémantique des intentions (ASI) et l’affinité sémantique des sections (ASS).

L’ASI permet de mesurer la proximité de sens de deux intentions. Cette métrique est basée sur la comparaison des deux paramètres qui composent l’intention, un verbe et une cible, en utilisant la relation SYN. Si les verbes des deux intentions sont identiques, ou synonymes, et que les cibles des deux intentions sont identiques, ou synonymes, leur affinité sémantique est égale à 1, sinon elle est égale à 0. L’ASI est définie de la manière suivante :

⎩⎨⎧ ∧

=sinon 0

.cible))i SYN .cible(i .verbe)i SYN .verbe(i si 1)i,ASI(i jiji

ji

L’ASS permet de mesurer la proximité sémantique de deux sections. Rappelons qu’une section est définie par un triplet <intention source, intention cible, stratégie>. Les calculs du coefficient ASS sont basés sur l’évaluation de la mesure ASI entre les deux couples d’intentions : entre les deux intentions sources et les deux intentions cibles. Les stratégies sont comparées en appliquant la relation de synonymie. L’ASS est égale à 1 si l’ASI des deux intentions sources est égale à 1, l’ASI des deux intentions cibles est égale à 1 et si les expressions des deux stratégies sont identiques ou synonymes. Dans ce cas, on dit que les deux sections sont similaires sémantiquement ; sinon l’AAS est égale à 0 et on dit que les deux sections ont une sémantique différente. L’ASS est définie de la manière suivante :

⎩⎨⎧ ∧=∧=

=><><sinon 0

s SYN s1)i,ASI(i1)i,ASI(i si 1)s,i,i ,s,i,iASS( klijljki

kllkijji

Les mesures de similarité structurelle permettent de comparer la structure de deux cartes afin de pouvoir identifier les parties qui se recouvrent. Elle est basée sur la similarité structurelle des intentions (SSI) et la similarité structurelle des sections (SSS).

La SSI permet de mesurer quel est le pourcentage d’intentions similaires dans deux cartes. Les calculs de la SSI sont basés sur la recherche des intentions similaires dans les deux cartes, c’est-à-dire sur les calculs d’ASI entre leurs intentions. Pour deux cartes c1 et c2, la SSI est calculée de la manière suivante :

∑=

∗= 2

1i

2121

c carte la dans intentions des nombre Le

cet c dans similaires intentions des nombre Le 2)c,SSI(c

i

Si la SSI est supérieure à 0, les cartes ont des intentions similaires qui peuvent être fusionnées lors de l’intégration des cartes. Si la SSI est égale à 0, les cartes n’ont aucune intention en commun.

La SSS permet de mesurer le pourcentage de sections similaires dans les deux cartes. Soient c1 et c2 deux cartes de processus, la similarité structurelle des sections est définie de la manière suivante :

13

∑=

∗=

2

1i

2121i

carte la dans sections des nombre Le

cet c dans similaires sections des nombre Le 2)c,SSS(c

ic

Finalement, la Similarité Structurelle Partielle des Sections (SSPS) permet de mesurer le pourcentage des sections similaires par couple d’intentions. Soit c1 et c2 deux cartes de processus comportant les sections <i1i,i1j> et <i2i,i2j>. La similarité structurelle partielle des sections est définie de la manière suivante :

><+><

><><∗=><><

2l12k1j1i

2l2k1j1i2l2k21j1i1 i,i entre sections de Nbi,i entre sections de Nb

i,iet i,ientre similaires sections de Nb 2)i,ic ,i,iSSPS(c

7.3.4 Modèle de processus de construction de méthodes par assemblage

Le modèle de processus de construction de méthodes par assemblage de composants décrit de manière détaillée la directive associée à la stratégie de construction de méthodes Par assemblage proposée par la carte générique (Figure 2). Ce modèle est également défini en utilisant le formalisme MAP et représente le processus de niveau d’abstraction plus bas que la carte générique.

L’approche de construction de méthodes par assemblage est basée sur l'analyse et la réalisation des besoins de méthode. Ceci signifie que l'ingénieur de méthodes est amené à démarrer le processus d’ingénierie de méthode par la définition des exigences que celle-ci devrait satisfaire. Ensuite, les composants satisfaisant ces exigences sont sélectionnés dans la base de méthodes et assemblés afin de composer une nouvelle méthode ou d'enrichir une méthode existante. Par conséquent, le modèle de processus est basé sur trois intentions principales nommées :

1. Spécifier les exigences de méthode

2. Sélectionner les composants

3. Assembler les composants

Comme le montre la Figure 6 représentant la carte d’assemblage, le modèle propose plusieurs stratégies pour atteindre les intentions.

Figure 6. Modèle de processus de construction de méthodes par assemblage de composants

14

Spécification des exigences de méthode La spécification des exigences de méthode pour un projet particulier dépend de la situation dans laquelle se trouve le projet et de l’objectif d’ingénierie de méthode défini précédemment (voir la Figure 2). Deux situations classiques peuvent être identifiées :

1. L’équipe de développement du projet est habituée à utiliser une méthode particulière pour tous les projets qu’elle réalise mais dans le cas présent elle considère que la méthode ne satisfait pas pleinement les besoins du projet et nécessite donc d’être adaptée.

2. L’équipe de développement du projet n’a pas de méthode habituelle et considère qu’aucune des méthodes classiques ne satisfait le projet en cours.

Les deux situations sont traitées dans le modèle de processus d’assemblage (Figure 6) par deux stratégies suivantes :

1. Stratégie basée intention

2. Stratégie basée processus

Voici les explications.

Dans la première situation, l’objectif de l’ingénieur de méthode est de préciser comment la méthode en question pourrait être améliorée afin de satisfaire les besoins du projet en cours. On peut identifier plusieurs types d’adaptations d’une méthode existante:

• Enrichissement de la démarche : le modèle de produit de la méthode est suffisamment riche mais le modèle de processus est trop pauvre et requiert d’être amélioré par de nouvelles démarches alternatives et/ou complémentaires.

• Extension : La méthode ne couvre pas toutes les vues nécessaires du système en construction ; l’adaptation dans ce cas consiste à ajouter de nouveaux modèles qui permettraient de modéliser les aspects manquants.

• Configuration : Certaines fonctionnalités fournies par la méthode ne sont pas pertinentes pour le projet en cours ; l’adaptation de la méthode consiste à configurer la méthode en sélectionnant uniquement les fonctionnalités nécessaires et en éliminant les autres.

Dans tous ces cas, le processus de spécification des exigences est basé sur l’identification des intentions à ajouter dans la carte de la méthode et/ou en éliminer d’autres. C’est pour cette raison que la stratégie correspondante est appelée Stratégie basée intention. « Ajouter le concept d’événement », « ajouter l’étape de validation de la complétude des besoins », « remplacer les directives d’aide à l’écriture de scénarios par des directives plus riches » sont des exemples de telles intentions. Les exigences obtenues sont exprimées sous forme d’une carte appelée la carte des exigences. Cette dernière est la carte de la méthode avec des nouvelles intentions qui devrait être couvertes par des nouveaux composants.

Supposons que l’objectif de l’ingénieur de méthodes est d’enrichir la démarche du modèle des cas d’utilisation classique (Figure 7a) par la possibilité de classer les cas d’utilisation ainsi que par de nouvelles démarches d’écriture des scénarios afin d’améliorer la qualité des cas d’utilisation. Suivant la stratégie basée intention, une nouvelle intention « Classer les cas d’utilisation » est ajoutée dans la carte du modèle des cas d’utilisation (Figure 7b). Cette intention est connectée avec le reste de la carte par trois stratégies : la stratégie « Classification » qui concerne la manière de classer les cas d’utilisation, la stratégie de « Découverte basée sur la classification » qui souligne la possibilité de découvrir de nouveaux cas grâce à la classification obtenue et finalement, la stratégie « Rédaction basée sur la classification » suggère que la classification peut influencer le contenu et le style des scénarios à rédiger. De plus, la carte des exigences propose d’éliminer l’ancienne stratégie « Le cas normal d’abord » si celle-ci est remplacée par une autre proposant des directives plus riches.

15

Figure 7. Carte des exigences pour l'enrichissement du modèle des cas d'utilisation

Dans la deuxième situation, l’objectif de l’ingénieur de méthodes est de construire une nouvelle méthode par assemblage de composants. Le processus de spécification des exigences consiste à définir un modèle de processus abstrait de la nouvelle méthode. C’est pourquoi la stratégie correspondante est nommée Stratégie basée processus. Les exigences sont également exprimées sous forme d’une carte appelée la carte des exigences où toutes les sections devraient être couvertes par des nouveaux composants.

Supposons, que l’objectif de l’ingénieur de méthodes est de construire une nouvelle méthode permettant de : (1) découvrir les besoins fonctionnels d’un système en se basant sur l’analyse des buts, (2) conceptualiser les besoins avec des outils linguistiques, par exemple sous forme des scénarios ou des cas d’utilisation, (3) valider les besoins avec des outils d’animation comme le prototypage ou un autre mécanisme de simulation. La carte des exigences, illustrée à la Figure 8, exprime ces besoins par trois intentions de base : Découvrir les besoins, Conceptualiser les besoins et Valider les besoins et plusieurs stratégies pour réaliser ces intentions.

Figure 8. Exemple d'une carte des exigences pour une nouvelle méthode

Sélection de composants Après avoir défini les exigences pour la méthode à construire ou à adapter, l’ingénieur de méthodes peut sélectionner les composants satisfaisant ces exigences. La carte d’assemblage (Figure 6) propose la stratégie dirigée par les exigences pour aider à la réalisation de cette tache. Cette stratégie guide

16

l’ingénieur de méthodes dans la construction des requêtes pour la recherche des composants dans la base de méthodes. Les requêtes de sélection sont formulées en attribuant des valeurs aux attributs définis dans le descripteur et l’interface du composant (voir le chapitre 4). Le composant sélectionné doit couvrir au moins une section de la carte des exigences et il peut en couvrir plusieurs.

Prenons comme exemple le cas d’adaptation du modèle des cas d’utilisation dont la carte des exigences est représentée à la Figure 7. Afin de couvrir les sections ajoutées à la carte initiale, l’ingénieur de méthodes construit la requête suivante :

Intention_de_reutilisation.verbe = ‘Classer’ ET Intention_de_reutilisation.cible = ‘Besoins fonctionnels’ ET Situation_de_reutilisation.Activité_d_Ingénierie = ‘Spécification des besoins’ ET Situation = ‘Cas d’utilisation’ ET Intention.verbe = ‘Classer’ ET Intention.cible = ‘Cas d’utilisation’

Grâce à cette requête, l’ingénieur de méthodes sélectionne deux composants issues de l’approche proposés par Cockburn [Cockburn00]. Ils offrent deux manières complémentaires de classer les cas d’utilisation : l’une est basée sur une hiérarchie de buts à trois niveaux, l’autre utilise une typologie des portées des cas d’utilisation. Les deux composants couvrent la section <Découvrir les cas d’utilisation, Classer les cas d’utilisation, Stratégie de classification> de la carte des exigences. En suivant la stratégie par agrégation (Figure 6), on s’aperçoit que la même approche propose également des directives pour retrouver d’autres cas d’utilisation, ce qui correspond à la section <Classer les cas d’utilisation, Découvrir les cas d’utilisation, Stratégie de découverte basée sur la classification> de la carte des exigences. De plus, cette approche propose des modèles et des directives de style pour l’écriture des scénarios en fonction du but et de la portée du cas d’utilisation identifié et satisfait ainsi la section <Classer les cas d’utilisation, Conceptualiser les cas d’utilisation, Stratégie de rédaction basée sur la classification> de la carte des exigences (Figure 7). Finalement, toute l’approche de rédaction des cas d’utilisation proposée par Cockburn [Cockburn00] est sélectionnée afin d’être assemblé avec le modèle des cas d’utilisation.

Dans le cas de la construction d’une nouvelle méthode, l’ingénieur de méthodes construit plusieurs requêtes pour couvrir toutes les exigences capturées dans la carte des exigences. Par exemple, la carte des exigences de la Figure 8 indique qu’il faut trouver des composants de méthode permettant de découvrir des besoins sous forme des buts. L’ingénieur de méthodes construit la requête suivante :

Intention_de_reutilisation.verbe = ‘Découvrir’ ET Intention_de_reutilisation.cible = ‘Besoins fonctionnels’ ET Situation_de_reutilisation.Activité_d_Ingénierie = ‘Spécification des besoins’ Intention.verbe = ‘Découvrir’ ET Intention.cible = (‘But’ OU ‘Besoin’)

En plus de la stratégie dirigée par les exigences, le processus d’assemblage propose également des stratégies permettant de valider et d’affiner la sélection des composants.

Chaque composant candidat est validé en évaluant à quel degré il correspond aux exigences de la méthode en construction. Autrement dit, quelle partie de la carte des exigences il pourrait couvrir. Ceci est pris en compte par la stratégie d’évaluation qui propose des mesures de similarité [Ralyté01a] permettant de comparer la carte des exigences avec le modèle de processus du composant et valider ainsi la sélection d’un composant.

En fonction des résultats d’évaluation des composants candidats, la sélection peut être affinée en suivant les stratégies de décomposition, d’agrégation et d’affinement (Figure 6).

• La stratégie de décomposition s’applique sur un composant agrégat. Elle permet de sélectionner les sous-composants qui sont pertinents et d’éliminer ceux qui sont inadéquats.

• Inversement, la stratégie d’agrégation cherche des composants agrégats contenant le composant candidat en supposant que le composant agrégat puisse fournir la solution pour les exigences qui ne sont pas encore satisfaites.

17

• La stratégie d’affinement cherche un autre composant satisfaisant la même intention mais de manière différente.

Assemblage de composants L’étape suivante dans le processus de construction de méthodes par assemblage est l’assemblage des composants sélectionnés. Dans le cas d’adaptation d’une méthode existante, il suffit de sélectionner un composant afin de progresser vers son assemblage avec le reste de la méthode qui est aussi considérée comme un composant. Le cas de construction d’une nouvelle méthode demande à l’ingénieur de méthodes de sélectionner au moins deux composants avant de passer à l’étape d’assemblage.

La carte d’assemblage (Figure 6) propose deux stratégies par association et par intégration qui correspondent aux deux techniques d’assemblage présentées au début de ce chapitre. Cela signifie que l’ingénieur de méthodes doit tout d’abord évaluer le degré de similarité des deux composants afin de choisir la stratégie adéquate. Les mesures de similarité peuvent être appliquées sur les modèles de produit et les modèles de processus des composants afin de détecter des éléments similaires ou communs.

Si les deux composants n’ont pas d’éléments communs, ni de concepts communs dans leurs parties de produit, ni d’intentions communes dans leurs parties de processus, la stratégie par association doit être sélectionnée. Inversement, si les composants se recouvrent partiellement, c’est-à-dire qu’ils partagent certains concepts et permettent de satisfaire les mêmes intentions mais de manière différente, la stratégie par intégration doit être appliquée.

La stratégie par association utilise essentiellement les opérateurs d’assemblage permettant de faire la connexion entre les composants. Plus précisément, la connexion des modèles de produit se fait par la définition des liens entre les concepts ou éventuellement par l’addition de nouveaux concepts. Si les modèles de produit des composants en question sont exprimés en termes de modèles objet, les opérateurs comme Ajouter association et Ajouter classe vont être appliqués. En ce qui concerne l’association des modèles de processus, elle est essentiellement basée sur la définition de l’ordre d’exécution. L’opérateur Ajouter section va être appliqué dans le cas où les modèles de processus des composants seraient exprimés sous forme de cartes.

Par exemple, le composant de méthodes fournissant les directives pour la définition du cycle de vie d’un objet nécessite que l’objet en question ainsi que ses relations avec d’autres objets soit définis préalablement. Par conséquent, le composant permettant de construire le modèle objet doit être réalisé avant la réalisation du composant destiné à la définition de cycle de vie de l’objet. Les deux composants ont des objectifs communs. L’association des modèles de produits se fait via la connexion des concepts Classe et Etat en ajoutant une nouvelle association ente eux.

La stratégie par intégration utilise les opérateurs d’assemblage permettant de fusionner ou de connecter les éléments communs des composants. Par conséquent, le processus d’intégration consiste à identifier les classes communes dans les modèles de produits des composants ainsi que les intentions communes dans leurs modèles de processus et de les fusionner. Par exemple, il peut être judicieux d’intégrer deux composants proposant des directives différentes pour la découverte des besoins. Le composant proposant des directives de découverte de besoins à base d’analyse de buts combiné avec celui proposant des directives de découverte à base d’acteurs permet d’obtenir un nouveau composant plus riche en terme de démarche que les deux composant utilisés séparément.

Les opérateurs Fusionner classes et Fusionner intentions sont alors appliqués. En ce qui concerne l’intégration des modèles de produits, d’autres opérateurs comme Connecter via généralisation de classes ou Connecter via spécialisation de classes peuvent également être utiles car dans certains cas les concepts peuvent avoir une sémantique similaire mais une structure différente et il est nécessaire de garder les deux concepts dans le modèle intégré. Les liens de généralisation/spécialisation sont alors créés entre ces concepts.

Dans les deux cas, association et intégration, il peut être nécessaire d’adapter les modèles avant leur association/intégration pour éviter les problèmes d’ambiguïté des noms avev des opérateurs comme

18

Renommer classe, Renommer attribut, Renommer intention etc., ainsi que Retyper association, Retyper attribut, etc.

L’assemblage du composant de méthode sélectionné dans la section précédente pour enrichir le modèle des cas d’utilisation se fait en suivant la stratégie par intégration car le composant en question contient des concepts communs avec la méthode initiale. Comme le montre les parties (a) et (b) de la Figure 9 représentant les modèles de produit des deux composants de méthodes à assembler, le concept de « Cas d’utilisation » est le concept de base dans les deux approches. Il a la même signification dans les deux cas mais sa structure est différente, elle est plus riche dans le modèle de Cockburn. L’opérateur Fusionner classes est appliqué sur les classes communes telles que « Cas d’utilisation », « Scénario » et « Acteur ». Cet opérateur préserve tous les attributs des deux classes ainsi que toutes les relations avec d’autres classes. Le « Scénario d’extension » de l’approche Cockburn [Cockburn00] doit être renommé pour être fusionné avec le « Scénario d’exception » du modèle des cas d’utilisation car ils ont la même sémantique. Le « Scénario » du modèle initial contient une description informelle tandis que celui du Cockburn est structuré en un ensemble d’Interactions. Puisque l’objectif d’intégration est d’utiliser les directives de rédaction de Cockburn, c’est le scénario structuré qui est gardé dans le modèle intégré, la propriété « Description » du « Scénario » est supprimé grâce à l’opérateur Supprimer attribut. La Figure 9 illustre les deux modèles de produit initiaux ainsi que le modèle intégré ; les classes foncées sont les classes fusionnées.

19

Figure 9. Modèles de produit des composants avant et après l'intégration

L’intégration des modèles de processus des deux composants consiste à fusionner les intentions et les stratégies communes. Comme le montre les parties (a) et (b) de la Figure 10 illustrant la carte de processus du modèle des cas d’utilisation et celle du modèle de Cockburn, les deux cartes partagent deux intentions communes « Découvrir les cas d’utilisation » et « Conceptualiser les cas d’utilisation ». Grâce à l’opérateur Fusionner intentions ces deux intentions sont fusionnées dans la carte intégrée. De plus, la section <Démarrer, Découvrir des cas d’utilisation, Stratégie par acteur> est identique dans les deux cartes : les deux approches proposent la même directive de découverte des cas d’utilisation en se basant sur l’analyse des acteurs du système. Ainsi, les deux stratégies sont fusionnées dans la carte intégrée. Finalement, l’opérateur Supprimer stratégie est appliqué afin d’éliminer la stratégie « Cas normal d’abord » du modèle des cas d’utilisation car elle est remplacée par la stratégie « Directives de rédaction » proposé dans le composant de Cockburn.

20

Figure 10. Modèles de processus des composants avant et après l'intégration

7.4 Construction de méthodes par extension

Cette approche de méthode situationnelle basée sur les extensions [Deneckere01, Deneckere98] répond à un objectif d’ingénierie des méthodes qui est d’adapter une méthode selon le projet en cours. Cette approche guide l’ingénieur de méthodes par des patrons d’extension qui permettent d’identifier des situations d’extension typiques et procurent des conseils pour exécuter l’extension, ou les extensions, requises par cette situation. La majorité des autres techniques de construction de méthode (comme l’approche par assemblage) permettent généralement de construire une nouvelle méthode modulaire contenant tous les points intéressants de différentes méthodes. De façon un peu différente, l’approche de construction par extension ne se base que sur une seule méthode, que l’on appellera la méthode d’origine, et qui devient le corps d’une méthode étendue répondant à des besoins spécifiques grâce à de nouveaux concepts [Deneckere01].

En effet, l’ingénieur a pu sélectionner une méthode qui lui a semblée la plus adaptée à son type d’applications mais qui peut très bien ne pas répondre à toutes ses exigences. Prenons l’exemple d’une entreprise dont le service du personnel rythme ses activités sur un calendrier basé sur les jours ouvrables, le service de comptabilité sur un calendrier comptable alors que les autres départements

21

utilisent le référentiel classique du calendrier Grégorien. Ce type d’application entraîne des traitements très particuliers, comme le calcul des jours de vacances qui se fera plus facilement avec un référentiel ne contenant que les jours ouvrés que dans un référentiel Grégorien contenant tous les jours de la semaine (où il faudra, par exemple, soustraire les fins de semaines et les jours fériés de toutes les semaines de vacances). Dans ce cas, l’application fonctionnera mieux si l’on y intègre la gestion de plusieurs calendriers spécifiques que l’on ne peut effectuer avec une méthode orientée objet classique. L’ingénieur de méthodes devra donc y intégrer certains concepts temporels, utiles pour le projet en cours mais n’y existant pas à l’origine.

La connaissance développée concernant une extension est encapsulée dans un composant réutilisable que l’on a appelé Patron.

7.4.1 Patrons de connaissance

Il n’est plus réellement nécessaire de présenter le concept de patron. Très largement utilisé dans la communauté du développement logiciel durant les deux dernières décennies, en particulier dans le domaine des approches orientées objet, ce concept a été plus récemment introduit dans la communauté de l’ingénierie des méthodes. Ce récent intérêt concernant les patrons trouve son origine dans [Coad92] puis est passé à la programmation logicielle [Beck97, Buschmann96], la conception système et logicielle [Coplien95, Gamma94, Vlissides96], la modélisation des données [Hay96] et l’analyse des systèmes [Fawler97]. Dans le domaine spécifique de l’ingénierie des méthodes, les patrons génériques aident à construire des méthodes situationelles. Ils permettent de connaître quels sont les meilleurs processus à utiliser dans telle ou telle situation et guident l’ingénieur lors de la construction de sa méthode.

Structure d’un patron d’extension Nous utilisons ici le formalisme défini dans [Deneckere01a, Deneckere98] et reproduit dans la Figure 11. Un patron est composé de deux parties : la connaissance réutilisable (le corps) et les aspects applicatifs (la signature).

Signature Corps

Méthode

Partie de Méthode

Situation Cible Intention

Signature Formelle

Signature Informelle

Patron

Opérateurs

Etend

Modifie

Correspond à

Correspond à

*

* *

* *

Figure 11: Méta-modèle d'un patron d'extension

Le corps encapsule la description du processus à appliquer au produit en modification à l’aide d’un ensemble d’opérateurs représentant les opérations de transformation à exécuter sur la méthode pour pouvoir l’étendre. La signature peut se voir sous deux aspects. La vue informelle de la signature permet de spécifier le domaine d’application, les heuristiques ainsi que les forces et les faiblesses du patron d’extension alors que la vue formelle permet de définir les parties de la méthode qui seront modifiées par le patron ainsi que l’extension spécifique que l’on souhaite effectuer. La signature représente la situation avant extension, l’intention à réaliser et la cible de cette extension. On appelle

22

également ce concept une interface [Rolland98]. Elle est vue comme un triplet <situation, intention, cible> associé au corps. L’interface est la partie visible d’un patron (voir Figure 12).

Situation Cible

Intention

Définition du Produit: [classe d’objets]

Etendre la méthode par généralisation pour y intégrer le concept de classe temporelle

Définition du Produit: [Classe = Spécialisation (classe d’objets,classe temporelle]

Corps du Patron

Quelle est la partie de la méthode que l’on veut obtenir ?

Quel est le but à atteindre ? Quelle est la partie de la méthode que l’on veut étendre ?

Figure 12: Partie Interface d’un patron

La situation est la partie de la méthode orientée objet à étendre. Elle représente toute partie du Produit en cours de développement ou toute partie de la Démarche en cours d’exécution pouvant faire l’objet d’une prise de décision de la part de l’ingénieur d’application. La granularité des situations est variable : celles-ci peuvent être atomiques comme, par exemple, lorsqu’elles font référence à un attribut unique ou à une seule classe, ou bien complexes, comme lorsqu’elles référencent une spécification entière ou un modèle dans son ensemble.

L’intention reflète le choix que peut faire l’ingénieur d’application à un moment donné du processus. Elle référence l’extension, le but à atteindre pour utiliser le patron. Il peut s’agir d’un objectif très global comme celui d’Etendre la méthode OMT ou bien d’un but plus précis, par exemple d’Etendre le concept de classe pour permettre la gestion d’historiques. L’intention conduit le processus d’utilisation des patrons.

La cible représente la partie de la méthode qu’il faut obtenir après application du patron.

Le corps explique comment procéder pour atteindre l’intention dans cette situation particulière.

Un fait important au sujet des patrons est que la façon d’effectuer une modification est différente selon la situation de départ. En conséquence, toutes les manières possibles d’appliquer une transformation doivent être définies pour permettre de gérer toutes les possibilités. Tous ces patrons sont ensuite stockés dans une bibliothèque de patrons.

Typologie des patrons d’extension Une méthode étant définie comme un ensemble à deux parties : la partie Produit et la partie Processus (ou Démarche), chaque extension de méthode devra donc prendre en compte l’extension de ces deux parties différentes, ainsi que l’indique la Figure 13.

MMéétthhooddeedd’’oorriiggiinnee

EExxtteennssiioonn dduuPPrroocceessssuussdd’’oorriiggiinnee

EExxtteennssiioonn dduuPPrroodduuiitt

dd’’oorriiggiinnee

MMéétthhooddeedd’’oorriiggiinnee MMéétthhooddee

EEtteenndduuee

Figure 13: Principe d'extension des parties Produit et Processus

23

En conséquence, nous distinguons deux types de patrons, ceux permettant d’effectuer une extension de la partie produit et ceux permettant l’extension de la partie processus.

Exemple de patron d’extension Ci-dessous un exemple de patron d’extension permettant d’intégrer la gestion des calendriers dans une méthode orientée-objet classique.

Situation: [X} = Spécialisation ([W]) D W est l'ensemble des sous-types de X. D est l'élément à éliminer après l'extension

Intention: Etendre, par Spécialisation, le Produit de [M]pour intégrer le concept de Classe Calendrier

Cible: [X] = Spécialisation (Classe Calendrier, W)

Situation : Granule Classe = Spécialisation (Classe Acteur, Classe Objet)

Intention: Etendre, par Spécialisation, le concept de Classe pour intégrer celui de Classe Calendrier

Cible: Classe = Spécialisation (Classe Acteur, Classe Objet, Classe Calendrier)

Corps du patron instancié Supprimer Granule

Insérer (Classe Calendrier) Insérer_isa (Classe Calendrier, Classe)

Insérer-cluster (Classe Acteur, Classe Objet, Classe Calendrier)

Classe

Classe Acteur

Classe Objet

Classe

Classe Calendrier

Classe Acteur

Classe Objet

M = Méthode O* où D] = Granule [X] = Classe [W] = {Classe Acteur, Classe Objet}

Patron

Patron instancié à O*

Granule

Corps du patron

Supprimer [D] Insérer (Classe Calendrier)

Insérer-isa (Classe Calendrier, [X]) Insérer-cluster ([W], Classe Calendrier)

Figure 14: Exemple d’application d’un patron d’extension

Nous représentons ici l’application du patron à la méthode O*. Nous pouvons constater ici que le concept de Classe Calendrier est inséré en tant que sous-type du concept de Classe et que le concept déjà existant de Granule est supprimé. La classe calendrier pourra être instanciée plusieurs fois dans le but d’obtenir plusieurs calendriers différents. De plus, ce patron produit un calendrier de référence qui est le calendrier Grégorien. Par exemple, une entreprise peut utiliser le calendrier Grégorien dans la majorité de ses services mais le calendrier des Jours-Ouvrés dans le service du personnel. En conséquence, il est nécessaire de définir deux calendriers différents pour l’application (ainsi que les fonctions de mapping permettant d’effectuer les conversions entre les deux calendriers). La Figure 15 offre une vision de l’objet Grégorien de la classe calendrier.

24

Calendar class Gregorian origin "01/01/0001:00:00:00" basic unit = chronon granules second : {1 basic unit, basic unit=1second} minute : {irregular} hour : {60 minutes, minute=1/60hour} day : {24 hours, hour=1/24day} month : {irregular} year : {12 months, mois=1/12 year} operations instant<Gregorian, *> operator+ (instant<Gregorian, *>, interval<Gregorian, *>) instant<Gregorian, *> operator+ (interval<Gregorian, *>, instant<Gregorian, *>) interval<Gregorian, *> operator- (instant<Gregorian, *>, instant<Gregorian, *>) EndCalendarClass

Figure 15: Définition du calendrier Grégorien

Les minutes et les mois ne sont pas des granules réguliers puisque leur quantité de temps n’est pas fixe. La minute représente en général 60 secondes (excepté lorsque l’on ajoute une seconde intermédiaire). De la même manière, le nombre de jours dans un mois varie de 28 à 31.

7.4.2 Méta-patron d’extension

La connaissance relative aux extensions est donc capturée dans des patrons qui sont eux-mêmes organisés en méta-patrons. Chaque méta-patron d’un domaine particulier pour lequel de la connaissance au sujet des extensions et sur la façon de l’exécuter a été définie est stocké dans une bibliothèque avec ses patrons correspondants. Cela permet donc à l’ingénieur de méthodes de connaître les différents objectifs qu’il peut réaliser avec ce méta-patron pour le champ d’application considéré (inventaire de tous les éléments que l’on souhaite intégrer dans la méthode) et les manières de les réaliser. Le meta-patron permet également de guider l’ingénieur de méthodes en ce qui concerne l’enchaînement des différents patrons pour lui éviter des incohérences.

Une fois que l’ingénieur de méthode a sélectionné le méta-patron pertinent pour le domaine d’extension de son projet, la stratégie basée sur les patrons le/la guide dans l’application systématique des patrons associé au méta-patron. Ci-dessous un exemple correspondant à un extrait du méta-patron guidant les extensions temporelles de méthodes. Celui-ci est composé de plusieurs patrons dont quelques uns sont donnés dans la Table 4 Chaque patron correspond à l’intégration d’un concept particulier pour laquelle il spécifie un certain nombre d’arguments permettant de décrire l’extension qui sera réalisée.

Table 4. Extrait du méta-patron "Etendre une méthode avec des concepts temporels"

Concept : Evénement temporel

Patron : Etendre une méthode avec des événements temporels

Arguments : Les applications ont souvent besoin de déclencher des opérations en suivant des données temporelles spécifiques. Ce patron permet l’insertion d’événements temporels dans la méthode. Il utilise un modèle et des domaines temporels dans le but de définir des moments particuliers pour le déclenchement des opérations.

Concept : Modèle temporel permettant de gérer des instants

25

Patron : Etendre une méthode avec une structure de points temporels discrets

Arguments : Les bases de données nécessitent l’utilisation d’une connaissance précise sur les événements. Ce patron permet de définir un modèle temporel (linéaire ou ayant une structure d’arbre) défini comme un ensemble de points temporels (ou instants). Ces points temporels ont une relation de précédence asymétrique et transitive.

Concept : Modèle temporel permettant de gérer des intervalles

Patron : Etendre une méthode avec une structure d’intervalles

Arguments : Certaines applications requièrent la gestion de données temporelles floues ou imprécises. Ce patron autorise la définition d’un modèle temporel comme un ensemble d’intervalles. Il aide à décrire trois types temporels : instants, intervalles et périodes, définis pour manipuler le temps. Un point isolé sur l’axe du temps est appelé un instant. Le temps entre deux instants est appelé un intervalle de temps, il est décrit par deux instants représentant les bornes inférieures et extérieures. Une période de temps est définie comme une durée, c’est à dire une quantité de temps qui n’est pas localisable sur l’axe du temps.

Concept : Domaine temporel

Patron : Etendre une méthode avec des domaines temporels

Arguments : Les méthodes classiques utilisent en général les domaines temporels liés à un attribut tels que Date, Time et TimeZone. Cependant, ces domaines sont très pauvres et n‘autorisent pas la représentation des attributs périodiques ou relatifs. Ce patron a comme but de permettre la génération de ces domaines temporels. Les temps utilisés peuvent être valide, transactionnel ou encore défini par l’utilisateur [Snodgrass85]. Le temps de validité est le temps auquel l’information mémorisée dans la base est valide dans le monde réel. Le temps de transaction représente l’instant où le fait survenu est enregistré dans la base. Le temps utilisateur est nécessaire pour toutes les informations temporelles dépendantes de l’application ; il s’agit d’une information ayant une sémantique de temps gérée par l’application.

Concept : Historique d’objet

Patron : Etendre une méthode avec des classes temporelles pour les historiques d’objets

Arguments : Les historiques sont parfois utilisés pour étudier l’évolution des données et exécuter les fonctions de répétition demandées par le processus décisionnel de trace d’une organisation. En conséquence, l’application doit produire de l’information pour chaque état des objets lorsque il est/était vrai ou lorsqu’il est/était exploitable. Ce patron permet d’intégrer la gestion du temps dans la définition de la classe ainsi que de grouper les propriétés qui évoluent en même temps et qui sont liées à la même dimension temporelle. Les états successifs des objets sont indexés par le temps de validité (temps du monde réel).

Concept : Version d’objet

Patron : Etendre une méthode avec des classes temporelles pour les versions d’objets

Arguments : Les opérations de Rollback sont de plus en plus demandées pour revenir aux états précédents de la base de données. Ce patron permet la création d’historiques d’objets gérant l’application de ces opérations de rollback sans mettre en danger la cohérence de la base de données. Les objets rétrospectifs permettent de préserver les états successifs d’un objet avec une indexation par le temps de transaction.

Concept : Contrainte temporelle

Patron : Etendre une méthode avec des contraintes temporelles

Arguments : La nécessité de gérer le temps introduit un autre problème, celui de contraindre

26

l’évolution des données. Les modèles doivent inclure des concepts permettant à l’ingénieur de définir quelles contraintes sont reliées au temps dans le but de conserver la cohérence des données. Ce patron utilise une classification de contraintes en contraintes intra-objets ou inter-objet [Snodgrass85] ainsi que la distinction entre les contraintes intra-temps et inter-temps [Deneckere98] dans le but d’aider l’ingénieur à contraindre l’évolution des données. Une contrainte intra-objet permet de définir l’intégrité localement à un objet par opposition à une contrainte inter-objet qui détermine l’intégrité globalement à un ensemble d’objets. Une contrainte intra-temps se définit localement à un instant t (chaque instant t doit vérifier la contrainte). Une contrainte inter-temps se définit en utilisant une information à des temps différents (chaque instant t doit vérifier la contrainte).

…

Cet exemple montre que, pour chaque concept défini correspondant à ce domaine des applications temporelles, et dont l’ingénieur veut doter la méthode, il existe un patron que l’on peut appliquer. Une description du patron permet ici de savoir quelles vont être les modifications apportées à la méthode.

7.4.3 Modèle de processus de construction de méthodes par extension

La carte, qui représente le processus de cette approche, est présentée à la Figure 16. Elle propose deux chemins possibles pour étendre une méthode :

(a) Chemin guidé par la correspondance de parons, directement à travers la stratégie guidée par la correspondance de patrons. Ce chemin aide à établir une correspondance entre les patrons stockés dans la bibliothèque et les besoins d’extension.

(b) Chemin guidé par le domaine, en utilisant de la connaissance générique reliée au domaine pour lequel l’extension doit être effectuée en suivant le chemin Sélectionner un méta-patron, Etendre une méthode avec une stratégie basée sur les patrons. Ce chemin sélectionne tout d’abord un méta-patron correspondant au domaine d’extension puis guide celle-ci en appliquant les patrons suggérés par le meta-patron.

Ces deux processus distincts utilisent la bibliothèque de patrons d’extension de différentes manières. Celui centré sur le domaine exploite le fait que l’ensemble des patrons et de leurs utilisations peut être encapsulé dans un meta-patron qui est valable pour les toutes les extensions de méthodes dans ce domaine (par exemple dans le domaine des structures de données temporelles). Si l’extension demandée ne correspond pas clairement à un certain type d’extension, un domaine d’extension bien défini, alors l’approche par correspondance de patrons devra être sélectionnée par l’ingénieur de méthodes.

Figure 16: Modèle de processus d’ingénierie des méthodes situationnelles basé sur les extensions

Chemin guidé par le domaine Ce chemin dans le processus basé sur les extensions, et illustré à la Figure 17, correspond à l’ensemble des sections permettant de

27

(1) Sélectionner un méta-patron avec la stratégie guidée par le domaine et

(2) d’étendre une méthode avec la stratégie basée sur les patrons.

Figure 17: Chemin guidé par le domaine dans le processus d'extension d'une méthode

La section permettant d’atteindre l’objectif de sélection d’un méta-patron aide l’ingénieur de méthode à reconnaître si l’extension qu’il/elle souhaite exécuter correspond à un domaine d’extension déjà défini. Un exemple typique d’un tel domaine est celui des structures de données temporelles. L’adaptation de toute méthode à ce domaine inclue des extensions telles que l’intégration, dans le modèle de produit de la méthode, d’un modèle temporel comprenant les calendriers appropriés (Grégorien, Basé sur les semaines, Basé sur les jours ouvrés, etc.), l’intégration d’événements temporels et d’expressions temporelles pour définir les conditions d’occurrence d’événements, etc. L’exemple d’un meta-patron adapté à ce domaine est donné dans la section précédente.

Prenons l’exemple de la méthode O* que l’on souhaite étendre au domaine des structures temporelles. L’application de ce meta-patron permet de modifier à la fois la partie produit de la méthode et sa partie processus. La figure ci-dessous illustre le résultat de l’exécution de plusieurs patrons différents de ce meta-patron : l’extension de la méthode aux classes temporelles et aux domaines temporels.

Classe Temporelle

Classe Objet

Classe Instantanée

Classe Estampillée

Classe Estampillée Temps de Validité

Classe Estampillée Temps de Transaction

Classe Estampillée Temps Bi-Temporel

*

Domaine

Domaine non Temporel

Domaine Temporel

Domaine Temporel Instant

Domaine Temporel Période

Domaine Temporel Intervalle

Domaine Temporel Instant-A

Domaine Temporel Instant-R

Domaine Temporel Intervalle-A

Domaine Temporel Intervalle-R

Propriété

*

Figure 18: Parties du modèle de produit de O* modifiées par l'exécution du méta-patron

L’exécution du méta-patron va encore bien au delà de ces modifications puisque la méthode sera étendue avec l’intégration de calendriers, de contraintes temporelles… De plus, le processus de construction également sera altéré pour prendre en compte ces nouveaux concepts.

Chemin guidé par la correspondance des patrons L’approche utilisant ce chemin par correspondance de patrons pour étendre une méthode (Figure 16) permet de guider l’ingénieur de méthodes dans la sélection des patrons d’extensions qui

28

correspondront le mieux à ses besoins. En conséquence, la carte de processus, qui modélise cette approche, est centrée autour de deux intentions principales :

(1) Spécifier les besoins d’extension et

(2) Sélectionner et Appliquer un patron.

Ceci est illustré à la Figure 19 ainsi que les stratégies permettant d’atteindre ces intentions.

Figure 19: Modèle de processus pour l’extension de méthode basé sur la correspondance de patrons

Ø Stratégie d’extraction des besoins

Cette stratégie aide l’ingénieur de méthodes à construire une carte représentant les besoins d’extension de la méthode. Cette carte est appelée une carte des besoins. Cette stratégie pourrait être décomposée en plusieurs autres stratégies représentant les différentes manières possibles d’extraire les besoins, comme par exemple la stratégie par entrevues, la stratégie par modélisation des buts ou encore la stratégie par analyse de documentations. L’ingénieur de méthodes est donc amené à démarrer ce processus par la définition des besoins que la méthode doit satisfaire, en utilisant les différentes techniques qui sont mises à sa disposition.

Un exemple d’intention, de besoin, serait Introduire un modèle de domaines temporels. Dans ce cas, une stratégie attachée à cette intention dans la carte des besoins pourrait être basé sur les intervalles. Basé sur les points temporels discrets (les instants) pourrait être une autre stratégie associée à la même intention. Deux cartes des besoins différentes peuvent inclure la même intention, comme Introduire un modèle de domaines temporels, mais avec des stratégies différentes. Cependant, une carte des besoins unique peut les inclure toutes les deux, signifiant que l’extension de méthode doit gérer les deux types de raisonnement temporels, celui basé sur les instants et celui basé sur les intervalles.

La figure suivante illustre une carte des besoins où deux intentions d’extension ont été définies : Etendre la méthode en introduisant les domaines temporels et Etendre la méthode en introduisant les

29

classes temporelles. Chacune de ces deux intentions peut être réalisée à l’aide de deux stratégies différentes selon les besoins de l’ingénieur de méthodes.

Figure 20: Exemple de carte des besoins

Ø Stratégie d’extension du produit versus stratégie d’extension du processus

Dans la bibliothèque, les patrons d’extension sont donc regroupés selon leur type : patrons d’extension de produit ou patron d’extension de processus. Le premier indique comment étendre un modèle de produit alors que le dernier concerne l’extension d’un modèle de processus. Ceci peut se voir dans la carte de la Figure 19 dans les deux stratégies permettant d’atteindre l’intention Sélectionner et Appliquer un patron qui sont la stratégie d’extension du produit et la stratégie d’extension du processus. Ces deux stratégies possèdent des règles de conduites permettant de faire correspondre les intentions et les stratégies de la carte avec la situation du patron.

Une extension de la partie produit d’une méthode permet d’introduire de nouveaux concepts dans un modèle existant alors qu’une extension de la partie processus d’une méthode permettra d’introduire la construction de ces nouveaux concepts dans la même méthode.

En effet, si la partie produit de la méthode ne correspond pas aux besoins de l’ingénieur, la méthode peut être modifiée par l’application d’un patron d’extension de produit. Cela permettra à l’ingénieur de méthodes de travailler avec un plus grand nombre de concepts dans le but de construire une application plus complète et plus cohérente. De plus, si l’ingénieur de méthodes applique un patron d’extension de produit alors que la méthode modifiée contient une partie processus, il devient préférable de modifier également cette partie pour préserver la cohérence de la méthode, c’est la raison pour laquelle il existe des patrons d’extension du processus d’une méthode.

Prenons l’exemple d’une extension de la méthode O* à laquelle l’ingénieur souhaite intégrer la notion de domaines temporels plus précis que le domaine Date. Il pourra alors appliquer le patron d’extension de produit correspondant qui lui permettra de remplacer ce domaine type par une classification de domaines temporels correspondant aux différents types de temps existants (temps de validité, temps de transaction, temps défini par l’utilisateur). Il pourra ensuite appliquer le patron d’extension du processus, correspondant à l’introduction de ce concept, à sa méthode pour permettre d’intégrer à la démarche de la méthode la définition d’attributs avec ces différents domaines. L’extension ainsi réalisée permettra donc à la méthode de gérer ce nouveau concept, à la fois dans son modèle de produit et dans son modèle de processus, la cohérence entre les deux parties de la méthode ayant été maintenue.

Ci-dessous un exemple d’extension réalisée sur la méthode O*. Cette méthode a été modifiée pour permettre l’intégration d’un modèle de domaines temporels. La Table 5 illustre les parties du produit et du processus concernés par l’extension avant et après la modification. La partie produit est

30

modélisée avec le formalisme objet O* et la partie processus est illustrée avec le formalisme de Nature.

Table 5. Exemple d'application d'une extension

Produit avant extension Processus avant extension

Domaine

Réel Entier

Granule

Chaîne decaractères

Date

< Elément ; Décrire Elément >

< Domaine; Décrire Domaine >

Produit après extension Processus après extension

Domaine

Domaine non Temporel

Domaine Temporel Granule

Domaine Temporel Instant

Domaine Temporel Période

Domaine Temporel Intervalle

Domaine Temporel Instant-A

Domaine Temporel Instant-R

Domaine Temporel Intervalle-A

Domaine Temporel Intervalle-R

< Domaine non Temporel; Décrire Domaine non

Temporel>

< Domaine Temporel; Décrire Domaine

Temporel>

< Domaine Temporel Instant; Décrire

Domaine Temporel Instant >

< Domaine Temporel Période; Décrire

Domaine Temporel Période >

< Domaine Temporel Intervalle; Décrire Domaine Temporel

Intervalle >

<Elément ; Décrire Elément>

< Domaine; Décrire Domaine >

< Domaine Temporel Instant-A; Décrire Domaine Temporel

Instant-A >

< Domaine Temporel Instant-R; Décrire Domaine Temporel

Instant-R >

< Domaine Temporel Intervalle-A; Décrire Domaine Temporel

Intervalle-A >

< Domaine Temporel Intervalle-R; Décrire Domaine Temporel

Intervalle-R >

On peut constater sur cette figure que la méthode a été modifiée, à la fois dans sa partie produit et dans sa partie démarche. Le concept de domaine existant dans la méthode d’origine a été renommé en concept de domaine non temporel et considéré comme un sous-type d’un concept plus général appelé domaine, puis le concept de domaine temporel a été intégré comme un sous-type du concept de domaine défini précédemment. Dans la partie processus, cette nouvelle généralisation a également été prise en compte puisque l’ingénieur d’applications a maintenant la possibilité de choisir une alternative a la description du domaine qui sera de décrire soit un domaine temporel (nouvelle démarche introduite dans la méthode), soit un domaine non temporel (démarche de la méthode d’origine).

7.5 Construction de méthodes par évolution

Cette section présente la stratégie par évolution pour la construction de méthodes (Figure 2). Cette stratégie répond à un besoin fréquemment ressenti qu’est l’évolution d’une méthode existante (la méthode As-Is) vers une nouvelle méthode (la méthode To-Be) satisfaisant de nouveaux besoins d’ingénierie [Ben Ayed05 ; Ralyté05].

Comme le montre la Figure 21, le principe de cette approche est d’utiliser un modèle initial (As-Is) comme une base d’évolution pour aboutir au modèle souhaité (To-Be). Ce principe est appliqué aux modèles de produit et de processus décrivant la méthode As-Is pour obtenir ceux de la méthode To-Be.

31

La difficulté sous-jacente à l’activité d’évolution d’une méthode se résume dans la nécessité de respecter lors de l’activité de ré-ingénierie de ces modèles :

• les exigences d’évolution de départ,

• les règles de construction de méthodes définies par le méta-modèle de méthodes adopté et,

• la cohérence de la méthode To-Be.

Figure 21. Vue générale de l’évolution de méthodes

Cette section est organisée en deux parties : la première est consacrée à la présentation du modèle de processus décrivant l’approche d’évolution de méthodes, la deuxième est consacrée à un cas d’application de l’approche sur la méthode industrielle Lyee.

7.5.1 Modèle de processus d’évolution de méthode

Le modèle de processus de l’approche d’évolution de méthodes est représenté à la Figure 22 en utilisant le formalisme MAP. Il est basé sur trois intentions principales : Spécifier les exigences d’évolution, Evoluer le modèle de produit et Evoluer le modèle de processus. Plusieurs stratégies alternatives sont fournies pour atteindre chacune de ces intentions. La première intention vise à guider l’ingénieur de méthodes dans la collecte et la spécification des exigences d’évolution exprimées par les utilisateurs et les éditeurs de la méthode As-Is. La seconde intention vise plutôt à assister l’activité d’évolution du modèle de produit. La troisième intention, quant à elle, a pour objectif de guider l’évolution du modèle de processus.

32

Figure 22. Modèle de processus d’évolution de méthode

Le modèle de processus d’évolution propose plusieurs démarches alternatives selon la situation d’ingénierie et la spécificité de chaque méthode. Un guidage est offert à l’ingénieur de méthodes dans chaque étape d’évolution pour la prise de décision concernant la progression dans le processus d’évolution.

Spécification des exigences d’évolution L’intention Specifier les exigences d’évolution est le point de départ du processus d’évolution de méthodes. Les exigences d’évolution complètent les objectifs d’ingénierie de méthodes définis précédemment (Figure 2) ; elles peuvent être sous la forme d’un document de besoins informel ou sous la forme d’une carte des exigences utilisant le formalisme MAP.

Pour spécifier les exigences d’évolution, on procède généralement par interview avec les utilisateurs et les éditeurs de la méthode, ces exigences représentent souvent :

• les limites et les problèmes constatés dans la méthode As-Is et les modifications qu’on souhaite lui apporter ;

• les attentes concernant la méthode To-Be, ces attentes peuvent concerner ce que cette méthode doit faire et/ou la manière de le faire.

Une fois spécifiées, les exigences d’évolution sont utilisées comme base dans le reste du processus d’évolution. Dans chaque étape d’ingénierie d’évolution de la méthode As-Is, l’ingénieur de méthodes doit veiller à respecter ces exigences.

Pour atteindre l’intention Spécifier les exigences d’évolution deux stratégies alternatives correspondant à deux situations d’ingénierie différentes sont proposées : Stratégie du processus guidé et Stratégie orienté but. La première stratégie est appliquée dans le cas où on peut connaître dès le début du processus d’évolution, la nature des transformations à apporter à la méthode As-Is et les exigences précises concernant la méthode To-Be. La deuxième stratégie est appliquée dans le cas où les exigences d’évolution que l’on est capable de définir se limitent à énoncer les buts que doivent satisfaire la méthode To-Be sans détailler la nature des transformations à réaliser.

Evolution du modèle de produit Une fois les exigences d’évolution spécifiées, l’ingénieur de méthode peut entamer l’ingénierie d’évolution de la méthode As-Is. Toute méthode étant composée d’un ou plusieurs modèles de produit

33

et d’un ou plusieurs modèles de processus, le projet d’évolution de méthode doit alors toucher chacun de ces modèles. Chaque élément du modèle de processus étant basé sur une partie de produit, chaque transformation touchant cet élément doit alors être répercutée sur la partie de produit correspondante. Inversement chaque modification touchant un élément de produit doit être répercutée sur les éléments du modèle de processus produisant cet élément de produit.

Pour atteindre l’intention Evoluer le modèle de produit trois stratégies sont proposées selon la situation d’ingénierie de chaque méthode : Par abstraction de modèle, Par adaptation de modèle et Par instanciation de méta-modèle. La stratégie de validation est utilisée pour s’assurer de la validité et la cohérence du ou des modèles de produit obtenus par évolution.

Ø Stratégie « Par abstraction de modèle »

La stratégie Par abstraction de modèle est sélectionnée dans le cas où l’on constate lors de l’expérience d’utilisation de la méthode As-Is qu’un modèle de produit de cette dernière contient des éléments n’ayant pas le même niveau d’abstraction. Ce cas de figure rend difficile la compréhension de la méthode et pose plusieurs problèmes lors de son application.

Le déploiement de cette stratégie permet d’abstraire à partir d’un modèle de produit As-Is une nouvelle couche de modèle dont les éléments possèdent un niveau d’abstraction plus élevé. Le modèle de produit résultat sera composé de deux couches ayant deux niveaux d’abstraction différents.

La directive décrivant la stratégie Par abstraction de modèle est formalisée par la carte présentée à la Figure 23. Cette directive contient une seule intention centrale Définir un élément de produit. La réalisation de cette intention est assurée par un ensemble de stratégies, deux de ces stratégies appelées Abstraction dirigée par le produit et Abstraction dirigée par le processus sont utilisées pour le début du processus d’évolution, la première stratégie est en relation avec le modèle de produit As-Is, la deuxième stratégie est en relation avec le modèle de processus As-Is.

Figure 23. Directive associée à la stratégie « par abstraction de modèle »

La stratégie Abstraction dirigée par le produit consiste à analyser le modèle de produit As-Is dans le but d’identifier les éléments qui peuvent être représentés par des concepts d’un niveau d’abstraction plus élevé. Les éléments identifiés seront définis et ajoutés à la nouvelle couche du modèle de produit en cours de construction.

La stratégie Abstraction dirigée par le processus propose d’analyser le modèle de processus As-Is et d’effectuer une abstraction de certaines de ces activités dans un niveau plus élevé. Les éléments de produit correspondant aux nouvelles activités obtenues seront définis et ajoutés à la nouvelle couche du modèle de produit en cours de construction.

La stratégie Top-down mapping est utilisée pour modéliser le lien entre les éléments des deux couches du modèle de produit To-Be obtenus par abstraction.

34

Les stratégies de généralisation, spécialisation, agrégation et décomposition sont utilisées pour raffiner le modèle de produit en cours de construction tandis que la Stratégie d’association est utilisée pour relier les différents éléments de ce modèle.

Ø Stratégie « Par adaptation de modèle »

La stratégie Par adaptation de modèle est sélectionnée dans le cas où la satisfaction des exigences d’évolution suggérerait d’opérer un certain nombre de transformations au modèle de produit As-Is. En appliquant cette stratégie le modèle de produit To-Be est alors obtenu en appliquant un ensemble d’opérateurs d’adaptation au modèle de produit As-Is. Ces opérateurs sont une instance, spécifique à la démarche d’évolution de méthodes, des opérateurs génériques d’IM présentés à la section 7.2.2. La table suivante illustre l’instanciation de ces opérateurs.

Table 6. Instanciation des opérateurs générique d’IM pour l’adaptation de modèles de produit

Opérateur générique

Opérateurs pour l’adaptation du modèle de produit

Classe Attribut Association Composition Est-un Renommer Renommer classe Renommer

attribut Renommer association

N/A N/A

Ajouter Ajouter classe N/A Ajouter association Ajouter comp. Ajouter Est-un Supprimer Supprimer classe N/A Supprimer

association Supprimer comp. Supprimer Est-un

Fusionner Fusionner classes Fusionner attributs

N/A N/A N/A

Fractionner Fractionner classe Fractionner attribut

N/A N/A N/A

Remplacer Remplacer classe Remplacer attribut

N/A N/A N/A

Généraliser Généraliser classe N/A N/A N/A N/A Spécialiser Spécialiser classe N/A N/A N/A N/A Ajouter composant

N/A Ajouter attribut (classe, association)

N/A N/A N/A

Supprimer composant

N/A Supprimer attribut (classe, association)

N/A N/A N/A

Déplacer composant

N/A Déplacer attribut (classe, association)

N/A N/A N/A

Attribuer N/A Attribuer domaine

Attribuer cardinalité N/A N/A

Retirer N/A Retirer domaine Retirer cardinalité N/A N/A Modifier N/A Modifier

domaine Modifier cardinalité N/A N/A

Retyper Retyper Class Retyper attribut Retyper association Retyper comp. Retyper Est-un

Ø Stratégie « Par instanciation de méta-modèle »

La stratégie Par instanciation de méta-modèle est sélectionnée dans le cas où le modèle de produit As-Is est jugé inadéquat pour satisfaire les exigences d’évolution rendant nécessaire son remplacement.

En utilisant cette stratégie le modèle de produit To-Be est alors obtenu par instanciation d’un méta-modèle de produit existant. De nombreux méta-modèles sont disponibles dans la littérature [Grundy 96, Hofstede93, Plihon96, Prakash02, Saeki94], le choix parmi ces méta-modèles etant déterminé par les objectifs et les spécificités de la méthode en cours d’évolution et les exigences d’évolution.

Evolution du modèle de processus L’intention Evoluer le modèle de processus suit celle d’évolution du modèle de produit. Elle consiste d’une part à répercuter les évolutions qu’ont subi les éléments du modèle de produit sur les éléments

35

du processus les manipulant et, d’autre part, à faire évoluer le modèle de processus As-Is pour satisfaire les objectifs d’évolution.

Quatre stratégies correspondant à quatre paradigmes différents pour la construction du modèle de processus sont proposées pour atteindre cette intention : Orientée-patron, Orientée-activité, Orientée-contexte et Orientée-stratégie. La stratégie de validation est appliquée pour tester et garantir la validité et la cohérence du ou des modèles de processus To-Be.

Ø Stratégie « Orientée-activité »

La stratégie Orientée-activité est sélectionnée dans le cas où l’on décide de construire le modèle de processus To-Be comme un processus séquentiel composé d’un ensemble d’activités permettant d’atteindre l’objectif défini pour la méthode.

L’application de cette stratégie permet de guider l’ingénieur de méthode dans la description des activités composant le modèle de processus To-Be ainsi que leur ordonnancement. Les activités sont obtenues par une approche de type décomposition fonctionnelle.

Ø Stratégie « Orientée-patron »

La stratégie Orientée-patron pour la construction du modèle de processus est basée sur l’utilisation des patrons. Le but de cette stratégie est de guider l’évolution du modèle de produit As-Is vers un modèle de processus prenant la forme d’un catalogue de patrons. Chaque patron identifie un problème générique rencontré lors de la construction du produit et propose une solution générique applicable chaque fois que ce problème apparaît. La partie solution du patron peut être exprimée par n’importe quel type de paradigme de modélisation de processus présenté dans cette section.

Figure 24. Directive associée à la stratégie « Orientée-Patron »

La directive de la stratégie Orientée-patron est formalisée par le MAP présenté à la Figure 24. Elle contient deux intentions principales Identifier un patron et Construire un patron. Un patron étant composé de deux parties, le problème et sa solution associé. L’intention Identifier un patron vise à identifier un problème pour lui associer un patron. L’identification du problème peut être basée sur l’identification de situations typiques récurrentes dans la construction du produit ou sur des buts génériques dans le contexte de la méthode. Ces deux cas de figure sont illustrés par les deux stratégies: Basée sur la situation et Dirigée par les buts.

Dans le cas d’identification d’un problème complexe nécessitant d’être décomposé en sous-problèmes pour pouvoir associer une solution à chaque sous-problème, la Stratégie d’agrégation est utilisée pour identifier plusieurs patrons atomiques et les combiner dans un patron composé apportant la solution au problème complexe.

36

L’identification d’une situation conduisant à la création d’un patron nous amène à supposer que l’application d’un autre patron a engendré cette situation, la Stratégie de précédence est utilisée pour l’identification et l’ordonnancement de patrons dans ce cas de figure.

L’intention Construire un patron vise à formaliser le problème (le but et la situation) et de construire la solution à ce problème. Deux stratégies permettent d’atteindre cette intention : Stratégie dirigée par le produit et Stratégie dirigée par les buts. La première stratégie construit la solution du patron en formalisant le processus permettant la production des éléments du produit décrit dans son but à partir de ceux décrits dans sa situation. La deuxième stratégie construit la solution du patron en réduisant son but en un ensemble d’actions atomiques permettant d’opérationaliser ce but.

La Stratégie de succession permet de considérer le produit obtenu par l’application du patron défini comme une situation potentielle pour l’identification d’un autre patron.

Ø Stratégie « Orientée-stratégie »

La stratégie Orientée-stratégie permet de faire évoluer un modèle de processus As-Is en réalisant sa réingénierie en utilisant le formalisme MAP permettant ainsi d’avoir un modèle de processus plus riche et offrant plusieurs démarches alternatives pour la construction du produit.

La directive de cette stratégie est présentée à la Figure 25. Inspirée de la métadémarche proposée dans [Benjamen99], cette directive est composée de deux intentions principales Définir une section et Définir une directive. La première vise la découverte et la définition d’une section composée du triplet <Intention source, Intention cible, Stratégie>. La deuxième a comme objectif d’aider l’ingénieur de méthodes dans la définition des directives associées aux sections (Directives de Réalisation d’Intention, Directives de Sélection d’Intention et Directives de Sélection de Stratégie).

Figure 25. Directive associée à la stratégie « Orientée-stratégie »

Deux stratégies alternatives permettent d’atteindre l’intention Définir une section : la Stratégie structurelle et la Stratégie fonctionnelle. La première est utilisée dans le cas où la méthode As-Is ne dispose pas initialement de modèle de processus ou si celui-ci se limite à une description informelle du produit à construire. La deuxième stratégie est utilisée dans le cas où la méthode As-Is possède un modèle de processus plus sophistiqué, composé d’un certain nombre d’étapes et de fonctions à réaliser et proposant différents moyens et/ou différentes manières pour les effectuer afin d’obtenir le produit. Cette stratégie fournie un guidage à l’ingénieur de méthodes pour l’identification des sections composant le modèle de processus To-Be en se basant sur ces étapes, ces fonctions, ces moyens et ces manières.

Quatre stratégies sont proposées pour la découverte de section à partir de celles déjà définies : Découverte d’alternative, Découverte par progression, Découverte par regroupement et Découverte par décomposition.

37

Pour atteindre l’intention Définir une directive deux stratégies sont fournies, Stratégie d'utilisation de formulaire et Stratégie guidée. La première est destinée aux experts et propose des formulaires prédéfinis selon le type de la directive (DRI, DSI ou DSS) tandis que la deuxième est destinée aux novices et offre un guidage plus détaillée pour la construction de ces directives.

Les deux stratégies : Stratégie de modification et Stratégie de correction entre les deux intentions Définir une section et Définir une directive offrent un guidage à l’ingénieur de méthodes pour affiner et corriger le modèle de processus en cours de construction. En effet, la première stratégie permet de répercuter les modifications apportées aux sections sur les directives associées, tandis que la deuxième permet de corriger une section sur la base de la description de la directive associée.

Ø Stratégie « Orientée-contexte »

La stratégie Orientée-Contexte est appliquée pour construire à partir du modèle de processus As-Is un nouveau modèle de processus basé sur le paradigme de modélisation du processus contextuel utilisé dans la théorie NATURE [Rolland95, Plihon96, Jarke99]. En utilisant ce formalisme le modèle de processus est basé sur une hiérarchie de contexte. Un contexte étant défini comme un couple <Situation, Intention>, la situation représente la partie de produit en cours de transformation et l’intention représente le but à atteindre dans cette situation. L’avantage de l’utilisation du paradigme orientée-contexte est de présenter à la fois les activités composant un processus et les décisions et les contextes qui conduisent à les exécuter.

La directive associée à la stratégie Orientée-contexte est présentée à la Figure 26. Il s’agit d’une directive plan proposant de définir en premier lieu la signature du contexte (1) puis de définir son type (2) et enfin de définir son corps (3).

Figure 26. Directive associée à la stratégie orienté-contexte

7.5.2. Exemple d’application

Cette partie est consacrée au cas d’application de l’approche par évolution pour la construction de méthodes dans le cadre du projet de recherche international Lyee.

Lyee ( GovernementaL MethodologY for softwarE providencE ) est une méthode de développement de logiciels inventée par F. Negoro [Negoro01a,b]. Cette méthode a comme spécificité de réduire le cycle de développement de logiciels en éliminant la phase de programmation et en permettant la génération automatique de code à partir des spécifications déclaratives des besoins de l’utilisateur à l’aide de l’outil LyeeALL.

LyeeALL est l’outil CASE supportant la méthode Lyee. Comme le montre la Figure 27, LyeeALL est composé d’un cadre de référence pour structurer les programmes, d’un moteur Lyee pour contrôler l’exécution des programmes et d’un mécanisme de génération pour générer les programmes à partir des besoins.

38

Figure 27. Architecture de LyeeALL

Au début du projet, il a été constaté que la méthode Lyee était décrite en termes opérationnels de bas niveau et qu’il était difficile de dégager une vue globale et systémique de la méthode. Cette situation rendait difficile la compréhension de cette méthode et posait plusieurs problèmes lors de son application. En effet, il existait un grand écart entre les besoins qui peuvent être exprimés par les utilisateurs des applications à développer et les entrées requises par LyeeALL pour générer ces applications.

L’objectif du projet de recherche Lyee était double : tout d’abord la rétro-ingénierie de la méthode Lyee par la formalisation de ces modèles de produit et de processus, ensuite l’évolution de cette méthode pour proposer une nouvelle méthode supportant le développement de logiciels en deux étapes qui sont l’ingénierie des besoins et la génération automatique de code.

Le reste de ce chapitre présente étape par étape le processus d’évolution de la méthode Lyee existante (la méthode As-Is) vers une nouvelle méthode Lyee centrée sur les utilisateurs (la méthode To-Be) en appliquant la Stratégie par évolution (Figure 2). Selon cette approche, l’ingénieur de méthodes doit commencer par la réalisation de l’intention Spécifier les exigences d’évolution (Figure 22). Suivant la Stratégie orientée-but, on obtient la carte des exigences présentée à la Figure 28. Cette carte contient deux intentions principales Capturer les besoins des utilisateurs et Spécifier les besoins Internes Lyee ; ces deux intentions représentent les buts que doit satisfaire la méthode To-Be.

Figure 28. Carte des exigences pour l’évolution de la méthode Lyee

Ø Evolution du modèle de produit

39

Une fois les exigences d’évolution spécifiées, la deuxième intention à atteindre est l’évolution du modèle de produit. Ainsi, l’ingénieur de méthodes commence par présenter le modèle de produit As-Is de la méthode Lyee. Ce modèle, présenté à la Figure 29, a été défini en utilisant la technique de métamodélisation ; il est dénommé Modèle des Besoins Interne Lyee (MBIL). Le concept central de ce modèle est le Process Route Diagram (PRD). Le PRD fournis le cadre de référence pour structurer les programmes Lyee. C’est un graphe dirigé dans lequel les nœuds sont des instances d’une structure basique appelée Scenario Function (SF). Un SF est une agrégation de trois sous-structures appelées chacune Pallet (W04, W02 et W03). Chaque pallet est décomposé à son tour en plusieurs sous-structures appelées vecteurs (Vectors). Il existe un ensemble particulier de vecteurs associés à chaque pallet, par exemple le pallet W04 est associé à quatre vecteurs L4, O4, S4 et R4.

Un autre concept fondamental dans le MBIL est Word, ce dernier correspond à une variable programme. Comme le montre la Figure 29, ce concept est spécialisé en trois catégories Action Words, Domain Word et Routing Word.

{complete, or}

Action Word

W04

W02

W03

PNTR

PNTD

PNTE

Logical Unit

LogicalIDDevice

SFID

11

1

1

1

1

1

1..*

NextpalletIDRouting Word

WordWordID

Domain Word

L3-conditionL4-formulaNameDomain

PRD1

POP1

PCL1

PCR1 PCR2 PBOXPWT1Word in

Pallet/Unit1..*

InterSF

PNTA PNTM

IntraSF

PNTN

PNTC

PRDPRDName

PalletPalletID

Scenario Function

Condition

{complete, or}

Action Word

W04

W02

W03

PNTR

PNTD

PNTE

Logical Unit

LogicalIDDevice

SFID

11

1

1

1

1

1

1..*

NextpalletIDRouting Word

WordWordID

Domain Word

L3-conditionL4-formulaNameDomain

PRD1

POP1

PCL1

PCR1 PCR2 PBOXPWT1Word in

Pallet/Unit1..*

InterSF

PNTA PNTM

IntraSF

PNTN

PNTC

PRDPRDName

PRDPRDName

PalletPalletID

PalletPalletID

Scenario Function

Condition

Figure 29. Modèle des Besoins Logiciel Lyee

Les Routing Words sont utilisés pour la génération des Routing Vectors qui assurent le branchement d’un pallet vers un autre durant l’exécution des programmes générés par LyeeALL. Il existe deux types de Routing Word les IntraSF et les InterSF. Les IntraSF assurent le branchement entre les différents pallets d’un SF. Les InterSF, quant à eux, assurent le branchement d’un pallet dans un SF vers un autre pallet dans un SF différent. Chacun de ces deux types se décline en plusieurs sous-types (PNTR, PNTN, PNTD, PNTE, PNTC, PNTA et PNTM), chacun de ces sous-types représente un cas particulier de branchement entre pallets.

Les Action Words sont utilisés pour la génération des Action Vectors qui contrôlent les échanges entrée/sortie dans les programmes générés par LyeeALL. Ce concept est spécialisé en sept classes (PRD1, POP1, PCL1, PCR1, PCR2, PBOX et PWT1), chaque classe est utilisée pour contrôler un type particulier d’action physique d’entrée/sortie : lecture, écriture, ouverture ou fermeture de fichier, ré-initialisation d’écran, etc.

Les Domain Words représentent des variables programmes dans un Logical Unit, elles peuvent représenter une variable saisie par l’utilisateur, une variable calculée par le programme ou encore un bouton dans une interface graphique. Le concept Logical Unit représente un ensemble cohérent de Words utilisés dans le même processus (lecture ou écriture) et correspondant à un même support physique (base de donnée, fichier, écran, etc.) utilisé par un programme généré par LyeeALL.

Pour faire évoluer le modèle de produit de la méthode Lyee, l’ingénieur de méthodes sélectionne la stratégie Par abstraction de modèle (Figure 22). Le résultat d’application de cette stratégie est le modèle de produit présenté dans la Figure 30. Ce modèle est composé de deux niveaux, le bas niveau représente le Modèle de Besoins Internes Lyee (MBIL), le haut niveau représente le Modèle de Besoins Lyee Centrés Utilisateur (MBLCU).

40

Lyee User Centric Requirements Layer

Lyee Software Requirements Layer

1 1..*

Item

NameDomain

{complete, or}

InputOutput

source

target LinkCondition

Duplex Continuous Multiplex

NameType

{complete, or}

NodeNodeID

PSGPSGName

0..*

0..*

IntermediateEndBegin

1

1..*1..*

1..*

0..1

{complete, or}

Action Word

W04

W02

W03

PNTR

PNTDPNTE

LogicalIDDevice

Logical Unit

SFID

11

1

1

1

1

1

1..*

NextpalletIDRouting Word Word

WordID

Domain WordL3-conditionL4-formula

NameDomain

PRD1POP1PCL1

PCR1 PCR2 PBOX

PWT1Word inPallet/Unit1..

*

InterSF

PNTA PNTM

IntraSF

PNTN

PNTC

PRDPRDName

PalletPalletID

Passive

Active

{complete, or}

Defined

conditionformula

Scenario Function

Condition

Interaction

Compound Atomic Winput Wouput Wresult Wend

Interaction Goal 1

Legend : Mapping link

Lyee User Centric Requirements Layer

Lyee Software Requirements Layer

1 1..*

Item

NameDomain

{complete, or}

InputOutput

source

target LinkCondition

LinkCondition

DuplexDuplex ContinuousContinuous MultiplexMultiplex

NameType

{complete, or}

NodeNodeID

PSGPSGName

0..*

0..*

IntermediateEndBegin

1

1..*1..*

1..*

0..1

{complete, or}

Action Word

W04

W02

W03

PNTR

PNTDPNTE

LogicalIDDevice

Logical Unit

SFID

11

1

1

1

1

1

1..*

NextpalletIDRouting Word Word

WordID

Domain WordL3-conditionL4-formula

NameDomain

PRD1POP1PCL1

PCR1 PCR2 PBOX

PWT1Word inPallet/Unit1..

*

InterSF

PNTA PNTM

IntraSF

PNTN

PNTC

PRDPRDName

PalletPalletID

PalletPalletID

Passive

Active

{complete, or}

Defined

conditionformula

Scenario Function

Condition

Interaction

Compound Atomic Winput Wouput Wresult Wend

Interaction Goal 1

Legend : Mapping link

Figure 30. Modèle de produit To-Be de la méthode Lyee

En utilisant la stratégie Abstraction dirigée par le produit (Figure 23), le concept Item est obtenu par abstraction à partir du concept Domain Word dans le MBIL. La Stratégie de spécialisation est utilisée pour spécialiser le concept Item en Input et Output. Les Outputs représentent les résultats produits par le système par contre les Inputs représentent les données saisies par l’utilisateur. De la même manière le concept Input est spécialisé en deux concepts Passive et Active. Le premier correspond aux items déclenchant les actions du système (par exemple les boutons dans une interface graphique), le second correspond aux valeurs saisies par l’utilisateur (par exemple une zone de texte dans une interface graphique).

Ensuite, nous analysons le modèle de processus As-Is. Celui-ci a comme objectif la génération automatique de programmes à partir de spécifications déclaratives des besoins des utilisateurs. L’exécution des programmes générés doit satisfaire les besoins des utilisateurs, c’est-à-dire un ou plusieurs de ces buts. Pour cette raison nous devons inclure dans la nouvelle couche de modèle de produit en cours de construction des concepts permettant de définir les buts de l’utilisateur et exprimer comment l’utilisateur interagit avec le système pour les atteindre.

La Stratégie Abstraction dirigée par le processus (Figure 23) nous permet de définir la notion d’interaction dans le MBLCU. Une interaction représente un échange entre l’utilisateur et le système. Cette interaction est orientée-but dans la mesure où l’utilisateur demande au système d’atteindre le but qu’il a en tête sans connaître comment le système va le faire. Par conséquent, le concept de but (Interaction Goal) est définit dans le modèle et nous l’associons à Interaction.

La complexité du but de l’interaction implique la complexité de l’interaction correspondante : si le but de l’interaction peut être décomposé en plusieurs buts atomiques, l’interaction correspondante peut aussi être décomposée. Pour cette raison, l’interaction est spécialisée en composée (Compound) et atomique (Atomic) en utilisant la Stratégie de spécialisation.

41

Figure 31. Vue générale d’une interaction

Une interaction atomique implique la manipulation de données en entrée et en sortie. En effet, comme le montre la Figure 31, l’utilisateur fournit un ensemble de données en input et reçoit en sortie les résultats satisfaisant son but. La Stratégie de décomposition nous permet de décomposer chaque interaction en quatre types d’items : Winput , Woutput , Wresult et Wend.

• Winput : représente les entrées fournies par l’utilisateur,

• Wresult : représente les résultats de la réalisation du but,

• Woutput : représente les sorties affichées à l’utilisateur

• Wend : représente la fin de l’interaction.

Par la suite la stratégie Abstraction dirigée par le produit (Figure 23) est appliquée pour abstraire le concept Defined à partir de celui de Logical Unit. D’une manière similaire le concept PSG (Precedence Succedence Graph) dans le MBLCU est obtenue par abstraction à partir du concept PRD dans le MBIL. La Stratégie de décomposition est utilisée par la suite pour définir la structure du PSG comme un graphe composé de liens (Link) et de nœuds (Node). Grâce à la Stratégie de spécialisation, un lien (Link) est spécialisé en Duplex, Continuous et Multiplex par contre le nœud (Node) est spécialisé en Begin, End et Intermediate.

Ø Evolution du modèle de processus

Cette section est consacrée à l’illustration du processus d’évolution du modèle de processus de la méthode Lyee. En se basant sur la carte des exigences (Figure 28), le modèle de processus To-Be doit satisfaire les objectifs suivants:

1. systématiser la capture des besoins des utilisateurs et leur formulation conformément au MBLCU,

2. systématiser la génération des besoins internes Lyee à partir des besoins Lyee centrés utilisateur.

La stratégie Orientée-Patron est utilisée pour évoluer le modèle de processus de la méthode Lyee (Figure 22). Le modèle de processus To-Be est alors construit sous la forme d’un Catalogue de patrons permettant d’atteindre les objectifs énoncés.

La directive supportant la stratégie Orientée-Patron (Figure 24) suggère de commencer le processus d’évolution par l’identification de patrons. Pour cela, nous appliquons la stratégie Dirigée par les buts en se basant sur les deux buts principaux : « Formuler les besoins des utilisateurs » et « Générer les besoins internes Lyee ».

• Formuler les besoins des utilisateurs

Comme énoncé dans la section précédente, la démarche d’expression des besoins des utilisateurs dans la méthode Lyee To-Be est centrée sur le concept d’interaction. Ainsi, l’identification de patrons correspondant au but Formuler les besoins des utilisateur est fondé sur ce concept et consiste à identifier les activités génériques permettant l’expression des besoins dans ce contexte. Quatre activités ont été identifiées suivant ce raisonnement :

• « Commencer une interaction » qui peut être associé au but : Formuler les besoins ‘To Start’

42

• « Réaliser les traitements » qui peut être associé au but : Formuler les besoins ‘To Act’

• « Préparer les sorties » qui peut être associé au but : Formuler les besoins ‘To Output’

• « Terminer l’interaction » qui peut être associé au but : Formuler les besoins ‘To End’.

Chacune de ces activités est reliée à la typologie des Words présentée dans le paragraphe précédent. Elles concernent la collecte et la spécification des words, leur groupement dans des defined et leur positionnement dans le psg correspondant à l’interaction.

− Commencer une interaction est en relation avec la capture des Winput

− Réaliser les traitements est en relation avec le calcul des Wresult

− Préparer les sorties est en relation avec la définition des Woutput

− Terminer l’interaction est en relation avec la détermination des Wend

Figure 32. Activités génériques pour la capture des besoins d’une interaction atomique

Ensuite, la stratégie Basée sur la situation est sélectionnée pour identifier les patrons correspondant aux quatre buts découverts (Figure 32). Selon cette stratégie, les différentes situations associées à chacun de ces buts sont identifiées. Par exemple, on peut distinguer deux situations différentes lors de la capture des Winput ; la première concerne le cas où les entrées sont directement saisies par l’utilisateur, la deuxième correspond au cas où ces valeurs sont obtenues via un accès à un fichier ou à une base de donnée. On identifie alors deux patrons ayant le même but Formuler les besoins ‘To Start’ mais ayant deux situations différentes les Inputs capturés à partir de l’utilisateur et les inputs capturés à partir d’un support interne. Ces deux patrons sont appelés P2 Immediate Start et P3 Prequisite for Start. D’une manière similaire on identifie deux situations génériques différentes pour chaque but et on associe un patron à chaque couple <but, situation>. Huit patrons génériques sont identifiés suivant le même principe ; ils sont récapitulés dans la Table 2.

Table 2 : Patrons associés au but Formuler les besoins des utilisateurs

But Situation Nom du Patron

Formuler les besoins ‘To Start’ Les Winput sont saisis directement par l’utilisateur

P2 Immediate Start

Formuler les besoins ‘To Start’ Les Winput sont extraits à partir d’une base de données ou un fichier

P3 Prequisite for Start

Formuler les besoins ‘To Act’ Les Wresult sont calculés par une formule simple qui ne nécessite pas le calcul de words intermédiaires

P1 Simple Word

43

Formuler les besoins ‘To Act’ Les Wresult sont calculés par une formule complexe qui nécessite le calcul de words intermédiaires et éventuellement des accès à la base de données

P8 Complexe Word

Formuler les besoins ‘To Output’ Pas d’obstacles dans la capture de Winput et dans la production des Wresult

P6 Single Output

Formuler les besoins ‘To Output’ Plusieurs cas pour la production de sorties sont considérés à cause d’éventuels obstacles dans la capture de Winput ou la production des Wresult

P7 Multiple Output

Formuler les besoins ‘To End’ L’interaction se termine normalement sans opération interne supplémentaire

P4 Simple End

Formuler les besoins ‘To End’ Une ou plusieurs opérations internes sont effectuées à la fin de l’interaction comme la sauvegarde de la totalité ou d’une partie des Woutput

P5 Compound End

Formuler les besoins d’une interaction atomique

Le but de l’interaction est atomique P9 Simple Composition

Formuler les besoins d’une interaction composée

Le but de l’interaction est composé P10 Complex Composition

Chacun des huit patrons (de P1 au P8) correspond à une activité de besoin atomique. La capture de l’ensemble des besoins correspondant à une interaction atomique requiert l’exécution de chacune des activités ‘To Start’, ‘To Act’, ‘To Output’ et ‘To End’. La Stratégie d’agrégation (Figure 24) est appliquée pour identifier le patron P9 Simple composition permettant de composer la solution correspondante à une interaction atomique comme une suite de quatre patrons atomiques.

La Stratégie de succession (Figure 24) nous suggère de réfléchir sur l’identification de patrons correspondant à une interaction composée. Ainsi, le patron P10 Complex Composition est identifié. Il est dédié à la formulation des besoins associés à une interaction composée. Il appelle le patron P9 pour chaque interaction atomique la composant.

La deuxième intention à atteindre dans la directive associée à la stratégie Orientée-patron (Figure 24) est la construction des patrons identifiés. Pour cela nous sélectionnons la Stratégie dirigée par le produit, celle-ci nous guide dans la définition de solution associée à chaque patron. Cette solution est définie par un ensemble d’activités permettant de satisfaire le but du patron.

Comme exemple, nous illustrons la construction du patron P2. Le but de ce patron consiste à formuler les besoins ‘To Start’. Il est donc nécessaire d’instancier les éléments (Defined, Item et PSG) qui sont utilisés pour capturer les valeurs en entrées. La Figure 33 présente le patron P2 comme suit : la première section introduit le nom du patron, la seconde section présente le problème (le but et la situation), la troisième section présente la solution proposée.

Patron P2: Immediate Start

Problème:

<But : Formuler les besoins ‘To Start’>

<Situation : Winput <= Captureuser( )>

Solution :

44

1. Créer un defined Sinput de type écran, déterminer son nom (name)

2. Eliciter les items associés au Winput

3. Lier les items au defined, déterminer pour chaque item son nom et domaine (domain)

4. Typer les items comme input et passive

5. Créer un psg avec le defined comme intermediate node et le lier à partir du nœud start avec un continuous link.

Figure 33. Patron P2 Immediate Start

Une présentation détaillée des 10 patrons et leur validation à travers des cas d’étude est disponible dans [Ben Ayed03a, Rolland02a,b, Rolland03].

• Générer les besoins internes Lyee

La réalisation du but Générer les besoins internes Lyee permet la transformation de l’ensemble des besoins des utilisateurs capturés en appliquant les 10 patrons présentés ci-dessus en un ensemble de besoins internes Lyee. La Stratégie basée sur la situation (Figure 24) aide à analyser les situations possibles associées à ce but. Une seule situation est identifiée : Les besoins des utilisateurs sont capturés correctement. De ce fait, un seul nouveau patron est crée P11 Generate LSR La Stratégie dirigée par le produit (Figure 24) aide à .construire la solution de ce patron. Cette stratégie nous suggère d’identifier les activités permettant de générer une instance du MBIL à partir d’une instance du MBLCU. Deux stratégies alternatives pour effectuer cette génération ont été découvertes : One to One Mapping et N to M Mapping. La première stratégie est entièrement automatisée par contre la seconde stratégie nécessite l’intervention de l’ingénieur Lyee pour statuer sur les différentes décisions concernant la génération. La solution de ce patron propose alors le choix entre ces deux stratégies. Chaque stratégie est composée d’un ensemble de règles de génération (R0, R1S11, R2S11, etc.), la description détaillée de toutes ces règles est disponible dans [Ben Ayed03b]. Le patron P11 est représenté à la Figure 34 ci-dessous.

Patron P11 : Generate LSR

Problème :

< But : Générer les besoins Internes Lyee à partir des besoins Lyee centrés utilisateur

< Situation : Les besoins des utilisateurs sont capturés correctement>

Solution :

Appliquer une des deux stratégies de génération

Ø Stratégie One to One Mapping

1. Appliquer R0 : Transformer PSG

2. Appliquer R1S11 : Transformer intermediate nodes

3. Appliquer R2S11 : Transformer defineds et items

4. Appliquer R3S11 : Transformer links

5. Appliquer R4 : Completer le mapping pour les éléments internes Lyee additionnels

Ø Stratégie N to M Mapping

1. Appliquer R0 : Transformer PSG

2. Appliquer R1T_FC : Transformer intermediate nodes avec la tactique Father-Child merge

ou

Appliquer R1T_B : Transformer intermediate nodes avec la tactique Brotherhood merge

3. Appliquer R2T_FC : Transformer defineds et items avec la tactique Father-Child merge

45

ou

Appliquer R2T_B : Transformer defineds et items avec la tactique Brotherhood merge

4. Appliquer R3T_FC : Transformer links avec la tactique Father-Child merge

ou

Appliquer R3T_B : Transformer links avec la tactique Brotherhood merge

5. Appliquer R4 : Completer le mapping pour les éléments internes Lyee additionnels

Figure 34. Patron P11

7.7 Conclusion

Dans ce chapitre, plusieurs approches, techniques et outils d’ingénierie de méthodes ont été présentées. Nous nous sommes intéressés à l’ingénierie des méthodes situationnelles, et tout particulièrement, aux approches de construction de méthodes à base de composants réutilisables. Par un composant réutilisable nous considérons ici toute partie consistante, cohérente et autonome de méthode. Le composant de méthode présenté au chapitre 4 de ce livre est un exemple de composant réutilisable dans la construction de nouvelles méthodes, un patron de produit ou de processus pour l’extension des méthodes existantes en est un autre. Finalement, tout modèle ou métamodèle est également considéré comme un composant réutilisable dans le processus d’IM.

Les approches présentées et illustrées dans ce chapitre, à savoir, l’approche par assemblage de composants de méthodes, l’approche par extension de méthodes existantes avec des patrons d’extension et l’approche par évolution vers des nouvelles méthodes, sont intégrées dans un modèle générique d’IM. Ce dernier est représenté en utilisant le formalisme MAP (voir le chapitre 3) basée sur deux intentions principales d’ingénierie de méthodes : (1) définir l’objectif d’ingénierie de méthodes et (2) construire une méthode satisfaisant cette objectif. Les trois approches représentent les trois stratégies de construction de méthodes à base de composants.

L’intégration des trois approches dans un modèle générique offre plusieurs avantages :

− Tout d’abord, le modèle générique guide l’ingénieur de méthodes dans son choix de l’approche la mieux adaptée à la situation en cours en lui proposant des arguments justifiant la sélection de chaque stratégie.

− La typologie des opérateurs génériques proposée par ce modèle offre un moyen sûr et rapide pour la définition des opérateurs spécifiques à chaque approche d’IM. Les opérateurs spécifiques sont obtenus par instanciation des opérateurs génériques.

− Il est possible de combiner différentes approches dans le même processus d’IM. Par exemple, la méthode obtenue par assemblage de composants peut être ensuite étendue avec des propriétés manquantes en utilisant la stratégie par extension ou transformée en une autre méthode par évolution.

− La flexibilité et l’évolutivité du formalisme MAP utilisé pour représenter le modèle générique permettent de compléter ce dernier avec de nouvelles approches intégrées sous forme de nouvelles stratégies.

Finalement, les trois approches d’IM par composition présentées dans ce chapitre guident l’ingénieur de méthodes lors de la construction de méthodes situationnelles ‘à la volée’.

Références

[Alexander77] C. Alexander, S. Ishikawa, M. Silverstein et al., “A Pattern Language”, Oxford University Press, New York 1977.

46

[Beck97] Beck, K., Smalltalk, Best Practice Patterns. Volume 1, Coding, Prentice Hall, Englewood Cliffs, NJ, 1997

[Ben Ayed03a] M. Ben Ayed, S. Nurcan, Technical Report TR2-1, Lyee International Research Project, Université Paris 1, 2003.

[Ben Ayed03b] M. Ben Ayed, S. Nurcan, Technical Report TR2-2, Lyee International Research Project, Université Paris 1, 2003.

[Ben Ayed05] M. Ben Ayed, J. Ralyté, C. Rolland, “Constructing the Lyee Method with a Method Engineering Approach”, Knowledge-based Systems journal, To be published 2005.

[Benjamen99] A. Benjamen, Une Approche Multi-démarches pour la modélisation des démarches méthodologique. Thèse de doctorat en informatique de l'Université Paris 1, 1999.

[Brinkkemper 98] Brinkkemper S., Saeki, M., Harmsen, F. Assembly Techniques for Method Engineering. Proceedings of the 10th International Conference CAiSE’98. Pisa, Italy, 1998.

[Buschmann96] Buschmann, F., Meunier, R., Rohnert, et al., Pattern-Oriented Software Architecture - A System of Patterns, John Wiley, 1996

[Coad92] Coad, P., Object-Oriented Patterns, Communications of the ACM, Vol. 35, No. 9, 1992, pp 152-159

[Cockburn00] Cockbrn, A. Writing Effective Use Cases. Addison Wesley, 2000. [Coplien95] Coplien, J.O., and Schmidt, D.O. (ed.), Pattern Languages of Program Design, Addison-

Wesley, Readind, MA, 1995 [Deneckere01] Deneckere, R., Approche d’extension de méthodes fondée sur l’utilisation de

composants génériques, PhD thesis, University of Paris 1-Sorbonne, 2001. [Deneckere02] Deneckere, R. Using Meta-patterns to Construct Patterns. Proc. of the Conference on

Object-Oriented Information Systems, OOIS'2002, Springer, France, 2002. [Deneckere98] Deneckere, R., Souveyet, C., Patterns for extending an OO model with temporal

features. Proceedings of OOIS’98 conference. Springer-Verlag, Paris (France), 1998. [Fowler97] Fowler, M., Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997 [Gamma94] Gamma, E., Helm, R., Johnson, R., et al., Design Patterns: Elements of Reusable Object-

Oriented Software, Addison Wesley, 1994 [Grundy 96] J.C. Grundy, J.R.Venable, Towards an integrated environment for method engineering,

Proc. IFIP WG 8.1 Conf. on method Engineering, Chapman and Hall, pp 45-62, 1996 [Grundy96] Grundy, J.C., Venable, J.R. Towards an Integrated Environment for Method Engineering.

In Challenges and Strategies for Research in Systems Development. W.W. Cotterman and J.A. Senn (Eds.). John Wiley & Sons. Chichester. pp. 45-62, 1996.

[Gupta01] Gupta, D., Prakash, N. Engineering Methods from Method Requirements Specifications. Requirements Engineering Journal, Vol.6, pp.135-160, 2001.

[Harmsen94] Harmsen A.F., Brinkkemper, S., Oei, H. Situational Method Engineering for Information System Projects. In Olle T.W. and A.A. Verrijn Stuart (Eds.), Mathods and Associated Tools for the Information Systems Life Cycle, Proceedings of the IFIP WG8.1 Working Conference CRIS'94, pp. 169-194, North-Holland, Amsterdam, 1994.

[Harmsen97] Harmsen, A.F. Situational Method Engineering. Moret Ernst & Young, 1997. [Hay96] Hay, D., Data Model Patterns: Conventions of Thought, Dorset House, NY, 1996 [Heym93] Heym, M., Osterle, H. Computer-aided methodology engineering. Information and

Software Technology, Vol. 35 (6/7), June/July, pp. 345-354, 1993. [Hofstede93] A.H.M. ter Hofstede, Information Modelling in Data Intensive Domains, Dissertation,

University of Nijimegen, the Netherlands, 1993. [Jarke99] M. Jarke, C. Rolland, A. Sutcliffe, R. Domges, The NATURE Requirements Engineering,

Shaker, Aachen, 1999. [Kumar92] Kumar, K., Welke, R.J. Method Engineering, A Proposal for Situation-specific

Methodology Construction. In Systems Analysis and Design: A Research Agenda, Cotterman and Senn (eds), Wiley, pp257-268, 1992.

[Mirbel02] Mirbel, I., de Rivieres, V. (2002). Adapting Analysis and Design to Software Context: The JECKO Approach. Proceedings of the International Conference on Object-Oriented Information Systems, OOIS’02, Montpellier, France, LNCS 2425, Springer, pp. 223-228..

[Negoro01a] F. Negoro, ‘Methodology to Determine Software in a Deterministic Manner’, Proceeding of ICII, Beijing, China, 2001.

47

[Negoro01b] F. Negoro, ‘A proposal for Requirement Engineering’, Proceeding of ADBIS, Vilnius, Lithuania, 2001.

[Plihon96] V. Plihon, Un environnement pour l'ingénierie des méthodes, Thèse de doctorat de l'Université Paris 1, janvier 1996.

[Prakash02] Prakash, N., Bhatia, M. P. S. Generic Models for Engineering Methods of Diverse Domains. Proceedings of CAISE’02, Toronto, Canada, LNCS 2348, pp. 612., 2002.

[Prakash97] Prakash, N. Towards a formal definition of methods. RE Journal, 2 (1), 1997. [Punter96] Punter H.T., Lemmen, K. The MEMA model : Towards a new approach for Method

Engineering. Information and Software Technology, 38(4), pp.295-305, 1996. [Ralyté04] J. Ralyté, C. Rolland, R. Deneckère, Towards a Meta-tool for Change-centric Method

Engineering: a Typology of Generic Operators, CAISE’04, Riga, Latvia, 2004. [Ralyté01a] Ralyté, J., Rolland, C. An Assembly Process Model for Method Engineering. Proceedings

of the 13th CAISE’01, Interlaken, Switzerland, 2001. [Ralyté01b] Ralyté, J., Rolland, C. An approach for method reengineering. Proceedings of the 20th

ER2001, Yokohama, Japan, LNCS 2224, Springer, pp.471-484, 2001. [Ralyté03] Ralyté, J., Deneckère, R., Rolland, C. Towards a Generic Model for Situational Method

Engineering. Proceedings of the 15th International Conference CAISE’03, Klagenfurt/Velden, Austria, LNCS 2681, Springer, pp. 95-110, 2003.

[Ralyté05] Ralyté, J., Rolland, C., Ben Ayed, M. An Approach for Evolution Driven Method Engineering. In Information Modeling Methods and Methodologies. J. Krogstie, T. Halpin, K. Siau (Eds.), Idea Group, Inc., USA, 2005.

[Rolland02a] C. Rolland, A User Centric View of Lyee Requirement, Proceeding of Lyee-W02 : New Trends in Software Methodologies, Tools and Techniques, pp. 155-169, Paris, 2002.

[Rolland02b] C. Rolland, Technical Report TR1-2, Lyee International Research Project, University Paris 1, 2002.

[Rolland03] C. Rolland, C. Souveyet, M. Ben Ayed, Guiding Lyee user requirements capture, Knowledge Based System Journal, Intention and Software Process 16 (7–8) (2003) 351–359.

[Rolland95] C. Rolland, C. Souveyet, M. Moreno. An Approach for Defining Ways-Of-Working, in the Information Systems Journal, 1995.

[Rolland96a] Rolland, C., Plihon, V. Using generic chunks to generate process models fragments. Proceedings of 2nd IEEE International Conference on Requirements Engineering, ICRE'96, Colorado Spring, 1996.

[Rolland96b] Rolland, C., Prakash, N. A proposal for context-specific method engineering. Proceedings of the IFIP WG 8.1 Conference on Method Engineering, Chapman and Hall, pp 191-208, Atlanta, Gerorgie, USA, 1996.

[Rolland98a] Rolland, C., Plihon, V., Ralyté, J. Specifying the reuse context of Scenario Method Chunks. Proceedings of the 10th International Conference CAISE'98, Pisa, Italy, 1998.

[Rolland98b] Rolland C., C. Souveyet, C. Ben Achour, Guiding Goal Modelling Using Scenarios. IEEE Transactions on Software Engineering, 24 (12), 1055-1071, Dec. 1998.

[Rolland98c] Rolland C., C. Ben Achour, Guiding the construction of textual use case specifications. Data & Knowledge Engineering Journal, 25(1), pp. 125-160, March 1998.

[Rossi00] Rossi, M., Tolvanen, J-P., Ramesh, B., Lyytinen, K., Kaipala, J. Method Rationale in Method Engineering. Proceedings of the 33rd Hawaii International Conference on Systems Sciences, 2000.

[Saeki94] M. Saeki, K. Wen-yin, Specifying Software Specification and Design Methods, Proceedings of Conference on Advanced Information Systems Engineering, CAISE'94, Lecture Notes in Computer Science 811, Springer Verlag, pp. 353-366, Berlin, 1994.

[Saeki03] Saeki, M. Embeding metrics into Information Systems Development methods: An Application of method Engineering Technique. Proceedings of the 15th International Conference CAISE’03, Velden, Austria, LNCS 2681, Springer, pp. 374-389, 2003.

[Snodgrass98] Snodgrass, I. Ahn. A ytaxonomy of time in databases. Proceedings of ACM SIGMOD conference. 1985.

[Song97] Song, X. Systematic Integration of Design Methods. IEEE Software, 1997. [Tolvanen96] Tolvanen, J-P., Rossi, M. & Liu H., Method Engineering : Current research directions

and implications for future research. In Method Engineering: Principles of method construction and

48

tool support. S. Brinkkemper, K. Lyytinen, R.J. Welke (Eds.), Proceedings of the IFIP TC8 WG8.1/8.2. Atlanta, USA, pp. 296-317, 1996.

[Tolvanen98] Tolvanen, J.-P. Incremental Mehtod Engineering with Modeling Tools: Theoretical Principles and Empirical Evidence. PhD Dissertation. University of Jyväskylä, Finland, 1998.