Méthodes basées composants : comparaison

2.3.1 Axe ingénierie des composants a) Analyse de domaine

Chacune des méthodes RUP [IBM, 2009], Select perspective [Select, 2009] et Catalysis [D'Souza et al., 1998] construit un modèle de domaine en utilisant des concepts et notations différentes.

La méthode RUP utilise des extensions d’UML modélisées par le profil de conception métier « UML profil for business modelling ». Ce profil définit un certain nombre d’éléments comme l’acteur métier « business actor », l’entité métier « business entity », les cas d’utilisation métier « business use case »…. Les diagrammes ainsi utilisés sont le diagramme de cas d’utilisation métier, le diagramme d’objets métier, le diagramme d’interaction métier et le diagramme d’activités.

Au niveau de son processus de développement « Consume », Select Perspective utilise la notation CSC Catalyst pour la modélisation des processus métier (BPM, Business Process Modeling). Lors de la définition des besoins métiers, la méthode utilise les diagrammes BPM suivants : PHD (Process Hierarchy Diagram) pour la hiérarchie des processus et PTD (Process Thread Diagram) pour l’enchaînement des processus.

La méthode Catalysis utilise les mêmes concepts et notations tout au long de son cycle de développement. En plus des concepts et notations UML, elle utilise deux concepts spécifiques : type d'objets (utilisé à la place de la classe dans les premières phases de développement) et type de collaboration (pour modéliser les interactions entre les objets).

b) Identification des composants

Dans RUP [IBM, 2009], l’identification d’un composant se base sur la génération d’un modèle de besoin par génération de cas d’utilisation à partir du modèle métier ; un cas d’utilisation est créé à partir d’une activité [Molina et al., 2000]. Les règles métier sont représentées sous forme de pré et post conditions.

Dans Select perspective [Select, 2009], la notion de composant métier est introduite au niveau de l’étude des besoins. De ce point de vue, la définition d’un composant consiste en la cohésion de fonctionnalités connexes, accessibles par une interface et encapsulées par une implémentation. Dans Symphony [Hassine, 2005], l’identification des composants repose sur la modélisation du modèle métier par des diagrammes de cas d’utilisation et des diagrammes de séquence qui représentent leurs dynamiques respectives. Ces cas d’utilisation sont regroupés à la fin de cette phase dans des entités capables de les assumer, et qualifiés d’objets métier.

c) Conception des composants

En terme de conception de composants, RUP [IBM, 2009] et Select perspective [Select, 2009] formalisent les composants en langage UML, en se basant sur les notions de classes ou de sous-systèmes assortis d’une ou plusieurs interfaces permettant de préciser ou non les services proposés. En terme d’implémentation, les deux méthodes ont recours aux diagrammes d’implémentation et de déploiement d’UML [OMG, 2007]. Les composants sont représentés en tant que type dans les diagrammes de composants et en tant qu’instances d’exécution dans les diagrammes de déploiement. Dans Catalysis [D'Souza et al., 1998], la phase de conception apparaît de manière différente. En effet, il est question de spécification de comportement externe d’un composant. Pour ce faire, la méthode utilise la notion de type. Quant à Symphony [Hassine, 2005], la conception des composants repose sur le modèle Symphony (§1.3.3) consistant en un diagramme de classes étendu. 2.3.2 Axe réutilisation des composants

a) Processus d’imitation

Le processus d’imitation est souvent défini comme un processus parallèle à un processus de développement basé composants. Ce processus peut être développé et amélioré séparément. À l’heure actuelle, seule la méthode Select perspective prend en compte clairement le double processus « Pour » et « Par » la réutilisation. La Figure 2-9 extraite de [Hassine, 2005] présente

le modèle SMaC (Supply Manage Consume) qui illustre la prise en charge de ces deux processus par cette méthode.

Figure 2-9 : Framework de processus de développement SMaC b) Niveau de réutilisation

Le niveau d’introduction de la notion de composant varie d’une méthode à une autre. Symphony et Select Perspective se distinguent des autres méthodes par l’identification des composants métier et de leurs responsabilités dans le système d’information cible, dès l’expression des besoins. Les autres méthodes introduisent les composants à partir de la phase d’analyse.

2.4 Évaluation des approches

Le Tableau 2-4 compare les méthodes citées ci-dessus selon le cadre de référence.

Ingénierie des composants Réutilisation des composants Analyse du domaine Identification des composants Conception des composants Processus d’imitation Niveau de réutilisation RUP [IBM, 2009] Diagrammes de cas d’utilisation métier, d’objets métier, d’interaction métier et d’activités Diagramme de cas d’utilisation Diagramme de classes étendu --- Étude des besoins Fournir Services de données Architecture technique

Architecture des données

Livraison de composants

Administration des composants

Administrer Demandes de services Composants Consommer Cadrage métier Architecture métier Planification incrémentale

Livraison de solutions métier

Cadrage de solutions métier Besoins

métier

Solutions métier

Catalysis [D'Souza et al., 1998] Type objet et type collaboration --- Collaboration de classes avec la notion type --- Analyse Symphony [Hassine, 2005] --- Diagramme de cas d’utilisation et de séquence Modèle Symphony (Diagramme de classes étendu) --- Analyse Select perspective [Select, 2009] CSC Catalyst Process Hierarchy, Process Thread --- Diagramme de classes étendu Modèle SMaC Étude des Besoins

Tableau 2-4 : Comparaison des méthodes de développement basées composants

2.5 Synthèse

Dans cette partie, nous avons présenté une description générale des méthodes basées composants, en nous intéressant en particulier à la prise en charge ou non du double processus pour et par la réutilisation.

Selon cette étude, la plupart des méthodes de développement à base de composants souffrent d’un certain nombre de faiblesses. Le principal problème qui freine la réutilisation est que le processus de développement est principalement axé « développement de systèmes d’information» (la prise en charge, par exemple, des techniques d’abstraction des connaissances de domaine reste absente). Généralement, ces méthodes n’utilisent pas clairement d’infrastructure de réutilisation, et la conception des composants passe par l’encapsulation des objets métier liés à un SI dans des entités appelées composants.

En outre, parmi les critères mis en avant lors de la conception des CM, nous avons distingué le critère variabilité défini comme une propriété essentielle qui maximise la réutilisabilité du composant. Ce critère est traité dans la partie suivante.

3 Variabilité

La mise en œuvre de l’ingénierie des CM pose un certain nombre d’exigences. Le principal besoin rencontré est d’assurer la production de composants dont la réutilisation est efficace en prévoyant une activité d’adaptation qui ajuste ces composants selon le contexte de son utilisation. Cela signifie que le modèle de composants doit prendre en considération la capacité de son adaptation ainsi que les effets produits par des éventuels changements. De cette exigence, nous avons tenu à expliciter la notion de variabilité, définie comme la capacité d’un système à s'adapter, se spécialiser et se configurer en fonction du contexte de son utilisation [VanGurp et al., 2000]. La variabilité doit être prise en compte d’autant plus que les besoins des utilisateurs ne sont généralement pas clairs, mais flous ou évolutifs.

La variabilité a été introduite dans différents domaines, plus particulièrement dans le développement des lignes de produits [Ziadi, 2004], [Pohl et al., 2005] et l’ingénierie de domaines [Kang et al., 1990] [Kang et al., 1998] [Bashroush et al., 2008]. Par contre, elle a été

peu exprimée au niveau de la conception des composants réutilisables, même s'il y a eu certaines tentatives comme celle de [Ramadour, 2001].

D’autre part, la variabilité a fait l'objet d'études au niveau des spécifications techniques et de l'implémentation d'un système [Bachmann et al., 2003], [Bosch, 2007] mais, paradoxalement n'a que rarement été abordée dans les plus hauts niveaux d’abstraction.

Cette partie a comme objectif la présentation du concept de variabilité. Elle s’articule de la manière suivante : dans un premier temps, nous présentons différentes définitions attribuées à ce concept (§3.1). Nous illustrons ensuite (§3.2) les concepts de base de la variabilité qui permettent par la suite de comparer un ensemble d’approches de modélisation (§3.3) de la variabilité dans un paragraphe d’évaluation (§3.4), avant un dernier paragraphe de synthèse (§3.5).

3.1 Définitions

L’expansion de la recherche dans le domaine de la variabilité a donné lieu à plusieurs définitions pour ce concept. La plupart des auteurs ont adopté la définition citée dans [VanGurp et al., 2000] : « Variability is the ability to change or customise a software system », traduit en « la capacité d’un système ou d’un artefact à être changé, personnalisé ou configuré selon un contexte d’utilisation particulier ». Cette définition est une définition de base qui a été personnalisée selon le domaine d’étude.

Selon l’ingénierie des domaines, la variabilité est considérée comme la représentation des caractéristiques qui sont définies en fonction des aspects essentiels et visibles du domaine, eux-mêmes identifiés à partir des connaissances de domaine [Kang et al., 1990].

Dans l’approche lignes de produits, la variabilité permet la conception d’une architecture permettant de définir plusieurs produits [Ziadi, 2004] [Pohl et al., 2005]. Les membres d’une ligne de produits sont caractérisés par leurs points communs et leurs points variables appelés « points de variation ».

Dans l’ingénierie des composants orientés problème [Ramadour, 2001], la variabilité est exprimée à travers les différentes solutions possibles d’un même problème, ce qui permet de maximiser la réutilisation des connaissances du domaine.

Dans l’approche Web sémantique, la variabilité est décrite comme un principe qui permet d’associer à un même concept de plusieurs points de vue. Ainsi, la variabilité vise à associer aux systèmes une connaissance qui guide leur usage [Guzélian et al., 2005]. [Sipka, 2005] rejoint cette dernière définition en décrivant la variabilité comme la représentation des instances d’un concept et la relation entre ses caractéristiques variables. Une caractéristique représente l’intention d’un concept et ses variantes représentent l’extension de ce concept. En résumé de cette partie, la variabilité est une technique qui sert à contrôler les parties communes et variables des artefacts d’un système dans le but de faciliter sa réutilisation dans un contexte donné.

3.2 Cadre de référence

La variabilité a fait l’objet de plusieurs travaux de recherche dans plusieurs contextes. Pour comparer ces travaux, nous définissons un cadre de référence composé de six axes : a)

Contexte de l’approche, b) Finalité de l’approche, c) Complétude, d) Identification de la variabilité, e) Représentation de la variabilité et f) Réduction de la variabilité. Ces six axes sont présentés dans la suite.

3.2.1 Définition du cadre de référence a) Contexte de l’approche

Cet axe porte sur la description des principes et objectifs d’une approche donnée, en analysant la nature des artefacts produits par le processus de représentation de la variabilité. Cet axe précise aussi le domaine dans lequel chacune des approches a fait ses preuves.

b) Finalité de l’approche

Cet axe vise à décrire la portée des solutions développées selon le concept de la variabilité. Ainsi, nous considérons que la variabilité peut être appliquée selon deux aspects : i) variabilité pour la personnalisation et ii) variabilité pour la réutilisation.

• La variabilité pour la personnalisation

Ce type de variabilité est conçu pour des besoins d’adaptation des solutions offertes par un système : soit aux besoins de l’utilisateur final, dans ce cas le système ainsi utilisé est appelé un système adaptable, soit à son environnement d’exécution, le système utilisé est appelé un système adaptatif. Ces deux notions sont appelées respectivement adaptation statique et adaptation dynamique selon [Frasincar et al., 2002] et [Kappel et al., 2000].

− Adaptation statique : les développeurs d’un composant permettent à l’utilisateur final de configurer et paramétrer ce composant par rapport à ses propres besoins. L’adaptation du composant implique une évolution du contexte d’exécution du composant et peut être explicitée par des interactions entre le composant et son contexte. Il est alors nécessaire de prendre en charge ces interactions au niveau du composant et, par voie de conséquence, leur impact sur l’adaptation de la structure et du comportement du composant. Un exemple de composant statiquement adaptable est présenté dans [Occello et al., 2006] ; il concerne une application de gestion d’agendas adaptables. L’application est constituée de composants dont le rôle est de simuler le fonctionnement d’un agenda de base, c’est-à-dire de permettre d’ajouter, supprimer et consulter des rendez-vous. À l’exécution, les agendas peuvent être adaptés par l’utilisateur final pour modifier leur comportement dans le but d’enrichir dynamiquement l’application. Par exemple, un agenda peut être adapté pour accepter un rendez-vous uniquement sous certaines conditions (disponibilité par exemple). Cette adaptation modifie le comportement de la méthode addRdv() de l’agenda adapté. D’autres formes d’adaptation vont faire intervenir des entités tierces, par exemple, « visualiser les rendez-vous » requiert une IHM, « mémoriser les RDV » requiert une base de données, etc.

− Adaptation dynamique : les développeurs d’applications sont aujourd’hui confrontés à des contextes d’exécution de plus en plus variables, qui nécessitent la création d’applications capables de s’adapter de façon autonome aux évolutions de ces contextes. Avec l’émergence de l’informatique nomade, les nouvelles applications doivent être capables de s’adapter elles-mêmes de façon autonome [Kephart, 2002] aux divers contextes d’exécution (ex. position géographique, bruit externe, etc.) auxquels elles sont confrontées,

et aux évolutions dynamiques de ceux-ci. Il devient ainsi nécessaire d’embarquer le programme chargé de l’adaptation dans les applications elles-mêmes. [David et al., 2006] propose que l’adaptation d’un système soit représentée par un programme chargé de (i) l’observation de l’environnement dans lequel évolue le système, (ii) la prise de décision des ajustements à apporter au système suite à la détection d’un changement significatif dans l’environnement, et enfin (iii) l’application des modifications choisies pour adapter le système.

• La variabilité pour la réutilisation

Ce type de variabilité consiste à rendre la variabilité explicite pour la conception d’un artefact réutilisable ; ceci signifie que la spécification de cet artefact définit une partie variable et une partie générique afin d'augmenter son applicabilité dans différentes applications. Ce type de variabilité est orienté concepteur d’applications qui adapte l’artefact selon les besoins de l’application en cours de construction. L’artefact ainsi utilisé est appelé un artefact adaptable avant de le réutiliser dans une application. Par exemple, un artefact réutilisable de gestion d’inscription peut contenir les deux fonctionnalités « inscription avec gestion de carte d’abonné » et « inscription sans gestion de carte d’abonné ». Lors de la conception du système, le concepteur doit adapter cet artefact selon les besoins de l’application à concevoir. c) Complétude

Il s’agit des différents types de variabilité représentés sur un artefact réutilisable. Nous distinguons cinq types de variabilité : variabilité métier, variabilité fonctionnelle, variabilité dynamique, variabilité structurelle et variabilité technique.

• Variabilité métier : représente la variabilité des activités représentées par l’artefact. Un artefact peut être décliné de différentes façons selon le SI auquel il se rapporte ;

• Variabilité fonctionnelle : représente la variabilité des fonctionnalités offertes par un artefact. Une fonctionnalité peut être choisie ou non par le concepteur lors de la réutilisation de cet artefact ;

• Variabilité dynamique : modélise la variabilité des interactions entre les classes du système ainsi qu’une description détaillée de la variabilité fonctionnelle ;

• Variabilité structurelle : représente la variabilité des concepts du système ; une structure de données peut varier d’un système à un autre. Par exemple, la structure de données d’une voiture dans une application chez un concessionnaire est différente de celle dans une agence de location de voitures ;

• Variabilité technique : représente la variabilité des artefacts de l’implantation d’un système donné.

d) Identification de la variabilité

L’identification de la variabilité est liée à la définition des caractéristiques qui différencient des applications de même nature. Cette phase se base aussi sur l’association de chaque variation identifiée à un ensemble d’alternatives ou variantes.

Par ailleurs, l’identification de la variabilité s’applique en fonction de la distribution de la variabilité dans l'espace et dans le temps [Bosch et al., 2001].

• La variabilité dans l'espace est mise en évidence quand un artefact capture différentes formes en même temps. Par exemple, un artefact de réservation peut se rapporter à plusieurs formes en même temps, selon qu’il s’agisse d’une réservation d'une chambre d'hôtel, d'un ouvrage d’une bibliothèque, d’un billet d’avion, etc.

• La variabilité dans le temps concerne le fait qu’il y ait différentes versions d'un artefact à différents moments. Il s’agit donc de l’évolution de l’artefact en fonction de l’évolution de son domaine d’application.

e) Représentation de la variabilité

Il est nécessaire de définir un langage de modélisation de la variabilité, afin d’assister le concepteur d’applications à bien prendre en compte ce concept. Nous présentons ici des exigences importantes qui doivent être prises en considération lors de la représentation de la variabilité.

• Représenter des parties fixes et des parties variables

Pour représenter la variabilité sur un artefact réutilisable, nous distinguons deux parties essentielles.

− Parties fixes : ce sont des éléments récurrents dans des SI de même nature. Ils représentent les structures de l’artefact obligatoirement réutilisables dans chaque système d’information. Ils sont directement intégrés dans le SI en cours de construction.

− Parties variables : elles représentent les structures de l’artefact pour lesquelles la réutilisation exige un processus de sélection adapté aux exigences d’un SI particulier. Ces éléments variables peuvent être communs à tous les SI tout en prenant différentes formes, ou ils peuvent être spécifiques à des SI particuliers.

Par ailleurs, un élément variable dans un artefact est représenté par une unité de variabilité, il s’agit d’un endroit spécifique auquel une décision est reliée. En effet, l’unité de la variabilité consiste à identifier avec précision la propriété variable d'un artefact. Cela mène à la définition, en premier lieu, du sujet et de l'objet de la variabilité [Pohl et al., 2005].

− Le sujet de la variabilité représente une propriété variable du monde réel. Par exemple, la réservation est un sujet de variabilité.

− L’objet de la variabilité représente un exemple particulier du sujet de variabilité. Par exemple, la réservation de train est un objet de la variabilité lié au sujet réservation.

En outre, pour représenter les différences entre des artefacts de la même famille, les concepts de Points de Variation (PV) et de Variantes (V) sont employés [Jacobson et al., 1997]. Nous définissons ces deux concepts comme suit :

− Un point de variation localise un endroit spécifique dans un artefact auquel une décision, prise lors de la conception d’un SI, est attachée.

− Une variante représente une réalisation spécifique d'un point de variation. Elle correspond aux solutions alternatives de conception.

Par exemple, lors de la conception du processus de réservation, la fonctionnalité réservation peut être réalisée de différentes manières. Elle est identifiée comme un PV, tandis que la réservation d’une chambre d’hôtel et la réservation d’un billet d’avion constituent, par

exemple, un ensemble de solutions alternatives pour ce PV et sont identifiées comme des variantes.

• Différencier les types de variation

La variabilité est définie par l’identification des points de variation et de leurs variantes. Un point de variation doit fournir des contraintes sur le choix de ses variantes, et ces contraintes sont matérialisées par les quatre types de variation suivants [Bachmann et al., 2001] [VanDerMaβen et al., 2002] :

− Option : un point de variation de type « option » fournit des variantes qui peuvent être sélectionnées ou non : à partir d'un ensemble de n options, k options (k compris entre 0 et n) peuvent être choisies, y compris toutes (n), ou aucune (0). Par exemple, un système de gestion d’une bibliothèque peut proposer ou non l’attribution d’une carte d’abonné. La création de carte d’abonné est identifiée comme optionnelle dans ce système.

− Alternative : un point de variation de type « alternative » permet le choix d’une seule variante parmi n choix possibles. Ce type de variation est connu sous le nom de la relation XOR entre les variantes de ce point de variation. Par exemple, pour réutiliser un système de gestion d’une bibliothèque, le concepteur doit choisir entre un système qui gère la réservation d’œuvre ou bien un système sans réservation. Ce système propose donc un choix entre deux alternatives : système avec ou sans réservation.

− Alternative Optionnelle : un point de variation de type « alternative optionnelle » est un point de variation de type option qui offre des variantes alternatives. Ce type de variation permet le choix de 0 ou 1 variante parmi n choix possibles. Par exemple, l’emprunt d’une œuvre dans une bibliothèque peut contenir un point de variation optionnel sur la gestion de garantie. Ce point de variation offre deux alternatives possibles : emprunt avec dépôt de