Environnement pour l’ingénierie des lignes de produits logiciels

Télécharger le fichier pdf d’un mémoire de fin d’études

L’ingénierie de domaine

Cette phase permet de gérer une ligne de produits ogiciels dans sa globalité et non pas comme un ensemble de produits séparés où chaque produit est traité indépendamment des autres. La ligne de produits logiciels doit alors inclure les besoins spécifiés par toutes les catégories d’utilisateurs visées.
Dés lors, il est possible de définir la portée dea lligne de produits logiciels, c’est-à-dire l’ensemble des produits planifiés. La définition des membres de la famille de produits planifiée permet d’identifier et de planifier l’implémentation des points communs réutilisables ainsi que les points de différence entre eux. C’est ainsi que cette phase adopte la stratégie de développement pour la réutilisation. En effet, lesartéfacts logiciels communs définis, comme par exemple les exigences, les composants et les classes, sont construits de façon à ce qu’ils soient réutilisés dans les produits planifiés.
Pour accomplir ces objectifs, l’ingénierie de domaine est composée de quatre activités qui sont l’analyse de domaine, la modélisation de domaine, l’implémentation de domaine et le test de domaine.
– Analyse de domaine : l’analyse de domaine inclut l’ingénierie des exigences du domaine. En effet, les exigences sont analysées pour identifiercelles qui sont communes à tous les produits et celles qui sont spécifiques à des produits bien particuliers.
– Modélisation de domaine : cette activité s’intéresse à la définition de l’architecture de la ligne de produits logiciels. Cette architecture donne une vue structurelle sur les différents membres de la ligne de produits logiciels. Cette activité doit alors inclure les mécanismes de variabilité utilisés et identifier les parties réutilisables de l’architecture.
– Réalisation (implémentation) de domaine : les différentes parties réutilisables de l’architecture sont détaillées et implémentées dansdes composants logiciels réutilisables.
– Test de domaine : cette activité est responsable de la validation et la vérification des composants réutilisables obtenus à l’issue de l’activité précédente. Les tests effectués sur les composants se font par rapport à leur conformité aux spécifications données dans les exigences, l’architecture et les artéfacts de modèle.

L’ingénierie d’application

Cette phase permet d’obtenir les produits concrets à partir des artéfacts identifiés dans la phase d’ingénierie de domaine. La stratégie adoptéeà ce niveau se base sur le développement avec réutilisation. En effet, cette phase a comme but de maximiser le taux de réutilisation des artéfacts définis et développés pour un produit bien spécifique de la ligne de produits. Les points communs et les points de différence doivent ainsi être exploités pour la construction des produits. La construction de ces produits est appelée dérivation de produits. Elle consiste à sélectionner les artéfacts qui seront présents dans un produit donné. Comme pour l’ingénierie de domaine, l’ingénierie d’application est composée de quatre activités à savoir ingénierie des exigences d’application, la modélisation d’application, l’implémentation d’application et le test d’application.
– Ingénierie des exigences de l’application : elle s’intéresse à désigner les exigences spécifiques aux produits souhaités. Ces exigences ont un impact direct sur les artéfacts du domaine qui seront réutilisés dans la constructiondu produit.
– Modélisation de l’application : elle permet d’obtenir l’architecture du produit à partir de l’architecture globale définie pendant la modélisation du domaine. Pour ce faire, les parties requises du modèle sont sélectionnées et incorporées.
– Réalisation (implémentation) de l’application : cette activité consiste à la réalisation du produit concret souhaité. Les composants qui correspondent aux parties sélectionnées dans l’étape précédente sont alors assemblés.
– Test de l’application : cette activité valide et vérifie que le produit obtenu à l’issue de l’activité précédente est conforme aux exigences, àl’architecture et aux parties du modèle sélectionnés.
La modélisation des lignes de produits facilite ains la réutilisation des concepts manipulés. Plusieurs approches dirigées par les modèles s’intéressent au développement et à la maintenance des lignes de produits logiciels. Cependant, la modélisation demeure une tâche complexe voir irréalisable pour les lignes de produits logiciels complexes et à très grande échelle [20]. C’est ainsi qu’est venue l’idée de distribuer la tâche de modélisation sur plusieurs équipes, chacune travaille sur un modèle partiel. Chaque fragment de modèle représente une vue partielle du modèle global de laligne de produits qui doit être obtenu par composition des fragments de modèles qui le constituent.
La composition de modèles de lignes de produits logiciels renforce la réutilisation et permet d’obtenir de nouveaux modèles de lignes de produits logiciels. Cependant cette tâche est loin d’être facile ou évidente, d’autant plus qu’il s’agit de modèles intégrant des éléments variables. La variabilité est donc un point principal à gérer durant la composition de ces modèles, d’où l’intérêt d’investir dans des travauxde recherche à ce sujet [5]. La sous section suivante présente le rôle joué par la variabilité ansd le contexte des lignes de produits logiciels.

La variabilité : concept clé dans l’ingénier des lignes de produits logiciels

Dans le contexte des lignes de produits logiciels, la notion de variabilité permet le développement des produits configurés par réutilisation des artéfacts prédéfinis et ajustables. Elle est modélisée au niveau de la phase d’ingénier de domaine pour représentés les différences entre les produits planifiés.
Plusieurs définitions on été attribuées à la variabilité. Par exemple, Weiss et Lai définissent la variabilité comme « une hypothèse sur la façon dont les membres d’une famille peuvent se différencier entre eux »[12]. Ceci explique le rôle que joue la variabili té dans l’adaptation des produits aux besoins spécifiques des catégories d’utilisateurs visées, pendant que les besoins communs sont présents et partagés par tous les membres de la ligne de produits.
La variabilité a aussi été classée en deux typesla: variabilité temporelle et la variabilité spatiale. Pohl et al. ont défini la variabilité temporelle comme « l’existence de différentes versions d’un artéfact qui sont valides à des moments différents » et la variabilité spatiale comme « l’existence d’un artéfact sous différentes formesen même temps »[14]. Cependant, la variabilité spatiale reste la plus traitée dans lapratique de l’ingénierie des lignes de produits logiciels. La variabilité représente ainsi un concept clé dans l’ingénierie des lignes de produits logiciels et doit être gérée tout au long du processus de développement. La composition des modèles de lignes de produits logiciels doit alors prendre en compte la variabilité des éléments de modèles et la gérer. Ceci complique d’autant plus le mécanisme de composition. La section suivante donne un aperçu sur les modèles utilisés pour représenter les lignes de produits logiciels. Elle se focalise sur les mécanismes de composition fournis et analyse leurs propositions pour gérer la variabilité durant la composition. D’autres critères d’analyse sont aussi considérés à savoir la gestion des structures de modèles, leurs consistances, les contraintes de variabilité ainsi que la sémantiquede la composition.

Modélisation et composition des lignes de produits logiciels

Pendant le développement des lignes de produits logiciels, le concepteur se trouve en face d’une multitude d’éléments à gérer. Pour faciliterla manipulation de ces éléments, il est important de les modéliser. Il s’agit de représente une abstraction des éléments appartenant à la ligne de produits étudiée pour diminuer leur complexité. Kramer a définit le but de l’abstraction par [5]:
« la traçabilité des correspondances à partir d’une représentation d’un problème vers une autre représentation qui préserve certaines propriét s souhaitées et qui réduit la complexité » Dans le contexte des lignes de produits logiciels, un modèle représente une abstraction de la ligne de produits logiciels considérée. Dans cettesection, nous distinguons trois catégories d’approches pour la modélisation et la composition des lignes de produits logiciels. Nous présentons pour chaque catégorie, une brève description des modèles utilisés pour la représentation des lignes de produits logiciels ainsi que les approches qui les adoptent. Ensuite une analyse détaillée est présentée pour s lemécanismes de composition proposés dans chacune des trois catégories. Cette analyse présente certains travaux pertinents et discute leurs avantages et inconvénients durant la composition des modèles de lignes de produits logiciels.

Approches des modèles de caractéristiques

Modélisation

Commençons d’abord par définir ce qu’est une caractéristique ou Feature. Dans la littérature, plusieurs définitions ont été données au concept de Feature [1][26][27][2][28][29][30][31][32][33]. Nous citons par exemple la définition donnée par Kang [1] qui considère qu’une Feature est : « tout aspect important et distinctif ou caractéristique visible par les diverses parties prenantes », comme l’utilisateur final, l’expert du domaine, etc…
Les diagrammes de caractéristiques fournissent unereprésentation explicite et concise de la variabilité. Ils représentent les choix à faire pourdéterminer les caractéristiques des produits envisagés [1][2]. Il s’agit d’une description graphique sous forme d’une hiérarchie des exigences d’une ligne de produits logiciels.
Plusieurs approches ont proposé de modéliser les lignes de produits logiciels par des modèles de caractéristiques à commencer par l’approche FODA (Feature Oriented Domain Analysis) de Kang [1]. Cette approche a pour objectif de capturer les points communs et les points de différences au niveau exigence. La caractéristiqueracine représente la ligne de produits logiciels, comme la caractéristique Security dans l’exemple de la figure 2.3. Cette caractéristique est décomposée en sous-caractéristiques qui sont elles aussi décomposées jusqu’à atteindre les caractéristiques feuilles. Des symboles graphiques spécifiques permettent de distinguer les caractéristiques obligatoires de celles optionnelles. Comme le montre l’exemple de la figure 2.3, la caractéristique OutsideDetection est obligatoire tandis que la caractéristique Alarm est optionnelle. Les relations entre les caractéristiques sont elles aussi représentées par des symboles graphiques comme parexemple la relation or représentée dans la figure pour spécifier que la caractéristiqueSensing peut être réalisée via un détecteur infra-rouge InfraredDetector, un détecteur volumétriqueVolumetricDetector ou bien les deux ensemble. L’alarme par contre peut être silencieuse, sous forme de sirène ou bien visuelle mais pas les trois ensemble. D’autre contraintes dites transversales de types inclusion, exclusion sont considérée par l’approche. Les contraintes d’une ligne de produits définissent les produits logiciels valides qui peuvent être obtenus.

Approches dirigées par les modèles annotatrices de variabilité

Modélisation

Certaines approches de développement de lignes de produits logiciels utilisent des annotations pour identifier les éléments variables dans le modèle. Nous distinguons les approches qui représentent les lignes de produits logiciels par le biais de modèles UML [11]. Plusieurs approches dirigées par les modèles utilisent des stéréotypes UML pour annoter les éléments variables qui appartiennent aux modèles de lignes de produits logiciels [3][21][22][23][4].
Par exemple, Clauss [21][24] propose un profil UML pour permettre l’expression de la variabilité dans les modèles UML qui représentent esd lignes de produits logiciels. Ce profil indique que tout élément du modèle peut faire l’objet d’un point de variation. Un point de variation localise la variabilité dans un modèle et ses différentes réalisations décrivent plusieurs variantes. Le point de variation contient plusieurs variantes qui déterminent les caractéristiques de la variabilité. Une variante est toujours attachée à un point de variation. Le point de variation implique plusieurs valeurs étiquetées pour déterminer le moment de la réalisation du point de variation et la cardinalitédes variances ainsi que le nombre de variances qui lui correspondent. Le stéréotype optional«» indique qu’un élément peut être supprimé dans le modèle dérivé.
Dans le travail de Ziadi [22] en plus de l’utilisation du modèle de caractéristiques, cette approche utilise des extensions d’UML pour modéliser la variabilité au niveau structurel grâce à deux mécanismes à savoir l’optionalité et la variation ainsi qu’au niveau comportemental moyennant trois mécanismes qui sont l’optionalité,la variation et la virtualité. Au niveau structurel (aspect statique) par exemple deux stéréotypes sont proposés:
– L’optionalité: par l’utilisation du stéréotypeoptional«» ce qui signifie que certaines propriétés sont optionnelles dans certains produitset donc elles peuvent être supprimées. L’optionalité n’est pas modélisée au niveau des associations entre les classes car une classe optionnelle signifie que toutes les associations auxquelles elle participe sont aussi optionnelles. L’optionalité d’une classe s’étend rsutous ses attributs et ses opérations, idem pour un paquetage optionnel dont l’optionalité s’étend sur tous ses éléments.
– La variation: par l’introduction des stéréotypes «variation» et «variant» associés respectivement aux classes abstraites et aux sous-classes concrètes.
– L’optionalité: par l’introduction du stéréotypeoptionalLifeline«» qui s’applique sur les messages reçus et envoyés des objets optionnels dans le diagramme de séquence. Le stéréotype optionalInteraction«» spécifie l’optionalité des interactions.
– La variation: par l’introduction du stéréotype variation«» appliqué sur une interaction qui référence un ensemble de sous-interactions stéréotypées «variant».
– La virtualité: par l’introduction du stéréotype virtual«» qui une fois appliqué sur une interaction, signifie que le comportement de celle-ci peut être redéfini par une autre interaction de raffinement associée à un produit particulier. 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. Kobra [3] est basée sur les composants. On ne parleplus de modèle de caractéristiques mais plutôt d’arbre de composants dont le composant raci ne représente le système et les sous composants représentent les éléments constitutifs udsystème. Elle utilise un seul stéréotype «variable» pour marquer les éléments variables de type paquetage, classe, attribut, opération, transition et interaction. Au niveau statique, l’approche traite les diagrammes de classes, au niveau comportemental (dynamique), les diagrammes de séquences et machine à états. L’approche introduit un modèle de décisions qui remplace le rôle du diagramme de caractéristiques et qui est construit à partir du modèle de famille de systèmes et des spécifications de l’ensemble des systèmes visés. Pour chaque décision le concepteur doit choisir une résolution qui affecte alors le modèlede famille de systèmes sous-jacent et peut renvoyer l’utilisateur vers de nouvelles décisions.
L’approche SEQUOIA (précédemment nommée SyF) [25] tiliseu le diagramme de caractéristiques pour la capture des exigences. Elle offre le moyen d’exprimer la variabilité au niveau du modèle UML de la ligne de produits logiciels grâce au stéréotype «VariableElement» (annexe A). Les contraintes de variabilité sont exprimées pour identifier les produits logiciels valides qui peuvent être obtenus à partir du modèle de la ligne de produits logiciels. Nous citons à titre d’exemple un e contrainte d’implication entre deux éléments variables (annexe A):
Implication (elem1, elem2) : une contrainte de type Implication spécifie que la présence de l’élémentelem1 dans un produit valide implique la présence de l’élémentelem2 dans le même produit valide de la ligne de produits et inversement.

Consolidation de modèles de lignes de produits logiciels

Sachant qu’une ligne de produits est modélisée sousune vue de structure composite, le respect des contraintes de variabilité spécifiées ste nécessaire mais pas suffisant. Des contraintes supplémentaires relatives à l’aspect structurel de la ligne de produits doivent être créées et respectées en plus des contraintes déjàpécifiées afin d’assurer la réalisation des options de la ligne de produits. Si un modèle de ligne de produits respecte uniquement les contraintes de variabilité sans considérer les propriétés structurelles engendrées par la présence de la variabilité dans le modèle, les modèles de produit résultants seront structurellement incomplets et par conséquent non capables de réaliser les fonctionnalités qui leurs sont attribuées.
La ligne de produits Security dont le modèle est présenté dans la figure 3.1 doit respecter les contraintes C1, C2, C3 et C4 associées à ses éléments variables. La résolution deces contraintes donne l’ensemble des produits valides. La figure 3.2 représente un modèle de produit de la ligne de produits Security valide du point de vue des contraintes C1, C2, C3 et C4. Ce modèle indique que le produit comporte les parts detector et alarm ainsi que leurs différents ports. Par exemple la figure 3.2 montre que les options de sirène et d’alarme visuelle sont présentes via les ports respectifs siren et visual. De même pour les options de détection représentées par les portscamControl, vFlow, cZoom et infraredDetector. Le port alarmEn est présent dans le modèle de produit pour permettre la réception de l’énergie.
Le modèle de produit illustré ci-dessous est valide en terme de contraintes utilisateur. Cependant, la classe composite Security, telle que spécifiée dans la figure 3.2, est incapable d’assurer ses fonctionnalités d’alarme et de détection: sa structure incomplète. En effet, l’absence des ports externes, camControlSec, vFlowSec, cZoomSec et infraredDetectorSec, empêche la classeSecurity de communiquer avec l’environnement extérieur pour réaliser les fonctions de détection. De même pour les ports externes sirenSec et visualSec sont absents du modèle de produit ce qui empêche la classeSecurity de communiquer avec l’environnement extérieur pour réaliser les fonctions d’alarme. De plus, l’absence de ces ports externes entraine l’absence des connecteurs qui les relient à leurs ports respectifs. D’autre part l’absence du port alarmController via lequel la part securityManager doit gérer la part alarm engendre l’isolation de celle-ci et empêche donc decontrôler son fonctionnement ainsi que son énergie.

Démarche de fusion : aperçu global

La figure 4.3 donne un aperçu global sur la démarche de fusion proposée. Nous distinguons trois principales phases : la première phase, appelée phase de consolidation, a pour objectif d’assurer que les modèles en entrée soient structurellement cohérents et complets. Nous utilisons pour cet objectif un ensemble de règles de consolidation, qui une fois appliqué aux modèles en entrée, permet d’obtenir des modèles consolidés et prêts à être fusionnés. La deuxième phase, nommée phase de fusion, met en œuvre les différents traitements effectués pour la fusion des modèles de lignes de produits. A l’issue de cette phase, nous obtenons un modèle fusionné qui doit passer par une seconde phase de consolidation au court de laquelle les mêmes règles de consolidation seront à nouveauappliquées afin d’aboutir à un modèle de fusion consolidé.

Propriété sémantique de l’agrégation

La définition des propriétés sémantiques de l’agrégation se base sur la relation entre l’ensemble des systèmes valides obtenus à partir du modèle d’agrégation résultant et l’ensemble des systèmes valides obtenus à partir de s modèles en entrée.
Plus précisément, le résultat de l’agrégation doitsatisfaire la propriété suivante :
Un système valide obtenu du modèle d’agrégation résultant représente l’assemblage de systèmes valides dont chacun est obtenu à partir de l’un des modèles en entrée.(PAg)
Nous présentons dans la suite deux propositions pour réaliser l’agrégation des modèles de lignes de produits tels que la propriété(PAg) est satisfaite.

Proposition1

La première alternative suppose que toutes les connexions identifiées entre les éléments externes des modèles de lignes de produits en entré sont obligatoires. Elles doivent être établies automatiquement. Pour ce faire, la proposition1 s’intéresse à gérer les ports variables des classes composites représentant les modèles d’entrée en se basant sur un ensemble de règles d’agrégation.

Règles d’agrégation

Règle 1 : Si deux ports sont connectables (hypothèse) et qu’ils doivent être connectés, et si l’un des deux ports est variable alors une contrainte doit être créée pour assurer que le port variable soit présent pour établir la connexion.
C’est par exemple le cas du port variable vFlowSec attaché à la classe composite Security et qui est connecté au port obligatoirevideoFlowC attaché à la classe composite Camera.
Règle 2 : Si deux ports simples sont connectables (hypothèse) et qu’ils doivent être connectés, et si les deux ports sont variables alors une contrainte doit être créée pour assurer que chacun des ports soit présent pour établir la connexion.
Par exemple le port variable cZoomSec attaché sur la classe composite Security est connecté au port variable zoomInstructC attaché sur la classe compositeCamera.
Règle 3 : Si deux ports variables sont connectables (hypothèse) et qu’ils doivent être connectés, et si au moins un des deux ports est multiple alors une contrainte doit être créée pour assurer que la présence du port non multiple (ou multiple si les deux ports sont multiples) dans tous les systèmes valides implique celle du port multiple.
Prenons l’exemple du port variable camEnergy attaché sur la classe compositeCamera et qui est connecté au port variable multiplecamControlSec attaché sur la classe compositeSecurity.
Algorithme d’agrégation :
Nous proposons un algorithme d’agrégation des modèles de lignes de produits en entrée représentés sous une vue de structure composite. L’algorithme AlgorithmeP1 implémente les règles d’agrégation précédemment décrites pour la oposition1r et montre comment les contraintes d’agrégation sont ajoutées afin d’assurer les connexions entre les ports externes des classes composites telles que la propriété(PAg) est respectée. Pour illustrer l’exécution de cet algorithme, nous continuons avec l’exemple de la figure 5.10.
L’algorithme AlgorithmeP1 prend en entrée la liste des connexions Connexions obtenue à l’issue de l’étape d’assemblage. Chaque connexion est définie par les deux ports connectés ainsi que par le lien de connexion choisi pour l’établir, qui peut être un connecteur par exemple. C1 est l’ensemble des contraintes du premier modèle de lignes de produits modèle1. C2 est l’ensemble des contraintes du deuxième modèle de lignes de produits modèle2. Ctrans est l’ensemble des contraintes transversales. C1, C2 et Ctrans sont aussi considérés en entrée de l’algorithme d’agrégation. Le résultat est l’ensemble final des contraintes Cres obtenu suite à l’application de l’algorithme.

Table des matières

1 Introduction
2 Etat de l’art
2.1. L’ingénierie des lignes de produits logiciels
2.1.1. Les lignes de produits logiciels
2.1.1.1. Apports de l’utilisation des lignes de produits logiciels
2.1.2. Environnement pour l’ingénierie des lignes de produits logiciels
2.1.2.1. L’ingénierie de domaine
2.1.2.2. L’ingénierie d’application
2.1.3. La variabilité : concept clé dans l’ingénierie des lignes de produits logiciels
2.2. Modélisation et composition des lignes de produits logiciels
2.2.1. Approches des modèles de caractéristiques
2.2.1.1. Modélisation
2.2.1.2. Composition
2.2.1.3. Synthèse
2.2.2. Approches de modélisation orientée aspects
2.2.2.1. Modélisation
2.2.2.2. Composition
2.2.2.3. Synthèse
2.2.3. Approches dirigées par les modèles annotatrices de variabilité
2.2.3.1. Modélisation
2.2.3.2. Composition
2.2.4. Bilan et positionnement
2.3. Conclusion
3 Choix de modélisation et aperçu global des contributions
3.1. Modèle de ligne de produits logiciels : vue de structure composite
3.2. Consolidation de modèles de lignes de produits logiciels
3. 2.1. Règle de connexion à un port simple (Reg1)
3.2.2. Règle de connexion à un port multiple (Reg2)
3.2.3. Règle de port variable attaché sur une part variable (Reg3)
3.2.4. Règle de port variable connecté à un port attaché sur une part variable (Reg4)
3.2.5. Règle de connecteur variable reliant deux ports simples (Reg5)
3.2.6. Règle de connecteur variable reliant deux ports dont au moins un est multiple (Reg6)
3.2.7. Synthèse
3.3. Formes de composition
3.4. Conclusion
4 Fusion des modèles de lignes de produits logiciels
4.1. Exemple illustratif
4.2. Démarche de fusion : aperçu global
4 .3. Consolidation des modèles en entrée : première phase de fusion
4.4. Fusion des modèles en entrée : deuxième phase de fusion
4.4.1. Etape de comparaison
4.4.2. Etape de fusion
4.4.2.1. Propriétés sémantiques de fusion
4.4.2.2. Fusion des éléments structurels
4.4.2.3. Fusion des contraintes de variabilité
4.4.3. Synthèse
4.5. Consolidation du modèle de fusion résultant : troisième phase de fusion
4.6. Conclusion
5 Agrégation des modèles de lignes de produits logiciels
5.1. Exemple illustratif
5.2. Démarche d’agrégation : aperçu global
5.3. Consolidation des modèles en entrée : première phase d’agrégation
5.4. Agrégation des modèles en entrée : deuxième phase d’agrégation
5.4.1. Propriété sémantique de l’agrégation
5.4.2. Proposition1
5.4.2.1. Règles d’agrégation
5.4.2.2. Synthèse
5.4.3. Proposition2
5.4.3.1 Règles d’agrégation :
5.4.3.2. Synthèse
5.4.4. Agrégation et effets de bord
5.5. Conclusion
6 Evaluation
6.1. SEQUIOA : Environnement pour le développement des lignes de produits logiciels
6.1.1. Processus de développement SEQUOIA
6.1.2. Architecture
6.1.2.1. Outil de propagation
6.1.2.3 Outil de calcul de produits
6.1.2.4. Outil de génération de modèle de décision
6.1.2.5. Outil de dérivation
6.2. Implémentation
6.2.1. Outil de consolidation
6.2.2. Outil de fusion
6.3. Consolidation de modèles de lignes de produits logiciels : Evaluation et apports
6.3.1. Stratégie d’évaluation
6.3.2. Résultats
6.4. Fusion de modèles : Evaluation et apports
6.4.1. Stratégie d’évaluation
6.4.2. Résultats
6.5. Conclusion
7 Conclusion
Bibliographie

Télécharger le rapport complet