HAL Id: hal-01876184
https://hal.archives-ouvertes.fr/hal-01876184
Submitted on 18 Sep 2018
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
conceptuelle et logicielle
Etienne Cocquebert, Damien Trentesaux, Christian Tahon
To cite this version:
Etienne Cocquebert, Damien Trentesaux, Christian Tahon. Méthode d’aide à la conception basée sur
la réutilisation conceptuelle et logicielle. Ingéniérie des Systèmes d’Information, Lavoisier, 2008, 13
(3), pp.9-33. �hal-01876184�
réutilisation conceptuelle et logicielle
Etienne COCQUEBERT, Damien TRENTESAUX, Christian TAHON
LAMIH UMR CNRS
Université de Valenciennes et du Hainaut-Cambrésis le Mont Houy
59313 Valenciennes cedex 9, France Prenom.Nom@univ-valenciennes.fr
RÉSUMÉ
. Les sites web ayant pris une place prépondérante en termes d’images, de diffusion d’information et d’outils de travail, les concepteurs de sites doivent faire face à un ensemble de critères (coût, délais, qualité, sécurité) de plus en plus contraignants pour satisfaire les utilisateurs. Après avoir montré que les résultats actuels des travaux de recherche académique et industriels ne répondent pas entièrement aux attentes des concepteurs, nous spécifions et proposons une méthode d’aide à la conception de systèmes d’informations web (SIW) appelé WISDOM, et son outil associé. Son originalité est de guider le concepteur dans le processus de conception en lui proposant la réutilisation de solutions conceptuelles et de composants logiciels. Après avoir montré comment nous avons validé les concepts, la méthode, et l’outil, nous concluons cet article en présentant nos perspectives selon les points de vue recherche et applicatif.
ABSTRACT
. Since the web sites become more and more important regarding advertising, information announcement, and working tool, web site designers have to take into account an increasing number of criteria (cost, delay, quality, security, maintenance) during design process. We then point out the reasons why academic and industrial researches results do not satisfy these criteria, we specify and propose an Information System Web site (ISW) design method which is call (WISDOM), and its associated tool. Original feature of WISDOM is to guide the designer along the design process, and to propose to reuse conceptual solutions and software components. Finally, we highlight a validation of the method and the tool, and we finish this article by a presentation of our prospects.
MOTS-CLÉS
: réutilisation logicielle, réutilisation conceptuelle, IDM, COTS, patrons, patrons métiers, patron processus, système patron
KEYWORDS: software reuse, conceptual reuse, MDE, COTS, patterns, business pattern,
process pattern, pattern system.
1. Introduction
Les sites web ayant pris une place prépondérante en termes d’images, de diffusion d’information et d’outils de travail, les concepteurs de sites doivent faire face à un ensemble de critères (coût, délais, qualité, sécurité, maintenabilité) de plus en plus contraignants car les utilisateurs souhaitent une mise à jour régulière des sites, une interface complète et rapide d’accès et un ensemble de fonctionnalités étendues. Afin de résoudre ce problème, un nombre élevé de méthodes et d’outils logiciels, à caractère académique, commercial ou issus du monde libre sont désormais proposés pour aider à la conception des sites web. L’objectif de cet article est de montrer que cette offre ne répond pas totalement aux attentes des concepteurs en termes de méthodes pour l’aider à définir, concevoir puis déployer un site en réutilisant des travaux existants, et de proposer une méthode d’aide à la conception de systèmes d’informations web (SIW) pour répondre aux attentes des concepteurs.
Le plan de cet article est organisé de la façon suivante : la partie 2 présente le contexte de notre étude afin d’en préciser les hypothèses de travail et les contraintes fonctionnelles. La partie 3 est constituée de notre état de l’art et a pour objet de montrer que les travaux actuels ne répondent pas à l’ensemble des attentes fonctionnelles identifiées dans la partie 2. Dans la partie 4, nous établissons les spécifications de notre méthode d’aide à la conception, à partir desquelles nous proposons la méthode WISDOM dans la partie 5 et son outil associé dans la partie 6. L’originalité de cette méthode et de cet outil est de favoriser la réutilisation conceptuelle et logicielle, tout en assurant une place centrale aux modèles de données. La partie 7 montre comment nous avons validé la méthode et l’outil en les utilisant pour concevoir des SIW réels. Enfin, la conclusion de cet article fait l’objet de la partie 8 et rappelle de manière synthétique comment nous avons répondu en partie aux attentes des concepteurs de SIW, et présente nos perspectives à court et à long terme concernant cette étude.
2. Contexte et hypothèses de travail
Nos travaux se basent sur un certain nombre d’hypothèses que nous proposons de mettre en évidence dans cette partie afin de fixer le contexte de notre étude et son domaine de validité.
Hypothèses sur le domaine de notre étude : hormis la conception de SIW qui
constitue notre domaine applicatif, notre étude relève de l’ingénierie par
réutilisation (définie dans (Oussalah, 1999) et (Cauvet, 2001)) : en effet, son
objectif est de proposer la réutilisation de solutions de conception et de solutions
d’implémentation. Elle relève également de l’ingénierie dirigée par les modèles
(définie par (Favre et al., 2006)) de par notre son souci de mettre le modèle au
centre du processus.
Hypothèses sur les SIW concernés : selon la classification de Gnaho (Gnaho, 2000), notre étude concerne les « sites de présence » tels des sites de conférence (relative faible complexité de données et du nombre de services), et les « sites catalogues » tels que ceux de type académiques (la structure de données est plus complexe que celle des sites de présence).
Hypothèses sur les fonctionnalités attendues : de notre expérience de conception de sites web
1, nous avons identifié quatre fonctionnalités nécessaires (mais non suffisantes) à supporter dans une méthode afin d’aider au mieux le concepteur de SIW. Elles constituent la « colonne vertébrale » de cet article car elles sont successivement utilisées pour structurer l’analyse de l’état de l’art, la spécification et la proposition de notre méthode d’aide à la conception, et la validation de la méthode et de l’outil. Ces fonctionnalités/attentes, numérotées pour y faire référence tout au long de l’article, sont les suivantes :
– F1 : guider le processus de conception, afin d’optimiser le temps de développement ;
– F2 : identifier et proposer de réutiliser des solutions de conception, afin de réutiliser des solutions de conception éprouvées dans des SIW en production ;
– F3 : identifier et proposer de réutiliser des composants logiciels, afin de ne pas redévelopper ce qui existe déjà ;
– F4 : assister la génération du code, afin de diminuer le temps de développement.
D’autres fonctionnalités telles que l’analyse de l’expression des besoins et l’ergonomie logicielle (graphisme, interaction homme-machine…) ne sont pas prises en compte car elles ne relèvent pas de notre domaine de compétence.
La partie suivante décrit notre analyse de l’état de l’art par rapport à ces quatre fonctionnalités/attentes.
3. Etat de l’art
Nous analysons dans cette partie pour chacune des quatre fonctionnalités/attentes citées ci-dessus les contributions identifiées dans chacun des domaines de notre étude. Cette partie reprend et étoffe l’état de l’art présenté dans (Cocquebert et al., 2007).
3.1 Guider un processus de conception
Dédiée à la fonctionnalité F1, cette partie présente notre analyse de travaux pour guider un processus de conception général ou dédié à la conception de SIW.
1
http://www.univ-valenciennes.fr/sp/cocquebert/
Pour guider un processus de conception général à l’aide de l’approche patron, nous retenons deux utilisations que nous estimons caractéristiques : la définition d’un patron processus (Parsons et al., 2006), et la définition d’un langage patron (Lukosch, 2006). Le patron processus guide la conception de manière directive en définissant les différentes étapes du développement ; le langage patron, plus pédagogique, guide la conception par les rubriques textuelles des patrons du langage. Cependant, l’utilisation n’étant pas informatisée, le suivi de la démarche peut ne pas être rigoureux.
Pour guider le processus de conception d’un SIW, de nombreuses méthodes ont été définies depuis la fin des années quatre-vingt dix (RMM, OOHDM, etc.), et présentées par Gnaho (Gnaho, 2000) et Villanova (Villanova, 2002). Cependant, ces méthodes sont très peu utilisées car inadaptées aux besoins des concepteurs (Lang, 2002). Elles considèrent toutes la modélisation selon les trois dimensions « navigation », « présentation », et « métier » (Halin, 2005), mais notre analyse des présentations de Gnaho et de Villanova est qu’il n’y a pas de consensus sur la succession des étapes de la conception d’un SIW. En effet, ces méthodes ont été conçues en fonction d’un domaine applicatif.
De notre point de vue, l’approche patron permet de guider un processus, mais son informatisation permettrait sans doute un suivi plus rigoureux du processus guidé ; si le processus guidé est spécifique à la conception de SIW, il doit prendre en compte les dimensions « navigation », « présentation » et « métier ».
3.2 Identifier et proposer des solutions de conception
Dédiée à la fonctionnalité F2, cette partie présente notre analyse de travaux pour informatiser l’exploitation de patrons afin d’identifier des solutions de conception.
Une première approche consiste à faire une recherche automatique dans les formalismes patrons existants. Suite à un état de l’art qui a montré que ces formalismes différent entre eux par le nombre de rubriques proposées et le degré de détail de celles-ci, (Conte et al., 2001a) propose le formalisme P-Sigma pour
« unifier » les formalismes existants afin d’élargir les possibilités de la recherche.
Utilisé dans différents projets industriels à travers AGAP, Atelier de Gestion et d’Application de Patrons pour définir et utiliser des patrons en P-Sigma (Conte et al., 2001b), P-Sigma a montré son intérêt pour permettre à l’ingénieur de patrons de définir de manière interactive des patrons, et pour l’ingénieur d’application de rechercher et d’imiter des solutions de conception. Cependant, la recherche et l’imitation reste à l’initiative de l’ingénieur d’application et nécessitent une expertise dans l’approche patron.
Une seconde approche consiste à définir un élément « au-dessus » des patrons
formalisés afin de rendre transparente leur exploitation. (Guerrero et al., 2001) et
(Licea et al., 2000) proposent de définir un modèle de domaine, aux entités duquel
ils associent les solutions de conception de leurs patrons. De cette manière, les
solutions de conception dans les patrons sont identifiées à partir de la spécification
fonctionnelle de l’application sur le modèle de domaine. Cependant, cela nécessite d’associer manuellement les solutions de conception avec les entités du modèle de domaine (quand celui-ci est disponible).
De notre point de vue, même si AGAP est encore au stade de prototype, P- Sigma permet une informatisation de la recherche de solutions de conception ; l’utilisation d’un modèle « au-dessus » des patrons permet une utilisation transparente des patrons par une approche fonctionnelle de la conception, mais elle nécessite un « mapping » manuel des solutions des patrons sur le modèle de domaine.
3.3 Identifier et proposer des composants logiciels réutilisables
Dédiée à la fonctionnalité F3, cette partie présente notre analyse de travaux pour identifier et proposer des composants logiciels pour mettre en œuvre une fonction.
Pour mieux positionner notre analyse, nous reprenons à notre actif la définition de Michel (Michel, 2006) pour les composants : « produits logiciels existants en de multiplies copies, dont le code source est parfois disponible, vendu, loué ou fourni gratuitement par un vendeur, ayant des mises à jour périodiques s’accompagnant d’un accroissement des fonctionnalités fournies alors que certaines autres deviennent obsolètes, ayant la capacité de proposer l’un de ses services (ou plus) comme partie indispensable au fonctionnement d’une autre application ».
Une approche orientée « développement » consiste à faciliter l’identification des composants en définissant sous la forme de facettes les informations utiles au concepteur pour faire son choix. A titre d’exemple, (Michel, 2006) définit dans son modèle des facettes fonctionnelles et des facettes non fonctionnelles afin de pouvoir prendre en compte plus d’informations lors de la consultation. Cependant, comme l’ont noté entre autres (Clark, 2004) et (Leu et al., 2002), la nécessité de consulter des facettes pour identifier un composant peut conduire à consommer un temps important si le nombre de facettes et/ou de composants référencés est important.
Une solution à ce problème de temps est apportée par l’approche « fonctions ».
L’approche « fonction » consiste à définir un modèle de domaine « au-dessus » des facettes. Le concepteur spécifie ses besoins sur ce modèle de domaine, et un processus maximise leurs satisfactions par des recherches itératives dans le catalogue de composants. Utilisée dans (Leu et al., 2002) et (Puljate et al., 2004), cette approche permet de s’affranchir du nombre de composants dans le catalogue et d’avoir une approche fonctionnelle de l’identification, mais elle nécessite également de les associer manuellement avec les entités du modèle de domaine (quand celui-ci est disponible). Une solution à ce problème d’association manuelle est apportée par l’approche « processus ».
Cette approche « processus » consiste à identifier les composants logiciels par
une « reconnaissance » de leur modèle dans le modèle des spécifications. A titre
d’exemple, (Le et al., 2001) utilise un processus formel sur une modélisation de
cartes du besoin, et (Khayati, 2005) utilise un processus semi-formel sur des diagrammes UML de classes. L’avantage de cette approche est d’être automatisable, mais nécessite de disposer des modèles des composants à reconnaître.
De notre point de vue, les approche identifiées ne sont pas complètes : l’approche orientée « développement » concerne surtout les petits catalogues, l’approche orientée « fonctions » nécessite d’associer manuellement les composants logiciels au modèle utilisé pour l’identification, et l’approche orientée « processus » nécessite de disposer du modèle de référence du processus de reconnaissance.
3.4 Assister la génération de code
Dédiée à la fonctionnalité F4, cette partie présente notre analyse de travaux pour assister la génération du code d’une application.
Une première catégorie de travaux propose des outils logiciels ou des ensembles intégrés d’éléments qui permettent le développement d’application mais dont le degré d’assistance est relativement faible car l’utilisateur doit savoir comment les utiliser pour son développement. Concernant les outils logiciels, nous retenons les frameworks et les outils associés aux méthodes de conception de SIW (présentées
§3.1). Les frameworks fournissent un ensemble de classes au sein d’une architecture logicielle qui doit être respectée pour un développement optimum ; les outils associés à quelques unes des méthodes de conception de SIW implémentent les concepts de ces méthodes (ArgoUWE pour la méthode UWE, VisualWADE pour la méthode OO-H, Webratio pour la méthode WebML, etc.), mais une étude de ces outils nous a montré que l’utilisateur n’est pas guidé dans les différentes étapes du développement du SIW. Concernant les ensembles intégrés d’éléments, appelés
« système patron » dans (Guerrero et al., 2001) et (Licea et al., 2000), et « patron architecture » dans (Parsons et al., 2006), ils intègrent des patrons métiers, et/ou un patron architecture, et/ou un patron processus, et/ou un framework de classes, mais l’adaptation des solutions d’implémentation disponibles est à la charge du concepteur.
Une deuxième catégorie de travaux propose un degré d’assistance élevé en générant le code à partir de la définition de modèles (IDM). A titre d’exemple, (Couturier, 2004) propose un ensemble de patrons qui génèrent le code à partir de la modélisation du besoin ; (Muller, 2005) propose un langage action qui génère automatiquement un code de SIW indépendant de la plateforme à partir d’une modélisation du besoin, puis un processus de compilation qui adapte ce code à la plateforme cible ; (Favre et al., 2006b), par rétro conception, génère automatiquement le modèle de composants existants, mais doit faire face aux problèmes d’intégration dans un seul modèle des modèles individuels générés.
De notre point de vue, l’assistance offerte par une première catégorie d’outil
réside dans leur proposition des éléments nécessaires au développement d’une
application, mais dont l’utilisation est à la charge du développeur ; une deuxième
catégorie d’outil, relevant de l’IDM, automatise la génération de code à partir de la modélisation du besoin.
Ayant analysé pour chacune des fonctionnalités/attentes les travaux des domaines qui nous concernent, nous nous proposons dans la conclusion de synthétiser ces analyses afin de voir l’étendue des réponses apportées par rapport à nos domaines d’études.
3.5 Conclusion sur l’état de l’art
Les méthodes de conception de SIW guident le concepteur dans les différentes étapes du cycle de conception, mais ne sont pas implémentées en tant que telles dans les outils qui leurs sont associés (l’utilisateur n’est pas assisté dans le suivi de la méthode) ; elles n’apportent pas de réelle assistance à la génération de code.
L’approche patron permet de guider un processus, mais de manière non informatisée ; elle permet d’identifier des solutions de conception en exploitant directement le formalisme, mais une expertise dans l’approche patron est toujours nécessaire, ou par le biais d’un modèle « au-dessus » des patrons, mais qui nécessite un « mapping » des solutions de conception sur ce modèle ; cette solution de modèle
« au-dessus » lui permet également de proposer des composants logiciels, mais cela nécessite également leur « mapping » sur le modèle de domaine ; enfin, l’assistance à la génération de code est faible car elle propose surtout les éléments nécessaires au développement, mais laisse l’adaptation à la charge du concepteur.
En remarquant que les autres travaux que nous avons présentés par rapport à la réutilisation de composants logiciels (approche orientée « développement » et approche orientée « processus ») et par rapport à l’assistance à la génération de code (IDM) ne concernent que la fonctionnalité où ils sont présentés, nous pouvons en déduire que, de notre point de vue, l’approche patron est le seul domaine qui couvre l’ensemble de nos attentes/fonctionnalités, mais qu’elle n’y répond pas complètement.
L’objectif de la partie suivante est de spécifier notre méthode d’aide à la conception de SIW pour répondre à l’ensemble de nos contraintes fonctionnelles, en nous appuyant sur certaines solutions mises en avant dans l’état de l’art.
4. Spécifications
Les spécifications sont structurées selon les quatre fonctionnalités/attentes des
concepteurs présentées dans la partie contexte, et constituent ici notre cahier des
charges fonctionnel. Leur présentation tient compte des solutions existantes
analysées dans l’état de l’art.
Spécifications pour guider le processus de conception : afin de guider le concepteur, il faut définir un processus de conception et un modèle de données permettant la modélisation d’un SIW.
Spécifications pour identifier et proposer des solutions de conception : afin de ne pas imposer une expertise dans l’approche patron pour cette identification, il faut définir un modèle de SIW « au-dessus » des patrons, et le relier aux étapes du processus de conception, formalisées sous la forme de patrons.
Spécifications pour identifier et proposer des composants logiciels : notre but étant d’apporter une aide au développement de SIW, il faut reprendre l’approche orientée « développement » pour identifier les composants logiciels, c’est-à-dire définir des facettes fonctionnelles et non fonctionnelles attendues pour le développement, et les relier aux étapes du processus de conception, formalisées sous la forme de patrons.
Spécifications pour assister la génération du code : il faut combiner l’approche patron et l’IDM : proposer l’ensemble des éléments pour le développement sous la forme d’un système patron car nos étapes du processus sont formalisées sous la forme de patron, assister la génération du code en mettant le modèle au centre du processus.
L’objectif de la partie suivante est de proposer une méthode d’aide à la conception de SIW, appelée WISDOM, qui satisfait à l’ensemble de ces spécifications.
5. La méthode WISDOM
La présentation de notre méthode est également structurée par rapport aux quatre fonctionnalités/attentes introduites dans la partie contexte. Nous avons utilisé UML comme formalisme de modélisation
2, et les diagrammes ont été réalisés avec l’outil open source « StarUML ».
5.1 Guider le processus de conception
Dédiée à la fonctionnalité F1, cette partie présente le processus de conception de la méthode et le modèle de SIW utilisé le long de ce processus.
5.1.1 Le processus de conception
L’objectif est de définir les différentes étapes du processus de conception d’un SIW. Les méthodes de conception de SIW ne proposant pas un processus de conception unique, nous proposons pour WISDOM un processus de conception
2
Nous renvoyons le lecteur par exemple à (Muller et al., 2004) pour des détails sur le
formalisme.
basé sur notre expérience de conception de SIW. Formalisé sous la forme d’un diagramme d’activité UML (Figure 1), ce processus itératif est composé de plusieurs étapes numérotées de 1 à 6. Nous détaillons maintenant les différentes étapes (l’aspect dynamique est indiqué dans le diagramme d’activité par les flèches et par les icônes de décision entre les étapes).
Figure 1 : diagramme d’activité du processus de conception d’un SIW
Etape 1 : « identification de la navigation ». Son objectif est de définir le menu du SIW à partir du cahier des charges donné par le client sur les items potentiels et les contenus à afficher.
Etape 2 : « identification de la présentation ». Son objectif est de définir le
modèle d’organisation des pages du SIW à partir du cahier des charges donné par le
client sur la technologie support de conception du SIW (FLASH, « graphique »,
« web 2.0 », « standard », etc.). Cette identification peut utiliser les standards de facto de la conception des SIW (bannière en haut des pages, menus à gauche ou en haut, etc.).
Etape 3 : « identification des contenus ». Son objectif est de définir les données associées à chacun des items du menu.
Etape 4 : « identification du type d’implémentation ». Son objectif est de choisir entre réutiliser un composant logiciel existant ou réaliser un développement spécifique pour afficher des données, implémenter un service ou implémenter le menu du SIW.
Etape 5 : « spécifier et réaliser un développement spécifique ». Son objectif est de réaliser un développement spécifique pour afficher des données, implémenter un service ou implémenter le menu du SIW.
Etape 6 : « intégration ». Son objectif est d’intégrer le composant logiciel ou le développement spécifique au sein de l’architecture logicielle du SIW, et à le connecter avec le modèle de présentation du SIW.
La définition de la structure du SIW nécessite de dérouler ce processus sur chacun des items du menu.
L’objectif de la partie suivante est de présenter le modèle de SIW qui est manipulé tout au long de ce processus.
5.1.2 Le modèle de SIW
L’objectif du modèle de SIW est de formaliser les entités conceptuelles utilisées le long du processus de conception que nous venons de présenter. En nous basant sur notre état de l’art, nous présentons les entités du modèle par rapport aux dimensions « navigation », « présentation » et « métier »
3.
Dimension « navigation ». La modélisation de cette dimension est présentée Figure 2. Selon ce modèle, instancié lors de l’étape « identification de la navigation », un site web est composé d’un menu. Un menu étant lui-même composé d’un ensemble d’items ou de groupes d’items, nous avons adapté le patron
« composite » et relié menu à item general, dont héritent item et groupe.
Comme un même menu peut être affiché de différentes manières, nous avons adapté le patron « stratégie » pour associer menu aux types d’affichage onglets et menu déroulant à travers strategie. Page web est associée à item general (donc à item et à groupe) car son contenu est spécifique soit à un item de menu, soit à un groupe d’items (par exemple pour rassembler sur une seule page les
3
Un mot écrit dans la police courier fait référence à la classe de même nom dans le
modèle présenté
nouveautés des items du groupe). Service est associé à item dans le cas où, par exemple, un item est directement associé à un service externe tel que HAL
4.
Dimension « présentation ». La modélisation de cette dimension est présentée Figure 3. Selon ce modèle, instancié lors de l’étape « identification de la présentation », toutes les instances de page web sont associées à un modele de présentation, et ce modèle est composé d’une ou plusieurs zones d’affichage de données. De manière analogue à la dimension navigation, un contenu de zone peut être affiché de différentes manières. Nous avons donc également adapté le patron
« stratégie » et relié zone à deux exemples d’affichage (animation et tableau) à travers strategie. Service est associé à zone dans le cas où, par exemple, le service HAL est accessible à partir du contenu affiché dans la zone.
Figure 2 : modèle associé à la dimension « navigation »
Dimension « métier ». La modélisation de cette dimension est présentée Figure 4. Selon ce modèle, instancié lors de l’étape « identification du contenu », une donnee est statique ou dynamique, et dans ce dernier cas, elle est principale si elle permet de différencier un enregistrement dans une table (par exemple, l’acronyme d’une conférence), secondaire si elle précise la définition d’une donnée principale (par exemple, le lieu et les dates d’une conférence), interne si elle n’est pas affichée. Les méthodes de gestion de ces données (insertion, modification, destruction, récupération) sont protégées afin de les définir dans les instances des classes filles.
Ayant défini le processus de conception et le modèle de SIW utilisé tout au long de ce processus, l’objectif de la partie suivante est de présenter comment nous identifions et proposons des solutions de conception dans WISDOM.
4
http://hal.archives-ouvertes.fr/
5.2 Identifier et proposer des solutions réutilisables de conception
Dédiée à la fonctionnalité F2, cette partie présente un modèle d’analyse de SIW pour permettre l’identification des solutions de conception, et sa connexion avec la formalisation patron des étapes du processus de conception.
Figure 3 : modèle associé à la dimension « présentation »
Figure 4 : modèle associé à la dimension "métier"
5.2.1 Modèle d’analyse de SIW
Dérivé du modèle de SIW, le modèle d’analyse de SIW permet de caractériser
dans un SIW en production l’utilisation d’entités du modèle de SIW selon les trois
dimensions de modélisation. Cela permet d’identifier des implémentations de
solutions de conception : selon la dimension « navigation » (cf. Figure 2), l’analyse
permet de définir le menu du SIW en se référant à un menu générique ; selon la
dimension « présentation » (cf. Figure 3), l’analyse permet de définir la disposition d’une zone et le résultat de la stratégie de l’affichage ; selon la dimension « métier » (cf. Figure 4), l’analyse permet de définir les données associées à un item de menu.
A partir de ces analyses, l’identification de solutions de conception par rapport à une dimension de modélisation consiste à construire une liste dont les items sont ceux qui sont le plus souvent réutilisés dans les SIW en production, et à l’adapter pour un nouveau SIW.
Le modèle d’utilisation et son exploitation pour identifier des solutions de conception étant définis, l’objectif de la partie suivante est de connecter cette identification avec les formalisations patrons des étapes du processus de conception.
5.2.2 Proposer des solutions de conception
Nous déroulons le processus de conception, et nous nous focalisons sur la rubrique « démarche » de nos patrons (formalisés en P-Sigma), et sur la rubrique
« cas d’application » quand des exemples sont disponibles.
Selon le processus de la Figure 1, la première étape est « identification de la navigation ». Le patron associé à cette étape aide à définir le menu d’un nouveau SIW selon la démarche ci-dessous.
Réalisation du patron associé à l’étape « identification de la navigation » Rubrique Définition Solution
Démarche
- identifier le type de SIW ;
- identifier les items les plus utilisés dans les SIW de même type, en utilisant l’analyse des SIW selon la dimension
« navigation » ;
- adapter la liste de la manière suivante : sélection d’items, ajout d’items, définition de groupes d’items si nécessaire, définition de l’ordre d’affichage des items dans un groupe ou dans le menu ;
- générer les tables de données associées au menu et les fichiers associés aux items du menu.
Selon notre processus de la Figure 1, l’étape suivante est « identification de la présentation ». Le patron associé à cette étape aide à identifier et à organiser différentes zones dans le modèle de présentation selon la démarche proposée ci- dessous.
Réalisation du patron associé à l’étape « identification de la présentation » Rubrique Définition Solution
Démarche
- identifier les informations communes à toutes les pages dans
les SIW de même type, en utilisant l’analyse des SIW selon
la dimension « présentation » ;
- définir le modèle d’organisation des pages en définissant des zones d’affichage. Les types de zones proposés sont les suivants :
- « zone commune » pour afficher les informations communes à toutes les pages,
- « zone accueil » pour afficher un contenu spécifique à la page d’accueil,
- « zone navigation » pour afficher le menu défini à l’aide du patron « navigation ». la définition de cette zone peut utiliser les standards de facto de la conception des SIW, - « zone liens» pour afficher un ou plusieurs liens pour
accéder rapidement à une page interne,
- « zone annonces » pour afficher un rappel d’événements à venir si le site web contient ce type d’information, - « zone contenu » pour afficher le contenu associé à un
item du menu. Cette zone est généralement située au centre de la page ;
- insérer les données sélectionnées dans la « zone commune ».
Cas
d’application
Zone communeZone accueil Zone navigation Zone annonces Zone liens
Exemples de zones sur une page d’accueil (LaPlagne2007)
Selon notre processus de la Figure 1, l’étape suivante est « identification des contenu ». Le patron associé à cette étape aide à identifier les données associées à un item de menu selon la démarche ci-dessous.
Réalisation du patron associé à l’étape « identification des contenu »
Rubrique Définition Solution
Démarche
Pour un item de menu :
- identifier les informations les plus utilisées dans les SIW de même type, en utilisant l’analyse des SIW selon la
dimension « métier » ;
- définir les données associées selon leur type. Les types de
données proposés sont les suivants :
- donnée statique : identifier le fichier correspondant, - donnée dynamique : préciser selon les types suivants :
- donnée principale : elles forment l’ensemble minimal de données à afficher pour différencier des
informations de même type,
- donnée secondaire : elles sont affichées à partir d’une sélection d’une donnée principale et lui sont
complémentaires,
- donnée interne : elles ne sont pas affichées mais sont utiles à la gestion de l’affichage des deux types précédents.
Cas
d’application
Données secondaires
Donnée principale
Exemple de types de données (GDR MACS)
Selon notre processus de la Figure 1, l’étape suivante est « identification du type d’implémentation ». Le patron associé à cette étape aide à choisir la mise en œuvre de l’affichage de données ou d’un menu ou de l’implémentation d’un service, selon la démarche ci-dessous.
Réalisation du patron associé à l’étape « identification du type d’implémentation »
Rubrique Définition Solution
Démarche
- identifier les services les plus utilisés dans les SIW de même type, en utilisant l’analyse des SIW selon les dimensions
« navigation » et « présentation » ;
- adapter la liste par la sélection ou l’insertion de nouveaux services ;
- rechercher des composants candidats pour la mise en œuvre
des services retenus et affiner la recherche en prenant en
compte les besoins non fonctionnels, ou spécifier et réaliser
un développement spécifique.
L’étape suivante est « intégration ». Nous n’y avons pas associé de patron métier car c’est une opération de codage, pour laquelle les patrons de conception ont déjà été définis (Gamma et al., 1995).
Après avoir montré dans cette partie comment l’identification de solutions de conception est intégrée et exploitée dans les démarches des formalisations patrons des étapes du processus de conception, l’objectif de la partie suivante est de présenter comment les composants logiciels sont identifiés et proposés dans WISDOM.
5.3 Identifier et proposer des composants logiciels réutilisables
Dédiée à la fonctionnalité F3 et de manière analogue aux solutions de conception, cette partie présente un modèle d’analyse de composants pour les caractériser, et sa connexion avec la formalisation patron des étapes du processus de conception. La proposition de composants ayant été abordée lors de la présentation de la démarche du patron « identification du type d’implémentation », nous ne présentons que le modèle d’analyse des composants.
Ces analyses ont pour objectif de minimiser la recherche d’information sur les composants, et l’acquisition de composants logiciels afin de les tester.
Selon nos spécifications, l’utilisation de l’approche « développement » nous conduit à définir dans le modèle d’analyse de composants les facettes fonctionnelles et non fonctionnelles attendues pour le développement. Présenté Figure 5, ce modèle d’analyse est défini par composant, caractérisé par un ensemble de rubriques, dont chacune regroupe un ensemble de facettes définies par leur vocabulaire (espace de valeurs autorisées). Le but de Generic_item est de factoriser des propriétés communes aux classes qui en héritent.
Figure 5 : modèle de composant
L’objectif de la partie suivante est de montrer comment la génération du code
d’un SIW est assistée dans WISDOM.
5.4 Assister la génération du code
Dédiée à la fonctionnalité F4, cette partie présente l’assistance à la génération de code. L’objectif de cette assistance est d’automatiser le développement à partir des données définies pendant le processus de conception. Selon nos spécifications, nous combinons l’approche patron et l’approche dirigée par les modèles.
L’approche patron nous conduit à définir un système patron, c’est-à-dire un ensemble intégré des éléments suivants : des patrons métiers (présentés dans la partie 4.2.2), un patron processus (mettant en œuvre le processus présenté dans la partie 4.1.1) ; un patron architecture, et un framework de classes. Dans le cadre de cet article, nous dirons simplement que le patron architecture est basé sur le patron MVC, et que le framework de classes permet la génération de code dont nous allons parler dans le paragraphe suivant.
L’approche dirigée par les modèles nous conduit à mettre le modèle au centre de notre processus afin de permettre :
– la génération de structures de données associées au menu (étape 1) et aux données spécifiques d’un item de menu (étape 3) ;;
– le partage d’entités entre étapes telles que page web (étapes 1 et 2), service (étapes 2 et 3), donnée (étape 1 et 2) ;
– l’intégration des données relatives au modèle de présentation s’il est défini à l’aide d’un éditeur WYSIWYG externe.
5.5 Conclusion sur la méthode WISDOM
L’objectif de cette partie était de proposer une méthode d’aide à la conception de SIW, appelée WISDOM, afin de mettre en œuvre nos spécifications.
Pour guider la conception de SIW, nous avons proposé un processus de conception basé sur notre expérience de conception de SIW, et un modèle de SIW selon les trois dimensions de modélisation. Nous avons ensuite formalisé des étapes du processus de conception sous la forme de patrons afin d’y intégrer les assistances au concepteur : pour la proposition de solutions de conception, nous avons défini un modèle d’analyse de SIW et intégré dans des patrons son exploitation ; pour la proposition de composants logiciels, nous avons défini un modèle d’analyse de composants, et intégré dans des patrons son exploitation. Pour assister la génération du code, nous avons combiné l’approche patron en définissant l’implémentation de la méthode par un système patron, et l’ingénierie dirigée par les modèles en mettant le modèle au centre du processus.
L’objectif de la partie suivante est de montrer une mise en œuvre possible de
certaines de ces propositions dans un outil associé à la méthode WISDOM.
6. Un outil associé à la méthode WISDOM
L’objectif de cette partie est de montrer la mise en œuvre de points clés de WISDOM au sein de l’outil logiciel appelé WISDOM Tool : proposer des solutions de conception et des composants logiciels. Le WISDOM tool se présente sous la forme d’un site web
5, dont la page d’accueil (cf. Figure 6) permet d’accéder aux différents éléments de la méthode WISDOM. Dans cette page d’accueil :
– les étapes 1 à 4 offrent en plus par rapport au processus de la Figure 1 la possibilité de consulter l’aide constitué par nos patrons métiers.
– les catalogues supports sont accessibles pour en gérer les contenu (réalisation, consultation, modification ou suppression d’analyse).
Dans le cadre de cet article, nous présentons uniquement la proposition de solutions de conception et de composants logiciels.
6.1 Identifier et proposer des solutions de conception
Relative à la fonctionnalité F2, l’objectif de l’étape « identification de la navigation » est de définir l’arborescence du SIW (cf. partie 5.1.1) ; selon la démarche définie dans le patron associé à l’étape, elle utilise l’analyse des SIW selon la dimension «navigation » (cf. partie 5.2.2). L’informatisation de cette démarche dans le WISDOM Tool consiste à proposer une liste composée des items de menus les plus souvent utilisés dans les SIW de même type, avec la possibilité d’adapter cette liste à un cas de conception de SIW.
La Figure 7 présente un extrait de l’interface du WISDOM Tool pour la définition du menu d’un SIW de type « présentation entité ». La liste est ordonnée selon le nombre de réutilisations des items, et l’utilisateur dispose des possibilités suivantes pour adapter cette liste à son cas de conception : indication du nom des groupes d’items (si nécessaire) dans la colonne « groupe » ; sélection des items proposés dans la colonne « item » ; définition de l’ordre d’affichage des items dans le menu ou dans le groupe dans la colonne « ordre ».
6.2 identifier et proposer des composants logiciels
Relative à la fonctionnalité F3, l’objectif de l’étape « identification du type d’implémentation » est de choisir la mise en œuvre (cf. partie 5.1.1), selon une démarche définie dans le patron associé à l’étape pour choisir un composant (cf.
partie 5.2.2). L’informatisation de cette démarche dans le WISDOM Tool consiste à proposer une liste de composants pour la mise en œuvre d’une fonction, avec la possibilité de consulter les fiches associées à ces composants pour faciliter un choix.
5
http://www.univ-valenciennes.fr/sp/cocquebert/wisdom/
Catalogue d’analyses de
SIW
Catalogue d’analyses de
composants
Figure 6 : extrait de la page d'accueil du WISDOM Tool
Figure 7 : extrait de l’interface pour définir l’arborescence
La Figure 8 présente un extrait de l’interface du WISDOM Tool pour une recherche sur la fonction « gestion de documents », et la Figure 9 montre quelques facettes non fonctionnelles, accessibles à partir du lien « détail » dans la liste de composants.
Figure 8 : extrait de la recherche d’un composant logiciel
Figure 9 : extrait des facettes non fonctionnelles d’un composant
6.3 Conclusion sur la mise en œuvre
L’objectif de cette partie était d’illustrer une mise en œuvre possible de nos propositions. Cette mise en œuvre se présente sous la forme d’un site web à partir duquel le concepteur a accès au processus de conception et à la gestion des catalogues supports. En nous focalisant sur l’étape « identification de la navigation » et « choisir un type d’implémentation », nous avons montré une mise en œuvre de points clés de la méthode WISDOM : proposer des solutions de conception, et proposer des composants logiciels en donnant accès aux caractéristiques d’un composant pour faciliter son choix.
Cependant, si l’outil est utilisable dans l’état actuel des développements, la démarche de chaque étape n’est pas entièrement interactive, et la génération du code à partir des mises à jour du modèle n’est pas complète.
L’objectif de la partie suivante est d’illustrer la validation de notre proposition WISDOM en utilisant son outil associé pour la conception de deux SIW réels.
7. Validation
La validation est structurée également par rapport à nos fonctionnalités/attentes
présentées dans la partie contexte.
7.1 Guider le processus de conception
Afin d’évaluer la fonctionnalité F1, la méthode et l’outil ont été utilisés par un étudiant stagiaire débutant en conception web pour concevoir le SIW de GISEH
6, groupe de travail du GDR CNRS « MACS ». Le cahier des charges, exprimé par des membres du GT, était une liste informelle d’items de menu et de services. Guidé par la méthode et utilisant l’outil, cet étudiant a conçu la structure du SIW de GISEH en deux semaines (définition de l’arborescence, organisation du modèle de présentation, définition des données métiers), et l’a implémenté en trois semaines (bannière en FLASH, développement d’un menu déroulant dynamique, et codage des méthodes internes). Le temps à retenir pour la réalisation de la fonctionnalité/attente « guider le processus de conception » est celui de la phase de conception (deux semaines). Considérant que cet étudiant était débutant en conception web, nous estimons que ce délai de conception est très rapide, et que l’absence de la méthode et de l’outil lui aurait demandé beaucoup plus de temps pour concevoir un site de qualité inférieure.
Même si nous reconnaissons que nous n’avons pas de comparaison réelle par rapport au temps mis pour concevoir un site similaire sans la méthode et l’outil, nous pensons que c’est une première validation par rapport à la fonctionnalité F1.
7.2 Proposer des solutions de conception
Afin d’évaluer la fonctionnalité F2, la méthode et l’outil ont également été utilisés par nous-même pour concevoir le nouveau SIW du LAMIH, dont le cahier des charges étant similaire à celui de GISEH. Par rapport à cette fonctionnalité/attente, le bénéfice de l’utilisation de la méthode et de l’outil est surtout apparu par l’intérêt des facilités interactives pour adapter les solutions de conception au cours de réunions. En l’absence de la méthode et de l’outil, cela nous aurait conduits à identifier des solutions de conception en dehors des réunions, et à les adapter au tableau pendant la réunion. Le délai de définition des solutions de conception aurait sûrement était plus important.
Même si nous reconnaissons que là également, nous n’avons pas de comparaison quantifiable, nous pensons que le succès de cette utilisation au cours de réunion constitue une première validation par rapport à la fonctionnalité F2.
7.3 Proposer des composants logiciels
Afin d’évaluer la fonctionnalité F3, nous avons utilisé l’outil pour choisir un composant afin de mettre en œuvre la gestion des inscriptions en ligne sur le SIW de la journée CAO-Calcul
7, organisée par l’AIP-PRIMECA (et dont la conception est présentée paragraphe 7.4). Les composants proposés pour cette fonction étaient
6
http://www.univ-valenciennes.fr/GDR-MACS/giseh/
7
http://www.univ-valenciennes.fr/sp/CAOCalcul/
« LAMIHRegister », « Confman » et « START V2 ». La consultation de leurs fiches dans le catalogue a permis de voir que :
– « Confman » est développé en Python (langage sur lequel nous n’avons pas de compétences), il est anglophone, la fonction « inscription » fait partie d’une des nombreuses autres fonctions qui ne sont pas utiles pour l’événement.
– « START V2 » n’est pas open source, n’est disponible que sur Windows et Unix, ce qui n’est pas compatible avec l’équipement de l’université, il est anglophone, la fonction « inscription » fait également partie d’une des nombreuses autres fonctions qui ne sont pas utiles pour l’événement.
– « LAMIHRegister » est développé en environnement LAMP, il est francophone, il n’apporte pas de fonctions non souhaitées.
Compte tenu de ces renseignements, le choix s’est porté sur
« LAMIHRegister ».
Par rapport à cette fonctionnalité/attente, nous ne pouvons pas quantifier le bénéfice de l’utilisation de l’outil, mais nous pouvons établir que son absence aurait nécessité (i) d’identifier ces composants sur internet, (ii) de consulter leurs sites web respectifs pour connaître ces informations. Nous estimons donc que la mise à disposition de ces informations est une première validation de cette fonctionnalité/attente.
7.4 Assister la génération de code
Afin d’évaluer la fonctionnalité F4, nous avons utilisé la méthode et l’outil pour concevoir le SIW de la journée « CAO-Calculs
8», organisée par l’AIP-PRIMECA.
Le cahier des charges était une énumération d’items (planning, objectif, partenaires, accès), et la possibilité de s’inscrire en ligne. La conception et l’implémentation du site a pris 4h30. Nous reconnaissons que le SIW était simple, mais la rapidité s’explique par l’existence de fonctions pertinentes dans le framework de classes pour assister le développement. En l’absence de la méthode et de l’outil, des concepteurs web confirmés ont estimé qu’à partir du même cahier des charges, ils auraient mis entre une journée et demi et deux jours pour concevoir.
Même si nous reconnaissons que ce SIW est simple, et que les chiffres donnés par les concepteurs confirmés ne sont que des estimations, nous pensons que cette rapidité de conception et d’implémentation est une première validation de cette capacité, alors même que le développement de l’outil n’est pas terminé.
7.5 Conclusion sur la validation
L’objectif de cette partie était d’illustrer le potentiel de la méthode et de l’outil vis-à-vis des fonctionnalités identifiées dans la partie contexte. Ces fonctionnalités ont été testées avec succès, mais elles n’ont pas été validées en tant que telles car
8
