Phase 1 : Détection des changements

La phase de détection des changements a pour objectif d’identifier les changements apportés aux modèles lors de leur évolution, tel que l’ajout d’un élément, sa modification ou sa suppression. Dans la section suivante (V.3.1), nous explicitons la manière de représenter ces changements dans le métamodèle MMC. La façon dont ces changements sont détectés est traitée dans la section V.3.2.

V.3.1. Extension du métamodèle MMC

Afin de représenter ces évolutions, nous avons étendu le MMC (voir le premier encadré de la Figure V-4) en introduisant les concepts suivants :

 History : méta-classe utilisée pour garder trace des changements appliqués,

 DiffElt : méta-classe abstraite qui permet d’enregistrer, une fois spécialisée, la trace des éléments ayant évolué. Elle possède deux attributs. Le premier contient le type de classification du changement (cf. section V.4) et le second contient la référence de l’élément construite à partir du nom de l’élément, de son méta-élément et du nom du modèle,

 DeletedElt : méta-classe qui représente un élément qui n’existe plus dans le modèle initial, mais qui est maintenu pour que sa trace soit conservée,

 ModifiedElt : méta-classe représentant un élément de modèle résultant d’une opération de modification d’un élément du modèle initial.

V.3.2. Enrichissement du M1C

L'extension du métamodèle MMC permet de mémoriser les différents changements sans définir comment détecter ces changements. Ce point fait l’objet de cette section.

Une solution pour résoudre le problème de détection automatique des changements est d’utiliser des techniques de calcul des discordances qui produisent un delta (∆) entre le modèle initial et le modèle ayant évolué. Comme exemple de Framework intégrant ces techniques, on peut citer EMFCompare (Brun et Pierantonio, 2008), qui fournit un algorithme générique pour le calcul des différences entre deux versions d’un modèle en se basant sur les techniques structurelles de calcul de distances. En se basant sur le delta entre deux modèles, on peut identifier les évolutions et les ajouter au modèle de correspondance (cf. Figure V-3).

Figure V-3 : Identification des changements avec EMFCompare

Cependant, cette approche qu’on peut qualifier d’approche en «temps différé» étant donné que l’information sur les changements se fait à la demande et non en temps réel, possède certains inconvénients qui la rendent lourde à mettre en œuvre :

 Restriction sur le nombre de modèles, étant donné que la comparaison ne peut être faite à la fois que sur un modèle (Model) et sa version précédente (Model_bis). De ce fait, pour un nombre n de modèles susceptibles d’avoir subi un changement, n deltas sont créés,

 Nécessité de conserver la version initiale de chaque modèle et celle qui a été modifiée,

 Appel de la procédure d’enrichissement du M1C pour chaque delta généré.

Pour remédier à ces inconvénients, nous proposons une solution fondée sur une approche en temps réel de détection automatique des changements. Cette solution consiste à utiliser le patron de conception Observateur (Observer)(Gamma et al., 1994, Larman, 2005). Le deuxième encadré de la Figure V-4 présente l’application de ce patron en l’intégrant au MMC. Le concept ModelElement représente le sujet concret à observer. Ce dernier est une spécialisation du concept Subject qui possède trois méthodes. Deux d’entre elles (attach et detach) permettent de fixer ou de détacher un objet observateur d’un élément de modèle. La troisième méthode (notify) permet de notifier le M1C des changements qui ont eu lieu. La méthode update de la méta-classe Observer est utilisée lors de la phase de traitement des changements afin de maintenir la cohérence des modèles. L’implémentation de ce patron de conception permet, en temps réel, d’informer le modèle de correspondance des différentes manipulations apportées aux modèles du domaine

Figure V-4 : Extension du métamodèle de correspondance MMC

Pour des raisons de clarté de présentation et afin de ne pas surcharger le M1C présenté sur la Figure IV-21 du chapitre précédent, nous avons décidé de faire abstraction de la syntaxe concrète et de représenter le M1C par le Tableau V-1 afin de suivre plus facilement les différentes phases du processus de maintien de la cohérence.

Le tableau ci-dessous se lit de la façon suivante. La première ligne par exemple signifie que la correspondance C1, non obligatoire (mandatory = false), relie, par le type de relation Similarity avec une valeur de priorité de 1, l’élément author (de type StereotypedEntity) du modèle de conception logicielle avec l’élément AuthorTable(de type Table)du modèle de persistance.

Nous avons attribué, lors de la mise en correspondance des méta-éléments (Section IV.6), les valeurs de priorité 1, 1, 2, 2, 3, 4, 5 respectivement aux types de relation Similarity, Dependency, Aggregation, Generalization, Play, Contribution et Requirement.

1 Software Design 2 Business Process 3 Persistence

Correspondance Type de relation Elément de modèle

Nom Obligatoire Nom Priorité SD1 BP2 PS3

C1 Non Similarity 1 StereotypedEntity:Author Table:AuthorTable

C2 Non Similarity 1 Entity:Paper Table:ArticleTable

C3 Oui Equality 1 Property:organization Column:organization

C4 Oui Equality 1 Property:address Column:address

C5 Non Similarity 1 Entity:Reviewer Table:ReviewerTable

C6 Non Aggregation 1 Property:firstName, Property:lastName

C7 Non Aggregation 1 Property:details Column:reviews, Column:decision

C8 Oui Equality 1 Property:submissionDate Column:submissionDate

C9 Non Similarity 1 Entity:Review DataObject:reviews

C10 Oui Requirement 5 Task:logIn Column:password, Column:e-mail

C11 Oui Contribution 4 Operation:reviewPaper() Task:Edit review

C12 Oui Contribution 4 Operation:reviewPaper() Task:Outsource paper

C13 Oui Contribution 4 Operation:createCom() Task:Enter comment

C14 Non Similarity 1 Entity:Comment DataObject:comment

C15 Non Play 3 StreotypedEntity:Reviewer Pool:Reviewer

C16 Non Similarity 1 DataObject:review Column:reviews

Tableau V-1 : Représentation simplifiée sous forme de tableau du M1C

La première partie du Tableau V-2 illustre certaines évolutions effectuées sur les modèles du CMS. Ces évolutions sont automatiquement détectées via l’outil et ajoutées au M1C, en fonction du type du changement. Premièrement, nous supposons que l’architecte de procédé a ajouté les rôles de président (Chairman) et d’auteur (Author) au modèle du processus métier. Deuxièmement, nous faisons l’hypothèse que l’architecte logiciel et l’architecte de procédé ont supprimé des éléments de modèle. Le premier a supprimé l’élément Property:phoneNumber ainsi que l’élément Entity:Comment alors que le deuxième a supprimé l’élément Task:outsource paper. Troisièmement, nous supposons que l’architecte logiciel a changé l’élément createCom( ) de type Operation par l’élément createComments( ) et qu’il a aussi remplacé l’élément Review de type Entity par l’élément Note.

Le mode de traitement d’un changement est fortement lié à son type et aux éléments affectés. La deuxième phase du processus, détaillée dans la section suivante, consiste à analyser les changements, en complétant le M1C (deuxième partie du Tableau V-2).