Expression et usage de la variabilité dans les patrons de conception Nicolas Arnaud — Agnès Front — Dominique Rieu LSR-IMAG, équipe SIGMA 681 rue de la passerelle BP 72 38402 Saint Martin d’Hères Cedex {prenom.nom}@imag.fr

[Chercheur]

RÉSUMÉ. La description d’un patron de conception ne se résume pas à la solution généralement semi-formelle et limitée à un diagramme de classes. L’application (imitation) d’un patron est certes dépendante des rubriques solutions mais bon nombre d’informations utiles à cette opération sont disponibles dans d’autres rubriques. Le concepteur de patrons y détaille souvent des variantes pour sa solution principale et il serait dommage de ne pas les exploiter lors du processus d’imitation, d’autant plus que ces variantes ont, la plupart du temps, des conséquences sur la spécification de la solution semi-formelle. Nous proposons au concepteur de patrons de représenter sa solution semi-formelle comme un mini-système à variantes dont le pilier central, exprimant la variabilité, est la vue des cas d’utilisation. Ce sous-modèle est le point d’entrée de notre processus d’imitation puisqu’on y opérera en premier lieu une sélection du jeu de variantes que l’on désire « imiter ».

ABSTRACT. A design pattern description is much more complex than a semi-formal solution restricted to a class diagram. Applying a pattern first depends on the solution specification but a lot of useful information can be founded into other items. Overlooking variants that the pattern engineer precised about his main solution may unserve the pattern itself because, most of the time, it has an effect on the solution specification. We purpose that pattern engineer represents his solution as a variable mini-system leaded by a use case view expressing variants. This functional model fragment is the entrance point for our imitation process, where application designer will select variants to imitate.

MOTS-CLÉS : patrons de conception, variabilité, processus d’imitation, UML 2

KEYWORDS: design patterns, variability, imitation process, UML2.

1. Introduction

L’exigence de qualité des systèmes d’information implique rigueur et continuité

dans les différentes phases de développement. Il est donc crucial de capitaliser les

savoirs et les savoir-faire afin de les réutiliser au cours d’autres processus de

développement. Nous considérons la réutilisation comme un gage de cette qualité, et

particulièrement si elle met en œuvre une traçabilité modulaire des spécifications.

Les patrons appliqués à l’ingénierie des systèmes, sont des outils particulièrement

pertinents pour ce type d’approche.

Un patron décrit un problème fréquemment rencontré dans un contexte ainsi que

la solution consensuelle qui le résout. Dans le domaine des systèmes informatiques

et pour ce qui nous intéresse dans celui de la conception de systèmes d’information,

on peut bien évidemment citer les patrons de conception et parmi les plus connus

ceux du Gang of Four (GoF) (Gamma et al., 1995), qui nous serviront à la fois de référence et d’exemple pour notre démonstration.

Le processus de réutilisation d’un patron, que nous appelons Imitation, permet d’extraire la solution du patron et de l’appliquer dans un système en construction.

Cependant, il n’y a pas de bonne imitation s’il n’y a pas de bonne spécification de la

solution.

Une bonne spécification est avant tout une spécification complète qui ne peut

être atteinte en recourant seulement à la modélisation statique (diagrammes de

classes). C’est pourquoi nous pensons qu’il est judicieux, à l’instar d’un système

d’information classique, de prendre en compte plusieurs aspects de la solution. Nous

identifions trois vues complémentaires : la vue des cas d’utilisation, la vue

dynamique et la vue statique.

Néanmoins, rendre sa solution semi-formelle complète sémantiquement n’est pas

suffisant pour retranscrire tous les apports d’un patron. Dans de nombreux cas, et

particulièrement pour le GoF, la description du patron est clairsemée d’informations

exprimant des variantes possibles de cette solution, et ceci selon tous les aspects :

fonctionnels, dynamiques ou statiques.

Nous proposons dans un premier temps (§2) une spécification plus complète,

sous la forme d’un mini-système, des patrons de conception et y greffons par la suite

un procédé d’expression de la variabilité (§3). La réutilisation des spécifications

ainsi produites est mise en œuvre au sein d’un processus d’imitation (§4). Le patron

« Observateur » du GoF sert d’illustration tout au long de l’article.

2. Une première approche : un mini-système complet

Le domaine de la conception des systèmes d’information est riche de processus

de développement (RUP, 2TUP,…) qui combinent aspects fonctionnels, dynamiques

et statiques. Il est naturel de proposer une approche similaire pour les mini-systèmes

que sont les solutions des patrons de conception.

2.1. Vue des cas d’utilisation : les fonctionnalités d’un patron

Un modèle de cas d’utilisation présente les fonctionnalités du système en

construction, les dépendances qui les relient et les acteurs qui les déclenchent. De ce

résultat issu de l’étude des besoins dépend le reste de la spécification. Si la solution

d’un patron apporte plusieurs fonctionnalités, nous proposons de les faire apparaître

explicitement.

Nous rappelons l’intention du patron «Observateur» : « Définir une dépendance entre les observateurs d’un même sujet telle que, quand le sujet change d’état, tous ces observateurs soient informés et mis à jour » (Gamma et al., 1995).

En ce qui concerne « Observateur », on peut déduire deux fonctionnalités :

modifier le sujet (subject modification) et gérer les observateurs (observers management). La première consiste en la modification du sujet avec mise à jour des

observateurs, la seconde traite de l’ajout et de la suppression des observateurs au

sujet. La figure 1 illustre la vue des cas d’utilisation pour ce patron.

L’acteur de la vue des cas d’utilisation correspond au « client » des patrons du

GoF. Ce dernier spécifie les points d’entrée qu’il utilise pour accéder à la solution.

L’acteur client est donc l’entité qui déclenche les fonctionnalités (cf. figure 1).

Figure 1. Observateur : vue des cas d'utilisation

2.2. Vue dynamique : diagrammes de séquence UML2

Dans la rubrique Collaborations, le GoF propose un diagramme de séquence décrivant le cas d’utilisation que nous avons appelé subject modification. La figure 2 présente ce diagramme de séquence.

Dans ce diagramme, c’est un observateur qui modifie le sujet mais, à priori,

n’importe quel objet pourrait en faire de même, y compris le client. Il est donc

nécessaire « d’étendre » ce diagramme de séquence afin de le rendre complet.

Figure 2. Observateur : diagramme de séquence du GoF

Figure 3. Observateur : diagramme de séquence avec UML2

Les diagrammes de séquence d’UML2 (OMG, 2005) apportent beaucoup d’un

point de vue procédural. Ainsi le parcours de tous les observateurs de l’algorithme

implémentant la méthode notifier (notify) peut être modélisé à l’aide d’un fragment

combiné1 muni d’une opérande de boucle (loop). Nous utilisons une frame de type

référence (interaction use) et le mécanisme des portes (gate) pour référencer le

diagramme de séquence de la méthode notify (SD_notify).

La figure 3 illustre notre adaptation des séquences subject modification et notify avec UML2. Nous complétons la solution originale avec la méthode

updateSubjectState afin de représenter le changement d’état du sujet. Ce que réalise précisément cette méthode n’est pas une préoccupation de ce patron. Le concepteur

qui imitera ce patron aura à sa charge de définir cette méthode mais ne pourra

remettre en cause son emplacement chronologique dans la séquence setState. Nous adoptons la même approche en ce qui concerne l’état de l’observateur, mis à jour

dans la méthode update en utilisant sa méthode privée setObserverState.

Pour des raisons de place, nous ne présentons qu’un seul diagramme de séquence

de « Observateur », mais d’autres sont nécessaires afin d’obtenir une spécification

complète.

2.3. Vue statique : Diagrammes de classes

Les diagrammes de classes expriment la structure des entités du système ainsi

que la réalisation de leurs relations. Cette structure est en partie déduite de la vue

dynamique, mais le concepteur y précise des propriétés statiques, par exemple les

cardinalités des associations.

La plupart des solutions de patrons se résument à une vue statique, en général un

diagramme de classes. Ces structures sont souvent accompagnées de notes textuelles

qui apportent quelques précisions. Cela peut aller du simple commentaire à

l’algorithme. Dans le cas d’ « Observateur » l’algorithme de la méthode notify est décrit à l’aide d’un pseudo-code.

En considérant les diagrammes de séquence de la vue dynamique, nous

proposons une nouvelle structure (figure 4, à droite) pour représenter la solution du

patron « Observateur », dont les différences avec la solution originelle du GoF

(figure 4, à gauche) sont les suivantes :

– Dans notre approche à mini-système, un algorithme est représenté dans la vue

dynamique. C’est le cas pour la méthode notify et sa note explicative devient donc redondante.

– Nous ne matérialisons pas l’état du sujet concret car il peut être représenté de

toute autre manière que par un seul attribut : plusieurs attributs, des liens avec

d’autres classes, une combinaison des deux, etc. Cependant nous nous devons

d’informer le concepteur d’applications du fait qu’il devra mettre en œuvre la

représentation de cet état lors de son imitation. Nous proposons d’utiliser une note

de type « à faire » (TODO).

1 Appelé aussi « inline frame ». Par la suite nous utilisons le terme « frame ».

– Nous avons ajouté à la vue dynamique une méthode privée de modification de

cet état dont le contenu dépendra de la représentation choisie lors de l’imitation.

C’est pourquoi la note « à faire » concerne l’état du sujet et sa modification.

Utiliser notre approche ne rend pas les solutions originales caduques. Elles

restent un excellent support didactique et facilitent d’autant la compréhension du

patron, c’est pourquoi il faut les conserver.

Figure 4. Observateur : vue statique

2.4. Les limites du mini-système

Une approche à vues multiples permet d’exprimer plus complètement la solution

semi-formelle d’un patron. Nous pourrions considérer que l’imitation de telles

solutions apporterait une meilleure qualité de réutilisation. Pourtant, il est des

informations que notre mini-système ne prend toujours pas en compte, par exemple

le fait que les fonctionnalités offertes par la solution d’un patron soient essentielles

ou facultatives.

Ainsi, contrairement à l’intention précisée par le GoF, le patron « Observateur » ne se borne pas à mettre en œuvre la notification des observateurs mais permet

également d’attacher ou de détacher ces derniers à un sujet (observers management). Cette fonctionnalité certes pratique n’est pas indispensable. La solution devrait donc

introduire le fait que la gestion des observateurs ne constitue qu’une fonction

secondaire qui peut ne pas être retenue lors de l’imitation. Dans la section suivante,

nous proposons d’exprimer, entre autres, ce type de variabilité de la solution d’un

patron.

Vue statique du GoF Vue statique du mini-système

3. La variabilité dans les patrons

3.1. Variabilité et point de variation

La variabilité est définie comme la capacité d’un système à être changé,

personnalisé et configuré en fonction d’un contexte spécifique (Van Grup, 2000).

Un point de variation est un endroit du système où il y a une variation

(Czarnecki et al., 2000), c'est-à-dire où des choix vont devoir être faits afin d’identifier les variantes à utiliser.

Il existe plusieurs types de variabilité pour un point de variation (Bachmann et al., 2001) :

– les options : choix de zéro ou plusieurs variantes parmi plusieurs,

– les alternatives : choix de une variante parmi plusieurs,

– les alternatives optionnelles : choix de zéro ou une variante parmi plusieurs,

– les ensembles d’alternatives : choix d’au moins une variante parmi plusieurs.

De nombreuses approches ont été proposées pour représenter la variabilité dans

les spécifications : FODA (Kang et al., 1990) et ses diagrammes de « features », les cas d’utilisation de (VanDerMaβen et al., 2002), les diagrammes de classes de (Clauss, 2001), les diagrammes de séquences de (Ziadi et al., 2005), etc. . Ces deux dernières approches proposent d’étendre UML à l’aide, entre autres, de stéréotypes.

Nous utilisons également les stéréotypes mais ne considérons, pour l’instant, que des

variantes de type option ou alternative.

3.2. Un opérateur pour la variabilité fonctionnelle

Les diagrammes de cas d’utilisation étant la base de la construction de nos mini-

systèmes, nous proposons un opérateur pour l’expression de leur variabilité.

L’opérateur de variabilité proposé est générique. Il peut en effet être utilisé pour les

quatre types de variabilité présentés en 3.1. Il est toujours composé d’un point de

variation (<<variation>>) et de plusieurs variantes (<<variant>>). A l’aide de

valeurs marquées sur ces stéréotypes, on exprime les cardinalités minimale et

maximale (selon le type de variabilité). Une alternative entre deux variantes

s’exprimera avec une cardinalité 1..1 alors qu’une optionalité aura toujours une

cardinalité minimale de zéro et une cardinalité maximale égale au nombre de

variantes (ou options). Nous utilisons la dépendance d’inclusion pour résoudre le

problème de lisibilité entre variantes d’un même point de variation mais de différents

types : s’il existe des alternatives et des options à un cas d’utilisation, nous incluons

à ce dernier un point de variation non fonctionnel dédié à l’expression des options.

La figure 5 présente la fonctionnalité A, ses deux alternatives way 1 et way 2 ainsi que deux options option 1 et option 2.

Figure 5. Opérateur générique pour la variabilité fonctionnelle

Par exemple, la spécification ci-dessus autorise les combinaisons [way1], [way1 + option1], [way2 + option1 + option2] mais interdit [way1+way2] ou encore [option1].

Si cet opérateur permet de représenter les quatre types de variabilité, sa

représentation nuit à la lisibilité du diagramme et rend son usage difficile. Nous

proposons d’ajouter des stéréotypes de dépendance qui remplaceront

avantageusement la représentation précédente. En ce qui concerne l’expression des

options et des alternatives, la représentation de la fonctionnalité A dans la figure 6 est équivalente à la figure 5.

D’autre part, en confrontant l’intention d’un patron – la plupart des formalismes

de patrons comporte une rubrique intention – à la solution proposée, on constate

parfois la présence de fonctionnalités principales donc obligatoires lors de

l’imitation, mais aussi de fonctionnalités secondaires qui, elles, ne le sont pas.

Figure 6. Simplification de l'opérateur générique

Alternative

Options

Dépendance

Les fonctionnalités secondaires peuvent être représentées à l’aide de notre

opérateur générique car elles peuvent être considérées comme des variantes

optionnelles (cardinalité 0..n parmi n) directement associées au client. On peut

appliquer la même logique aux fonctionnalités principales à ceci près que ce sont des

« options obligatoires » (cardinalité n..n parmi n variantes). Pour ne pas surcharger le

diagramme, nous définissons de nouveaux stéréotypes d’association : <<primary>>

et <<secondary>>. La figure 6 est le diagramme de cas d’utilisation d’un patron

comportant la fonctionnalité principale A et une fonctionnalité B secondaire.

Le caractère variable de certaines solutions semi-formelles de patrons est

généralement rendu explicite par les informations complémentaires fournies par

l’ingénieur de patrons à l’aide d’autres rubriques. Dans les patrons du GoF, la

rubrique Implémentation détaille souvent des variantes purement techniques mais également des variantes conceptuelles, qui correspondent à la notion de point de

variation.

La fonctionnalité principale du patron « Observateur » est de permettre la

modification de l’état du sujet avec une mise à jour automatique et donc implicite

des observateurs. Cependant il est également possible que le déclenchement de cette

mise à jour soit à la charge exclusive de celui qui initie le changement d’état. Les

deux cas sont discutés dans la rubrique Implémentation du patron. Conformément à notre approche, nous pouvons en déduire un point de variation observers notification avec une alternative à deux variantes nommées respectivement implicit notification et explicit notification. La figure 7 illustre une spécification variable (ou à variantes) de la vue des cas d’utilisation pour la solution du patron « Observateur ».

Figure 7. Observateur : vue à variantes des cas d'utilisation

Dès lors que les cas d’utilisation sont spécifiés, il faut compléter le système avec

les aspects dynamiques (diagrammes de séquences) et statiques (diagrammes de

classes) en prenant en compte la notion de variabilité.

3.3. Variabilité dynamique

UML 2 permet d’inclure des frames (fragments d’interaction) dans d’autres fragments et également d’y faire référence. Nous pouvons donc inclure des sous-

séquences correspondant aux variantes en gardant une très bonne visibilité. Cela

permet aussi de pouvoir exprimer les propriétés communes aux variantes (en général

le préambule et l’épilogue) au sein du point de variation lui-même.

Une règle doit être respectée : tout point de variation de la vue des cas

d’utilisation doit, dans la vue dynamique, être représenté par au moins une frame d’un diagramme de séquence. L’application de cette règle est facilitée par les

diagrammes de séquence d’UML2 puisqu’il est possible de faire correspondre une

séquence à un cas d’utilisation. Afin d’obtenir une spécification claire, nous utilisons

les stéréotypes <<variation>> et <<variant>> sur les frames relatives à un point de variation ou à une variante.

En repartant des séquences du 2.2, on peut construire une partie de la vue

dynamique à variantes pour le patron « Observateur ». Celle-ci est illustrée dans la

figure 8. On y retrouve une frame pour le point de variation (partie invariable) ainsi qu’une frame par variante. La séquence de la méthode notify reste inchangée (cf. notify figure 3).

Figure 8. Diagramme de séquence à variantes de observers notification

3.4. Variabilité statique et généricité

Il ne reste plus qu’à préciser les apports statiques de chaque fonctionnalité pour

finaliser notre système. A ce niveau, notre proposition va s’écarter de la construction

classique d’un système. En effet, nous suggérons de donner, pour chaque cas

d’utilisation spécifié, ses apports statiques au modèle de la solution. Ceci demande

un effort de discrimination qui se révélera bénéfique au moment de l’imitation.

La structure est disséminée dans plusieurs fragments qui s’assembleront pour

former une vue statique classique lors de l’imitation. Toute classe « impactée » par

une variation ou plus généralement par une fonctionnalité sera représentée dans le

fragment statique de ce cas d’utilisation avec ses propriétés apportées. La plupart des

propriétés statiques peuvent être déduites de la vue dynamique. La figure 9 présente

les fragments statiques des cas d’utilisation subject modification, observers notification, explicit notification, implicit notification et observer management.

La visibilité de la méthode de notification n’est pas la même selon la variante de notification choisie. En effet, pour une notification explicite, cette méthode doit être

publique pour pouvoir être déclenchée de l’extérieur. Ceci est d’ailleurs garanti par

le message du diagramme de séquence lui même. Mais, dans le cas d’une notification

implicite, une visibilité protégée est plus adéquate. Dans la figure 9, la visibilité de la

méthode notify n’est précisée qu’au niveau des variantes.

Figure 9. Observateur : fragments statiques

Ces fragments sont à réutiliser en l’état ; il n’est par exemple, pas nécessaire de

préciser que notify doit rester protégée si la variante de notification implicite est choisie, elle le restera de facto. Cependant ces diagrammes de classes ne sont pas

complètement figés. Comme expliqué en 2.3, lors de l’imitation, le concepteur devra

compléter les « trous », comme par exemple l’état du sujet ou sa méthode privée

subject modification observers notification (<<variation>>)

explicit notification (<<variant>>)

observers management implicit notification (<<variant>>)

d’affectation, ou encore le fait qu’il puisse y avoir plusieurs types d’observateurs

concrets.

D’autres propriétés statiques restent également à exprimer : par exemple le fait

que le concepteur pourra, lors de l’imitation, définir plusieurs classes d’observateurs

concrets (cf. duplicable=true, figure 9).

Nous proposons, pour exprimer ces propriétés de généricité, une approche que

nous avons présentée dans (Arnaud et al., 2004) où nous étendons UML avec des méta-propriétés spécifiques à la généricité : par exemple, une méta-propriété

booléenne (sur la métaclasse Classe) précisant si une classe peut être dupliquée au sein d’une imitation (cette méta-propriété a une valeur par défaut à faux).

4. Processus d’imitation

La section précédente a montré comment l’ingénieur de patrons pouvait préciser

la variabilité et la généricité de ses solutions au sein de ce que nous appelons un

modèle imitable. L’objectif est maintenant de permettre au concepteur de systèmes

d’information d’imiter un patron afin de tirer partie de cette spécification.

Nous proposons au concepteur de systèmes d’information un processus

d’imitation traçable, qui le guidera du choix du patron (et donc de son modèle

imitable) à l’intégration du modèle imité dans le système en construction (cf. figure

10). Ce processus est composé de deux sous-processus : le processus de réduction et

le processus d’application. Par manque de place, nous ne présentons par la suite que

le déroulement global de ces deux processus.

Figure 10. Processus d'imitation

4.1. Processus de réduction

Le processus de réduction est constitué de deux activités.

– Le choix du patron à imiter consiste à sélectionner un patron dans un système de patrons. La solution du patron sélectionné est appelée un modèle imitable et

consiste en un mini-système à variantes composé de trois vues. Cette activité n’est

pas spécifique aux concepts que nous présentons dans cet article, mais aborde une

problématique beaucoup plus générale, aussi nous ne la détaillons plus ici.

– La réduction permet au concepteur de choisir les variantes qu’il désire imiter à partir de la vue des cas d’utilisation. La figure 11 illustre la réduction fonctionnelle

du patron « Observateur » via la sélection de l’alternative implicit notification. La partie droite représente la vue fonctionnelle du mini-système imité dans l’état

adaptable. Les vues dynamiques et statiques déduite de ce mini-système sont

comparables aux figures 3 et 4 (partie droite) excepté le fait que tout ce qui concerne

la gestion des observateurs (méthodes attach et detach) n’est pas conservé.

Figure 11. Construction d'un modèle imité [adaptable] pour "Observateur"

4.2. Processus d’application

Le processus d’application est constitué de trois activités qui peuvent être

exécutées de manière itérative.

– L’adaptation permet au concepteur de renommer les propriétés et de d’adapter le modèle imité [adaptable] en restant conforme aux règles de généricité. Le modèle

obtenu est appelé modèle imité [adapté]. Dans la figure 12, qui présente la vue

statique du modèle imité [adapté], Wind_Distribution est une imitation de Concrete_Subject. Concrete_Observer est dupliquée en HistoDiag et SectorDiag.

– La résolution consiste à traiter les notes TODO. Par exemple, il s’agit de compléter la mise en œuvre de l’état du sujet (cf. note dans la figure 4, droite). Dans

la figure 12, elle a été résolue par l’insertion des attributs north, south, east et west et la spécification complète de updateValues. Par contre, la note de droite n’a pas encore été résolue : les résolutions des notes TODO peuvent être réalisées à tout moment. Et certaines résolutions n’auront d’ailleurs lieu qu’après l’intégration du

modèle imité à la spécification du système d’information.

Réduction

– L’intégration consiste à fusionner la spécification du modèle imité [adapté] avec celle du système d’information. Un système d’information est donc perçu

comme un ensemble de modèles imités, mais également de spécifications originales

ne provenant pas de l’imitation d’un patron, mais du savoir-faire du concepteur.

L’intégration a en partie déjà été traitée dans (Arnaud et al., 2005) où nous avons proposé deux opérateurs pour l’intégration d’imitations : par délégation et par

fusion.

Figure 12. Vue statique d’un modèle imité [adapté]

5. Travaux liés

Les travaux visant à améliorer la spécification des solutions des patrons afin de

garantir une réutilisation plus sûre peuvent être caractérisés de différentes manières.

Nous retiendrons ici trois critères d’amélioration.

Complétude des spécifications. Dans la plupart des travaux (Meijler et al., 1997), (Arnaud et al., 2004), seuls les aspects statiques (classes, propriétés et associations) sont pris en compte. Dans une approche comme (Albin-Amiot et al., 2001), certains apports dynamiques sont mis en œuvre, grâce à un méta-modèle plus spécifique aux

patrons que UML. Par exemple, la méta-classe PDelegatingMethod (spécialisation de la méta-classe Method) est utilisée pour spécifier qu’une méthode fait appel à une autre via une association donnée. Cela permet, entre autres, une certaine

automatisation de la génération de code. Dans (France et al., 2004), les vues statiques (Structural Pattern Specification) et dynamiques (Interaction Pattern

Specification) sont traitées conjointement, les IPS spécifiant les interactions des

participants décrits dans les SPS. Contrairement à ces travaux, notre proposition

manipule et adapte des spécifications complètes comportant trois types d’aspects :

fonctionnels, dynamiques et statiques.

Expression de la variabilité. (Budinsky et al., 1996) et (Sunyé, 1999) traitent de l’expression et du choix de variantes d’implémentation de patron. Les apports de ces

travaux peuvent être positionnés au niveau de ce que nous appelons la réduction. Si

l’expression de la variabilité a peu été utilisée dans les travaux sur les patrons,

rappelons (cf. 3.1) qu’elle a par contre été utilisée dans d’autres contextes tels que

les lignes de produits (Ziadi et al., 2005) ou l’ingénierie des besoins (Bennasri, 2005).

Extension du méta-modèle d’UML. Par manque de place nous n’avons pas décrit les extensions d’UML nécessaires pour l’expression de la variabilité et des règles de

généricité. Notre approche consiste à étendre UML (Arnaud et al., 2004) d’une manière suffisamment générique pour être applicable à tout patron. Dans la plupart

des approches (Meijler et al., 1997), (France et al., 2004), le méta-modèle d’UML est étendu par des concepts spécifiques à chaque patron pris en compte.

6. Conclusion

Nous proposons dans cet article un processus d’imitation pour les patrons de

conception tenant compte à la fois des aspects variables mais également génériques

de la solution proposée par un ingénieur de patrons. Pour cela, nous donnons à ce

dernier les outils de spécification nécessaires à l’expression de ces propriétés au sein

d’un mini-système à trois vues (fonctionnelle, dynamique et statique), rendant ainsi

la solution plus complète. Le modèle de la solution ainsi créé est dit « imitable ».

C’est grâce à la vue fonctionnelle composée d’un modèle des cas d’utilisation,

que le concepteur de systèmes d’information va réduire la solution imitable en sélectionnant certaines variantes. Le mini-système obtenu est dit « adaptable ». Il est

ensuite appliqué au contexte de l’imitation via trois actions qui permettent l’adaptation des propriétés génériques de la solution (telle la duplication d’une classe participante), la résolution des « trous » qui sont des parties du modèle imité exclusivement à la charge du concepteur et l’intégration de cette spécification au système d’information en cours de création.

La spécification d’un modèle imitable est une opération nécessitant un lourd

investissement de la part d’un ingénieur de patrons qui n’a de sens que lorsqu’il

s’agit d’un patron qui va être très souvent réutilisé. Le gain se situe ensuite au niveau

du concepteur de systèmes qui dispose alors d’un processus de réutilisation sûr et en

grande partie automatisable (transformation de modèles). Cependant, pour que les

imitations ne soient pas que des spécifications figées, nous devons fournir au

concepteur d’application les moyens d’exploiter la traçabilité mise en place. Le cas

échéant, le concepteur pourra revenir sur certains de ses choix lors du processus

d’imitation sans pour autant remettre en cause l’intégralité du travail déjà accompli.

A terme, nous souhaitons instrumenter ce processus d’imitation et le généraliser à

des patrons de niveau analyse ou même de niveau métier.

7. Bibliographie

Albin-Amiot H., Guéhéneuc Y.G., « Meta-modeling Design Patterns : application to pattern

detection and code synthesis », Proceedings of ECOOP Workshop on Automating Object-Oriented Software Development Methods, June 2001.

Arnaud N., Front A., Rieu D., « Deux opérateurs pour l’intégration d’imitations de patrons »,

Congrès INFORSID’05, Mai 2005.

Arnaud N., Front A., Rieu D., « Une approche par méta-modélisation pour l’imitation des

patrons », Congrès INFORSID’04 , Mai 2004.

Bachmann F., Bass L., « Managing variability in software architecture », ACM SIGSOFT Software Engineering Notes, Volume 26, n°3, Mai 2001

Bennasri S., Une approche intentionnelle de représentation et de réalisation de la variabilité

dans un système logiciel, Thèse de doctorat, Université de Paris I, Février 2005.

Budinsky, F.J., M.A. Finnie, J.M. Vlissides et P.S. Yu, « Automatic code generation from

design patterns”. IBM Systems Journal, 1996

Clauss M., « Generic modeling using UML extensions for variability », OOPSLA 2001, Workshop on Domain Specific Visual Languages, pages 11-18, Septembre 2001.

Czarnecki K., Eisenecker U. W., Generative Programming – Methods, Tools and Applications, Addison-Wesley, 2000.

France R.B., Dae-Kyoo K., Sudipto G., Eunjee S., « A UML-Based Pattern Specification

Technique », IEEE transactions on software engineering, vol. 30, no. 3, March 2004

Gamma E., Helm R., Johnson R., Vlissides J., Design Patterns : Element of Reusable Object-Oriented Software, Addison-Wesley professional computing series, 1995.

Kang K., Cohen S., Hess J., Novak W., Peterson S., Feature-Oriented Domain Analysis

(FODA) feasibility study, Technical report CMU/SEI-90-TR-21, Software Engineering

Insitute, Carnegie Mellon University, Novembre 1990

Meijler T.D., Demeyer S., Engel R., « Making design patterns explicit in Face », European Software Engineering Conference, 1997.

Object Management Group, « Unified Modeling Language : Superstructure », version 2.0,

Août 2005.

Sunyé, G., « Génération de code à l'aide de patrons de conception », Langages et Modèles à Objets - LMO'99, Villeneuve s/ mer, 1999.

Van der Maβen T., Lichter H., « Modeling variability by UML use case diagrams »,

International Workshop on Requirements Engineering for Product Lines (REPL’02), pages 19-25. AVAYA labs, Septembre 2002.

Van Grup J., Variability in Software Systems, the key to software reuse, Licentiate Thesis,

University of Groningem, Sweden, 2000.

Ziadi T, Jézéquel J.M., « Manipulation de lignes de produits logiciels : une approche dirigée

par les modèles », Ingénierie Dirigée par les Modèles (IDM’05), Mai 2005.