CHAPITRE 2 : ETAT DE L’ART
6. La vue Implémentation
La vue Implémentation traite du processus de construction des approches orientées services. Quatre facettes permettent de couvrir cette vue : (i) Degré de couverture des phases du cycle de développement ; (ii) Outil de conception ; (iii) Généricité du méta-modèle à plusieurs
plateformes ; et (iv) Passage spécification métier – spécification technique. Ces facettes sont décrites dans les sections ci-dessous.
6.1. Degré de couverture des phases du cycle de développement
Le processus de développement spécifie la manière dont le développement est organisé en phases, indépendamment du type de support technologique utilisé dans le développement [Derniame et al. 1999], et ce processus diffère selon les méthodologies proposées. Chacun des différents processus définit un certain cycle de développement. De manière générale, le cycle de développement comporte quatre phases qui partent des besoins jusqu’à l’implémentation : l’élicitation des besoins, l’analyse des besoins, la conception et l’implémentation. Au-delà de ces quatre phases, nous pouvons également citer les phases de vérification, de teste et de déploiement. Malgré leur importance pour la mise en œuvre des applications orientées services, nous ne nous intéressons pas à ces dernières phases, préférant concentrer notre analyse sur les quatre phases précédentes, pour lesquels les approches orientées services offrent des solutions plus riches.
Par exemple, [Penserini et al. 2007] adoptent la méthodologie de développement orientée agent Tropos [Bresciani et al. 2004] pour la mise en œuvre de son processus de développement composé d’agents logiciel. Tropos suit une approche incrémentale par raffinement itératif. Il s’agit d’une méthodologie générique pouvant être appliquée à des contextes différents. Elle couvre une grande partie du cycle de développement, et se base sur une notation formelle (Formal Tropos) qui lui permet de vérifier et valider ses modèles. Cependant, ces outils fournis par Tropos ne sont réellement applicables que durant les phases d’élicitation et d’analyse des besoins.
Pour chacune des quatre phases du cycle de développement que nous analysons ici, nous associons des degrés qui partent du signe « ++ », signifiant que la phase est très importante dans le processus de développement, au signe « -- », signifiant que la phase est beaucoup moins importante. De manière similaire, lorsque la mise en place d’une phase par le concepteur d’une approche n’est pas aussi importante (ou inversement moins importante), nous la qualifions par le signe «+ » ou « - », ce qui signifie que la phase est seulement importante (ou inversement peu importante). Il peut arriver qu’une approche orientée service n’ait pas une des phases implémentée, dans ce cas, cette phase n’est pas mentionnée.
362 2
Degré de recouvrement des phases : ENSEMBLE (ENUM : {Elicitation des besoins (--/- /+/++), Analyse des besoins (--/-/+/++), Conception (--/-/+/++), Implémentation (--/-/+/++)}
6.2. Outil de conception
La facette Outil de conception se concentre sur les outils permettant la production des spécifications selon des modèles et des diagrammes définis par les notations. Ces outils permettent d’avoir des spécifications propres, lisibles, facilement modifiables. Bien souvent, ils permettent aussi la vérification de leurs syntaxes, leurs cohérences et de leur complétude. Les outils peuvent être regroupés dans des environnements.
Au sein de l’approche [Pensirini et al. 2007], plusieurs outils aident à l’application de la méthodologie Tropos. Par exemple, T-Tool [Kazhamiakin et al. 2003] est un outil utilisable durant les phases préliminaires de collecte des besoins. Il permet l’analyse et la validation des spécifications en utilisant les notations formelles introduites par Formal Tropos. T-Tool applique pour cela la technique du model checking. T-Tool permet par ailleurs d’animer certains modèles afin d’être validés par les développeurs. Un autre exemple, l’outil GR-Tool [Sebastiani et al. 2004] est aussi fourni par la méthodologie Tropos. C’est un outil de conception graphique permettant de spécifier les diagrammes de buts et d’exécuter les algorithmes qui leur correspondent.
La facette Outil de conception se définit alors come suit :
Outils de conception : ENSEMBLE (outils)
6.3. Généricité du méta-modèle à plusieurs plateformes
Les méthodologies liées aux approches orientées services se limitent bien souvent à des aspects très spécifiques des systèmes en cours de développement. Dans leur majorité, elles ne couvrent pas la totalité du processus de développement. [Cossentino et al. 2007] explique que les différentes méthodologies ont différents avantages et ne peuvent pas être appliquées toutes sur différentes plateformes, car elles se concentrent sur des problèmes bien trop spécifiques. Par conséquent, on ne peut pas avoir une méthodologie unique pour une utilisation générale, avec un certain niveau de personnalisation. Selon [Cossentino et al. 2007], les concepteurs, pour résoudre leurs problèmes spécifiques dans un contexte d’une application aussi spécifique, préfèrent définir leur propre méta-modèle, particulièrement conçu pour leurs besoins. Ainsi, pendant la phase d’implémentation, la plateforme cible utilisée est souvent
spécifiée directement sur le méta-modèle décrit dans la phase de conception de chaque méthodologie.
Ainsi, la méthodologie PASSI [Cossentino et al. 2005] propose, par exemple, un méta-modèle dont les concepts permettent à l’outil PTK (PASSI Toolkit) [Chella et al. 2004] de générer de code uniquement pour la plateforme JADE, alors que la méthodologie Tropos [Pensirini et al. 2007] permet aussi la génération de code pour la plateforme JACK.
La facette Généricité du méta-modèle peut être définie comme suit :
Généricité du méta-modèle à plusieurs plateformes : Booléen
6.4. Passage spécification métier – spécification technique
Selon [Azaiez 2007], un large fossé sépare encore les phases d’analyse et de conception des phases d’implémentation. Le problème vient du fait que les plates-formes ne couvrent pas tous les concepts pris en compte au niveau des modèles produits par la méthodologie. Cela entraine une perte de sémantique, d’une part, entre les phases d’analyse des besoins et les phases de conception et, d’autre part, entre les phases d’implémentation. C’est donc au développeur que revient la charge de créer les entités correspondantes afin de palier aujourd’hui à l’absence de certains concepts dans le méta-modèle. Le degré de la perte de sémantique entre les niveaux n’est pas le même pour toutes les méthodologies. Certaines méthodologies perdent moins, c’est le cas de la méthodologie de [Pensirini et al. 2007], alors que d’autres en perte plus.
La facette Passage Métier – Technique est définie comme suit :
Passage Métier – Technique : ENUM {Inexistant, Perte de sémantique ++, Perte partielle +}
Figure 2.2. Les