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. Vue statique du GoF Vue statique du mini-système 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.
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 minisystè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.
Options Alternative Dépendance 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
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 soussé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. subject modification observers notification (<<variation>>) explicit notification (<<variant>>) implicit notification (<<variant>>) observers management 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
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é. Réduction 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.
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.