Instructions: Analyse de variabilité
L'analyse de variabilité crée un modèle qui distingue les aspects variables des aspects plus stables du modèle de domaine. Elle permet l'externalisation des types anticipés de changements et leurs règles correspondantes, autorisant une introduction non invasive ultérieure de changements dans la conception existante.
Relations
Description principale

Introduction

Le concepteur de service doit savoir qu'en constituant un Artefact : Spécification de service, il doit équilibrer deux forces concurrentes ;

  • Spécialisation : nécessité d'assurer qu'un service réalise l'action requise et remplit ainsi la fonction identifiée pendant l'Activité : Analyse des actifs existants.
  • Généralisation : nécessité d'assurer qu'un service est aussi réutilisable que possible de sorte que les exigences futures ne requièrent pas de refonte majeure des services existants.

Pour ce faire, le concepteur peut faire appel à des techniques regroupées sous l'expression courante analyse de "Communité et variabilité". Ces techniques sont connues et documentées depuis un certain temps, principalement dans les domaines de la formulation des patterns [Coplien, Gabriel] et de la conception des lignes de progiciels [GBS, JGBS01, JB02, MRR04, Parnas, SBM01]. Dans ces domaines, le concepteur doit également équilibrer ces mêmes forces dans les patterns - nécessité de capturer la variabilité en tant que paramètres pour le pattern afin de pouvoir appliquer le pattern dans différentes situations.

Dans la documentation sur les patterns, [Coplien] décrit la communité comme "l'essence d'une abstraction" et la variabilité comme "le sel de la vie" alors que [Gabriel], plus concret, décrit la relation entre la communité et l'abstraction -- une bonne abstraction doit capturer les aspects communs dans l'ensemble de la solution tout en identifiant les différences de chaque élément.

L'abstraction en programmation est le processus consistant à identifier des patterns communs ayant des variations systématiques ; une abstraction représente le pattern commun et permet de préciser la variation à utiliser.

En des termes similaires [Parnas] définit une famille de programmes (que nous qualifierions aujourd'hui de lignes de progiciels), basée sur les propriétés communes de l'ensemble et sur les propriétés spécifiques de chaque membre :

Nous considérons qu'un ensemble de programmes constitue une famille, dès qu'il est opportun d'étudier des programmes de l'ensemble en observant d'abord les propriétés communes de l'ensemble, puis en déterminant les propriétés spécifiques de chaque membre de la famille

Capturer la variabilité

La construction de nombreux systèmes ne prévoit pas l'incorporation des changements résultant de nouvelles exigences. L'analyse de communité et de variabilité crée une conception résiliente bien plus à même de s'adapter aux changements. Pour ce faire, les concepteurs évitent la programmation directement dans le code ou dans la conception d'aspects du domaine dont ils anticipent l'évolution via le processus d'externalisation : ils séparent les aspects évoluant le plus rapidement des éléments fonctionnels et structurels du domaine des aspects plus stables, non évolutifs. Cette technique permet de faire évoluer la conception du système et de la développer pour l'adapter aux nouvelles exigences, sans pratiquer d'altérations invasives. Pendant l'analyse, la communité et la variabilité sont modélisées en termes de hiérarchies de types. Chaque point de variabilité est identifié et externalisé. Par exemple, des instances de variation comme Client organisationnel et Client individuel peuvent être modélisées en deux réalisations d'un Type de client pouvant être développé selon les besoins. Le type externalisé (par exemple, Type de client) est associé à des Règles client appliquées à tous les clients et permettant de détailler et de développer chaque Type de client via des Types de règle spécifiques.

La première étape de l'analyse est l'identification des dépendances sur le Type à la fois d'un point de vue fonctionnel (statique) et d'un point de vue des processus (dynamique). Identifier les types de processus dépendant des types d'entités (fonctionnels) constitue une bonne approche heuristique de la restructuration de la conception :

  • Identifiez les éléments communs de la fonction et du processus (par exemple, Processus métier de réservation).
  • Séparez les aspects évolutifs de ceux plus stables. Identifiez les types clés associés à la fonction et au processus pour lesquels un changement est anticipé ou qui sont dépendants (le Type de réservation varie selon le Type de client -- une modification du Type de client peut entraîner une modification du Type de réservation).
  • Externalisez les variations et créez des hiérarchies de types à l'aide d'instances connues (le Type de fréquence peut être Préféré ou Régulier, la Partie peut être Organisationnelle ou Individuelle).

Ces points de variabilité constituent une partie importante dans la construction de systèmes résilients et évolutifs. En externalisant les points de variabilité, il est possible de les modifier sans affecter le reste de la conception. Ainsi, l'effet de vague du changement est contenu et limité par les points de variabilité. Un diagramme de classes UML illustrant cette hiérarchie fournit une feuille de route de la conception détaillée et en dernier lieu, de l'implémentation.

Les principes de base de la conception basée sur la communité et la variabilité sont, par conséquent, les suivants :

  1. Séparer les aspects évolutifs de ceux plus stables, dans un domaine.
  2. Séparer l'interface de l'implémentation.
  3. Matérialiser les aspects modifiés. Si un élément du domaine est en flux constant, il peut alors être plus sûr de matérialiser cet élément dans une classe (ou dans une couche supérieure de réutilisation).
  4. Construire des actifs à chaque niveau de réutilisation. Les niveaux de réutilisation sont : classe de base, hiérarchie d'héritage, hiérarchie d'agrégation, cluster, infrastructure préfabriquée, composant, pattern, architecture générique.
  5. Chaque élément de réutilisation possède ses propres règles de comportement outre les métadonnées nécessaires pour auto-décrire avec réflexion et évolutivité l'élément de réutilisation pour les requêtes d'exécution, pour les fonctions de services.

Références

[Arsanjani]    A. Arsanjani. Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules. Washington University Technical Report number:  wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000.

[Coplien]    J. O. Coplien. Multi-Paradigm Design for C++. Addison-Wesley Professional ; 1ère édition, 1998.

[Gabriel]    R. P. Gabriel. Patterns of Software: Tales from the Software Community. Oxford University Press, 1998.

[GBS]    J. van Gurp, J. Bosch et M. Svahnberg. Managing Variability in Software Product Lines. http://citeseer.ist.psu.edu/568368.html

[GHJV]    E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns. Addision-Wesley 1994.

[JGBS01]    J. van Gurp, J. Bosch et M. Svahnberg. On the notion of variability in software product lines. In Proceedings 2nd Working IEEE / IFIP Conference on Software Architecture (WICSA), pages 45--54. IEEE Computer Society, 2001. http://citeseer.ist.psu.edu/vangurp01notion.html

[JB02]    M. Jaring, J. Bosch, Representing Variability in Software Product Lines: A Case Study, devant apparaître à la conférence Second Product Line Conference (SPLC-2), San Diego CA, 19 au 22 Août, 2002. http://citeseer.ist.psu.edu/jaring02representing.html

[MRR04]    Jurgen Meister, Ralf Reussner et Martin Rohde. Managing Product Line Variability by Patterns. http://se.informatik.uni-oldenburg.de/pubdb_files/pdf/ManagingProductLineVariabilityByPatterns-Final.pdf

[Parnas]    D. L. Parnas. On the Design and Development of Program Families. IEEE Transactions on Software Engineering, SE-2(1):1--9, 1976.

[SBM01]    A. Stephenson, D. Buttle et J. McDermid. Extending Commonality Analysis for Embedded Control System Families. Notes de lecture dans Computer Science, Volume 1951, 2001. http://citeseer.ist.psu.edu/stephenson51extending.html

[SGB01]    M. Svahnberg, J. van Gurp, J. Bosch, A Taxonomy of Variability Realization Techniques, soumis en juin 2001. http://citeseer.ist.psu.edu/svahnberg01taxonomy.html