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
:
-
Séparer les aspects évolutifs de ceux plus stables, dans un domaine.
-
Séparer l'interface de l'implémentation.
-
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).
-
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.
-
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
|