THÈSE. Manipulation de Lignes de Produits en UML

N o d ordre : 3083 THÈSE présentée devant l université de Rennes 1 pour obtenir le grade de : Docteur de l université de Rennes 1 Mention Informatique par Tewfik ZIADI Équipes d accueil : IRISA-TRISKELL École doctorale : MATISSE Composante Universitaire : IFSIC, Université de Rennes 1 Titre de la thèse : Manipulation de Lignes de Produits en UML Soutenue le 13 Décembre 2004 Composition du jury M. Albert Benveniste Président MM. Christophe Dony Rapporteurs Ferhat Khendek MM. Charles Consel Examinateurs Loïc Hélouët Jean-Marc Jézéquel

Table des matières Introduction 17 I État de l art 23 1 Les Lignes de Produits Logiciels 25 1.1 Introduction.................................. 25 1.2 Des familles de programmes aux Lignes de produits............ 26 1.3 Une approche adoptée dans l industrie................... 26 1.4 L ingénierie de Domaine et d Application.................. 27 1.4.1 Ingénierie du domaine........................ 28 1.4.2 Ingénierie d application....................... 29 1.5 La variabilité logicielle............................ 29 1.5.1 Les dimensions de la variabilité................... 30 1.5.2 Les points de variation........................ 31 1.5.3 La variabilité au niveau de l implantation............. 31 1.6 Les contraintes................................ 32 1.7 Conclusion................................... 33 2 UML pour la modélisation de Ligne de Produit 35 2.1 Introduction.................................. 35 2.2 Unified Modeling Language (UML)..................... 35 2.2.1 Une sémantique à base de méta-modélisation........... 36 2.2.2 Les contraintes OCL......................... 37 2.2.3 Les diagrammes............................ 38 2.2.4 Extensibilité.............................. 40 2.2.5 Ingénierie des modèles........................ 42 2.3 État de l art sur la modélisation de LdP en UML............. 45 2.3.1 Modélisation de la variabilité dans les modèles UML....... 45 2.3.2 Gestion des contraintes....................... 50 2.3.3 Le support de la dérivation des modèles de produits....... 50 2.3.4 Synthèse................................ 52 3

4 Table des matières 2.4 Une approche dirigée par les modèles.................... 53 3 Spécification de comportement dynamique des systèmes 55 3.1 Introduction.................................. 55 3.2 Les scénarios : la vue inter-objets...................... 56 3.2.1 Les diagrammes de séquence d UML1.x.............. 56 3.2.2 Les diagrammes de séquence d UML2.0.............. 59 3.2.2.1 Les interactions...................... 59 3.2.2.2 Les mécanismes de composition.............. 61 3.2.3 Message Sequence Charts...................... 64 3.3 Les machines à états : la vue intra-objet.................. 66 3.4 Des scénarios aux machines à états..................... 67 3.4.1 Motivations.............................. 67 3.4.2 État de l art sur les travaux existant................ 68 3.4.3 Comparaison de comportement................... 70 3.5 Conclusion................................... 70 4 La Modélisation de la Variabilité 73 4.1 Introduction.................................. 73 4.2 La ligne de produit banque......................... 74 4.3 Modélisation de l aspect statique des LdP................. 75 4.3.1 La variabilité............................. 75 4.3.2 Définition des extensions....................... 76 4.3.3 Exemple................................ 78 4.4 Modélisation de l aspect dynamique des LdP............... 78 4.4.1 La variabilité............................. 78 4.4.2 Définition des extensions....................... 81 4.4.3 Exemple................................ 82 4.5 Vers un profil UML pour les LdP...................... 83 4.6 Spécification algébrique des diagrammes de séquence des LdP...... 87 4.6.1 Expressions de Référence...................... 87 4.6.2 Expressions de Référence des LdP................. 89 4.6.3 Exemple................................ 90 4.7 Conclusion................................... 91 5 La Modélisation des Contraintes de LdP 93 5.1 Introduction.................................. 93 5.2 Les contraintes OCL au niveau méta-modèle................ 93 5.3 Les contraintes génériques des LdP..................... 94 5.3.1 La contrainte de dépendance.................... 94 5.3.2 La contrainte d héritage....................... 96 5.4 Les contraintes spécifiques des LdP..................... 97

Table des matières 5 5.4.1 La contrainte de présence...................... 98 5.4.2 La contrainte d exclusion mutuelle................. 100 5.5 Conclusion................................... 101 II Dérivation de produits 103 6 Dérivation de modèles statiques des produits 105 6.1 Introduction.................................. 105 6.2 La LdP Mercure............................... 105 6.3 Dérivation de produits............................ 109 6.3.1 De modèle de LdP aux modèles de Produits............ 110 6.3.2 Dérivation............................... 112 6.3.3 Implantation en MTL........................ 113 6.4 Prise en compte des contraintes dans la dérivation............ 117 6.5 Conclusion................................... 117 7 Dérivation de comportements 119 7.1 Une Approche Algébrique.......................... 119 7.2 Dérivation des expressions de produits................... 120 7.2.1 Modèles de décision......................... 120 7.2.2 Dérivation............................... 122 7.3 Des expressions de produits aux machines à états............. 125 7.3.1 Un cadre algébrique pour les machines à états........... 125 7.3.1.1 Opérateurs de composition................ 127 7.3.1.2 Expressions de référence des machines à états..... 130 7.3.2 Génération des machines à états.................. 131 7.3.2.1 Diagrammes de séquence de base............. 131 7.3.2.2 Diagrammes de séquence combinés............ 136 7.4 Évaluation de l approche........................... 139 7.4.1 Avantages............................... 139 7.4.2 Limites................................ 141 7.5 Discussion autour de la synthèse...................... 142 7.5.1 Vues Inter-objet et intra objet.................... 143 7.5.2 Le rôle de la synthèse........................ 146 7.6 Conclusion................................... 147 8 Application et validation 149 8.1 Les projets CAFE et FAMILIES...................... 149 8.2 L outil prototype PLiBS........................... 150 8.3 Études de cas................................. 152

6 Liste des figures III Conclusion et perspectives 157 Annexes 163 A Les contraintes de LdP en MTL 165 B Le code de la dérivation de la LdP Mercure en MTL 169 C L exemple de Guichetier automatique 179 Bibliographie 189

Table des figures 1.1 L ingénierie de lignes de produits...................... 27 1.2 Exemple d un diagramme de caractéristiques FODA........... 29 1.3 La dimension espace et temps dans la variabilité............. 30 2.1 L architecture à quatre niveaux de l OMG................. 37 2.2 Le diagramme de cas d utilisation d une application bancaire...... 39 2.3 Extrait d un diagramme de classes d une application bancaire...... 40 2.4 Exemple de spécification d un profil UML2.0 et son utilisation...... 42 2.5 Les transformations de modèles....................... 43 3.1 Exemple d un diagramme de séquence d UML1.x et ses concepts.... 57 3.2 Le branchement conditionnel dans les diagrammes de séquence d UML1.x 57 3.3 Une partie de méta-modèle des interactions dans UML1.5........ 58 3.4 Une partie du méta-modèle des diagrammes de séquence d UML2.0... 60 3.5 Exemple d un DS dans UML2.0 et ses concepts.............. 60 3.6 Exemple des références vers les DS dans UML2.0............. 61 3.7 Exemple d un diagramme de séquence combiné.............. 63 3.8 Exemple d un diagramme de vue d ensemble d interaction dans UML2.0 63 3.9 Exemples de basic MSC........................... 64 3.10 Exemple d une inline-expression....................... 65 3.11 Exemple d un HMSC............................. 66 3.12 Exemple de machine à états......................... 67 4.1 Variation dans un diagramme de classes.................. 76 4.2 Extrait du méta-modèle d UML des classes................ 76 4.3 Exemple d une variation où une classe variante est associée à deux points de variation.................................. 77 4.4 Le diagramme de classes de la LdP banque................ 78 4.5 Exemple d une interaction combinée référençant une interaction optionnelle 80 4.6 Exemple d une interaction variation..................... 80 4.7 Exemple d une interaction combinée référençant une interaction virtuelle 81 4.8 Les interactions de base dans la LdP banque................ 84 4.9 L interaction combinée de la LdP banque avec la variabilité....... 85 7

8 Table des figures 4.10 Les extensions d UML pour la modélisation des LdP........... 86 5.1 Les contraintes génériques dans les LdP.................. 95 5.2 Exemple de dépendance d utilisation dans un modèle de LdP...... 95 5.3 Les dépendances dans le méta-modèle d UML............... 96 5.4 Exemples d héritages dans des diagrammes de classes de LdP...... 97 5.5 La généralisation dans le méta-modèle d UML............... 97 5.6 Les contraintes spécifiques dans les LdP.................. 98 5.7 La méta-classe Model dans le méta-modèle d UML............ 99 5.8 Exemple d un diagramme de classes d une LdP.............. 99 5.9 Exemple d un diagramme de classes d un produit dérivé......... 100 6.1 Le diagramme de caractéristiques de la LdP FODA........... 107 6.2 Le diagramme de classes UML de la LdP Mercure............ 108 6.3 La structure du patron de conception Fabrique Abstraite........ 109 6.4 La fabrique abstraite dans la LdP Mercure................ 110 6.5 La fabrique abstraite étendue avec des stéréotypes pour la LdP Mercure 111 6.6 Le modèle obtenu pour le produit CustomMercure............. 116 7.1 Le diagramme de séquence combiné du produit BS1............ 124 7.2 Exemple de machines à états à plats.................... 126 7.3 Exemple d application de l opérateur seq s................. 128 7.4 Exemple d application de l opérateur loop s................ 129 7.5 Exemple d application de l opérateur alt s................. 131 7.6 Le DS de base Deposit dans la LdP banque................ 132 7.7 Exemple de la synthèse d une machine à états à partir d un DS de base. 133 7.8 Les machines à états de base de l objet Bank................ 135 7.9 De seq à seq s................................. 136 7.10 De alt à alt s................................. 137 7.11 De loop à loop s............................... 137 7.12 La machine à états pour l objet Bank dans le contexte de produit BS2.. 138 7.13 La machine à états pour l objet Bank dans le contexte de produit BS4.. 140 7.14 Exemple d une machine à états non-déterministe............. 142 7.15 Exemple d un diagramme de séquence engendrant de blocage pour la diffusion.................................... 143 7.16 Exemple d un DS avec un choix non-local................. 144 7.17 Les machines à états générées à partir de DS de la Figure 7.16...... 144 7.18 Les relations entre le comportement des scénarios et celui de machines à états...................................... 145 8.1 Exemple de spécification de RESD-PL dans PLiBS........... 150 8.2 L instantiation du modèle de décision dans PLiBS............ 151 8.3 La synthèse des machines à états dans PLiBS............... 152

Table des figures 9 8.4 Exemple d une machine à états synthétisée dans PLiBS......... 153 9.5 Intégration dans les deux niveaux des LdP................. 160 C.1 Les diagrammes de séquence de base pour l exemple de guichetier automatique.................................... 180

Liste des tableaux 2.1 Exemple d un modèle de décision de KobrA................ 51 2.2 Table récapitulative des travaux existant autour de la manipulation des LdP avec UML................................ 52 4.1 Les membres de la LdP banque....................... 74 4.2 Les règles de base pour la représentation des DS en RESD........ 88 7.1 Les instances du modèle de décision de la LdP banque.......... 121 8.1 Statistiques sur le nombre d états et de transitions générés pour la machine à états de l objet Bank dans la LdP banque............. 154 11

Introduction La discipline «Génie Logiciel» a été inventée dans la fin des années 1960 pour répondre à la croissance de la complexité des logiciels. Elle avait comme but principal de définir et de proposer des solutions et des méthodologies pour le développement des logiciels. Son champ a évolué pour couvrir les nouvelles problématiques introduites par l extension de la pénétration de l informatique dans l industrie. On arrive ainsi à une situation où la problématique n est plus de développer un seul logiciel à la fois mais plutôt concevoir et développer une ligne (ou une famille) de logiciels qui prend en compte des facteurs de variation et permet de minimiser les coûts et les temps de réalisation. Les facteurs de variation peuvent être techniques (utilisation d une variété de matériels associés aux logiciels), commerciaux (création de plusieurs versions allant d une version limitée à une version complète), ou culturels (logiciels destinés à plusieurs pays). Pour illustration, on peut citer les logiciels intégrés aux téléphones mobiles qui doivent supporter plusieurs standards de communication et une variété de langues (dans [74], Maccari et al. affirment par exemple que les téléphones Nokia doivent supporter plus de 60 langues). Cette notion de lignes de produits n est pas totalement nouvelle car David Parnas dans [95] a déjà étudié les familles de programmes dès 1976. Cependant ce paradigme n a émergé comme une approche à part du génie logiciel seulement ces dernières années, lorsqu il a commencé à regrouper une communauté à travers les différent projets européens tels que ESAPS [1], CAFE [2], FAMILIES [3]. Aux États Unis, Le Software Engineering Institue a également crée une action spéciale qui s intéresse à l ingénierie des lignes de produits [85]. Dans la littérature, il y a un consensus sur la définition d une ligne de produits logiciel (LdP). Elle est définie comme un ensemble de systèmes partageant un ensemble de propriétés communes et satisfaisant des besoins spécifiques pour un domaine particulier [27, 21]. La notion de variabilité est utilisée pour regrouper les caractéristiques qui différencient les produits de la même famille. Les langues supportées sont un exemple de variabilité dans une LdP du domaine des téléphones mobiles. La gestion de cette variabilité est la première activité pour le développement de lignes de produits. La deuxième activité concerne la construction d un produit particulier (on parle aussi de dérivation de produit) qui consiste en particulier à figer certains choix vis-à-vis de la variabilité définie dans la LdP. Une 13

14 Introduction particularité des LdP est que certains choix sont incompatibles entre eux, d autres sont liés. Un choix particulier lors de la dérivation d un produit peut exclure ou exiger d autres choix. Une ligne de produits doit donc aussi gérer des contraintes permettant de faciliter les choix lors de la dérivation. Trouver des solutions pour répondre aux problématiques des LdP a attiré beaucoup d attention ces dernières années. Plusieurs travaux se sont intéressés à la manipulation des LdP au niveau du code en utilisant diverses technologies comme la technologie des objets [7, 59, 105, 63] et la programmation générative [26, 11, 82, 81]. Même si ces travaux se basent sur des technologies et des techniques qui ont connu une réussite remarquable dans le domaine du génie logiciel, la maîtrise du code devient de plus en plus difficile avec la croissance exponentielle de la complexité des logiciels (il n est pas surprenant de trouver maintenant des systèmes avec des millions de lignes de code). Indépendamment du code, la modélisation semble une solution permettant de mieux maîtriser cette complexité. Il ne s agit plus de manipuler le code du système lui même mais plutôt de manipuler un ensemble de modèles le décrivant d une manière plus abstraite. La modélisation est le fondement de plusieurs méthodes d analyse et de conception telles que OMT [100], Booch [16] et OOSE [52] qui ont donné naissance à UML (Unified Modeling Language ) [93, 86, 94], «le» standard industriel de modélisation, et par la suite à l ingénierie des modèles [25], ou Model Driven Engineering (MDE), le champ du génie logiciel basé sur la modélisation. Cette thèse se situe dans le contexte de la modélisation de lignes de produits en UML, et propose de nouvelles approches pour leur manipulation. Comme nous le verrons par la suite, il existe dans la littérature de très nombreux travaux autour de la manipulation des LdP en UML [39, 14, 110, 57, 33, 34, 9, 8, 61, 113, 30, 29, 20, 19, 99]. La principale hypothèse de la plupart de ces travaux concerne l utilisation des mécanismes standards d extension d UML pour permettre la modélisation des LdP et prendre en compte les nouvelles dimensions de la modélisation de la variabilité, de la dérivation de produits et de la gestion de contraintes. Mais en étudiant de plus près ces travaux, des constats d insuffisances se dégagent et indiquent que la manipulation de LdP en UML manque de maturité : Le premier constat est que la majorité des travaux existant utilisent seulement deux vues d UML pour modéliser les LdP : les cas d utilisation [39, 14, 110, 57, 34] et les modèles statiques [113, 61, 20, 19]. Cependant, peu de travaux font référence à l aspect dynamique des LdP. En effet, en plus des cas d utilisation et des modèles statiques, UML propose aussi des modèles tel que les diagrammes de séquence et les machines à états permettant de spécifier le comportement dynamique de systèmes. Comme nous le verrons par la suite, le peu existant ne propose pas de mécanismes puissants pour exprimer de la variabilité.

Introduction 15 Le deuxième constat concerne le support de la dérivation qui est une activité importante dans une approche supportant les LdP. Certains travaux se contentent seulement de modéliser la variabilité et ne font pas référence à la dérivation de produits [61, 33, 99]. Ceci, à notre avis, restreint l utilité de ces travaux à un but descriptif et les limite à des objectifs de documentation d architectures à l aide de modèles UML. Les travaux de [9, 8, 29] font référence à la dérivation de produits mais ne la formalisent pas et ne proposent pas de solution pour sa mise en oeuvre. Le troisième constat concerne la gestion des contraintes dans les LdP. Comme mentionné ci-dessus, les LdP sont caractérisées par un ensemble de contraintes qui guident la dérivation de produits. Là aussi, seuls deux travaux [30, 20] utilisant UML font référence aux contraintes des LdP. Cependant aucun parmi ceux-là n utilise OCL (Object Constraint Language) [112] pour spécifier les contraintes des LdP bien que OCL soit un standard faisant partie d UML. Contributions La thèse que nous défendons s articule autour de trois contributions associées aux trois dimensions principales des LdP à savoir : la modélisation de la variabilité, la gestion des contraintes et la dérivation de produits. La première contribution de cette thèse concerne la modélisation de la variabilité dans les modèles UML. Nous étendons UML pour permettre la spécification de la variabilité dans deux types de modèles d UML : les diagrammes de classes et les diagrammes de séquence. Contrairement aux travaux existant, la modélisation de la variabilité dans les diagrammes dynamiques d UML est le coeur du travail présenté dans cette thèse. Nous proposons trois mécanismes pour spécifier la variabilité dans les diagrammes de séquence d UML. Comme nous le verrons par la suite, UML2.0 (la nouvelle version d UML) améliore considérablement les diagrammes de séquence d UML1.x en particulier par l introduction d opérateurs de composition. Nous utilisons ces opérateurs de composition pour spécifier algébriquement les diagrammes de séquence d UML2.0 sous forme de ce que nous appelons par la suite les expressions de référence. Nous étendons ces expressions par trois constructions algébriques de variabilité pour spécifier les diagrammes de séquence des LdP. La deuxième contribution concerne la gestion des contraintes de LdP dans les architectures modélisées en UML. Nous identifions deux types de contraintes dans les LdP : les contraintes génériques et les contraintes spécifiques et nous proposons d utiliser le langage OCL pour les formaliser.

16 Introduction La troisième contribution concerne la dérivation de produits. Nous défendons le principe qu une approche de manipulation de LdP en UML doit aller au delà des buts descriptifs et doit proposer un support pour instantier la variabilité introduite pour dériver les modèles UML de produits membres de la LdP. Nous formalisons cette dérivation en utilisant la transformation de modèles. Nous considérons la dérivation de modèles statiques de produits ainsi que leur comportements. La dérivation des modèles statiques est formalisée comme une transformation de modèle qui permet d obtenir le diagramme de classes d un produit particulier à partir de celui de la LdP. Pour réaliser la dérivation de comportements, nous avons étudié une problématique qui a attiré beaucoup d attentions ces dernières années. Il s agit de la génération (appelée aussi synthèse) automatique de machines à états à partir de diagrammes de séquence. Comme mentionné ci-dessus les diagrammes de séquence d UML2.0 améliorent la première génération par leur spécification algébrique. Nous proposons donc de revisiter le problème de la synthèse dans le contexte d UML2.0 en proposant une nouvelle approche algébrique. Nous étendons par la suite cette approche pour supporter la variabilité introduite dans les lignes de produits, aspect qui n est pas traité jusqu à maintenant dans les travaux existant autour de la synthèse. La dérivation de comportements sera donc définie comme une génération automatique de machines à états spécifiques aux produits à partir de diagrammes de séquence de la LdP. Les travaux présentés dans cette thèse ont fait l objet de diverses publications [83, 118, 120, 121, 123, 122, 119]. Plan du document Ce document est organisé en quatre parties : La première partie présente un état de l art; elle est divisée en trois chapitres : le chapitre 1 présente les lignes de produits logiciels et leurs concepts fondamentaux. Le chapitre 2 rappelle les principes d UML et ses concepts qui seront abordés dans le reste de ce document. Il présente aussi un état de l art des travaux existant autour de la manipulation de LdP en UML. Comme l aspect comportemental des LdP est le coeur du travail présenté dans cette thèse, le but du chapitre 3 est de présenter les scénarios et les machines à états comme des moyens pour la spécification de comportements. Nous discutons aussi les travaux existant sur la synthèse de machines à états à partir de scénarios. Les contributions de cette thèse sont détaillées dans la deuxième et troisième partie de ce document. La deuxième partie présente en deux chapitres notre contribution à la modélisation des LdP en UML. Le chapitre 4 détaille les extensions que nous proposons

Introduction 17 pour la modélisation de la variabilité dans les diagrammes de classes ainsi que dans les diagrammes de séquence. Ce chapitre présente aussi la spécification algébrique que nous proposons pour les diagrammes de séquence d UML2.0. Le chapitre 5 présente les deux types de contraintes de LdP que nous avons identifiées ainsi que leur formalisation en OCL. La troisième partie de ce document traite la dérivation de produits. Le chapitre 6 décrit la dérivation de modèles statiques. Le chapitre 7 détaille notre approche pour la génération de machines à états de produits à partir de diagrammes de séquence d une LdP. Le chapitre 8 discute le prototype que nous avons développé pour la dérivation de comportements ainsi que sa validation sur des études de cas. Il présente aussi les contributions aux projets européens CAFE [2] et FAMILIES [3] dans lesquels s inscrivent les travaux présentés dans cette thèse. La quatrième partie conclut ce document et présente des perspectives possibles des travaux présentés dans cette thèse.

18 Introduction

Première partie État de l art 19

Chapitre 1 Les Lignes de Produits Logiciels 1.1 Introduction L approche Lignes de produits (LdP) logiciels appelée aussi Famille de Produits 1 est une transposition des chaînes de production au monde du logiciel. Le principe est de minimiser les coûts de construction de logiciels dans un domaine d application particulier en ne développant plus chaque logiciel séparément, mais plutôt en le concevant à partir d éléments réutilisables. La première difficulté liée à cette approche réside dans la conception d une architecture permettant de définir plusieurs produits. Les membres d une ligne de produits sont caractérisés par leurs points communs, mais aussi par leurs différences (aussi appelées variabilité). La gestion de cette variabilité est l une des activités clé des lignes de produits. Dans une chaîne de production de véhicules, des voitures sont fabriquées à partir d un ensemble d éléments communs (roues, volant, vitres,..etc) mais peuvent comporter certaines caractéristiques qui les différencient (nombre de chevaux du moteur, présence ou non de la climatisation,..etc). Dans le monde logiciel, les différences peuvent apparaître de manière analogue, en fonction de choix techniques (utilisation d un type particulier de matériel), commerciaux (création d une version limitée), régionaux (produits destinés à plusieurs pays). Une autre difficulté de l utilisation d une ligne de produits concerne la construction d un produit logiciel (on parle aussi de dérivation de produit) qui consiste en partie à figer certains choix vis-à-vis de la variabilité définie dans la ligne de produits. De toute évidence, certains choix sont incompatibles entre eux. Si l on reprend l analogie ci-dessus, une voiture comporte généralement un seul moteur, et il faut alors choisir entre une motorisation essence ou diesel. De la même manière, un choix particulier lors de la dérivation d un logiciel peut exclure certaines variantes. Par exemple le choix d un cabriolet à toit amovible exclura 1 Dans [109], Frank van der Linden justifie l origine de deux appellations par l emplacement géographique : l appellation «ligne de produits» est utilisée aux États Unis d Amérique et «famille de produits» est utilisée en Europe. Nous utiliserons les deux appellations indifféremment dans ce document. 21

22 1.2 Des familles de programmes aux Lignes de produits la possibilité de choisir un toit ouvrant. Une ligne de produits doit donc aussi intégrer des contraintes de cohérence permettant de faciliter les choix lors de la dérivation. Le but de ce chapitre est de présenter l approche LdP en terme de concepts et de fondations. 1.2 Des familles de programmes aux Lignes de produits Bien que les Lignes de Produits Logiciel soient un nouveau paradigme du génie logiciel, la construction des familles de programmes a été déjà étudiée par David Parnas en 1976 [95]. Mais ce paradigme n a émergé que ces dernières années, lorsqu il a commencé à regrouper une communauté à travers les différent projets européens tels que ESAPS [1], CAFE [2], FAMILIES [3], aussi que les conférences SPLC (Software Product Line Conference) et PFE (Product Family Enginnering) entièrement consacrées à cette approche (troisième édition de SPLC en 2004 et cinquième édition de PFE en 2003). Il y a un consensus dans la littérature sur la définition d une ligne de produits logiciels. Une ligne de produits logiciel est un un ensemble de systèmes partageant un ensemble de propriétés communes et satisfaisant des besoins spécifiques pour un domaine particulier [27, 21]. Un domaine est un secteur de métier ou de technologies ou des connaissances caractérisées par un ensemble de concepts et de terminologies compréhensibles par les utilisateurs de ce secteur [27]. La définition ci-dessus de la ligne de produits caractérise les produits, membres de la ligne de produits, par un ensemble de propriétés communes (commonalité), mais aussi par leurs différences (variabilité). Nous présentons ici leur définitions, une discussion plus détaillée est présentée dans la section 1.5. La variabilité regroupe l ensemble des hypothèses montrant comment les produits, membres de la ligne de produits, diffèrent [115]. La commonalité regroupe l ensemble des hypothèses qui sont vraies pour tous les produits, membres de la ligne de produits [115]. 1.3 Une approche adoptée dans l industrie Motivée par la diversité des facteurs de variation des logiciels dans certains domaines, l approche ligne de produits a été adoptée depuis sa naissance dans l industrie. Le SEI (Software Engineering Insttiute) a publié plusieurs expériences industrielles prouvant

Les Lignes de Produits Logiciels 23 sa réussite [10]. Dans [75, 74], il est montré comment Nokia a opté pour l approche ligne de produits pour gérer la diversité des logiciels des téléphones mobiles. Dans [74], Maccari et al. estime que pour maintenir le marché, Nokia doit introduire sur le marché entre 30 et 40 nouveaux produits par an; ceci rend leur production à partir de zéro très difficile. En plus de cette donnée, Nokia doit aussi répondre à plusieurs facteurs de variation entre ses produits tel que la langue de l interface utilisateur. En effet, les produits de Nokia supportent approximativement 60 langues [74], chaque langue a ses propres particularités : les langues Occidentales sont basées sur les caractères latins et s affichent de gauche à droite, la longue arabe doit être affichée de droite à gauche avec le besoin de connecter les caractères pour apparaître comme une seul signe, et le chinois qui a aussi ses propres caractéristiques. Les produits de Nokia doivent aussi être compatibles avec les différent standards de communication numériques tel que GSM 900, GSM 1900, TDMA,..etc [75]. 1.4 L ingénierie de Domaine et d Application L ingénierie des lignes de produits logiciels, telle qu elle est définie dans la littérature [26, 1, 2], distingue deux niveaux, illustrés par la Figure 1.1 : Ingénierie du domaine et Ingénierie d application. Fig. 1.1: L ingénierie de lignes de produits

24 1.4 L ingénierie de Domaine et d Application 1.4.1 Ingénierie du domaine L ingénierie du domaine consiste à développer et construire les assets (un asset est un élément qui permet de développer un logiciel, par exemple un document de spécification, modèle, code,..etc.) qui seront réutilisés pour la construction de produits ; il s agit d un développement pour la réutilisation. Dans ce premier niveau, nous distinguons trois activités [26, 1, 2] : l analyse, la conception et l implantation du domaine. Le but de l analyse du domaine est d étudier le domaine de la ligne de produits et d identifier les commonalités et les variabilitiés entre les produits. Il existe plusieurs méthodes pour l analyse de domaine, la plus connue est FODA [62]. Le domaine dans FODA est décrit dans un modèle de caractéristiques (une caractéristique est appelée feature), spécifié sous forme d arbre dont les noeuds représentent les caractéristiques de domaine et les arcs spécifient des liens de composition entre les caractéristiques. FODA distingue trois catégories de caractéristiques : les caractéristiques obligatoires pour tous les produits membre de la LdP, les caractéristiques optionnelles qui sont présentes seulement dans certains produits et les caractéristiques alternatives. La Figure 1.2 montre un exemple de modèle de caractéristique FODA d une ligne de produits de voitures [26]. Chaque caractéristique dans le diagramme correspond à un concept du domaine. Les caractéristiques obligatoires sont représentées par des rectangles avec des cercles pleins, tandis que les caractéristiques optionnelles sont représentées par des rectangles avec des cercles vides. La caractéristique Climatisation dans le modèle FODA de la Figure 1.2 est optionnelle. Il existe trois types de moteurs dans une LdP de voitures : électrique, essence ou diesel; ceci est spécifié par une caractéristique alternative Moteur avec trois caractéristiques variantes Électrique, Essence, et Diesel. Une caractéristique alternative est représentée par un arc de cercle à travers les arcs des caractéristiques variantes. Le but de la conception de domaine est d établir une architecture logicielle générique de la ligne de produits. Il n y a pas de consensus sur la définition d une architecture logicielle et par conséquent pour l architecture de ligne de produits. Bass et al. [10] définissent une architecture logicielle de ligne de produits comme une architecture standard qui comporte un ensemble de composants, des connecteurs et des contraintes. Pour les lignes de produits, l architecture devrait être comme une architecture de référence à partir de laquelle l architecture de chaque produit est dérivée. La variabilité identifiée pendant l analyse de domaine doit être spécifiée explicitement dans l architecture de ligne de produits. L implantation de domaine consiste à implanter l architecture générique définie dans la conception de domaine sous forme de composants qui vont être réutilisés dans l ingénierie d application pour la construction de chaque produit.

Les Lignes de Produits Logiciels 25 Fig. 1.2: Exemple d un diagramme de caractéristiques FODA 1.4.2 Ingénierie d application L ingénierie d application consiste à utiliser les résultats de l ingénierie de domaine pour la construction, appelée aussi dérivation, d un produit particulier. Il s agit d un développement par la réutilisation (voir la Figure 1.1). Comme mentionné ci-dessus, les résultats de l ingénierie de domaine (les modèles de caractéristiques, l architecture générique, et les composants) contiennent de la variabilité, la dérivation d un produit particulier a donc besoin de décisions (ou des choix) associées à ces points de variation. La notion de modèle de décision [8] est utilisée pour capturer et enregistrer les décisions nécessaires à la dérivation de produits. 1.5 La variabilité logicielle La commonalité et la variabilité sont les concepts centraux dans les lignes de produits logiciels. Dans cette section, nous discutons plus en détail le concept de variabilité que celui de commonalité. Ceci est justifié par le fait que la gestion de la variabilité demande plus d efforts que celui des commonalité. En effet, les propriétés communes dans la LdP sont identifiées et utilisées telle qu elles pour la construction de tous les produits. Cependant la variabilité demande, en plus de son identification, des mécanismes pour sa gestion (on parle aussi de résolution de la variabilité). Même si l approche ligne de produits est un nouveau paradigme, la gestion de la variabilité logicielle n est pas un nouveau problème et plusieurs techniques de conception et de programmation permettent de la gérer [7, 105] (voir aussi section 1.5.3). Cependant en dehors du contexte de lignes de produits, la variabilité concerne un seul produit, c.à.d. la variabilité fait partie du produit et elle est résolue après que le produit est délivré et installé dans son environnement d exécution. Dans le contexte des lignes de produits, la variabilité doit être explicitement spécifiée et elle fait partie de la ligne de produits et au contraire de la

26 1.5 La variabilité logicielle variabilité d un seul produit, la variabilité dans les lignes de produits est résolue avant que le produit ne soit délivré et installé dans son environnement d exécution. Dans [8], Atkinson et al. appellent la variabilité contenue dans un seul produit la variabilité de temps d exécution et la variabilité contenue dans la ligne de produits la variabilité de temps de développement. Nous considérons en premier lieu dans ce document la variabilité de LdP, c.à.d. la variabilité résolue avant la délivrance et l installation des produits. 1.5.1 Les dimensions de la variabilité La variabilité logicielle apparaît en deux dimensions [17, 60] : le temps et l espace (voir la Figure 1.3) : La dimension du temps concerne la variation dans le temps d un seul produit logiciel. La Figure 1.3 montre l évolution dans le temps des produits d une version à une autre. La dimension de l espace concerne la variation entre plusieurs produits de la même famille. Les même éléments logiciels sont utilisés dans plusieurs produits et la variation concerne principalement des variations de fonctionnalités, c.à.d. les produits diffèrent dans les fonctionnalité qu ils supportent. Dans ce document nous considérons seulement la dimension de l espace, c.à.d. la variation dans les fonctionnalités. Fig. 1.3: La dimension espace et temps dans la variabilité

Les Lignes de Produits Logiciels 27 1.5.2 Les points de variation Dans les lignes de produits, la variabilité est identifiée durant l ingénierie de domaine et elle est introduite par ce qui est appelé les points de variations. Jacobson et al. [53] définissent un point de variation comme suit : Un point de variation identifie un ou plusieurs emplacements auxquels la variation peut se produire [53]. Un point de variation peut être vu comme un point de décision [39] avec plusieurs choix possibles appelés variants. Le noeud Moteur dans le diagramme FODA dans la Figure 1.2 est un exemple de point de variation avec trois caractéristiques variantes : Essence, Électrique et Diesel. L optionnalité est un cas particulier d un point de variation où le seul choix possible est la présence ou non de la caractéristique. Le noeud Climatisation représente un autre exemple de point de variation. En plus, au niveau du modèle de caractéristiques, les points de variation doivent apparaître à tous les niveaux d abstraction (exigences, architectures, implantation, tests,..etc.). Au niveau d architectures, les travaux [111, 24] ont étudié l extension des langages de description d architecture pour la spécification de la variabilité dans les architectures de lignes de produits. Nous présentons une étude détaillée dans le chapitre 2 sur les travaux existants autour de la modélisation des architectures de LdP en UML. Dans la suite, nous discutons la variabilité au niveau de l implantation. 1.5.3 La variabilité au niveau de l implantation Plusieurs techniques au niveau de l implantation permettent la gestion de la variabilité. Les deux travaux [7, 105] citent quelques techniques pour le gestion de la variabilité au niveau de l implantation. Parmi les techniques et approches utiles pour la gestion de la variabilité au niveau de l implantation on peut retenir : Les techniques de compilation Elles permettent la dérivation d un produit pendant la phase de compilation. La compilation conditionnelle et le chargement de bibliothèques sont des exemples de ces techniques. Elles sont utiles si la variabilité concerne les parties de code à inclure ou à exclure et dans les bibliothèques qu ils utilisent. Les techniques liées aux langages de programmation Les langages à objets (LAO) ont apporté quelques techniques utiles pour implanter la variabilité. Citons l abstraction à travers la notion d héritage, la surcharge et la liaison dynamique. Les points de variation peuvent être définis comme abstraits et redéfinis par chaque variant d une manière spécifique. Certains LAO permettent de définir des classes paramétrées, appelées classes templates. La variabilité peut être implantée en utilisant les classes templates lorsque les variantes ne diffèrent que sur un ensemble de types de paramètres.

28 1.6 Les contraintes Les patrons de conception Les patrons de conception [31] fournissent des solutions réutilisables pour certains type de problèmes. Dans [59], le patron de conception fabrique abstraite (Abstract Factory) est utilisé pour la réification des variants. La fabrique abstraite permet de définir une interface pour la création des produits concrets. [63] propose un ensemble de patrons pour modéliser la variabilité. Des approches de programmation Des approches récentes de génie logiciel peuvent être utilisées pour implanter et gérer la variabilité dans les systèmes. La séparation des aspects [65] est une approche permettant de réduire la complexité des systèmes. Le principe est de décomposer le problème en un ensemble de composants fonctionnels et d aspects transversaux. Quelques travaux [7, 13, 12, 36] proposent d utiliser cette approche pour la gestion de la variabilité dans les LdP. L idée est que pour implanter la variabilité les aspects peuvent être vus comme des points de variation et chaque produit, membre de la LdP, est différencié par l ensemble des aspects qu il utilise. Le travail de Lopez-Herrejon et al. [73] présente une étude de cas sur l implantation d une ligne de produit en AspectJ. La programmation générative [26] est une approche qui s intéresse au développement des familles de systèmes, elle est basée sur la notion de «générateur». La variabilité dans les LdP peut être implantée en développant des générateurs comme des artefacts génériques, leur instantiation permet de générer l implantation d un produit. Dans [11], Batory et al. propose une autre approche générative pour la gestion des variants. Dans [82, 81], une approche pour gérer la variabilité basée sur l évaluation partielle des programmes C. Même si ces travaux au niveau d implantation se basent sur des technologies et des techniques qui ont connu une réussite remarquable dans le domaine du génie logiciel, la maîtrise du code devient de plus en plus difficile à gérer avec la croissance exponentielle de la complexité des logiciels. 1.6 Les contraintes En plus de la variabilité, les lignes de produits logiciels sont caractérisées par des contraintes de dépendance entre les points de variations. En effet, la résolution d un point de variation peut influencer la résolution d autres points de variation. FODA, la méthode de l analyse de domaine présentée ci-dessus, introduit les règles de composition comme un moyen pour décrire les contraintes de dépendances dans un modèle de caractéristiques. FODA [62] permet de décrire deux types de règles de composition : de présence et d exclusion. La règle de présence spécifie que le choix d une caractéristique optionnelle ou variante exige la présence d une autre caractéristique optionnelle ou variante. La règle d exclusion entre deux caractéristiques spécifie qu elles ne peuvent pas être présentes dans le même produit. Les contraintes des lignes de produits appa-

Les Lignes de Produits Logiciels 29 raissent aussi au niveau de l architecture. Bass et al. [10], considèrent d ailleurs que les contraintes font partie de l architecture des LdP. Le travail de Jaring et al. [54] présente une classification des contraintes de LdP. Nous verrons dans le chapitre suivant que peu de travaux utilisant UML pour la modélisation des architectures de lignes de produits modélisent les contraintes de LdP. L une des contributions de cette thèse est de proposer l utilisation d OCL (Object Constraint Langage) pour la spécification de ces contraintes ; ceci est présenté dans le chapitre 5. 1.7 Conclusion Dans ce chapitre nous avons présenté les concepts et les principes fondamentaux de l approche ligne de produits logiciels. Cette approche introduit trois nouvelles activités dans les activités classiques de développement des systèmes : La modélisation de la variabilité. La variabilité est la caractéristique principale dans une LdP. Donc la première activité est la modélisation et la spécification explicite de la variabilité à travers l introduction des points de variation. La gestion des contraintes. Une LdP est caractérisée aussi par un ensemble de contraintes spécifiant des propriétés de dépendances entre les points de variation. Donc, la deuxième activité est la gestion de ces contraintes. La dérivation des produits. La dérivation d un produit, membre de la LdP, consiste en partie à instantier les différent points de variation définis dans la ligne de produits et générer les produits. Nous nous sommes intéressés dans ce document à la manipulation des architectures de lignes de produits en UML. Nous considérons donc la variabilité au niveau des architectures des LdP modélisées en UML. Le travail présenté dans cette aborde les trois activités ci-dessus. La deuxième partie de ce document présente notre approche autour des deux premières activités, la troisième partie décrit notre approche pour la dérivation des produits.

30 1.7 Conclusion

Chapitre 2 UML pour la modélisation de Ligne de Produit 2.1 Introduction UML (Unified Modeling Language) est le standard de l OMG (Object Groupe Management) pour la modélisation orientée objet des systèmes logiciels. Il propose un ensemble de notations, sous forme de diagrammes, pour la documentation et la spécification des systèmes. Les diagrammes d UML modélisent le logiciel selon différent points de vues : vue fonctionnelle, vue statique, vue dynamique et vue d implantation et de déploiement. UML est essentiellement destiné à modéliser un seul produit logiciel à la fois. Cependant comme nous allons voir dans ce chapitre, plusieurs travaux se sont intéressés à l utilisation d UML pour la modélisation des LdP. Ceci s explique par deux raisons principales : UML est un standard largement adopté dans l industrie et il existe plusieurs outils qui le supportent. UML définit des mécanismes standards d extensions permettant d étendre et d adapter sa notation et sa sémantique à un domaine particulier. Les stéréotypes et les tagged values sont des exemples de ces mécanismes. L objectif principal de ce chapitre est de faire un état de l art sur les travaux existants dans la littérature autour de la manipulation des lignes de produits en UML. Nous commençons par un bref rappel d UML et des concepts qui seront abordés dans ce document. 2.2 Unified Modeling Language (UML) La notation UML (Unified Modeling Language) [93, 86, 94] constitue une étape importante dans la convergence des notations utilisées dans le domaine de l analyse et la conception objet puisqu elle représente une synthèse des méthodes les plus utili- 31

32 2.2 Unified Modeling Language (UML) sées : OMT (Object Modeling Technique) [100], Booch [16] et OOSE(Object-Oriented Software Engineering) [52]. Depuis la première version d UML, le standard de l OMG (Object Management Groupe) n a pas cessé d évoluer. Cependant la refonte majeure d UML est le standard UML2.0 [94, 86] adopté en Août 2OO3. UML2.0 représente un pas réel pour supporter la croissance des logiciels actuels, d une part par le support de la nouvelle vision de l OMG à savoir MDA (Model Driven Architecture) [102], et d autre part par le support des nouvelles technologies en particulier l approche par composants logiciels. 2.2.1 Une sémantique à base de méta-modélisation Depuis ses premières versions, le standard UML est caractérisé par sa sémantique définie par une approche de méta-modélisation. Un méta-modèle est la définition des constructions et des règles de création des modèles [80]. Le méta-modèle d UML définit donc la structure que doit respecter tout modèle UML. Le méta-modèle d UML1.x est défini dans un seul document, cependant le standard UML2.0 est maintenant divisé en deux documents : UML2.0 Infrastructure [86] et UML2.0 Superstructure [94]. UML Infrastructure décrit les constructions fondamentales utilisées pour la définition d UML2.0 sous forme d une librairie d infrastructure (InfrastructureLibrary). UML Superstructure réutilise et raffine la librairie d infrastructure et définit le méta-modèle proprement dit, vu par les utilisateurs. L approche de méta-modélisation adoptée par l OMG est connue comme une hiérarchie à quatre niveaux [86] (voir la Figure 2.1) : Niveau méta-méta-modèle (M3). M3 est le niveau méta-méta-modèle, il définit le langage de spécification du méta-modèle. Le MOF (Meta Object Facility) [87] est un exemple d un méta-méta-modèle. Niveau méta-modèle (M2). M2 est le niveau méta-modèle. Le méta-modèle d UML se situe à ce niveau et il est spécifié en utilisant le MOF, c.à.d. les concepts du méta-modèle d UML sont des instances des concepts de MOF. La Figure 2.1 montre deux méta-classes du méta-modèle UML : Class et Association. Niveau modèle (M1). M1 correspond au niveau des modèles UML des utilisateurs. Les concepts d un modèle UML sont des instances des concepts du méta-modèle UML. La Figure 2.1 montre un extrait de diagramme de classes pour une application bancaire contenant deux classes Account et Customer liées par une association UML. Les deux classes sont des instances du méta-classe Class et le lien est une instance du méta-classe Association du méta-modèle UML. Niveau objets (M0). M0 correspond au niveau des objets à l exécution. Il s agit ici de deux objets must et acc des instances des deux classes Customer et Account respectivement.

UML pour la modélisation de Ligne de Produit 33 Le méta-modèle d UML [94] est décrit en utilisant une partie de la notation d UML lui même. Les concepts suivants sont utilisés : Les classes d UML, pour décrire les méta-classes. Les attributs, pour décrire les propriétés attachées à une méta-classe. Les associations, pour décrire des liens entre les méta-classes. Les paquetages (packages), pour regrouper les méta-classses par domaine. Fig. 2.1: L architecture à quatre niveaux de l OMG 2.2.2 Les contraintes OCL Le méta-modèle UML spécifie la structure que doit respecter tout modèle UML. En d autre terme, il spécifie des contraintes structurelles sur ces modèles. UML inclut le langage OCL (Object Constraints Language) [112] comme un moyen supplémentaire pour renforcer les contraintes structurelles des modèles UML en ajoutant des invariants sur les classes du méta-modèle d UML. Les contraintes OCL au niveau méta-modèle représentent donc des règles de conformité des modèles UML, elles sont exprimées au niveau méta-modèle et elles sont évaluées sur tous les éléments de modèles UML, instances des éléments du méta-modèle d UML. Les contraintes OCL sont étendues pour être utilisées aussi pour exprimer des propriétés sur un modèle UML (niveau M1). Elles sont utilisées pour spécifier des invariants, des pré et des post conditions sur les opérations et des gardes sur les transitions dans

34 2.2 Unified Modeling Language (UML) les machines à états. Les contraintes exprimées au niveau M1 sont évaluées et vérifiées sur les modèles d objets (niveau M0). 2.2.3 Les diagrammes La notation UML est décrite sous forme d un ensemble de diagrammes. La première génération d UML (UML1.x), définit neuf diagrammes pour la documentation et la spécification des logiciels. Dans UML2.0 Superstructure [94], quatre nouveaux diagrammes ont été ajouté : il s agit des diagrammes de structure composite (Composite structure diagrams), les diagrammes de paquetages (Packages diagrams), les diagrammes de vue d ensemble d interaction (Interaction overview diagrams) et les diagrammes de synchronisation (Timing diagrams). Ils sont regroupés dans deux classes principales : Diagrammes statiques Regroupe les diagrammes de classes, les diagrammes d objets, les diagrammes de structure composite, les diagrammes de composants, les diagrammes de déploiement, et les diagrammes de paquetages. Diagrammes dynamiques Les diagrammes de séquence, les diagrammes de communication (nouvelle appellation des diagrammes de collaboration d UML1.x), les diagrammes d activités, les machines à états, les diagrammes de vue d ensemble d interaction, et les diagrammes de synchronisation. Dans ce document nous nous somme intéressés à trois types de diagrammes : les diagrammes de classes, de séquence, et les machines à états. Le chapitre 3 décrit les deux derniers diagrammes. Nous décrivons brièvement dans ce qui suit les diagrammes de cas d utilisation et les diagrammes de classes (nous avons choisi de présenter aussi les diagrammes de cas d utilisation car il existe plusieurs travaux dans la littérature autour de la modélisation des cas d utilisation dans le contexte de lignes de produits). Les autres diagrammes sont présentés en détail dans [94]. Les diagrammes de cas d utilisation Les cas d utilisation (use cases) représentent l apport principal de Ivar Jaccobson et sa méthode OOSE [52] à UML. L objectif des cas d utilisation est l expression des besoins en termes de services que doit assurer le système. Les diagrammes de cas d utilisation dans UML définissent deux concepts principaux : les acteurs, et les cas d utilisation. Un acteur est une entité extérieure du système qui peut initier l un de ses cas d utilisation. Un cas d utilisation est une fonctionnalité offerte par le système. La Figure 2.2 montre un diagramme de cas d utilisation pour un exemple d une application bancaire. L acteur principal est le guichetier de la banque (Clerk) qui peut initier trois cas d utilisation de système : Withdraw from account, Deposit on account, and Account creation.

UML pour la modélisation de Ligne de Produit 35 Les diagrammes de cas d utilisation permettent de définir deux types de relations entre les cas d utilisation : l inclusion et l extension. Un cas d utilisation peut être compris dans un autre cas d utilisation; ceci signifie que le service spécifié par le deuxième est compris dans le service du premier. Un cas d utilisation peut étendre un cas d utilisation père; ceci signifie que le service du premier est une spécialisation du service du deuxième. Les relations entre les cas d utilisation sont notées comme des flèches de dépendances avec les mots-clés <<include>> pour l inclusion et <<extend>> pour l extension. Bank Account creation Clerk Withdraw from account Deposit on account Fig. 2.2: Le diagramme de cas d utilisation d une application bancaire Diagrammes de classes Le diagramme de classes permet de définir la structure de toutes les classes qui constituent un système. Une classe est définie en plus de son nom par des attributs et des méthodes. Le diagramme de classes dans la Figure 2.3 montre deux classes Account et Customer, la classe Account est définie avec un attribut balance et trois méthodes getbalance, deposit et withdraw. En plus de la structure des classes, le diagramme de classes définit aussi des relations entre ses classes. Les associations d UML sont des exemples de ces relations. Une association UML peut contenir des informations supplémentaires : le nom de l association, le rôle de chaque classe dans l association et les cardinalités de chaque classe dans l association. L association définie dans le diagramme de classes de la Figure 2.3 illustre la relation de possession entre les deux classes Account et Customer. Une instance de la classe Customer peut être liée à un ensemble d instances de la classe Account (cardinaltité *). Cependant une instance de la classe Account est liée à une et une seule instance de la classe Customer (cardinatilité 1..1). UML offre aussi des mécanismes d abstraction dans les diagrammes de classes

36 2.2 Unified Modeling Language (UML) à travers les notions de l héritage, de classes abstraites, et d interfaces. L héritage (spécialisation/généralisation) est un mécanisme permettant à une sous-classe d hériter des attributs et des méthodes d une autre classe appelée super-classe. Une sous-classe peut redéfinir l implantation d une ou de plusieurs méthodes de la super-classe : c est le mécanisme de la surcharge. Une classe abstraite peut contenir des méthodes dont le corps est défini par ses sous-classes. Le nom d une classe abstraite dans un diagramme de classes est noté en italique. Une classe d interface définit seulement les signatures des méthodes sans aucune implantation et ses sous-classes fournissent leur implantation. Une classe d interface est notée avec le stéréotype <<Interface>>. Les classes peuvent être regroupées dans des paquetages. Un paquetage UML (Package) est un espace de nommage. La Figure 2.3 illustre un paquetage UML appelé Bank qui regroupe les deux classes Account et Customer. bank Customer name : string adresse : string 1 * Account #balance : real +getbalance() +withdraw(in amount:real) +deposit(in amount:real) Fig. 2.3: Extrait d un diagramme de classes d une application bancaire 2.2.4 Extensibilité A priori la notation UML est destinée à la modélisation de tout type de systèmes. Cependant certains systèmes dans des domaines spécifiques sont caractérisés par des propriétés qui nécessitent l ajout d informations supplémentaires. Prenons par exemple le domaine des systèmes temps réel pour lesquels il est nécessaire de spécifier des propriétés de qualité de services. La notation standard d UML ne permet pas d ajouter une telle information d où le besoin d une extension de cette notation. En plus des domaines spécifiques, il y a aussi le besoin d adapter UML à une plate-forme technique particulière. Par exemple, pour modéliser un système qui sera implanté sur une plate-forme de type EJB (Entreprise Java Beans), on aura besoin de dire qu une classe particulière joue le rôle d un composant EJB (Bean). Pour répondre à ces besoins particuliers, l OMG a introduit depuis la version UML1.3 des mécanismes dits d extension permettant de spécialiser et d adapter UML

UML pour la modélisation de Ligne de Produit 37 à des domaines, des plate-formes ou des méthodes spécifiques. Les mécanismes d extension introduits depuis la version UML1.3 sont les Tagged Values, les Stéréotypes, et les Contraintes. La notion de Profil est introduite comme un moyen pour structurer et regrouper les trois mécanismes précédents. L OMG a standardisé des profils dans certains domaines particuliers. On trouve par exemple un profil UML pour les systèmes temps réel [92], un profil UML pour les applications d entreprise distribuées (EDOC) [91] et aussi des profils UML pour les plate-formes EJB et CORBA. En plus de ces profils standardisés, les utilisateurs peuvent définir leur propre profil et certains ateliers comme Objecteering de Softeam permettent de les implanter et les intégrer dans l environnement de modélisation [101]. Les profils dans le standard UML2.0 font partie de la librairie d infrastructure [86]. La Section Extension Mechanisms dans UML1.x [93] est remplacée par un paquetage appelé Profils dans UML2.0 Infrastructure. Nous décrivons brièvement dans ce qui suit deux concepts essentiels dans ce paquetage, à savoir les stéréotypes et les profils. Le lecteur peut consulter le document UML Infrastructure [86] pour une présentation détaillée. Les stéréotypes Le stéréotype est le mécanisme de base pour l extension d UML. Il définit comment une méta-classe particulière du méta-modèle d UML peut être étendue pour permettre l utilisation d une terminologie ou d une notation spécifique à un domaine ou une plate-forme particulière. Un stéréotype est lié par un lien d extension [86] à une méta-classe particulière du méta-modèle. Les tagged values introduits dans UML1.x sont considérés dans UML2.0 comme des propriétés des stéréotypes. Quand un stéréotype est appliqué à un élément du modèle (instance de la méta-classe sur laquelle le stéréotype est défini), cet élément sera noté par <<label stéréotype>> et les valeurs de ses propriétés si elles existent, seront considérées comme des tagged values associés à cet élément. Un tagged value a un nom et un type. La Figure 2.4 montre un exemple de définition de deux stéréotypes [86] : Clock et Creator. Le stéréotype Clock étend les deux méta-classes Class et Component et il définit une propriété resolution comme un tagged value dont le type est integer. Le lien d extension est noté par une flèche orientée (voir Figure 2.4). Les Profils Un profil, par définition, étend un méta-modèle de référence ou un autre profil [86]. Le méta-modèle de référence peut être le méta-modèle d UML ou un autre méta-modèle basé sur la librairie d infrastructure. L appellation profil UML est utilisée pour désigner un profil dont le méta-modèle de référence est le méta-modèle UML. Les profils UML peuvent être considérés comme des dialectes du langage UML [86]. Un

38 2.2 Unified Modeling Language (UML) profil UML regroupe un ensemble de stéréotypes et tagged values. La Figure 2.4 montre un exemple du profil UML appelé Example regroupant les deux stéréotypes Clock et Creator. Les profils dans UML2.0 sont notés comme des paquetages UML avec le stéréotype <<profile>>. Le paquetage UserExample est un exemple de modèle utilisateur basé sur le profil Example. La classe StopWatch est définie avec les deux stéréotypes de profils et les tagged values associées aux stéréotypes sont définis comme des notes UML (voir la Figure 2.4). Fig. 2.4: Exemple de spécification d un profil UML2.0 et son utilisation En plus des stéréotypes et des tagged values, un profil UML peut contenir aussi des contraintes et des règles [88]. Les contraintes spécialisent la sémantique des éléments du méta-modèle de référence sous le profil. Elles peuvent être associées aux méta-classes ou aux stéréotypes dans le contexte du profil. Les règles dans un profil UML décrivent en particulier comment le profil est utilisé. Par exemple, elles peuvent décrire comment le code est généré à partir de modèles basés sur ce profil ou comment ces modèles sont transformés en d autre modèles,..etc. Les règles dans un profil sont souvent définies en utilisant un langage de transformation de modèle. L atelier Objecteering par exemple propose un langage appelé J pour la définition des règles d un profil [101]. 2.2.5 Ingénierie des modèles Apres le succès d UML, la nouvelle voie de l OMG est MDA (Model Driven Architecture) [102]. MDA est une démarche de développement basées sur les modèles qui permet de séparer les spécifications fonctionnelles d un système des spécification de sa réalisation. La notion de PIM (Platform Independant Model) est utilisée pour la spécification des fonctionnalités de système indépendamment de toutes plate-formes d implantation. Cependant la notion de PSM (Platform Independant Model) spécifie le système selon une plate-forme technologique particulière. MDA est une réalisation d une approche générale de génie logiciel appelée Ingénierie de Modèle [25], ou MDE (Model Driven Engineering) La transformation de modèles est un concept clé dans MDE. En effet, un logiciel est

UML pour la modélisation de Ligne de Produit 39 construit selon MDE par transformation de modèles : des modèles métiers jusqu a la génération de code. Les paragraphes suivants discutent la transformation de modèles et présente un exemple de langage de transformation, en occurrence MTL qu on va utiliser dans le chapitre 6 de ce document. Transformation de modèles Une transformation de modèle consiste à traduire un modèle donné appelé modèle source, en un autre modèle, appelé modèle cible [25]. Une transformation de modèle peut être un simple raffinement d un modèle source ou une transformation entre deux modèles différents. La génération de code Java par exemple à partir d un modèle UML est un autre exemple de transformation ou le modèle cible est un programme Java. La Figure 2.5 montre l architecture type des transformations de modèles [25]. Une transformation est appliquée à un modèle source vers un modèle cible. Les modèles sources et cibles sont basés sur des méta-modèles, donc la transformation est définie au niveau de ces méta-modèles (voir la Figure 2.5). Fig. 2.5: Les transformations de modèles Model Transformation Languge (MTL) MTL (Model Transformation Language) [4] est un langage de transformation de modèles développé dans l équipe Triskell et qui implante l architecture type dans la

40 2.2 Unified Modeling Language (UML) Figure 2.5. MTL est un langage orienté objet permettant d écrire des programmes pour la transformation de modèles instances du méta-modèle UML ou d autres méta-modèles. Il permet de se connecter à des dépositaires de modèles pour naviguer dans un modèle présent dans le dépositaire ou éventuellement le modifier. MTL peut être utilisé avec des dépositaires différents grâce à son API générique. MTL est caractérisé aussi par son système du typage proche d OCL. Pour permettre la réutilisation, les transformation sont définies dans des bibliothèques. La bibliothèque ElementCollecting ci-dessus manipule un modèle appelé source_model. Elle définit une fonction collectmodelelementsnames() permettant de parcourir un modèle source et de récupérer dans une liste les noms de tous ses éléments. Le parcours d un ensemble d éléments d un modèle en MTL est réalisé en utilisant des objets de type Iterator de la bibliothèque Standard. (1) library ElementCollecting; model source_model : RepositoryModel;... (2) collectmodelelementsnames (set : Standard : :Set) : Standard : :Set { (3) ret : Standard : :Set (4) elementiterator : Standard : :Iterator; (5) anelement : source_model : :Core : :ModelElement; (6) elementiterator := := set.getnewiterator(); (7) elementiterator.start(); (8) while elementiterator.ison() { (9) anelement := elementiterator.item().oclastype( (10)!source_model : : : :Core : :ModelElement!); (11) ret := ret.including(element.name.oclastype( (12)!Standard : :String!)); (13) elementiterator.next(); } (14) return ret; }... MTL est un exemple d implantation du futur standard de l OMG pour la transformation de modèle appelé QVT (Queries Views Transfortmations) [90]. Nous utilisons MTL dans le chapitre 6 pour la dérivation de l aspect statique de produits. Le modèle de classes d un produit est obtenu par spécialisation du modèle de classes de la LdP.

UML pour la modélisation de Ligne de Produit 41 2.3 État de l art sur la modélisation de LdP en UML L objectif de cette section est de présenter les travaux existant autour de la modélisation des LdP en utilisant le standard UML. Nous présentons ces travaux selon les trois activités principales de l ingénierie de LdP à savoir : la modélisation de la variabilité, la gestion des contraintes et le support de la dérivation de produits. 2.3.1 Modélisation de la variabilité dans les modèles UML Comme nous l avons mentionné dans le chapitre 1, la gestion de la variabilité est l activité essentielle dans une approche supportant les LdP. Les travaux utilisant UML se sont intéressés à la modélisation de la variabilité dans les diagrammes d UML. Dans la suite, nous présentons des travaux qui modélisent la variabilité dans les diagrammes de cas d utilisation, les diagrammes statiques et les diagrammes dynamiques. Les cas d utilisation Halmans et al. [39] présente une étude détaillée sur la modélisation de la variabilité dans les cas d utilisation. Cet article étend aussi les cas d utilisation par une nouvelle notation pour décrire les points de variation. Un point de variation est représenté graphiquement dans un diagramme de cas d utilisation par un rectangle. Les auteurs distinguent deux types de points de variation : les points de variation obligatoires (ils sont représentés par des rectangles noirs ) et la points de variation optionnels (ils sont représentés par des rectangles gris). Les variants sont des cas d utilisation stéréotypés <<variant>>. Un point de variation peut définir plusieurs cas d utilisation variants ; ceci est modélisé par des liens reliant les cas d utilisation variants aux points de variation associés. Ces liens portent des cardinalités spécifiant le nombre minimum et maximum de variants à choisir dans un produit particulier. Bertolino et al. [14] propose deux approches pour la modélisation des cas d utilisation dans les lignes de produits. Dans l approche basée sur l introduction explicite de la variabilité, des étiquettes (tags) sont introduites dans la description textuelle des cas d utilisation pour permettre l introduction des points de variation dans les cas d utilisation de la ligne de produits. Les cas d utilisation des produits sont dérivés par la résolution des points de variation. Maßen et al. [110] fait une proposition pour étendre le méta-modèle d UML pour spécifier explicitement la variabilité. Trois nouvelles méta-classes sont introduites : VariationPoint, Alternative et Option, décrivant trois nouvelles relations entre les cas d utilisation (en plus des deux standards : inclusion et extension décrites ci-dessus).

42 2.3 État de l art sur la modélisation de LdP en UML John et al. [57] étend les cas d utilisation d UML et leur description textuelle pour décrire ce qui est appelé par les auteurs des cas d utilisation génériques. Des étiquettes proches de celles de [14] sont introduites pour décrire la variabilité. Le stéréotype <<variant>> est associé aux cas d utilisation optionnels. Ce même stéréotype peut être appliqué aussi aux acteurs. Gomaa et al. [34] introduit la variabilité dans les cas d utilisation en utilisant trois stéréotypes <<kernel>>, <<optional>> et <<variant>>. Ces même stéréotypes sont aussi utilisés pour décrire la variabilité dans les diagrammes de classes. Discussions L introduction des nouvelles représentations graphiques (comme proposées dans [39]) pour décrire la variabilité dans les cas d utilisation nous semble une solution appropriée. En effet, l introduction des cardinalités par exemple dans les diagrammes de cas d utilisation proposé dans [39] viole le méta-modèle d UML1.4 auxquels les auteurs se référèrent. [14, 57] s intéressent à la représentation textuelle des cas d utilisation à l aide des templates. Les cas d utilisation peuvent être décrits aussi à l aide des diagrammes de séquence d UML. Les diagrammes statiques KobrA KobrA [8, 9] est une nouvelle méthode pour l ingénierie des composants logiciels. L objectif principal de KobrA est de combiner les approches par composants et Ligne de Produits pour le développement des systèmes. La structure statique des composants KobrA (Komponents) est décrite par des diagrammes de classes d UML. La variabilité est introduite à l aide d un seul stéréotype : <<variant>>. Ce stéréotype peut être appliqué aux paquetages, aux classes, aux attributs et aux méthodes de classes dans un diagramme de classes. SPLIT-Daisy La méthode SPLIT (Software Product Line Integrated Technology) [22] est développée dans un laboratoire commun entre Alcatel et Thales appelé LCAT. SPLIT-Daisy [61] s intéresse à la description des architectures de lignes de produits en utilisant UML (quatre approches au total sont définies dans SPLIT [22], les trois autres sont : Cloud, Ladder et Wheels). La variabilité est introduite par la notion de point de variation. Un point de variation est représenté comme une classe UML stéréotypée <<variation-point>> avec un ensemble d attributs. Un point de variation est associé à un élément particulier de modèle statique (une classe ou un paquetage UML) et il est défini par un ensemble de classes ou de paquetages variants. Un point de variation est défini aussi par un mécanisme de variabilité ; il est représenté comme un stéréotype appliqué à une association reliant le point de variation et son élément. SPLIT introduit trois mécanismes de variabilité [61] : <<extend>>, <<insert>> et

UML pour la modélisation de Ligne de Produit 43 <<parametrize>> ; le mécanisme extend par exemple est utilisé quand l héritage est introduit pour étendre la définition d une classe jouant le rôle d un point de variation. VPM [113, 114] propose une méthode appelée VPM (Variation Point Model) pour décrire les points de variation dans les lignes de produits. Un point de variation dans VPM est désigné par le symbole (ce symbole est le même que celui introduit par [53]). La vue statique de l architecture de LdP est spécifiée comme un diagramme de classes UML étendu par un tagged value désignant un point de variation. Il est appliqué aux méthodes de classes affectées par ce point de variation. Les méthodes associées à un point de variation seront raffinées au moment de la dérivation des produits. Le raffinement est basé sur trois mécanismes de l orienté objet : l héritage, la paraméterization et la délégation. Flege. [30, 29] définit l optionnalité comme le seul mécanisme de variabilité. L optionnalité est introduite en utilisant deux stéréotypes : <<Optional>> pour désigner qu un élément de modèle est optionnel. Le stéréotype <<HasVariability>> est associé à un élément non optionnel mais qui contient un ou plusieurs éléments optionnels (par exemple un paquetage UML qui contient une ou plusieurs classes optionnelles). Clauß Clauß a étudié la possibilité d étendre le méta-modèle d UML pour décrire la variabilité. Le premier travail [20] de cet auteur se concentre en particulier sur l introduction d un ensemble de stéréotypes pour permettre de décrire un modèle de caractéristiques FODA (cf. section 1.4.1) comme un diagramme de classes d UML. Chaque caractéristique est spécifiée comme une classe UML et Clauß introduit trois stéréotypes, un pour chaque type de caractéristiques dans FODA : <<mondatory>>, <<optional>>, <<alternative>>. Dans [19], Clauß propose des extensions pour spécifier la variabilité au niveau de l architecture statique de la LdP modélisée par un diagramme de classes. Ici trois stéréotypes appliqués aux classes d UML ont été introduits : <<optional>> pour désigner une classe optionnelle, <<variationpoint>> et <<variant>> respectivement pour désigner un point de variation et ses sous-classes variantes. Gomaa et al. Gomaa avec ses co-auteurs se sont intéressés à la modélisation de lignes de produits en utilisant UML dans plusieurs travaux [33, 34, 35]. Dans [33, 34], trois stéréotypes : <<kernel>>, <<optional>> et <<variant>> ont été introduits pour décrire les classes obligatoires, optionnelles et variantes respectivement dans les diagrammes de classes. Robak et al. [99] présente une étude sur les travaux relatifs à la modélisation de la variabilité dans UML. Les auteurs ont étudié les travaux qui ont fait la correspondance entre les modèles de caractéristiques et les modèles UML et ils proposent par

44 2.3 État de l art sur la modélisation de LdP en UML la suite un stéréotype <<variable>> et un tagged value feature pour spécifier la variabilité dans les modèles de composants d UML. Un composant UML, d après les auteurs, implante une ou plusieurs caractéristiques et, pour garder la trace sur la caractéristique implantée par le composant, le tagged value feature est associé au stéréotype <<variable>>. Il prend comme valeur le nom de la caractéristique implantée par le composant. Discussions Un nombre important des travaux se sont intéressés aux diagrammes statiques d UML et en particulier aux diagrammes de classes. Ceci à notre avis peut être expliqué par deux raisons principales : La majorité des travaux [33, 20, 99] s inspirent des modèles de caractéristiques qui introduisent la variabilité au premier niveau d abstraction (niveau de l analyse du domaine discuté dans la section 1.4.1). En effet, le modèle de caractéristiques, comme celui de FODA, décrit une structure statique du domaine en terme de concepts et des relations entre eux. Czarnecki et al. [26] justifie même qu il y a une grande similarité entre la notion de concept dans le modèle de caractéristique et de classe dans les langages orientés objet. La deuxième raison est plus liée à la nature des diagrammes de classes eux même. En effet, les diagrammes statiques en particulier ceux de classes sont la vue principale dans la notation UML. L approche que nous proposons dans le chapitre 4 pour la modélisation des LdP considère les diagrammes statiques d UML et elle propose des extensions pour décrire la variabilité dans les diagrammes de classes d UML (voir le chapitre 3). Nos extensions prennent l avantage d être bien formalisées. En effet, là où les approches existantes introduisent seulement des stéréotypes et/ou des tagged values, nous formalisons nos extensions sous forme un profil UML regroupant des stéréotypes mais aussi des contraintes OCL spécialisant la sémantique des méta-classes étendues. Les diagrammes dynamiques KobrA Les diagrammes de séquence et les machines à états d UML sont utilisés dans KobrA respectivement pour la spécification des interactions et le comportement des composants KobrA (Komponent). Le même stéréotype <<variant>>, utilisé pour documenter la variabilité dans les diagrammes statiques, est aussi réutilisé pour décrire la variabilité dans les diagrammes de séquence et dans les machines à états. La variabilité introduite par KobrA dans les diagrammes de séquence concerne l optionnalité des messages échangés entre les objets. Un message stéréotypé <<variant>> est optionnel, c.à.d. il est seulement supporté par certains produits membres de la LdP. Dans les machines à états, les états et les transitions optionnels sont stéréotypés <<variant>>.

UML pour la modélisation de Ligne de Produit 45 Gomaa Dans [33], Gomaa modélise les machines à états et les diagrammes de collaboration des lignes de produits sans utilisation des extensions. En effet, la variabilité est seulement introduite dans les cas d utilisation et les diagrammes de classes en utilisant les trois stéréotypes présentés ci-dessus : <<kernel>>, <<optional>> et <<variant>>. Des diagrammes de collaboration sont définis pour tous les types de cas d utilisation (optionnel, obligatoire et variant) et le choix d un diagramme de cas d utilisation implique le choix de diagramme de collaboration correspondant. De la même manière, les machines à états sont définies pour tous les types de classes dans le diagramme de classes et le choix de la présence d une classe implique la présence de la machine à états correspondante. Flege Dans [30, 29], les deux stéréotypes <<Optional>> et <<HasVariability>> (présentés ci-dessus) sont utilisés aussi pour décrire la variabilité dans les machines à états. Ils peuvent être appliqués aux états et aux transitions dans les machines à états. Robak et al. Les auteurs de [99] montrent un diagramme d activité UML de la LdP. Le stéréotype <<variable>> est associé aux activités optionnelles. Discussions Peu de travaux se sont intéressés à la modélisation de la variabilité dans les diagrammes dynamiques d UML. Le peu existant est limite en terme de mécanismes et de puissance pour la spécification de la variabilité : Le seul mécanisme d optionnalité proposé dans KobrA, à travers le stéréotype <<variant>> appliqué dans les diagrammes de séquence seulement aux messages, est difficile à utiliser en pratique. En effet, si tous les messages d un même diagramme de séquence sont optionnels, l utilisateur sera obligé de les décrire tous avec le stéréotype <<variant>> ce qui compromet la lisibilité du diagramme de séquence. L approche adoptée par Gomaa [33], de ne pas introduire la variabilité directement dans les diagrammes de séquence mais seulement l introduire dans les cas d utilisation et ensuite la projeter sur les scénarios, restreint le rôle de ces derniers. En effet, cette solution ne considère que les scénarios qui décrivent les cas d utilisation. Cependant, les scénarios peuvent être utilisé indépendamment des cas d utilisation. Les propositions de Flege [30] et Robak et al. [99] restent très légères car elles ne proposent que de réutiliser les stéréotypes définis pour les diagrammes statiques dans les machines à états et dans les diagrammes d activités d UML. La modélisation de la variabilité dans les diagrammes dynamiques d UML est le coeur du travail présenté dans cette thèse. Nous proposons trois mécanismes pour spécifier la variabilité dans les diagrammes de séquence d UML. Au contraire des travaux précédents nous ne spécifions pas la variabilité dans les machines à états mais nous proposons une

46 2.3 État de l art sur la modélisation de LdP en UML approche permettant d obtenir automatiquement des machines à états pour chaque produit à partir des scénarios. Les trois mécanismes de variabilité sont décrits dans le chapitre 4 et la dérivation des machines à états dans le chapitre 7. 2.3.2 Gestion des contraintes La deuxième activité dans l ingénierie de LdP est la gestion des contraintes. Seulement deux travaux utilisant UML font référence aux contraintes de lignes de produits. Flege [30, 29] introduit le besoin d une évaluation de l architecture de ligne de produits pour détecter d éventuelles incohérences. Un exemple d incohérence présenté par l auteur est le cas où une classe non optionnelle dans un diagramme de classes hérite d une classe optionnelle dans le même modèle de ligne de produits. Il y a un risque de dériver un produit incohérent dans le cas ou la classe optionnelle est supprimée. Flege [29] propose un algorithme parcourant l architecture de ligne de produits pour détecter les éventuelles incohérences. Clauß Nous avons mentionné ci-dessus que Clauß [20] a proposé la représentation d un diagramme de caractéristiques FODA sous forme d un diagramme de classe UML étendu par un ensemble de stéréotypes. Pour la spécification des contraintes de dépendances de FODA, deux stéréotypes : <<requires>> et <<mutex>> ont été introduits pour spécifier respectivement les contraintes d exigence et d exclusion mutuelle. Discussions Là aussi peu de travaux utilisant UML, modélisent ou font référence aux contraintes de LdP. Dans le chapitre 5, nous proposons de modéliser les contraintes de LdP en utilisant OCL. Les contraintes de cohérence identifiées par Flege [29] sont proches de ce que nous applerons dans le chapitre 5 les contraintes génériques. 2.3.3 Le support de la dérivation des modèles de produits La dérivation de produit consiste principalement à résoudre la variabilité introduite dans les LdP pour produire les membres de la LdP. Comme nous l avons mentionné dans la section 1.5, la variabilité peut être résolue après que le produit soit délivré et installé dans son environnement d exécution à l aide des techniques des langages à objets telles que l héritage, la liaison dynamique, la surcharge et la délégation. Les mécanismes de variabilité proposés respectivement par SPLIT-Daisy [61] et VPM [113, 114] sont basés sur ces techniques et la résolution est reportée à l exécution. KobrA et Flege se sont intéressés à la dérivation avant de délivrer le produit. En d autres termes ils dérivent des modèles de produits à partir de ceux de la ligne de produits. Nous décrivons ces deux travaux :

UML pour la modélisation de Ligne de Produit 47 KobrA La spécification des modèles UML pour la LdP est réalisée dans l étape Framework Engineering de KobrA [8, 9]. La dérivation d un produit particulier de la LdP est réalisée dans l étape Application Enginering en se basant sur les choix des utilisateurs. La méthode KobrA introduit le modèle de décision comme un élément auxiliaire des modèles UML génériques de la LdP. Un modèle de décision est construit pour chaque modèle contenant la variabilité. La Figure 2.1 montre un exemple de modèle de décision KobrA associé au diagramme de classes. Il est décrit par une table dans laquelle chaque ligne correspond à une question concernant une variabilité particulière dans les modèle de la LdP. La colonne Effect décrit textuellement l action à réaliser pour obtenir le modèle d un produit. Des modèles de décision similaires peuvent être associés aussi aux diagrammes de séquence et aux machines à états contenant la variabilité. Tab. 2.1: Exemple d un modèle de décision de KobrA ID Question Resolution Effect 2 1 Is a customer allowed to overdraw his/her account up to a certain limit? Is it an international bank that handles different currencies? Yes No Yes No Remove stereotype <<variant>> of attribute Account limit. remove attribute Account limit. Remove stereotype <<variant>> of attribute Account limit Remove attribute Account limit. Flege Le modèle de décision de cette approche est spécifié par un ensemble de tagged values associés aux élément optionnels. La dérivation de l architecture d un produit particulier est décrite par un algorithme textuel qui exploite le modèle de décision et spécialise le modèle de LdP en fonction de modèle de décision. L algorithme est basé sur deux actions principales : laisser ou supprimer les éléments optionnels en fonction des décisions. Discussion Le support de la dérivation est une activité importante dans une approche supportant les LdP. Utilisant UML, le support de la dérivation est un critère important pour déterminer l utilité de l approche pour les utilisateurs. Les approches [61, 33, 99] qui ne modélisent que la variabilité dans les modèles UML sans un support pour dériver les produits, ont une utilité restreinte à but descriptif. La variabilité est décrite explicitement dans les modèles de LdP sans traitement opérationnel postérieur. Ces approches sont utiles seulement pour la documentation des architectures de lignes de produits à l aide des modèles UML. La thèse ici défendue est qu une approche de modélisation de LdP en UML doit aller au delà des buts descriptifs et doit proposer un support pour instantier la variabilité

48 2.3 État de l art sur la modélisation de LdP en UML introduite pour produire les modèles UML des produits membres de la LdP. Nous considérons par la suite la dérivation des modèles de produits et au contraire des approches de [9, 8, 29] qui restent informelles, nous formalisons cette dérivation comme des transformations de modèles UML. 2.3.4 Synthèse Dans cette section nous avons présenté un large état de l art autour de la modélisation de lignes de produits logiciels en UML. Plusieurs travaux se sont intéressés à la modélisation des lignes de produits en UML. La Table 2.2 présente un récapitulatif de ces travaux. Les travaux sont présentés selon les trois activités de l ingénierie des LdP. Nous remarquons que seulement quatre travaux modélisent explicitement la variabilité dans les diagrammes dynamiques d UML. Nous avons discuté ci-dessus les limites de ces travaux. Seul KobrA fait référence à la dérivation des diagrammes dynamiques. Cependant KobrA décrit informellement cette dérivation et ne propose pas une solution technique pour la réaliser. Une autre remarque de ce récapitulatif est que seulement deux travaux font référence aux contraintes sur les LdP. Cependant aucun parmi eux n utilise OCL pour spécifier les contraintes des LdP bien que OCL est un standard faisant partie d UML. Tab. 2.2: Table récapitulative des travaux existant autour de la manipulation des LdP avec UML Modélisation de la variabilité Gestion des contraintes Dérivation des produits Bertolino et al. Halmans et al. John et al. Maßen et al. Cas d util. Diag.Stat. Diag.Dyna. OCL Autres Diag.Stat. Diag.Dyna. X X X X Robak et al. X X Clauß X X Gomaa et al. X X X Flege X X X X KobrA X X X X SPLIT-Daisy X VPM X

UML pour la modélisation de Ligne de Produit 49 2.4 Une approche dirigée par les modèles Les contributions de cette thèse se situent autour des trois activités de l ingénierie de LdP : la modélisation de la variabilité dans les diagrammes d UML, la gestion de contraintes et le support de la dérivation de produits. Modélisation de la variabilité Nous proposons un ensemble d extensions sous forme d un profil UML pour la spécification de la variabilité dans les diagrammes UML. Au contraire des travaux existant où l aspect dynamique de la LdP est négligé, nous introduisons trois mécanismes pour la modélisation de la variabilité dans les diagrammes de séquence d UML. Notre proposition pour décrire la variabilité est présentée dans le chapitre 4. Gestion des contraintes Nous identifions deux types de contraintes de LdP et nous proposons de les spécifier en OCL. La spécification des contraintes de LdP est décrite dans le chapitre 5. Dérivation de produits Nous proposons deux approches basées sur la transformations de modèles UML pour la dérivation des modèle de produits. Nous dérivons les modèles statiques des produits ainsi que les modèles dynamiques. Ceci est décrit en détail dans les chapitres 6, et 7 respectivement.

Chapitre 3 Spécification de comportement dynamique des systèmes 3.1 Introduction L état de l art présenté dans le chapitre précédent à montré que les travaux existant autour de la manipulation des LdP en UML se sont intéressés en particulier à la modélisation de l aspect statique. Comme nous l avons mentionné, une justification probable à cette orientation est la forte influence des méthodes d analyse de domaine sur ces travaux. Cependant peu de travaux modélisent et spécifient l aspect comportemental des LdP. Partant de ces constats nous nous sommes intéressés à la modélisation de cet aspect dans les lignes de produits. L aspect comportemental est modélisé dans UML en deux vues : la vue inter-objets, qui décrit les interactions entre l ensemble des objets du système, et la vue intra-objet qui décrit le comportement interne de ces objets. Pour la modélisation de comportement inter-objets, UML utilise les scénarios (appelés les diagrammes de séquence) et adopte les machines à états pour la modélisation de comportement intra-objet. Les scénarios sont souvent utilisés pour décrire les cas d utilisation au moment de la spécification des exigences, donc ils sont spécifiés à la première étape du développement de système. Plus tard dans le processus de développement, le comportement détaillé du système est spécifié en modélisant des machines à états pour les classes du système. Certaines techniques et outils permettent de générer du code à partir de ces machines à états et de produire l implantation d un système [42]. Le but de ce chapitre est d introduire les deux vues inter-objets et intra-objet que nous allons utiliser pour la modélisation des comportements dans les LdP. Nous présentons les scénarios, les machines à états ainsi qu un état de l art autour des travaux sur la génération de machines à états à partir de scénarios. 51

52 3.2 Les scénarios : la vue inter-objets 3.2 Les scénarios : la vue inter-objets Les scénarios sont utilisés pour définir des exigences comportementales. Ils sont proches de la compréhension des utilisateurs et ils sont souvent utilisés pour raffiner les cas d utilisation et produire une vue abstraite du système. Plusieurs notations ont été proposées, parmi lesquelles les diagrammes de séquence d UML, les Message Sequence Chart (MSC) [51] et les Live Sequence Chart (LSC) [23]. Nous présentons seulement les diagrammes de séquence d UML ainsi que les MSC. Dans [70], on trouvera une présentation détaillé des différents langages et notations pour les scénarios. 3.2.1 Les diagrammes de séquence d UML1.x Depuis les premières versions d UML, les diagrammes de séquence ont été introduits comme un moyen pour décrire les interactions dans un système. La première génération des diagrammes de séquence d UML1.x est inspirée des OMSC (Object Message Sequence Chart) de Buschmann et al. [18] qui sont eux même dérivés, avec des modifications des MSC (Message Sequence Chart) [51]. Un diagramme de séquence (DS) d UML permet de décrire les interactions entre les objets du système selon un point de vue temporel. Il spécifie l ordre des envois et des réceptions de messages. La Figure 3.1 montre un exemple de diagramme de séquence et ses éléments de base. Les axes verticaux représentent les lignes de vie des objets participants dans le DS. Un objet dans un DS est soit une instance d une classe du système, soit une instance d un acteur. La notion d activation permet d indiquer la durée d une action et elle décrit le flot de contrôle sur la ligne de vie d un objet. Graphiquement, elle est décrite par un rectangle sur la ligne de vie de l objet. Les interactions entre les objets sont modélisées par des flèches horizontales appelées messages. Un message est défini par un objet émetteur et un autre récepteur. La création et la destruction des objets sont des cas particuliers de messages dans un DS (voir la Figure 3.1). La récursion est un message particulier pour lequel l objet récepteur est l objet émetteur sont identiques (voir la Figure 3.1). En plus de ces éléments de base, la spécification des diagrammes de séquence d UML1.x [93] fait référence à deux mécanismes décrivant le branchement et l itération de messages. La Figure 3.2 montre un exemple de branchement conditionnel dans un diagramme de séquence d UML1.x [93]. Le branchement est réalisé en associant des gardes (conditions) aux messages. Seul le message dont la garde est vérifiée est envoyé. Le branchement est en quelque sorte un moyen de décrire l alternative entre l envoi de deux ou plusieurs messages. Le standard UML1.x fait référence à la possibilité d ajouter des itérations dans un diagramme de séquence. Cependant il ne dit pas comment cette itération est possible [93]. La sémantique des diagrammes de séquence d UML1.x Les diagrammes de séquence d UML1.x sont définis dans la partie Collaboration

Spécification de comportement dynamique des systèmes 53 Fig. 3.1: Exemple d un diagramme de séquence d UML1.x et ses concepts Fig. 3.2: Le branchement conditionnel dans les diagrammes de séquence d UML1.x

54 3.2 Les scénarios : la vue inter-objets du méta-modèle d UML. La Figure 3.3 montre la partie du méta-modèle définissant les interactions dans UML1.5 [93]. Une interaction, spécifiée par un diagramme de séquence, regroupe un ensemble de Messages échangés entre un ensemble d instances de ClassifierRole. La sémantique d un diagramme de séquence peut être considérée comme une relation d ordre partiel entre ses messages [93]. Elle est définie par les deux associations activator et predecessor (voir la Figure 3.3). L association activator définit une relation de causalité entre un message entrant (qui joue le rôle d activator) et un ensemble de messages sortants sur une ligne de vie. Cependant l association predecessor décrit une relation d ordre entre les messages sortants sur une instance. Fig. 3.3: Une partie de méta-modèle des interactions dans UML1.5 Limites des diagrammes de séquence d UML1.x Comme nous l avons vu ci-dessus, la sémantique de la première génération des DS d UML1.x est définie par les deux relations predecessor et activator. La spécification UML1.5 définit les prédécesseurs d un message par (voir [93] pp 2-119) : "The set of Messages whose completion enables the execution of the current Message. All of them must be completed before execution begins." Dans le cas des messages asynchrones, la question posée est comment un émetteur d un message asynchrone sait-il que ce message est terminé pour passer au message suivant? [96] présente une étude critique des diagrammes de séquence d UML1.x dans un environnement asynchrone. De plus, les diagrammes de séquence d UML1.x sont pauvres en terme de mécanismes pour la description des interactions complexes. La sémantique des branchements conditionnels et de l itération est ambigüe. [32] note cette ambiguïté et propose d associer aux diagrammes de séquence des annotations textuelles

Spécification de comportement dynamique des systèmes 55 pour permettre la description explicite des alternatives et des itérations. On retrouve ces constats de manque d expressivité de la première génération des diagrammes de séquence dans le Request For Proposal (RFP) pour UML2.0 [89]. Nous lisons : «.. Experience has shown that to maintain a large set of sequence diagrams is difficult. The current sequence diagram notation offers little help to structure specifications using sequence diagrams nor does it provide an overview of how these sequence diagrams are related to each other. Issues encountered include, but are not limited to the following : Modelers cannot decompose the complex behavior in sequence diagrams. This may entail both a decomposition of the roles involved in an interaction as well as a decomposition of the sequence itself. Modelers cannot reference one sequence diagram from another. Modelers cannot combine sequence diagrams by means other than sequential composition (e.g., parallel, optional, repetition). Modelers have limited ability to define variability within a single sequence diagram..» La nouvelle génération, récemment adoptée, des diagrammes de séquence dans UML2.0 [94] a pris en compte ces manques et elle améliore fortement ceux proposés dans UML1.x. Le but de la prochaine section est de les présenter. 3.2.2 Les diagrammes de séquence d UML2.0 Le standard UML2.0 a apporté une refonte majeure aux diagrammes de séquence. Il est maintenant possible de décrire et spécifier les exigences sous forme d un ensemble de diagrammes de séquence de base et par la suite de les composer en utilisant des opérateurs pour obtenir des scénarios plus complexes. Aussi, les diagrammes de séquence dans UML2.0 sont maintenant considérés comme des collections partiellement ordonnées d événements (au lieu des collections ordonnées de messages dans UML1.x), ce qui introduit la concurrence et l asynchronisme et permet la définition de comportements plus complexes. 3.2.2.1 Les interactions Les diagrammes de séquence dans UML2.0 [94] sont définis dans la section Interaction de UML2.0 Superstructure. La Figure 3.4 résume cette section. La méta-classe Interaction spécifie une unité de comportement décrivant l échange d information entre un ensemble d objets dans un diagramme de séquence. La méta-classe Lifeline spécifie un objet dans une interaction. InteractionFragment est une partie d interaction. La composition entre une interaction et InteractionFragment spécifie qu une interaction peut englober un ensemble de sous-interactions. CombinedFragment définit une com-

56 3.2 Les scénarios : la vue inter-objets position d un ensemble de InteractionOperand en utilisant un opérateur d interaction (nous discutons plus en détail la composition des diagrammes de séquence ci-dessous). Chaque message est défini par deux événements : un événement spécifiant son émission et un autre spécifiant sa réception. L événement d émission d un message précède toujours l événement de sa réception. La méta-classe EventOccurrence définit les événements dans une interaction. Un événement se produit sur une ligne de vie particulière, les événements sur la même ligne de vie sont totalement ordonnées [94]. Fig. 3.4: Une partie du méta-modèle des diagrammes de séquence d UML2.0 Une nouvelle notation des diagrammes de séquence a été introduite dans UML2.0. Un diagramme de séquence d UML2.0 est maintenant décrit par un cadre rectangulaire libellé par le mot clé sd (pour Sequence Diagram) dans le coin gauche supérieur. La Figure 3.5 montre la notation d un diagramme de séquence simple dans UML2.0 Fig. 3.5: Exemple d un DS dans UML2.0 et ses concepts

Spécification de comportement dynamique des systèmes 57 3.2.2.2 Les mécanismes de composition Comme nous l avons mentionné ci-dessus, la grande nouveauté dans la nouvelle génération des diagrammes de séquence d UML2.0 est la possibilité de composer les diagrammes de séquence pour spécifier des comportements plus complexes. La composition des diagrammes de séquence d UML2.0 est introduite par le moyen de deux mécanismes de base : les références vers les DS et les opérateurs d interactions. Les références vers les DS UML2.0 introduit la notion d occurrence d interaction pour permettre à un diagramme de séquence de référencer un autre diagramme de séquence. Une occurrence d interaction (spécifiée par la méta-classe InteractionOccurrence dans Figure 3.4), est en quelque sorte un raccourci [94] vers une copie du contenu d une interaction. Le diagramme de séquence SD2 dans la Figure 3.6 référence le diagramme de séquence SD1. La référence vers un diagramme de séquence est décrite par un cadre rectangulaire libellé par le mot clé ref dans le coin gauche supérieur; le nom de DS référencé est spécifié au milieu du cadre. Fig. 3.6: Exemple des références vers les DS dans UML2.0 Les opérateurs d interaction Les DS d UML2.0 peuvent être composés en utilisant un ensemble d opérateurs appelés Opérateur d interaction. Les opérateurs de composition possibles dans UML2.0 sont définis dans le méta-modèle par l énumération InteractionOperator (voir Figure 3.4). Un opérateur d interaction est associé à une interaction combinée (CombinedFragment-voir Figure 3.4) et il compose un ensemble d opérandes d interaction (InteractionOperand - voir la Figure 3.4). Nous décrivons dans ce qui suit les opérateurs fondamentaux : La séquence (seq). L opérateur de séquence seq spécifie une séquence faible entre les comportements des opérandes [94]. La composition séquentielle faible

58 3.2 Les scénarios : la vue inter-objets signifie que les événements situés dans le premier DS sur une ligne de vie particulière doivent être exécutés avant les événements de deuxième DS situés sur la même ligne de vie [94]. Mais seq n impose pas de synchronisation entre des lignes de vie différentes. L alternative (alt). L opérateur alt définit un choix entre les comportements d un ensemble de DS. L itération (loop). L opérateur loop spécifie l itération de comportement d un DS. La séquence forte (strict). L opérateur strict spécifie une composition séquentielle forte. Au contraire de l opérateur seq, où l ordre est seulement imposé sur les événements sur la même ligne de vie, l opérateur strict spécifie que tous les événements (quelle que soit leur localisation) du premier DS doivent être exécutés avant les événements du deuxième DS. La composition parallèle (par). L opérateur par spécifie que les événements des opérandes peuvent être exécutés en parallèle, c.à.d. dans n importe quel ordre ou en concurrence. Option (opt). L opérateur opt spécifie un choix entre le comportement d un DS ou un comportement vide. Cet opérateur est équivalent à une alternative où le deuxième opérande est une interaction vide (sans événements). La composition des diagrammes de séquence d UML2.0 est décrite dans des diagrammes de séquence combinés. La Figure 3.7 montre un exemple de diagramme de séquence combiné qui référence et compose trois diagrammes de séquence : SD1, SD2 et SD3. Les opérateurs de composition dans les diagrammes de séquence combinés sont décrits par des cadres rectangulaires avec un coin gauche supérieur labellisé par l opérateur (seq, alt, loop..etc). Les opérandes pour les opérateurs de séquence, d alternative, et de parallélisme sont séparés par des lignes horizontales discontinues. La composition séquentielle peut être aussi implicitement donnée par l ordre relatif de référence aux diagrammes de séquence. Par exemple le DS CombinedSD dans la Figure 3.7, est équivalent à l expression : loop (SD1 seq (SD2 alt SD3)). UML2.0 propose aussi une autre notation pour la spécification de la composition des diagrammes de séquence dans ce qui est appelé les diagrammes de vues d ensemble d interactions (qui sont en quelque sorte des diagrammes d activités dont les activités sont des DS). La Figure 3.8 montre un exemple de diagramme de vues d ensemble d interactions ; il est équivalent à l expression : SD1 seq (SD2 alt SD3).

Spécification de comportement dynamique des systèmes 59 Fig. 3.7: Exemple d un diagramme de séquence combiné Fig. 3.8: Exemple d un diagramme de vue d ensemble d interaction dans UML2.0

60 3.2 Les scénarios : la vue inter-objets Nous revenons sur la formalisation des diagrammes de séquence d UML2.0 dans les chapitres 4 et 7. Nous définissons un diagramme de séquence de base en utilisant une relation d ordre partiel et la composition des DS est représentée algébriquement par ce que nous appelons par la suite des Expressions de Référence de Diagrammes de Séquence. 3.2.3 Message Sequence Charts La nouvelle génération des diagrammes de séquence d UML2.0 n a pas pris cette forme par hasard et il n est que le fruit d un rapprochement vers les Message Sequence Chart (MSC), le langage de scénarios standardisé par l ITU [51]. Comme nous l avons mentionné ci-dessus, un diagramme de séquence d UML2.0 est considéré maintenant comme une collection d événements partiellement ordonnée ce qui facilite la communication asynchrone qui caractérise les MSC. De plus, les mécanismes de composition introduit dans les DS d UML2.0 sont inspirés des MSC : les occurrences d interactions sont proches des MSC references [51], les interactions combinées sont proches des inlineexpressions des MSC et les diagrammes de vues d interaction sont proches des Hight Level Message Sequence Chart (HMSC). [44] présente une comparaison détaillée entre les deux standards qui prouve bien leur similarité. Nous présentons brièvement dans ce qui suit les MSC. Pour une présentation détaillée, le lecteur peut consulter [51]. basic Message Sequence Charts (bmsc) Les MSC définissent les basic MSC (bmsc) comme un moyen pour décrire le comportement simple d un ensemble d entités appelées instances qui communiquent de manière aysnchrone. La Figure 3.9 montre des exemples de bmsc. Fig. 3.9: Exemples de basic MSC Inline-expressions

Spécification de comportement dynamique des systèmes 61 Les MSC [51] introduisent les inlines-expressions pour permettre l introduction du choix, des itérations..etc dans un MSC. La représentation graphique des inlineexpression est proche des opérateurs d interactions d UML2.0 (un cadre dont le coin supérieur gauche porte le nom de l inline-expression). La norme Z.120 [51] introduit quatre inline-expressions : Alternative (alt). L inline-expression alt définit deux ou plusieurs parties d interaction possibles. Une seule partie est choisie. La Figure 3.10 montre un exemple de l inline-expression alt. Optionnel (opt). Les événements à l intérieur de l inline-exptression opt peuvent être exécutés ou non. Itération (loop). Les événements à l intérieur de l inline-expression loop sont itérés. Parallèle (par). Il spécifie que les événements dans les deux parties (ou plus) de l inline-expression par peuvent être exécutés en parallèle. Fig. 3.10: Exemple d une inline-expression High Level Message Sequence Charts (HMSC) Les HMSC [51] sont un autre mécanisme de composition dans les MSC. Un HMSC compose un ensemble de bmsc sous forme d un graphe. Il permet de décrire la composition séquentielle, l alternative, l itération et la composition parallèle des bmsc. La sémantique de l alternative, l itération et de la composition parallèle est équivalente à celle expliquée ci-dessus pour les inline-expressions. La composition séquentielle

62 3.3 Les machines à états : la vue intra-objet considérée dans les HMSC [51] est la composition séquentielle faible. La Figure 3.11 montre un exemple de HMSC qui référence et compose trois bmsc : connect, failed et succeed. En plus des noeuds de référence, un HMSC a un noeud de départ unique et peut avoir plusieurs noeud finaux. Fig. 3.11: Exemple d un HMSC La sémantique opérationnelle des MSC est définie à l aide d une algèbre de processus [98]. Une autre sémantique basée sur les structures d événements est proposée dans [48]. 3.3 Les machines à états : la vue intra-objet Les scénarios tels que les diagrammes de séquence d UML décrivent la coopération de plusieurs objets pour réaliser une fonctionalité. Cependant la spécification du comportement d un seul objet est le domaine des techniques de modélisation orientées états. Les machines à états et ses variantes comme les statecharts de David Harel [40] sont des exemples de ces techniques. Une machine à états d UML (une variante des statecharts de David Harel) est généralement associée à une classe particulière. Elle décrit le comportement complet de tous les objets instances de la classe. Le comportement d un objet est décrit par un ensemble d états et de transitions. La Figure 3.12 montre les concepts de base d une machine à état d UML. Les états décrivent certaines conditions sur l objet et les transitions indiquent les réactions possibles de l objet avec le respect des conditions de l état courant et les événements qui déclenchent ces réactions. Une transition est définie par : Un événement déclencheur de la transition. Une condition garde de la transition. Une action exécutée lorsque la transition est tirée.

Spécification de comportement dynamique des systèmes 63 Les machines à états d UML introduisent aussi quelques concepts des statecharts de David Harel tels que les états hiérarchiques (pour la spécification des états composites) et orthogonaux (pour la spécification des états évoluant en parallèle). Nous avons choisi de ne pas présenter ces concepts avancés car nous ne considérons dans le reste de ce document que les machines à états à plats, c.à.d. des machines à états sans hiérarchie et sans orthogonalité. Nous revenons sur la formalisation des machines à états dans le chapitre 7. Fig. 3.12: Exemple de machine à états 3.4 Des scénarios aux machines à états 3.4.1 Motivations Les scénarios sont un bon moyen pour spécifier les exigences comportementales du système en termes d interactions entre les objets du système. Ils sont proches de la compréhension humaine et ils ont eu une grande réussite dans le domaine des télécommunications à travers les Message Sequence Chart ainsi que dans le domaine de la Modélisation Orienté-Objet (MOO) à travers les diagrammes de séquence d UML. Les machines à états ont eu leur réussite surtout dans le domaine de conception rigoureuse des systèmes réactifs, en particulier pour la vérification de systèmes (model checking) et aussi pour la génération de squelettes d implantation [42]. Les scénarios et les machines à état décrivent tous les deux un aspect comportemental du système et, même s ils différent dans la vue qu ils donnent (les scénarios spécifient une vue inter-objets du système et les machines spécifient une vue intra-objet des objets du système), la relation entre les deux formalismes a attiré beaucoup d attention. Tout d abord dans le domaine des télécommunications et de l ingénierie des protocoles où plusieurs travaux se sont intéressés à la génération par exemple de spécifications SDL (Specification Description Language) à partir des MSC [5, 79]. Dans le domaine de la MOO, le lien entre les deux formalismes a été clairement établi dans la méthode OMT (Object Modeling Technique) avant même l apparition

64 3.4 Des scénarios aux machines à états d UML. Nous lisons dans [97] pp 174 : chaque scénario correspond à un chemin dans la machine à états. Nous trouvons aussi une description informelle d une une technique permettant de construire une machines à états d un objet à partir des scénarios [97]. Après l apparition d UML, plusieurs travaux (voir la section 3.4.2) ont proposé d automatiser la génération des machines à états à partir des scénarios. Ceci peut être expliqué par le fait qu il semble illusoire de définir le système en concevant «tous ses scénarios» d un coté et de l autre coté, modéliser directement le comportement du système par les machines à états n est pas un processus intuitif car la notion d état est souvent non naturelle dans les premières étapes de processus de développement. Dans la sections suivante nous présentons un état de l art sur les travaux existants autour de la synthèse des machines à états à partir des scénarios. 3.4.2 État de l art sur les travaux existant Nous présentons les travaux dans le contexte des diagrammes de séquence d UML et des MSC. On peut également citer un autre travail intéressant de Harel et al. [43] qui consiste à synthétiser des machines à états à partir des LCS. La synthèse à partir des diagrammes de séquence d UML1.x Comme nous avons vu dans la section 3.2.1, la première génération des diagrammes de séquence d UML1.x souffre du manque d expressivité, en particulier par l absence des mécanismes de composition pour gérer l existence de plusieurs scénarios. Les solutions proposées [64, 69, 78, 117] pour la synthèse des machines à états utilisent souvent des informations supplémentaires et des hypothèses adhoc pour la gestion de l existence de plusieurs scénarios. Whittle et al. [117] propose une approche pour la génération des machines à états à partir de plusieurs diagrammes de séquence. Les auteurs proposent d ajouter des pré et des post conditions, exprimés en OCL, aux messages définis dans les diagrammes de séquence. Cette information supplémentaire permet d identifier un ensemble de variables, d établir un vecteur d états, et de détecter des conflits dans la spécification avant le début de la synthèse. La synthèse commence à générer, par projection des messages sur la ligne de vie de l objet, une machine à états à partir de chaque scénario. Par la suite, les machines à états générées sont intégrées dans une seule machine à états résultat qui représente le comportement complet de l objet. Pour l intégration, les auteurs proposent une définition de la similarité entre deux états dans deux machines à états différentes : deux états sont similaires si leur vecteur d états est équivalent et s ils ont une seule transition d entrée avec le même label. La fusion des différentes machines à états génère un automate fini englobant toutes les états et les transitions de tous les machines à états. Entre les états similaires, des transitions non-déterministe de type ǫ sont ajoutées. Par la suite, les auteurs appliquent des algorithmes standards pour rendre

Spécification de comportement dynamique des systèmes 65 l automate résultat déterministe (éliminer les ǫ transition). Les auteurs proposent enfin deux techniques pour introduire la hiérarchie dans les machines à états : l une est basée sur le vecteur d état introduit et l autre sur le diagramme de classes. Koskimies et al. [69, 84] décrit une méthode pour la génération des machines à états à partir de plusieurs diagrammes de séquence. Ce travail est basé sur l application des idées de l algorithme de Biermann et Krishnawamy [15] qui synthétise un programme à partir des traces d exécution. Les auteurs font la correspondance entre les scénarios et les traces et entre les machines à états et les programmes. Les émissions de messages définissent des états dans les machines à états et les réceptions définissent des transitions. La principale hypothèse de cette approche est que les états sont identiques s ils sont liés aux mêmes envois de messages. Cette approche à été implantée dans l outil SCED [84]. Mäikinen et al. [78] propose une approche interactive, appelée MAS pour la génération des machines à états à plats. La principale caractéristique de cette approche est qu elle interagit avec l utilisateur pour accepter ou refuser le statechart généré. Kriss et al. Dans [64], un algorithme est proposé pour la génération de machines à états à partir de plusieurs scénarios exprimés sous forme de diagrammes de collaboration d UML1.x. Pour intégrer les machines à états, l algorithme demande à l utilisateur d ajouter des noms d états dans les machines à états générées. Deux états dans deux machines à états sont intégrés s ils ont le même nom. Tahir et al. [106] présente une approche utilisant les réseaux de Pétri pour la génération de machines à états à partir de plusieurs diagrammes de séquence. Là encore, le problème posé par les auteurs est la façon de gérer l existence de plusieurs scénarios. Ils proposent de générer à partir de chaque scénario un réseau de Pétri, ensuite ces réseaux de Petri sont intégrés dans un réseau composé. L hypothèse de la composition est que tous les diagrammes de séquence sont alternatifs. La synthèse à partir des MSC Certains travaux ont étudié la synthèse des machines à états à partir des scénarios spécifiés par des MSC/HMSC. Uchitel et al. [107, 103] propose de générer des LTS (Labbeled Transition Systems) à partir des MSC. L approche génère des spécifications FSP(Finite Sequential Process) [77] à partir des scénarios et ensuite l outil LSTA [76] est utilisé pour la génération des LTS. Les auteurs ont montré aussi que leur approche permet de supporter les deux travaux [117, 69].

66 3.5 Conclusion Krugger et al. [71], propose de générer des statecharts à partir d un ensemble de basic MSC. Les états des automates générés sont identifiés en utilisant la notion de condition des MSC [51]. La même condition dans plusieurs bmsc réfère le même état dans la machine à états. Les auteurs ne considèrent pas les HMSC. Leue et al. Une approche est proposée dans [72] pour synthétiser des ROOM charts à partir des HMSC. Les ROOM charts sont une forme de statecharts asynchrones. Helouet et al. [49] a étudié la synthèse d automates communicants à partir des HMSC. La communication entre automates est asynchrone avec des files d échange de messages entre chaque paire d automates. 3.4.3 Comparaison de comportement En liaison avec le problème de la synthèse, certains travaux se sont intéressés à comparer le comportement spécifié dans les scénarios et celui produit par les machines synthétisées. [28] à étudié l implantation des bmsc, il justifie que certains modèles de communication ne permettent pas l implantation même d un simple scénario. En plus de la synthèse, Helouet et al. [49] ont étudié aussi l égalité des comportements spécifiés par les HMSC et celui d automates communicants synthétisés. La conclusion de leur étude est que l égalité entre les deux langages n est possible que sur une classe restreinte des HMSC; cependant ils ont prouvé l inclusion des comportements des HMSC dans ceux des machines communicantes pour un modèle de communication simple. [72] impose des conditions sur les scénarios pour assurer une égalité entre les exigences et le comportement des machines synthétisées. [108] introduit la notion de scénarios impliqués (implied scenarios) pour détecter les scénarios qui apparaissent en plus dans les modèles synthétisés et ensuite augmenter les scénarios d entrée avec ces scénarios impliqués. Le processus s arrête si l ensemble de scénarios impliqués est vide. 3.5 Conclusion Dans ce chapitre nous avons présenté deux moyens principaux pour la spécification de comportements des systèmes : les scénarios et les machines à états. Nous avons présenté deux formalimes pour les scénarios : les diagrammes de séquence d UML et les MSC. Nous avons présenté plus en détail la nouvelle génération des diagrammes de séquence d UML2.0 car c est le formalisme que nous utilisons par la suite pour la spécification du comportement dans les lignes de produits. Nous avons présenté aussi les machines à états comme un moyen pour décrire la spécification du comportement complet d un objet. Enfin, nous avons discuté le problème de la synthèse des machines à états à partir des scénarios et nous avons présenté un état de l art autour des travaux existants.

Spécification de comportement dynamique des systèmes 67 Les diagrammes de séquence d UML2.0 améliorent la première génération et proposent des mécanismes de composition ce qui motive le besoin de revisiter le problème de la synthèse et de proposer une nouvelle approche. Nous proposons dans le chapitre 8 une approche pour la génération des machines à états à partir des diagrammes de séquence d UML2.0. Nous étendons cette approche pour supporter la variabilité dans les lignes de produits, aspect qui n est traité jusqu à présent dans aucun des travaux existant sur la synthèse.

Chapitre 4 La Modélisation de la Variabilité 4.1 Introduction Comme nous avons vu dans le chapitre 1, la modélisation de la variabilité est la première activité dans toute approche supportant les LdP. Dans une modélisation de type UML, l utilisation des mécanismes d extension semble la solution la plus appropriée. Ces mécanismes sont clairement établis comme partie du standard UML et ils sont supportés par la plupart des ateliers. Dans ce chapitre, nous utilisons les mécanismes d extension d UML pour la modélisation de la variabilité. Nous proposons de modéliser deux aspects dans les architectures de LdP en UML : L aspect statique Il est modélisé comme un diagramme de classes étendu par deux mécanismes de variabilité. L aspect dynamique Il est modélisé en utilisant les diagrammes de séquence étendus par trois mécanismes de variabilité. Au contraire des travaux [8, 29] qui modélisent l aspect dynamique des LdP, nous avons choisi d introduire la variabilité seulement dans les scénarios et non dans les machines à états. Ceci est justifié par le fait que les scénarios sont plus proches de la compréhension des utilisateurs (cf. section 3.2), donc l introduction de la variabilité dans les scénarios facilite sa communication aux utilisateurs dans les premières étapes du processus de développement (la communication de la variabilité est un critère important pour la réussite de toute approche de LdP [39]). Aussi, l expression de la variabilité au niveau des machines à états exige la manipulation par les utilisateurs des éléments de comportements de trop bas niveau (des transitions et des états). Utilisant les scénarios, les utilisateurs manipulent plutôt des fragments de comportements plus importants. Nous verrons néanmoins au chapitre 7 comment synthétiser des machines à états, à partir de nos scénarios. Dans ce chapitre nous présentons les extensions d UML2.0 que nous proposons pour la modélisation de la variabilité dans les diagrammes de classes ainsi celles proposées 69

70 4.2 La ligne de produit banque pour les diagrammes de séquence. Nous illustrons nos extensions par l exemple d une LdP du domaine bancaire. 4.2 La ligne de produit banque Nous allons utiliser un exemple illustratif de LdP de banque [8]. Il s agit d un ensemble de systèmes produisant les fonctionnalités standards dans le domaine bancaire. Les produits de cette famille sont destinés à plusieurs banques et chaque produit peut offrir les fonctionnalités suivantes : Création de comptes (F1) Les clients sont capables d ouvrir des comptes mais ils doivent le faire avec une somme minimale de départ. Un compte peut avoir un montant de découvert, et une devise pour sa gestion. Ces deux données sont spécifiées pendant la création du compte. Dépôt (F2) Les clients peuvent déposer de l argent sur leurs comptes en se présentant au guichet de la banque. Retrait (F3) Les clients peuvent retirer de l argent sur leurs comptes. Si le compte a un montant de découvert, le client peut retirer une somme jusqu à cette limite. Sinon, il ne peut pas retirer au delà du solde courant du compte. Gestion des devises (F4) Le système peut offrir une fonctionnalité pour la gestion des devises. Il s agit en particulier des services de conversion de ou à partir de l Euro vers les différents devises : dollar, livre,..etc. La variabilité dans cette ligne de produits concerne deux aspects : Le support ou non des découverts sur les comptes : certains produits ne permettent pas d ajouter des découverts sur les comptes des clients. Le support des fonctionnalités de gestion de devise : certains produits sont destinés à des banques qui ne gèrent que des comptes en Euro et ne supportent pas la gestion des devises. La fonctionnalité F4 est optionnelle pour les membres de cette LdP. La Table 4.1 montre quatre produits membres de la LdP banque. Le produit BS1 (Bank System 1) par exemple, supporte les découverts sur les comptes et il ne supporte pas la gestion des devises. Tab. 4.1: Les membres de la LdP banque Produit Le support des découverts La gestion des devises BS1 OUI NON BS2 NON NON BS3 NON OUI BS4 OUI OUI

La Modélisation de la Variabilité 71 4.3 Modélisation de l aspect statique des LdP Comme nous les avons présentés dans la section 2.2.3, les diagrammes de classes d UML sont utilisés pour décrire la structure statique d un système en terme de classes et leurs associations. Pour modéliser l aspect statique d une LdP, la variabilité doit être explicitement spécifiée et modélisée dans un diagramme de classes d une LdP. Dans la suite de cette section nous présentons deux mécanismes de variabilité dans les diagrammes de classes ainsi que leurs définitions en terme d extensions au méta-modèle d UML. 4.3.1 La variabilité Deux types de points de variation sont proposés et modélisés en utilisant les stéréotypes d UML : l optionnalité et la variation. L optionnalité L optionnalité dans les lignes de produits signifie que certaines propriétés sont optionnelles pour certains produits de la LdP, c.à.d. elles peuvent être supprimées dans ces produits. L optionnalité qu on considère dans les diagrammes de classes concerne les classes, les attributs, les opérations et les paquetages. Elle est introduite par le stéréotype <<optional>>. Nous ne modéliserons pas l optionnalité des associations UML, cependant une classe optionnelle signifie que toutes les associations auxquelles la classe participe sont optionnelles. Dans le cas où la classe optionnelle vient à être supprimée dans un modèle du produit, toutes ses associations seront également supprimées. L optionnalité d une classe signifie aussi que tous ses attributs et ses opérations sont optionnels. Dans le cas d un paquetage optionnel, l optionnalité s étend aux classes ainsi qu à tous les autres éléments qu il contient. La variation Nous avons présenté dans la section 2.2.3, l héritage dans UML à travers la notion de spécialisation et généralisation comme un mécanisme d abstraction. Il permet à une sous-classe d hériter des attributs et des opérations de sa super-classe. Ce mécanisme permet de gérer la variabilité (cf. section 1.5.3). L idée est de modéliser un point de variation par une super-classe abstraite et les classes variantes comme des sous-classes concrètes. Chaque classe variante définit l implantation de la super-classe. Cependant cette variabilité n est résolue qu au moment de l implantation et elle n est ni explicite ni visible au niveau du diagramme de classes. Pour permettre une spécification et une visibilité explicite de la variation dans un diagramme de classes UML, nous introduisons deux stéréotypes <<variation>> et <<variant>> associés respectivement aux classes abstraites et aux sous-classes concrètes. La Figure 4.1 montre un exemple de point de variation modélisé par une classe abstraire PV stéréotypée <<variation>> et deux classes variantes V1 et V2. Les classes variantes sont modélisées comme des sous-classes concrètes stéréotypées <<variant>>. Dans un modèle du produit particulier, une ou plusieurs classes variantes seront présentes. Notons qu une classe abstraite

72 4.3 Modélisation de l aspect statique des LdP stéréotypée <<variation>> peut avoir des sous-classes concrètes qui ne sont pas stéréotypées <<variant>> (voir par exemple la classe A dans la Figure 4.1). Ceci signifie que ces sous-classes sont communes à tous les produits, c.à.d. elles seront présentes dans tous les modèles de tous les produits. Fig. 4.1: Variation dans un diagramme de classes 4.3.2 Définition des extensions Les stéréotypes introduits ci-dessus pour la modélisation de la variabilité dans les diagrammes de classes sont définis comme des extensions sur la partie du méta-modèle d UML2.0 spécifiant les classes [94]. La Figure 4.2 montre les méta-classes de cette partie concernées par nos extensions. La méta-classe Class spécifie une classe UML; elle peut avoir un ensemble d attributs et un ensemble d opérations. Un attribut d une classe est spécifié par la méta-classe Property et une opération par la méta-classe Operation. Ces deux dernières méta-classes héritent de Feature. La méta-classe Pakage spécifie un paquetage UML; un paquetage peut contenir un ensemble de classes. La méta-classe Class hérite de Classifier. Fig. 4.2: Extrait du méta-modèle d UML des classes Comme l optionnalité peut concerner les paquetages, les classes, les attributs et les opérations, le stéréotype <<optional>> étend donc les méta-classes Classifier, Pa-

La Modélisation de la Variabilité 73 ckage, et Feature. Les deux stéréotypes <<variation>> et <<variant>> qui spécifient la variation dans un diagramme de classes étendent la méta-classe Classifier. Les contraintes OCL La sémantique des extensions introduites au méta-modèle UML peut être renforcée par un ensemble de contraintes exprimées en OCL. Pour les deux stéréotypes <<variation>> et <<variant>>, la contrainte suivante est ajoutée : Si une classe stéréotypée <<variant>> hérite de plusieurs classes stéréotypées <<variation>>(voir par exemple la Figure 4.3), cela posera un problème d ambiguïté à la dérivation de modèles de produits car la décision de la présence de la classe variante V dépend des deux points de variation VP1 et VP2. Cette contrainte est formalisé en OCL comme un invariant de la méta-classe Classifier comme suit : context Classifier inv : self.isstereotyped ( variant ) implies self.supertype select(isstereotyped( variation )) size()=1 isstereotyped(s : string) est une opération permettant de vérifier si un élément de modèle est stéréotypé s. Elle est formalisée en OCL comme suit : context Construct : :Class : :isstereotyped(s : string) :Boolean; isstereotyped = self.extensions-> exists(e E.ownedEnd.type.name =s) Fig. 4.3: Exemple d une variation où une classe variante est associée à deux points de variation

74 4.4 Modélisation de l aspect dynamique des LdP 4.3.3 Exemple La Figure 4.4 montre le diagramme de classes de la LdP banque modélisée avec les extensions introduites dans la section précédente. La classe Convertor offre deux méthodes permettant la gestion des devises (la conversion de et vers l Euro). Comme cette fonctionnalité est optionnelle pour les membres de la ligne de produit, la classe Convertor est stéréotypée <<optional>>. La classe abstraite Account est stéréotypée <<variation>> et ses deux sous-classes AccountWithLimit et AccountWithoutLimit sont des classes variantes (elles sont stéréotypées <<variant>>). Comme certains produits supportent seulement l Euro comme monnaie, l attribut currency dans la classe Account est optionnel. Fig. 4.4: Le diagramme de classes de la LdP banque 4.4 Modélisation de l aspect dynamique des LdP Nous utilisons la nouvelle version des diagrammes de séquence d UML2.0 étendue par trois mécanismes de variabilité pour la modélisation de l aspect dynamique des LdP. Pour la spécification des diagrammes de séquence des LdP, nous modélisons en premier lieu les interactions de base pour ensuite les composer par une interaction combinée. La variabilité y est alors introduite. Dans cette section nous présentons les trois mécanismes de variabilité, ensuite nous les définissons comme des extensions d UML et enfin nous illustrons ces mécanismes sur l exemple de la LdP banque. 4.4.1 La variabilité Nous introduisons trois types de variabilité dans les diagrammes de séquence : l optionnalité, la variation et la virtualité.

La Modélisation de la Variabilité 75 L optionnalité L optionnalité proposée pour les diagrammes de séquence comporte deux aspects : l optionnalité des objets participants dans le DS et l optionnalité du comportement lui même : Un objet optionnel dans un diagramme de séquence signifie que les messages envoyés ou reçus par cet objet sont optionnels pour les membres de la LdP, c.à.d. ils peuvent être supprimés dans certains produits. Pour spécifier l optionnalité des objets dans les DS, nous introduisons un nouveau stéréotype <<optionallifeline>> appliqué aux objets optionnels. Une interaction combinée peut référencer une interaction optionnelle. L optionnalité d une interaction signifie que son comportement est optionnel, c.à.d. tous les messages contenus dans cette interaction peuvent être supprimés dans certains produits. Pour la spécification de l optionnalité des interactions, nous introduisons le stéréotype <<optionalinteraction>> et un tagged value qui a comme nom optionalpart et comme type une chaîne de caractère (string). Le tagged value optionalpart spécifie le nom de l occurrence de l interaction optionnelle; il est introduit pour différencier les différentes occurrences de l interaction optionnelle. En effet, il se peut que cette dernière soit référencée plusieurs fois dans la même interaction combinée. La Figure 4.5 montre un exemple 1 d une interaction combinée référençant une interaction optionnelle. L exemple spécifie que le comportement défini par l interaction SD1 peut être supprimé dans l interaction combinée SD dans certains produits. SD1-occ1 est la valeur de tagged value optionalpart; il désigne le nom de l occurrence de l interaction optionnelle SD1. La variation Ce type de variabilité permet à la LdP de définir un ensemble de comportements variants parmi lesquels un produit particulier devra choisir une et une seule variante. Utilisant les DS d UML2.0, la variation du comportement est modélisée comme une interaction stéréotypée <<variation>> qui référence un ensemble de sous-interactions stéréotypées <<variant>>, qui à leur tour spécifient les comportements variants. Comme pour les interactions optionnelles, une interaction stéréotypée <<variation>> peut être référencée plusieurs fois dans une interaction combinée. Pour différencier les différentes occurrences, nous introduisons le tagged value variationpart qui indique le nom de l occurrence de l interaction variation. La Figure 4.6 montre un exemple d interaction modélisant la variation du comportement. 1 Nous suivons la notation des tagged values dans UML2.0. Un tagged value est présenté comme une note UML au lieu d une présentation entre accolades suivant le nom dans UML1.x. Notons aussi que le standard ne fait pas référence à la façon dont les stéréotypes sont associés aux interactions (les seuls exemple qu on trouve dans la spécification UML [86] concernent seulement la partie statique et au moment de rédiger ce document il n y a pas d outils qui supportent la nouvelle version des diagrammes de séquence d UML2.0). Nous avons choisi qu un stéréotype dans une interaction est spécifié juste audessus de son nom (voir par exemple la Figure 4.5).

76 4.4 Modélisation de l aspect dynamique des LdP Fig. 4.5: Exemple d une interaction combinée référençant une interaction optionnelle L interaction SD définit une variation du comportement appelée SD-occ1 avec deux interactions variantes : DS-v1, et DS-v2 (l ordre de référence des interactions variantes n est pas important). Notons que le mécanisme de variation est différent de l opérateur d interaction alt. Le mécanisme de variation propose un choix résolu lors de la dérivation de produits. Un produit dérivé ne contiendra donc qu une des possibilités de comportement. Cependant l opérateur alt définit un choix résolu après la dérivation de produit, c.à.d. à l exécution. Fig. 4.6: Exemple d une interaction variation

La Modélisation de la Variabilité 77 La virtualité La virtualité d une interaction signifie que son comportement peut être redéfini par une autre interaction de raffinement associée à un produit particulier. Ce type de variabilité est inspiré d une construction existante dans les MSC [51]. Le comportement de l interaction virtuelle sera remplacé pendant la dérivation de produit par le comportement de l interaction de raffinement associée au produit. La virtualité est introduite par le stéréotype <<virtual>> et le tagged value virtualpart indiquant l occurrence de l interaction virtuelle. La Figure 4.7 montre un exemple d une interaction SD qui référence une interaction virtuelle. Fig. 4.7: Exemple d une interaction combinée référençant une interaction virtuelle 4.4.2 Définition des extensions Nous définissons les stéréotypes et les tagged values introduits ci-dessus pour la modélisation de la variabilité dans les diagrammes de séquence comme des extensions à la partie du méta-modèle d UML2.0 qui concerne les DS (voir section 3.2.2.1 pour une présentation des principales méta-classes de cette partie). <<optionallifeline>> Comme nous avons vu dans la section 3.2.2.1, les objets participants dans un DS d UML2.0 sont spécifiés par la méta-classe Lifeline. Le stéréotype <<optionallifeline>>, qui spécifie l optionnalité des objets, étend cette méta-classe. <<optionalinteraction>> Nous définissons le stéréotype <<optionalinteraction>> comme une extension à la méta-classe InteractionFragment. Ceci pour permettre de définir l optionnalité non seulement d une interaction mais aussi de ses occurrences lorsque celle-ci sera référencé dans une interaction combinée. En effet, les deux méta-classes Interaction et InteractionOccurrence, qui spécifient respectivement les interactions et leur occurrences, héritent de la métaclasse InteractionFragment (voir la partie du méta-modèle d UML des DS dans la

78 4.4 Modélisation de l aspect dynamique des LdP Figure 3.4). Comme nous les avons présentés dans la section 2.2.4, les tagged values dans UML2.0 sont considérées comme des attributs des stéréotypes. Le tagged value optionalpart est défini comme un attribut du type string associé au stéréotype <<optionalinteraction>>. <<variation>> et <<variant>> La variation du comportement, telle qu elle a été présentée ci-dessus, est spécifiée comme une interaction référençant un ensemble de sous-interactions. Le stéréotype <<variation>> étend la méta-classe Interaction qui spécifie les interactions dans le méta-modèle d UML2.0. Cependant le stéréotype <<variant>> étend la méta-classe InteractionFragment. Le tagged value variationpart est défini comme un attribut du type string associé au stéréotype <<variation>>. <<virtual>> Ce stéréotype étend la méta-classe InteractionFragment. Le tagged value virtualpart est défini comme un attribut de type string associé au stéréotype <<virtual>>. Les contraintes OCL Deux contraintes, associées aux extensions introduites dans les diagrammes de séquence, sont identifiées et spécifiées en OCL : Une interaction stéréotypée <<variation>> doit au moins contenir deux sous-interactions stéréotypées <<variant>> context Interaction inv : self.isstereotyped ( variation ) implies self.fragment select(isstereotyped( variant )) size()>=2 Une InteractionFragment stéréotypée <<variant>> est contenue dans une et une seule interaction stéréotypée <<variation>>. context InteractionFragment inv : self.isstereotyped ( variant ) implies self.enclosinginteraction select( isstereotyped( variation )) size()=1 4.4.3 Exemple La Figure 4.8 montre les interactions de base de la LdP banque. Le DS Deposit par exemple spécifie l interaction de l acteur Clerk et les deux objets du système :

La Modélisation de la Variabilité 79 Bank et Account pour déposer de l argent sur un compte d un client. L interaction combinée BankPL de la Figure 4.9 montre comment les interactions de base de la Figure 4.8 sont composées. Elle spécifie qu il y a quatre principales alternatives dans les comportements qui correspondent aux quatre fonctionnalités présentées ci-dessus : (F1) Création des comptes (F2) Dépôts de l argent (F3) Retrait d argent (F4) Gestion des devises. L interaction combinée BankPL contient de la variabilité et illustre les deux types de variabilité : l optionnalité et la variation : Certains produits ne supportent pas les découverts sur les comptes. L occurrence de l interaction SetLimit, qui permet d ajouter le montant d un découvert pendant la création du compte, est définie avec le stéréotype <<optionalinteraction>> pour spécifier qu elle est optionnelle. Le tagged value optionalpart prend comme valeur la chaîne de caractère settinglimit (voir la Figure 4.9) L objet Converter est stéréotypé <<optionallifeline>> dans l interaction BankPL pour spécifier qu il est optionnel. La gestion de devise est une fonctionnalité optionnelle, donc les occurrences des interactions SetCurrency, ConvertToEuro et ConvertFromEuro sont définies comme optionnelles. Le tagged value optionalpart prend comme valeur respectivement settingcurrency, toeuro et fromeuro (voir la Figure 4.9) Il existe deux interactions variantes pour le retrait d argent à partir des comptes : retrait avec vérification du solde et du montant de découvert, et retrait avec seulement vérification du solde. L interaction Withdraw est stéréotypée <<variation>> et les deux occurrences des interactions WithdrawWithLimit et WithdrawWithoutLimit sont stéréotypées <<variant>>. Le tagged value variationpart prend comme valeur la chaîne withdrawaccount (voir la Figure 4.9) 4.5 Vers un profil UML pour les LdP UML introduit la notion du profil UML pour regrouper un ensemble de stéréotypes, de tagged values et de contraintes (cf. section 2.2.4). Dans la section précédente, nous avons proposé des mécanismes pour la spécification de la variabilité dans les diagrammes de classes et les diagrammes de séquence. Dans [122], nous avons défini ces extensions sous forme d un profil UML pour les LdP. La Figure 4.10 montre la structure de ce profil. Nous suivons la notation des profils dans UML2.0 (cf.section 2.2.4); une méta-classe est présentée comme une classe stéréotypée <<metaclasse>> et un stéréotype est présenté comme une classe stéréotypée <<stereotype>>. Les extensions pour l aspect statique

80 4.5 Vers un profil UML pour les LdP Fig. 4.8: Les interactions de base dans la LdP banque

La Modélisation de la Variabilité 81 Fig. 4.9: L interaction combinée de la LdP banque avec la variabilité

82 4.5 Vers un profil UML pour les LdP des LdP sont regroupées dans le paquetages StaticAspect et celles pour l aspect dynamique sont regroupées dans le paquetage DynamicAspect (voir la Figure 4.10). Notons que la structure de ce profil a évolué par rapport à la première version dans [122]. En effet, dans [122], nous avons défini le stéréotype <<optionalinteraction>> comme une extension de la méta-classe Interaction. Ceci est justifié par le fait que dans ce premier travail nous n avons considéré que l optionnalité dans les interactions sans références. Cependant pour permettre de définir l optionnalité non seulement pour une interaction mais aussi pour ses occurrences lorsque celle-ci sera référencée dans une interaction combinée, nous avons défini ici le stéréotype <<optionalinteraction>> comme une extension au méta-classe InteractionFragment. Le changement est le même pour le stéréotype <<variant>>. Fig. 4.10: Les extensions d UML pour la modélisation des LdP

La Modélisation de la Variabilité 83 4.6 Spécification algébrique des diagrammes de séquence des LdP Comme nous avons vu lors de la présentation de la nouvelle version des diagrammes de séquence d UML2.0, dans la première partie de ce document, la grande nouveauté dans les diagrammes de séquence d UML2.0 provient des mécanismes de composition. Ces mécanismes permettent de décrire les exigences comportementales comme un ensemble d interactions de base, et par la suite de les composer dans des interactions combinées pour spécifier des exigences plus complètes. Les opérateurs d interaction des DS d UML2.0 permettent de décrire algébriquement les interactions combinées. Nous avons choisi d utiliser une formalisation algébrique pour la spécification des diagrammes de séquence des LdP. Comme nous allons voir dans le chapitre 7, cette représentation algébrique permet de simplifier la formulation de la dérivation. Dans [45], Haugen et al. utilisent aussi une représentation algébrique des DS d UML2.0 et ils introduisent un nouveau opérateur xalt permettant de distinguer dans un choix entre les comportements obligatoires et potentiels. Un comportement potentiel représente une variante d un comportement obligatoire. Ce nouveau opérateur est proche de la construction variation que nous avons introduit ci-dessous. Le but de cette section est d introduire la formalisation algébrique que nous proposons et d introduire ce que nous appelons les expressions de référence. Nous étendons par la suite ces expressions pour supporter les trois mécanismes de variabilité introduits dans la section 4.4. 4.6.1 Expressions de Référence Une interaction combinée référence et compose un ensemble d interactions de base. La composition est basée sur les opérateurs d interaction (cf. section 3.2.2.2). Dans la suite de ce document nous ne considérons que les trois opérateurs fondamentaux à savoir seq, alt et loop respectivement pour spécifier la séquence faible, l alternative et l itération. Une interaction combinée sera spécifiée algébriquement par une RESD (Reference Expression for Sequence Diagram). Par la suite, nous utilisons une notation proche de EBNF (Extended Backus Normal Form) pour la définition des expressions de référence. Une expression de référence de diagrammes de séquence (RESD) est soit une référence vers un diagramme de séquence de base, une expression vide (E ) ou une composition d expressions en utilisant les trois opérateurs d interaction seq, alt et loop. E définit une interaction vide, c.à.d. sans échanges de messages. Définition 1 Une Reference Expression for Sequence Diagrams (notée RESD par la suite) est une expression de la forme : <RESD> : :=<PRIMARY> ("alt" <RESD> "seq" <RESD>)* <PRIMARY> : :=E <IDENTIFIER> "("<RESD>")"

84 4.6 Spécification algébrique des diagrammes de séquence des LdP "loop" "(" <RESD> ")" <IDENTIFIER> : := ([ 6,"a"-"z","A"-"Z"] ["0"-"9"])* Une interaction combinée peut être directement spécifiée par une expression de référence. La Table 4.2 montre les règles de représentation de base des DS combinés d UML2.0 en RESD. Tab. 4.2: Les règles de base pour la représentation des DS en RESD La notation des DS d UML2.0 Expressions de référence

La Modélisation de la Variabilité 85 4.6.2 Expressions de Référence des LdP Les RESD décrivent algébriquement les interactions combinées au moyen des opérateurs d interaction. Cependant ces expressions, telles quelles, ne spécifient pas la variabilité. La prochaine étape de notre spécification algébrique est d étendre les RESD afin de spécifier la variabilité. Nous introduisons trois constructions algébriques, une pour chaque type de variabilité. Ces constructions permettent de définir des expressions optionnelles, variations et virtuelles. Expressions optionnelles Une expression optionnelle est la spécification algébrique d une interaction optionnelle. Une expression optionnelle OpE est définie par un nom et une expression de référence. Définition 2 Une expression optionnelle (OpE) a la forme suivante : OpE : := "optional" <IDENTIFIER> "[" <RESD> "]" Une occurrence d interaction optionnelle (une interaction référencée et stéréotypée <<optionalinteraction>>) peut être décrite directement par une expression optionnelle. La valeur du tagged value optionalpart dans le diagramme spécifie le nom dans l expression. Par exemple, l interaction de la Figure 4.5 est spécifiée par l expression suivante : optional SD1-occ1 [ SD1 ] Expressions variations Une expression variation spécifie algébriquement une interaction variation. Elle est définie par un nom et deux ou plusieurs expressions de référence jouant le rôle des expression variantes. Définition 3 Une expression variation (VaE) est définie comme suit : VaE : := "variation" <IDENTIFIER> "[" <RESD> "," <RESD> ("," <RESD>)* "]" Une expression variation est obtenue à partir d une interaction stéréotypée <<variation>>. Le nom dans l expression est la valeur de tagged value variationpart. Les expressions variantes sont les expressions obtenues à partir des interactions variantes (c.à.d. les sous-interactions stéréotypées <<variant>>). Par exemple, l interaction de la Figure 4.6 est spécifiée par l expression suivante : variation SD-occ1 [ SD-v1, SD-v2 ]

86 4.6 Spécification algébrique des diagrammes de séquence des LdP Expressions virtuelles Une expression virtuelle est la spécification algébrique d une interaction virtuelle. Elle est définie par un nom et une expression de référence. Définition 4 Une expression virtuelle (ViE) est définie comme suit : ViE : := "virtual" <IDENTIFIER> "[" <RESD> "]" Une expression virtuelle est obtenue directement à partir d une interaction virtuelle, c.à.d. une interaction stéréotypée <<virtual>>. Le nom de la partie virtuelle dans l expression est la valeur du tagged value virtualpart. L interaction virtuelle dans la Figure 4.7 est spécifiée par l expression suivante : virtual SD3-occ1 [ SD3 ] Expressions de LdP Les constructions algébriques introduites ci-dessus permettent d étendre les RESD pour modéliser les comportement des LdP. Définition 5 Une Reference Expression for Sequence Diagrams of Product Lines (notée RESD-PL par la suite) est une expression de la forme : <RESD-PL> : :=<PRIMARY-PL> ("alt" <RESD-PL> "seq" <RESD-PL>)* <PRIMARY-PL> : :=E <IDENTIFIER> "("<RESD-PL>")" "loop" "(" <RESD-PL> ")" VaE OpE ViE 4.6.3 Exemple L interaction combinée BankPL de la Figure 4.9 référence quatre interactions optionnelles et une interaction variation. Elle est décrite algébriquement par l expression de référence suivante : E BPL = loop( Deposit alt (CreateAccount seq (CreateAccountOk seq (optional settinglimit [ SetLimit ] seq optional settingcurrency [SetCurrency ])) alt CreateAccountFailed) alt (variation withdrawaccount [ WithdrawWithLimit, WithdrawWithoutLimit ] seq ( WithdrawOk alt WithdrawFailed)) alt (optional fromeuro [ ConvertFromEuro ]) alt (optional toeuro [ ConvertToEuro ] ))

La Modélisation de la Variabilité 87 4.7 Conclusion Ce chapitre a proposé un ensemble de mécanismes pour la spécification de la variabilité dans les diagrammes de classes et les diagrammes de séquence d UML. Les extensions proposées pour les diagrammes de classes sont proches des travaux existants [19, 8, 34]. Cependant la contribution majeure se situe dans les mécanismes de variabilité proposés pour la modélisation de l aspect dynamique des LdP en utilisant les diagrammes de séquence, aspect peu étudié jusqu à présent (cf. section 2.3). Nous avons présenté aussi dans ce chapitre une formalisation algébrique des diagrammes de séquence d UML2.0 inspirée des MSC [51]; les extensions de variabilité sont définies par des constructions algébriques. Dans le reste de ce document nous considérons cette formalisation pour la manipulation de diagrammes de séquence des LdP. Comme nous allons voir dans le chapitre 7, cette spécification algébrique nous permet de définir une approche algébrique pour la dérivation de comportements de produits.

Chapitre 5 La Modélisation des Contraintes de LdP 5.1 Introduction Les architectures de ligne de produits sont définies par un ensemble de points de variation mais aussi par un ensemble de contraintes décrivant en particulier des règles de dépendance entre points de variation. C est par exemple le cas des chaînes de production de voitures où le choix d une option ou d une caractéristique peut exiger ou exclure le choix d autres options ou caractéristiques. La gestion des contraintes est une activité essentielle dans le contexte des LdP. FODA [62], la méthode de l ingénierie du domaine, propose deux règles de composition permettant de spécifier des dépendances de présence et d exclusion entre les caractéristiques du domaine. Comme nous avons vu dans l état de l art autour de la modélisation des LdP en UML (voir la section 2.3.2), peu de travaux font référence aux contraintes de LdP. Aucun travail n utilise OCL (Object Constraint Language) [112] pour la gestion des contraintes de LdP bien qu OCL soit un standard faisant partie intégrante d UML. Dans ce chapitre nous utilisons le langage OCL pour décrire et spécifier les contraintes sur les architectures de LdP modélisées en UML. En plus des contraintes de dépendances, nous identifions et spécifions les contraintes génériques comme des contraintes assurant la cohérence des modèles de produits dérivés. Les contraintes sur les LdP sont définies par des contraintes OCL au niveau méta-modèle. C est pour cette raison que nous faisons un bref rappel sur ce type de contraintes dans la section suivante. 5.2 Les contraintes OCL au niveau méta-modèle Comme nous l avons mentionné dans la section 2.2.2, le langage OCL a été créé spécialement pour répondre au besoin de formaliser des contraintes architecturales sur la structure des modèles UML. Il permet de définir des invariants sur les méta-classes 89

90 5.3 Les contraintes génériques des LdP du méta-modèle d UML. Les contraintes OCL au niveau méta-modèle sont exprimées au niveau méta-modèle (niveau M2; cf. section 2.2.1) et elles sont évaluées sur tous les modèles UML (niveau M1; cf. section 2.2.1). Un exemple de contraintes architecturales est la contrainte classique qui interdit l héritage cyclique (c.à.d. dans le diagramme de classes, le graphe d héritage ne peux présenter de cycles). Une telle contrainte est définie dans le méta-modèle d UML2.0 [94](pp 61) par un invariant à la méta-classe Classifier de la manière suivante : context Classifier inv : not self.allparents()->includes(self) La construction allparents() est une opération OCL additionnelle définie dans [94] permettant de récupérer tous les ascendants directs et indirects dans une relation d héritage d un Classifier. 5.3 Les contraintes génériques des LdP Les extensions que nous avons introduites dans le chapitre 4 pour les diagrammes statiques et dynamiques permettent de définir dans l architecture de LdP des éléments communs qui seront présents dans toutes les architectures des produits et certains éléments variables (optionnels ou variants) qui peuvent être supprimés. Définition 6 Un élément dans un modèle de LdP est dit variable s il est optionnel ou variant. Dans les autres cas, il est dit commun. La possibilité de définir des éléments variables n assure pas automatiquement la cohérence d un modèle de ligne de produits. Il existe des règles structurelles que toute ligne de produits doit respecter. Par exemple, un élément commun ne doit pas pouvoir utiliser d éléments variables (le risque étant de dériver un produit incomplet en supprimant les éléments variables). Nous proposons de spécifier les contraintes génériques comme des contraintes OCL au niveau méta-modèle. La même solution a été déjà utilisée dans [38] pour la définition des patrons de conception en UML. La Figure 5.1 montre que les contraintes génériques sont définies sur le méta-modèle d UML et qu elles sont évaluées sur tous les modèles des LdP. Dans ce qui suit nous présentons deux contraintes génériques applicables aux diagrammes de classes de LdP : la contrainte de dépendance et la contrainte d héritage respectivement liées à la notion de Dependency et de Generalization d UML. Nous présentons aussi leur formalisation en OCL. 5.3.1 La contrainte de dépendance Description

La Modélisation des Contraintes de LdP 91 Fig. 5.1: Les contraintes génériques dans les LdP Un élément commun ne doit pas être dépendant d un élément variable. La Figure 5.2 montre un exemple d une dépendance UML dans un modèle de LdP où le paquetage P1 utilise un paquetage optionnel P2 (la dépendance d UML est notée par une flèche stéréotypée et discontinue allant du client au fournisseur; le stéréotype permet de spécifier le type de dépendance, soit l usage dans cet exemple). Le paquetage P2 est variable, c.à.d. il peut être supprimé dans certains modèles de produits qui deviennent par conséquent incohérents dans la mesure où le paquetage P1, qui est commun, dépend de P2. La contrainte de dépendance permet d interdire telles situations d incohérence. Fig. 5.2: Exemple de dépendance d utilisation dans un modèle de LdP Formalisation en OCL Nous proposons de formaliser la contrainte de dépendance comme une contrainte OCL au niveau méta-modèle. La Figure 5.3 montre la partie du méta-modèle d UML liée aux dépendances [94]. La méta-classe Dependency spécifie une relation de dépendance entre un ensemble d éléments fournisseurs (suppliers) et un ensemble d élément clients. D après [94], une dépendance signifie que la sémantique des clients n est pas complète sans la présence des fournisseurs. La contrainte de dépendance est formalisée comme un invariant à la méta-classe Dependency. Elle assure que dans tous les modèles de LdP, on ne peut pas voir une dépendance dont des clients communs dépendent des fournisseurs variables. Sa formalisation en OCL est comme suit :

92 5.3 Les contraintes génériques des LdP context Dependency inv : self.supplier ->exists(s S.isStereotyped( optional ) or S.isStereotyped( variant )) implies self.client -> forall( C C.isStereotyped( optional ) or C.isStereotyped( variant )) Fig. 5.3: Les dépendances dans le méta-modèle d UML 5.3.2 La contrainte d héritage Description Lorsqu une classe commune hérite d une classe variable, il est probable que le modèle contient une incohérence. La Figure 5.4-a montre un exemple de telle situation, la suppression de la classe optionnelle B1 dans un modèle de produit engendre une incohérence car la classe A1 qui n est pas optionnelle dépend (par le lien de l héritage) de la classe optionnelle B1. Cependant dans certains cas particuliers, notamment lorsque le modèle de la ligne de produit contient de l héritage multiple (voir la Figure 5.4 - b), ce type de construction semble être cohérent car même avec la suppression de la classe C2 dans un produit, la classe A2 hérite toujours de B2. Il est cependant plus prudent de souligner les parties du modèle qui contiennent ce type d héritage, en définissant la contrainte d héritage. Formalisation en OCL La Figure 5.5 montre la partie du méta-modèle d UML qui spécifie l héritage. La méta-classe Generalization lie une sous-classe (définie par l association specific) et une super-classe (définie par l association general). La contrainte d héritage est

La Modélisation des Contraintes de LdP 93 Fig. 5.4: Exemples d héritages dans des diagrammes de classes de LdP formalisée comme un invariant à la méta-classe Generalization de la manière suivante : context Generalization inv : (self.general.isstereotyped( optional ) or self.general.isstereotyped( variant )) implies (self.specific.isstereotyped( optional ) or self.specific.isstereotyped( variant )) Fig. 5.5: La généralisation dans le méta-modèle d UML 5.4 Les contraintes spécifiques des LdP En plus des contraintes génériques valables pour toutes les LdP, un concepteur doit pouvoir exprimer des relations entre les éléments variables d un modèle d une LdP particulière. Ce type de contraintes est inspiré des règles de compositions de FODA [62]. Nous appelons les contraintes de dépendance entre les éléments variables d une LdP les contraintes spécifiques (spécifiques car elles sont spécifiques à une ligne de produit particulière). Tout produit dérivé doit satisfaire l ensemble des contraintes spécifiques définies par le concepteur. Nous proposons de formaliser les contraintes spécifiques comme des contraintes OCL au niveau méta-modèle; elles sont associées à une ligne de produit

94 5.4 Les contraintes spécifiques des LdP particulière et évaluées sur tous les modèles de produits dérivés à partir de la LdP (voir la Figure 5.6). Fig. 5.6: Les contraintes spécifiques dans les LdP Nous formalisons dans ce qui suit deux contraintes spécifiques permettant d exprimer des relations de dépendance de présence ou au contraire d exclusion mutuelle dans un diagramme de classes. 5.4.1 La contrainte de présence La contrainte de présence lie deux ou plusieurs éléments variables par une relation d implication. Elle permet d exiger la présence d un ou plusieurs éléments variables dans un produit dérivé lorsqu un ou plusieurs autres éléments variables s y trouvent. Nous proposons que les relations de dépendance de présence dans un diagramme de classes de LdP soient formalisées comme invariants de la méta-classe Model. Le choix de cette méta-classe est justifié par le fait que nous cherchons une méta-classe qui joue le rôle d un conteneur de tous les éléments d un modèle UML (compris un diagramme de classes). En effet, le méta-modèle UML définit la méta-classe Model comme un espace de nommage contenant un ensemble d éléments décrivant une abstraction du système en cours de modélisation [94]. La Figure 5.7 montre la place de la méta-classe Model dans le méta-modèle UML [94]. Un Model hérite de Namespace qui contient un ensemble de NamedElement. Tout élément dans un modèle UML (compris une classe) est un NamedElement (la méta-classe Class hérite de la méta-classe NamedElement). Pour illustrer la formalisation de contrainte de présence, nous considérons un diagramme de classes d une LdP avec deux classes optionnelles C1 et C2 tel que celui

La Modélisation des Contraintes de LdP 95 de la Figure 5.8. La contrainte de présence entre les deux classes C1 et C2 (dans le sens où la présence de la classe appelée C1 exige la présence de la classe appelée C2) est formalisée comme un invariant de la méta-classe Model de la manière suivante : context Model inv : self.presenceclass( C1 ) implies self.presenceclass( C2 ) presenceclass(c) est une opération OCL vérifiant la présence d une classe appelée C dans un Namespace. Elle est définie en OCL dans la manière suivante : context Namespace : :presenceclass(c : Class) : Boolean; presenceclass = self.ownedmember->exists(el : NamedElement (el.ocliskindof(class) and cl.name = C.name) or ( el.iskindof(namespace) and el.presenceclass(c))) Fig. 5.7: La méta-classe Model dans le méta-modèle d UML Fig. 5.8: Exemple d un diagramme de classes d une LdP

96 5.4 Les contraintes spécifiques des LdP La contrainte de présence, formalisée ci-dessus comme un invariant à la méta-classe Model, permet de vérifier que dans tous les diagrammes de classes des produits, obtenus par dérivation du diagramme de classes de la LdP, la présence de la classe C1 implique la présence de la classe C2. La Figure 5.9-a montre un exemple d un diagramme de produit dérivé à partir du diagramme de classe de la Figure 5.8. Ce modèle de produit est obtenu par la suppression de la classe C2 et le maintien de la classe C1 (les classes M1, M2, et M3 sont présentes aussi car elles sont communes à tous les produits). La Figure 5.9-b, montre les éléments du méta-modèle UML pour le diagramme de classes de la Figure 5.9-a. Il y a une instance de la méta-classe Model (spécifiant tout le modèle), deux instances de la méta-classe Package (spécifiant les deux paquetages P1 et P2), et quatre instances de la méta-classe Class (spécifiant les classes C1, M1, M2, M3). L instance de la méta-classe Model ne vérifie pas l invariant ajouté par la contrainte de présence ci-dessus, car la classe C1 est présente dans le modèle, mais pas C2. Fig. 5.9: Exemple d un diagramme de classes d un produit dérivé 5.4.2 La contrainte d exclusion mutuelle La contrainte d exclusion mutuelle spécifie un lien d exclusion mutuelle entre deux ou plusieurs éléments variables dans un modèle de la ligne de produit, c.à.d. ces éléments variables ne peuvent pas être présents simultanément dans le modèle d un produit dérivé. Dans un diagramme de classes de LdP, la contrainte d exclusion mutuelle spécifie que deux ou plusieurs classes variables ne peuvent pas être présentes dans le même diagramme de classes d un produit. Comme la contrainte de présence, nous ajoutons cette contrainte comme invariant de la méta-classe Model. Par exemple, dans le diagramme de classes de la LdP banque présenté dans la Figure 4.4, il existe une contrainte d exclusion mutuelle entre les deux classes AccountWithLimit et AccountWithoutLimit. Elle est spécifiée comme un invariant de la méta-classe Model de la manière suivante :

La Modélisation des Contraintes de LdP 97 context Model inv : (self.presenceclass( AccountWithLimit ) implies not self.presenceclass( AccountWithoutLimit )) and (self.presenceclass( AccountWithoutLimit ) implies not self.presenceclass( AccountWithLimit )) 5.5 Conclusion Dans ce chapitre nous avons identifié deux types de contraintes dans les LdP et nous avons vu qu elles peuvent être spécifiées comme des contraintes OCL au niveau métamodèle. Pour l illustration de ces contraintes, nous avons formalisé deux contraintes génériques pour la cohérence des modèles des LdP et deux contraintes spécifiques pour la spécification des relations de dépendances entre les points de variation. Nous verrons dans le chapitre suivant que les contraintes génériques et spécifiques des LdP sont respectivement considérées comme des pré et des post conditions pour la dérivation de modèles de produits. La vérification automatique des contraintes de LdP dans un atelier UML demande un interpréteur et un solveur de contraintes OCL au niveau méta-modèle (niveau M2). De nombreux interpréteurs de contraintes au niveau M1 ont déjà été proposés. Cependant peu d outils permettent la vérification des contraintes au niveau méta-modèle (niveau M2). Pour permettre de tester nos contraintes de LdP nous les avons traduites en utilisant le langage MTL. Le lecteur pourra trouver cette traduction dans l annexe A.

Deuxième partie Dérivation de produits 99

Chapitre 6 Dérivation de modèles statiques des produits 6.1 Introduction Dans la section 4.3, nous avons modélisé l aspect statique des LdP par des diagrammes de classes d UML. Nous avons proposé deux mécanismes pour modéliser la variabilité : l optionnalité et la variation. En plus de la modélisation de la variabilité, une autre activité importante dans toute approche supportant les LdP est la dérivation de produits qui consiste en particulier à résoudre la variabilité introduite dans le modèle de la LdP. La section 2.3.3 a montré que seulement deux travaux [9, 29] font référence à la dérivation de modèles de produits. Nous avons discuté ces deux travaux et nous avons vu que même s ils font référence à la dérivation des modèles de produit, ils ne formalisent pas cette dérivation et il ne proposent pas une solution pour sa mise en oeuvre (cf. section 2.3.3). Dans ce chapitre nous proposons une approche pour la dérivation de l aspect statique des LdP basée sur les transformations de modèles. Les modèles statiques des produits (des diagrammes de classes) sont dérivés par transformation à partir du modèle statique de la LdP. Pour faciliter la dérivation, nous étendons la méthode de Jézéquel [58, 59], proposée précédemment pour la réification des produits à la compilation, pour qu elle supporte la dérivation de modèles de produits. Nous illustrons cette dérivation sur la LdP Mercure et nous utilisons un langage de transformation de modèles, en l occurrence MTL [4], pour sa réalisation. 6.2 La LdP Mercure La LdP Mercure est une famille de serveurs SMDS (Switched Multi-Megabit Data Service) dont la conception et l implantation est décrite en détail dans [55, 56]. Un produit de cette LdP est un système permettant de délivrer et d échanger des mes- 101

102 6.2 La LdP Mercure sages entre un ensemble d interfaces réseaux connectées à un système distribué. La LdP Mercure doit prendre en compte les facteurs de variabilité suivants : Interfaces réseau : La LdP Mercure doit supporter une variété d interfaces réseau, par exemple : ATM, Ethernet, FDDI, ISDN,..etc. Chaque interface est gérée par un pilote du réseau (NetDriver). Processeurs : Mercure supporte une variété de processeurs. Chaque processeur (Engine) est spécialisé pour une fonctionnalité particulière, par exemple gestion des messages, gestion de la persistance..etc. Gestionnaire : Une variété de techniques doit être assurée pour la gestion du réseau; c est le rôle du gestionnaire (Manager). Interface graphique : Un nombre variable d interfaces graphiques d utilisateurs (GUI) sont supportées par les produits Mercure. Langage : La LdP Mercure supporte un nombre variable de langages d interfaces d utilisateurs (Language). La Figure 6.1 montre le diagramme de caractéristiques de la LdP Mercure (nous utilisons la notation FODA [62]; cf. section 1.4.1). Mercure est constitué de processeur (Engine), de pilote réseau (NetDriver), de gestionnaire (Manager), d interface graphique (GUI), et de langage (Language). Un produit Mercure peut supporter un ou plusieurs processeurs parmi Engine1, Engine2,..EngineN; nous utilisons les caractéristiques alternatives de FODA pour représenter cette variabilité. De la même manière nous définissons les caractéristiques NetDriver, Manager, GUI et Language. La LdP Mercure définit une contrainte de dépendance. En effet, le pilote réseau NetDriver1 exige la présence du processeur Engine1. Comme nous l avons mentionné dans la section 1.6, FODA permet de décrire des règles de composition pour spécifier des relations de dépendance entre les caractéristiques. Une règle de présence est ajoutée au diagramme de caractéristiques de la LdP Mercure pour spécifier une dépendance de présence entre NetDriver1 et Engine1 (voir la Figure 6.1). La combinaison des cinq facteurs de variabilité engendre un nombre important de produits Mercure. Cependant pour simplifier l illustration, nous ne considérons dans la suite que trois produits : FullMercure, CustomMercure, et MiniMercure : FullMercure C est la version complète. Ce produit supporte tous les pilotes réseau; tous les processeurs ; tous les gestionnaires ; toutes les interfaces graphiques ; tous les langages. CustomMercure C est une version restreinte qui supporte seulement un processeur : Engine1; deux pilotes réseau : NetDriver1 et NetDriver2; un seul gestionnaire : Manager1; deux interfaces graphiques : (GUI1 et GUI2); deux langages : Language1

Dérivation de modèles statiques des produits 103 Mercure Engine Manager Language Engine 1 Engine N Manager 1 Manager N Language 1 Language 1 Net Driver GUI NetDriver 1 NetDriver N GUI 1 GUI N Composition rules NetDriver1 requires Engine1 Fig. 6.1: Le diagramme de caractéristiques de la LdP FODA et Language2. MiniMercure C est une version minimale qui supporte seulement un processeur Engine1; un pilote réseau : NetDriver1; un gestionnaire : Manager1; deux interfaces graphiques : GUI1, GUI2; un seul langage : Language1. Modélisation en UML Nous modélisons l aspect statique de la LdP Mercure en utilisant les diagrammes de classes d UML. Pour l introduction de la variabilité, nous utilisons le mécanisme variation présenté dans la section 4.3. Nous définissons une classe abstraite stéréotypée <<variation>> appelée Engine et un ensemble de sous-classes concrètes stéréotypées <<variant>> : Engine1, Engine2..EngineN. De la même manière, nous modélisons les autres points de variation : NetDriver, Manager, GUI et Language. La Figure 6.2 montre le diagramme de classes de la LdP Mercure (nous ne montrons que les classes sans attributs ni méthodes). Il spécifie que le système Mercure est une instance de la classe Mercure qui est composé par une classe Engine (qui encapsule le travail du processeur), une collection de NetDriver, une collection de Manager, et les GUI (qui encapsulent les interfaces graphiques des utilisateurs). Une GUI elle même a une collection de langages supportés. La contrainte de présence FODA entre les deux caractéristiques NetDriver1 et Engine1 est modélisée dans le diagramme de classes UML en OCL comme une contrainte de présence (cf. section 5.4) entre les classes NetDriver1 et Engine1. Elle

104 6.2 La LdP Mercure est ajoutée comme un invariant de la méta-classe Model : context Model inv : self.presenceclass( NetDriver1 ) implies self.presenceclass( Engine1 ) Notons que le diagramme de classes de la LdP Mercure dans la Figure 6.2 vérifie bien les deux contraintes génériques de LdP (cf. section 5.3) : la contrainte de dépendance et d héritage. En effet, il n y a pas dans ce modèle un élément commun qui dépend ou qui hérite d autres éléments variables. <<variant>> Engine 1 Mercure 1 1 1 1 <<variation>> Engine 1... <<variant>> Engine N 1 1..* watch * <<variation>> NetDriver 1..* 1 <<variant>> NetDriver 1... <<variant>> NetDriver N Buffers 1..* Message 1..* Observe 1..* <<variation>> Manager <<variant>> Manager 1... 1..* <<variant>> Manager N 1 Use 1..* <<variation>> GUI <<variant>> GUI 1... 1 <<variant>> GUI N Available 1..* Use 1 <<variation>> Language <<variant>> Language 1... <<variant>> Language N Fig. 6.2: Le diagramme de classes UML de la LdP Mercure

Dérivation de modèles statiques des produits 105 6.3 Dérivation de produits Une fois que la LdP est modélisée, la question est comment dériver les produits membres de la LdP? Pour l exemple de la LdP Mercure, comment générer les trois produits FullMercure, CustomMercure, et MiniMercure? Jézéquel [58, 59] a proposé une méthode originale pour dériver les produits de la LdP Mercure. Elle est basée sur l utilisation d un patron de conception de création appelé Fabrique Abstraite (Abstract Factory) [31]. Ce patron permet de définir une interface pour la création d une famille d objets liés. La Figure 6.3 illustre sa structure générale [31] : une fabrique abstraite (AbstractFactiry) est définie comme une classe abstraite avec un ensemble de méthodes de création d objets appelées méthodes fabriques (Method Factory) (par exemple la méthode CreateProductA() dans la Figure 6.3). Les fabriques concrètes (Concrete Factory) sont des classes concrètes de la fabrique abstraite et elles définissent l implantation des méthodes fabriques. AbstractFactory CreateProductA() CreateProductB() 1 has Client AbstractProductA * ConcreteFactory1 ConcreteFactory2 CreateProductA() CreateProductB() CreateProductA() CreateProductB() ProductA2 ProductA1 AbstractProductB * ProductB2 ProductB1 Fig. 6.3: La structure du patron de conception Fabrique Abstraite La méthode proposée par Jézéquel [58, 59] consiste à utiliser la fabrique abstraite comme une interface pour la création des objets dans chaque produit Mercure. Ceci est illustré dans la Figure 6.4 [58, 59]. La classe Mercure_Factory est la fabrique abstraite; elle définit cinq méthodes fabriques, une pour chaque point de variation : new_gui(),new_engine(), new_netdriver(), new_manager(), et

106 6.3 Dérivation de produits new_language(). Chaque méthode fabrique a pour type de retour la classe abstraite associée. Par exemple le type de retour de la fabrique new_gui() est GUI. Les fabriques concrètes : FullMercure, CustomMercure et MiniMercure sont des sous-classes de la fabrique abstraite, chaque fabrique concrète est associée à un produit Mercure. Basée sur les mécanismes des langages orientés objets en particulier la liaison dynamique, Jézéquel [58, 59] a montré que sa méthode assure des performances intéressantes au processus de dérivation de produits à la compilation Cependant cette dérivation est postérieure à la délivrance de produits, c.à.d. elle est réalisée après que le produit soit délivré et installé dans son environnement d exécution. Comme indiqué dans la section 1.5, la dérivation postérieure est liée à la nature de certains types de variabilité logicielle. Nous avons également mentionné, que nous nous intéressons dans ce document à la dérivation des modèles de produits qui permet de résoudre la variabilité avant la délivrance des produits. Dans la section suivante, nous proposons d étendre légèrement l utilisation de la fabrique abstraite dans la méthode de Jézéquel [58, 59] pour permettre une dérivation des modèles des produits. Mercure_Factory new_gui() new_language() new_network_manager() new_netdriver() new_engine() 1 1 Mercure FullMercure CustomMercure MiniMercure Fig. 6.4: La fabrique abstraite dans la LdP Mercure 6.3.1 De modèle de LdP aux modèles de Produits L approche que nous adoptons pour la dérivation de produits est basée sur les transformation de modèles UML (cf. section 2.2.5). Nous formalisons la dérivation comme

Dérivation de modèles statiques des produits 107 une transformation de modèle dans laquelle le modèle source est un modèle de LdP (un diagramme de classes ici) et le modèle cible est un modèle de produit (un diagramme de classes aussi). Nous utilisons un langage de transformation de modèles, en l occurrence MTL (Model Transformation Language) [4], pour réaliser cette transformation. L extension que nous proposons à l approche de Jézéquel [58] pour permettre la dérivation de modèles de produits concerne l utilisation de la fabrique abstraite. La Figure 6.5 montre la nouvelle structure de la fabrique abstraite pour la LdP Mercure. Nous proposons d utiliser les stéréotypes d UML pour restreindre le type de retour des méthodes fabriques dans les fabriques concrètes. Ceci permet d expliciter les choix des classes variantes dans chaque produit. Par exemple, le produit CustomMercure contient seulement GUI1 et GUI2. Nous ajoutons donc à la méthode fabrique new_gui() deux stéréotypes : <<GUI1>> et <<GUI2>>(voir la Figure 6.5). Pour un produit qui supporte toutes les classes variantes d un point de variation, la méthode fabrique de sa fabrique concrète ne sera pas stéréotypée (voir par exemple la fabrique concrète associé au produit FullMercure dans la Figure 6.5). Mercure_Factory +new_gui():gui +new_language():language +new_network_manager():manager +new_netdriver():netdriver +new_engine():engine FullMercure +new_gui():gui +new_language():language +new_network_manager():manager +new_netdriver():netdriver +new_engine():engine MiniMercure +<<GUI1>>new_gui():GUI +<<Language1>>new_language():Language +<<Manager1>>new_network_manager(): [] Manager +<<NetDriver1>>new_netdriver():NetDriver +<<Engine1>>new_engine():Engine CustomMercure +<<GUI1>><<GUI2>>new_gui():GUI +<<Language1>><<Language2>>new_language():Language +<<Mnager1>>new_network_manager():Manager +<<NetDriver1>><<NetDriver2>>new_netdriver():NetDriver +<<Engine1>>new_engine():Engine Fig. 6.5: La fabrique abstraite étendue avec des stéréotypes pour la LdP Mercure

108 6.3 Dérivation de produits 6.3.2 Dérivation La dérivation est formalisée comme une transformation de modèles qui prend comme entrée le modèle de la LdP et une fabrique concrète qui correspond au produit dont on veut dériver le modèle. La transformation fournit en sortie le modèle correspondant au produit. La dérivation est définie dans l algorithme ci-dessous qui comporte trois étapes : Sélection des classes variantes, Spécialisation du modèle, et une étape d optimisation. Notons que la dérivation initialise le modèle de produit par le modèle de la LdP, ensuite des transformations sont appliquées sur ce modèle jusqu à l obtention du modèle de produit final. 1. Sélection des classes variantes : La première étape consiste à sélectionner les classes variantes qui devront être incluses dans le modèle du produit en se basant sur les stéréotypes introduits dans la fabrique concrète. En effet, les stéréotypes permettent d identifier les éléments au niveau méta-modèle et par conséquent de les manipuler par une transformation de modèles. Pour chaque méthode «fabrique», nous récupérons ses stéréotypes. Ces stéréotypes spécifient les noms des classes variantes sélectionnées. Pour l exemple du produit CustomMercure qui correspond à la fabrique concrète CustomMercure dans la Figure 6.5, les classes sélectionnées à la fin de cette étapes sont GUI1, GUI2, Language1, Language2, NetDriver1 et Engine1. 2. Spécialisation du modèle : Dans cette étape toutes les classes variantes qui n ont pas été sélectionnées dans la première étape sont supprimées du modèle. 3. Optimisation du modèle : Dans cette étape, les fabriques qui ne sont pas utilisés sont supprimés du modèle. Cette étape comporte aussi une tâche d optimisation de l héritage. En effet, si pour une classe abstraite seulement une et une seule classe variante est sélectionnée, l optimisation de l héritage consiste à remplacer la classe abstraite par la classe variante sélectionnée. Par exemple, le produit CustomMercure supporte seulement Manager1, l optimisation de l héritage consiste à remplacer la classe abstraite Manager par Manager1 (voir la Figure 6.6). Toutes les références vers Mananger dans le modèle sont remplacées par des références vers Manager1. L intérêt de cette étape d optimisation, est de permettre de résoudre la liaison dynamique dès cette phase de dérivation, et donc d obtenir un système plus compact et plus efficace [58]

Dérivation de modèles statiques des produits 109 algorithm : DeriveP roductm odels() Input : PL_model : Model aconcretefactory : Class Output : Product_model : Model étape 1 : La sélection des classes variantes selectedvariantslist := ; for chaque méthode fabrique new_pv dans aconcretefactory do definedvariantslist := new_pv.getallstereotypesnames() if definiedvariantslist = then abstractclass := new_pv.getreturntype() subclassesnames :=abstractclass.getallsubclassesnames() selectedvariantslist.add(allsubclassesnames); else selectedvariantslist.add(definedvariantslist); end if end for étape 2 : Spécialisation du modèle for chaque classe variante C in PL_model do if (C.getName()/ selectedvariantslist) and C.getAllSubClasses()/ selectedvariantslist) then supprimer la classe C du PL_model; end if end for étape3 : Optimisation du modèle supprimer toutes les classes concrètes qui ne sont pas utilisées ; optimiser l héritage; Product_model := PL_model; return Product_model; 6.3.3 Implantation en MTL Pour l implantation de la dérivation, nous avons utilisé un langage de transformation de modèles MTL(Model Transformation Language) développé au sein de l équipe Triskell (cf. section 2.2.5) à l IRISA. Nous décrivons brièvement l implantation en MTL de la première étape de l algorithme de dérivation, c.à.d. la sélection des variantes. Le code de toute la transformation est présenté dans l annexe B de ce document. Une bibliothèque MTL appelée PLDerivation est définie pour contenir la transformation de la dérivation. La transformation principale est définie dans la procédure derivepl() ci-dessous qui prend comme paramètre la fabrique concrète correspondante

110 6.3 Dérivation de produits au produit dont on veut dériver son modèle. L initialisation de la transformation en MTL est définie de la manière suivante : library PLDerivation; model source_model : RepositoryModel; derivepl(concretefactory : source_model : :Core : :Class) { //local variable selectedvariants : Standard : :Set; definedvariants : Standard : :Set; feature : source_model : :Core : :Feature; operation : source_model : :Core : :Operation; operationiterator : Standard : :Iterator; subclassesnames : Standard : :Set; stereotypesnames : Standard : :Set; classesiterator : Standard : :Iterator;... Le code MTL ci-dessous de la procédure derivepl() implante l étape de sélection des classes variantes. La procédure crée une variable operationiterator (ligne 2) pour parcourir toutes les opérations de la fabrique concrète. Pour chaque opération, nous construisons les deux ensembles subclassesnames et stereotypesnames : L ensemble subclassesnames contient les noms de toutes les classes variantes associées à l opération courante. Les lignes 9 et 10 montrent comment cet ensemble est obtenu. Il s agit de collecter les noms de toutes les sous-classes de la classe représentant le type de retour de l opération courante. getreturntype(), allsubclasses() et collectmodelelementsnames() sont des méthodes auxiliaires dont le code MTL est détaillé dans l annexe B. getreturntype() permet de récupérer le type de retour d une opération dans une classe UML. allsubclasses() prend comme paramètre une classe et permet de récupérer ses sous-classes. collectmodelelementsnames() collecte les noms d éléments du modèle contenus dans un ensemble (cf. section 2.2.5). L ensemble stereotypesnames contient les noms des stéréotypes associés à l opération courante (voir lignes 11 et 12). L ensemble definedvariants est l intersection des ensembles subclassesnames et stereotypesnames (voir la ligne 13). Les noms des classes sélectionnées à la fin de cette étape sont contenus dans l ensemble selectedvariants. Notons que si la liste

Dérivation de modèles statiques des produits 111 definedvariants est vide, nous ajoutons aux classes sélectionnées l ensemble contenant toutes les classes variantes (lignes 14 et 15). Sinon, nous ajoutons le contenu de l ensemble definedvariants à l ensemble des classes sélectionnées (voir ligne 16). //...suite de derivepl() { // Step 1 : Variant selection (1) selectedvariants := newset(); (2) operationiterator := concretefactory.feature.getnewiterator(); (3) operationiterator.start(); (4) while operationiterator.ison() { (5) feature := operationiterator.item().oclastype( (6)!source_model : :Core : :Feature!); (7) if feature.ocliskindof(!source_model : :Core : :Operation!). and(feature.name.substring(1, 4).[=]( new_ )) { (8) operation := feature.oclastype(!source_model : : Core : :Operation!); //finding all subtypes names of the return type (9) subclassesnames := collectmodelelementsnames( (10) allsubclasses(getreturntype(operation))); //finding all stereotypes names (11) stereotypesnames := collectmodelelementsnames( (12) operation.stereotype.oclastype(!standard : :Set!)); //retreiving variants to be selected (13) definedvariants := subclassesnames.intersection(stereotypesnames); //adding this result to the to-keep variant list (14) if definedvariants.isempty() { //no variant retreived means all variants are selected (15) selectedvariants := selectedvariants.union(subclassesnames); }else { (16) selectedvariants := selectedvariants.union(definedvariants); } } (17) operationiterator.next(); } }...

112 6.3 Dérivation de produits Comme nous l avons mentionné dans la section 2.2.5, MTL permet de parcourir un modèle mais aussi de le modifier par la suppression ou l ajout de nouveaux éléments. MTL fournit la primitive delete() permettant de supprimer un élément dans un modèle. La deuxième étape dans l algorithme de dérivation consiste à parcourir de nouveau le modèle et le spécialiser en supprimant les classes variantes qui ne sont pas sélectionnées. Nous avons choisi de ne pas présenter ici le code de cette étape ni de l étape d optimisation. Cependant le lecteur trouvera tout le détail dans l annexe B. Nous avons appliqué la dérivation aux trois produits de la LdP Mercure : FullMercure, CustomMercure, et MiniMercure. La Figure 6.6 montre le modèle de produit CustomeMercure obtenu automatiquement par la dérivation du modèle de la LdP Mercure de la Figure 6.2. Fig. 6.6: Le modèle obtenu pour le produit CustomMercure

Dérivation de modèles statiques des produits 113 6.4 Prise en compte des contraintes dans la dérivation Nous avons identifié dans le chapitre 5, deux types de contraintes associées aux LdP : les contraintes génériques et les contraintes spécifiques : Les contraintes génériques sont des contraintes de cohérence et doivent être vérifiées sur tous les modèles de la LdP. La dérivation des produits ne peut pas être appliquée si le modèle de la LdP ne vérifie pas les contraintes génériques. Ces contraintes peuvent être donc vues comme des pré-conditions au processus de transformation dérivation. Les contraintes spécifiques spécifient des dépendances entre les points de variation. Elles doivent être vérifiées sur les modèles de produits obtenus après que le processus de dérivation soit terminé. Elles représentent donc des post-conditions à la dérivation. Par exemple, le modèle du produit CustomMercure dans la Figure 6.6 satisfait la contrainte de présence définie ci-dessus car il comporte les classe NetDriver1 et Engine1. Comme mentionné dans la section 5.5, nous avons traduit les contraintes génériques et spécifiques des LdP en MTL (voir annexe A). Ceci nous a permis de vérifier les contraintes génériques sur le diagramme de classes de la LdP Mercure avant d effectuer la dérivation. Par la suite les contraintes spécifiques sont vérifiées sur les trois modèles de produits obtenus. 6.5 Conclusion Dans ce chapitre nous avons présenté une approche permettant de dériver les modèles statiques de produits à partir d un modèle de la LdP. Nous avons légèrement étendu une méthode, basée sur l utilisation d un patron de conception précédemment proposée pour la dérivation à la compilation, pour permettre une dérivation pendant la conception. Nous avons formalisé la dérivation comme une transformation de modèle UML et nous avons utilisé le langage MTL pour sa réalisation. L utilisation des transformations de modèles pour réaliser la dérivation des architectures statiques présente l avantage de maintenir une abstraction sur les produits. En effet, après dérivation nous avons des modèles de produits et non leur implantation ce qui permet par la suite l évolution et/ou la maintenance de produits.

Chapitre 7 Dérivation de comportements 7.1 Une Approche Algébrique Dans le chapitre 4, nous avons modélisé l aspect dynamique des LdP en utilisant les diagrammes de séquence d UML2.0 étendus par trois mécanismes de variabilité. Les diagrammes de séquence sont des bons moyens pour la modélisation d exigences comportementales ; ils sont souvent utilisés dans la première étape du processus de développement de systèmes. Nous avons également présenté dans la section 3.3 les machines à états comme un formalisme proche de l implantation, permettant la spécification détaillée du comportement de systèmes. La section 3.4 a montré que le passage des diagrammes de séquence aux machines à états a attiré beaucoup d attention dans le contexte des diagrammes de séquence d UML1.x. Nous avons discuté en détail ces travaux (cf. section 3.4) et nous avons vu qu ils souffrent de la faible expressivité des DS d UML1.x. Cependant, la nouvelle version des DS d UML2.0 introduit des opérateurs de composition et permet de décrire algébriquement leur composition; ceci permet de revisiter le problème de la synthèse dans le contexte d UML2.0 et proposer une nouvelle approche. Inspiré par la façon dont les diagrammes de séquence d UML2.0 peuvent être algébriquement composés, nous proposons une approche algébrique pour la génération des machines à états à partir des DS. En plus de son support de la nouvelle génération des DS d UML2.0, notre approche a la particularité de supporter les DS des LdP. Nous utilisons cette approche pour la dérivation de comportements de produits à partir des diagrammes de séquence des LdP. Cette dérivation est définie en deux étapes : Dérivation des expressions de produits L expression de référence (RESD-PL) est spécialisée pour un produit particulier en fonction des critères de décisions. Génération des machines à états Des machines à états sont générées à partir des expressions de référence de produits. 115

116 7.2 Dérivation des expressions de produits Dans le reste de ce chapitre nous décrivons en détail ces deux étapes. Nous réutilisons de nouveau la LdP banque pour l illustration de notre approche. 7.2 Dérivation des expressions de produits La première étape dans notre approche de dérivation de comportements est de dériver les expressions de produits à partir de l expression de référence de la LdP. Les expressions de LdP contiennent des points de variation introduits par les trois constructions de variabilité : optional, variation et virtual. La dérivation des expressions de produits a besoin des décisions associées à ces points de variation pour obtenir l expression d un produit particulier. Comme nous l avons mentionné dans la section 1.4.2, la notion de modèle de décision est utilisée dans les LdP comme un moyen pour capturer et enregistrer les décisions nécessaires à la dérivation de produits. Avant de détailler le processus de dérivation des expressions de produits, nous formalisons les modèles de décision et leurs instances dans le contexte de nos expressions de référence de LdP. 7.2.1 Modèles de décision Un modèle de décision est associé à une expression de référence de LdP (RESD-PL). Il spécifie les décisions nécessaires pour la dérivation des expression de produits, membre de la LdP. Ces décisions concernent les trois constructions de variabilité introduites dans les RESD-PL : La décision sur la présence ou non des expressions optionnelles incluses dans le RESD-PL. La décision sur le choix des variants de comportement. Il s agit de choisir pour une expression de variation une seule expression variante. La décision sur le raffinement des expressions virtuelles dans le RESD-PL. Il s agit de spécifier une expression de raffinement. Considérons de nouveau l expression de référence E BPL de la LdP banque (cf. section 4.6) : E BPL = loop( Deposit alt (CreateAccount seq (CreateAccountOk seq (optional settinglimit [ SetLimit ] seq optional settingcurrency [SetCurrency ])) alt CreateAccountFailed) alt (variation withdrawaccount [ WithdrawWithLimit, WithdrawWithoutLimit ] seq ( WithdrawOk alt WithdrawFailed)) alt (optional fromeuro [ ConvertFromEuro ]) alt (optional toeuro [ ConvertToEuro ] ))

Dérivation de comportements 117 E BPL contient cinq points de variation et son modèle de décision spécifie les décisions suivantes : La présence ou non des quatre expressions optionnelles : settinglimit, settingcurrency, fromeuro, et toeuro. Le choix d une expression variante pour l expression variation withdrawaccount (c.à.d. choisir entre WithdrawWithLimit et WithdrawWithoutLimit). Les résolutions de décisions pour un produit particulier sont définies dans ce que nous appelons une instance du modèle de décision. Définition 7 Une instance du modèle de décision (noté DMI par la suite) associée à un produit P est un ensemble de couples (name i, Res), ou name i désigne la nom de l expression optionnelle, variation ou virtuelle et Res est la résolution liée au produit P. Les résolutions sont définies comme suit : La résolution d une expression optionnelle est soit TRUE ou FALSE. Pour une expression variation comportant E 1,E 2,E 3..E n pour expressions variantes, la résolution est l entier i si l expression E i est sélectionnée. La résolution d une expression virtuelle est une expression de raffinement E. La Table 7.1 montre les instances du modèle de décisions associées aux quatre produits de la LdP banque (cf. section 4.6). DM1 par exemple est l instance du modèle de décision associé au produit BS1 qui supporte les limites sur les comptes et il ne supporte pas les opérations de gestion de devises. Tab. 7.1: Les instances du modèle de décision de la LdP banque Produit Instance du modèle de décision (DMI) BS1 BS2 BS3 BS4 DM1 ={(settinglimit, TRUE), (settingcurrency, FALSE), (withdrawaccount, 1), (fromeuro, FALSE), (toeuro, FALSE)} DM2 ={(settinglimit, FALSE), (settingcurrency, FALSE), (withdrawaccount, 2), (fromeuro, FALSE), (toeuro, FALSE)} DM3 ={(settinglimit, FALSE), (settingcurrency, FALSE), (withdrawaccount, 2), (fromeuro, TRUE), (toeuro, TRUE)} DM4 ={(settinglimit, TRUE), (settingcurrency, TRUE), (withdrawaccount, 1), (fromeuro, TRUE), (toeuro, TRUE)}

118 7.2 Dérivation des expressions de produits 7.2.2 Dérivation Comme pour les modèles statiques, nous considérons la dérivation des modèles comportementaux de produits comme une transformation de modèles. Les diagrammes de séquence des produits sont dérivés à partir des DS de la LdP. Comme les DS des LdP sont spécifiés algébriquement par les RESD-PL, nous formalisons cette spécialisation à travers la notion d interprétation. Les expressions de produits sont obtenues par une interprétation de l expression de la LdP dans le contexte d une instance du modèle de décision. Dans la suite, nous décrivons l interprétation associée à chaque construction de variabilité puis nous illustrons la dérivation des expressions de produits sur l exemple de la LdP banque. optional La dérivation d une expression optionnelle signifie décider de sa présence ou non dans l expression d un produit. Si la résolution de l expression optionnelle est TRUE, cette expression sera présente dans l expression du produit. Si la résolution est FALSE, l expression sera supprimée et la dérivation renvoi une expression vide. Ceci est formalisé par l interprétation suivante : { E si (name,true) DMi optional name [ E ] DMi = si (name,false) DMi E L expression vide E est la spécification d une interaction vide. E est un élément neutre pour la composition séquentielle et l alternative. Elle est aussi idempotente pour l opérateur loop, c.à.d. : E seq E = E; E seq E = E E alt E = E; E alt E = E loop (E ) =E. variation La dérivation d une expression variation signifie le choix d une expression variante parmi toutes les expressions variantes possibles. Ceci est formalisé comme suit : variation name [ E 1, E 2,.. ] DMi = E j si (name,j) DMi virtuel La dérivation d une expression virtuelle signifie son remplacement par une autre expression de raffinement. Si l expression de raffinement n est pas fournie, la dérivation garde par défaut l expression virtuelle : virtual name [ E ] DMi = E si (name,e ) DMi, E sinon Utilisant les interprétations de base ci-dessus, la dérivation des expressions de produits peut être définie maintenant comme suit :

Dérivation de comportements 119 Expression-Produit = Expression-LdP DMI, où DMI est l instance de modèle de décision associé au produit qu on veut dériver son expression. Considérons la LdP banque, l expression de produit BS1 : E BS1 est obtenue par interprétation de l expression E BPL dans le contexte de l instance du modèle de décision DM1, c.à.d. E BS1 = E BPL DM1, où : DM1 ={(settinglimit, TRUE), (settingcurrency, FALSE), (withdrawaccount, 1), (fromeuro, FALSE), (toeuro, FALSE)} La dérivation des quatre expressions optionnelles et de l expression variation dans E BS1 est réalisée comme suit : optional settinglimit [ SetLimit ] DM1 = SetLimit optional settingcurrency [ SetCurrency ] DM1 = E optional toeuro [ ToEuro ] DM1 = E optional fromeuro [ FromEuro ] DM1 = E variation withdrawaccount [WithdrawWithLimit, WithdrawWithoutLimit ] DM1 =WithdrawWithLimit L expression de référence du produit BS1 résultat est l expression E BS1 ci-dessous. Notons que comme E est un élément neutre pour seq et alt, E est supprimé de l expression du produit. E BS1 = loop( Deposit alt (CreateAccount seq (CreateAccountOk seq SetLimit ) alt CreateAccountFailed) alt ( WithdrawWithLimit seq ( WithdrawOk alt WithdrawFailed))) Appliquons le même processus pour le produit BS2 et BS4 en dérivant l expression E BPL dans le contexte de DM2 et DM4 respectivement, nous obtenons l expression E BS2 et E BS4 : E BS2 = loop( Deposit alt (CreateAccount seq (CreateAccountOk ) alt CreateAccountFailed) alt ( WithdrawWithoutLimit seq ( WithdrawOk alt WithdrawFailed)))

120 7.2 Dérivation des expressions de produits E BS4 = loop( Deposit alt (CreateAccount seq (CreateAccountOk seq SetLimit seq SetCurrency ) alt CreateAccountFailed) alt ( WithdrawWithLimit seq ( WithdrawOk alt WithdrawFailed)) alt ( ConvertFromEuro) alt ( ConvertToEuro)) Les expressions de produits dérivées sont des expressions de référence des DS (RESD), c.à.d. elles spécifient des diagrammes de séquence d UML2.0 sans variabilité. La Figure 7.1 montre le diagramme de séquence combiné associé au produit BS1. Fig. 7.1: Le diagramme de séquence combiné du produit BS1

Dérivation de comportements 121 7.3 Des expressions de produits aux machines à états à l issue de la première étape de dérivation de comportements, nous avons obtenu des diagrammes de séquence spécifiques aux produits. L étape suivante consiste à générer des machines à états à partir de ces diagrammes de séquence de produits. Comme discuté dans la section 3.4, la génération (appelée aussi synthèse) automatique de machines à états à partir de scénarios permet d assurer une traçeabilité entre les exigences (spécifiées par les scénarios) et la conception détaillée du système (spécifiée par les machines à états). Nous avons étudié les travaux existant et nous avons vu que les approches proposées dans le contexte des diagrammes de séquence d UML1.x utilisent souvent des informations supplémentaires et des hypothèses adhoc pour la gestion de l existence de plusieurs scénarios (les mécanismes de composition des diagrammes de séquence d UML1.x sont très limités ; cf section 3.2.1). Nous proposons dans cette section une méthode algébrique qui revisite le problème de la synthèse dans le contexte des diagrammes de séquence d UML2.0. Nous formalisons en premier lieu un cadre algébrique pour les machines à états inspiré de celui des DS d UML2.0. Ensuite, nous formalisons la synthèse comme une transformation de scénarios, spécifiés comme une composition de DS de base, vers une composition de machines à états. Comme nous le montrons par la suite, l avantage de cette méthode est sa flexibilité : la modification ou le remplacement d un scénario influence peu le processus de synthèse ce qui assure une meilleure traçeabilité entre les exigences et la conception détaillée du système. Dans le reste de cette section nous présentons le cadre algébrique que nous proposons pour les machines à états et nous détaillons notre méthode de synthèse. 7.3.1 Un cadre algébrique pour les machines à états Nous proposons de définir un cadre algébrique pour la composition des machines à états similaire à celui des diagrammes de séquence d UML2.0. Nous formalisons trois opérateurs permettant la composition séquentielle, l alternative et l itération des machines à états. Nous utilisons les expressions de référence des machines à états comme une spécification algébrique de leur composition. Par la suite, nous considérons seulement les machines à états à plats et nous n utiliserons pas les constructions avancées comme la hiérarchie et les états concurrents. Définition 8 Une machine à états à plats est un 6-tuple S,s 0,E,A,δ,J où S est l ensemble des états, s 0 est l état initial, E est un ensemble d événements, A est un ensemble d actions, δ S E A S est une relation de transition. J S est un ensemble d états de jonction.

122 7.3 Des expressions de produits aux machines à états Les états de jonctions sont proches des états finaux dans les automates classiques et ils auront un rôle supplémentaire pendant la composition des machines à états (nous utilisons l appellation machine à états mais nous voulons dire machine à états à plats). La Figure 7.2 montre un exemple de machines à états. Les états de jonction sont représentés avec des cercles doubles. La machine à états ST1 dans la Figure 7.2 est définie par le 6-tuple S,s 0,E,A,δ,J tel que : S = {s1,s2,s3} s 0 = s1 E = {e1} A = {a1,a2} δ = {(s1,e1,a1,s2),(s2,,a1,s3)} J = {s3} ST référence une machine à états vide, qui contient un seul état qui est à la fois état initial et état de jonction. Les ensembles d événements et d actions de ST sont vides (voir la Figure 7.2). La définition suivante introduit l équivalence entre machines à états. Fig. 7.2: Exemple de machines à états à plats Définition 9 Une machine à états ST1 = S 1,s 1 0,E1,A 1,δ 1,J 1 est dite équivalente à ST2 = S 2,s 2 0,E2,A 2,δ 2,J 2 (noté ST1 ST2) si : E 1 = E 2, A 1 = A 2, et il existe un isomorphisme µ = (µ 0,µ 1,µ 2 ), où : µ 0 : S 1 S 2 µ 0 (s 1 0 ) = s2 0 µ 1 : δ 1 δ 2, δ 1 = (s 1,e,a,s 2 ) δ 1, µ 1 (δ 1 ) = (s 1,e,a,s 2 ), tel que µ 0(s 1 ) = s 1 et µ 0 (s 2 ) = s 2 µ 2 : J 1 J 2, tel que : j 1 J 1, µ 2 (j 1 ) = j 2 j 2 J 2 et µ 0 (j 1 ) = j 2.

Dérivation de comportements 123 Nous utilisons la notation ST1 ST2 pour designer la non équivalence des deux machines à états ST1 et ST2 7.3.1.1 Opérateurs de composition Nous formalisons trois opérateurs pour la composition des machines à états : seq s, loop s, et alt s respectivement pour la composition séquentielle, l itération et l alternative. Les états de jonction que nous avons introduits précédemment seront nécessaires pour la formalisation de ces opérateurs. Dans la suite nous présentons ces trois opérateurs. Chaque opérateur est présenté par une définition formelle, une ou plusieurs propriétés algébriques et illustré par un exemple. Soit ST1 = S 1,s 1 0,E1,A 1,δ 1,J 1 and ST2 = S 2,s 2 0,E2,A 2,δ 2,J 2 deux machines à états. Séquence (seq s ). La composition séquentielle de deux machines à états est une machine à états qui décrit le comportement du premier opérande suivi par le comportement du deuxième. L opérateur seq s est formalisé comme suit : ST1 seq s ST2 = S,s 0,E, A,δ,J, où : L état initial de ST1 seq s ST2 est l état initial de la première machine à états si elle n est pas vide sinon c est l état initial de deuxième machine. c.à.d { s 1 s 0 = 0 si ST1 ST s 2 0 sinon S est défini comme suit : S 1 S 2 {s 2 0 } si (s2 0 J2 ST2 ST ) S = S 2 si ST1 ST S 1 S 2 sinon Les événements et les actions de ST1 seq s ST2 sont l union des ensembles d événements et d actions des deux opérandes : E = E 1 E 2 ; A = A 1 A 2. La composition séquentielle de deux machines à états préserve toutes les transitions de ses opérandes, sauf les transitions à partir de l état initial de ST2 quand ST2 ne spécifie pas une boucle. Une machine à états spécifie une boucle si son état initial est un état de jonction. Pour la concaténation des deux machines, de nouvelles transitions sont ajoutées à partir de chaque état de jonction de la première machine vers tous les successeurs de l état initial dans la deuxième machine, c.à.d. :

124 7.3 Des expressions de produits aux machines à états δ = δ 1 (δ 2 S E A S) {(j,e,a,s) J 1 E 2 A 2 S 2 (s 2 0,e,a,s) δ2 )} { J J = 2 J 1 si s 2 0 J2 J 2 sinon Propriété algébrique ST est un élément neutre pour la composition séquentielle, c.à.d. ST : ST seq s ST ST seq s ST ST. Exemple La Figure 7.3 montre la machine à états obtenue par composition séquentielle de deux machines ST1 et ST2. Les états de jonction de la machine à états résultat sont ceux de ST2. Fig. 7.3: Exemple d application de l opérateur seq s Itération (loop s ). L opérateur loop s définit l itération d une machine à états, c.à.d. le comportement spécifié par la machine à états est itéré un nombre infini de fois. loop s est formalisé comme suit : loop s (ST1) = S,s 0,E, A,δ,J, tel que : L état initial de la machine à états itérée reste inchangé, c.à.d. s 0 = s 1 0. S contient tous les états sauf les états de jonction, c.à.d. S = (S 1 J 1 ) {s 1 0 }. Les ensembles des événements et des actions restent inchangés, c.à.d. E = E 1 ; A = A 1. L itération ajoute des transitions à partir des prédécesseurs de chaque état de jonction vers l état initial, et supprime les transitions vers les états de jonction. Ceci est formalisé de la manière suivante : δ = (δ 1 S E A S) {(s,e,a,s 1 0 ) (s,e,a,j) δ1 }

Dérivation de comportements 125 L ensemble des états de jonction de la machine à état résultant contient seulement l état initial, c.à.d. J = {s 1 0 }. Propriété algébrique L itération d une machine à états vide est la machine vide elle-même, c.à.d. loop s (ST ) ST. Exemple La Figure 7.4 montre la machine à états obtenue par l itération de ST 2. Elle contient un seul état de jonction qui est l état initial Fig. 7.4: Exemple d application de l opérateur loop s Alternative (alt s ). La machine à états obtenue par composition alternative spécifie un choix entre les comportements de ses opérandes. ST1 alt s ST2 = S,s 0,E,A,δ,J, tel que : s 0 = un nouvel états si ST1 et ST2 spécifient des boucles,.c.à.d. (s 1 0 J1 s 2 0 J2 ST1 ST ST2 ST ) s 2 0 si seulement ST1 spécifie une boucle ou ST1 est vide.c.à.d. (s 1 0 J1 ST1 ST ) s 2 0 J2 s 1 0 sinon Notons que nous conservons s 1 0 comme état initial par défaut, mais nous obtenons un résultat similaire si nous conservons s 2 0.

126 7.3 Des expressions de produits aux machines à états S = S 1 si (ST2 ST ST1 ST ) S 2 si (ST1 ST ST2 ST ) {s 0 } si (ST1 ST ST2 ST ) S 1 S 2 {s 0 } si (s 1 0 J1 s 2 0 J2 ST1 ST ST2 ST ) S 1 S 2 {s 2 0 } S 1 S 2 sinon E = E 1 E 2 ; A = A 1 A 2. si s1 0 J1 s 2 0 J2 Pour spécifier un choix entre les comportements de deux machines à états, de nouvelles transitions sont ajoutées à partir du nouvel état initial vers tous les successeurs de l état initial du deuxième opérande. Ceci est défini de la manière suivante : δ = (δ 1 S E A S) (δ 2 S E A S) {(s 0,e,a,s) (s 1 0,e,a,s) δ1 (s 2 0,e,a,s) δ2 } L ensemble des états de jonction est l union des ensembles d états de jonctions des opérandes, c.à.d. J = (J 1 J 2 ) S. Propriété algébrique ST est un élément neutre pour la composition alternative, c.à.d. ST alt s ST ST alt s ST ST. La composition alternative est commutative, c.à.d. ST1 alt s ST2 ST2 alt s ST1. Exemple La composition alternative entre les deux machines à états ST 1 et ST 2 est illustrée dans la Figure 7.5. L état initial de la machine à états résultat est celui de ST1 et l ensemble des états de jonction est l union de ceux de ST1 et ST2. 7.3.1.2 Expressions de référence des machines à états Nous introduisons les expressions de référence des machines à états comme une représentation algébrique de leur composition. Définition 10 Une expression de référence pour les machines à états (noted REST pour Reference Expression for Statecharts, par la suite) est une expression de la forme : <REST> : :=<PRIMARY> ("alt s " <REST> "seq s " <REST>)* <PRIMARY> : :=ST <IDENTIFIER> "("<REST>")" "loop s " "(" <REST> ")" <IDENTIFIER> : := ([ 6,"a"-"z","A"-"Z"] ["0"-"9"])*

Dérivation de comportements 127 Fig. 7.5: Exemple d application de l opérateur alt s 7.3.2 Génération des machines à états Utilisant le cadre algébrique que nous avons formalisé dans la section précédente, nous présentons dans cette section un algorithme pour la génération des machines à états à partir des diagrammes de séquence d UML2.0. En premier lieu, nous montrons comment des machines à états sont générées à partir des diagrammes de séquence de base. Ensuite, nous définissons la génération des machines à états à partir des diagrammes de séquence combinés comme une transformation entre les RESD et REST. 7.3.2.1 Diagrammes de séquence de base Comme nous l avons mentionné dans la section 3.2.2, un diagramme de séquence d UML2.0 de base est considéré maintenant comme une collection d événements partiellement ordonnés au lieu d une collection de messages dans UML1.x. Nous définissons un DS de base par une relation d ordre partiel comme ci-dessous. Notons que comme nous ne manipulerons que les événements d un DS, la définition que nous introduisons est simple et elle ne contient pas la notion de message. Définition 11 Un diagramme de séquence de base est un nuplet (E,,I,φ), où : E est un ensemble d événements, est une relation d ordre partiel imposée par les lignes de vies et les messages, I est un ensemble d objets participant au diagramme de séquence, φ : E I est une fonction associant un événement à une localisation La relation est une relation d ordre partiel, c.à.d. elle est réflexive, antisymétrique et transitive.

128 7.3 Des expressions de produits aux machines à états Considérons par exemple le DS de base Deposit dans la Figure 7.6, ce diagramme de séquence est défini par le nuple (E,,I,φ)(nous notons!m l envoi de message m et?m sa réception), où : E = {!depositonaccount,?depositonaccount,!deposit,?deposit}!depositm essage,?depositm essage} = {(!depositonaccount,?depositonaccount), (!depositonaccount,!deposit),(!depositonaccount,?deposit), (!depositonaccount,!depositm essage),(!depositonaccount,?depositm essage),(?depositonaccount,!deposit), (?depositonaccount,?deposit),(?depositonaccount,!depositm essage),(?depositonaccount,?depositm essage), (!deposit,?deposit),(!deposit,?depositm essage), (!deposit,?depositm essage),(?deposit,?depositm essage), (?deposit,?depositm essage),(!depositm essage,?depositm essage)} w I = {Clerk,Bank,Account} φ = {(!depositonaccount, Clerk),(?depositOnAccount, Bank), (!deposit, Bank),(?deposit, Account),(!depositM essage, Bank), (?depositm essage, Clerk)} Fig. 7.6: Le DS de base Deposit dans la LdP banque La génération d une machine à états pour un objet donné à partir d un DS de base est basée sur la projection des événements de DS sur la ligne de vie de l objet. Notons que comme nous ne considérons pas l opérateur d interaction par (cf. section 3.2.2.2) et par conséquence les corégions 1, la projection des événements d un DS sur un objet particulier sera définie comme un ordre total(noté <). 1 Une corégion est une zone sur la ligne de vie d un objet dans un DS permettant de spécifier que les événements de cette zone peuvent se produire en n importe quel ordre ou en concurrence. Les corégions dans les DS d UML2.0 sont modélisées à l aide de l opérateur par [94].

Dérivation de comportements 129 Définition 12 Une projection π O (S) d un diagramme de séquence S sur un objet O est la restriction de la relation d ordre partiel aux événements situés sur la ligne de vie de l objet O. Comme cette restriction est un ordre total, nous allons considérer la projection comme un mot π O = e 1.e 2..e n tel que φ 1 (O) = {e 1,... e n }, and e 1 < e 2 <...e n. Par exemple, le mot?depositonaccount!deposit!depositm essage est la projection de DS Deposit dans l exemple de banque sur l objet Bank. Les réceptions de messages deviennent des événements dans la machine à états et les émissions deviennent des actions. Pour la transition associée à une réception, la partie action est vide, et pour les transitions associées à des actions, la partie événement est vide. L algorithme P(S, O) ci-dessous montre comment générer une machine à états pour un objet O à partir d un DS S. La machine à états générée est une séquences d états, et elle contient un seul état de jonction qui correspond à l état atteint lorsque tous les événements sur la ligne de vie sont traités. Notons aussi que si un objet ne participe pas à un DS, la projection de DS sur cet objet est un mot vide ǫ. Pour ce cas particulier, la machine à états générée est la machine vide ST. La Figure 7.7 illustre l algorithme de synthèse d une machine à états de l objet Bank à partir de DS de base Deposit. Fig. 7.7: Exemple de la synthèse d une machine à états à partir d un DS de base

130 7.3 Des expressions de produits aux machines à états algorithm : P(S, O) Input : A basic SD S, an object O Output : A statechart ST O = (S,s 0,E,A,δ,J) Crée un état initial s 0 currentstate := s 0 E := ; A := ; S := s 0 ; J = ; δ = ProjectedEvents := π O (S) if ProjectedEvents est vide then return(st ) else for i = 1 to P rojectedevents do e i := ProjectedEvents[i] Crée un nouveau état s ; S = S {s} if e i est un événement de réception then E := E {e i } Tr := (currentstate, e i,, s) δ := δ {Tr} else if e i est un événement d envoi then A := A {e i } Tr := (currentstate,, e i, s) δ := δ {Tr} end if end if currentstate := s end for J = currentstate return(st o ) end if L algorithme ci-dessus nous permet de générer, pour un objet spécifique, une collection des machines à états de base à partir des différents diagrammes de séquences de base. Chaque machine à états est en quelque sorte le comportement partiel de l objet dans le diagramme de séquence. La Figure 7.8 montre toutes les machines à états générées à partir des diagrammes de séquence de base de la LdP banque (voir la Figure 4.8 dans la section 4.4.3) pour l objet Bank. La machine à états P(Deposit, Bank) par exemple est générée à partir du DS Deposit.

Dérivation de comportements 131 Fig. 7.8: Les machines à états de base de l objet Bank

132 7.3 Des expressions de produits aux machines à états 7.3.2.2 Diagrammes de séquence combinés L extension de l algorithme pour les diagrammes de séquence combinés est basée sur leurs spécifications algébriques sous forme des RESD. Nous définissons la synthèse des machines à états à partir des interactions combinées comme une construction des expressions de référence de machines à états à partir de RESD. Avant de détailler cette construction, nous discutons la correspondance entre les opérateurs d interaction d UML2.0 et les opérateurs de machines à états que nous avons formalisé ci-dessus. De seq à seq s Comme présenté dans la section 3.2.2.2, l opérateur d interaction seq définit une séquence faible entre les diagrammes de séquence. La séquence faible est définie dans [94] comme une séquence forte entre tous les événements situés sur la même ligne de vie, c.à.d. les événements situés sur une ligne de vie particulière dans le premier opérande doivent être exécutés avant les événements situés sur la même ligne de vie du deuxième opérande. Comme les machines à états générées par l algorithme ci-dessus décrivent les comportements des DS sur une ligne de vie particulière, l opérateur de séquence entre des DS correspond donc à une séquence entre les machines à états pour le même objet générées à partir de ces DS (voir la Figure 7.9). Fig. 7.9: De seq à seq s

Dérivation de comportements 133 De alt à alt s L opérateur alt spécifie le choix entre les DS. Pour un objet particulier, l alternative entre les DS spécifie aussi une alternative entre les machines à états générées à partir de ces DS pour cet objet (voir la Figure 7.10). Fig. 7.10: De alt à alt s De loop à loop s L itération d un DS spécifie que tous les événements (compris ceux situés sur la même ligne de vie) dans ce DS sont itérés un nombres infinis de fois. L itération des DS correspond donc à une itération des machines à états générées à partir de ce DS pour chaque objet (voir la Figure 7.11). Fig. 7.11: De loop à loop s

134 7.3 Des expressions de produits aux machines à états De RESD aux REST Considérons, une expression RESD E décrivant les interactions d un ensemble d objets O = {O 1,O 2,..O n }. Pour chaque objet O i, une expression REST E i est construite par remplacement respectif dans le RESD de seq, alt, et loop par les opérateurs des machines à états seq s, alt s, et loop s et chaque référence à un diagramme de séquence S par une référence à la machine à états P(S,O i ). A partir de l ensemble d expressions {E 1,E 2,..E n }, n machines à états sont générées utilisant les opérateurs de composition des machines à états. Pour illustration, nous appliquons cette construction à l expression de référence associé au produit BS2 dans la LdP banque. L expression de référence REST pour l objet Bank obtenue est REST (BS2,Bank) décrit ci-dessus. La Figure 7.12 montre la machine à états obtenue à partir de cette REST. REST (BS2,Bank) = loop s ( P(Deposit, Bank) alt s (P(CreateAccount, Bank) seq s (P(CreateAccountOk, Bank) ) alt s P(CreateAccountFailed, Bank)) alt s P((WithdrawWithLimit, Bank) seq s ( P(WithdrawOk, Bank) alt s P(WithdrawFailed, Bank)))) Fig. 7.12: La machine à états pour l objet Bank dans le contexte de produit BS2

Dérivation de comportements 135 La même méthode peut être appliquée pour le produit BS4. Une expression REST (BS4,Bank) est obtenue (voir ci-dessous). La Figure 7.13 montre la machine à états de l objet Bank obtenue à partir de REST (BS4,Bank). Notons que comme les deux produits BS2 et BS4 diffèrent par la présence ou non du montant de découvert et le support des opérations de conversion, les machines à états générées (La Figure 7.12 et la Figure 7.13) diffèrent par les transitions qui concernent l ajout et la vérification du montant de découvert et celles qui concernent la conversion des devises. La différence entre les deux machines à états est illustrée par des zones grises dans la Figure 7.13. REST (BS4,Bank) = loop s ( P(Deposit, Bank) alt s (P(CreateAccount, Bank) seq s (P(CreateAccountOk, Bank) seq s P(SetLimit, Bank) seq s P(SetCurrency, Bank) ) alt s P(CreateAccountFailed, Bank))alt s ( P(WithdrawWithLimit, Bank) seq s (P(WithdrawOk, Bank) alt s P(WithdrawFailed, Bank))) alt s ( P(ConvertFromEuro, Bank)) alt s ( P(ConvertToEuro, Bank))) 7.4 Évaluation de l approche 7.4.1 Avantages L approche algébrique que nous avons présentée dans les sections précédentes pour la dérivation de comportement de produits présente trois principaux avantages : Le premier avantage concerne la séparation entre l étape de dérivation des expressions de produits et de génération des machines à états. Cette séparation permet de rendre notre approche utile même en dehors des LdP. En effet, sans la variabilité les machines à états sont générés directement à partir des expressions de référence des diagrammes de séquence d UML2.0 [119]. Le deuxième avantage est lié à l étape de génération des machines à états. La définition de la synthèse de machines à états à partir des diagrammes de séquence d UML2.0 comme une transformation directe entre les RESD et REST donne une flexibilité au processus de la synthèse. En effet, toute modification (ajout ou suppression d un DS dans le RESD) n influence que légèrement le processus de la synthèse. Il suffit seulement de modifier (ajouter ou supprimer la machine à état qui correspond) les REST; ceci favorise une meilleure traçeabilité entre les exigences (spécifiées par les DS) et la conception détaillée (spécifiée par les machines à états). Pour illustrer cette flexibilité, considérons de nouveau l expression de référence du produit BS4 et supposons que nous voudrions remplacer les diagrammes de séquence ConvertFromEuro et ConvertToEuro par deux DS permettant la conversion de et au dollar : ConvertFromDollar et ConvertToDollar

136 7.4 Évaluation de l approche Fig. 7.13: La machine à états pour l objet Bank dans le contexte de produit BS4

Dérivation de comportements 137 respectivement. La nouvelle expression de BS4 prend donc cette forme : E newbs4 = loop( Deposit alt (CreateAccount seq (CreateAccountOk seq SetLimit seq SetCurrency ) alt CreateAccountFailed) alt ( WithdrawWithLimit seq ( WithdrawOk alt WithdrawFailed)) alt ( ConvertFromDollar) alt ( ConvertToDollar)) La nouvelle REST pour l objet Bank est obtenue facilement à partir de l ancienne expression en remplaçant les machines à états générées à partir de ConvertFromEuro et ConvertToEuro par celles obtenues à partir ConvertFromDollar et ConvertToDollar. La nouvelle REST est l expression REST (newbs4,bank) décrite ci-dessous. Une nouvelle machine à états est obtenue à partir de cette expression par la composition des machines à états générées avant la modification et les nouvelles machines à états correspondant au changement de REST. REST (newbs4,bank) = loop s ( P(Deposit, Bank) alt s (P(CreateAccount, Bank) seq s (P(CreateAccountOk, Bank) seq s P(SetLimit, Bank) seq s P(SetCurrency, Bank) ) alt s P(CreateAccountFailed, Bank)) alt s ( P(WithdrawWithLimit, Bank) seq s (P(WithdrawOk, Bank) alt s P(WithdrawFailed, Bank))) alt s ( P(ConvertFromDollar, Bank)) alt s ( P(ConvertToDollar, Bank))) Comme nous l avons mentionné dans la section 3.2.2, les diagrammes de séquence d UML2.0 sont inspirés des mécanismes de composition dans les MSC [51]. Nos expressions de référence sont proches des expressions de référence des MSC [51] et un HMSC peut être représenté par une expression de référence dont les termes sont des références aux bmsc [68]. Nos propositions pour la modélisation de la variabilité des LdP peuvent donc s appliquées aux MSC et nos constructions algébriques peuvent étendre les expressions de référence des MSC. 7.4.2 Limites Notre approche de génération des machines à états à partir des diagrammes de séquence d UML2.0 a quelques limites : Notre approche supporte seulement les trois opérateurs d interaction d UML2.0 : seq, alt et loop. Cependant le support de l opérateur d interaction opt (cf. section 3.2.2.2) semble immédiat. En effet, d après [94], cet opérateur est équivalent à l opérateur alt où le deuxième opérande est le diagramme de séquence vide,

138 7.5 Discussion autour de la synthèse c.à.d. opt(sd) = alt (SD, E ). Il sera intéressant d étudier l extension de notre approche aux autres opérateurs d interaction d UML2.0. Nous n avons considéré que les machines à états à plats. Ceci pose le problème de la lisibilité des machines à états dans le cas où elles contiennent un nombre important d états. Notre approche peut être amélioré par l introduction de l hiérarchie en utilisant les techniques basées sur les diagrammes de classes [117] ou de réusinage (ou refactoring) [104]. Les machines à états obtenues à partir de certaines expressions de référence REST ne sont pas nécessairement déterministes. Considérons par exemple l expression E = loop s (ST1 seq s ST2) seq s ST1, où ST1 et ST2 sont les références vers les machines à états dans la Figure 7.2. La machine à états obtenue à partir de cette expression est non-détérministe (voir la Figure 7.14). Ceci demande une étape supplémentaire de déterminisation une fois que le processus de synthèse est achevé. Cette déterminisation peut être réalisée en utilisant les algorithmes standard des automates [6]. Fig. 7.14: Exemple d une machine à états non-déterministe 7.5 Discussion autour de la synthèse Nous avons formalisé la dérivation de comportements des produits comme une synthèse de machines à états à partir de scénarios. Comme mentionné dans le chapitre 3, les scénarios et les machines à états représentent deux vues d un système : la vue interobjets et la vue intra-objets. Dans de cette section nous discutons la relation qui peut exister entre ces deux vues et le rôle de la synthèse dans le contexte d une méthodologie de développement de systèmes.

Dérivation de comportements 139 7.5.1 Vues Inter-objet et intra objet Nous avons mentionné dans la section 3.4.3 que certains travaux existant autour de la synthèse des machines à états à partir des scénarios se sont intéressés à la comparaison de comportements spécifiés dans les scénarios et ceux obtenus dans les machines à états synthétisées [49, 72, 108]. Un autre travail intéressant dans ce contexte est l étude de l implémentabilité de scénarios pour un certain nombre de modèles de communication dans [28]. Le choix du modèle de communication entre les objets influence fortement les comportements obtenus dans les machines à états synthétisées. Pour illustrer cette influence, nous considérons trois modèles de communication entre les objets : synchrone, asynchrone, et diffusion (braodcast). La communication synchrone signifie que l échange de messages entre les objets est instantanné et il n y a pas de tampons pour garder les messages. Dans les communication asynchrones des tampons de messages sont utilisés. Plusieurs stratégies de gestion de tampons sont possibles (une file pour chaque objet, une file partagée entre deux objets,..etc). La communication par diffusion est le modèle adopté dans les statecharts de David Harel [40]. Les événements sont diffusés et ils sont consommés par les machines à états concernées par cet événement. La Figure 7.15 montre un DS simple et les trois machines à états générées pour les trois objets A, B, et C. Si on considère la diffusion comme modèle de communication entre les trois objets, il y a un risque de blocage. En effet, si le message m2 est diffusé avant m1, les deux objets A et B seront bloqués car l objet A a besoin de recevoir m2 avant d envoyer m3. Ce blocage ne se produira pas si le modèle de communication est synchrone ou asynchrone. Cet exemple montre que le choix de la diffusion comme modèle de communication engendre des blocages dans certains DS. Fig. 7.15: Exemple d un diagramme de séquence engendrant de blocage pour la diffusion La Figure 7.16 montre une autre situation dans laquelle quel que soit le modèle

140 7.5 Discussion autour de la synthèse de communication adopté (synchrone ou asynchrone) il aura un blocage. Si l objet A envoie le message m1, il n y a pas moyen d informer l objet C pour qu il envoie le message m3. Cette situation est connue dans la communauté des MSC sous le nom de choix non-local [48]. Fig. 7.16: Exemple d un DS avec un choix non-local Fig. 7.17: Les machines à états générées à partir de DS de la Figure 7.16 Les deux exemples ci-dessus montrent que le choix d un modèle de communication entre objets a des conséquences sur les comportements des machines synthétisées. Ce même choix influence la relation entre le comportement spécifié dans les scénarios et celui obtenu dans les machines à états synthétisées. Quatre situations principales peuvent se produire : Situation 1 : Égalité La première situation est l égalité entre les deux comportements, c.à.d. les comportements spécifiés dans les DS sont exactement les mêmes que ceux obtenus dans les machines à états. Il est évident que ce cas est la situation idéale, cependant comme il a été démontré dans [49], l égalité n est possible que par la restriction du langage des scénarios, c.à.d. en ajoutant des conditions sur

Dérivation de comportements 141 les scénarios en entrée de l algorithme de la synthèse. Ces conditions sont basées sur la notion de recontructibilité des choix dans un scénario composé [49]; d après les auteurs, l égalité n est assurée que si tous les choix sont reconstructibles. Situation 2 : Inclusion sens 1 Dans la deuxième situation, seulement les comportement de machines à états sont inclus dans les comportements de scénarios (voir la Figure 7.18). Mais certains comportements spécifiés dans les scénarios ne peuvent pas être assurés par les machines à états. Situation 3 : Inclusion sens 2 Tous les comportements spécifiés dans les scénarios sont inclus dans ceux des machines à états synthétisées (voir la Figure 7.18). Dans cette situation la synthèse des machines à états, en plus des comportements spécifiés dans les scénarios, a généré des nouveaux comportements. Situation 4 : Incomparable La dernière situation est la situation où il n a y a pas inclusion dans un sens où dans l autre. Les machines états assurent certains comportements spécifiés dans les scénarios mais elles engendrent de nouveaux comportements. Il y a aussi certains comportements spécifiés dans les scénarios qui ne sont pas assurés par les machines à états synthétisées. Fig. 7.18: Les relations entre le comportement des scénarios et celui de machines à états Notre méthode de synthèse assure l inclusion sens 2 utilisant un modèle de communication asynchrone simple basé sur des files entre chaque paire d objets [119]. Les comportements spécifiés dans les diagrammes de séquence d UML2.0 sont donc inclus dans les comportements de machines à états générées.

142 7.5 Discussion autour de la synthèse 7.5.2 Le rôle de la synthèse Dans cette section nous discutons le rôle que peut jouer la synthèse dans un processus de développement. Nous avons souligné dans la section 3.4.2, que les motivations principales de la synthèse des machines à états à partir des scénarios sont d un coté profiter des techniques de vérification basées sur les machines à états et de l autre coté utiliser les techniques et les outils pour la génération du code. En plus de la vérification et de génération de code, nous discutons aussi la simulation comme un rôle possible de la synthèse : Vérification d exigences Les machines à états ont montré leur potentiel dans le domaine de la vérification de systèmes. Les résultats de la synthèse des machines à états peuvent être utilisés comme un moyen pour la vérification des exigences du système spécifiées par les scénarios. Un exemple d utilisation de la synthèse pour la vérification est l algorithme présenté dans [107] (cf. section 3.4.2). En effet, cet algorithme génère des spécifications FSP (Finite Sequential Process), les auteurs proposent d utiliser LTSA [76] pour la vérification de certaines propriétés et la détection des blocage dans les scénarios. Génération de code Puisque la synthèse permet de générer des machines à états à partir des diagrammes de séquence, nous pouvons utiliser des techniques et des outils tels que l outil Rhapsody [50] pour générer de code exécutable. Ceci représente une étape importante vers la génération directe de code exécutable à partir des exigences spécifiées par des scénarios. [41] a discuté cette transition comme un rêve ambitieux mais possible pour les LSC. Dans [116], Whittle et al. ont utilisé leur algorithme de synthèse pour la génération de code d un système de contrôle aérien. Simulation Même si la simulation est possible directement à partir des scénarios [47], la synthèse des machines à états peut être utile pour la simulation. L outil UMLAUT [46] contient un module de simulation qui génère un système de transitions étiquetées à partir d un ensemble de machines à états (la construction du système de transitions et la simulation sont décrites dans [37]). Les résultats de la synthèse peuvent donc être utilisé pour la simulation en utilisant UMLAUT. Comme la synthèse n assure pas toujours l égalité entre le comportement de scénarios et celui de machines à états (voir la discussion dans la section précédente), la synthèse devrait être vue comme une étape vers la conception détaillée et non comme une transition directe et sûre. Dans la suite, nous discutons l adaptabilité des résultats de la synthèse à la vérification et à la génération de code en fonction de la relation entre le comportement des scénarios et celui des machines à états :

Dérivation de comportements 143 Situation 1 : Dans la première situation où il y a l égalité entre les deux comportements, la synthèse est une étape de transition sûre et les résultats de la synthèse peuvent être utilisés pour la vérification et pour la génération de code sans risque d incohérence. Situation 2 : Dans la deuxième situation où seulement les comportements de machines à états sont inclus dans les comportements de scénarios, les résultats de la synthèse sont très adaptés à la vérification car si les machines à états ne vérifient pas certaines propriétés ou s il y a des blocages, ceci signifie certainement qu il y a des erreurs dans les exigences spécifiées dans les scénarios. Cependant le code généré à partir de ces machines à états n implimente pas toutes les exigences. Situation 3 : Dans la troisième situation, toutes les exigences spécifiées dans les scénarios sont assurées par les machines à états. La synthèse peut être utilisée pour la vérification des exigences ainsi que pour la génération de code. Cependant, il faut être conscient que des nouveaux comportements sont générés dans les machines à états. Donc des erreurs ou des blocages détectes dans les machines à états peuvent concerner ces derniers comportements et non les comportements des scénarios. Situation 4 : Dans la cas ou les deux comportements sont incomparables, les résultats de la synthèse ne sont adaptés ni à la vérification, ni à la génération de code. En effet, les machines à états engendrent de nouveaux comportements sans assurer toutes les exigences. 7.6 Conclusion Dans ce chapitre, nous avons présenté une approche algébrique pour la dérivation de comportements de produits. Cette approche synthétise automatiquement des machines à états spécifiques aux produits à partir de scénarios de la LdP. Elle présente deux avantages : d une part elle revisite le problème de la synthèse des machines à états dans le contexte d UML2.0 et d autre part elle supporte les exigences des LdP. Nous avons discuté la relation entre les comportements spécifiés dans les scénarios et ceux des machines à états synthétisées ainsi que le rôle de la synthèse dans une méthodologie de développement de système. Ainsi, les résultats de la synthèse peuvent être utilisés pour la vérification des exigences, la simulation et/ou la génération de code exécutable.

144 7.6 Conclusion

Chapitre 8 Application et validation 8.1 Les projets CAFE et FAMILIES Les travaux présentés dans cette thèse se sont déroulés dans le cadre de deux projets Européens CAFE [2] et FAMILIES [3]. L objectif du projet itea cafe (from Concept to Application in System-Family Engineering) [2] était de développer autour d uml une infrastructure permettant de définir et de gérer des familles d architectures de logiciels correspondant à des lignes de produits. Labellisé en janvier 2001, le projet cafe regroupait un nombre important d industriels européens (notamment Philips, Siemens, Thales, Alcatel, esi, Bosch Gmbh, etc.) Le projet CAFE était divisé en cinq workpackages et chaque workpackage est divisé en tâches. Nous avons participé à deux workpackages : Workpackage 2 : La construction des assets (Asset building). Nous avons participé et contribué dans la tâche 2.2 à la construction d assets génériques en définissant des DS de séquence génériques, c.à.d. des DS avec variabilité. Nous avons contribué aussi à la tâche 2.4 par la spécification de contraintes de LdP en OCL. Workpackage 3 : Utilisation d assets (Asset usage). Nous avons contribué dans la tâche 3.3 pour la dérivation de produits. Le projet FAMILIES [3] est la suite du projet CAFE. Il regroupe la majorité des partenaires de CAFE avec quelques nouveaux partenaires. Nous avons continué à contribuer à ce projet par l utilisation de notre approche de dérivation de comportement sur une étude de cas commune aux partenaires. 145

146 8.2 L outil prototype PLiBS 8.2 L outil prototype PLiBS Nous avons discuté dans le chapitre 5, l implantation de la dérivation de l aspect statique dans les LdP en utilisant MTL (les sources et les modèles sont téléchargeables de [4]). Dans cette section nous présentons l outil prototype PLiBS (Product Line Behavior Synthesis) que nous avons développé pour la dérivation de comportements présentée dans le chapitre 6. L outil implante la dérivation d expressions ainsi que la synthèse de machines à états. Dérivation d expressions de produits PLiBS permet de spécifier les expressions de référence des LdP (RESD-PL) telles que définies dans le chapitre 4. La Figure 8.1 montre la spécification de l expression de la LdP banque dans PLiBS. PLiBS facilite l instantiation des points de variation dans le RESD-PL par l extraction automatique de ces dernières dans une fenêtre spécifique (voir la Figure 8.2). PLiBS extrait les expressions optionnelles, variations et virtuelles. L instantiation d un produit particulier se fait par de simples sélections parmi les choix possible. PLiBS par la suite dérive l expression du produit en fonction de l instance du modèle de décision en utilisant l approche présentée dans la section 7.2. Fig. 8.1: Exemple de spécification de RESD-PL dans PLiBS Synthèse des machines à états La dérivation de machines à états à partir des expressions de référence se fait dans PLiBS dans une fenêtre séparée. Ceci pour permettre la séparation des deux étapes de dérivation des expressions de produits et l étape de la génération de machines à états.

Application et validation 147 Fig. 8.2: L instantiation du modèle de décision dans PLiBS

148 8.3 Études de cas En plus des expressions de référence, l étape de synthèse des machines à états a besoin de la spécification des interactions des DS de base. Nous utilisons actuellement dans PLiBS une réprésentation textuelle des DS de base proche que celle des bmsc [51]. La Figure 8.3 montre la fenêtre principale dans PLiBS pour la génération des machines à états. L utilisateur choisit l objet considéré parmi tous les objets participants dans un ou plusieurs DS de base. La Figure 8.4 montre un exemple de visualisation d une machine à états générée dans PLiBS. Fig. 8.3: La synthèse des machines à états dans PLiBS 8.3 Études de cas L outil PLiBS a été utilisé pour la génération des machines à états des quatre produits de la LdP banque (cf. section 4.2). La Table 8.1 résume les statistiques sur le nombre d états et transitions dans la machine à états de l objet Bank dans les quatre produits banque. On constate que les machines à états synthétisées sont effectivement différentes les une des autres, ce qui valide l intérêt de notre approche.

Application et validation 149 Fig. 8.4: Exemple d une machine à états synthétisée dans PLiBS PLiBS a été utilisé dans deux autres études de cas : 1) la LdP Camera [120, 122] qui concerne un ensemble de systèmes pour la gestion des caméras numériques 2) la Ligne de Produits pour la Vente aux Enchères (LdPVE) [121] sur Internet. Il s agit d une famille de serveurs de ventes aux enchères permettant à des utilisateurs de négocier l achat et la vente de biens par le web (inspirée de systèmes tels que E-Bay) dont l objectif est d imiter le plus possible le déroulement de séances d enchères dans des salles de ventes. En plus de ces études de cas académiques, nous avons utilisé notre approche de dérivation de comportements et le prototype PLiBS dans une étude de cas communes aux partenaires du projet Famillies. Il s agit d une famille de systèmes gérant des montres multimédia. L utilisation de cette étude de cas était intéressante pour la validation de notre approche, car l un des partenaires a fournit une implantation en Java de tous les produits basée sur une conception «manuelle» de machines à états. Nous avons modélisé de nouveau cette LdP en utilisant nos scénarios de LdP et nous avons comparé les machines à états synthétisées par PLiBS et celles fournies par le partenaire. Même si notre conception n était pas la même que celle du partenaire, la comparaison montre bien qu elles sont proches. L approche de synthèse des machines à états a été aussi validée sur l exemple de guichetier automatique de banque, ou ATM (Automatic Teller Machine) [119]. Dans

150 8.3 Études de cas l annexe C, le lecteur trouvera les diagrammes de séquence de base et l expression de référence associés à cet exemple. Nous avons utilisé les scénarios de base comme fournis dans les deux travaux [117, 107] et nous avons formalisé leurs compositions dans une expression de référence. Les machines à états synthétisées par PLiBS sont les mêmes obtenues par ces deux travaux. Tab. 8.1: Statistiques sur le nombre d états et de transitions générés pour la machine à états de l objet Bank dans la LdP banque # States # Transitions BS1 12 16 BS2 10 14 BS3 13 19 BS4 15 21

input./partie3/chapitre7

152 8.3 Études de cas

Troisième partie Conclusion et perspectives 153

155 Contributions Les travaux présentés dans cette thèse s articulent autour de la manipulation de LdP logiciels en UML. Ils couvrent les trois activités principales dans les LdP à savoir la modélisation de la variabilité, la gestion des contraintes et la dérivation de produits : Le chapitre 4 de ce document a présenté un ensemble de mécanismes permettant de modéliser la variabilité dans l aspect statique et dynamique des LdP. L aspect statique est modélisé en utilisant les diagrammes de classes étendus par deux mécanismes de variabilité. Les diagrammes de séquence d UML, étendus par trois mécanismes de variabilité, sont utilisés pour modéliser l aspect dynamique. Nous avons défini ces mécanismes comme des extensions au méta-modèle UML ce qui facilite leur intégration dans un atelier UML. Notre contribution majeure à la modélisation de la variabilité concerne l aspect dynamique, peu traité jusqu à maintenant dans les travaux existant. La chapitre 5 a traité les contraintes de LdP. Nous avons identifié deux types de contraintes : d une part les contraintes génériques qui sont des règles structurelles assurant la cohérence de toute modélisation de LdP. D autre part les contraintes spécifiques qui spécifient les dépendances entre les points de variation dans un modèle de LdP. Nous avons proposé de formaliser les deux types de contraintes comme des contraintes OCL au niveau du méta-modèle d UML. Les chapitres 6 et 7 ont présenté la dérivation de produits. Nous avons considéré la dérivation de l aspect statique de produits ainsi que l aspect comportemental. Le diagramme de classes d un produit est obtenu par spécialisation de celui de la LdP. Pour la dérivation de comportements, nous avons proposé dans le chapitre 7 une approche algébrique qui dérive des machines à états d un produit à partir de diagrammes de séquence de la LdP. Cette approche de dérivation de comportements présente un double avantage : d une part elle supporte la variabilité des LdP et d autre part elle supporte les diagrammes de séquence d UML2.0. Notre approche de dérivation de comportements peut être utilisée en dehors du contexte des LdP. Il s agit d utiliser seulement l étape de génération de machines à états à partir de diagrammes de séquence d UML2.0 (voir notre travail dans [119]). Comme nous l avons présenté dans la section 1.4, l ingénierie de LdP s articule en deux niveaux : Ingénierie de domaine et Ingénierie d application (voir la Figure 1.1). Nos propositions pour la manipulation de LdP en UML peuvent être intégrés dans ces deux niveaux comme il est illustré dans la Figure 9.5. Au niveau ingénierie de domaine, des exigences génériques de la LdP sont définies comme un ensemble de diagrammes de séquence de base et une expression de référence (RESD-PL) comportant les constructions

156 de variabilité. L architecture statique de la LdP est modélisée comme un diagramme de classes contenant des points de variation. Au niveau de l ingénierie d application, la dérivation consiste à dériver automatiquement l architecture statique d un produit particulier et à synthétiser un ensemble de machines à états pour les objets de ce produit. Perspectives Fig. 9.5: Intégration dans les deux niveaux des LdP Amélioration de l approche de dérivation de comportements Comme mentionné dans la section 7.4.2, notre approche de dérivation de comportements présente certaines limites en particulier l absence de hiérarchie dans les machines à états synthétisées. Une perspective possible pour remédier à cette limite sera d étudier la possibilité d introduire la hiérarchie dans les machines à états à plats. Le travail de [104], réalisé dans l équipe Triskell, considère l introduction de la hiérarchie dans les machines à états à plats comme une étape de réusinage (ou refactoring). L intégration de cette étape dans notre approche de dérivation pourrait être une solution envisageable. Vers une chaîne complète pour la manipulation de LdP en UML Les tra-

157 vaux présentés dans cette thèse rentrent dans un cadre global initié par l équipe Triskell et basé sur l ingénierie des modèles. Il s agit de développer une plateforme et des méthodologies autour d UML pour la modélisation, le test et la validation de systèmes. La plateforme, basée sur MTL, est appelée UMLAUT NG [4] (UMALUT NG est la nouvelle version de UMLAUT [46]); nous envisageons de travailler sur l intégration du prototype PLiBS à cette plateforme. D autres perspectives consistent à implanter dans PLiBS un algorithme de déterminisation des machines à états et à le lier à un générateur de code. De produits aux LdP L approche que nous avons adopté dans ce document pour la manipulation de LdP en UML est une approche descendante. Les modèles de la LdP sont spécifiés en premier lieu et par la suite les modèles de produits sont obtenus par dérivation. Cependant, il existe actuellement des cas où un grand nombre de produits dans le même domaine sont modélisés séparément, c.à.d. sans prise en compte de la variabilité dès le départ. Une question peut être posée : peut-on envisager une approche ascendante pour la construction de la LdP à partir de ces produits? Ceci nous conduit à poser une autre question dans le contexte d UML sur l automatisation de la recherche des éléments communs et variables dans les modèles UML? Vers des patrons de comportement La discution autour de la synthèse dans le chapitre 7 a montré que dans certains modèles de communication et pour certains diagrammes de séquence il y a un risque de blocage et d incohérence dans les machines à états générées. Une piste de recherche intéressante à approfondir est d identifier tous les cas de diagrammes de séquence qui engendrent des incohérences et par la suite proposer des solutions sous forme de patrons réutilisables permettant de les résoudre au niveau des DS. Pour la situation du choix-non local (cf. section 7) par exemple, la solution sera d ajouter un ensemble de messages de synchronisation entre les objets du DS. Ces messages peuvent être définis dans un DS qui devient un patron de comportement réutilisable à chaque fois qu un choix non-local est détecté. L insertion du patron de comportement dans le DS origine pourrait se réaliser en utilisant le tissage d aspect dynamique [67, 66].

158

Annexes 159

Annexe A Les contraintes de LdP en MTL Nous décrivons ici la traduction des contraintes de LdP en MTL. Comme nous les avons présenté dans le chapitre 5, il existe deux types de contraintes : les contraintes génériques et les contraintes spécifiques. Nous avons défini une bibliothèque appelé PLConstraints contenant un ensemble de fonction MTL, une fonction pour chaque contrainte de LdP. Par exemple la fonction checkalldependencies() ci-dessus permet de vérifier que tous les dépendances UML dans un modèle de LdP vérifient la contrainte de dépendance définie dans la section 5.3.1. library PLConstraints ; model PL_model : R epos itory M odel ; model Product_model : R epos itory M odel /****************************************************/ /* La contrainte de dépendance */ /****************************************************/ checkalldependencies ( ) : Standard : : Boolean { ret : Standard : : Set ; dependencyiterator : Standard : : Iterator ; dependency : PL_model : : Core : : Dependency ; notfailed : Standard : : Boolean ; elementssupplier : PL_model : : Core : : Set ; elementsclient : PL_model : : Core : : Set ; ret := newset ( ) ; notfailed = true dependencyiterator :=! PL_model : : Core : : Dependency!. allinstances ( ). getnewiterator ( ) ; 161

162 Les contraintes de LdP en MTL dependencyiterator. start ( ) ; while dependencyiterator. ison () and notfailed.[=]( true ){ dependency := dependencyiterator. item ( ) ; elementssupplier := dependency. supplier ; elemntsclient := dependency. c l i e nt ; i f elementssupplier. exists (S : ModelElement S. isnotcommun (){ } notfailed := true ; } dependencyiterator. next ( ) ; return notfailed ; } /****************************************************/ /* La contrainte d héritage */ /****************************************************/ checkallgeneralizations ( ) : Standard : : Boolean { ret : Standard : : Set ; generalizationiterator : Standard : : Iterator ; generalization : PL_model : : Core : : Generalization ; notfailed : Standard : : Boolean ; classgeneral : PL_model : : Core : : Class ; c l a s s S p e c i f i c : PL_model : : Core : : Class ; ret := newset ( ) ; notfailed = true generalizationiterator :=! PL_model : : Core : : Generalization!. allinstances ( ). getnewiterator ( ) ; generalizationiterator. start ( ) ; while generalizationiterator. ison () and notfailed.[=]( true ){ generalization := generalizationiterator. item ( ) ; classgeneral := generalization. general ; c l a s s S p e c i f i c := generalization. s p e c i f i c ;

Les contraintes de LdP en MTL 163 } i f classgeneral. isnotcommun () and not c l a s s S p e c i f i c. isnotcommun { notfailed := true ; } generalizationiterator. next ( ) ; } return notfailed ; /**************************************************************/ /* La vérification de la présence d une classe dans un modèle */ /*************************************************************/ presenceclass (C: Product_model : : Core : : Class ) : Standard : : Boolean { iterator : Standard : : Iterator ; class : Product_model : : Core : : Class ; found : Standard : : Boolean ; c l a s s I t e rator :=! source_model : : Core : : Class!. allinstances ( ). getnewiterator ( ) ; classname : Standard : : String ; c l a s s I t e rator. start ( ) ; found:= f a l s e ; while i terator. ison ( ). and found.[=]( f a l s e ) { class := classiterator. item ( ). oclastype (! Product_model : : Core : : Class! ) ; classname:= class. name. oclastype (! Standard : : String! ) ; i f (C.. name. oclastype (! Standard : : String! ). [ = ] ( classname )) found:= true ; } iterator. next ( ) ; } return found ; /****************************************************/ /* La contrainte de présence */ /****************************************************/ checkpresenceconstraint (C1, C2: Product_model : : Core : : Class ) : Standard : : Boolean {

164 Les contraintes de LdP en MTL ret : Standard : : Boolean ; i f ( presenceclass (C1).[=]( true ). and presenceclass (C2 ).[=]( f a l s e )){ ret := f a l s e ; } e lse { ret := true ; } return ret ; } /****************************************************/ /* La contrainte d exclusion mutuelle */ /****************************************************/ checkexclusionconstraint (C1, C2 : Product_model : : Core : : Class ) : Standard : : Boolean { ret : Standard : : Boolean ; i f ( presenceclass (C1).[=]( true ). and presenceclass (C2 ).[=]( true )){ ret := f a l s e ; } e lse { ret := true ; } return ret ; }

Annexe B Le code de la dérivation de la LdP Mercure en MTL library PLDerivation ; model fullmercure : RepositoryModel ; model custommercure : R epos itory M odel ; model minimercure : R epos itory M odel ; model source_ model : R epos itory M odel ; main ( ) : Standard : : Void { // local variables mdrdriv er : MDRDriver : : MDRModelManager ; mdrdriver := new MDRDriver : : MDRModelManager ( ) ; mdrdriver. i n i t ( ) ; // intanciate the model, save result in another f i l e fullmercure := mdrdriver. getmodelfromxmi (.\\ MetaModel\\xmi_1.2\\01 02 15.xml, UML, FullMercure,.\\Uml1.4 Models\\MercurePL. xmi,.\\ DerivedProductModel \\ FullMercure. xmi ) ; custommercure : = mdrdriv er. getmodelfromxmi (.\\ MetaModel\\xmi_1.2\\01 02 15.xml, UML, CustomMercure, 165

166 Le code de la dérivation de la LdP Mercure en MTL.\\Uml1.4 Models\\MercurePL. xmi,.\\ DerivedProductModel \\CustomMercure. xmi ) ; minimercure : = mdrdriv er. getmodelfromxmi (.\\ MetaModel\\xmi_1.2\\01 02 15.xml, UML, MiniMercure,.\\Uml1.4 Models\\MercurePL. xmi,.\\ DerivedProductModel \\MiniMercure. xmi ) ; } Deriving FullMercure. toout ( ) ; source_model := fullmercure ; derivepl ( findclass ( FullMercure ) ) ; Deriving CustomMercure. toout ( ) ; source_ model : = custommercure ; derivepl ( findclass ( CustomMercure ) ) ; Deriving MiniMercure. toout ( ) ; source_ model : = minimercure ; derivepl ( findclass ( MiniMercure ) ) ; Derivation done.. toout ( ) ; /****************************************************/ /* La procédure principale de dérivation */ /****************************************************/ derivepl ( concretefactory : source_model : : Core : : Class ) { selectedvariants : Standard : : Set ; definedvariants : Standard : : Set ; feature : source_model : : Core : : Feature ; operation : source_model : : Core : : Operation ; operationiterator : Standard : : Iterator ; subclassesnames : Standard : : Set ; stereotypesnames : Standard : : Set ; c l a s s e s I t e r a t o r : Standard : : Iterator ; aclass : source_model : : Core : : Class ; name : Standard : : String ; classestodelete : Standard : : Set ;

Le code de la dérivation de la LdP Mercure en MTL 167 // Variant s election selectedvariants := newset ( ) ; operationiterator := concretefactory. feature. getnewiterator ( ) ; operationiterator. start ( ) ; while operationiterator. ison () { feature := operationiterator. item ( ). oclastype (! source_model : : Core : : Feature! ) ; i f feature. ocliskindof (! source_model : : Core : : Operation! ). and ( feature. name. substring (1, 4).[=]( new_ ) ) { operation := feature. oclastype (! source_model : : Core : : Operation! ) ; // finding a l l subtypes names of the return type subclassesnames : = collectm odelelements N ames ( allsubclasses ( getreturntype ( operation ) ) ) ; // finding a l l stereotypes names stereotypesnames := collectmodelelementsnames ( operation. stereotype. oclastype (! Standard : : Set! ) ) ; // retreiving variants to be selected definedvariants := subclassesnames. intersection ( stereotypesnames ) ; } //adding this result to the to keep variant l i s t i f definedvariants. isempty () { //no variant retreived means a l l variants are selected selectedvariants := selectedvariants. union ( subclassesnames ) ; } e lse { selectedvariants := selectedvariants. union ( definedvariants ) ; } } operationiterator. next ( ) ; classestodelete := newset ( ) ; classesiterator :=! source_model : : Core : : Class!. allinstances ( ). getnewiterator ( ) ; classesiterator. start ( ) ; while c l a s s es I t e r a t o r. ison () {

168 Le code de la dérivation de la LdP Mercure en MTL aclass := c l a s s e s I t erator. item ( ). oclastype (! source_model : : Core : : Class! ) ; name := aclass. name ; i f isstereotyped ( aclass, variant ). and( selectedvariants. excludes (name )) { subclassesnames : = collectm odelelements N ames ( allsubclasses ( aclass ) ) ; i f selectedvariants. excludesall ( subclassesnames ) { collectdelete ( aclass. generalization. oclastype (! Standard : : Set! ) ) ; collectdelete ( subgeneralizations ( aclass ) ) ; classestodelete := classestodelete. including ( aclass ) ; } } c l a s s es I t e r a t o r. next ( ) ; } collectdelete ( classestodelete ) ; optimizeinheritance ( ) ; } removeunusefullfactories ( concretefactory ) ; removeunusefullfactories ( concretefactory : source_model : : Core : : Class ) { superclasses : Standard : : Set ; ancestor : source_model : : Core : : Class ; } superclasses := collectdirectsuperclasses ( newset ( ). including ( concretefactory ) ) ; i f superclasses. s ize ().[ < >](0) { while superclasses. s ize ().[ < >](1) { superclasses := collectdirectsuperclasses ( superclasses ) ; } ancestor := superclasses. getnewiterator ( ). nextitem ( ) ; collectdelete ( allsubclasses ( ancestor ), new HasNotSubClassCondition ( ). inithasnotsubclasscondition ( concretefactory ) ) ; } findclass ( name : Standard : : String ) : source_model : : Core : : Class {

Le code de la dérivation de la LdP Mercure en MTL 169 a llclassesit : Standard : : Iterator ; aclass : source_model : : Core : : Class ; } a llclassesit :=! source_model : : Core : : Class!. allinstances ( ). getnewiterator ( ) ; a llclassesit. start ( ) ; while a l l C l a s s e s I t. ison () { aclass := a l l C lassesit. item ( ). oclastype (! source_model : : Core : : Class! ) ; i f aclass. name.[=]( name ) { return aclass ; } a l l C l a s s e s I t. next ( ) ; } throw Cannot find class named. concat (name ) ; getreturntype ( operation : source_model : : Core : : Operation ) : source_model : : Core : : Class { parameteriterator : Standard : : Iterator ; parameter : source_model : : Core : : Parameter ;! source_model : : Data_Types : : ParameterDirectionKind!. allinstances ( ) ; } parameteriterator := operation. parameter. getnewiterator ( ) ; parameteriterator. start ( ) ; while parameteriterator. ison () { parameter := parameteriterator. item ( ) ; i f parameter. kind. name.[=]( pdk_return ) { return parameter. type ; } parameteriterator. next ( ) ; } throw Cannot find return type of. concat ( operation. owner. name. oclastype (! Standard : : String! ) ). concat (. ). concat ( operation.name. oclastype (! Standard : : String! ) ) ; subgeneralizations ( clazz : source_model : : Core : : Class ) : Standard : : Set {

170 Le code de la dérivation de la LdP Mercure en MTL ret : Standard : : Set ; generalizationiterator : Standard : : Iterator ; generalization : source_model : : Core : : Generalization ; ret := newset ( ) ; generalizationiterator :=! source_model : : Core : : Generalization!. allinstances ( ). getnewiterator ( ) ; generalizationiterator. start ( ) ; while generalizationiterator. ison () { generalization := generalizationiterator. item ( ) ; i f generalization. parent.[=]( clazz ) { ret := ret. including ( generalization ) ; } generalizationiterator. next ( ) ; } } return ret ; allsubclasses ( clazz : source_model : : Core : : GeneralizableElement ) : Standard : : Set { ret : Standard : : Set ; generalizationiterator : Standard : : Iterator ; generalization : source_model : : Core : : Generalization ; ret := newset ( ) ; generalizationiterator :=! source_model : : Core : : Generalization!. allinstances ( ). getnewiterator ( ) ; generalizationiterator. start ( ) ; while generalizationiterator. ison () { generalization := generalizationiterator. item ( ) ; i f generalization. parent.[=]( clazz ) { ret := ret. including ( generalization. child. oclastype (! source_model : : Core : : Class! ) ) ; ret := ret. union ( allsubclasses ( generalization. child. oclastype (! source_model : : Core : : Class! ) ) ) ; } generalizationiterator. next ( ) ; }

Le code de la dérivation de la LdP Mercure en MTL 171 } return ret ; collectm odelelements N ames ( s e t : Standard : : Set ) : Standard : : Set { ret : Standard : : Set ; iterator : Standard : : Iterator ; element : source_ model : : Core : : ModelElement ; } ret := newset ( ) ; iterator := set. getnewiterator ( ) ; iterator. start ( ) ; while i terator. ison () { element := iterator. item ( ). oclastype (! source_model : : Core : : ModelElement! ) ; ret := ret. including ( element. name. oclastype (! Standard : : String! ) ) ; iterator. next ( ) ; } return ret ; collectdelete ( set : Standard : : Set ) { collectdelete ( set, new Condition ( ). initcondition ( true ) ) ; } class Condition { condition : Standard : : Boolean ; initcondition ( condition : Standard : : Boolean ) : Condition { s e l f. condition := condition ; return s e l f ; } } canremove( element : source_ model : : Core : : ModelElement ) : Standard : : Boolean { return condition ; } collectdelete ( set : Standard : : Set ; condition : Condition ) { ret : Standard : : Set ;

172 Le code de la dérivation de la LdP Mercure en MTL iterator : Standard : : Iterator ; element : source_ model : : Core : : ModelElement ; name : Standard : : String ; } iterator := set. getnewiterator ( ) ; iterator. start ( ) ; while iterator. ison () { element := i terator. item ( ). oclastype (! source_model : : Core : : ModelElement! ) ; i f condition. canremove( element ) { name := element. name ; i f isnull (name ). not () { \ t. concat (name ). concat ( removed ). toout ( ) ; } element. delete ( ) ; } iterator. next ( ) ; } isstereotyped ( clazz : source_model : : Core : : Class ; stereotypename : Standard : : String ) : Standard : : Boolean { stereotypeiterator : Standard : : Iterator ; stereotype : source_model : : Core : : Stereotype ; } stereotypeiterator := clazz. stereotype. getnewiterator ( ) ; stereotypeiterator. start ( ) ; while stereotypeiterator. ison () { stereotype := stereotypeiterator. item ( ). oclastype (! source_model : : Core : : Stereotype! ) ; i f stereotype. name.[=]( stereotypename ) { return true ; } stereotypeiterator. next ( ) ; } return f a l s e ; class HasNotSubClassCondition extends Condition { subclass : source_model : : Core : : GeneralizableElement ; inithasnotsubclasscondition ( subclass : source_model

Le code de la dérivation de la LdP Mercure en MTL 173 } : : Core : : GeneralizableElement ) : HasNotSubClassCondition { s e l f. subclass := subclass ; return s e l f ; } canremove( element : source_ model : : Core : : ModelElement ) : Standard : : Boolean { i f element. ocliskindof (! source_model : : Core : : GeneralizableElement! ) { return PLDerivation. allsubclasses ( element ). including ( element ). excludes ( s e l f. subclass ) ; } e lse { return true ; } } directsuperclasses ( clazz : source_model : : Core : : Class ) : Standard : : Set { ret : Standard : : Set ; generalizationiterator : Standard : : Iterator ; generalization : source_model : : Core : : Generalization ; ret := newset ( ) ; generalizationiterator := clazz. generalization. getnewiterator ( ) ; generalizationiterator. start ( ) ; while generalizationiterator. ison () { generalization := generalizationiterator. item ( ) ; ret := ret. including ( generalization. parent. oclastype (! source_model : : Core : : Class! ) ) ; generalizationiterator. next ( ) ; } } return ret ; collectdirectsuperclasses ( set : Standard : : Set ) : Standard : : Set { ret : Standard : : Set ; iterator : Standard : : Iterator ;

174 Le code de la dérivation de la LdP Mercure en MTL element : source_ model : : Core : : ModelElement ; } ret := newset ( ) ; iterator := set. getnewiterator ( ) ; iterator. start ( ) ; while iterator. ison () { element := i terator. item ( ). oclastype (! source_model : : Core : : ModelElement! ) ; ret := ret. union ( directsuperclasses ( element ) ) ; iterator. next ( ) ; } return ret ;

Annexe C L exemple de Guichetier automatique La Figure C.1 montre les diagrammes de séquence de base pour l exemple de guichetier automatique d une banque. L expression de référence qui les compose est l expression E ATM ci-dessus. E ATM = loop(userarrives seq ( loop( (EnterPassword seq BadPassword)) seq (EnterPassword seq (BadAccount alt (AccountOK seq (TransactionFailed alt TransactionSucceeded)) alt UserCancel))) alt UserCancel) 175

176 L exemple de Guichetier automatique Fig. C.1: Les diagrammes de séquence de base pour l exemple de guichetier automatique

Bibliographie [1] ESAPS project, http ://www.esi.es/esaps/, 1999. [2] CAFE project, http ://www.esi.es/en/projects/cafe/cafe.html, 2001. [3] FAMILIES project, http ://www.esi.es/en/projects/families/, 2003. [4] Inria model transformation language, http ://modelware.inria.fr, 2003. [5] M. Abdalla, F. Khendek, and G.Butler. New results on deriving sdl specifications from mscs. In G.Bochman & Y.Lahav editors R.Dssouli, editor, Proc. of 9th SDL forum, pages 51 66, 1999. [6] A. Aho, R. Sethi, and J. Ullman. ompilers : Principles, Techniques, and Tools. 1986. [7] M. Anastasopoulos and C. Gacek. Implementing Product Line Variabilities. Technical Report IESE Report No. 089.00/E, Version 1.0, IESE, November 2000. [8] C. Atkinson, J. Bayer, C. Bunse, E. Kamsties, O. Laitenberger, R. Laqua, D. Muthig, B. Paech, J. Wüst, and J. Zettel. Component-based Product Line Engineering with UML. Component Software Series. 2001. [9] C. Atkinson, J. Bayer, and D. Muthig. Component-Based Product Line Development : The KobrA Approach. In P. Donohoe, editor, First Software Product Line Conference (SPLC1), pages 289 309. Kluwer Academic Publishers, August 2000. [10] L. Bass, P. Clements, and R. Kazman. Software Architecture in Practices. Addison-Wesley, 1998. [11] D. Batory, R. Lopez-Herrejon, and J-P Martin. Generating product-lines of product-families. In Proc. Automated Software Engineering Conference (ASE 02), 2002. [12] J. Bayer. Introducing Separation of Concerns to Product Line Engineering. In GCSE 00 Young Researchers Workshop, 2000. [13] J. Bayer. Towards Engineering Product Lines Using Concerns. In Workshop on Multi-Dimensional Separation of Concerns in Software Engineering (ICSE 2000), June 2000. [14] A. Bertolino, A. Fantechi, S. Gnesi, G. Lami, and A. Maccari. Use Case Description of Requirements for Product Lines. In International Workshop on Requirement Engineering for Product Line (REPL02), pages 12 18, September 2002. 177

178 Bibliographie [15] A-W. Biermann and R. Krishnaswamy. Constructing programs from example computations. IEEE Transaction Software Engineering, 2(3) :141 153, September 1976. [16] G. Booch. Object Oriented Design with Applications. Benjamin Cummings, 1991. [17] J. Bosch, G. Florijn, D. Greefhorst, J. Kuusela, H. Obbink, and K. Pohl. Variability Issues in Software Product Lines. In Fourth workshop Product Familly Engineering (PFE4), pages 11 19, 2001. [18] F. Buschmann, R. Meunier, H. Rohnert, Peter Sommerlad, and Michael Stal. Pattern-Oriented Software Architecture : A System of Patterns. Wiley, 1996. [19] M. Clauß. Generic modeling using uml extensions for variability. In Workshop on Domain Specific Visual Languages at OOPSLA 2001, 2001. [20] M. Clauß. Modeling variability with uml. In GCSE 2001 Young Researchers Workshop, 2001. [21] P. Clements and L.Northrop. Software Product Lines : Practices and Patterns. Addison-Wisley, Boston, 2001. [22] M. Coriat, J. Jourdan, and F. Boisbourdin. The SPLIT Method : Building Product Lines for Software Intensive Systems. In First Software Product Line Conference (SPLC1), pages 147 166, 2000. [23] W. Damm and D. Harel. Lscs : Breathing life into message sequence charts. Formal Methods in System design, 19(1) :45 80, 2001. [24] E-M. Dashofy, André van der Hoek, and R. N. Taylor. An infrastructure for the rapid development of xml-based architecture description languages. In Proceedings of the 24th international conference on Software engineering, pages 266 276. ACM Press, 2002. [25] Groupe OFTA Ingénierie des modèles. L ingéniérie des modèles logiciels et systèmes. Number 30 in collection Arrago. OFTA, Paris, May 2004. [26] W.U. Eisenecker and K Czarnecki. Generative Programming : Methods, Tools, and Applications. Addison-Wesley, 2000. [27] W. El Elkaim. System family architecture glossary. Technical report, ESAPS Project, 2001. [28] A. Engels, S. Mauw, and M. Reniers. A hierarchy of communication models for message sequence charts. In T. Mizuno, editor, Proceedings of FORTE X and PSTV XVII, pages 75 90, 1997. [29] O. Flege. System Family Architecture Description Using the UML. Technical Report IESE-Report No. 092.00/E, IESE, December 2000. [30] O. Flege. Using a decision model to support product line architecture modeling, evaluation, and instantiation. In Proceedings of Product Line Architecture Workshop. The First Software Product Line Conference (SPLC1), pages 15 20, 2000.

Bibliographie 179 [31] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Pattern Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [32] T. Gehrke and T. Firley. Generative sequence diagrams with textual annotations. In Proceedings of the 9th GI/ITG-Workshop Formale Beschreibungstechniken füverteilte Systeme (FBT 99), pages 65 72. Herbert Utz Verlag, jun 1999. [33] H. Gomaa. Object Oriented Analysis and Modeling for Families of Systems with UML. In W. B. Frakes, editor, IEEE International Conference for Software Rreuse (ICSR6), pages 89 99, June 2000. [34] H. Gomaa. Modeling Software Product Lines with UML. In Peter Knauber and Giancarlo Succi, editors, International Workshop on Software Product Lines : Economics, Architectures, and Implications (SPLW2), pages 27 31, 2001. [35] H. Gomaa and M.E. Shin. Multiple-View Meta-Modeling of Software Product Lines. In IEEE International Conference on Engineering of Complex Computer Systems (ICECCS 02), page 238, 2002. [36] M.L. Griss. Implementing Product-Line Features by Composing Component Aspects. In First Software Product Line Conference (SPLC1), pages 271 288, 2000. [37] A. Le Guennec. Génie Logiciel et Méthodes Formelles avec UML : Spécification, Validation et Génération de tests. PhD thesis, École doctorale MATISSE, Universite de Rennes 1, June 2001. [38] A. Le Guennec, G. Sunyé, and J-M Jézéquel. Precise modeling of design patterns. In LNCS, editor, Proceedings of UML 2000, volume 1939 of LNCS, pages 482 496, 2000. [39] G. Halmans and K. Pohl. Communicating the variability of a software-product family to customers. Software and System Modeling, 2(1) :15 36, 2003. [40] D. Harel. Statecharts : A visual formalism for complex systems. Science of Computer Programming, 8(3) :231 274, 1987. [41] D. Harel. From play-in scenarios to code : An achievable dream. IEEE Computer, 34(1) :53 60, January 2001. [42] D. Harel and E. Gery. Executable object modeling with statecharts. In Proceeding of International Conference on Software Engineering (ICSE 1996), 1996. [43] D. Harel and H. Kugler. Synthesizing state-based object systems from lsc specifications. Int. J. of Foundations of Computer Science, 13(1) :5 51, 2002. [44] O. Haugen. Comparing uml2.0 interactions and msc-2000. In SAM 2004, volume LNCS. Springer-Verlag Berlin Heidelberg, 2004. [45] O. Haugen and K. Stolen. STAIRS-Steps to Analyze Interactions with Refinement Semantics. In UML Conference UML2003, pages 388 402, October 2003. [46] W.M Ho, J-M Jézéquel, A. Le Guennec, and F. Pennaneac h. UMLAUT : an extendible UML transformation framework. In Proc. Automated Software Engineering, ASE 99, Florida, October 1999.

180 Bibliographie [47] L. Hélouët. A simulation framework for message sequence charts. In 9th SDL Forum, SDL 99, June 1999. [48] L. Hélouët. Analyse des exigences des sytèmes répartis exprimées par des langages de scénarios. PhD thesis, Université de Rennes 1, 2000. [49] L. Hélouët and C. Jard. Conditions for synthesis of communicating automata from hmscs. In 5th International Workshop on Formal Methods for Industrial Critical Systems (FMICS), April 2000. [50] I-Logix. Rhapsody. http ://www.ilogix.com/products/rhapsody/index.cfm. [51] ITU-T. Z.120 : Message sequence charts (MSC), november 1999. [52] I. Jacobson, M. Christerson, P. Jonsson, and G. Övergaard. Object-Oriented Softaware Engineering : A Use Case Driven Approach. Addison-Wesley, 1992. [53] I. Jacobson, M. Griss, and. Jonsso. Software Reuse : Architecture Process and Organization for business Success. 1997 ACM Press New York, 1997. [54] M. Jaring and J. Bosch. Variability dependencies in product family engineering. In Proceedings of the Fifth Internationl Workshop on Product Familly Engineering (PFE-5), volume 2863 of LNCS. Springer Verlag, 2003. [55] J-M. Jézéquel. Object Oriented Software Engineering with Eiffel. Addison-Wesley, 1996. [56] J-M. Jézéquel. Object-oriented design of real-time telecom systems. In IEEE International Symposium on Object-oriented Real-time distributed Computing, ISORC 98, Kyoto, Japan, April 1998. [57] I. John and D. Muthig. Tailoring Use Cases for Product Line Modeling. In International Workshop on Requirement Engineering for Product Line (REPL02), pages 26 32, September 2002. [58] J-M. Jézéquel. Reifying configuration management for object-oriented software. In Proceedings of the 20th international conference on Software engineering, pages 240 249. IEEE Computer Society, 1998. [59] J-M. Jézéquel. Reifying variants in configuration management. ACM Transaction on Software Engineering and Methodology, 8(3) :284 295, July 1999. [60] J-M. Jézéquel. Model-driven engineering with contracts, patterns, and aspects. In Tutorial Program of AOSD 2003 : 2nd International Conference on Aspect- Oriented Software Development. ACM-IEEE, March 2003. [61] W. El Kaim. Managing variability in the lcat split/daisy. In Proceedings of Product Line Architecture Workshop. The First Software Product Line Conference (SPLC1), pages 21 32, 2000. [62] K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute (SEI), November 1990.

Bibliographie 181 [63] B. Keepence and M. Mannion. Using Patterns to Model Variability in Product Families. IEEE Software, pages 102 108, July/August 1999. [64] I. Khriss, M. Elkoutbi, and R. Keller. Automating the synthesis of uml statechart diagrams from multiple collaboration diagrams. In Proc. of UML 98 : Beyond the Notation, pages 115 126, 1998. [65] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J-M. Loingtier, and J. Irwin. Aspect-oriented programming. In ECOOP 97 Object- Oriented Programming 11th European Conference, 1997. [66] Jacques Klein, Benoit Caillaud, and Loic Hélouët. Merging scenarios. In 9th International Workshop on Formal Methods for Industrial Critical Systems (FMICS), Linz, Austria, oct 2004. [67] Jacques Klein and Noel Plouzeau. Transformation of behavioral models based on compositions of sequence diagrams. In Proceedings of Model-Driven Architecture : Foundations and Applications 2004 (MDAFA), page 255, Linkoping, Sweden, jun 2004. [68] O. Kluge, P.S. Kritzinger, and L. Lambert. Normal form for composition in message sequence charts (msc 96). In Teletraffic 97, 1997. [69] K. Koskimies, T. Systä, J. Tuomi, and T. Männistö. Automated support for modeling oo software. IEEE Software, 15 :87 94, Janu 1998. [70] I.H. Krüger. Distributed System Design with Message Sequence Charts. PhD thesis, Institut für Informatik, Ludwig-Maximilians-Universität München, July 2000. [71] I. Krüger, R. Grosu, P. Scholz, and M. Broy. From mscs to statecharts. In Franz J. Rammig, editor, Distributed and Parallel Embedded Systems. Kluwer Academic Publishers, 1999. [72] S. Leue, L. Mehrmann, and M. Rezai. Synthesizing room models from message sequence chart specifications. In Proceedings of 13th IEEE Conference on Automated Software Engineering, Honolulu, Hawaii, Octobre 1998. [73] R. Lopez-Herrejon and D. Batory. Using aspectj to implement product-lines : A case study. Technical report, University of Texas at Austin, Sept 2002. [74] A. Maccari and A. Heie. Managing infinite variability. In Jilles van Gurp and Jan Bosch, editors, Software Variability Management Workchop, number IWI preprint 2003-7-01, pages 28 34. Research institute of Mathematics and Computing Science of the university of Groningen, 2003. [75] A. Maccari and A-P. Tuvinen. System family architectures : Current challenges at nokia. In F. van der Linden, editor, IW-SAPF, volume LNCS, pages 107 115. Springer, 2000. [76] J. Magee. Behavioral analysis of software architectures using ltsa. In Proceeding of International Conference on Software Engineering (ICSE 1999), 1999.

182 Bibliographie [77] J. Magee and J. Kramer. Concurrency : State Models and Java Programs. John Wiley and Sons, 1999. [78] E. Mäkinen and T. Systä. Mas-an interactive synthesizer to support behavioral modeling. In Proceeding of International Conference on Software Engineering (ICSE 2001), 2001. [79] N. Mansurov and D. Zhukov. Automatic synthesis of sdl models in use case methodology. In G.Bochman & Y.Lahav editors R.Dssouli, editor, Proceedings of 9th SDL forum, pages 225 240, 1999. [80] Meta-Model. www.metamodel.com, web. [81] A.-F. Le Meur, J.L. Lawall, and C. Consel. Specialization scenarios : A pragmatic approach to declaring program specialization. Higher-Order and Symbolic Computation, 17(1) :47 92, 2004. [82] A-F. Le Meure. Approche Déclarative pour la spécialisation des programmes C. Ph.d, Université de Rennes1, 2002. [83] L. Monestel, T. Ziadi, and J-M. Jézéquel. Product line engineering : Product derivation. In Workshop on Model Driven Architecture and Product Line Engineering, associated to the SPLC2 conference, San Diego, August 2002. [84] K. Koskimies T. Männistö, T. Systä, and J. Tuomi. Sced : A tool for dynamic modeling object systems. Technical Report A-1996-4, University of Tampere, 1996. [85] L.M. Northrop. A framework for software product line practice -version 3.0. Web http ://www.sei.cmu.edu/plp/framework.html, Software Engineering Institute, 2002. [86] Object Management OMG. Uinified modeling language specification version 2.0 : Infrastructure. Technical Report ptc/03-09-15, OMG, 2003. [87] Object Management Group OMG. Meta object facility (mof). Technical Report OMG Document : ad/97-08-14, Sept 1997. [88] Object Management Group OMG. Analysis and design platforme task force - white paper on the profile mechanism. Technical report, OMG, April 1999. [89] Object Management Group OMG. Request for proposal uml 2.0 superstructure rfp. Technical Report OMG Document : ad/00-09-02, August 2001. [90] Object Management Group OMG. Request for proposal : Mof 2.0 queries / views/- transformations rfp. Technical Report OMG Document : ad/02-04-10, August 2002. [91] Object Management Group OMG. Uml profile for enterprise distributed object computing specification. Technical Report OMG Adopted Specification ptc/02-02-05, February 2002.

Bibliographie 183 [92] Object Management Group OMG. Uml profile for schedulability, performance, and time specification. Technical Report OMG Adopted Specification ptc/02-03- 02, March 2002. [93] Object Management Group OMG. Omg unified modeling language specification, version 1.5. Technical report, March 2003. [94] Object Management Group OMG. Uinified modeling language specification version 2.0 : Superstructure. Technical Report pct/03-08-02, OMG, 2003. [95] D.L Parnas. On the design and development of program families. IEEE Transactions on Software Engineering, SE2(1) :1 9, March 1976. [96] S. Pickin. Test des composants Logiciels pour les Télécommunications. PhD thesis, Université de Rennes 1, 2003. [97] Rambaugh and al. Modélisation et conception orientées objet. Masson, 1995. [98] M. Reniers and S. Mauw. High-level message sequence charts. In A. Cavalli and A. Sarma, editors, SDL97 : Time for Testing - SDL, MSC and Trends, Proceedings of the Eighth SDL Forum, pages 291 306, Evry, France, Septembre 1997. [99] S. Robak, R. Franczyk, and K. Politowicz. Extending the uml for modeling variability for system families. International Journal of Applied Mathematics Computer Sciences, 12(2) :285 298, 2002. [100] J. Rumbaugh, M. Blaha, F. Eddy, P. W., and W. Lorensen. Object Oriented Modeling and Design. Prentice Hall Inc. Englewood Cliffs, New Jersy, USA, 1991. [101] Softeam. Profiles uml et langage j : Controlez totalement le développement d application avec uml. White paper, 99. [102] R. Soley and the OMG Staff. Model-driven architecture. white paper, OMG Document, Nov 2000. [103] S.Uchitel, J.Kramer, and J.Magee. Synthesis of behavioral models from scenarios. IEEE Transaction on Software Engineering, 29(2) :99 115, February 2003. [104] G. Sunyé, D. Pollet, Y. Le Traon, and J-M. Jézéquel. Refactoring UML models. In Proceedings of UML 2001, volume 2185 of LNCS, pages 134 148. Springer Verlag, 2001. [105] M. Svahnberg and J. Bosch. Issues Concerning Variability in Software Product Lines. In F. van der Linden, editor, IWSAPF3, pages 146 157, 2000. [106] O. Tahir, J. Cardozo, and C.S. Blanc. Génération automatique des diagrammes d états-transitions uml à partir des diagrammes de séquence. In MSR 4eme Colloque Francophone sur la modélisation des systèmes réactifs, pages 505 520, 2003. [107] S. Uchitel and J. Kramer. A workbench for synthesising behaviour models from scenarios. In Proc. of International Conference on Software Engineering (ICSE 2001), 2001.

184 Bibliographie [108] S. Uchitel, J. Kramer, and J. Magee. Detecting implied scenarios in message sequence chart specifications. In proceedings of the 9th European Software Engineering Conferece and 9th ACM SIGSOFT International Symposium on the Foundations of Software Engineering (ESEC/FSE 01), September 2001. [109] F. van der Linden. Software Product Families in Europe : The Esaps and Café Projects. Software, 19(4) :41 49, July/August 2002. [110] T. van der Maßen and H. Lichter. Modeling Variability by UML Use Case Diagrams. In International Workshop on Requirement Engineering for Product Line (REPL02), pages 19 25, September 2002. [111] R. van Ommering, F. van der Linden, J. Kramer, and J. Magee. The Koala Component Model for Consumer Electronics Software. IEEE Computer, pages 78 85, March 2000. [112] J. Warmer and A. Kleppe. The Object Constraint Language-Precise Modeling with UML. Object Technology Series. Addison-Wesley, 1998. [113] D.L. Webber. The Variation Point Model For Software Product Lines. Ph.d, George Mason University, George Mason University Fairfax, VA, Fall Semester 2001 2001. [114] D.L. Webber and H. Gomaa. Modeling Variability with the Variation Point Model. In C. Gacek, editor, International Conference on Software Reuse (ICSR 02), pages 109 122. LNCS, 2002. [115] M.D. Weiss and C.T. Robert Lai. Software Product-Line Engineering : A Family- Based Software Development Process. Addison-Wisley, 1999. [116] J. Whittle, J. Saboo, and R. Kwan. From scenarios to code : An air trafic control case study. In Proceeding of International Conference on Software Engineering (ICSE 2003), 2003. [117] J. Whittle and J. Schumann. Generating statechart designs from scenarios. In Proceeding of International Conference on Software Engineering (ICSE 2000), 2000. [118] T. Ziadi, L. Hélouët, and J-M. Jézéquel. Behaviors generation from product lines requirements. In International Workshop Workshop on Software Architecture Description and UML at UML2004, October 2004. [119] T. Ziadi, L. Hélouët, and J-M. Jézéquel. Revisiting statecharts synthesis with an algebraic approach. In International Conference on Software Engineering, ICSE 26, Edinburgh, Scotland, United Kingdom, May 2004. [120] T. Ziadi, L. Hélouët, and J-M. Jézéquel. Modeling behaviors in product lines. In Proceedings of REPL 02 (workshop on Requirements Engineering for Product Lines), Essen, Germany, September 2002. [121] T. Ziadi, L. Hélouët, and J-M. Jézéquel. Modélisation de lignes de produits en UML. In Proc. of LMO 2003, Langages et Modèles à Objets, Vannes, France, Fev. 2003.

Bibliographie 185 [122] T. Ziadi, L. Hélouët, and J-M. Jézéquel. Towards a uml profile for software product lines. In Proceedings of the Fifth Internationl Workshop on Product Familly Engineering (PFE-5), volume 3014 of LNCS, pages 129 139. Springer Verlag, 2003. [123] T. Ziadi, J-M. Jézéquel, and F. Fondement. Product line derivation with uml. In Proceedings Software Variability Management Workshop, Univ. of Groningen Departement of Mathematics and Computing Science, February 2003.