STRATEGIE
  Le projet STRATEGIE (CMCU F14 06) est un projet de coopération franco-tunisienne. Il inclut deux partenaires : le Centre de Recherche en Informatique (CRI) de l'Université de Paris 1 et le laboratoire RIADI-GDL de l'Ecole Nationale de Sciences Informatiques (ENSI) en Tunisie. Le projet s'intéresse au problème de l'ingénierie des besoins pour l'assemblage de composants de différentes granularités. L'objectif est de développer un environnement logiciel de mise en œuvre d'une démarche pour guider le processus de recherche et d'assemblage de composants répondant à un ensemble de besoins.   

La présentation du projet est organisée comme suit : la section 1 présente les motivations du projet. La section 2 décrit les objectifs à atteindre. Nous décrivons les différentes composantes du projet en section 3. Nous présentons successivement en section 4 et 5 les résultats obtenus et les publications réalisées.

  Motivations

Dans le but de réduire les coûts et les risques du développement des logiciels, les organisations dont le fonctionnement est fondé sur des systèmes d'information technologisés, tendent de plus en plus à basculer d'un développement sur mesure à un développement par composants.
Ces composants prennent des formes différentes. Ils peuvent être des solutions pré définies à des problèmes génériques prenant la forme de patrons. Ils peuvent être des logiciels disponibles sur étagère (COTS : Commercial Off-The-Shelf) ou des composants complexes (CCOTS) comme les systèmes ERP (Enterprise Ressource Planning ou PGI en français ; ces derniers comprennent plusieurs modules interconnectés couvrant la plupart des fonctions clés d'une entreprise (gestion des ressources humaines, ventes, trésorerie, etc.) et sont développés pour satisfaire un grand nombre de besoins d'une large variété de clients. De ce fait, ils contiennent un grand nombre de variantes parmi lesquelles une organisation aura à choisir pour adapter le système à ses propres besoins.
Dans tous les cas, la situation est insatisfaisante sur le plan de l'ingénierie des besoins ; c'est-à-dire de l'assemblage d'un ensemble de composants qui, pris collectivement, doivent assurer la satisfaction des besoins d'une organisation comme il est montré dans [1,5,6]. C'est également ce qui ressort de l'étude demandée au Partner Group en 1998 et qui montre que l'installation d'un système ERP présente les inconvénients suivants :
1. Coûts élevés,
2. Implémentation difficile et consommatrice du temps,
3. Obligation de ré-ingénierie des processus de l'entreprise,
4. Difficulté d'alignement aux besoins spécifiques de l'entreprise,
5. Besoins d'allocation importante de ressources internes,
6. Manque de support technique par les vendeurs de systèmes ERP,
7. Forte possibilité de conflit culturel.
Notre analyse de la situation conduit à dire que les difficultés viennent d'un décalage de langages (Figure 1): celui avec lequel les promoteurs de composants s'expriment est fonctionnel, au niveau détaillé (interface de communication, format de données etc.) alors que les acteurs de l'organisation (les clients des promoteurs) s'expriment en termes de buts de gestion à satisfaire, de stratégies applicables et raisonnent globalement. Le problème posé peut donc s'énoncer en deux temps :
(a) comment exprimer les besoins des clients ?
(b) comment décrire les caractéristiques fonctionnelles des composants pour faciliter la sélection et l'assemblage de composants qui répondent à ces besoins ?

Comme le montre la Figure 1, il y a deux façons d'aborder le problème de l'alignement des fonctionnalités des composants aux besoins d'une organisation. La première, qui prévaut aujourd'hui est dirigée par les composants. Elle part des composants et tente de sélectionner ceux qui semblent satisfaire les besoins. Elle s'appuie sur des mécanismes d'indexation qui permettent d'interroger les descripteurs des composants et d'en extraire les pertinents. Selon Frakes [2], les mécanismes d'indexation peuvent être de deux catégories : avec un vocabulaire contrôlé ou avec un vocabulaire non contrôlé. La première catégorie limite les termes qui peuvent être utilisés pour indexer les composants ainsi que la manière selon laquelle ils seront combinés. Dans la seconde catégorie, des valeurs énumérées, des facettes et des mots clés sont utilisés pour indexer les composants dans une classification énumérée où le domaine d'intérêt est divisé en deux classes hiérarchiques.
L'organisation hiérarchique aide les utilisateurs à comprendre les liens entre les termes d'indexation et facilite la recherche. Dans une classification par facettes, le domaine d'intérêt est analysé pour déterminer les facettes dont les valeurs servent pour indexer les composants.

Procéder à partir de la sélection des composants présente plusieurs inconvénients : d'une part, le fait que le processus de recherche est basé sur les composants, alors qu'il devrait être dirigé par les besoins, rend difficile la satisfaction de ces besoins. D'autre part, la sélection est accomplie sur la base d'un composant individuel, ce qui peut aboutir à un assemblage globalement insatisfaisant.
La seconde approche que nous préconisons dans ce projet est dirigée par les besoins. Les besoins des clients sont exprimés globalement puis affinés progressivement et les composants sont sélectionnés au fur et à mesure en fonction de leur aptitude à satisfaire les besoins, localement et globalement. Pour faciliter l'alignement, nous proposons d'utiliser le même langage pour décrire les fonctionnalités des composants et les besoins des clients.
Les clients veulent exprimer leurs besoins en termes de buts, d'intentions et de stratégies alors que les vendeurs de composants parlent de caractéristiques de bas niveau telles que écrans, flux d'entrées et sorties, et format de données. Les clients placent leurs besoins dans le contexte large de l'organisation alors que la description d'un composant est locale et fonctionnelle.
La position proposée dans ce projet est qu'il est difficile de comprendre les fonctionnalités d'un produit sans comprendre son contexte d'utilisation. Pour cette raison nous proposons un langage de description qui est adapté à l'expression des besoins organisationnels. En synthèse le langage proposé ou langage de carte d'intentions et de stratégies, permet de formuler les besoins en termes de tâches et de stratégies pour les exécuter et invite les promoteurs de composants à décrire les fonctionnalités de leurs composants en montrant comment ils peuvent contribuer à la résolution des tâches et selon quelles stratégies. Les besoins et les fonctionnalités sont donc exprimés sous forme de cartes. Une carte est un graphe labellé et dirigé composé de nœuds qui sont des intentions et d'arcs qui sont des stratégies pour satisfaire les intentions. L'intention capture la notion de tâche tandis que la stratégie est la manière de réaliser la tâche.
Lorsque la carte décrit des besoins, elle donne une vision stratégique (qui justifie le nom du projet) de ce qui est attendu du système technologisé en termes de tâches organisationnelles qu'il supporte et de stratégies pour les réaliser. Quand la carte décrit un composant, elle met en évidence les tâches que le(s) composant(s) contribu(ent) à mettre en œuvre par des moyens automatiques.

  Objectifs du projet

L'objectif du projet STRATEGIE est de développer un environnement logiciel de mise en œuvre d'une démarche guidée supportant le processus d'assemblage de composants de différentes granularités. La démarche doit :
- inclure une phase d'ingénierie de besoins qui garantit que les composants sélectionnés correspondent aux besoins de l'organisation,
- permettre la sélection des composants à différents niveaux de granularité, et en particulier aux deux niveaux intentionnel (des buts attendus du système) et fonctionnel (des fonctionnalités proposées) et,
- fournir des mécanismes de d'extraction intelligente de composants dans une base de composants.

  Description du Projet

Architecture de l'environnement
L'architecture de l'environnement est présentée à la Figure 2. Il s'organise autour de quatre pôles :
1- la base de composants,
2- le gestionnaire de la base de composants,
3- le moniteur d'assemblage et,
4- la bibliothèque de patrons d'assemblage.

Le cœur de l'environnement est la base de composants. Elle stocke les composants et leurs descriptions (intentionnelles et fonctionnelles). Le gestionnaire de la base de composants assure l'administration de la base. Il permet de mettre la base à jour en utilisant l'éditeur de cartes pour introduire la description intentionnelle d'un composant. Il intègre un module de recherche intelligente. Le moniteur d'assemblage met en œuvre le processus d'assemblage. Il utilise la carte d'expression des besoins construite au moyen de l'interface de capture des besoins ainsi que les cartes des composants sélectionnés et construit la carte de l'assemblage. Il s'appuie sur la bibliothèque de patrons qui guide le processus d'assemblage qu'il met en œuvre. La bibliothèque de patrons d'assemblage contient tous les guides méthodologiques rédigés sous forme de patrons de processus utilisés par le module d'assemblage.
On précise dans ce qui suit deux aspects essentiels de l'environnement, la description des composants et le processus d'assemblage.

Description des composants
La Figure 3 ci-dessous illustre les deux niveaux de description des composants de la base de
composants. Chaque composant est décrit selon une vue intentionnelle et une vue fonctionnelle. Chacune d'elle peut comporter plusieurs niveaux de détail.
- La vue intentionnelle se base sur le concept de carte. La carte utilise deux notions fondamentales, intention et stratégie. Une intention capture la notion de tâche organisationnelle que le composant aide à réaliser alors que la stratégie est la manière selon laquelle l'intention peut être satisfaite. Les nœuds de la carte sont des intentions, ses arcs sont étiquetés par des stratégies. La nature orientée de la carte définit une relation d'ordre de la satisfaction des intentions. Le concept central est celui de section qui est un triplet (intention origine, intention cible, stratégie) et décrit comment l'intention cible peut être satisfaite à partir de l'intention source par la stratégie. A ce niveau, la carte replace les composants dans le contexte organisationnel de leur utilisation. Ce qui cherche à être mis en valeur n'est pas ce qu'ils font et surtout comment ils le font qui est important mais à quoi ils servent. Evidemment, cela doit faciliter l'alignement des composants aux besoins de l'organisation qui seront exprimés dans les mêmes termes.
- La vue fonctionnelle consiste à décrire le composant du point de vue des fonctionnalités qu'il offre et des conditions de leur mise en œuvre. Contrairement à la vue précédente, celle-ci entre dans les détails techniques des interfaces, des contraintes base de données, contraintes de plateforme technique etc. Le formalisme qui sera utilisé est celui du langage de patrons de conception défini par l'équipe grenobloise et qui permet (a) de séparer la description de l'interface du composant de celle de son corps et, (b) d'organiser la description de la fonctionnalité de manière structurée comme un arbre de plans, choix et exécutables [4].
Les deux vues sont liées l'une à l'autre par le fait que chaque section de la carte est associée à un composant fonctionnel.
Enfin, pour permettre une description intentionnelle à plusieurs niveaux de détail, chaque section de la carte peut être décrite comme une carte. Ce mécanisme d'affinement permet de voir un composant de granularité i comme un assemblage complexe de composants de granularité i+1. Il y a donc récursivité de la description des composants permettant un processus d'assemblage progressif qui affine l'expression et la prise en compte des besoins et sélectionne puis assemble les composants en conséquence.

Processus d'assemblage
La Figure 4 est une description graphique du processus d'assemblage qui montre les quatre buts clés pour une extraction et un assemblage efficaces des composants COTS conformes aux besoins de l'entreprise. Pour accomplir chacun de ces buts, l'approche définira les quatre processus conduisant à :
(a) Construire la carte As-Is,
(b) Construire la carte To-Be,
(c) Construire la ou les carte(s) COTS,
(d) Construire la carte de l'assemblage ou carte assemblée
L'approche est une extension de celle permettant de conduire le changement [3]. Elle met en évidence le rôle du modèle As-Is, décrivant selon Jackson [3] les propriétés indicatives, et le modèle To-Be, décrivant les propriétés optatives. Le modèle As-Is reflète l'état courant de l'organisation tandis que le modèle To-Be décrit le futur souhaité par l'organisation. Par ailleurs, elle introduit le modèle COTS et le modèle d'assemblage. Tous ces modèles sont représentés par des cartes. La carte As-Is reflète la pratique courante de l'entreprise et décrit les buts/besoins satisfaits jusque là. Elle sert de support pour critiquer la situation courante et pour identifier les besoins futurs capturés dans la carte To-Be. Cette dernière carte reflète ce que l'entreprise veut accomplir par l'acquisition d'un système à base de composants COTS. La carte COTS exprime les buts ou besoins qui peuvent être accomplis parl'usage de composants COTS. Finalement, la carte d'assemblage ou carte assemblée reflète ce que
sera réellement le système futur ; elle montre (a) quels besoins seront satisfaits par l'assemblage de composants COTS, (b) ceux qui pour être satisfaits nécessiteront des composants spécifiques faits maison  et (c) ceux qui ne seront pas pris en compte.
Le processus peut être itératif ; chaque cycle correspondant à une sélection et un assemblage de composants COTS satisfaisant plus ou moins les besoins. Les itérations peuvent être justifiées soit parce que l'alignement avec les besoins n'est pas parfait, soit que d'autres informations, en termes de besoins, sont nécessaires.


  Résultats

   Thème 1 : Gestionnaire de la base de composants
   Thème 2: Module d'assemblage

Les activités menées dans chacun des ces thèmes sont décrites dans ce qui suit :

Thème 1 : Gestionnaire de la base de composants
Ce thème est subdivisé en trois sous thèmes à savoir :
   Implémentation du module de gestion de la base de composants
   La recherche intelligente
   Editeur de carte

Implémentation du module de gestion de la base de composants
L'activité de ce thème a conduit d'une part, à finaliser la définition du langage intentionnel et du langage fonctionnel et d'autre part, à implémenter la base de composants. En effet, le langage intentionnel a pour objectif de comprendre les fonctionnalités d'un composant sans comprendre son contexte d'utilisation (quand/ comment/ou/… le réutiliser ). Dans ce cadre, les approches orientées par les buts ont fait leurs preuves dans le domaine de l'ingénierie des besoins en permettant l'alignement des fonctions du système aux besoins organisationnels. A cet effet, l'approche que nous préconisons basée sur un langage de description adapté à l'expression de besoins organisationnels, et qui est le langage MAP. Quant au langage fonctionnel, notre étude consiste à décrire les fonctionnalités qu'offre un composant et les conditions de sa mise en œuvre. Contrairement à la vue précédente, celle-ci entre dans les détails techniques des interfaces, des contraintes base de données, des contraintes de plate-forme technique, etc.
L'implémentation de la base de composants est une tâche importante et critique. En fait, extraire les critères de description des composants n'est pas facile. Les composants déjà existants ne se présentent pas d'une manière facile, la documentation associée peut ne pas être standard ou elle pourrait être absente. Automatiser cette tâche nous permet d'une part de  faciliter la description des composants et d'autre part d'avoir le maximum de bibliothèques accessibles par notre système de recherche. Les bibliothèques utilisées pour l'implémentation de cette base consistent en des bibliothèques des codes binaires exécutables qui sont des bibliothèques des composants EJB,COM, CORBA et JavaBean.

Les documents qui rapportent sur l'avancement de cette activité sont référencés [1][5].

La recherche intelligente
Cette tâche a conduit à développer une infrastructure logicielle permettant d'aider le développeur à réutiliser des composants logiciels à partir de différentes bibliothèques localisées sur Internet tout en proposant un processus de recherche intelligent guidant le développement par réutilisation (ingénierie d'applications) et améliorant la pratique de la réutilisation.

Le processus de recherche que nous proposons est représenté par des modèles de processus présenté avec le formalisme MAP. Ce dernier nous permet de représenter un processus de recherche stratégique et multi démarches. Le choix d'une intention se fait selon une stratégie bien définie et dépend du développeur. La carte est le support d'une recherche intelligente ; c'est un apport dans cette tâche. Notre processus de recherche n'est pas seulement multi démarches ou stratégique, il se base aussi sur l'apprentissage des traces des recherches précédentes, des profils des développeurs et des types des composants en recherche. En fait, deux développeurs cherchant le même composant peuvent ne pas suivre le même chemin mais atteindrent le même résultat.

Le module de recherche a été implémenté tout en utilisant l'environnement Jbuilder et le SGBD Oracle. Différentes stratégies de recherche on été proposées. De même, la recherche peut être approximative ou exacte. En effet, nous avons utilisé un thésaurus qui nous a permis de définir la recherche approximative. L'extraction des composants candidats sont extrait à partir de leurs bibliothèques  d'origine d'une manière transparente à l'utilisateur. Ce dernier, n'a pas besoin de savoir comment écrire une requête associée à une bibliothèque particulière ceci est la tâche du processus de recherche que nous proposons.
Implémenter la partie intelligente de notre processus de recherche est notre travail en cours.

Le document sur l'avancement de cette activité est référencé [3].

Editeur de carte
L'activité de cette tâche a conduit au développement d'un outil qui consiste à adapter une approche guidée par les besoins de l'utilisateur.
La contribution majeure dans ce projet consiste à proposer une approche initiée par l'utilisateur pour la modélisation de ses objectifs, car nous partons de l'idée principale que seul ce dernier est capable de nous renseigner sur ses attentes et qu'au lieu d'essayer de prévoir ses besoins, il faut le doter d'outils et de moyens lui permettant d'exprimer ses  intentions d'une manière claire et simple.
Le travail ne se contente pas de modéliser les objectifs de l'utilisateur mais de les formaliser et d'identifier les correspondances permettant l'exécution d'une recherche personnalisée sur le système de recherche.
Comme résultat, nous avons mis en place un module de  modélisation des objectifs paramétrables selon le profil de l'utilisateur.
En ce qui concerne la modélisation des objectifs de l'utilisateur dans le cadre d'une recherche
informationnnelle, il est à rappeler que nous sommes dans l'obligation de mettre en évidence trois principales caractéristiques décrivant le contexte d'une session de recherche:
1-L'utilisateur possède des buts ou intentions qu'il désire atteindre.
2-L'utilisateur développe des démarches et des stratégies informationnelles et cognitives pour atteindre ses intentions.
3-L'utilisateur a besoin d'outils lui permettant de mettre en exécution ses intentions.

Pour ces principales raisons, le modèle  Map a été jugé comme étant le formalisme approprié pour atteindre ce but.
En effet, ce modèle de carte sert principalement à définir la vue intentionnelle de l'utilisateur dans un contexte de recherche informationnelle.

Les documents sur l'avancement de cette activité sont référencés [6][4].

Thème 2: Module d'assemblage
Deux tâches ont été réalisées :
   Interface de capture des besoins
   Définition du module d'assemblage

Implémentation de l'interface de capture des besoins
L'activité de cette tache a conduit à la représentation des processus stratégiques et l'utilisation de la logique temporelle pour formaliser la sémantique de navigation au sein d'une carte.
Le module de simulation prend en charge le besoin de l'utilisateur, il identifie la situation et l'intention désirée, recherche dans la trace les chemins complets utilisées dans le même cas de figure (raisonnement par cas) et il évalue les différents chemins selon les critères précisés par l'utilisateur en utilisant l'ordre de préférence et les techniques d'optimisation telles que la programmation dynamique, la méthode Monte Carlo, et ce pour aboutir à la stratégie optimale.
Le documents sur l'avancement de cette activité est référencé [7].

Définition du module d'assemblage
La description des composants sous forme de cartes (langage intentionnel) permet de réaliser un assemblage de l'application à développer au niveau des besoins. En effet, il est possible de construire incrémentalement la carte de l'application au fur et à mesure que de nouveaux composants sont sélectionnés par assemblage des cartes.
Par ailleurs, une description détaillée des composants (langage fonctionnel) permet d'aider à l'intégration des composants. En effet, celle-ci nécessite la compréhension de ce que fait le composant et comment il est construit. Notre approche consiste à réaliser l'intégration en deux étapes : une intégration au niveau des interfaces et une intégration au niveau de l'architecture.
Le document relatif à cette activité est référencé [8].

  Publications
[1] Y. Ayadi, R. Beltaifa, Etude et Gestion de Composants de Type Code, Rapport interne, Novembre 2001.
[2] I.Bayoudh, Y.Jamoussi, H. Ben Ghezala, Formalisation of the Enactment and Decision Analysis in a Meta-Map,  The 2002 International Conference on Software Engineering Research and Practice, Las Vegas, USA;  july 2002.
[3] S. Ben Abdallah, N. Kraiem, H. Ben Ghezala,  Outil de Validation d'une Spécification Formelle, Application à la spécification formelle initiale RAISE d'une infrastructure de réutilisation de logiciels, Mémoire de Projet de fin d'études, INSAT, Tunisie.
[4] A. Benhadjali, Y. Jamoussi, H. Ben Ghézala,  Support des Processus Stratégiques dans un Environnement Centré Processus, Mémoire de DEA, ENSI, 2002.
[5] S. Ben Sassi, L. Labed, H. Ben Ghezala, COTS Description : an Overview and Framwork Proposal, article rédigé en vue de soumission, Décembre 2002.
[6] S. Bennasri, Editeur de cartes, Rapport interne Octobre 2002.
[7] S. Bennasri, Une Approche Dirigée par les Besoins pour l'Ingénierie des Systèmes à Base de Composants, Rapport interne, Décembre 2002.
[8] M. EssaFi, N. Bellamine, H. Ben Ghezala, Approche de Simulation Basée sur les Agents Application au Méta-modèle de processus NATURE, Mémoire de DEA, ENSI, 2002.
[9] C.Rolland, Ingénierie des besoins pour systèmes à base de composants, Actes du 19ème Congrès INFORSID, Suisse, Juin 2001. Invited conference.
[10] C. Rolland, Requirements Engineering for COTS based Systems, XXVII Latin American Conference on Informatics (CLEI'2001), Merida, Venezuela. September 25-28, 2001. Invited conference.
[11] C. Rolland, N. Prakash, Matching ERP System Functionality to Customer Requirements, Proceedings of the 5th IEEE International Symposium on Requirements Engineering, Toronto, Canada. August 27-31, 2001.
[12] J. Ralyte, C. Rolland, An assembly process model for method engineering, Proceedings of the 13th Multi International Conference on Advanced Information Systems Engineering, CAISE'01, Interlaken, Switzerland. June 6-8, 2001.
[13] S. Bennasri, S. Ben Sassi, Y Jamoussi, Etat de L'art sur l'Ingénierie des Systèmes à Base de Composants : Présentation des principaux concepts standards, méthodes et environnements, Rapport interne, Décembre 2001.
[14] S. Bennasri, C. Souveyet
Component Reuse and Component-Based Methodologies, Proceedings of the International workshop on Mechanisms for Enterprise Integration : From objects to ontologies (MERIT 2001) at the 15th European Conference on Object Oriented programming (ECOOP), Budapest, Hongrie, June 19, 2001.

  Réferences

[1] A. Finkelstein., G. Spanoudakis, M..Ryan Software package requirements and procurement. In : Proc. of the 8th International workshop on Software Specification and Design, IEEE Computer Society Press, Washington, DC, 1996, pp 141-145.
[2] W. Frakes, T. Pole, An empirical Study of Representation Methods for Reusable Software Components, in IEEE Transactions on Software Engineering, Vol. 20, No 8, August 1994.
[3] M. Jackson, Software requirements and specifications - A lexicon of practice, principles and prejudices,. Addison Wesley Press, 1995.
[6] M. Jarke, C. Rolland, A. Sutcliffe, R. Dömges ; « The NATURE Requirements Engeneering » ; Shaker Verlag, Aachen, ISBN 3-8265-6174-0. 1999.
[4] S. Lauesen, M. Mathiassen Use Cases in a COTS Tender, REFSQ'99, Int. Workshop on Requirements For Systems Quality, Hiedelberg, 1999
[5] C. Ncube, N. Maiden., Guiding parallel requirements acquisition and COTS software selection, Int.IEEE Conference on Requirements Engineering, Limerick, Ireland, 1999

Rapports Internes

Projet Stratégie, Rapport annuel fin 1ère année, projet CMCU n° 01F1406,
Centre de Recherche en Informatique (CRI), Université de Paris1-France, Laboratoire RIADI-GDL, Ecole Nationale des Sciences Informatiques (ENSI) -Tunisie, Décembre 2001

Projet Stratégie, Rapport annuel fin 2ème année, projet CMCU n° 01F1406,
Centre de Recherche en Informatique (CRI), Université de Paris1-France, Laboratoire RIADI-GDL, Ecole Nationale des Sciences Informatiques (ENSI) -Tunisie, Décembre 2002

Projet Stratégie, Rapport final de fin de projet, projet CMCU n° 01F1406,
Centre de Recherche en Informatique (CRI), Université de Paris1-France, Laboratoire RIADI-GDL , Ecole Nationale des Sciences Informatiques (ENSI) -Tunisie, Décembre 2003