THÈSE. Manipulation de Lignes de Produits en UML

Transcription

1 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

2

3 Table des matières Introduction 17 I État de l art 23 1 Les Lignes de Produits Logiciels Introduction Des familles de programmes aux Lignes de produits Une approche adoptée dans l industrie L ingénierie de Domaine et d Application Ingénierie du domaine Ingénierie d application La variabilité logicielle Les dimensions de la variabilité Les points de variation La variabilité au niveau de l implantation Les contraintes Conclusion UML pour la modélisation de Ligne de Produit Introduction Unified Modeling Language (UML) Une sémantique à base de méta-modélisation Les contraintes OCL Les diagrammes Extensibilité Ingénierie des modèles État de l art sur la modélisation de LdP en UML Modélisation de la variabilité dans les modèles UML Gestion des contraintes Le support de la dérivation des modèles de produits Synthèse

4 4 Table des matières 2.4 Une approche dirigée par les modèles Spécification de comportement dynamique des systèmes Introduction Les scénarios : la vue inter-objets Les diagrammes de séquence d UML1.x Les diagrammes de séquence d UML Les interactions Les mécanismes de composition Message Sequence Charts Les machines à états : la vue intra-objet Des scénarios aux machines à états Motivations État de l art sur les travaux existant Comparaison de comportement Conclusion La Modélisation de la Variabilité Introduction La ligne de produit banque Modélisation de l aspect statique des LdP La variabilité Définition des extensions Exemple Modélisation de l aspect dynamique des LdP La variabilité Définition des extensions Exemple Vers un profil UML pour les LdP Spécification algébrique des diagrammes de séquence des LdP Expressions de Référence Expressions de Référence des LdP Exemple Conclusion La Modélisation des Contraintes de LdP Introduction Les contraintes OCL au niveau méta-modèle Les contraintes génériques des LdP La contrainte de dépendance La contrainte d héritage Les contraintes spécifiques des LdP

5 Table des matières La contrainte de présence La contrainte d exclusion mutuelle Conclusion II Dérivation de produits Dérivation de modèles statiques des produits Introduction La LdP Mercure Dérivation de produits De modèle de LdP aux modèles de Produits Dérivation Implantation en MTL Prise en compte des contraintes dans la dérivation Conclusion Dérivation de comportements Une Approche Algébrique Dérivation des expressions de produits Modèles de décision Dérivation Des expressions de produits aux machines à états Un cadre algébrique pour les machines à états Opérateurs de composition Expressions de référence des machines à états Génération des machines à états Diagrammes de séquence de base Diagrammes de séquence combinés Évaluation de l approche Avantages Limites Discussion autour de la synthèse Vues Inter-objet et intra objet Le rôle de la synthèse Conclusion Application et validation Les projets CAFE et FAMILIES L outil prototype PLiBS Études de cas

6 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

7 Table des figures 1.1 L ingénierie de lignes de produits Exemple d un diagramme de caractéristiques FODA La dimension espace et temps dans la variabilité L architecture à quatre niveaux de l OMG Le diagramme de cas d utilisation d une application bancaire Extrait d un diagramme de classes d une application bancaire Exemple de spécification d un profil UML2.0 et son utilisation Les transformations de modèles Exemple d un diagramme de séquence d UML1.x et ses concepts Le branchement conditionnel dans les diagrammes de séquence d UML1.x Une partie de méta-modèle des interactions dans UML Une partie du méta-modèle des diagrammes de séquence d UML Exemple d un DS dans UML2.0 et ses concepts Exemple des références vers les DS dans UML Exemple d un diagramme de séquence combiné Exemple d un diagramme de vue d ensemble d interaction dans UML Exemples de basic MSC Exemple d une inline-expression Exemple d un HMSC Exemple de machine à états Variation dans un diagramme de classes Extrait du méta-modèle d UML des classes Exemple d une variation où une classe variante est associée à deux points de variation Le diagramme de classes de la LdP banque Exemple d une interaction combinée référençant une interaction optionnelle Exemple d une interaction variation Exemple d une interaction combinée référençant une interaction virtuelle Les interactions de base dans la LdP banque L interaction combinée de la LdP banque avec la variabilité

8 8 Table des figures 4.10 Les extensions d UML pour la modélisation des LdP Les contraintes génériques dans les LdP Exemple de dépendance d utilisation dans un modèle de LdP Les dépendances dans le méta-modèle d UML Exemples d héritages dans des diagrammes de classes de LdP La généralisation dans le méta-modèle d UML Les contraintes spécifiques dans les LdP La méta-classe Model dans le méta-modèle d UML Exemple d un diagramme de classes d une LdP Exemple d un diagramme de classes d un produit dérivé Le diagramme de caractéristiques de la LdP FODA Le diagramme de classes UML de la LdP Mercure La structure du patron de conception Fabrique Abstraite La fabrique abstraite dans la LdP Mercure La fabrique abstraite étendue avec des stéréotypes pour la LdP Mercure Le modèle obtenu pour le produit CustomMercure Le diagramme de séquence combiné du produit BS Exemple de machines à états à plats Exemple d application de l opérateur seq s Exemple d application de l opérateur loop s Exemple d application de l opérateur alt s Le DS de base Deposit dans la LdP banque Exemple de la synthèse d une machine à états à partir d un DS de base Les machines à états de base de l objet Bank De seq à seq s De alt à alt s De loop à loop s La machine à états pour l objet Bank dans le contexte de produit BS La machine à états pour l objet Bank dans le contexte de produit BS Exemple d une machine à états non-déterministe Exemple d un diagramme de séquence engendrant de blocage pour la diffusion Exemple d un DS avec un choix non-local Les machines à états générées à partir de DS de la Figure Les relations entre le comportement des scénarios et celui de machines à états Exemple de spécification de RESD-PL dans PLiBS L instantiation du modèle de décision dans PLiBS La synthèse des machines à états dans PLiBS

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

10

11 Liste des tableaux 2.1 Exemple d un modèle de décision de KobrA Table récapitulative des travaux existant autour de la manipulation des LdP avec UML Les membres de la LdP banque Les règles de base pour la représentation des DS en RESD Les instances du modèle de décision de la LdP banque 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

12

13 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 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 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é.

15 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 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

17 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 18 Introduction

19 Première partie État de l art 19

20

21 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 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

23 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 L ingénierie de Domaine et d Application 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.

25 Les Lignes de Produits Logiciels 25 Fig. 1.2: Exemple d un diagramme de caractéristiques FODA 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 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 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é

27 Les Lignes de Produits Logiciels 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 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 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-

29 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 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 Conclusion

31 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 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 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.

33 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 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