Les Lignes de Produits Logiciels dans les Systèmes d’Information Web : Un modèle de développement
Thème : Lignes de Produits pour les Systèmes d’Information Web
Plan :
Chapitre 1. État de l’art des lignes de produits
- Définition des lignes de produit
- Les principes de gestion des lignes de produits
- L’ingénierie de domaine
- Définition
- Objectifs
- L’ingénierie d’Application
- Définition
- Objectifs
- Notion de Variabilté et de commonalité
- Notion de Caractéristique (Feature): FODA
- Notion de Point de variation
- Les objectifs de la mise en place des lignes de produit
- Avantages et inconvénients des lignes de produit
- Avantages sur le plan économique
- Meilleure capitalisation de la connaissance en production,
- Amélioration de la qualité, diminution des coûts de conception et de production,
- Soutien à l’innovation,
- Réduction du time-to-market
- Avantages sur d’autres plans
- Favorisation des découvertes et innovations
- Optimisation de l’effort de développement et de test par rapport à la diversité de l’offre de produits,
- Optimisation de la gestion des défauts en permettant que la correction d’un défaut constaté sur un produit bénéficie aux produits « similaires »
.
- Les contraintes et besoins liés à sa mise en place
- Les contraintes liées à la définition d’une architecture globale au niveau du domaine
- Les contraintes au niveau du pilotage du domaine pour maintenir la cohérence des produits.
- Les outils de gestion de lignes de produits
- Requitim (Cortim) ou REQUIrements Management Toolkit by CorTIM
- Gears (BigLever Software Gears)
- Pure:Variants (Pure Systems)
Chapitre 2. Etat de l’art des méthodes de développement des applications Web et conception des architectures des systèmes d’informations Web
- Les méthodes de conception des applications web
- RMM: Relationship Management ModelWebML: Web Modeling Language
- HDM: Hypertext Design Model
- WSDM: Web Site Design Method
- OOHDM: Object-oriented Hypermedia Design Method
- UWE: UML-based Web Engineering
- Les techniques, méthodes et outils Internet, Intranet, Extranet
2.1. Intranet
2.2. Extranet
2.3. Comparaison entre Intranet, Extranet et Site web externe
- Etude comparative entre les Systèmes d’Information Traditionnels et les systèmes d’Informations Web.
- Définition des Systèmes d’Information Traditionnels
- Ergonomie des SIT
- Origine et usage
- Etat de l’art actuel
- Comparaison entre les Systèmes d’Information Traditionnels et les systèmes d’Informations Web.
- Comparaison entre les différentes méthodes de développement des applications Web
Chapitre 3. Lignes de produits et les Systèmes d’informations, état de l’art et contribution
- Etat de l’art des SIW
1. Le concept de SIW
1.1. Portrait des SIW
1.2. Systèmes d’Information basés sur le Web
1.3. Notion d’applications Web
- Architecture de ligne de produits pour le design des applications web
- Introduction
- Architectures de ligne de produits
- Koriandol, une PLA spécifiquement conçue pour le web
- Outil de suppo
- Management/Configuration du module
- Environnement Run-time
- Présentation du moteur
- Exemple
- Travaux connexes
- Conclusions
- Interprétation du document
- Illustration à l’aide du cas du site de commerce en ligne Amazon.fr
- Rôle des différents intervenants dans la conception des SIW à partir des LdP
- Les avantages des LdP dans la conception des SIW
Chapitre 4. Application
- A Product Line Approach to Design and Embbeded Web system for Healthcare et Designing Embedded Websystems for Healthcare
1.1. Vue d’ensemble du système
- Contexte du modèle
- Modèle du sous-système
- Travaux connexes
- Conclusions et travaux futurs
- An architecture Framework to Design a Healthcare Information System
- Interprétation
- Les avantages du SIS ou du HHS
INTRODUCTION
Les SIW ou Systèmes d’Information Web sont des systèmes d’information trouvant leur fondement dans les technologies web (Isakowitz et al. 1998). Ces systèmes d’information ont commencé leur expansion vers l’an 2000 et sont actuellement de plus en plus utilisés en industrie car ils ont révolutionné les systèmes d’information traditionnels. Les composants principaux des SIW sont les intranets, les extranets, le commerce électronique et les sites web externes. Chacun de ces SIW présente ses particularités, le rendant unique.
Le SIW est utilisé dans un but informatif et l’adhésion de l’information dans ce concept a fortement évolué depuis l’usage plus courant des logiciels et matériels informatiques dans les entreprises. Ainsi, on note que la traditionnelle transmission d’information via des méthodes traditionnelles est dépassée par rapport au SIW qui use d’Internet et de sa vertu internationale pour promouvoir un produit, un service ou simplement pour faire connaître une entreprise.
L’implication des lignes de produits dans le domaine des SIW est plus récente. Les lignes de produits permettent la création de plusieurs produits présentant de grandes similarités mais qui, au final, restent différentes. Elles sont utilisées à des fins de « réutilisation », c’est-à-dire qu’on se sert d’un produit spécifique pour créer d’autres dérivés de ce dernier à partir de ses coordonnées.
Les avantages d’une ligne de produits sont considérables. Etant une « famille de produit », elle permet, par exemple, à un constructeur automobile de créer plusieurs modèles à partir d’un prototype donné. Ces modèles détiennent les similarités de base présentes dans le prototype comme des pneus achetés chez le même fournisseur ; cependant, ils ont également leur spécificité, telle que la présence d’un toit ouvrant pour une voiture ou l’ouverture télécommandée des portières pour une autre, alors que ces deux voitures sont issues d’une même ligne de produits.
En même temps, les lignes de produits permettent de produire de nombreux produits sans trop de contraintes du point de vue financier, temps ou main d’œuvre. Elles permettent donc une facilitation de la production, surtout grâce à son principe de réutilisation.
Les lignes de produits en rapport avec les logiciels sont nommées « lignes de produits logiciels ». Il s’agit d’ « un ensemble de systèmes partageant un ensemble de fonctionnalités communes, satisfaisant des besoins spécifiques pour un domaine particulier et développés de manière contrôlée à partir d’un ensemble commun d’éléments réutilisables » (Clements and Northrop, 2001).
En intégrant le concept des lignes de produits dans le domaine de l’informatique, les entreprises de développement des logiciels qui sont les plus à même d’utiliser ce concept anticipent l’inflation des coûts liés à la construction de plusieurs logiciels et se permettent de produire des divers logiciels à la fois grâce à l’utilisation du paradigme des Lignes de produits. Leur but est d’augmenter la production de logiciels tout en maximisant leur qualité et en diminuant le coût et le délai de production.
L’évolution du génie logiciel combinée à celui des SIW a donc permis d’envisager, puis de réaliser la création de lignes de produits logiciels pour les SIW. Dans cette optique, les SIW sont conçus en se basant sur le principe des lignes de produits. Notre thème porte spécifiquement sur ces LdP dans les SIW. Le but de ce mémoire est donc de mettre en place un modèle pour le développement des systèmes d’information web en utilisant le paradigme des lignes de produits.
Pour ce faire, nous allons le diviser en quatre grandes parties. La première partie parlera de l’état de l’art des lignes de produits. Nous y verrons la définition des lignes de produits, les principes de gestion des lignes de produits, les objectifs de la mise en place des lignes de produit, les avantages et inconvénients des lignes de produits et les contraintes et besoins liés à leur mise en place.
Le second chapitre de notre travail sera spécialement orienté vers l’état de l’art des méthodes de développement des applications Web et la conception des architectures des systèmes d’informations Web. Nous y détaillerons les techniques, méthodes et outils Web. Puis, nous nous livrerons à une étude comparative entre les Systèmes d’Information Traditionnels et les systèmes d’Informations Web et à une comparaison entre les différentes méthodes de développement des applications Web/
Le chapitre 3 sera consacré à l’Etat de l’art et à la contribution des lignes de produits et des systèmes d’information et le dernier chapitre sera entièrement consacré à l’application.
Chapitre 1. Etat de l’art des lignes de produits
Avant d’entrer dans le vif du sujet, nous allons d’abord nous focaliser sur la définition des lignes de produits.
- Définition des lignes de produit
En terme général, les lignes de produits représentent un ensemble de produits de la même spécificité avec les mêmes caractéristiques dans un seul et même ensemble. En d’autres termes, elles sont comparables à une structure mère comprenant plusieurs éléments relatifs à cette structure. Ces éléments qui sont des produits sont identiques sur quelques points mais différents sur d’autres.
Lorsque les lignes de produits entrent en interaction avec les Systèmes d’Information Web, elles sont communément appelées « lignes de produits logiciels ». Une ligne de produits logiciels est « un ensemble de systèmes partageant un ensemble de fonctionnalités communes, satisfaisant des besoins spécifiques pour un domaine particulier et développés de manière contrôlée à partir d’un ensemble commun d’éléments réutilisables ». Elle vise une réduction des coûts de production et de maintenance tout en favorisant la création de plusieurs logiciels à la fois, regroupés en son sein.
Le champ d’action des lignes de produits est actuellement axé autour des entreprises. Ces dernières se servent de ce concept pour standardiser leur processus de développement d’entreprises centré sur la production de systèmes, de logiciels ou de matériels et pour accroitre leur taux de productivité.
Ces entreprises prennent en compte les éléments communs et variables constituant les logiciels ainsi que les éléments réutilisables qui ont servi à leur production.
Si tels sont les avantages de ce concept, il contient toutefois quelques limites et lacunes notamment au niveau de l’insuffisance en nombre des logiciels détenant un grand nombre de points communs ou des différences. L’élaboration des lignes de produit permet d’arrêter de concevoir des logiciels un à un mais plutôt de les produire en masse grâce aux « assets » dits « éléments réutilisables ».
Les « assets » sont des documents, des matériaux constitutifs, des plans ou des modèles à suivre. Les différences entre les logiciels sont appelés « variabilités». La qualité d’une ligne de produits repose entièrement sur la bonne gestion de ces différences et similarités.
L’exemple le plus concret concernant les lignes de produits est la production automobile, plus précisément celle d’une chaîne automobile. Les véhicules sont conçus avec des points communs tels que les roues et le volant et des points de différence tels que l’ajout de système de climatisation. Enfin, les logiciels conçus dans ces lignes de produits peuvent être à vocation matérielle ou commerciale.
La conception d’une ligne de produits demande l’application de deux types d’ingénierie : l’« Ingénierie du domaine » et l’« Ingénierie de l’application ». L’ingénierie du domaine est dédiée à la construction des assets utiles pour la réutilisation. L’ingénierie de l’application est celle qui consiste à utiliser les assets développés pour la production des produits.
Les lignes de produits logiciels font partie du génie logiciel inventé en 1960. Plusieurs projets européens, à savoir ESAPS, CAFE et FAMILIES ont permis aux lignes de produits d’intégrer le génie logiciel. La première étude sérieuse menée pour le compte des lignes de produits a été dirigée par l’informaticien spécialisé en génie logiciel dénommé David Parnas en 1976.
L’approche par les lignes de produits étant particulièrement bénéfique aux entreprises, diverses conférences ont été menées pour sa promotion et le partage de son utilisation dans les industries : SPLC (Software Product Line Conference) et PFE (Product Family Engineering). Outre ces conférences, les lignes de produits sont également exposées durant Les journées « Ligne de produits » qui se tiennent annuellement.
La ligne de produit a gagné du terrain auprès des entreprises grâce à une action menée par le Software Engineering Institute (SEI) qui, ayant testé et appliqué cette approche, a partagé au grand public ses vertus et avantages. Ainsi, des grands génies de la téléphonie tels que Nokia ont adopté les lignes de produits en accord avec les différents logiciels qu’ils intègrent dans leurs téléphones mobiles. On note, par exemple, la diversité des langues (plus de 60) disponibles lors de la manipulation du téléphone qui est caractéristique d’une variabilité.
La ligne de produits a également été abordée par cette industrie du fait qu’elle doit développer et concevoir un grand nombre de téléphones en une année, les LdP lui permettent donc d’accroître sa production et de suivre le flux de production exigé, ou même de l’excéder afin de générer plus de bénéfices tout en garantissant la qualité et l’innovation dans les produits.
Pour bien cerner le concept de ligne de produits, il est essentiel de connaitre la signification des différents termes techniques qui lui sont propres :
- Les similarités ou « commonalités » sont les points communs que chaque logiciel détient,
- Les variabilités représentent les différences que les logiciels présentent,
- « Un domaine est un secteur de métier ou de technologies ou des connaissances caractérisées par un ensemble de concepts et de terminologies compréhensibles par les utilisateurs de ce secteur »
Les lignes de produits sont donc particulièrement utiles, voire même indispensables aux industries, surtout aux industries automobiles et à celles œuvrant dans la téléphonie mobile. Leurs avantages sont indéniables, pour ne citer que la réduction des coûts de production au profit d’une croissance au niveau de la production elle-même.
Les objectifs des lignes de produits logiciels sont d’éviter la conception d’un logiciel ou d’un produit « à partir de zéro » (Techno 35), mais plutôt de produire un bon nombre de produits à partir de la réutilisation d’un seul logiciel. Cela implique qu’un concepteur réalise et fabrique un produit à partir d’éléments réutilisables de sorte que plusieurs autres produits similaires puissent être conçus au même moment.
Les lignes de produits logiciels reposent donc essentiellement sur le procédé de réutilisation. Cette « solution méthodologique et technologique » (BEN RHOUMA AOUINA) est surtout utilisée pour le développement de systèmes logiciels complexes et fastidieux. Les concepteurs se concentrent donc sur l’optimisation de la réutilisation et donc sur la conception de meilleurs éléments réutilisables.
Dans cette optique, on note l’usage d’une ingénierie des domaines dont l’objectif principal est de créer une gamme de systèmes logiciels avec des traits communs plutôt que d’un seul système logiciel uniquement.
Les lignes de produit logiciels passent par plusieurs phases telles que la phase de modélisation lors de leur conception. Ces phases s’appuient sur la réutilisation des assets et sur une configuration commune à tous les logiciels produits. La phase de modélisation est l’étape primordiale constituant la conception des lignes de produits. Elle permet de définir les éléments similaires et les éléments différents dans un produit et dans l’ensemble de logiciels de produits conçus.
La modélisation consiste en une approche par un modèle comme celui du modèle par les caractéristiques ou celui des modèles UML ou Unified Modeling Language. Elle peut constituer une contrainte ou une limite lorsque le concepteur de la lige de produits en confronté à une ligne de produit compliquée à réaliser ou complexe dans son développement ou dont les membres doivent être plus nombreux que d’habitude.
En effet, lorsqu’il est amené à produire des logiciels de type complexe, il n’est pas évident pour lui de trouver des caractéristiques en masse, surtout du point de vue variabilité. De plus, il peut aussi faire face aux demandes ou aux exigences tendancielles des clients, des utilisateurs de tels logiciels et de la technologie qu’i devra assouvir, d’où une pression énorme et un effort en plus à déployer.
La modélisation est une phase cruciale dans la conception d’un système de logiciels dans la mesure où elle permet de visualiser la composition de ce dernier et de déterminer les fonctions et rôles de chaque intervenant dans la conception de la ligne de produits logiciels
En pratique, la tâche de modélisation est distribuée sur différents intervenants ou équipes. Elle est effectuée selon les exigences et les types de clients. Les intervenants réalisent chacun des modèles qui, combinés, constitueront le modèle global du système de logiciel. La ligne de produits est confrontée à un problème majeur au niveau de la composition de chaque produit. On dit que les logiciels à mettre en place sont souvent de grande taille, rendant compliqué la composition de chaque modèle. Cette difficulté se fait sentir au niveau des procédures et des techniques à mettre en place afin d’assembler et de travailler les composants des différents modèles.
Ce cas concerne surtout les logiciels compliqués qui nécessitent des caractéristiques et une structure hors du commun.
Dans la conception de lignes de produits, le plus important est de se focaliser sur les variabilités présentes dans chaque modèle. En effet, elle doit être visible et chacun devrait pouvoir différencier chaque modèle réalisé d’un autre malgré leurs caractéristiques communes. La conception de ces variabilités est compliquée dans la mesure où chaque variabilité doit être représentée par une « information de variabilité » lui étant spécifique. C’est dans cette optique qu’on parle de difficultés ou contraintes relatives aux variabilités, un des éléments cruciaux lords de la composition et de la modélisation d’un système de logiciels.
Ce qui rend complexe la conception des variabilités, c’est le fait de définir l’information de variabilité, mais aussi les contraintes de variabilité pour chaque élément composant chaque modèle. Ces dernières doivent être identifiées et conçues de sorte que tous les modèles composant une ligne de produits soient dépourvus des contraintes qui risquent de les rendre invalides et donc impossibles à mettre sur le marché.
Le dernier élément important constituant un modèle dans une ligne de produits, et non le moindre, est une « sémantique bien définie qui reflètera la portée et la visée de la ligne de produits. Tous ces éléments sont à définir pendant la phase de composition d’une ligne de produits. Une fois qu’ils sont bien inclus dans chaque modèle, ils doivent être vérifiés à la fin de la modélisation et de la composition avant de déclarer que tel ou tel modèle est bien valide.
Le processus de modélisation étant un processus de base dans la conception d’une ligne de produits, il doit être choisi suivant les objectifs et les modèles d’une ligne de produits. Il convient donc de choisir la bonne architecture pour les variabilités, telle qu’UML ou le formalisme orthogonal.
La modélisation et la composition des lignes de produits font partie de leur phase de conception. Cette phase est essentiellement compose de deux ingénieries : ingénierie de domaine et ingénierie d’application. Ces ingénieries ont pour but de concevoir et de mettre en place différents modèles de produits issus d’une seule et même ligne en peu de temps, à faible coût et de manière qualitative. C’est cette ingénierie qui permet la conception de plusieurs modèles à la fois, au lieu d’un modèle à la fois comme c’était le cas auparavant. L’ingénierie des LdP est donc la source de modélisation de la LdP elle-même.
La ligne de produits présente divers avantages indéniables. Basée sur la réutilisation qui, selon Krueger, est « Le processus de création des systèmes logiciels à partir des logiciels existants au lieu de les créer à partir de zéro », elle évite alors de faire des efforts pour la production d’un seul produit mais plutôt d’utiliser des éléments appelés assets pour créer une famille de produits simultanément. La réutilisation constitue un des atouts majeurs de la conception des lignes de produits, elle sert, depuis quelques décennies, à réduire le coût de production tout en assurant une amélioration de la qualité.
La réutilisation, dans le domaine des lignes de produits logiciels, cache plusieurs défis tels que l’indentification des assets ou éléments à réutiliser et l’intégration de ces derniers dans chaque produit avec moins de difficulté, de temps et de coût que lorsqu’on part de zéro pour concevoir un produit. Ces contraintes ont été abolies avec l’apparition de la ligne de produits puisque ces efforts ont été réduits par ce concept dès lors qu’un modèle doit présenter des similarités.
Pour mener à bien l’acte de réutilisation, une bonne planification est requise, sinon les budgets alloués à cette dernière risqueraient d’être nettement supérieurs au budget de la création à partir de zéro. Néanmoins, ce point est aussi résolu en termes de ligne de produits logiciels. En effet, la qualité tant prônée chez les LdP résulte de la planification étudiée, testée et prouvée en matière de réutilisation.
La réutilisation puise ses forces en réutilisant les éléments les plus onéreux et contraignants comme les structures, et les composantes d’un logiciels. Ces éléments seront réutilisés chez les autres méthodes avec plus d’amélioration et de perfectionnement, rendant la LdP plus qualitative.
Mais la réutilisation à elle-seule n’est pas suffisante pour la conception de plusieurs modèles identiques et différents à la fois. Elle est alors accompagnée de la configuration de masse que Davis définit de la sorte : « La production à grande échelle de biens adaptés aux besoins individuels des clients « . La configuration de masse est une étape cruciale dan s la conception de la ligne de produits puisqu’elle constitue une étape primordiale dans l’ingénierie de la LdP.
Elle permet d’intégrer les éléments communs et les éléments différents dans chaque modèle en accord avec les exigences d’un public cible d’utilisateurs prédéfinis. Ainsi, l’ingénierie permet de faire en sorte à ce que plusieurs modèles de produits soient pensés, créés et intégrés dans une même famille de produits en vue de satisfaire un large public de consommateurs et d’utilisateurs.
Outre la configuration de masse, on note aussi la modélisation et la composition des lignes de produits logiciels. La modélisation est une abstraction définie par Kramer comme étant « la traçabilité des correspondances à partir d’une représentation d’un problème vers une autre représentation qui préserve certaines propriétés souhaitées et qui réduit la complexité ».
Approches de modélisation orientée aspects
Les approches de modélisation orientée aspects séparent les éléments de modèles qui appartiennent à différentes préoccupations. Un modèle primaire ou aussi de base représente le cœur fonctionnel du système. Plusieurs modèles d’aspects sont aussi modélisés pour représenter les préoccupations transverses du système, comme par exemple la sécurité et la persistance. Les modèles d’aspects doivent alors être composés avec le modèle primaire afin d’obtenir un modèle de conception intègre [47]. La communauté de développement de logiciels par aspects porte un intérêt particulier à l’exploitation des mécanismes utilisés pour le développement des lignes de produits logiciels.
Plusieurs travaux se sont focalisés sur la capture des points communs et des points variables dans une ligne de produits logiciels en utilisant les aspects à une étape précoce [48][49][50][51] ainsi qu’à l’utilisation de la technologie de l’aspect au niveau implémentation pour représenter les caractéristiques des lignes de produits. Par exemple, Groher et Voelter [52][53][54] représentent les caractéristiques d’une ligne de produits logiciels au niveau modèle par des aspects (qui sont aussi des modèles). Au niveau implémentation, les aspects encapsulent les implémentations des caractéristiques. Pour obtenir un produit de la ligne de produits, les aspects sont composés avec la base selon une sélection des caractéristiques pour une configuration donnée. C’est ainsi qu’ils expriment la variabilité par les aspects.
Parmi les approches existantes pour la composition des modèles de lignes de produits logiciels par utilisation des technologies de l’aspect, deux approches sont sélectionnées et analysées dans cette partie.
Dans [55][56][57] les auteurs proposent de fusionner les modèles en deux phases. La première phase consiste à comparer les modèles à fusionner pour identifier les éléments qui représentent un même concept. Ces éléments sont alors dits des éléments correspondants. Ils sont ensuite fusionnés durant la phase de fusion. Pour identifier les éléments correspondants, l’approche propose de se baser sur la comparaison des signatures des éléments. Tout type d’élément possède un type de signature défini par ses propriétés syntaxiques pour assurer l’unicité des éléments. Deux éléments sont alors fusionnés s’ils ont des signatures équivalentes.
Par exemple, le type de signature d’une classe UML est défini par la propriété name qui indique le nom de la classe ainsi que la propriété isAbstract qui indique si la classe est abstraite ou non. La signature de la classe Sensing de la figure 15 est donc définie par {name= Sensing, isAbstract=false}. Si deux vues de la classe Sensing appartiennent aux modèles à fusionner et qu’elles ont le même nom et la même valeur de la propriété isAbstract, elles sont alors correspondantes et elles sont fusionnées durant la phase de fusion pour former une seule classe dans le modèle de fusion résultant.
Dans ce travail, les auteurs mènent un raisonnement local sur les modèles durant la fusion. La variabilité n’est pas traitée à ce niveau, ce qui explique l’absence de gestion de l’information de variabilité associée aux éléments des modèles à fusionner. De même pour les contraintes de variabilité qui ne sont pas traitées durant le processus de fusion proposé.
L’approche de Clarke [58][59] représente beaucoup de similitudes avec l’approche précédente. Dans cette proposition, un modèle appelé theme est créé pour chaque exigence du système. Ces themes, équivalents aux modèles d’aspects et primaires, représentent différentes vues du modèle global. Le modèle intègre est obtenu par composition des ces themes. Dans l’approche Theme, des relations de composition spécifient comment les modèles doivent être composés par identification des éléments correspondants ainsi que comment ils sont fusionnés. Le mécanisme de fusion est utilisé en se basant sur la comparaison des noms des éléments à fusionner. La description de l’utilisation de ce critère de comparaison manque de précision.
Elle reste dépendante de l’utilisateur de l’approche. Cependant, nous rappelons que la comparaison des éléments à fusionner en se basant sur leurs noms demeure un critère faible et permissif comme nous l’avons illustré pour l’approche d’Acher dans la figure 2.8. De plus comme pour l’approche précédente, les auteurs raisonnent localement sur les modèles et ne traitent pas la variabilité. La fusion des modèles ne traite donc ni l’information de variabilité des éléments à fusionner ni les contraintes de variabilité qui leurs sont associées. De même que l’approche précédente, le raisonnement sur les modèles durant la fusion reste local. La variabilité n’est pas traitée à ce niveau, ce qui explique l’absence de gestion de l’information de variabilité associée aux éléments des modèles à fusionner. De même pour les contraintes de variabilité qui ne sont pas traitées durant le processus de fusion proposé.
L’utilisation des techniques de développement par aspect des logiciels dans le contexte des lignes de produits logiciels prend de plus en plus d’ampleur. En effet, les différentes exigences de la ligne de produits sont modélisées sous forme d’aspects (qui sont des modèles) et d’un modèle de base. Pour obtenir un produit de la ligne de produits logiciels, le modèle de base est composé avec les aspects qui représentent les exigences du produit souhaité. Les mécanismes de composition à ce niveau se basent sur l’aspect structurel des modèles composés. Cependant le raisonnement de ces approches au niveau composition reste local et ne traite donc ni l’information de variabilité des éléments structurels ni les contraintes de variabilité. De même la sémantique de composition n’est pas évoquée par ces approches.
|
Approches dirigées par les modèles annotatrices de variabilité
Certaines approches de développement de lignes de produits logiciels utilisent des annotations pour identifier les éléments variables dans le modèle. Nous distinguons les approches qui représentent les lignes de produits logiciels par le biais de modèles UML [11]. Plusieurs approches dirigées par les modèles utilisent des stéréotypes UML pour annoter les éléments variables qui appartiennent aux modèles de lignes de produits logiciels [3][21][22][23][4]. Par exemple, Clauss [21][24] propose un profil UML pour permettre l’expression de la variabilité dans les modèles UML qui représentent des lignes de produits logiciels.
Ce profil indique que tout élément du modèle peut faire l’objet d’un point de variation. Un point de variation localise la variabilité dans un modèle et ses différentes réalisations décrivent plusieurs variantes. Le point de variation contient plusieurs variantes qui déterminent les caractéristiques de la variabilité. Une variante est toujours attachée à un point de variation. Le point de variation implique plusieurs valeurs étiquetées pour déterminer le moment de la réalisation du point de variation et la cardinalité des variances ainsi que le nombre de variances qui lui correspondent. Le stéréotype «optional» indique qu’un élément peut être supprimé dans le modèle dérivé.
Dans le travail de Ziadi [22] en plus de l’utilisation du modèle de caractéristiques, cette approche utilise des extensions d’UML pour modéliser la variabilité au niveau structurel grâce à deux mécanismes à savoir l’optionalité et la variation ainsi qu’au niveau comportemental moyennant trois mécanismes qui sont l’optionalité, la variation et la virtualité. Au niveau structurel (aspect statique) par exemple deux stéréotypes sont proposés:
– L’optionalité: par l’utilisation du stéréotype «optional» ce qui signifie que certaines propriétés sont optionnelles dans certains produits et donc elles peuvent être supprimées. L’optionalité n’est pas modélisée au niveau des associations entre les classes car une classe optionnelle signifie que toutes les associations auxquelles elle participe sont aussi optionnelles. L’optionalité d’une classe s’étend sur tous ses attributs et ses opérations, idem pour un paquetage optionnel dont l’optionalité s’étend sur tous ses éléments.
– La variation: par l’introduction des stéréotypes «variation» et «variant» associés respectivement aux classes abstraites et aux sous-classes concrètes. Au niveau comportemental (aspect dynamique): diagrammes de séquence
– L’optionalité: par l’introduction du stéréotype «optionalLifeline» qui s’applique sur les messages reçus et envoyés des objets optionnels dans le diagramme de séquence. Le stéréotype «optionalInteraction» spécifie l’optionalité des interactions.
– La variation: par l’introduction du stéréotype «variation» appliqué sur une interaction qui référence un ensemble de sous-interactions stéréotypées «variant».
– La virtualité: par l’introduction du stéréotype «virtual» qui une fois appliqué sur une interaction, signifie que le comportement de celle-ci peut être redéfini par une autre interaction de raffinement associée à un produit particulier. Le comportement de l’interaction virtuelle sera remplacé pendant la dérivation de produit par le comportement de l’interaction de raffinement associée au produit.
Kobra [3] est basée sur les composants. On ne parle plus de modèle de caractéristiques mais plutôt d’arbre de composants dont le composant racine représente le système et les sous composants représentent les éléments constitutifs du système. Elle utilise un seul stéréotype «variable» pour marquer les éléments variables de type paquetage, classe, attribut, opération, transition et interaction. Au niveau statique, l’approche traite les diagrammes de classes, au niveau comportemental (dynamique), les diagrammes de séquences et machine à états. L’approche introduit un modèle de décisions qui remplace le rôle du diagramme de caractéristiques et qui est construit à partir du modèle de famille de systèmes et des spécifications de l’ensemble des systèmes visés. Pour chaque décision le concepteur doit choisir une résolution qui affecte alors le modèle de famille de systèmes sous-jacent et peut renvoyer l’utilisateur vers de nouvelles décisions.
L’approche SEQUOIA (précédemment nommée SyF) [25] utilise le diagramme de caractéristiques pour la capture des exigences. Elle offre le moyen d’exprimer la variabilité au niveau du modèle UML de la ligne de produits logiciels grâce au stéréotype « VariableElement» (annexe A). Les contraintes de variabilité sont exprimées pour identifier les produits logiciels valides qui peuvent être obtenus à partir du modèle de la ligne de produits logiciels. Nous citons à titre d’exemple une contrainte d’implication entre deux éléments variables (annexe A): Implication (elem1, elem2) : une contrainte de type Implication spécifie que la présence de l’élément elem1 dans un produit valide implique la présence de l’élément elem2 dans le même produit valide de la ligne de produits et inversement.
|
Tableau 1. Approches de modélisation et de composition des lignes de produits. Source : Ben Rhouma Aouina T. (2012) : Composition des modèles de lignes de produits logiciels, Thèse de doctorat, UNIVERSITÉ PARIS-SUD.
Enfin, un des grands avantages et non le moindre des lignes de produits est sa conception réfléchie et optimisée qui permet de réduire nettement les tarifs de production tout en accroissant considérablement la qualité de chaque produit issu d’une LdP. De ce fait, les LdP sont adoptées par les plus grandes industries de la téléphonie mobile comme Nokia qui, en 2012, arrivait à produire 25 à 30 modèles de téléphone en un an ou des industries aéronautiques ou automobiles.
Après avoir étudié les bases, notamment la définition, de l’approche par la ligne de produits, nous allons maintenant entrer en profondeur dans la connaissance des LdP en analysant leurs différents principes de gestion.
- Les principes de gestion des lignes de produits
La gestion des lignes de produits détermine la qualité d’une gamme de produits. Pour créer une LdP digne de ce nom, deux sortes d’ingénierie sont utilisées : l’ingénierie de domaine et l’ingénierie d’application. Nous allons d’abord définir l’ingénierie de domaine et ses objectifs avant de nous tourner vers l’ingénierie d’application.
- L’ingénierie de domaine
- Définition
Comme nous l’avons mentionné un peu plus haut, l’ingénierie de domaine ou « Domain Engineering » concerne la construction et le développement des « assets » utiles pour la création des logiciels. Les « assets » en question sont des éléments réutilisables. L’ingénierie de domaine est la première étape du processus de création et d’élaboration d’une ligne de produits car elle permet de réaliser la réutilisation, fondement même des LdP. Cette phase est exceptionnellement conçue afin de développer les éléments pour la réutilisation.
Elle comporte trois activités :
- Activité d’analyse de domaine ou Reference Requirements
Elle consiste à apprendre tout ce qui concerne le domaine de la LdP à mettre en place, c’est-à-dire à détecter les similarités et les variabilités présentes dans chaque produit, par exemple FODA.
- Activité de conception de domaine ou Reference architecture
La conception de domaine est l’étape réservée à la réalisation de ce qu’on appelle « architecture logicielle générique » Cette architecture logicielle générique déterminera chaque produit puisqu’elle servira de référence à sa conception. Elle contient, généralement, les caractéristiques propres à l’élaboration de la LdP, à savoir ses constituants, ses connecteurs et les difficultés rencontrées lors de sa mise en place. L’activité de conception de domaine doit impérativement être effectuée après avoir analysé le domaine car l’architecture définie durant cette phase sera explicitement rapportée vers l’architecture logicielle générique.
- Activité d’implantation du domaine ou Production Plan
L’implantation du domaine est la phase succédant à la conception du domaine. Une fois l’analyse et la conception du domaine achevées, on pourra alors procéder à l’implantation du domaine.
Cette dernière consiste à transposer l’architecture générique mentionnée précédemment vers le domaine à concevoir de manière à obtenir des « composants » ou « assets » essentiels à l’ingénierie d’application.
L’ingénierie de domaine est donc la phase primordiale à la bonne mise en place d’une ligne de produits. Tout ce qui touche les actions primaires pour la conception des LdP est effectué durant cette étape. En outre, l’ingénierie de domaine permet aussi de déterminer les noms attribués à chaque produit ou « scope ».
Après cette définition détaillée de l’ingénierie de domaine, composant essentiel de la gestion des lignes de produits, nous allons maintenant déterminer ses différents objectifs.
- Objectifs
L’ingénierie de domaine est la phase clé dans la conception des lignes de produits. Elle permet d’analyser le domaine, de concevoir l’architecture générique propre à ce dernier et d’implanter tous ces éléments dans le domaine, avant de léguer les rennes à l’ingénierie d’application.
En général, l’ingénierie de domaine est indispensable pour :
« Définir la variabilité autorisée et ses limites,
Capitaliser les artefacts d’ingénierie (exigences, modèles, code, test, etc.),
Gérer les évolutions en maintenant la cohérence globale des produits,
Gérer les défauts et leurs impacts. »
Elle permet d’établir d’avance les principales caractéristiques de chaque produit qui va former la ligne de produits. La LdP repose donc essentiellement sur sa réussite, ce qui amène à la considérer avec sérieux et à ne pas la sous-estimer. Pour ce faire, des professionnels en la matière devraient être mobilisés et sollicités pour garantir une ingénierie de domaine optimale et impeccable.
La raison d’être de l’ingénierie de domaine est de permettre la gestion de la LdP dans son ensemble, c’est-à-dire la gestion commune de tous les modèles et non la gestion individualisée. Cette phase permet de mettre en place les éléments relatifs aux exigences de tous les usagers des logiciels conçus. En même temps, cette étape permet de caractériser les objectifs que chaque modèle de produit renferme. Dans cette optique, l’ingénierie des domaines est cent pour cent focalisée sur les éléments réutilisables qui définiront les points communs entre chaque logiciel formé.
- L’ingénierie d’Application
- Définition
L’ingénierie d’application ou « Application Engineering/ Development with reuse » est la phase utilisant les résultats de l’ingénierie de domaine dans le but de construire la ligne de produits. Elle permet la réutilisation de ces éléments pour les convertir en nouveaux logiciels. L’ingénierie d’application est également appelée « dérivation » pour sa faculté à « dériver » les éléments réutilisables conçus dans l’ingénierie de domaine en les convertissant en logiciels.
Cette phase s’appuie sur la réutilisation des éléments réutilisables ou assets pour développer chaque modèle de la dP.
Elle renferme quatre étapes successives :
L’ « Application Requirements »
L’application requirements permet d’identifier les variabilités chez chaque produit et de déterminer les exigences du logiciel final conçu à partir des « assets » ou « core assets ».
- L’ « Application Design »
L’application design est l’étape consistant à arranger l’architecture générique en fonction des variabilités et des besoins spécifiques lies à la conception des nouveaux logiciels.
- L’ « Application Coding »
L’application coding est en liaison directe avec les différents besoins spécifiques requis par les nouveaux logiciels. Dès que ces besoins sont identifiés, l’application coding est en charge de former de nouveaux composants leur correspondant.
- L’ « Application Testing »
Cette étape consiste à tester les éléments réutilisables dans la phase domaine d’application pour attester de leur compatibilité avec les nouveaux composants conçus en phase d’application testing et éviter d’éventuelles anomalies.
Nous pouvons constater à travers les différentes phases formant l’ingénierie d’application qu’elles sont échelonnées par degré d’importance et qu’elles dépendent les unes des autres. A présent, nous allons découvrir les différents objectifs de l’ingénierie d’application.
Figure 1: Processus de développement logiciel classique. Source : TECHNO 35 Smals : Les lignes de produits logiciels : Réutilisation et variabilité. Publication périodique de Smals, Juin 2009
- Objectifs
L’ingénierie d’application est le domaine étudiant les propriétés des nouveaux logiciels et qui les met en pratique. Pour qu’elle soit menée à bien, l’expert chargé de l’ingénierie de domaine doit optimiser son travail. Les objectifs de l’ingénierie d’application sont :
- La conception de logiciels performants dotés de variabilités et de commonalité à la fois à l’aide des éléments réutilisables ou assets fabriqués dans l’ingénierie de domaine,
- La mise en place de nouveaux composants réutilisables en adéquation avec les éléments réutilisables déjà en main permettant d’assouvir les besoins spécifiques que les logiciels pourraient avoir,
- L’achèvement des logiciels finaux
En somme, on peut constater une interdépendance entre l’ingénierie de domaine et l’ingénierie d’application. En même temps, la mise en place de ces deux processus est complexe, du point de vue des « variabilités » qui constituent actuellement les contraintes les plus conséquentes dans la conception de nouveaux logiciels.
Pour une gestion optimale des lignes de produits, il vaut donc mieux perfectionner ces deux ingénieries et respecter à la lettre leurs étapes. Maintenant que nous avons défini les principes de gestion des LdP, nous allons nous tourner vers la notion de variabilité et de commonalité.
La visée de l’ingénierie d’application est avant tout de produire les produits demandés grâce aux assets ou artefacts développés dans l’ingénierie de domaine. Elle représente donc une étape dépendante de celle de l’ingénierie de domaine. Dans cette optique, elle se donne pour mission de réutiliser le plus d’éléments possibles pour un modèle bien particulier de la LdP et d’étudier en profondeur les similarités et variabilités présentes dans chaque produit afin de mener à bien l a construction des produits ou dérivation.
La figure ci-dessous résume le processus de développement d’une ligne de produits logiciels
Figure 2: Processus de développement d’une ligne de produits logiciels. Source : TECHNO 35 Smals : Les lignes de produits logiciels : Réutilisation et variabilité. Publication périodique de Smals, Juin 2009
- Notion de Variabilité et de commonalité
Comme nous l’avons répété plusieurs fois dans ce travail, le concept des lignes de produits puisent leur particularité dans la commonalité et la variabilité. Ces deux notions déterminent une mise en place de lignes de produits conforme aux règles.
La commonalité ou similarité « regroupe « l’ensemble des hypothèses qui sont vraies pour tous les produits, membres de la ligne de produits » C’est un des éléments clés permettant de concevoir des logiciels issus d’une seule famille de produits. En général, ces similarités sont souvent faciles à détecter puisqu’il s’agit des éléments de base tels que le volant ou les portières dans une voiture. En d’autres termes, ce sont des composants qu’on ne peut pas séparer du produit, des éléments présents dans chaque produit formant une ligne de produits.
La variabilité, elle, « regroupe l’ensemble des hypothèses montrant comment les produits membres de la ligne de produits diffèrent »
Nous allons entamer cette sous-partie par la présentation de la caractéristique ou feature en nous basant sur l’exemple de FODA.
- Notion de Caractéristique (Feature): FODA
Par définition, la caractéristique ou Feature est, selon Kang, « tout aspect important et distinctif ou caractéristique visible par les diverses parties prenantes ». La feature est obtenue à partir des analyses de la variabilité menée en phase de l’ingénierie de domaine. Elle permet donc de différencier un produit d’un autre. Elle prend forme de diagramme avec plusieurs niveaux comportant la variabilité pour chaque produit (les éléments qui différencie un produit d’un autre) comme l’atteste le diagramme de FODA.
La caractéristique ou « feature » est un ensemble d’éléments logiciels déterminant un contexte particulier. La feature collecte les exigences imposées par les logiciels finaux. Elle a pour but de trouver les exigences réutilisables par les logiciels finaux citées ci-dessus afin de limiter leur nombre. En temps normal, les features se décomposent en plusieurs sous-features afin d’obtenir une « feature finale » capable de se conformer à un composant logiciel réutilisable.
Exemple de features : le domaine des véhicules
– Carrosserie
– Moteur Essence,
– Moteur électrique
– Moteur diesel
– Vitres manuelle
– Vitres automatique
– Climatisation
En plus d’avoir défini la notion de caractéristique, Kang a érigé un modèle de caractéristique désormais célèbre et usité partout dans le monde : le diagramme de FODA ou Feature Oriented Domain Analysis. Ce diagramme hiérarchisé a pour objectif de présenter les points communs et les variabilités dans un logiciel. Dans le FODA, on trouve une caractéristique racine qui est la ligne de produits elle-même. Puisque le FODA prend la forme d’un arbre, la caractéristique racine qui est la LdP se divise en plusieurs autres parties ou caractéristiques qui représenteront les commonalités et les variabilités.
Le FODA est la feature la plus utilisée et la plus connue. Il permet également de déterminer les éléments communs et variables dans un produit. Il prend la forme d’un diagramme ressemblant à un « arbre » constitué de nœuds représentant les particularités ou caractéristiques du domaine et d’arcs, une sorte de branches traduisant les relations existant entre les caractéristiques. Dans cette optique, trois catégories de caractéristiques sont visibles dans le FODA :
- La première est celle des caractéristiques obligatoires, c’est-à-dire les composants ou éléments qui doivent impérativement être présents dans chaque produit. Les éléments obligatoires sont les constituants mêmes d’un produit, ils permettent de le définir et de le distinguer des autres. En termes d’exemple, nous pouvons citer un ordinateur qui doit impérativement être muni d’un écran qu’il soit ordinateur portable ou ordinateur de bureau.
L’écran définit l’ordinateur qui ne pourrait pas fonctionner sans lui, il fait partie des composants essentiels de ce derniers et lui permet de fonctionner correctement et d’être utilisé comme il se doit.
- La seconde est celle des caractéristiques optionnelles qui, comme son nom l’indique, n’est pas obligatoire à tous les produits, c’est-à-dire que ces caractéristiques sont visibles chez certains produits et absentes chez d’autres. Les caractéristiques optionnelles sont des options souvent chargées du confort de l’utilisateur du produit ou destinées à le distinguer des autres, à le valoriser et à le promouvoir.
Toujours dans l’exemple de l’ordinateur, on pourrait prendre comme option la présence d’un filtre superposé à l’écran de l’ordinateur de bureau. Tous les ordinateurs de bureau ne sont pas munis de ce filtre et on peut s’en passer, il incombe à l’utilisateur de le placer sur l’écran afin de démarquer cet ordinateur des autres de la même série et d’y ajouter donc une fonction supplémentaire qui, ici, est le filtrage des rayons X émanés par l‘ordinateur afin de se protéger contre les maladies qu’ils peuvent engendrer (maladies des yeux, etc.)
- La troisième est celle des caractéristiques alternatives qui sont des éléments alternatifs c’est-à-dire que leur présence n’impacte en rien l ‘utilisation d’un produit ou son fonctionnement. Les caractéristiques alternatives sont donc des caractéristiques de rechange.
Dans l’exemple d’un ordinateur de bureau, on pourrait prendre comme composants alternatifs les écrans de l’ordinateur qui pourraient être des écrans plats ou LCD ou des écrans classiques CRT ou LED.
Le FODA est une des méthodes les plus efficaces dans la détection des variabilités et des composants communs dans les produits constituant une ligne de produits spécifique. Il consiste en une analyse approfondie du domaine du produit en vue de dégager les domaines obligatoires, optionnels ou alternatifs. L’exemple illustratif du FODA est le diagramme de FODA pour une voiture. La voiture en question fait partie d’une série ou ligne de produits. De ce fait, elle possède certaines similarités et différences vis-à-vis des autres voitures membres de cette même LdP.
Le FODA identifie la voiture comme étant le domaine ou le produit. En étudiant de près son aspect, ses composants ou ses options, on note qu’elle doit obligatoirement avoir une carrosserie, un moteur et des vitres. Il s’agit ici des caractéristiques obligatoires qu’elle doit posséder. En allant plus en profondeur, on constate, lors de l’analyse, que la voiture comporte aussi une climatisation, ce qui n’est pas le cas des autres.
La climatisation est alors une caractéristique optionnelle car elle est facultative et n’est présente que chez certaines voitures. Une fois que ces caractéristiques obligatoires et optionnelles auront été identifiées, on procède à l’identification des caractéristiques alternatives. Dans le cas présent, il peut s’agir du moteur qui peut fonctionner de manière électrique ou qui doit être alimenté par une essence ou qui sera un moteur diesel. Il se peut également que ce soit au niveau des vitres qui peuvent être manuelles ou automatiques.
Pour résumer, le FODA présente donc les caractéristiques d’un produit en dégageant les caractéristiques obligatoires, optionnelles ou alternatives. La figure suivante résume le FODA utilisé pour le cas d’une voiture.
Caractéristique obligatoire
Caractéristique optionnelle
Caractéristique alternative
Figure 1. Exemple d’un diagramme de caractéristiques FODA (ZIADI T.)
A part le FODA, nombreuses autres caractéristiques ont également vu le jour : FORM ou Feature Oriented Reuse Method , Feature RSEB et Generative Programming. FORM a la particularité de divise rune LdP en plusieurs « couches » permettant de connaitre d’autres points de vue concernant la modélisation de la LdP et de prendre en compte d’autres critères tels que la technologie ou l’environnement. La feature RSEB met en exergue la cohésion entre les modèle de caractéristiques et les modèles de conception Plusieurs autres approches ont succédé l’approche FODA et ont permis son extension. Le Generative Programming a pout visée de rendre la conception de la LdP automatique.
La composition d’une caractéristique de lignes de produits connait plusieurs approches. Le tableau que nous dresserons ci-dessus est entièrement retranscrit d’un mémoire portant sur la composition des modèles de lignes de produits logiciels écrit par Takoua BEN RHOUMA AOUINA. Il présente les différentes approches de composition d’une caractéristique selon plusieurs auteurs.
Approche à base de règles de transformation de modèles
Alves et al. [38] ont motivé le besoin de faire évoluer les lignes de produits logiciels et plus particulièrement les modèles de caractéristiques. Dans ce travail, les auteurs proposent d’étendre la notion traditionnelle de transformation pour les lignes de produits logiciels. La transformation de modèles est satisfaite lorsque l’ensemble des systèmes valides du modèle de caractéristiques reste le même ou évolue. Pour ce faire, ils proposent un ensemble de règles de transformation qui considèrent les spécificités du modèle de caractéristiques. La figure 2.4 présente un exemple de règle de transformation.
Cette règle prend en entrée un modèle de caractéristiques incluant la caractéristique variable B et les caractéristiques C et D reliés par une contrainte de type xor. Ceci veut dire que les systèmes valides sont ABC, AC, ABD et AD. La transformation de ce modèle donne un modèle de caractéristiques où les caractéristiques B, C et D sont reliés par une contrainte de type or. L’ensemble des systèmes obtenus à partir de ce modèle inclut l’ensemble des systèmes valides obtenus à partir du premier modèle.
La proposition présentée dans ce travail ne se limite pas à la transformation des modèles de caractéristiques. Les auteurs suggèrent aussi l’utilisation des règles de transformation dans la fusion des modèles de caractéristiques. Cependant, les règles de transformation proposées ont aussi besoin d’être étendues pour traiter les différents cas rencontrés dans la fusion. Ces règles traitent principalement les contraintes de variabilité sans intérêt particulier à la structure des caractéristiques ou leurs informations de variabilité.
De plus, les règles proposées se limitent à gérer des contraintes de types and, or et xor. Les contraintes transversales de types implication et équivalence ne sont pas traitées par les règles proposées, malgré leur importance et la fréquence de leur utilisation dans le contexte des lignes de produits. Les règles de fusion de contraintes ne sont pas génériques, elles restent limitées aux types de contraintes spécifiées. Des précisions supplémentaires sont aussi nécessaires pour expliquer les critères de comparaison des caractéristiques à fusionner ainsi que les propriétés sémantiques de la fusion.
|
Approche à base de règles visuelles de fusion de modèles
Inspirés par le travail d’Alves et al. Segura et al. [39] proposent un catalogue de règles visuelles pour la fusion des modèles de caractéristiques. Chaque règle est composée de deux parties ; la partie gauche représente les deux patrons des modèles de caractéristiques à fusionner en entrée (les pré-conditions). La partie droite représente le patron du modèle de caractéristiques résultant de la fusion (post-conditions). La figure 2.5 donne un exemple de ces règles.
Les règles de fusion proposées permettent d’obtenir un modèle de caractéristiques dont l’ensemble des systèmes valides inclut au moins l’ensemble des systèmes valides obtenus à partir des modèles de caractéristiques en entrée. Ceci implique que le modèle de caractéristiques résultant permet d’obtenir des produits qui ne sont valides pour aucun des modèles d’entrée. La sémantique de la fusion manque de précisions pour les règles proposées. En effet, pour une sémantique donnée de la fusion (par exemple en mode union ou en mode intersection), le catalogue de règles doit être trié ; certaines règles sont maintenues pour la fusion alors que d’autres doivent être mises à jour selon la propriété sémantique choisie.
La règle présentée dans la figure 2.6, montre la fusion de deux patrons de modèles de caractéristiques. Le premier contient deux caractéristiques A et B ayant une contrainte associée de type implication. Le deuxième inclut deux caractéristiques A et B ayant une contrainte associée de type équivalence. Le résultat de leur fusion donne un modèle de caractéristiques qui inclut les deux caractéristiques variables A et B permettant ainsi toutes les combinaisons possibles de A et B. Pour une fusion en mode union par exemple, cette contrainte permet d’obtenir des systèmes valides qui n’appartiennent à aucun des modèles d’entrée. Le système qui contient la caractéristique A est un système valide obtenu à partir du modèle de fusion. Cependant, ce système n’est valide pour aucun des modèles de caractéristiques en entrée. Cette règle doit alors être mise à jour pour satisfaire la propriété union de la fusion.
Les auteurs proposent des règles de fusion pour spécifier l’information de variabilité des éléments résultant de la fusion, comme l’exemple de la règle illustrée dans la figure 2.5. Ils proposent aussi un catalogue de règles pour la fusion des contraintes, comme l’exemple dans la figure 2.6. Cependant, l’énumération de ces règles selon les types de contraintes n’offre pas de généricité et limite la fusion aux types de contraintes identifiées. De plus, le catalogue de règles contient 30 règles qui doivent être vérifiées selon la sémantique de fusion.
|
Approche à base d’opérateurs de fusion et d’agrégation de modèles
Acher et al. proposent [42] un ensemble d’opérateurs pour la composition de modèles de caractéristiques. Nous distinguons plus particulièrement les deux opérateurs suivants :
– Opérateur de fusion : cet opérateur permet de fusionner des parties communes de modèles de caractéristiques pour obtenir un modèle de caractéristiques intègre. L’opérateur de fusion utilise le nom des caractéristiques comme critère de correspondance. Les caractéristiques ayant le même nom sont alors fusionnées. Cependant, ce critère reste étroitement lié au contexte de modèle de caractéristiques. Il ne présente pas de problèmes de fusion pour ce typ de modèles qui est généralement utilisé pour représenter les lignes de produits à un niveau d’abstraction élevé.
Ceci est loin d’être similaire pour des modèles de nature différente comme par exemple les modèles UML et qui représentent un niveau d’abstraction moins élevé que les modèles de caractéristiques. Comparer les éléments de modèles selon un seul critère qui est leurs noms est relativement facile à implémenter comme critère de correspondance. Cependant, ce critère peut être très permissif dans certains cas. Par exemple, comparer les attributs de classes en se basant sur leurs noms comme critère de correspondance peut impliquer des problèmes lors de la fusion si les types associés à ces attributs sont incompatibles.
La figure 2.7 montre l’exemple des caractéristiques Sensing appartenant à deux modèles de caractéristiques différents. Selon la proposition d’Acher, deux éléments des modèles peuvent être fusionnés s’ils ont le même nom. Nous déduisons donc que Sensing de modèle1 correspond à Sensing de modèle2. De même, infraredDetector et volumetricDetector de modèle1 correspondent respectivement à infraredDetector et volumetricDetector de modèle2. Par conséquent les éléments Sensing, infraredDetector et volumetricDetector de modèle1 peuvent être fusionnés avec les éléments respectifs Transport, infraredDetector et volumetric Detector de modèle2.
Nous avons ensuite représenté les mêmes éléments dans un modèle UML illustré dans la figure 2.8. En utilisant le même critère de comparaison, nous constatons que les classes Sensing de modèle1 et modèle2 correspondent (même nom). Les attributs volumetricDetector de modèle1 et modèle2 correspondent aussi et possèdent des types compatibles, contrairement aux attributs infraredDetector qui correspondent selon le critère du nom mais qui ont des types incompatibles (InfraredDetector et Sensor).
Dans ce cas, la fusion des éléments infraredDetector peut engendrer des problèmes à cause de l’incompatibilité de leurs types. Les caractéristiques dans chaque modèle de caractéristiques sont reliées par des contraintes permettant ainsi de déterminer l’ensemble des systèmes valides. Dans l’exemple de la figure 2.9, les caractéristiques InfraredDetector et volumetricDetector sont liées par une contrainte de type or comme le montre le modèle de la figue 2.9(a), alors que les mêmes caractéristiques sont liées par une contrainte de type xor dans le modèle de la figure 2.9.(b).
Pour décider de la contrainte résultante de la fusion des deux contraintes précédentes, les auteurs proposent un ensemble de règles de fusion. Ces règles calculent à partir des contraintes des modèles fusionnés les nouvelles contraintes reliant les caractéristiques du modèle de fusion. Il s’agit de calculer la contrainte prédominante des deux contraintes à fusionner selon la sémantique de fusion choisie (c’est-à-dire union ou intersection). Par exemple dans la figure 2.9. (a) les contraintes à fusionner sont de types respectifs or et xor. La règle de fusion dans ce cas identifie la contrainte résultante de type or comme le montre le modèle résultant de la figure 2.9. (c).
Sensing Infrared Detector: Infrared Detector Volumetric Detector: Volumetric Detector
Bien que les règles proposées permettent de fusionner les contraintes, elles restent limitées aux contraintes de types and, or et xor. Les contraintes transversales qui existent entre les caractéristiques ne sont pas traitées. Par exemple les contraintes de type implication ne sont pas gérées durant la fusion. Ce type de contraintes spécifie que la présence d’une caractéristique dans un système valide implique la présence d’une ou plusieurs autres caractéristiques dans le même système valide.
De même pour les contraintes de type équivalence qui ne sont pas traitées durant la fusion. Ce type de contraintes spécifie la coprésence de toutes les caractéristiques dans un même système valide, si l’une d’entre elles est présente dans ce système et inversement. Contrairement à la fusion des contraintes, la fusion des caractéristiques qui appartiennent aux modèles d’entrée n’est pas réalisée de manière explicite. Elle est incluse dans le traitement de fusion des contraintes sans précisions supplémentaires.
– Opérateur d’agrégation : cet opérateur est utilisé pour produire de nouveaux modèles de caractéristiques en reliant d’autres modèles existants par des contraintes transversales. La proposition d’agrégation se limite à rassembler les arbres de caractéristiques en entrée sous une nouvelle caractéristique racine du modèle d’agrégation résultant. Dans l’exemple de la figure 2.10, l’agrégation des modèles de caractéristiques InHomeSecurity et Alarm se résume simplement à créer une nouvelle racine source, Security, qui regroupe les deux modèles d’entrée en regroupant leurs caractéristiques racines.
Dans le contexte des modèles de caractéristiques, on ne soulève pas de questions sur la faisabilité de connecter des caractéristiques variables appartenant aux modèles dont ils réalisent l’agrégation. De même pour la gestion de la variabilité de ces caractéristiques ainsi que les contraintes qui permettent de les relier. Toutefois, ces questions représentent des points d’interrogation dans le cas d’utilisation de l’opérateur d’agrégation pour d’autres modèles comme par exemple des modèles UML. La compatibilité entre les éléments des modèles d’entrée, la gestion de la variabilité des éléments ainsi que les contraintes sont parmi les principaux problèmes à résoudre.
|
Approche selon la superposition de codes
Apel et al. [44][45] proposent d’organiser les éléments structurels des caractéristiques en utilisant le mécanisme de FST (Feature Structure Tree). La fusion des caractéristiques revient alors à fusionner leurs FSTs correspondantes. La proposition de la fusion se base sur le mécanisme de superposition. La superposition permet la fusion des fragments de codes correspondants aux différentes caractéristiques. C’est un processus de composition récursive d’arbres par composition des noeuds qui se situent au même niveau en partant de la racine.
Les figures 2.11 et 2.12 montrent les modèles de caractéristiques et les fragments de code qui leurs sont correspondent respectivement. La figure 2.11 représente l’arbre de caractéristiques de la ligne de produits InHomeSecurity du fragment de code à gauche dans la figure. La ligne de produits inclut une détection intérieure représentée par la caractéristique InHomeDetection et la caractéristique de détection de mouvement Sensing qui inclut un détecteur infrarouge InfraredDetector et un détecteur volumétrique VolumetricDetector. Les différentes caractéristiques représentent des éléments du code correspondant.
De même, la figure 2.12 représente l’arbre de caractéristiques de la ligne de produits InHomeSecurity du bout de code à gauche dans la figure. La ligne de produits inclut une détection intérieure représentée par la caractéristique InHomeDetection et de la caractéristique de détection de mouvement Sensing qui inclut un détecteur infrarouge InfraredDetector et un détecteur de 160 degré 160DegreeDetector. Les différentes caractéristiques représentent des éléments du code correspondant.
En s’appuyant sur le mécanisme de superposition, la composition des fragments de code de la figure 2.11 et la figure 2.12 implique la composition par superposition des modèles de caractéristiques correspondants. La figure 2.13 montre le résultat de cette composition au niveau code et au niveau modèle de caractéristiques.
Un modèle de caractéristiques est « une hiérarchie de caractéristiques avec variabilité » [46]. Il peut donc être représenté par un FST avec variabilité. Cependant, la proposition ne prend pas en considération la variabilité des caractéristiques qui appartiennent aux modèles à fusionner. L’information de variabilité n’est donc pas gérée durant la fusion. De même, la proposition ne traite pas la fusion des contraintes associées aux modèles d’entrée. Les auteurs proposent de fusionner des modèles UML non annotés par la variabilité en utilisant le mécanisme de superposition. Leur critère de correspondance entre les éléments à fusionner se base sur le nom, le type ainsi que la position dans le modèle.
Cependant, ce critère représente une faiblesse dans certains cas. Prenons par exemple le modèle de structure composite où des classes composites incluent des propriétés de nature différentes comme les ports, parts et connecteurs par exemple. Nous reprenons l’exemple de Sensing présenté dans la figure 2.7. Supposons que les modèles à fusionner consistent en deux classes composites nommées Sensing dont chacune contient deux propriétés InfraredDetector et volumetricDetector. Le premier modèle représente la propriété volumetricDetector par une part typée par une classe VolumetricDetector. Le deuxième modèle représente la même propriété volumetricDetector par un port typé par une classe VolumetricDetector. En se basant sur le critère de correspondance mentionné, c’est-à-dire le nom, le type et la position des éléments, les propriétés volumetricDetector des deux modèles correspondent bien qu’elles soient représentées différemment (part et port). Ceci implique des problèmes dans leur fusion.
|
Tableau 2. Approches sur la composition des caractéristiques. Source : Ben Rhouma Aouina T. (2012) : Composition des modèles de lignes de produits logiciels, Thèse de doctorat, UNIVERSITÉ PARIS-SUD.
Une fois que nous aurons fait le tour des features, nous allons nous focaliser un peu plus sur la notion de point de variation.
- Notion de Point de variation
La variabilité pose souvent problème aux entreprises souhaitant développer une ligne de produits. En effet, il apparait plus compliqué de trouver des points de différenciation entre plusieurs produits issus d’une même LdP. Cette variabilité est étudiée et jugée avant la livraison du logiciel, c’est-à-dire qu’elle doit être définie et identifiée au préalable.
Pour pouvoir obtenir une bonne variabilité, il faut savoir rivaliser d’inventivité et trouver des idées ou des concepts novateurs à un grand nombre afin de les répartir entre les différents logiciels, permettant à leurs utilisateurs de détecter ce qui rend leur logiciel différent de celui des autres, dès lors qu’ils proviennent de la même LdP.
La variabilité dispose de deux dimensions :
– la dimension espace ou variabilité spatiale : variation entre plusieurs produits de la même famille
– la dimension temps ou variabilité temporelle : variation dans le temps des produits d’une version à une autre.
Selon Pohl et al., la variabilité temporelle est « l’existence de différentes versions d’un artéfact qui sont valides à des moments différents » et la variabilité spatiale représente « l’existence d’un artéfact sous différentes formes en même temps ». La variabilité spatiale est la plus côtoyée et la plus présente dans la conception des lignes de produits.
A noter que le principe de la réutilisation suppose qu’un logiciel est utilisé plusieurs fois dans la conception de produits de la même famille, d’où l’importance de la variabilité qui peut prouver qu’il s’agit bien de deux produits différents avec plusieurs similitudes. On peut prendre comme exemple de variabilité les options supplémentaires insérées dans les portables qui les différencient des autres.
La variabilité est également étudiée dans l’ingénierie de domaine. Jacobson et al. la définissent comme suit : « Un point de variation identifie un ou plusieurs emplacements auxquels la variation peut se produire » En d’autres termes, ce sont les différences présentes chez chaque logiciel dans une même ligne de produits. Il est constitué par ce qu’on appelle les « variants ».
On note souvent la présence des variabilités ou points de variation lorsque le produit en question détient plusieurs caractéristiques qui permettent de ne pas le confondre avec les autres produits issus de la même LdP que lui. Ces éléments peuvent être des petits détails tels que les options ou les fonctionnalités supplémentaires incluses dans les téléphones portables.
Lorsqu’une option est présente chez un modèle mais absente dans d’autres alors qu’ils proviennent d’une seule et même famille de produits, on dit qu’il détient une variabilité. Cette variabilité est définie durant la phase d’ingénierie de domaine et est définie par Weiss et Lai comme étant « une hypothèse sur la façon dont les membres d’une famille peuvent se différencier entre eux ». La variabilité représente les besoins spécifiques des utilisateurs, c’est-à-dire qu’en différenciant chaque modèle des autres, elle permet de satisfaire les besoins des usagers selon sa nature ou son type. A contrario, les similarités prouvent l’appartenance d’un produit à une ligne de produit avec des caractéristiques communes bien identifiées.
La conception d’une ligne de produits repose en grade partie sur a variabilité qui permet aux produits d’être similaires tout en restant différents. Elle représente d’ailleurs une contrainte majeure dans le façonnement de la LdP puisqu’elle doit être appréhendée durant la phase de modélisation et nécessite une gestion qui n’est assurée que par les professionnels en la matière.
Après avoir fait le tour de la question concernant les points de variation, les commonalités et les caractéristiques propres aux lignes de produits, une brève présentation des objectifs de la mise en place de ces dernières s’impose.
- Les objectifs de la mise en place des lignes de produit
Plusieurs entreprises ou institutions attestent de l’efficacité des lignes de produits, surtout en termes de production et d’atteinte d’objectif. En effet, es objectifs que les lignes de produits se fixent sont toujours en accord avec ceux de ces entreprises.
Les lignes de produits ont différents objectifs, les plus importants sont ceux de minimiser les coûts de production des logiciels et d’augmenter leur production en se servant d’anciens modèles. Grâce à ce concept, plusieurs grandes entreprises ont déjà su remonter la pente face aux périodes de crise en adoptant les lignes de produits et le concept a été adopté tant par les banques que par certains gouvernements tels que le Canada.
La ligne de produits vise également la réutilisation de certains éléments et évitent donc les gaspillages inutiles. Elles sont mises en place afin d’accroître le taux de bénéfice des entreprises et de faciliter leur processus de production de par son fonctionnement à la chaine.
D’autres objectifs peuvent encore être sur la ligne de mire de ces LdP, mais pour l’heure, nous allons parler des avantages et des inconvénients de ces dernières.
- Avantages et inconvénients des lignes de produit
Les lignes de produits logiciels ont une solution proposée par le génie logiciel. Elles sont connues pour leur efficacité mais présentent également quelques failles que nous allons discuter ci-dessous.
- Avantages sur le plan économique
Les lignes de produits offrent des avantages dans tous les domaines : au niveau de la production, de la concurrence, de l’économie, etc. Ceux que nous allons relater prochainement concernent exclusivement les bienfaits que la ligne de produits peut apporter sur le plan économique.
- Meilleure capitalisation de la connaissance en production
Les lignes de produits ont été adoptées dans les entreprises peu après leur apparition. Elles interviennent directement dans le cœur d’activité de ces dernières en touchant à la part de production et d’entrée de revenu. Leur visée est d’abord purement économique avec une baisse considérable du montant de production. De ce fait, les entreprises qui les adoptent profitent donc d’une entrée fructueuse d’argent tout en économisant et en réduisant les sorties d’argent en matière de production industrielle.
En même temps, les lignes de produits représentent une solution et une alternative à long terme permettant de créer divers produits ou logiciels en même temps. Ce qui permettra d’avoir de nombreux logiciels avec les mêmes propriétés et des variabilités en un temps calculé et permettra de calculer le rendement moyen en logiciels et ainsi de rendre régulière la production. Ceci peut faire éviter les crises et les contraintes liées à l’inflation des coûts des matières premières. Cependant produire les mêmes produits lors des baisses du marché ou lorsque la tendance varie et que les produits en question ne sont plus en vogue risque de faire perdre beaucoup de bénéfices. Il faut alors analyser constamment le marché.
- Amélioration de la qualité, diminution des coûts de conception et de production
Les lignes de produits présentent des avantages combinés tels que l’amélioration de la qualité, la diminution des coûts de conception et de production. En effet, lors de la conception d’une LdP, les critères relatifs à la commonalité et à la variabilité sont scrupuleusement surveillés, d’où la qualité toujours supérieure des produits proposés.
Et bien qu’il soit produit en masse, ce produit aura la chance d’être de qualité supérieure vu les séries de contrôle qu’il subira en vue d’attester de cette qualité.
Les entreprises adoptant les approches par la ligne de produits sont surtout avantagées par les multiples avantages que ce type de procédé leur permet, surtout en termes d’économie. En effet, les lignes de produits ont un mode de fonctionnement continu, c’est-à-dire que les entreprises réalisent une production à la chaine, mais de manière plus sophistiquée et évoluée. Cette production à la chaine évoluée se caractérise surtout par un meilleur suivi de chaque produit par les ingénieries de domaine et d’application.
Les produits sont alors conçus de manière innovante avec des contrôles et des suivis réguliers et optimaux. En général, les productions massives manquent en qualité, ce qui n’est pas le cas des produits membres d’une ligne de produits.
Le processus de réutilisation sur lequel repose toute conception de ligne de produits lui permet également de favoriser une réduction du coût de production du fait que les matières et ressources requises pour la production diminuent avec les composants réutilisables ou assets qui font la plus grosse part du travail. De ce fait, les moyens financiers destinés à la production sont de moins en moins sollicités, alors que les produits fabriqués sont plus nombreux et plus qualitatifs qu’auparavant. D’où la nécessité de suivre de plus près l’approche par les lignes de produits et de s’en servir pour faire fructifier la production et l’optimiser, avec un coût de moins en moins onéreux.
- Soutien à l’innovation
La ligne de produits est également à vocation novatrice, c’est-à-dire qu’elle favorise, par le désir incessant de créer des modèles uniques et similaires en même temps, l’esprit de création et d’invention. Dans le but de veiller à ce que tous les produits ne soient pas complètement identiques, leurs concepteurs intègrent, par exemple, des fonctionnalités de plus en plus révolutionnaires aux matériels et outils qu’ils conçoivent. On peut citer en exemple les systèmes de reconnaissance qui deviennent de plus en plus performants et requièrent une reconnaissance digitale à l’aide d’une empreinte de la main, d’un scan des yeux ou d’une reconnaissance vocale.
Les lignes de produits sont donc constamment partenaires de nouvelles idées et de nouvelles créations, rendant chaque produit conçu différent des autres par les options qu’il détient. Ce sont ces options qui suscitent le soutien à l’innovation car elles sont toujours performantes afin d’éviter de se laisser battre par les concurrents, de fidéliser les clients et de répondre à leurs attentes de plus en plus compliquées et ardentes.
Il convient de souligner dans cette sous-partie que pour mieux déjouer la concurrence et se rapprocher de la clientèle en présentant des concepts, des idées ou des façons de voir novateurs, les acteurs dans la conception des lignes de produits doivent avoir les compétences requises à ces tâches.
- Réduction du time-to-market
Le time to market est le terme caractérisant le temps qu’il faut pour concevoir et réaliser un projet avant de le lancer sur le marché. C’est donc une extension du temps de production. Le time-to-market est un des critères de sélection dans la production puisqu’il impacte fortement sur les bénéfices te revenus que la vente d’un produit peut générer. En d’autres termes, savoir gérer le time-to-market permet aux entreprises d’accroître la rentabilité d’un produit et de gagner une longueur d’avance par rapport aux concurrents.
La ligne de produits permet de réduire considérablement le time-to-market puisqu’elle favorise la production en groupe d’un produit, c’est-à-dire qu’on ne se focalise plus sur la conception d’un seul produit pendant une période donnée pour ensuite concevoir un autre produit avec les mêmes caractéristiques que lui selon le même délai imparti. La ligne de produits réduit le temps de production d’une gamme de produits et permet d’économiser ce temps au profit d’une mise en marché plus tôt que si on avait conçu les produits un à un.
Une fois ces avantages économiques des lignes de produits relatés, nous allons maintenant nous concentrer sur les avantages globaux de la mise en application de l’approche par les lignes de produits.
- Avantages sur d’autres plans
Dans cette sous-partie, nous allons évoquer brièvement les avantages que les lignes de produits peuvent procurer en dehors des bienfaits économiques.
- Favorisation des découvertes et innovations
Comme nous l’avons déjà mentionné un peu plus haut, les lignes de produits sont favorables aux découvertes et aux innovations du fait qu’elles incitent à la création et aux idées nouvelles grâce aux variabilités qui doivent figurer dans chaque produit. Pour illustrer notre hypothèse, prenons l’exemple des téléphones mobiles Nokia qui, d’année ne année, intègrent une langue nouvelle faisant passer le nombre de langues disponibles dans ces petits appareils à plus de 60 à l’heure actuelle.
De ce fait, leurs utilisateurs dans de s pays spécifiques peuvent donc se servir de leurs portables en utilisant leur propre langue au lie d’être obligés de se servir de la langue standard qui est l’anglais.
En outre, on peut aussi prendre l’exemple des innovations et découvertes en matière de téléphonie mobile comme la possibilité de recharger leur batterie à l’énergie solaire, leur faculté à indiquer la géo localisation des utilisateurs grâce à leur fonctionnalité GPS, au développement de plusieurs applications telles que Facebook, Instagram ou Whatsapp qui sont des réseaux sociaux permettant aux gens du monde entier de se communiquer, de s’échanger des informations, des photos, et de se parler via un téléphone mobile.
- Optimisation de l’effort de développement et de test par rapport à la diversité de l’offre de produits
Les lignes de produits logiciels sot également réputés pour leur faculté à accentuer, voire même à optimiser l’effort de développement et de test par rapport à la diversité de l’offre de produits. Chaque produit membre d’une ligne de produits est donc certifié de qualité puisque des tests effectués en ingénierie de domaine et en ingénierie d’application permettent de vérifier leurs compétences, de détecter des anomalies ou d’éventuels défauts de construction et d’y remédier avant le lancement sr le marché.
En d’autres mots, puisque les produits constitutifs de la LdP sont toujours en grand nombre et qu’ils sont presque identiques, ils requièrent alors une vérification plus minutieuse et des tests successifs et répétés afin de garantir la qualité de chacun d’entre eux.
- Optimisation de la gestion des défauts en permettant que la correction d’un défaut constaté sur un produit bénéficie aux produits « similaires »
De même, on remarque que la similarité des produits membres d’une LdP renforce la gestion des défauts en permettant que la correction d’un défaut sur un produit bénéficie aux produits similaires. Chaque produit issu d’une même LdP est donc soumis aux mêmes tests et à la même vérification afin de garantir sa conformité aux autres et de corriger ses défauts par rapport à ses « semblables ».
Dans cette optique, on note plus d’effort de la part des entreprises dans la correction des défauts relatifs à chaque produit du fait quelle sont soucieuses de se démarquer des concurrents et de garder une image positive d’elles-mêmes aux yeux de la clientèle.
Nous avons vu dans cette sous-section que les lignes de produits ont un effet positif sur la production, la mise en marché, la vente, etc. d’un produit fabriqué en plusieurs modèles détenant chacun ses particularités et ses points communs. Malgré l’existence des ces avantages indéniables, les LdP ont aussi des points faibles et plusieurs contraintes et besoins impactent négativement sur leur mise en place.
- Les contraintes et besoins liés à sa mise en place
- Les contraintes liées à la définition d’une architecture globale au niveau du domaine
Les lignes de produits ont un niveau d’exigence élevé en ce qui concerne l’architecture globale. En général, cette architecture doit être la même pour tous les produits. Il s’agit de l’architecture générique qui sera la base de toutes les architectures de tous les produits membres d’une seule et même ligne de produits. Sa mise en place pose souvent problème pour les concepteurs de la ligne de produits puisque les similarités entre les produits sont plutôt faciles à établir que les variabilités.
En effet, il faut savoir juger d’une fonction qui sera bien accueillie par le public, qui devra être différente de celles des concurrents et qui devra surtout être novatrice et propre au produit. En général, les complications majeures apparaissent souvent au niveau de la conception de cette architecture globale rendant la LdP difficile à mettre en place.
- Les contraintes au niveau du pilotage du domaine pour maintenir la cohérence des produits
Il en est de même pour le pilotage du domaine pour maintenir la cohérence des produits. Les contraintes à ce niveau sont surtout liées à la modélisation des variabilités, une des principales difficultés rencontrées lors d la modélisation, de la composition et de la conception des modèles membres d’une même ligne de produit. Ces contraintes sont surtout identifiées dans les variabilités spatiales.
Les contraintes liées à l’ingénierie de domaine relèvent du souci de trouver des éléments ou des options qui pourraient différencier chaque produit des autres. Cette contrainte est majeure dans la mesure où toute la conception même de la LdP repose sur la faculté même du concepteur à dénicher des points de variation et des éléments différents à insérer dans chaque modèle.
Après avoir identifié les contraintes liées à la mise en place des LdP, nous allons maintenant nous tourner vers trois exemples d’outils de gestion de lignes de produits : Requitim, Gears et Pure Variants.
- Les outils de gestion de lignes de produits
- Requitim (Cortim) ou REquirements Management Toolkit by CorTIM
Requitim est un logiciel développé par CORTIM. Il permet de faciliter la gestion des exigences dans la conception des lignes de produits en se basant sur un processus bien défini. Les outils REQUITIM sont des add-ons du logiciel de gestion des exigences Rational DOORS®, et sont indépendant des uns des autres. (In : site officiel http://www.requitim.com/).
Requitim dispose de deux outils principaux :
- Data Model Editor et
- Requirements Management.
Le Data Model Editor permet de voir la globalité des données d’un projet avec des tâches spécifiques :
- Identifier si les modules DOORS® sont reliés par le bon type de lien et dans le bon sens
- Filtrer la visualisation sur un type de lien
- Ouvrir un module DOORS® depuis l’interface du « Data Model Editor »
- Détecter la présence de liens du type « DOORS Link »
- Maîtriser la complexité d’un projet DOORS® (http://www.requitim.com/?mod=Data_Model_Editor)
La figure ci-dessous est un « aperçu des compétences de ce logiciel » qui, placé sur un module, est capable de visionner tout l’aspect de l’environnement qi l’entoure et d’en définir chaque détail.
Source : site officiel Requitim : http://www.requitim.com/?mod=Data_Model_Editor
Le Requirements Management, tout comme le Data Model Editor, est un outil complémentaire à DOORS®. Son rôle dans la gestion des la ligne de produits est de gérer les exigences en termes d’évolution et de circuit d’approbation en soutenant le processus mis en place à cette fin durant la conception d’un modèle. Cet outil facilite le travail du concepteur qui est alors exempté de tâches complexes et longues telles que la numérotation des exigences, le changement de maturité ou le versionnement. (In : http://www.requitim.com/?mod=Requirements_Management)
Requitim est aussi efficace grâce à sa capacité à manipuler les exigences, son rôle principal. La figure suivante présente les actions qu’il utilise pour optimiser la manipulation des exigences :
Figure 5. Actions du Requirements Management. Source : http://www.requitim.com/?mod=Requirements_Management
En somme, le Data Model Editor est un outil de visualisation des données d’un projet, utilisé pour visualiser l’environnement de conception d’un modèle de produit, tandis qu’un Requirements Management est un outil de management des exigences, conçu pour gérer et manipuler les exigences dans un modèle.
- Gears (BigLever Software Gears)
Gears est un outil d’ingénierie, un logiciel BigLever’s Gears Product Line Engineering Tool and Lifecycle Framework™ permettant d’automatiser la ligne de produits en rendant automatique la conception d’une multitude de modèles basée sur la réutilisation d’un asset plutôt que d’utiliser la configuration et la conception manuelle d’une nué e de modèle composant une LdP. Il permet de créer une ligne de production automatisée axée autour de trois éléments :
- Configurable Assetsou Assets configurables qui sont des systèmes configurables et des artefacts logiciels tels que le code source, les exigences, les modèles et les cas de tests conçus pour être partagés à travers le portfolio de la gamme de produits,
- Feature Profilesou profils de caractéristique, un élément permettant de modéliser chaque produit dans le portfolio en termes de choix de fonctions optionnelles et variables spécifiées pour la ligne de produits,
- Product Configurator ou Configurateur de produit, un élément assemble et configure automatiquement les systèmes et les assets logiciels – y compris les exigences, conception, développement et essais – guidés par des profils de caractéristiques des produits, afin de produire des produits du portfolio.
Etant un logiciel d’ingénierie de ligne de produits, BigLever Software Gears présente des avantages de taille :
- Une augmentation de la portée de la diversité des produits à l’échelle des différents produits qui peuvent être livrés de manière efficace dans une ligne de produits,
- Une réduction des coûts et des frais généraux par-développement de produits et des marges bénéficiaires plus élevées,
- Une réduction des délais de commercialisation pour les produits nouveaux et mis à jour, et une agilité accrue pour réagir aux nouvelles opportunités et à l’évolution des conditions du marché,
- Une augmentation de la qualité des produits, une réduction de la densité de défauts et une meilleure gestion des risques.
- Pure Variants (Pure Systems)
Le Pure Variants ou Pure Systems est un logiciel permettant de gérer les variables. Ses objectifs sont :
- Une réalisation efficace de solutions logicielles sur mesure
- Une gestion des tâches complexes,
- Une transformation des exigences et contraintes en solutions,
- Résoudre automatiquement les conflits,
- Une application basée sur le logiciel Eclipse,
- Une obtention de la copie d’évaluation le jour-même et
- Une obtention d’une communauté de variables pures. (In : http://www.pure-systems.com/pure_variants.49.0.html)
Pure Variants permet le développement de logiciels de solution sur mesure. Il intervient dans le processus de développement d’un produit en l’intégrant parfaitement tout en restant indépendant du langage de programmation. Il décrit et gère efficacement toutes les parties de produits logiciels avec leurs composants, restrictions et conditions d’utilisation. Il crée un ensemble d’informations pour créer des solutions automatiques à partir des caractéristiques choisies. De plus, il favorise un processus de développement de produit plus efficace, plus rapide et plus fiable.
Le premier chapitre de ce mémoire intitulé « Etat de l’art des lignes de produits » est entièrement voué à la compréhension de la notion de ligne de produits, des différentes ingénieries qui permettent la conception des modèles membres d’une LdP et une connaissance des outils de gestion de la LdP.
Nous avons vu dans ce chapitre qu’une ligne de produits logiciels est composée de plusieurs logiciels qui sont appelés membres de la LdP. Ces modèles sont conçus en masse grâce à un processus complexe de configuration, de composition et de modélisation. Les modèles ou logiciels membres d’une LdP logiciel sont composés d’éléments similaires appelés commonalités ou similarité et d’éléments de différenciation appelés variabilités.
Les similarités sont des caractéristiques communes à tous les logiciels tandis que les variabilités sont des caractéristiques uniques dans chaque produit le permettant de se distinguer des autres. Le principe de gestion d’une ligne de produit repose donc essentiellement sur la gestion de ces variabilités qui attestent de l’unicité de chaque produit du fait que chaque modèle détient une particularité et des options adaptées à un genre spécifique d’utilisateur. Les ingénieries de la ligne de produit permettent de développer ces variabilités (ingénierie de domaine).
Cette ingénierie de domaine permet aussi de concevoir les assets, les éléments réutilisables qui serviront lors de la phase d’ingénierie d’application. Pour détecter les éléments similaires et les éléments de différenciation dans un modèle ou dans un produit, on utilise le FODA, un diagramme en forme d’arbre permettant de dégager les différentes caractéristiques obligatoires, optionnelles et facultatives dans un produit. A noter que la conception d’une ligne de produits est également majoritairement basée sur la réutilisation.
L’approche par les lignes de produit permet une conception rapide, simplifiée et efficace de plusieurs produits en même temps avec un gain de temps considérable, un coût de production minimal et une qualité optimisée des produits. Le gain de temps se traduit par la réutilisation qui consiste à utiliser des composants réutilisables ou assets qui vont constituer les caractéristiques communes à tous les produits ou similarités. Le coût de production repose aussi sur la réutilisation qui évite de façonner un produit à partir de zéro et qui, en plus, facilite la production d’une multitude de produits simultanément.
Enfin, la qualité de production optimisée est traduite par la recherche constante d’innovation due à l’obligation de trouver des variabilités pour chaque produit, un défi encore très mal géré dans la conception d’une ligne de produits. Tous ces avantages de la ligne de produits sont favorisés par des outils de gestion de la LdP tels que le Pure Variants, le BigLever Software Gears ou le Requitim.
Après avoir longuement discuté de l’état de l’art des lignes de produits, nous allons maintenant entrer en profondeur dans le développement de notre problématique en nous focalisant entièrement sur l’état de l’art des méthodes de développement des applications web et la conception des architectures des systèmes d’informations web ou SIW.
Chapitre 2. Etat de l’art des méthodes de développement des applications Web et conception des architectures des systèmes d’informations Web
Ce chapitre est un long passage consacré aux méthodes de développement des applications Web et à la conception des architectures des systèmes d’information. Pour mener à bien notre étude, il importe de définir préalablement ce qu’on entend par système d’information avant de nous focaliser sur lesdites méthodes.
Actuellement, l’information se répand et se diffuse partout grâce aux applications web que ce soit grâce aux méthodes Intranet, Extranet ou Internet. L’ère que nous vivons incite grandement les entreprises spécialisées dans tous les domaines, y compris dans celui du développement d’application web, de se servir du Web pour promouvoir leurs activités et pour marquer leur visibilité par rapport aux concurrents. On note actuellement la recrudescence d’applications et de systèmes censés favoriser le développement interne de nombreux groupes industriels tels que ceux dédiés à l’importation et à l’exportation des données en ligne.
Le Web 2.0 est l’application web qui a fortement révolutionné l’usage des applications web dans les industries. Elle a permis de rendre possible l’utilisation de plusieurs serveurs au lieu de se servir de plusieurs ordinateurs à la fois. De plus, elle a aussi contribué à développé et à concevoir les mêmes systèmes que ceux des Desktops jadis utilisés en guise d’application web. Grâce au développement et à la mise en marché en masse du Web 2.0, les applications Web ont pris d’assaut le marché en étant de plus en plus évolutives et complexes (Kadri).
Le développement web est un concept découvert depuis plusieurs décennies, mais le terme n’a été officialisé qu’en 1998, lors de la conférence d’ACM sur les Hypertextes et les hypermédias. L’ingénierie du développement web rejoint la discipline du développement de logiciel avec plus de modernité et de technologie.
Selon Jim Conallen : «L’application Web est un ensemble de formulaires et de pages HTML générées dynamiquement (au moins en partie), et qui constitue une application métier. L’exemple le plus simple est celui d’une horloge: en cliquant sur un lien ou un bouton on obtient en retour l’heure courante. Cette dernière bénéficie d’avantages indéniables tels qu’un déploiement beaucoup plus aisé qu’en mode client serveur et un accès universel à moindre coût. L’interface privilégiée est celle du client léger, mais on pourra lui associer d’autres technologies si des interfaces encore plus riches sont nécessaires. La pierre angulaire d’une application Web est le serveur d’applications. »
Les applications mises sur le web et basées sur celui-ci sont diverses. Conallen décrit les applications web de la manière suivante : « les applications web résultent de l’utilisation de sites et de systèmes web » et définit un environnement à la fois technologique et virtuel du fait que le web est quand même un concept virtuel. Ainsi, on parle de système web, une infrastructure permettant d’échanger des informations d’un ordinateur à un autre ou de plusieurs ordinateurs à d’autres. Il est composé d’éléments essentiels tels que :
– le réseau, qui relie physiquement les ordinateurs,
– un poste client doté d’un navigateur, i.e. un logiciel permettant d’afficher localement les documents hébergés sur d’autres ordinateurs du réseau,
– un poste hôte sur lequel un service (ou démon), appelé serveur Web, permet de localiser et de retourner les informations demandées par le client au moyen de requêtes. (Villanova-Oliver)
Le lien hypertexte permet de faire fonctionner une application web. En effet, il pourvoit à la mise en relation des différentes pages web entre elles via un réseau de liens. Dans une application web, on trouve également un serveur d’application web qui permet aux utilisateurs d’effectuer d’autres tâches en dehors de la simple navigation.
A noter cependant que les applications web présentent une différence par rapport aux sites web. Baresi et al. font état de cette différence en attribuant deux dimensions au site web : celles d’information et de navigation, et d’ajouter une troisième dimension en plus de ces deux là à l’application web qui est la dimension d’opération. Conallen appuie cette hypothèse en renchérissant sur la faculté opérationnelle et sur l’aspect manipulable de l’application web. Il la décrit comme étant plus polyvalente et plus complexe, avec une possibilité d’effectuer des tâches et opération de création, de développement ou de suppression qui ne sont pas faisables sur un simple site web.
Cette complexité et cette polyvalence des applications web se traduisent par exemple par le fait de pouvoir s’enregistrer en tant qu’utilisateur via un nom d’utilisateur et un mot de passe sur un serveur grâce à la fenêtre ou au volet dédié à cet effet sur la page d’application web. Cet enregistrement pourvoit au stockage et à la sauvegarde de données sur le serveur, un fait improbable via un site web. L’avancée du temps a également permis aux applications web de se démarquer et d’évoluer, d’où l’apparition en masse d’applications web spécialisées dans le fonctionnement et la gestion d’entreprises.
En appui aux travaux de Conallen, une autre classification des applications web émerge [Mecc 99). Elle sous-entend aussi la complexité des applications web en référence à la gestion de données et aux offres de services par les sites web via l’application proprement dite. Il s’agit ici de la complexité des données et de la complexité des services qui ont permis à [Mecc99] de soulever quatre catégories :
– les sites de présence sur le Web sont caractérisés par un faible degré de complexité tant en terme de données que de services. Leur objectif concerne principalement la mise en ligne d’informations, à des fins publicitaires par exemple, ou résultant d’une volonté de diffuser des informations diverses (activités d’une association, présentations de manifestations, informations personnelles, etc.). Généralement constitués d’un petit nombre de pages, ces sites sont principalement construits à l’aide d’éditeurs HTML et ne s’appuient quasiment pas sur des techniques de développement ad-hoc.
|
– les sites « catalogues » ou à forte intensité de données (data-intensive Web sites) sont caractérisés par le fait qu’ils publient une masse importante de données, selon une structure hypertexte complexe. Ils n’offrent en revanche pas ou peu de services.
|
– les sites orientés services ont vocation à fournir des services spécifiques tels que ceux offerts par les moteurs de recherche3 ou les applications de messagerie électronique. De tels sites peuvent reposer sur des bases de données de taille conséquente, mais la structure des données et de l’hypertexte reste simple. La complexité est donc davantage liée aux applications sous-jacentes qui garantissent les services, et c’est en général autour de ces aspects que s’oriente le développement de tels sites. |
– les Systèmes d’Information basés sur le Web (SIW) constituent la quatrième catégorie de sites Web. Ils combinent la mise à disposition et la gestion de données complexes avec des services interactifs sophistiqués. Les applications de commerce électronique et les SI des organisations entrent dans cette catégorie. |
Tableau. Source : Villanova-Oliver M. (2002) : Adaptabilité dans les systèmes d’information sur le web : Modélisation et mise en œuvre de l’accès progressif. Thèse pour l’obtention du grade de docteur en informatique, Institut National Polytechnique de Grenoble.
Cependant, la fiabilité des applications web est souvent mise à l’épreuve, notamment à cause du développement et des exigences de plus en plus complexes du marché, de la compétition et des opérations de transactions monétaires appuyées par des fraudes et des arnaques en tous genres. En outre, FLE(1999) détecte une anomalie chez certaines applications web mal conçues et déficientes du point de vue navigabilité, traçabilité et fonctionnalité. En outre, les applications web et les applications traditionnelles présentent des différences indéniables surtout en termes d’architecture, de qualité, de contrôle et de maintenance (Villanova-Oliver, 2002).
Yan (1998) détecte deux aspects pertinents d’une application web : les aspects statiques et faciles et les aspects dynamiques plus complexes regroupant les serveurs web et les bases de données serveurs Open DataBase Connection ou ODBC ou Java DataBase Connection (JDBC).
La complexité du développement et de la gestion des applications web a conduit à opérer des séries de tests performants en vue de valider les applications Web. Hélas, ces tests ne sont pas toujours de haut niveau et manquent souvent de bonne finalisation. Ces tests doivent être effectués à l’aide d’outils spécifiques compliqués à manipuler et souvent mis à l’épreuve face à la dimension statique des applications web. (Adnane, 2006).
La section suivante est une présentation des méthodes de conception des applications Web entièrement inspirée et basée sur les travaux de Marlène Villanova-Oliver pour sa thèse de doctorat en 2002. Les travaux richement dirigés, élaborés et entretenus de cette chercheure sous servirons donc ici de base et seront nos sources pour toute cette partie.
- Les méthodes de conception des applications web
- RMM: Relationship Management ModelWebML: Web Modeling Language
Aperçu général de RMM
Le RMM (Relationship Management Methodology) [Isak95] est un outil de conception, et de construction des applications hypermédia qui permet de mieux assurer la gestion des éléments d’information. Il est recommandé dans [Isak95] grâce à sa capacité de structurer l’application des informations ainsi que de les modifier facilement. Il est par contre inutile de l’utiliser pour des applications faiblement structurées comme les applications artistiques ; cette approche est en revanche efficace pour les applications.
Les étapes de la méthode
L’objectif principal du RMM réside dans le développement intégral du logiciel tout en suivant ses processus. On retrouve principalement trois étapes destinées à la conception et quatre autres pour le développement.
La première étape de la conception des applications web s’agit de représenter le domaine d’application à travers un modèle E-R. L’étape suivante se soucie de concevoir les slices et de déterminer la façon dont le contenu des entités aux utilisateurs est représenté et quelles possibilités d’accès sont offertes. Pour faciliter cette seconde étape, un diagramme de slices est définit selon chaque entité et celui-ci mettra en évidence ses propres représentations.
A partir de cette étape, on obtient un artefact de schéma E-R+ correspondant au modèle obtenu par l’étape précédente qui a permis à chaque entité d’être remplacée par son diagramme de slices .C’est dans le système multimédia de présentation des informations ou l’hypermédia qu’un slice devient un nœud ou une page HTML. La troisième et dernière étape de la conception consiste à définir les aspects navigationnels de l’hypermédia. Des éléments en rapports avec le modèle E-R sont remplacés par des liens, regroupements ou index grâce aux indications suivantes :
- Etablissement d’un lien bidirectionnel pour une relation (1.1)
- Choix d’un index ou une visite guidée dans le cas d’une relation (1 ; n)
C’est à partir de ce stade que le modèle RMDM est défini et que les modalités d’accès finales sont représentées.
En ce qui concerne le processus de développement, la première étape consiste à décrire une règle de transformation afin de transformer les éléments du modèle RMDM en objets de la plate-forme retenue pour le développement c’est-à-dire l’établissement des index par des formulaires HTML. L’étape suivante met en valeur la conception de l’interface utilisateur et la description de l’apparence ainsi que la localisation de chaque élément du modèle RMDM.
La troisième étape du processus de développement est consacrée à la conception du comportement à l’exécution et à la prise de décision relative aux mécanismes de navigation et au suivi des actions de l’utilisateur. Le degré de volatilité des données est un critère de choix d’une génération dynamique des pages. Enfin vient la septième et dernière étape qui vise à construire et à soumettre des divers tests au système élaboré.
Limites et extensions de la version originale de RMM
Selon Isakowitz et d’autres auteurs du 18ème siècle, le RMM présente des inconvénients dans la possibilité de modélisation et de démarche. Voici une brève présentation de ses deux limites :
Limite des slices et leur évolution : les m-slices
On constate que les pages Web à caractère complexes ne sont pas suffisamment modélisées par le RMM, le slice est peu flexible car il ne peut être utilisé qu’à l’entité ce qui veut dire qu’il est impossible que des informations venants de plusieurs entités se classent dans un seul et unique slice.
Dans [Isak97a], un m-slice est créé pour combler le non flexibilité des slices, « m » se référant aux poupées russes emboitables ou Matriochkas. Ces dits m-slices favorisent le regroupement des informations proviennent de diverses sources afin de constituer des unités d’informations très complexes intégrant d’autres m-slices.
Redéfinition du processus de conception
Le RMM se limite au niveau conceptuel de l’hypermédia qui suit une approche dop-town. Le modèle E-R donne une forme initiale à l’hypermédia puis le sculpte à l’aide des diagrammes de slices évoqués auparavant. L’inexistence de primitives de modélisations favorisant la construction de l’application par des éléments encore plus petits est selon [Isak97b] un problème majeur qui peut être contré par les m-slices construits à partir des attributs et composés par des nœuds de l’hypermédia. Toutefois, une approche de conception devient ascendante ou bottom-up. Bref, Le problème se révèle être la difficulté de production d’un modèle d’application représentant clairement l’hypermédia.
Un diagramme de redéfinition des étapes conceptuelles est proposé par les auteurs [Isak97b].Ce dernier est un diagramme d’application servant à remplacer le type de modélisation résultant de la troisième étape du processus de conception. Le processus de changement et remplacement est ici appréhendé de manière ascendante et descendante :
- La structure générale de l’application est mise en évidence à partir de la description de la première version du diagramme d’application, les unités du diagramme sont départagées en m-slices par une approche
- Les m-slices construisent un diagramme d’application tout en respectant les étapes spécifiques par une approche de type ascendante [Isak97b].
Les deux approches descendante et ascendante combinées permettent de comparer les deux diagrammes d’application et d’identifier les problèmes tels l’oubli et suppression des m-slices .Ainsi, à partir de ses deux approches le concepteur affine ces spécifications d’une manière approximativement successive pour obtenir un diagramme d’application conformes aux approches précitées.
Conclusion sur RMM
RMM est à la fois une démarche de conception et de développement des hypermédias de structure à caractère stable et à contenu fréquemment modifié.
RMM est basé sur une image HDM et un modèle E-R le spécifie, quant à l’hypermédia, il est alors construit à partir du modèle RMDM grâce à la transformation des m-slices en nœuds et des relations en lien de navigation. Les apports de RMM par rapport à HDM, relèvent particulièrement d’une reproduction plus détaillée de l’utilisation des différents éléments du modèle. Néanmoins, RMM est la seule méthodologie qui met en exergue les diverses étapes de conception de l’hypermédia et la seule qui soit exécuter dans l’atelier RMCase ou Relationship Management Case Tool) [Diaz95] incluant les différentes intervalles du procédé.
Par ailleurs, RMM a fait l’objet d’offres qui veulent étendre les déterminations de liens de navigation dynamiques [Gabb98], aspects liés à la présentation [Fras01][Fras02]). La version originale de RMM est insuffisante en adaptation car les m-slices ne sont pas utilisés à des fins d’adaptation à différents utilisateurs : ils décrivent seulement la conception de la représentation informatique des utilisateurs.
- HERA
Aperçu général de Hera
Pour [Fras01], les possibilités de précision proposées par RMM dans un concept présentation sont éphémères. L’on reproche souvent au RMM de n’introduire que quelques éléments de représentation dans le diagramme d’application ce qui peut biaiser le modèle de conception et freiner le processus même.
Le projet Hera [Houb00] est selon les auteurs une étape de création de la présentation et des adaptations [Fras02] tenant en compte des spécificités matérielles, des choix de l’utilisateur et de l’historique de ses navigations.
Conception de la présentation
Elle se distingue par un niveau logique et un niveau représentatif .Au premier niveau, des spécificités de présentation plus évoluées que les liens de navigation dans RMM sont manifestées par le biais définition de nouveaux éléments de modélisation. Au second niveau présentatif, la production d’un diagramme de présentation est vivement conseillée pou faciliter le rapport des deux niveaux.
Le niveau logique
Ici, le diagramme d’application est doté de renforcements sous forme de relations se situant à un niveau élevé d’abstraction et des liens de navigations et les relations dans le temps et dans l’espace entre les mi-slices.
Ces relations sont parfois simples c’est-à-dire qu’elles ne proviennent que d’une seule source et sont parfois multiples ou provenant de plusieurs sources et cibles , en ce qui concerne cette pluralité de sources , plusieurs dispositions sont proposées sur la base des opérateurs AND et OR comme la configuration multi and target qui préconise que franchir le lien vise à atteindre les cibles [Fras01]).
On remarque aussi l’insertion des mi-slices dans d’autres et cette relation constitue ce qu’on appelle un internal mi-slice ou internal relationship. Elle requiert une spécification du contenu m-slice si son lien a été pénétré ; c’est dans ce cas qu’on évoque le terme de preserving et vanishing source relationship ou relation interne de préservation.
Les précisions au niveau logique exposent intégralement l’agencement de la présentation sans donner une représentation concrète et visible des sélections en termes d’organisation navigationnelle, spatiale et temporelle.
Le niveau présentation
Comme ce qui a été dit précédemment, le diagramme de représentation promeut la description de la conception de l’hypermédia .Les éléments obtenus durant le niveau logique deviennent par suite des éléments de présentation : les relations navigationnelles et l’expression matérialisent les liens établis entre m-slices et régions qui sont proprement définies comme une collection d’attributs véhiculant l’information du domaine référant l’élément source d’information. Chaque région est agrégée à une zone rectangulaire de l’écran, déterminée par une grandeur et une position.
La liaison m-slice-région peut affecter un même m-slice à différentes régions, ou différents m-slices à une même région. Elle ne doit en aucun cas conduire à une séparation d’une unité significative qu’un m-slice doit montrer.
Trois types de relations sont remarquées au niveau de la relation m-slice et régions qui ont chacun une morphologie et un caractère propre en liaison étroite avec sa réalisation : on trouve la relation de navigation qui sert à représenter les hyperliens de navigation, puis la relation temporelle exprimant la notion de durée dans la présentation qu’elle soit intrinsèque ou conceptrice, plus précisément, cette relation vise à déterminer la durée de l’affichage de l’information.
En dernier lieu, nous pouvons parler de la relation spatiale qui décrit l’emplacement des coordonnées d’une région cible par rapport à une région source. Notons que ces trois relations sont décrites par un indice de synchronisation.
La progression du processus de RMM résulte du [Fras01] qui élabore une spécificité de l’hypermédia. C’est au niveau logique du processus que sont incorporées les unités de modélisation de l’hypermédia et c’est au niveau spécifique que les éléments relatifs à la présentation sont pris en charge. Ces niveaux évitent que les choix de présentation ne soient extraits lors de la phase d’installation.
Conception des adaptations
La conception des adaptations est proposée dans [Fras02], elle détermine l’apparence des m-slices et concrétise la relation entre elles. L’adaptabilité et l’adaptativité sont les deux types d’adaptation envisagés. L’adaptabilité vise à exploiter des informations concernant les capacités d’accès aux dispositifs comme la taille de l’écran, la capacité de mémorisation ainsi que la vitesse du réseau et la mise en page que l’utilisateur souhaite.
L’adaptabilité se basant sur la définition d’un profil décrit en utilisant le vocabulaire CC/PP [Klyn01].Ce profil propose les caractéristiques matérielles et logicielles du navigateur en question et procède de manière à stocker le choix personnel de l’utilisateur ou le User Preference. L’augmentation des m-slices décrits de condition à évoquer ce qui est accepter pour afficher les m-slices .L’adaptability condition noue un lien entre le profil et la catégorisation des m-slices , elle fait en sorte que le m-slice soit intégré dans une page HTML lorsque les conditions d’associations sont acceptées par le dispositif de sortie.
L’adaptativité quant à elle est une adaptation se focalisant sur l’historique de la navigation d’un utilisateur. Les informations concernant les activités de l’utilisateur sont regroupées et mises à jour au fur et à mesure qu’il soit actif. Le modèle de l’utilisateur définit un ensemble de pairs attributs_ valeurs correspondant au concept et à la valeur que l’utilisateur y attribut. Les conditions d’adaptativité font partie de la valeur minimale d’intérêt accordée par rapport à l’utilité de présentation du m-slice, elles évaluent également la valeur d’un concept selon un utilisateur en fonction des pages qu’il a visitées. Lorsqu’un lien est consulté par l’utilisateur, le concept augmente automatiquement de valeur et doit être considéré par le concepteur.
Conclusion sur Hera
Hera est une étape importante dans la conception de l’hypermédia, elle facilite le passage du niveau logique à la phase de réalisation finale ou phase d’implémentation. Les capacités de modélisation selon Hera se classent en deux catégories bien distinctes :
- L’adaptabilité comme analyse statique de la présentation antérieure de la navigation
- L’adaptativité come analyse dynamique c’est-à-dire le changement de représentation navigationnelle. [Fras02]).
Ces deux modes déterminent la visibilité et l’aspect des m-slices, néanmoins l’adaptativité ne recourt qu’à l’aspect afin de réduire les inconvénients du RMM.
- WEBML
Le web Modeling language est une codification graphique ayant une syntaxe ou forme textuelle XML des applications web complexes Il permet en effet de sculpter les données, les pages qui la composent, la technique de navigation entre les pages, la présentation et l’individualisation par utilisateur. Le WebML procède par :
- L’assemblage des besoins
- La conception des données
- La création de l’hypertexte
- La conception de la présentation
- La conception des utilisateurs et groupes d’utilisateurs
- La phase de conception de la personnalisation
La phase de collecte des données vise à déterminer les objectifs principaux du site par rapport aux besoins de l’utilisateur, à identifier les utilisateurs cibles et à personnaliser le site.
La phase de collecte des données sert à créer le modèle de structure qui définit les liens, le domaine et données d’application comme les entités, les attributs et les différentes composantes. Elle n’est réalisable que grâce à un diagramme de type UML et un modèle XML.
La phase de création de l’hypertexte consiste à construire un modèle de conception et un modèle de navigation par l’architecture de l’application web. Le premier modèle construit le s nœuds en termes de page. Le second quant à lui décrit comment les pages et unités vont être liées entre elles et comment l’utilisateur pourra naviguer facilement à travers ces unités. En vue de cette facilité de navigation, deux liens contextuels et non contextuels sont à utiliser, ils permettent le transport d’information de l’unité initiale jusqu’ à l’unité d’objectif.
La phase de conception de la présentation est une phase durant la quelle on assemble les feuilles de styles ou lay out ainsi que la présentation spécifique du contenu. On distingue deux types de feuilles de styles : les non typées qui sont indépendantes au contenu, applicables sur n’importe qu’elle page et les styles typées qui sont spécifiques au contenu, applicables que sur une seule page.
La conception des utilisateurs et groupes d’utilisateurs décrit et spécifie les groupes ou types d’utilisateurs selon leur traits communs, , caractéristiques définies grâce aux propriétés des concepts du modèle structurel. C’est durant cette phase que l’on tente de délimiter le profil utilisateur.
Le profil utilisateur profite d’un UML et est structuré en interne c’est le cas du regroupement des attributs sous forme de composants. Le mot profil est ici associé à l’identité personnelle de l’utilisateur, à ses activités, les pages qu’il a dernièrement visitées, les items visités et les achats effectués. Ce profil est évolutif par rapport à la navigation.
La phase de conception de la personnalisation personnalise la page en fonction des données du profil utilisateur. On distingue deux types de personnalisations : d’abord la personnalisation déclarative parallèle au comportement de l’utilisateur, ensuite la personnalisation procédurale qui consiste à catégoriser l’utilisateur dans pour le personnaliser et le différencier des autres par exemple le client privilégié.
Etapes | Collecte des besoins | Conception des données | Conception de l’hypertexte | Conception de la présentation | Conception des utilisateurs et groupes d’utilisateurs | Conception de la personnalisation |
Artefacts produits | Objectifs du site, utilisateurs cibles, exemples de contenu, guides de styles, personnalisation, contraintes | Entités, attributs, composants, liens entre entités | Modèle de composition (nœuds, page, unité de contenu), Modèle de navigation (liens contextuels, liens non contextuels | Feuilles de styles typées, Feuilles de styles non typées | Profil utilisateur | Entités, Attributs, Composants (pour la personnalisation déclarative) et Règles métier (pour la personnalisation procédurale) |
Artefacts produits dans le cycle de vie selon la méthode WebML [Ceri 00]. Source : Xiong, 2008
Aperçu général de Web ML
Ce langage est utilisé dans l’approche de spécification par étapes consécutives et s’inscrit dans des travaux HDM Lite [Frat98] qui adapte les propositions du HDM à la généralité spécifique du web. A part ce HDM-Lite , on retrouve aussi le HDM –Lite W313 (Web-based Intelligent Information Infrastructure) [Ceri99] qui oriente le concept de dérivation et de personnalisation.
Web ML fait des représentations graphiques associées à une syntaxe XML afin de mieux présenter le site. Les articles concernant le webMl que nous avons étudiés [Ceri00a][Ceri00b] [Ceri01][Ceri02], révèlent qu’il existe une variation du nombre de dimensions.
Certaines dimensions sont à la base de l’approche car elles sont constamment présentes dans la littérature sur WebML et aboutissent aux modèles structurels, de déviation, de agencement, et de navigation. Les deux derniers modèles se classent dans le modèle hypertexte qui à lui seul arrive à définir la typologie de l’hypertexte. Une quatrième dimension de gestion des contenus est décrite dans le langage WebML de par les extensions des modèles de composition et de navigation.
Le modèle structurel
Il permet de structurer les contenus inclus dans le site , ses éléments peuvent être des relations et entités qui désignent des connexions similaires entre les éléments. Une entité peut être hiérarchisée et peuvent avoir un identifiant unique représenté par un attribut nommés et typés. Les relations binaires expriment le rôle d’une entité source à une entité cible qui peuvent être influencées par une cardinalité que le WebML impose pour assure cette traduction de rôle.
Bref, le modèle structurel s’appuie sur une concordance et correspondance d’Entité /Relation. Les auteurs préconisent à la fois une approche objet pour satisfaire les contraintes liés à ce modèle.
Le modèle de dérivation
Obtenu à partir du modèle structurel, il consiste à rajouter dans le schéma préétablit des informations nécessaires à la redéfinition du regroupement des données ainsi que l’augmentation de la faculté d’expression. Il est exprimé par le biais des requêtes permettant de construire des représentations supplémentaires dont le contenu est définit intentionnellement. Les dérivations servent à transférer les attributs d’une entité vers une autre, à définir des caractéristiques calculés, à créer des entités découlées regroupant des objets aux propriétés communes. Un langage inspiré du chemin OQL nommé WebML-OQL, est défini pour cela.
Le modèle de composition
Le modèle de composition est utilisé pour délimiter le nombre de pages qu’un site peut constituer ainsi que les informations dont les pages sont dotées. Ce modèle offre une unité graphique et un contenu symbolisant une page de l’hypermédia. Ces unités aident à l’accomplissement de la détermination des pages grâce aux multiples possibilités qu’elles détiennent (possibilité d’intégration, de représentation des instances par instance, les visites guidées).
Le modèle de navigation
Le prochain modèle nous informe sur la formation de l’hypertexte à partir de la liaison des pages du modèle de liaison en s’appuyant sur les deux variantes suivantes :
- Les liens contextuels permettant de promouvoir une relation reflétant le schéma de la « sémantique d’application » entre les unités. Ce lien a pour rôle de porter l’information de l’unité source vers l’unité de destination tout en déterminant les objets à transporter vers cette source. Les objets transportés dépendent fortement de l’unité source, c’est le cas du Data Unit dont le contexte est l’identifiant de l’instance montrée dans l’unité au moment de l’activation du lien .Pour un Filter Unit par contre on parle de valeurs d’attributs de l’utilisateur conformément au formulaire associé.
- Les liens non contextuels est un moyen de relier librement les pages dans le site, librement veut ici dire qu’il y a indépendance des unités qu’elles émanent et de la sémantique associée aux concepts des unités. Prenons l’exemple d’une page du site reliée à la page d’accueil par un lien non contextuel.
Extensions apportées aux modèles de composition et de navigation
Pour supporter les modes d’utilisation à part la consultation des informations, des concepts pour la saisie de données et les initiatives ont été ajoutés à WebML [Ceri00b] .Les extensions dont nous parlons ici consistent à l’ajout, la modification et suppression des données. Le modèle de composition regroupe deux types d’unités appelées Data Entry Unit et Operation Unit ; le modèle de navigation lui, propose des liens spécifiques aux deux unités.
L’unité Data Entry Unit collecte, dans des champs précis les valeurs données en entrée qui seront ensuite utilisées comme paramètres opérationnels. La valeur d’un champ appelée constante est extraite d’une base d’informations par l’utilisateur. Une propriété appelée ‘activating’ est ensuite ajoutée aux liens du modèle afin d’indiquer que le lien résultant d’une telle unité active et requiert une opération. Un lien d’activation possède également des caractéristiques fondamentales favorisant le transfert des valeurs de paramètres du Data Entry Unit vers l’Operation Unit.
Inversement, une Operation Unit invoque une opération externe à l’application ou une opération pour la création, la modification et la suppression de contenu, et la création et la suppression de relations. Deux types de lien sont attachés en sortie d’une opération : d’une part , on a le OK-Link et d’une autre part on a KO-Link, qui indiquent vers quel élément du site aller si l’exécution de l’opération est en échec ou en succès.
La définition de la présentation
La présentation est l’apparence des pages du site définie dans le précédent modèle de composition [Ceri00a]. Les auteurs envisagent de recourir à des feuilles de styles communs indépendantes du contenu des pages et/ou de style granulaire plus fine qui s’appliquant à des notions spécifiques Pourtant, dans [Ceri01], on ne fait plus référence à un véritable modèle conceptuel spécifique à la présentation, mais à des dispositifs d’application de feuilles de styles XSL à des fichiers XML qui sont porteurs du contenu du site. Le modèle de présentation se synthétise alors à la précision des feuilles de style à relier aux fichiers de contenu.
La personnalisation
Deux entités désignées Group et User [Ceri00a] constituent le modèle Web ML, elles décrivent respectivement, un profil utilisateur ayant une certaine particularité et un utilisateur individuel. Ces entités sont reliées aux autres par des relations, structurées et agencées. Les entités Group et User sont pour gérer l’accès privée et personnel. Et pour contrôler cet accès, il est primordial de distinguer les utilisateurs enregistrés qui font partie d’une communauté définie selon leur besoin et les non enregistrés qui appartiennent à la classe everyone. Le site view ou la vision d’un site qui sont des constructions à partir du modèle structurel est défini selon le dispositif d’accès et l’optique de diffusion qui peut être soit un HTML ou un WML.
Pour ce qui est de la personnalisation, une vue du site peut être adaptée selon le profil d’un utilisateur, la personnalisation est donc appliquée de façon procédurale ou déclarative.
La personnalisation déclarative fait appel à des concepts d’entités et d’attributs qui se définissent selon les informations spécifiques à l’utilisateur. Le système trie, regroupe et récupère les informations de chaque utilisateur pour les utiliser lors de la spéculation du contenu des unités relatives aux notions découlés. Le calcul du prix d’un article, tient donc compte du pourcentage de remise accordé à l’utilisateur (information recueillie dans son profil), est réalisé de manière déclarative. La personnalisation procédurale repose sur une base XML proposée par WebML qui écrit les règles métiers représentées par un triplet événement- condition à remplir et l’action à entreprendre permettant le calcul et le stockage de données de l’utilisateur.
Processus de conception avec WebML
Le processus de conception nécessite la mobilisation de plusieurs techniciens compétents dont un expert des données pour la construction du modèle structurel, un architecte de l’application Web pour concevoir les pages, les unités et liens de navigation, un architecte du style Web pour les aspects relatifs à la présentation du site, et un administrateur Web pour la définition des utilisateurs, des groupes et de leur droits.
Tout d’abord, on procède par la collecte des besoins d’applications par la détermination des objectifs du site dont les contenus attendus et d’éléments de personnalisation. Notons que WebML ne consiste pas à donner des propositions relatives aux besoins. Ensuite vient la seconde étape de conception des données par l’expert des données qui détermine le modèle structurel et les dérivations essentielles.
Puis, on procède par la conception de l’hypertexte de manière générale en évaluant le nombre de visiteurs du site selon les groupes d’utilisateurs et leur d’accès. L’architecte met en évidence chaque page et leur unité composante ainsi que les liens. L’architecte procède par calcul approximatif la première vue du site et adopte un technique « copier-coller ». L’hypertexte est ensuite élaboré à partir d’une conception précise sur la définition des pages crées durant la précédente étape.
Des index et filtres qui facilitent l’accès aux informations sont introduits avec l’ajout de différents chemins d’accès par la suppression ou fractionnement des pages. L’administrateur web joue un rôle d’intégrateur d’aspects personnels et travaille le modèle structurel et sa dérivation pour y apporter des modifications car elle est jugée nécessaire.
L’étape finale correspond à la de présentation, et elle n’est abordée que lorsqu’il n’est plus nécessaire de retravailler les quatre modèles et quand l’ensemble des pages d’une vue du site est stable.
Conclusion sur WebML
Ø Notation pour la spécification conceptuelle des applications Web selon la dimension du contenu, sa gestion et la composition des pages.
- Mise en œuvre des capacités d’adaptabilité et d’adaptativité grâce à la description des règles et la recherche d’informations
- Approche modèle reposant sur le langage et s’appuyant sur un ensemble de concepts disponibles sous forme de représentations graphiques basées sur XML
- Démarche classée dans le Web Ratio Site Development Studio qui est un outil de conception commercial.
- HDM: Hypertext Design Model
Ce modèle se base sur le modèle entité-relation se prolongeant avec une organisation hiérarchisé [21].HDM il est à la fois un outil d’identification des composants atomiques hypermédia et un critère d’assemblage des structures, ce modèle se soucie en effet de concevoir les aspects en large et de décrire l’agencement de l’hypertexte en ne tenant pas compte de la mise en œuvre spécifique. L’entité représentée par les structures d’information est une information indépendante pouvant être relayé et supprimée de l’application.
Les entités sont assemblées dans des types d’entité comme le « Traviata » et l’Aida » qui appartiennent à l’entité « opéra musical »
Une des caractéristiques les plus remarquables de HDM est l’admission de différentes catégories de liens qui tiennent compte des différentes relations qui se présentent entre les éléments d’informatifs, tels que la capture des relations de domaine et des règles de navigation ou plus exactement le mode de déplacement de l’utilisateur sur la structure hypermédia. Des liens de perspective nous aide à associer ses unités à un composant, prenons l’exemple du « Le baptême de Crist / italien-texte » et « Le baptême de Crist / italien-image » qui sont associés à la composante « Le baptême de Crist ».
Bref, le modèle HDM est un groupement d’entités et de liens réels obéissant à des règles définies par le schéma HDM même. L’hypertexte est par conséquent constitué de données de navigation dont les guides et cartes de visites. Des liens se situant dans l’hyperbase ne sont pas mis en exergue dans le schéma mais peuvent recourir à un ajout dans l’application afin de donner un repère d’entrée pour l’utilisateur.
HDM et HDM2 permet la description du schéma mais ne fournit que quelques informations sur les étapes de conception et développement de l’hypermédia [26].Ils ne font que favoriser une méthode de développement proposée par HDM .Toutefois, c’est sur ce modèle que se fonde la gestion relationnelle RMM et l’Object-Oriented Hypermédia Design Model OOHDM.
- WSDM: Web Site Design Method
Aperçu général de WSDM
La conception d’un site web WSDM [DeTr98][Goed98] se différencie par la mise en valeur des souhaits du public cible. Au lieu de considérer les informations comme source de conception, WSDM spécule l’intérêt des utilisateurs : par opposition aux approches HDM, RMM, OOHDM-96, la proposition devient une approche justifiée par l’existence des utilisateurs et visiteurs d’un site. Il est primordiale d’étudier les attentes des cibles concernées afin d’améliorer et de répondre à leurs besoins.
Pour concevoir le WSDM, on doit tout d’abord passer par la « Mission Statement » qui vise à annoncer la mission tout en répondant aux questions suivantes : quels sont les objectifs du site et qui sont les cibles ? Les réponses obtenues de ces questions feront découler la classification et la caractérisation du public cible ou proprement dite la spécification des utilisateurs.
La conception se divise en trois phases : modélisation objet et domaine, modélisation fonctionnelle puis conception navigationnelle. Après la mission Statement, on passe à la conception en vue de l’implémentation pour terminer le WSDM par la phase d’implémentation du site dans l’environnement HTML.
Modélisation du public
La modélisation du public se subdivise en deux périodes. La classification des utilisateurs désignés dans [Cast01]) est menée à partir de l’étude des édits de mission du site lors de la première étape. Des classes utilisateurs sont donc identifiées et elles regroupent les utilisateurs qui ont une similarité de besoins en informations et en fonctions user requirements [Goed98]. Notons qu’un utilisateur ne peut pas faire partie de plusieurs classes. [Cast01] propose une approche arrangeant les catégories d’utilisateurs en hiérarchie.
De par ces catégories générales existent les sous-catégories ou perspectives se traduisant en sous- classes car elles partagent les mêmes usability requirements comme la langue utilisée, la compétence et les préférences utiles pour décrire les classes des utilisateurs [DeTr98].
Modélisation conceptuelle
Modélisation objet et modélisation du domaine
Elle intéresse la définition plus formelle des Usability Requirements évoquées dans les classes utilisateurs et perspectives par une notation OMT ou E-R. Une réunion d’objets conceptuels ou objects chunk est élaborée pour chaque Usability Requirements, elle montre les différents objets et leurs relations. Ces chunks sont classifiés en un modèle appelé User Object Model (UOM) qui attribue la représentation du domaine d’application pour une classe utilisateur particulière.
A partir de chaque UOM, un Modèle Objet Perspective (Perspective Object Model – POM) est déterminé lorsqu’il est juger nécessaire de donner des versions différentes de types d’objets conformément aux spécifications des perspectives. Le modèle du domaine est acquis lors d’une étape de modélisation qui se synchronise à une réunion de tous les UOM.
Conception Navigationnelle
Durant la conception navigationnelle, on essaye de produire un modèle de navigationnelle La seconde étape de la modélisation conceptuelle vise à produire le modèle de la navigation composée de navigation tracks décrivant la possibilité de . Ce modèle est composé de pistes de navigation dites navigation tracks qui décrivent les possibilités de progression à travers les données. Une association de navigation ou navigation chunk est spécifique selon chaque User Requirements .Les les pistes de navigation modélisent le site web.
Modélisation en vue de l’implémentation
Elle repose sur la définition des pages qui vont constituent le site en structure et apparence externe. WSDM recommande de suivre des règles de conception pour aboutir à site cohérent, convivial, attrayant. Par exemple, une page doit contenir des informations biens agencées pour que l’utilisateur ne soit pas dans un cas de surcharge, le concepteur doit aussi savoir guider son utilisateur par des points et signes de repérage.
Conclusion sur WSDM
- approche centrée sur l’utilisateur qui détermine ses besoins identifie des classes utilisateurs qui « indiquent » ces besoins.
- Description des variantes de classes utilisateurs pour alléger la modélisation des publics cibles.
- Inexistence de véritable modèle de l’utilisateur. Les informations des différents utilisateurs sont renvoyées au niveau du modèle de données.
- Construction des modèles objets, montrant ainsi une représentation du domaine d’application en concordance avec les particularités des variantes de classes.
- L’adaptation du WSDM crée un hypermédia correspondant aux exigences des différentes catégories d’utilisateurs
- Processus à vision statique de l’adaptation.
- OOHDM: Object-oriented Hypermedia Design Method
OOHDM (Object-Oriented Hypermedia Design Method) [Schwabe 98] est une approche basée sur des modèles pour finaliser des applications hypermédias. Il revêt quatre étapes dont la Modélisation conceptuelle, Conception de la navigation, Conception de l’interface abstraite et Implémentation.
Dans la phase de Modélisation conceptuelle, le domaine d’application est modélisé selon les principes de l’approche orientée objet avec une notation similaire à UML. L’objectif dans cette phase est de capturer la sémantique relative au domaine. Le résultat de cette étape est un ensemble de diagrammes de classes appelé ‘modèle conceptuel’ et représentant les différents concepts du domaine et les liens qu’il peut y avoir entre eux.
Dans la phase de Conception de la navigation, les nœuds et pages de navigation, les contextes de navigation ou ensemble de nœuds de navigation ainsi que les chemins de navigation sont identifiés à partir du modèle conceptuel. Cette identification se fait d’après le profil de l’utilisateur final et l’analyse de différents scénarios. Le produit résultant de cette phase est un diagramme de contexte représentant les contextes de navigation.
Dans la phase de Conception de l’interface abstraite, les objets de l’interface perçus par l’utilisateur sont spécifiés au moyen de l’ ADV (Abstract Data Views) [Cowan 95], une notation absolue pour les concepts de l’interface d’une application hypermédia. Ainsi chaque élément de l’interface est décrit par sa structure, ses rapports avec les objets de navigation, et ses effets face aux événements extérieurs.
Dans la phase d’Implémentation, l’application finale est codée selon l’ADV de la phase précédente. Les artefacts produits utilisés dans la méthode OOHDM sont présentés dans le Tableau 2.
|
Modélisation Conceptuelle | Conception de la navigation | Conception de l’interface abstraite | Implémentation |
Artefacts produits | Classes, sous systèmes, relations, attributs, perspectives | Nœuds, liens, structures d’accès, contextes de navigation, transformations navigationnelles | Objets de l’interface abstraite, réponses aux événements externes, transformations de l’interface | Pages Web |
Source : Xiong, 2008
Aperçu général de OOHDM
La méthode OOHDM (Object Oriented Hypermedia Design Methodology) [Schw96] [Schw98] s’inspire tout comme RMM du modèle HDM. Elle se particularise toutefois des méthodes précédentes par l’usage d’une démarche de conception orientée objet. Les premiers articles sur OOHDM [Schw96] révèlent que l’approche objet de renvoi est OMT [Rumb99]. Les prochaines articles laisse les auteurs dire que UML [Booc99][Rumb99] est acceptable de par sa qualité de standard [Ross99] et parce que leurs offres pour l’analyse des besoins [Güel00] s’en inspirent.
Pour les auteurs, l’approche objet est essentiellement indispensable dans le cas d’applications informationnelles sujettes à des transformations ou simultanément des calculs complexes sont réalisés. Ils proposent par conséquent d’exprimer les actions correspondantes par la méthode de classes. Quatre méthodes de conception font l’objet d’OOHDM mais dans [Güel00], les auteurs proposent une autre étape prolongeant le processus en amont des quatre autres.
Cette étape est consacrée à la collecte des besoins. OOHDM Le procédé se basé sur des spécifications permettant de connaitre les besoins des utilisateurs L’activité de conception tourne autour de la relation entre l’utilisateur et le système de navigation. Le processus initial de OOHDM recourt à une modification: les étapes sont analogues, mais la démarche et les spécifications produites sont plus précises ce qui est le plus remarqué durant modélisation conceptuelle et navigationnelle.
Les étapes d’OOHDM dans sa version proposée en 2000. Source : Villanova, 2002
Collecte des Besoins
L’identification des besoins permet par la suite de concevoir le schéma conceptuel et navigationnel c’est pourquoi cette étape est d’une importance majeure. La collecte des besoins est réalisée selon une succession de cinq étapes :
– Recherche des rôles au sens d’acteur dans UML et ainsi que les responsabilités qui doivent être tenues par l’application ;
– Catégorisation de scénarios ou descriptions narratives des tâches par les utilisateurs selon les fondements proposés dans [Caro95].
– Spécification des cas d’utilisation [Jaco99], chacun regroupant les scénarios décrivant la même responsabilité.
– Spécification des Diagrammes d’Interaction Utilisateur (User Interaction Diagram – UID) [Vila00a][Vila00b] qui capturent les interactions observables , entre un utilisateur et une application.
– Validation ou acceptation des cas d’utilisation et diagrammes d’interaction utilisateur à travers un entretien entre le concepteur et les utilisateurs impliqués.
Modélisation Conceptuelle
La modélisation conceptuelle établit le modèle conceptuel de l’application selon l’UML. Elle vise à appliquer des règles de modification UID pour acquérir un diagramme de classes représentatif du domaine d’application. Ces normes, détaillées dans [Vila00a][Vila00b], se fondent essentiellement sur les techniques courants de rationalisation des schéma définies dans [Elma94].
D’un point de vue général, le processus consiste, pour chaque UID, à trouver à partir des éléments qui le composent, les classes, les attributs de classes, et relations sémantiques entre classes.
Modélisation de la Navigation
Priorisée dans les deux versions OOHDM, elle est caractérisée par son essai de construction de modèle de navigation .Il s’agit notamment de faire une différence majeure par rapport aux propositions antécédentes et de considérer que les objets obtenus par navigation ne sont pas ceux du modèle conceptuel mais d’autres qui ont été élaborés par des mécanismes de vue ou à partir de quelques objets conceptuels. Le modèle navigation dans l’hypermédia sera obtenu à l’issue de différentes phases décrites ci-dessous.
Modélisation de la navigation correspondant à une tâche
Selon chaque fonction, les cas d’utilisation, scénarios, UID et du modèle conceptuel sont étudiés en vue de construire un contexte navigationnel [Schw96]. Ces contextes sont un moyen d’organisation de l’espace de navigation par la définition des unités constitués d’informations, de liens et d’éventuels autres. Ils disposent d’une structure de navigation interne comme la séquentielle et l’index, ainsi que d’un point d’entrée et des index reliés.
Les contextes navigationnels les plus ordinaires décrivent des réunions, en fonction des caractéristiques que les éléments doivent satisfaire et en fonction d’objets issus d’une unique classe. Des explications graphiques propres aux contextes sont données dans [Schw98] et l’idée générale est proposée dans [Guël00] pour pouvoir établir ces contextes.
Production du diagramme de contexte navigationnel de l’application
Cette phase consiste à élaborer un seul diagramme à partir des contextes navigationnels décrits pour chaque fonction. L’union des contextes est menée à bien et d’éventuels ajustements sont entreprises afin d’obtenir un diagramme adéquat reflétant les besoins des utilisateurs. Ce diagramme doit encore être affiné car il ne possède pas tous les traits propres à la navigation dans l’hypermédia
Spécification du modèle de navigation de l’application
La spécification repose sur un ensemble de références parmi lesquels figurent le diagramme final de contexte navigationnel et les cartes de précisions issus des étapes ultérieures.
Il y a tout d’abord un établissement du schéma des classes navigationnelles ou les nœuds qui décrivent le contenu à travers lequel l’utilisateur .Un nœud est une vue sur une ou certaines classes du modèle conceptuel, il possède des éléments obtenus à partir des liens de passation d’un nœud vers un autre.
Ces nœuds sont obtenus par des relations conceptuelles établissant des relations nouvelles. Un nœud peut être impliqué dans différents contextes. Il est jugé nécessaire d’exprimer un certain nombre de donnés qui sont complémentaires au contexte.
Pour cela, des classes spécifiques, appelées InContext [Schw96], sont définissent chaque nœud et chaque lien dans lequel il apparaît. Une classe InContext a une structure similaire à celle du patron de conception « décorateur » de Gamma [Gamm95].Quand un nœud est de même structure au patron décorateur est obtenu dans un contexte, les informations InContext correspondante s’additionnent aux données de base su nœud.
Après, vient l’établissement d’une table de correspondance conceptuelle –navigationnelle. Dans le modèle de conception, une classe de base est choisit pour chaque nœud et l’on procède par comparaison des attributs et des méthodes.
Conception de l’interface abstraite
Quand la structure de navigation est déterminée, les apparences des interfaces font l’objet de sujet. OOHDM se réfère à l’approche ADV (Abstract Data View [Cowa95]) dans la description de l’interface utilisateur pour décrire l’interface utilisateur. Les ADV sont des objets interface associés aux objets du modèle OOHDM comme les nœuds et index et dont les attributs définissent les caractéristiques en termes organisationnel et d’apparence. Certains attributs arrangent la liste des événements que l’utilisateur peut provoquer et auxquels l’ADV doit prêter attention. L’aspect dynamique tel que le comportement à constituer par rapport à un événement sont décrits par des ADV-charts, résultant des statecharts [Carn94].
Implémentation
C’est lors de cette étape que les objets conceptuels, de navigation et d’interface décrits par les différents modèles d’OOHDM sont traduits en fonction du milieu informatique choisi pour l’installation. Une ébauche concernant les obstacles et techniques recommandées pour établir les différentes communications est proposée dans [Schw98].
Conclusion sur OOHDM
La méthode OOHDM (version proposée en 2000 [Güel00]) est déterminée par un processus en cinq étapes débutant par un examen des tâches que les utilisateurs peuvent effectuer dans l’application. Il introduit une dimension fonctionnelle dans les méthodes antérieures. Les besoins fonctionnels sont exprimés par des scénarios.
Ces spécifications font partie des étapes de modélisation conceptuelle et navigationnelle et chaque étape est définit par un schéma objet qui lui est spécifique : diagramme de contexte navigationnel, diagramme de classes navigationnelles et InContext. La détermination de l’interface permet de décrire les objets qui composent qui compose l’interface de l’application à partir des unités de navigation. En définitive, la dernière étape se résume à la correspondance entre les éléments d’interface et ceux de l’implémentation.
OOHDM se différencie des approches antérieures par une approche de conception objet. Le degré de concordance offert entre les niveaux conceptuel et navigationnel favorise la réalisation de la méthode à un modèle conceptuel objet .Néanmoins, dans OOHDM l’adaptation permet surtout de choisir la version hypermédia que l’utilisateur veut, en fonction du groupe d’acteurs auquel il appartient. Dans les cartes de précision, les groupes (employés, dirigeants, etc.) auxquels s’adresse le contexte navigationnel fait référence sont mentionnés [Güel00].
- UWE: UML-based Web Engineering
UWE (UML-based Web Engineering) [Koch 02] [Hennicker 00] est une méthode servant à concevoir les applications Web. Elle se base sur une extension de la notation UML appelée « profil UML » selon la terminologie de l’OMG pour élaborer plusieurs formes de l’application Web tels que la navigation ou la présentation. Cette méthode regroupe quatre activités de modélisation qui sont l’analyse des besoins, la modélisation conceptuelle, la modélisation de la navigation et la modélisation de la présentation.
La phase d’analyse des besoins, détermine quels seront les différents utilisateurs de l’application ainsi que les différentes actions qui devront être faites. Elle permet donc d’identifier les divers types d’utilisateurs de l’application ainsi que les fonctionnalités correspondant à chacun d’eux.
La phase de modélisation conceptuelle utilise les éléments de la phase ultérieure pour servir de base à l’élaboration UML. Cette phase a pour objectif principal la production du modèle de domaine en tenant compte de la navigation, la présentation et l’interaction ainsi que les deux aspects modélisation de navigation et de la présentation qui seront nécessaires aux phases suivantes. La phase de modélisation de la navigation spécifie à la fois les objets visités par navigation et la manière de les atteindre.). Le modèle de l’espace de navigation est un diagramme UML constitué de classes pénétrables identifiées par le stéréotype « navigational class ».
Des liens de « navigabilité directe » permettent le passage d’une classe vers une autre et cette structure de navigation transforme le modèle de l’espace de navigation et l’enrichissant avec des éléments de plus haut niveau comme l’ « index », « visite guidée », « requête » et « menu ». Ces éléments permettent une structuration navigationnelle en spécifiant comment accéder à chaque page .La phase de modélisation de la présentation décrit comment les différentes structures de l’information décrit à travers accessible à travers l’espace de navigation sont présentées à l’utilisateur.
A chaque classe navigable et à chaque structure de navigation sont associées une ou plusieurs classes de présentation qui comprend des éléments basiques tels que ‘image’, ‘ancre’, ‘collections d’ancres’. Ainsi, chaque structure de navigation est influencée par un modèle template pour sa présentation.
Les artefacts produits et utilisés dans la méthode UWE sont présentés dans le tableau suivant :
Etapes | Analyse des besoins | Modélisation conceptuelle | Modélisation de la navigation | Modélisation de la présentation |
Artefacts produits | Cas d’utilisation en UML | Diagramme de classes UML | Diagramme de classes UML enrichis avec des classes et des structures de navigation | Classes de présentation (ou template) |
Artefacts produits dans le cycle de vie selon la méthode UWE [Koch 02]. Source : Xiong, 2008
Aperçu général d’UWE
Classée dans l’approche pour l’amélioration et le développement des applications hypermédias fondés sur le web, UWE (UML-based Web Engineering) [Koch00a] est une approche méthode qui couvre tout le cycle de développement des applications en cinq phases: la création ou conception, l’élaboration, la construction, la transition et la maintenance.
Les quatre premières reprennent et ajustent celles du processus Unifié (PU) [Jaco99] à partir duquel le processus proposé dans UWE. La cinquième phase élargi le PU par la prise en compte d’actions liées à la confirmation et gestion d’un système qui, après sa création nécessite des ajustements au niveau du contenu, la présentation ou encore l’agencement de l’hypermédia.
Dans le cadre de cet état d’art, nous ne décrirons plus la totalité du processus, mais notre étude sera plutôt axée sur l’étude d’UWE et les propositions relatives à l’abstract et à la conception de l’application. Nous mentionnerons également que l’approche repose sur un méta-modèle, appelé Munich Reference Model [Koch00], formalisant les caractères et principes de fonctionnement et progression des applications hypermédias adaptatives. La description de ce méta-modèle n’est toutefois indispensable si l’on veut comprendre exactement la proposition décrite.
UWE propose une explication et une méthode [Koch00]. L’explication présentée offre des règles de modélisation qui combinent les notations d’UML [UML99] et des extensions spécifiques d’un profil UML[Baum99][Henn00]. A travers un processus de création itératif et incrémental, la méthode permet l’analyse des besoins, la modélisation conceptuelle, la conception de la navigation et celle de la présentation, ainsi que la modélisation des utilisateurs et des adaptations.
Les dimensions abordées donnent lieu à six modèles, représentés par des paquetages. Les relations de dépendance entre les packages révèlent la repères visibles existant entre les processus permettant d’aboutir à ces modèles.
Analyse des besoins
L’analyse des besoins dans UWE se veut être une approche établie sur les cas d’utilisation et consiste à identifier et satisfaire les besoins fonctionnels des différents utilisateurs auxquels doit répondre l’application.
Les entités de création utilisées à cette étape sont ceux proposés par UML. Les notions d’acteurs, de cas d’utilisation, de relations d’héritage, d’utilisation et d’extension entre eux, ainsi que les mécanismes de paquetages et de vues sont repris et conservent la sémantique décrite par UML. Les notations graphiques sont également celles d’UML.
C’est lors de cette étape que la démarche conduit les propositions communes vers les processus par les cas d’utilisation. Il s’agit en général ainsi que les activités qu’ils entreprennent. Ces activités sont révélées par des cas d’utilisation auxquels sont reliés les acteurs. Si nécessaire, des relations d’utilisation et d’extension sont définies entre certains cas d’utilisation, ainsi que des relations d’héritage entre acteurs.
Modélisation Conceptuelle
Cette étape vise à établir le modèle conceptuel du domaine d’application en en se référant aux besoins et décrit le diagramme UML qui organise les concepts du domaine sur les UML suivants : classes, associations et paquetages. L’exactitude des deux derniers éléments permet aux classes du modèle conceptuel UML d’avoir une subdivision optionnelle s’ajoutant aux attributs et opérations. Ce compartiment ou subdivision est fait pour recevoir des variantes qui forment des autres informations utilisées pour adapter le contenu de la classe en fonction de chaque profil utilisateur.
La démarche de la modélisation conceptuelle consiste à identifier les classes et à spécifier pour chacune ses attributs et opérations, elle veut aussi relier les classes par des associations et à remarquer d’éventuels problèmes exprimés en OCL (Object Constraint Language).
Modélisation de la Navigation
La modélisation de la navigation comprend en fait deux étapes, conduisant à l’élaboration de deux modèles. D’abord, un modèle de l’espace de navigation permet de décrire quels objets atteints par la navigation. La structure de navigation exprime comment ces objets sont atteints dans l’application. Nous pencherons à l’étude successive des deux modèles et les étapes associées.
Modélisation de l’espace de navigation
L’espace de navigation est modélisé grâce aux classes navigation et aux associations navigation qui sont tous deux des entités du UWE.
La première présente une catégorie dont une classe navigation représente une classe dont les applications sont atteintes par l’utilisateur lorsqu’il navigue dans l’hypermédia. Les caractéristiques d’une classe navigation sont celles de la classe conceptuelle homologue. Il est pourtant possible d’omettre certains traits de la classe conceptuelle lorsqu’ils conviennent au modèle de navigation c’est-à-dire qu’il n’est plus utile de les concrétiser dans l’hypermédia.
Il est aussi faisable de donner à la classe navigation des caractéristiques qui n’appartiennent pas à la classe conceptuelle correspondante. Ces attributs doivent dérivés à partir d’une classe du modèle conceptuel qui n’apparaissant pas dans le modèle de navigation. Ils sont évalués à partir d’une expression OCL.
La seconde association navigation exprime une éventualité d’accès direct à une classe navigation cible à partir d’une classe navigation source. Cette classe navigation est représentée sur le schéma par une flèche dirigée et stéréotypée par l’expression « direct navigability ». Le sens de cette flèche montre la direction de l’association navigation, qui est uni-directionnelle. On parle par contre de bidirectionnalité lorsque l’association navigation être parcourue dans les deux sens .En effet, toute extrémité fléchée d’une association navigation est dotée d’un nom de rôle et d’une abondance qui exprime respectivement le rôle de la classe cible.
Les associations du modèle conceptuel sont modifiées en associations navigation quand les classes du modèle conceptuel qu’elles relient possèdent des classes navigation dans le modèle de l’espace de navigation. Des contraintes en OCL permettent de délimiter des limitations sur le modèle de l’espace de navigation qui prend par la suite une forme de diagramme de catégorie UML en mettent en relief des éléments statiques de deux types.
Les associations navigation Se reflètent dans le modèle de l’espace de navigation d’UWE, La façon dont cette navigation est réellement maintenue dans l’hypermédia est décrite par le modèle de la structure de navigation que nous allons à présent décrire.
Modélisation de la structure de navigation
Un modèle de concrétisation des faisabilités de navigation dans le modèle de navigation est produit grâce à la modélisation de la structure de navigation. Des primitives d’accès définissent le modèle de structuration à partir du modèle d’avant. La structuration recourt à trois étapes bien distinctes .Premièrement, les primitives d’accès que sont les index, les visites guidées et requêtes augmentent le modèle de navigation, la primitive d’accès introduite par UWE exprime une requête en OCL et est modélisée par une classe stéréotypée ou index guided tour et query.
La démarche spécifique à UWE procède par le suivi des règles de modification du modèle source, ces règles sont imprécises concernant certains aspects .Le modèle de structure est modifié par le biais de l’ajout d’un quatrième type d’accès ou menu qui est un intervalle de classe liant une classe Menultem avec une composition. Les menus sont des accès directs aux classes hétérogènes contrairement à l’index qui n’offre accès qu’à un seul type de classe ou classe navigation.
Pour introduire des menus au modèle de la structure de la navigation, on associe un menu à une classe navigation initiale. La liaison de ces deux types est réalisée par une composition. Les rôles des associations navigation sont alors les items du menu et ce sont eux qui sont en liaison avec la cible.
La modélisation de la structure de navigation se termine par l’ajout des propriétés aux différents éléments du modèle pour spécifier et différencier des contraintes en vue d’une l’adaptation adéquate. Nous pouvons citer comme exemple la propriété direct guidance attribuée à une visite guidée doit indiquer le meilleur nœud à choisir en fonction de l’utilisateur. Il en est de mêmes pour la propriété annotated en concordance avec un index ou menu et qui devra circonscrire les mécanismes des éléments.
Modélisation de la Présentation
Elle est principalement composée d’un ensemble de vues montrant la forme et le contenu des nœuds de l’hypermédia en décrivant la façon dont l’utilisateur et les nœuds sont en concordance. UWE propose deux étapes pour la modélisation de la présentation : le premier concerne la conception des storyboards et le second le flot de présentation.
La création de storyboards repose sur trois éléments décrits par le profil UWE dont une classe stéréotypée « UI View » ou encore User Interface View , Une instance de Vue Interface Utilisateur ou VIU qui permet de grouper les unités qui doivent être présentées de manière simultanée. L’élément suivant est une « presentation class », qui divise une VIU en unités basiques Le troisième élément est une classe abstraite ou User Interface Element associée à une classe présentation par une composition.
Cette dernière classe se spécialise en diverses classes stéréotypées comme le « text », « image », « video », « audio », « form » ou « anchor ». Ces deux dernières classes sont considérées comme des éléments d’interaction cela veut plus exactement dire que la classe « anchor » est attachée à un lien de navigation, la classe « form »soumet l’information, déclenche l’événement .Ces éléments ont une représentation graphique singulière dans [Koch01].
Modélisation des utilisateurs
La modélisation des utilisateurs a pour but de déterminer les spécificités à retenir pour concevoir des profils utilisateurs et instaurer des liens entre eux et leurs relations avec les entités de modèle représenté dans un diagramme de classes.
La construction du modèle utilisateur requiert la recherche des caractéristiques adaptées au domaine d’application en vue de l’adaptation. Par exemple, une classe Type de Paiement indiquant le mode de paiement de l’utilisateur est justifié en l’application de commerce électronique mais n’a pas forcément la même valeur et intérêt dans d’autres cas. Des classes peuvent s’adapter et s’associer avec les autres.
Modélisation de l’Adaptation
Ce dernier modèle d’adaptation d’UWE est fondé sur un concept de règle modélisé par une classe de type « rule» et lié par Une relation d’une classe « action » avec une classe « condition » qui sont liées à des classes des modèles utilisateur. Des règles d’adaptation spécifient comment le contenu, navigation, et présentation doivent être adaptés.
Les règles d’acquisition décrivent la manière de s’approprier les informations de l’utilisateur et mettre à jour son modèle en décrivant ses comportements examinés par le système à partir de la classe « User Behaviour » Les règles conditions et actions précitées sont exprimées en langage naturel formel avec OCL.
Des diagrammes de collaboration sont élaborés pour mettre en évidence les enchaînements aléatoires des règles. Bref, cette démarche reprend les spécifications dans les multiples modèles en les exprimant sous forme de règles.
- Les techniques, méthodes et outils Internet, Intranet, Extranet
Pour se faire un site web doit recourir à l’emploi des techniques et méthodologies tel l’internet, l’extranet et l’intranet .Ces trois techniques sont reconnues pour leur capacité de diffusion des informations dans le temps et l’espace. On assiste aujourd’hui à une forte émergence d’applications et de systèmes collaboratifs de gestion de contenus en ligne, de syndication, d’importation et d’exportation de données. En plus de développer ces nouvelles applications, les entreprises spécialisées dans le développement d’applications Web doivent maintenant faire face aux demandes accrues de pseudo migration des applications Desktops vers le Web. Par conséquent, des milliers d’applications de différents domaines sont déployées sur le Web.
Les applications traditionnelles Desktop tendent à perdre leur valeur à cause de l’apparition du Web. Les utilisateurs sont beaucoup plus à l’aise avec la navigation par le biais d’un navigateur, et la conception des interfaces est désormais possible avec le web. Le web permet aux administrateurs du système de ne gérer que quelques serveurs contrairement à l’époque du Desktop. Le concept de Web.2.0 a augmenté le degré de complexité des applications web mais a ouvert un chemin électronique grâce aux sites web administratifs et gouvernementaux.
- Intranet
Par définition, l’Intranet est un réseau informatique privé à l’intérieur d’une organisation et qui utilise les technologies Web (protocoles et applications TCP/IP) (Actual, 1999; Centre francophone d’informatisation des organisations (CEFRIO), 2000; Office de la langue française (OLF), s.d.). Cet outil permet de gérer, de partager et de répertorier les informations et les connaissances (Choo et al., 2000), de communiquer et de collaborer et de faciliter l’accès l’échange et l’accessibilité aux informations en utilisant les différentes interfaces et les données d’applications (Guengerich et al., 1997).
Intranet est donc un système d’information web permettant de communiquer et de collaborer en toute liberté en profitant d’un échange fluide et cohérent d’information via le web. L’opérationnalité, la qualité et l’efficacité d’un intranet repose sur son contenu qui doit être optimisé, sa technologie qui doit être actuelle et performante et de sa « culture informationnelle positive ».
Le bon fonctionnement d’un outil intranet nécessite également l’intervention de professionnels et le déploiement de ressources financières et budgétaires de choc (Hannam, 1996). Les intervenants humains sont utiles pour la conception du contenu, la gestion d’intranet et les interférences avec les utilisateurs.
- Extranet
L’extranet est un réseau informatique constitué des intranets de plusieurs entreprises qui communiquent entre elles, à travers le réseau Internet, au moyen d’un serveur Web sécurisé (Actual, 1999; Arsenault, 2000; Centre francophone d’informatisation des organisations (CEFRIO), 2000; whatis?com, s.d.).
En l’an 2000, Baker définit quatre rôles principaux des extranets :
- le partage d’information sous la forme de publication électronique,
- la communication stratégique entre les compagnies et leurs bureaux distants ainsi que les travailleurs mobiles,
- l’accès à des applications clés de traitement de l’information comme le suivi de la production et des commandes, et
- la sécurité des échanges (Baker, 2000).
En général, l’extranet est surtout utilisé par les professionnels et les entreprises qui souhaitent échanger des informations entre elles par le biais d’un réseau électronique. Etant surtout utile en affaire, il nécessite alors des compétences en processus d’affaires (Watson, 2000). De plus, ses concepteurs doivent avoir une grande connaissance des systèmes de sécurité réseautiques. Cependant, les technologies dont il use sont similaires à ceux utilisés pour l’internet et pour l’intranet. (Dufour, 2003)
Pour résumer, on peut aisément dire que les intranets et les extranets qui usent d’une même et seule technologie : le web. Cependant, on note leur portée différente et leurs usages souvent opposés.
- Comparaison entre Intranet, Extranet et Site web externe
Certains auteurs et chercheurs contestent l’appartenance du site web externe à la famille des SIW. Cependant, Dufour (2003) intègre ce dernier dans les SIW et établit une comparaison entre les intranets, les extranets et les sites web externes que nous allons représenter dans le tableau suivant :
Site web externe La littérature sur les tâches et compétences professionnelles propres aux sites Web externes ne présente que peu d’études empiriques, les textes étant plutôt anecdotiques ou écrits dans une optique de vulgarisation. L’étude des textes permet toutefois de recueillir suffisamment d’information pour dresser un portrait des principales tâches et fournir des exemples de compétences professionnelles qui y sont liées. La description des tâches et des compétences professionnelles pour chacune des dimensions et des phases de développement des SIW est présentée dans les sections qui suivent. Dimension technologique
La dimension technologique est celle qui fait le plus consensus dans la littérature. Un certain consensus émerge, entre autres, sur les intervenants identifiés, les principaux étant : programmeur, administrateur de système, concepteur Web et webmestre. Phase de la planification stratégique
La planification stratégique des sites Web externes est abordée par peu d’auteurs dans la littérature : Sam-Mag (2000) mentionne la définition des stratégies en matière de sécurité pris en charge par le « responsable sécurité », Leiserson (2002) signale la définition des types de fichiers inclus dans le système et Garrett (2003) parle de l’élaboration de la stratégie globale pour les technologies. Phase de la conception et de l’opérationnalisation
Il est possible d’identifier deux composantes impliquées lors de la conception et de l’opérationnalisation : (1) les applications et le matériel, et (2) les sites Web externes. L’implication conceptuelle et opérationnelle au niveau des applications et du matériel fait intervenir comme tâches l’installation et la configuration des bases de données (Jordan, 1997; Sam-Mag, 2000; Shachtman, 1998; Taylor et al., 2001; van der Walt & van Brakel, 1997), la sélection, le développement, l’installation, la configuration et la maintenance des applications et du matériel (Blanc, 1999; Dougherty, 1997; Jordan, 1997; Miller, 1994; Reiss, 2000; Rosenfeld & Morville, 1998; Sam-Mag, 2000; Shachtman, 1998; van der Walt & van Brakel, 1997; Web Developer’s <Virtual Library>, s.d.), le support technique en général (van der Walt & van Brakel, 1997) ainsi que la sécurité (Jordan, 1997; Sam-Mag, 2000; Taylor et al., 2001; van der Walt & van Brakel, 1997). Les compétences professionnelles liées sont à teneur fortement technique et technologique : connaissance des langages de programmation, capacité à configurer un serveur, capacité à gérer la sécurité du réseau, etc. (Sam-Mag, 2000; Shachtman, 1998). La composante « sites Web externes » renvoie à la conception du site Web externe : développement, test, validation, vérification, révision et mise en ligne (Blanc, 1999; Garrett, 2003; Jordan, 1997; Leiserson, 2002; Leong, 1997; Sam-Mag, 2000; Shachtman, 1998; Taylor et al., 2001; van der Walt & van Brakel, 1997; Web Developer’s <Virtual Library>, s.d.). Cette composante implique des compétences professionnelles techniques et technologiques comme la connaissance des langages et protocoles Internet ainsi que des différentes plates-formes informatiques (Sam-Mag, 2000). Phase de la gestion des ressources
La gestion des ressources se situe au niveau des applications et du matériel et porte sur la gestion des bases de données (Jordan, 1997; Sam-Mag, 2000), la gestion du serveur et des applications liées (Sam-Mag, 2000; Web Developer’s <Virtual Library>, s.d.), ainsi que la gestion des risques (Sam-Mag, 2000). Cette gestion demande des compétences professionnelles comme une connaissance minimale des principaux environnements informatiques, la maîtrise des langages de programmation ainsi que la capacité à gérer des systèmes d’information (Sam-Mag, 2000). Aucune mention explicite des compétences professionnelles de gestion n’est faite pour la dimension « gestion des ressources ». Les compétences professionnelles mentionnées sont plutôt liées au domaine géré (gestion des systèmes d’information, connaissance des langages de programmation, etc. (Sam-Mag, 2000)); la gestion transcende cette dimension et semble être considérée comme implicite. Ceci est aussi observé pour les autres dimensions étudiées. Dimension informationnelle
C’est au niveau de la dimension informationnelle que les plus grandes divergences apparaissent, en particulier pour la prise en charge de ces activités. Les tâches informationnelles sont associées à différents intervenants comme, par exemple aux gens de la rédaction (Rowbotham, 1999) et au webmestre (Sam-Mag, 2000; van der Walt & van Brakel, 1997). Certaines responsabilités informationnelles se voient aussi explicitement attribuées au bibliothécaire et au documentaliste : le repérage et l’organisation de l’information (Dougherty, 1997; Sam-Mag, 2000). Phase de la planification stratégique
La phase de la planification stratégique se caractérise par les tâches d’identification de l’information à inclure (Dougherty, 1997; Miller, 1994), de la planification des activités de rédaction (Sam-Mag, 2000), de la définition des processus éditoriaux et d’approbation (Garrett, 2003), de l’élaboration d’une stratégie au niveau du contenu (Garrett, 2003) ainsi que de règles de navigation (Sam-Mag, 2000). Phase de la conception et de l’opérationnalisation
Les tâches de conception et d’opérationnalisation de la dimension informationnelle identifiées dans les écrits sont liées à : • la création de l’information — collecte, rédaction, édition, présentation (Blanc, 1999; Garrett, 2003; Jordan; 1997; Leiserson, 2002; Leong, 1997; Reiss, 2000; Rosenfeld & Morville, 1998; Rowbotham, 1999; Sam-Mag, 2000; van der Walt & van Brakel, 1997; Web Developer’s <Virtual Library>, s.d.). Ceci fait appel à une bonne connaissance du milieu organisationnel, du Web et des règles de communication ainsi qu’à des qualités rédactionnelles et syntaxiques (Sam-Mag, 2000);
• la vérification de la qualité de l’information (Rosenfeld & Morville, 1998; van der Walt & van Brakel, 1997);
le repérage de l’information (Sam-Mag, 2000) qui commande une maîtrise d’Internet et une formation en documentation (Sam-Mag, 2000);
• l’organisation de l’information et son indexation (Dougherty, 1997; Garrett, 2003; Leiserson, 2002; Miller, 1994; Rosenfeld & Morville, 1998); Sam-Mag, 2000; van der Walt & van Brakel, 1997). Ceci fait appel au domaine de la documentation (Sam-Mag, 2000);
• l’élaboration de la navigation (Garrett, 2003; Rosenfeld & Morville, 1998; Taylor et al., 2001).
|
Extranet Les définitions d’extranet sont très similaires et se synthétisent ainsi : Extranet : Réseau informatique constitué des intranets de plusieurs entreprises qui communiquent entre elles, à travers le réseau Internet, au moyen d’un serveur Web sécurisé (Actual, 1999; Arsenault, 2000; Centre francophone d’informatisation des organisations (CEFRIO), 2000; whatis?com, s.d.).
Les extranets répondent à quatre tâches principales : (1) le partage d’information sous la forme de publication électronique, (2) la communication stratégique entre les compagnies et leurs bureaux distants ainsi que les travailleurs mobiles, (3) l’accès à des applications clés de traitement de l’information comme le suivi de la production et des commandes, et (4) la sécurité des échanges (Baker, 2000). Une de leurs utilisations principales est le support du commerce électronique interentreprises (Saunders, 1998; Schwarzwalder, 1999a). Les clients pour lesquels le système est développé sont centraux à ce type de SIW ([Mark], 2000; Miller, 2000; Preston & McCrohan, 1998; Strom, 1997). La planification initiale de l’extranet devra donc tenir compte de cette clientèle mais aussi des objectifs de l’extranet et de sa portée (Strom, 1997). Bien que les technologies utilisées soient les mêmes que pour les sites Web externes et les intranets, le déploiement effectif des technologies extranet demande en plus une compréhension approfondie des processus d’affaires (Watson, 2000). La littérature sur les tâches et les compétences professionnelles requises pour la mise sur pied d’un extranet est encore plus mince que celle sur le commerce électronique. Aucun texte n’a été trouvé qui identifie explicitement les différentes tâches et compétences professionnelles. Il faut noter que puisque les extranets sont considérés comme une des principales avenues pour le commerce électronique (Schwarzwalder, 1999a), il est possible qu’ils n’aient pas fait l’objet d’un développement spécifique à ce niveau et relèvent plutôt de la littérature sur le commerce électronique. Certains auteurs utilisent effectivement les deux concepts indistinctement. Mais les caractéristiques générales d’un extranet peuvent servir à identifier les grandes familles de compétences professionnelles requises. Partageant avec les autres SIW les mêmes technologies Web, les extranets vont posséder les caractéristiques de base qui se retrouvent dans le contexte des sites Web externes sur les plans technologique et informationnel ainsi qu’au niveau de l’interface graphique et de l’interaction système-utilisateurs. Le contexte des extranets donne une importance accrue aux compétences professionnelles technologiques reliées à la sécurité des réseaux. De plus, comme pour les intranets, il est possible de rencontrer un besoin d’intégration de systèmes existants qui demandent des compétences professionnelles spécifiques tant opérationnelles que de gestion. Finalement, les utilisateurs étant au cœur des extranets, le processus de définition des besoins est particulièrement important ainsi que la compréhension des processus d’affaires.
|
IntranetL’intérêt pour les intranets est de plus en plus grand et les organisations les adoptent rapidement (Lamb, 1999). L’intranet est présenté comme un outil qui permet : • la gestion, le partage et le repérage de l’information et des connaissances (Choo et al., 2000; Lamb, 1999; Lynch, 1997; Nanfito, 1997); • la communication et la collaboration (Baker, 2000; Choo et al., 2000; Lynch, 1997; Nanfito, 1997), car l’intranet peut être utilisé comme collecticiel (Detlor 2000; Lamb, 1999) à des coûts beaucoup moins élevés que certains produits commerciaux (Garman, 1996); • la facilitation de l’accès à l’information en offrant une interface intégrée aux différentes bases de données et applications (Guengerich et al. (1997) cités dans Chou (1998); Lynch, 1997). Cependant, un écart entre ces utilisations anticipées (collecticiels, réseaux locaux, bibliothèques virtuelles, systèmes de gestion des documents et SIW) et les utilisations actuelles qu’en font les organisations est observé (Lamb, 1999). Le manque de modèles de développement d’intranets peut expliquer en partie cette difficulté (Fichter, 2000). Dimension technologiquePhase de la planification stratégique
Le développement de normes techniques supervisé par un comité technique Web est un élément qui ne ressort que dans la littérature sur les intranets ainsi que la définition des mécanismes d’accès, de copies de sécurité et d’archivage (Telleen, 1996). Les tâches liées aux stratégies de sécurité et à la définition des types de fichiers n’apparaissent pas dans la littérature sur les intranets.
Phase de la conception et de l’opérationnalisation
L’intranet ayant entre autres comme objectif de supporter le travail interne, une dimension « intégration des systèmes existants » s’ajoute au niveau de la conception et de l’opérationnalisation (Tellier, 2000). L’univers plus contrôlé et fermé de l’intranet crée un environnement propice au développement et à l’implantation d’outils de recherche (Adourian & Schweyer, 1997; McQueen & DeMatteo, 1999), activités moins présentes dans la littérature sur les sites Web externes. Phase de la gestion des ressources
Les écrits sur l’intranet ajoutent un volet de gestion des ressources humaines « technologiques » que sont les webmestres (Telleen, 1996) ainsi que celui de la gestion des outils de recherche (Adourian & Schweyer, 1997; McQueen & DeMatteo, 1999). La gestion des risques est une tâche absente pour les intranets. Dimension informationnellePhase de la planification stratégique
Les tâches nouvelles trouvées dans la littérature pour la planification stratégique de la dimension informationnelle des intranets sont l’identification des besoins informationnels ainsi que le développement des politiques, normes et guides de style (Telleen, 1996). Ces activités, prises en charge par des individus comme le rédacteur ou l’éditeur ou par des comités comme un conseil Web, demandent des compétences professionnelles liées au développement de politiques, à l’identification de besoins ainsi qu’à la communication orale et écrite (Telleen, 1996). L’élaboration des règles de navigation, présente dans les écrits sur les sites Web externes, est absente pour les intranets. Phase de la conception et de l’opérationnalisation
À la phase de la conception et de l’opérationnalisation, la littérature sur les intranets présente de nouvelles tâches d’analyse du contenu (Adourian & Schweyer, 1997) ainsi que de traitement du contenu, d’extraction et d’accessibilité des connaissances (Tellier, 2000).
Les tâches de vérification de la qualité de l’information, du repérage et de l’élaboration de la navigation ne se retrouvent pas dans la littérature consultée sur les intranets. Phase de la gestion des ressourcesSeule la dimension de la gestion des ressources diffère sensiblement car elle est beaucoup plus détaillée au niveau de l’intranet qu’au niveau des sites Web externes. La gestion des ressources pour la dimension informationnelle des intranets ajoute les tâches de gestion des ressources humaines et des normes informationnelles, de gestion de l’organisation de l’information, de gestion de la révision du contenu, de la coordination des éditeurs et de la gestion des échéances de rédaction (Telleen, 1996) ainsi que de la gestion des activités de veille (Tellier, 2000). Dimension « interface graphique »
Seule la phase de la conception et de l’opérationnalisation de la dimension « interface graphique » d’un intranet est abordée dans la littérature consultée tandis que, pour les sites Web externes, la phase de planification stratégique est aussi présente. L’intégration des bases de données et applications patrimoniales existantes propres au contexte des intranets crée un besoin pour le développement d’interfaces spécifiques (Telleen, 1996). Cependant, les aspects plus graphiques comme le développement de logos et de bannières sont moins présents, l’importance d' »accrocher » visuellement les utilisateurs étant peut être moins grande dans le contexte de la clientèle plus « captive » des intranets. Dimension « interaction système-utilisateurs »Phase de la conception et de l’opérationnalisation
La dimension « interaction système-utilisateurs » sur le plan de la conception et de l’opérationnalisation est abordée par les auteurs au niveau du développement et de la prestation de formations. Ces formations couvrent un plus grand éventail de thématiques que celles présentées dans la littérature pour les sites Web externes. Les sujets des formations mentionnés dans les écrits sont la création de pages Web, l’évaluation de sites Web externes, la recherche de documents sur l’intranet (Adourian & Schweyer, 1997) ainsi que l’utilisation générale de l’intranet (Starnes et al., 1997; Telleen, 1996). La sensibilisation ainsi que l’intégration des caractéristiques des utilisateurs n’apparaissent pas dans les écrits sur les intranets. Phase de la gestion des ressources
Au niveau de la gestion des ressources, la présence d’un coordonnateur pour la formation est observée (Telleen, 1996). |
Comparaison entre Intranet, extranet et site web externe. Source : Dufour, 2003.
- Etude comparative entre les Systèmes d’Information Traditionnels et les systèmes d’Informations Web
- Définition des Systèmes d’Information Traditionnels
- Ergonomie des SIT
Un système d’information traditionnel est un moyen de communication, de sauvegarde, de partage et de diffusion d’informations presque non basé sur le web. Ce partage et cet échange d’informations se fait dans un milieu bien défini et est appuyé par des logiciels, des matériels, des données ou des procédures bien spécifiques.
- Origine et usage
Dans les années 80 jusqu’aux années 90, les SIT étaient de plus en plus répandus dans les entreprises. Ils représentaient alors une certaine hiérarchie de l’entreprise et étaient utilisés surtout pour gérer le fonctionnement interne, pour améliorer l’échange d’informations entre les différents salariés et pour améliorer le processus de management interne. On remarque alors l’apparition de systèmes DSS (soutiens de décisions), de gestion d’information comme le MIS ou des SIT usités par la direction ou EIS. Ces SIT ont formé une pyramide, une forme très en vogue à cette époque.
- Etat de l’art actuel
Actuellement, les SIT sont surtout utilisés en entreprise et présentent différents aspects. On parle d’ERP ou Enterprise Resource Planning ou PGI (Progiciel de Gestion Intégré) dédié spécifiquement au bon fonctionnement de l’entreprise. Il existe aussi des SIT sous forme de CRM ou Customer Relationship Management ou gestion de la relation cliente (GRC).
Ce dernier prend en compte l’utilisateur qui fait partie des personnes à informer, tout comme les intervenants dans l’entreprise. Df’autres SIT tels que XRM ou eXtended Relationship management ou gestion de la relation au tiers, le SCM ou Supply Chain Management ou GCL (Gestion de la chaîne logistique), le HRM ou Human Resource management ou gestion des ressources Humaines (GRH), le PDM : Product Data Management ou Système de Gestion de Données Techniques (SGDT).
Actuellement, on note une tendance basculant vers l’information des utilisateurs en même temps que des intervenants dans la conception du SIT. De plus, les évolutions technologiques qui ne cessent d’accroitre permettent une meilleure diffusion, une meilleure gestion et une meilleure sauvegarde des informations. On peut alors dire que nous assistons surtout à une information de plus en plus diffusée sur le web suivant des processus de plus en plus automatisés.
Cette orientation vers l’usager sous-entend une gestion du contenu, une conception optimale mais aussi une gestion accrue de l’accès qui doit être plus ouvert, plus souple et élargi.
- Comparaison entre les Systèmes d’Information Traditionnels et les systèmes d’Informations Web
D’après les différents aspects du système d’information traditionnel ou SIT et du Système d’information web ou SIW ? Nous pouvons conclure que ces deux concepts ont la même finalité qui est d’organiser et d’arranger le fonctionnement d’une société ou d’une entreprise. Par conséquent, les finalités sont communes, seule la technologie diffère car le SIT est traditionnel et le SIW est révolutionnaire puisque basé sur le Web.
De ce fait, des études, notamment celles de Collette Rolland en 1988, ont permis de définir le SI en tant qu’ensemble composé de :
– « de collection de données, représentation partielles, en partie arbitraires mais nécessairement opératoires, d’aspects pertinents de la réalité de l’organisation sur lesquels on souhaite être renseigné. Ces collections inter-reliées, aussi cohérentes que possible, sont mémorisées et communiquées dans le lieu, le moment et la présentation appropriées aux acteurs qui en ont l’usage ;
– de collections de règles qui fixent le fonctionnement informationnel. Ces règles traduisent ou sont calquées sur le fonctionnement organisationnel. Parties intégrantes du SI, elles doivent être connues des acteurs qui utilisent le SI et leur sont nécessaires pour l’interprétation et la manipulation des collections de données ;
– d’un ensemble de procédés pour l’acquisition, la mémorisation, la transformation, la recherche, la communication et la restitution des renseignements ;
– d’un ensemble de ressources humaines et de moyens techniques intégrés dans un système, coopérant et contribuant à son fonctionnement et à la poursuite des objectifs qui lui sont assignés. »
Ainsi, plusieurs théories ont commencé à s’intéresser de près au SIW comme une extension plus informatisée et technologique du SI puisque basée sur le Web. Ces études ont même mené à une certaine théorie destinée à savoir si un SI doté d’une application Web ne diffèrerait pas d’une SIW proprement dite. Quoi qu’il en soit, la grande différence entre ces deux concepts repose surtout dans la technologie et dans les utilisations.
- Comparaison entre les différentes méthodes de développement des applications Web
Evaluer les sites web est une tâche encore très peu connue et pratiquée. La recherche des mensurations pour l’évaluation quantitative de la qualité des applications Web n’en est qu’à ses premiers termes. Il est devenu essentiel pour les industries de développer ces applications en mettant au point des principes et méthodes d’approches spécifiques.
Il est vrai que des guides de style, principes et techniques de conception spécifiques aux applications Web, apparaissent par une rapidité incroyable Pourtant, très peu de travaux ont été effectués et publiés sur l’évaluation quantitative de la qualité de cette application.
L’importance de la qualité de ces applications et leurs interfaces utilisateurs n’est plus à démontrer. Les concepts définis pour le développement des connexions humain-ordinateur pour des applications conversationnelles traditionnelles sont pertinents et satisfaisants pour des applications Web. Quoique, les caractéristiques générales de ces applications sollicitent les considérations additionnelles [PRE 01].
La qualité des interfaces peut avoir un impact important sur la réussite de l’application même au plan. Donc, pour réaliser un bon système web tant dans la structure que le contenu, il est tout d’abord nécessaire d’établir une manière qualitative évaluative des sites web.
L’émergence du Web, à partir des années 90, a constitué un grand changement permettant de considérer et réaliser différemment la diffusion et le traitement de l’information. En tant qu’application de l’internet, le Web offre un espace large d’informations sans limite offertes par cette infrastructure. A u commencement, sa création découle des travaux autour du concept d’hypertexte dont il reprend les fondements organisationnels non-linéaire des contenus de données hébergés dans des machines éloignées accessibles grâce aux multiples chemins de navigation.
Les hypertextes type image, son, vidéo ou encore multimédia, ont vocation à présenter les informations utiles au site web qui sont présentées par une approche hypermédia ; il est également possible d’effectuer des à travers l’interface web. Ces applications constituent un SI ou système d’Information basé sur le web désigné par SIW [Taka97][Isak98a]. Un SIW forme un ensemble constitué de ressources humaines et de moyens techniques, de règles de fonctionnement, de données et de procédés pour acquérir, mémoriser, transformer, rechercher, communiquer et restituer ces données [Roll88].
Le Web constitue alors une base pour la création des systèmes. Un élément différenciant l’approche SIW par rapport à une approche SI influence concrètement le processus de conception. Les SIW mettent en œuvre, comme les hypermédias, une organisation non-linéaire d’informations reliées entre elles par plusieurs chemins, ces derniers multipliant les possibilités d’accès à une même information (Villanova, 2002). La conception des SIW doit, en conséquence, porter sur les deux dimensions suivantes :
- une activité d’organisation des informations en vue de la présenter car jugée comme base de navigation, il est interdit de l’ignorer dans le processus de développement des SWI.
- Nécessité d’une activité courante aux aspects fonctionnels ou à la conception des services auxquels doit répondre le SIW, est nécessaire.
Les applications Web présentent certaines caractéristiques et applications classiques différentes des logiciels .Ces caractéristiques environnementaux tels les approches ainsi que la vitesse de développement des applications les rendent différents et compliqués par rapport au développement des logiciels traditionnel. Les aspects liés à la sécurité de ces applications est plus important et plus critique que ceux dédiés aux applications classiques (Kadri, 2009).
Par les caractéristiques distinguant les SIW des SI, le recours aux logiciels traditionnels de conception est difficile et inadéquat. En effet, les aspects présentationnels et navigationnels ne sont pas prioritaires dans un processus de développement de SI non basés sur le Web. Par contre, les méthodes de conception d’hypermédias ont particulièrement attiré à la structuration des pages, à l’élaboration des liens entre elles pour la navigation, et à leur apparence lors de la présentation. Nonobstant, la conception d’un SIW n’est pas une activité banale ni une simple de manipulation de médias et de création de présentations.
En outre, Zelnick met en évidence combien cela est observé dans les faits à travers une étude visant à évaluer les applications sur le Web [Zeln98]. Les approches de conception d’hypermédias n’appréhendent pas de façon systématique le milieu fonctionnel du système. En effet, le public cible d’un SIW est beaucoup plus large que celui d’un SI traditionnel, même s’il est toutefois possible de limiter l’accès d’un SIW à une population spécifique en ayant recours à des politiques de sécurité comme l’intranet.
Dans le cas d’un SIW ouvert, la population d’utilisateurs est plus large et plus diversifiée cette pluralité des utilisateurs se constate à plusieurs niveaux relativement similaires par exemple à leurs buts, leurs préférences en terme de présentation, leurs connaissances.
D’une autre manière, comparées aux applications traditionnelles, elles présentent plusieurs caractéristiques propres tout en étant de taille et de complexité de plus en plus élevées (Malak, 2002). En constatant que ces applications évoluent très précipitamment, même si la plupart des sites Web sont pauvrement conçus et présentent des déficits sur les plans aussi bien de la navigabilité, de la fonctionnalité que de la traçabilité [FLE 98].
Dans la plupart des cas, les sites sont confus, trop lents et ne répondent pas aux besoins des utilisateurs. Des études récentes montrent que 90% des sites ne satisfont pas les objectifs de qualité préalablement établis par les concepteurs [BOL 00a; WAR 99] et ceci pour différentes raisons :
- technologie sous-jacente non conçue pour les applications en temps réels ;
- Technologies du concepteur non équitable à celles de l’utilisateur
- développement des sites Web amateurs focalisant trop seulement l’aspect visuel des interfaces. Il en résulte des sites lourds, difficiles à utiliser, et ne répondant pas aux besoins des usagers ;
- manque de standards d’ingénierie et techniciens associés à la production de sites Web de haute qualité.
Dans l’optique de choisir entre les différentes méthodes de développement des applications Web, elles sont comparées par évaluation de leur base de critère dont la modélisation de l’utilisateur, dimensions de l’adaptation, modélisation et mise en œuvre des adaptations, et capacités d’adaptation du SIW conçu (Villanova, 2002).
La modélisation des utilisateurs permet de définir si l’utilisateur peut être l’objet de représentation dans les approches étudiées Le tableau suivant nous en dira beaucoup plus
Critères d’évaluation relatifs à la modélisation des utilisateurs. Source : Villanova, 2002
La vision synthétique de l’évaluation des méthodes en regard de la modélisation de l’utilisateur est récapitulée dans le tableau ci-dessus. Les cases vides dans le tableau montrent que RMM et OOHDM n’ont pas de modèle en la matière et ne sont donc pas évaluées sur les autres critères .Les autres propositions utilisent un modèle des utilisateurs ou un modèle à part entière pour WSDM, Hera, UWE, alors que WebML intègre la représentation des utilisateurs dans le concept d’informations.
Evaluation des méthodes concernant la modélisation des utilisateurs. Source : Villanova, 2002
WSDM propose un modèle de représentation des groupes d’utilisateurs élaborés sur la base de leurs besoins en informations et données. Les ‘oui’ reportés en italique pour les critères de connaissances spécifiques au domaine d’application et préférences de présentation traduisent que l’exploitation de telles informations est suggérée par les auteurs mais décrite cependant de façon informelle.
Une représentation des utilisateurs individuels dans Hera permet de spécifier les conditions matérielles et logicielles dans lesquels le système est exploité. Des considérations en termes de présentation sont également représentées. Le modèle repose sur le vocabulaire CC/PP proposé par le W3C [Klyn01].
UWE représente les caractéristiques des utilisateurs en tant qu’individus par la création des classes appropriée dans le modèle. Seule la représentation des connaissances est envisagée les fonctionnalités ne sont pas considérées par le modèle c’et à dire que c’est dans la construction de la structure de l’hypermédia que les modalités sont définies d’accès aux données. Des préférences de l’utilisateur liées à la présentation sont également exprimées dans les classes spécifiques.
Les utilisateurs sont représentés dans des classes de type structurel grâce au Web ML, les groupes sont définis sur la base de fonctions communes à plusieurs utilisateurs, qui peuvent être plus compliqués qu’une simple navigation. Les utilisateurs sont principalement caractérisés par des informations conformes au domaine qui sont exploitables dans des règles de gestion métier : l’application cible de Web ML étant un outil de commerce électronique, aide à classer les individus par des données telles que le taux de remise qui lui est accordé.
Pour ce qui est de l’acquisition des informations caractéristiques d’un modèle utilisateur, les procédures ne sont pas clairement évoquées dans les approches. Pour WSDM, le concepteur construit explicitement les informations concernant les fonctionnalités de chaque groupe.. Notons que Dans Hera, une partie des informations sur le profil doit être donnée explicitement par le concepteur ou l’utilisateur.
Il est utile des souligner qu’ aucune offre ne mentionne clairement les droits de l’utilisateur à l’égard du modèle le concernant. Notamment, la lecture et la rectification des caractéristiques et préférences par l’utilisateur lui-même devraient être autorisées même si de telles informations sont automatiquement déterminées par le système.
Dimensions adaptées
Les critères d’évaluation de cette rubrique permettent d’identifier les dimensions qui font l’objet d’adaptation dans les approches présentées.
Critères d’évaluation relatifs aux dimensions adaptées. Source : Villanova, 2002.
Pour chacun des critères, nous indiquons dans le Tableau 4.4 les éléments de modélisation proposés ou les techniques employées à ces fins. Notons que nous mentionnons les aspects qui, selon nous, pourraient être utilisés à des fins d’adaptation même si, dans certaines propositions (RMM, OOHDM), l’adaptation n’apparaît pas clairement supportée (notamment en raison de l’absence d’un modèle utilisateur). Une case vide traduit l’absence de proposition en la matière.
Les éléments de modélisation, les techniques, les aspects des critères sont proposés, selon des propositions RMM et OOHDM, une adaptation n’est toujours pas supportée (case vide dans le tableau).
Dans RMM, Hera et OOHDM, les adaptations en termes de contenu, structure et navigation dans l’hypermédia sont mélangés car le modèle de l’hypermédia est fortement couplé au modèle du domaine. UWE et Web ML proposent une autre représentation du domaine qui expose les possibles adaptations de contenu tout en définissant une vue du site selon les groupes d’utilisateur.
UWE ajoute le compartiment ‘variant’ à la description des classes UML alors que Web ML adopte un modèle de dérivation défini sur le modèle informatif. Il s’agit aussi de vues mais, à la différence d’OOHDM, ce modèle est indépendant de toute représentation hypermédia. En termes de structure et de navigation, UWE intègre des propriétés dans le modèle de structure de navigation qui en contraignent les spécifications.
Des modèles (User Object Model et Perspective Object Model) qui présentent la vision du modèle de données de chaque groupe d’utilisateur décrient par WSDM ne garantie pas l’uniformité des descriptions avec les nœuds de l’hypermédia .Les adéquations concernant la navigation sont en fait induites par les deux modèles ci-dessus : les pistes de navigation reflètent les possibilités de cheminement dans les éléments du modèle.
WebML définit une vue du site distinctif à chaque groupe mais également spécifique à chaque méthode d’accès du groupe. Des feuilles de styles XLST adéquates sont définies, traitant ainsi une configuration d’adaptation de la présentation. Hera adopte une approche plus simple en définissant des conditions de présentation sur les m-slices et en exploitant celles-ci selon les préférences des utilisateurs et les conditions d’exploitation dans différents processus d’adaptation.
Bref, OOHDM, WSDM et Web ML sont des propositions d’adaptation des fonctionnalités du SIW. Ces approches ont en commun une construction de différentes versions de l’hypermédia des groupes d’utilisateurs. En conséquence, les pages auxquelles peuvent accéder les utilisateurs constituent un espace restreint qui répond à leurs besoins informationnels et fonctionnels.
Evaluation des méthodes concernant les dimensions adaptées
Modélisation et mise en œuvre de l’adaptation
A travers cette étape, nous essayerons d’identifier s’il existe une phase d’analyse des besoins en matière d’adaptation et si les méthodes ont ou non recours à un modèle conceptuel d’adaptation.
Ce tableau synthétise les résultats de cette analyse. On remarque l’existence d’une case vide indiquant l’absence de proposition. Dans WSDM, AWIS-M et UWE, une phase d’analyse vise à déterminer les besoins fonctionnels des utilisateurs et des besoins en matière d’adaptation dans la mesure où elle conduit à la détermination de différents groupes d’utilisateurs en fonction desquels différentes versions de l’hypermédia seront élaborées. Toutefois, l’analyse fonctionnelle ne suffit pas à déterminer réellement des attentes relatives aux capacités d’adaptation du système.
En outre, OOHDM et WSDM ne présentent pas de modèle conceptuel de l’adaptation et Web ML ne propose pas de modèle spécifique s: la spécification déclarative correspond à des caractérisations introduites dans les classes utilisateurs qui permettent d’émaner le modèle de dérivation. La spécification procédurale est exprimée par des règles événement – condition – action. Il est important de préciser à quelle structure la règle est liée. Hypothétiquement, elle est intégrée dans les descriptions des unités du modèle de composition.
Dans Hera, les éléments pour l’adaptabilité sont définis dans le modèle conceptuel de l’hypermédia sous forme de conditions sur les m-slices. Elle repose sur un modèle spécifique de règles. L’hypermédia délivré à l’utilisateur est construit en fonction de ces spécifications. D’une part, les éléments qui satisfont les conditions décrites dans le modèle conceptuel sont retenus pour composer les pages. D’autre part, les règles de types événement – condition – action sont traitées par le moteur d’adaptation emprunté à AHA [DeBr99].
C’est sur la base des spécifications qu’il convient construire l’hypermédia selon une approche descendante : les Unités Sémantiques de Navigation (USN) sont sélectionnées en fonction de la catégorie de l’utilisateur, puis les Nœuds de Navigation (NN) en fonction du profil de la catégorie d’utilisateur, et enfin, les Éléments de Base (EB) en fonction du degré d’appartenance de l’utilisateur à ce profil. Enfin, UWE propose un modèle spécifique de l’adaptation qui exprime sous forme de règles spécifiques insérées dans les autres modèles.
Critères d’évaluation relatifs à la modélisation et mise en œuvre de l’adaptation. Source : Villanova, 2002
Capacités d’adaptation du SIW conçu
Ces derniers écrits ont pour buts d’évaluer les capacités d’adaptation que SIW peut atteindre à partir des méthodes étudiées. Notons que les définitions retenues pour les différentes capacités d’adaptation combinent les définitions de l’adaptabilité et de l’adaptativité présentées auparavant.
Critères d’évaluation relatifs aux capacités d’adaptation du SIW. Source : Villanova, 2002
La combinaison de ces deux approches apparaît à travers les deux dimensions. La simplification des définitions retenues est liée au fait que seuls les deux cas de processus d’adaptation sont considérés.
Les constats établis grâce aux précédentes rubriques sont présentés dans le Tableau 4.7. Les conventions utilisées dans le tableau sont les suivantes : le caractère ‘+’ indique que le SIW présente la capacité d’adaptation associée, le caractère ‘–’ traduit que cette capacité n’est pas observable dans le système, l’association de ces deux caractères ‘+ / –’ exprime que la présence de cette capacité est discutable. La capacité d’adaptation minimale est observable dans tous les SIW conçus avec les méthodes présentées.
D’une part, il est évidemment nécessaire que l’installation veille à ce que la programmation respecte les modèles et les principes. D’autre part, la seconde condition porte sur l’obligatoire identification de l’utilisateur et du groupe auquel il appartient afin de pouvoir choisir la version du SIW que le concepteur devra lui présenter. RMM, OOHDM et WSDM proposent uniquement de choisir la version qui correspond à l’utilisateur.
Evaluation des capacités d’adaptation des SIW conçus avec les méthodes étudiées =. Source : Villanova, 2002.
Pour les capacités d’adaptabilité du SIW, l’évaluation est plus atténuée. Les raisons à cela sont principalement liées, d’une part à l’absence de description de l’utilisateur sur sa propre représentation dans le système, et, d’autre part, aux préférences de l’utilisateur prises en compte par les modèles. D’une manière générale, Hera et Web ML, et UWE présentent certaines caractéristiques pouvant laisser supposer que les SIW offrent des capacités d’adaptabilité. Toutefois, aucune description ne positionne clairement ces approches en termes d’adaptabilité.
Le développement web officialisé depuis 1998 concerne les pages HTML et le développement de logiciel avec les technologies modernes virtuelles. L’application des ces technologies permet de mieux échanger les informations entre plusieurs ordinateurs et de coordonner les tâches des trois composantes web dont le réseau qui lie entre eux les ordinateurs puis le poste client qui affiche les documents hébergés sur un autre ordinateur et enfin un poste hôte qui sert à localiser les informations demandées par le client. L’application web se diffère des sites web par sa capacité d’information et de navigation et opération et sa facilité de manipulation et création.
[Mecc99] soulève quatre grandes catégories par rapport à la complexité des applications web : D’abord, les sites de présence sur le web caractérisés par un faible degré de complexité en diffusant les informations, ces sites sont construits à partir des éditeurs HTML. Ensuite, les sites catalogues à forte densité de données en publiant une quantité importante de données. Puis les sites orientés services qui sont les moteurs de recherche et enfin, et enfin les SIW qui mettent à disposition la gestion des données jugés complexes avec des services interactifs modernes.
Les méthodes de conception des applications web se diversifient en plusieurs étapes selon les outils en autres le RMM Relationship Management Model Web ML qui a pour principale fonction la conception des hypermédias et la gestion des éléments informatifs, il a une grande capacité de structuration et modification des informations c’est pourquoi les auteurs le qualifie comme efficace et crédible.
Les étapes du RMM sont la conception des applications web, la conception des slices et la conception du contenu des entités, la construction des diagrammes de slices. Il convient utile de réexpliquer les limites de la méthode RMM qui réside dans son incapacité à modéliser les pages web complexes ainsi que la non flexibilité du slice et la conception de l’hypermédia. Pour remédier à ses limites [Isak97b] préconise les diagrammes et les m-slices construits à partir des attributs.
Le processus de changement et de remplacement sont appliqués de manière ascendante et descendante qui, combinés aident à comparer les diagrammes d’applications et à identifier les problèmes durant la phase de conception.
A part RMM, les applications web disposent aussi de la méthode HERA pour la création de la présentation et des adaptations en prenant en compte des critères individuels de l’utilisateur et les derniers sites qu’il a visité. La conception dans un projet HERA se fait en deux niveaux dont la manifestation des liens de navigation et la production des diagrammes de présentation. Dans cette méthode, la liaison des m-slices et de la région peut affecter un mêmes slice dans différentes régions. Cette liaison se base sur trois relations dont la relation de navigation, les relations temporelles, les liens hyperliens de navigation.
La conception des adaptations spécifie l’apparence des m-slices en matérialisant leur relation, les adaptations en HERA sont l’adaptabilité et l’adaptativité qui mettent en œuvre et conçoit les dimensions de mémorisation et la taille de l’écran. Bref, HERA est une étape de passage d’un niveau logique vers une phase de finalisation. Elle est une étude à la fois statique et dynamique de la présentation et changement de la navigation.
Le Web ML quant à lui est une codification qui se veut graphique et se basant sur le langage XML des applications complexes. Il sert à structurer les données et les pages. Cette phase procède par l’assemblage des besoins, la conception des données, la création de l’hypertexte, la conception de la présentation, la conception des utilisateurs, et enfin la phase de conception de la personnalisation.
La collecte des données i détermine les objectifs du site par rapport aux utilisateurs, la création du modèle de structure ; la phase de création de l’hypertexte construit les modèles de navigation et les nœuds et aussi la mise en relation des pages. Pour ce qui est de la phase de conception de la présentation, elle assemble les feuilles de styles et présente de manière adéquate les contenus ; la conception des utilisateurs est faite pour décrire le profil utilisateur ou identité personnelle qui profite d’un UML et élaborer des données lui correspondant.
En finale la phase de conception de la personnalisation comme son nom l’indique est une étape de personnalisation de la page d’après les données de l’utilisateur. Elle s’accomplit suivant le comportement de l’usager encore appelée personnalisation déclarative parallèle ainsi que la catégorisation de l’usager à correspondre à un groupe de personnes ayant des traits d’informations communs.
Le Web ML est un des travaux HDM Lite en adaptant ses propositions à la généralité spécifique du web. L’un de ses points forts est cette représentation graphique grâce à l’XML. En applications web, on remarque plusieurs dimensions à la base du Web ML aboutissant aux modèles de structure, d’agencement, et de navigation.
Le modèle de dérivation consiste à augmenter la faculté d’expression et à rajouter dans le diagramme des éléments pour redéfinir les données. Ce modèle sert à transférer les attributs d’une entité vers une autre et à créer des entités.
Le modèle structurel façonne les éléments dans le site directement en relation avec les entités qui sont hiérarchisées et représentées par des attributs nommés ou typés. Le modèle structurel s’appuie sur une lien et communication entre l’entité et la relation.
Le modèle de composition sert à délimiter le nombre de pages et informations qu’un site peut englober, il propose un contenu symbolisant l’hypermédia qui va déterminer les pages.
Le modèle de navigation qui constitue les liens textuels et non contextuels forme l’hypertexte et relie librement les pages en les rendant indépendantes des unités.
Pour améliorer les éléments saisis dans le site web, des initiatives [Ceri00b] ont été prises et ceci dans le cadre de pouvoir mieux gérer, modifier, ajouter et supprimer d’autres sous-éléments ou données.
Après avoir analysé profondément ce second chapitre de notre mémoire, nous allons maintenant nous concentrer uniquement sur le troisième chapitre c’est-à-dire sur l’état de l’art et la contribution des Lignes de produits et des Systèmes d’informations,
Chapitre 3. Lignes de produits et les Systèmes d’informations, état de l’art et contribution
Ce chapitre traite de l’état de l’art et de la contribution des lignes de produits et des Systèmes d’information. Pour bien cerner ce sujet, nous allons d’abord établir un petit état de l’rat des Systèmes d’Information Web ou SIW.
- Etat de l’art des SIW
1. Le concept de SIW
Isakowitz et al. définissent le SIW comme étant un système d’information basé sur les technologies web (1998). A cet effet, plusieurs auteurs (Detlor, 1999; Isakowitz et al., 1998; Press, 1999, Takanashi, 1998) considèrent l’intranet, l’extranet, le commerce électronique et le site Web externe externes formant un système d’information comme faisant partie de la grande famille des SIW.
2. Portrait des SIW
Le Web a émergé au début des années 1990, suscitant une révolution dans le domaine de la diffusion et du traitement d’information. Le Web est une application reposant entièrement sur Internet, ce qui lui permet de disposer d’un espace d’information de la même envergure qu’Internet. Au début de sa mise en place, le web a été centré sur le concept d’hypertexte : un principe simple d’organisation non-linéaire des contenus informationnels hébergés sur des machines distantes et accessibles par de multiples chemins de navigation. (Villanova-Oliver, 2002)
Outre l’hypertexte, on distingue aussi l’hypermédia. Ces concepts diffusent et présentent les informations sous forme de textes, de vidéos ou d’images, sous-entendant une implication directe de l’utilisateur du point de vue de ses besoins et exigences. En général, le concept d’hypermédia est le plus utilisé par les applications web pour présenter telle ou telle information. Ce concept permet aussi de traiter les informations à travers l’interface Web. Ce sont ces applications web qui forment les systèmes d’information web puisqu’elles sont basées sur le web [Taka97][Isak98a].
Les systèmes d’information peuvent être traditionnels ou SIW, c’est-à-dire basés entièrement sur le web. Les SIW requièrent l’intervention d’acteurs humains tout comme le déploiement de ressources matérielles et techniques et d’outils spécifiques.
De plus, il doit contenir des règles de fonctionnement, de données et de procédés pour acquérir, mémoriser, transformer, rechercher, communiquer et restituer ces données [Roll88]. On parle alors de SIW ou Système d’information web lorsque les SI dépendent du Web dans leur mise et place et leur exploitation. Le concept d’hypermédia permet à un système d’information d’être diffusé par plusieurs chemins sur le Web, impliquant la circulation facile et répétée d’une information qui peut être obtenue en empruntant plusieurs chemins sur Internet.
Concevoir une SIW n’est pas facile et nécessite l’intervention des personnes habilitées à le faire, c’est-à-dire de professionnels de l’information. Ces derniers doivent prendre en compte deux dimensions essentielles dans la conception des SIW :
- L’activité d’organisation d’information qui constitue le support de navigation et qui ne doit pas être négligée puisqu’elle permet de présenter l’information sur le Web,
- L’activité consacrée spécifiquement aux aspects fonctionnels qui est primordiale dans la mesure où elle permet de concevoir les services que le SIW doit respecter.
Les SIW sont différents des SIT ou Systèmes d’Information Traditionnels. Les SIT sont considérés comme étant classiques et non mis à jour du fait qu’ils ne dépendent pas d’Internet. Ils sont alors plus compliqués à utiliser et ne s’adaptent plus vraiment à l’époque technologique d’aujourd’hui. Le fait que les SIT ne soient pas fondés sur le Web implique alors qu’ils ne se focalisent pas prioritairement sur la navigation et sur la présentation sur Internet tout comme les SIW. A une époque où le règne d’Internet dans le monde entier est incontestable, on note une dégradation de l’usage, de l’utilité et de la pertinence des SIT non basés sur le Web au profit des SIW. En effet, ils ne permettent pas diffusion rapide et presque sans limite des informations comme c’est le cas pour le SIW.
Les SIW dotés d’une conception d’hypermédias, par exemple, est un exemple bien typique de la différence flagrante entre le SIT et le SIW. Si le SIT ne s’intéresse presque pas à la navigation et aux outils d’Internet, le SIW, par les hypermédias, se concentre grandement sur l’agencement des pages Web, à la conception de liens entre elles en termes de navigation et à l’ergonomie des pages avant de les présenter. Zelnick met en évidence une étude portant sur l’attention portée sur la présentation des pages en matière de SIW et souligne l’importance de cet acte.
Les différences entre SIT et SIW sont aussi flagrantes du côté des utilisateurs et de la faculté de ces SI de s’ouvrir à leurs utilisateurs. N effet, on constate que les SIT détiennent un nombre plus restreint d’usagers que les SIW du fait des informations diffusées n’importe où dans le monde grâce à Internet. Cependant, les SIW tels que l’intranet peuvent tout aussi bien cibler leurs utilisateurs et les limiter en termes de nombre. On constate alors que les SIW et les besoins et attentes des utilisateurs sont également interdépendants.
Les SIW profitent d’une accessibilité qui les avantage grâce au Web et disposent d’un public mixte et hétéroclite. Ainsi, ces usagers ont chacun des objectifs, des connaissances, des préférences, des conditions d’accès aux SIW et des compétences différents et spécifiques, ce qui incite les SIW à prendre en considération les exigences et besoins des utilisateurs en priorité.
A cet effet, on parle aussi de capacité d’adaptation des SIW (Villanova-Oliver, 2002) vis-à-vis des attentes des usagers. Cette adaptation a pour but de rassurer et de fidéliser l’utilisateur, de lui montrer que la présentation de la page et l’interface qu’il visite ont été conçues spécifiquement en accord avec ses goûts et ses exigences.
Les SIW sont considérés comme un système d’information composé par plusieurs réseaux. Baker identifie les extranets, les intranets et Internet comme formant un seul réseau d’affaires. Un SIW dispose d’n modèle général constitué par quatre dimensions et trois phases de développement présentées dans le tableau ci-dessous :
Les dimensions des SIW :
• une dimension informationnelle qui fait référence à l’information contenue dans le SIW et aux tâches reliées (organisation, repérage, etc.);
• une dimension technologique qui comprend l’ensemble des aspects technologiques du SIW comme les langages de programmation utilisés ou l’architecture technologique; • une dimension « interface graphique » qui est composée des aspects graphiques du SIW tels que la mise en page, la signature graphique, etc.;
• une dimension « interaction système-utilisateurs » qui rend compte des moyens pris — autres que l’interface graphique — pour gérer l’interaction des utilisateurs avec le système comme, par exemple, de la formation à l’utilisation du SIW ou la personnalisation du système à des profils d’utilisateurs.
|
Les phases de développement des SIW :
une phase de planification stratégique où les buts du SIW ainsi que les politiques générales gouvernant les entrées, le traitement et les sorties sont définis;
• une phase de conception et d’opérationnalisation où le SIW est conçu, développé, mis en place, maintenu à jour et évaluer;
• une phase de gestion des ressources où ce qui est nécessaire au soutien des tâches du SIW est défini sur les plans humain, technologique et financier, et où s’effectue la coordination de la technologie, des données et des ressources humaines afin d’atteindre les objectifs du SIW.
N.B.
Il est à noter qu’un SIW ne passe pas nécessairement par ces trois phases de manière linéaire. Son développement peut être itératif et le faire passer par les différentes phases de manière répétée et sans respecter d’ordre précis. |
Tableau 3. Dimensions et phases de développement des SIW. Source : Villanova-Oliver M. (2002) : Adaptabilité dans les systèmes d’information sur le web : Modélisation et mise en œuvre de l’accès progressif, Thèse pour obtenir le grade de Docteur, Institut National Polytechnique de Grenoble.
3. Systèmes d’Information basés sur le Web
Comme nous l’avons maintes fois signalé précédemment, les SIW sont basés sur le Web. Dotés des concepts d’hypermédias et d’hypertextes, les SIW offrent une gestion de l’information fondée sur un réseau « nœud » reliés entre eux par des liens. Ces nœuds sont les hypermédias et les hypertextes. L’hypertexte est un réseau de nœud servant à produire des textes, c’est-à-dire que l’information n’est composée que de textes.
Lorsque les informations sont illustrées non seulement pas des textes, mais aussi par des images, des sons ou des vidéos présents simultanément sur une même page de présentation, on parle d’hypermédias. On constate alors que les sites Internet et les pages web actuelles sont touts composés d’hypermédias puisqu’ils comportent l’ensemble de ces éléments.
S’intéresser à l’hypermédia est alors plus intéressant en SIW qu’aux hypertextes. Contrairement aux SIW qui sont des concepts émergents et assez neufs, l’hypermédia a déjà été discuté depuis 1945 par Vannevar Bush dans son article As we may think. Dans cet article, Vannevar Bush met en exergue la différenciation du fonctionnement d’un ordinateur ou des systèmes informatiques vis-à-vis du fonctionnement du cerveau humain.
Pour illustrer ses affirmations, il compare alors le mode de stockage et de récupération d’informations d’un cerveau humain avec un système d’information qu’il juge usant de techniques rigides et linéaires, contrairement au cerveau humain qui, pour ces mêmes tâches, raisonne en associant plusieurs idées à la fois et use de différents chemins pour arriver à la finalité qui est le stockage et la récupération des données.
Quant au terme hypertexte, il fut inventé par Ted Nelson en 1965 en se basant sur les œuvres de Bush. Ce dernier relie le cerveau humain au système informatique en leur attribuant un processus similaire dans le stockage et la récupération de donnée. Les chemins décrits par Bush sont, pour Nelson, empruntés par le cerveau en fonction de ce qu’il cherche ou de ce qu’il attend. Les systèmes informatiques et le cerveau humain usent donc à peu près du même processus pour arriver à leur fin.
Le concept d’hypermédia existe donc depuis plus d’un demi siècle mais n’a été popularisé et vulgarisé que grâce à deux évènements marquants [Lang01a] :
- Le lancement d’Apple de l’outil auteur Hypercard et 1987 qui est considéré comme un « organisateur d’informations ». cet outil fonctionne avec les mêmes principes qu’un concept hypermédia. Véritable innovation à cette époque, l’Hypercard est doté de ce qu’n appelle un HyperTalk, un outil créant des scripts permettant à l’usager de relier entre elles les informations qu’il a classées en unités ou cartes.
HyperCard comporte des textes, des sons et des images fixes ou animées à la fois, ce qui lui vaut une popularité immédiate. D’ailleurs, cet outil a été vendu en un million d’exemplaire lors de sa première année de mise sur le marché et a promu l’hypermédia auprès des personnes dotées de matériels informatiques t pouvant user de l’hypermédia pour créer leur propre application.
- La création du Web est le second facteur de popularisation de l’hypermédia. Lang considère que bien que l’hypermédia ne soit pas obligatoirement basé sur le Web, ce dernier à permis de le développer et de le promouvoir partout dans le monde. (Bieber, 1997).
Maintenant que nous avons vu l’Etat de l’art et notamment l’historique des SIW, nous allons entrer dans les détails de ce troisième chapitre en nous focalisant sur les architectures de ligne de produits pour le design des applications Web.
- Notion d’applications Web
Les applications web sont surtout utilisées en tant que « vitrine sur le web » (Xiong 2008) par les entreprises, les organismes, les institutions et les particuliers dans le but de promouvoir leur image et de l’améliorer ainsi que de mettre en ligne leurs prestations. Dans cette optique, toute application est sujette à une conception complexe et optimale et à un souci de développement d’interfaces. L’interface est la page que l’usager utilisera pour mener une action bien définie comme effectuer des achats en ligne, des emprunts de livres, etc.
Plus elle est qualitative, plus son usager réalisera avec succès les objectifs qu’il s’est fixé en l’utilisant. Cette insatisfaction des clients conduit à une mauvaise publicité du concepteur de l’interface, et donc à une mauvaise image de l’entreprise proposant les services.
Dans ce cadre, Thatcher (2006) expose un vote de lois en faveur du respect de la qualité des applications web dans plusieurs pays. Cette loi exige le respect des exigences minimales et d’obligation en termes d’application relatives à la conception et au développement des applications web. Dans cette mesure, la conception optimisée d’interfaces (Rossi, 2006) de qualité supérieure est devenue une exigence prioritaire pour les concepteurs d’applications web. Cette conception optimisée est aussi relative aux exigences de plus en plus capricieuses en faveur de l’évolution grandissante des applications web dans l’espace et dans le temps et en tenant compte des attentes des utilisateurs.
En 2001, Ivory développe des solutions afin d’assurer un suivi de développement ergonomique d’une application web en référence à l’optimisation de sa conception. Il développe entre autres :
- Des démarches de conception centrées utilisateur,
- Des démarches de conceptions participatives,
- Une organisation de connaissances ergonomiques et
- Des méthodes d’évaluation.
Les applications web exigent la mise en place d’un processus de conception web complexe et uniformisé avec une mise à jour ponctuelle de la page pour rester d’actualité. Il s’agit de processus de conception classiques retranscrit d’un mémoire de Joseph Xiong en 2008.
La navigation est un aspect important des applications Web [Fleming 98] que nous ne retrouvons pas dans les systèmes interactifs classiques. Dans une application Web, nous ne parlons plus d’« utiliser » l’application mais de « naviguer » dans l’application. Si la navigation est mal conçue, l’utilisateur peut se perdre et passer du temps à chercher l’information voulue. Dans le pire des cas, l’application ne lui offrira pas la possibilité de revenir sur ses pas (auquel cas, l’utilisation de la fonction « retour arrière » du navigateur sera obligatoire). Par conséquent, la navigation peut causer des problèmes d’utilisabilité importants et nécessite d’être prise en compte dans une étape du processus de conception ;
|
Le contenu informatif est important pour les systèmes interactifs Web, contrairement aux systèmes interactifs classiques où le traitement des données est plus important. Ainsi, les informations sont fréquemment mises à jour (d’autant plus que ces mises à jour sont rapides et peu coûteuses). Le contenu d’une application Web peut être amené, dans certains cas, à évoluer plusieurs fois en une journée ceci afin d’y ajouter de nouvelles informations, d’y apporter des modifications sur le contenu existant, etc.
|
Tableau. Source : Xiong Joseph (2008) : Une méthode d’inspection automatique de recommandations ergonomiques tout au long du processus de conception des applications Web. Thèse en vue de l’obtention du doctorat, Université Toulouse III – Paul Sabatier.
Pour peaufiner ce processus de conception, Scapin et al.v(2000) développent un processus de conception itératif pour le web basé sur ces phases :
- Expression des besoins – La phase Expression des besoins (ou Analyse des besoins) identifie les principaux buts des commanditaires, le contexte d’utilisation et les besoins. Elle comprend la collecte du contenu qui sera utilisé plus tard.
- Spécification – La phase de Spécification (ou Modélisation conceptuelle) produit des spécifications à partir du contexte d’utilisation et des besoins recueillis dans la phase précédente. Des modèles détaillés sont construits pour formaliser les besoins, comme, par exemple, la structure de navigation, les tâches utilisateur réalisables avec l’architecture de l’application et du site.
- Conception – La phase de Conception consiste à affiner les spécifications d’après leur contenu. A la fin, des modèles de navigation, de page et de données sont construits. Une spécification détaillée est produite afin de guider l’implémentation de l’application Web.
- Implémentation – La phase d’Implémentation (ou Développement) correspond à la construction physique de l’application Web, à la production des pages HTML et à l’éventuelle intégration de contenus multimédias (son ou vidéo). A la fin de cette phase, toutes les pages ont un contenu, des liens et des éléments graphiques incorporés. L’application est prête à être livrée. (Xiong, 2008)
Cette conception optimisée entraine une évaluation performante de la qualité des applications web qui, selon BRA (2000), nécessite une forte interaction entre deux types d’utilisateurs et le site web :
- les utilisateurs finaux qui sont surtout à la recherche d’information ou de produits à acheter. Ils ont un comportement qui est fortement affecté par leur culture, leur langage, leur niveau de connaissances antérieures dans le domaine et leur expérience sur le Web. Ils interagissent avec les sites Web via une couche de technologie qu’ils ignorent, qui n’est pas sous le contrôle du concepteur du site et qui comporte : les navigateurs, les protocoles, les plug-ins, les systèmes d’exploitations, les plate-formes, les dispositifs d’interaction (écrans, multimédia…) et les connexions réseaux ;
- les développeurs et les professionnels de la maintenance qui essayent d’offrir un site de qualité en maintenant le caractère opérationnel du système ou en l’améliorant. Ils font face à une technologie qui évolue très rapidement et à un système qui a un cycle de vie très rapide. La maintenance d’un site Web se fait avec un rythme plus important que les autres produits logiciels à cause de la pression du marché et de l’absence d’une barrière de distribution. En plus, la portée de la maintenance devient souvent tellement large qu’une refonte totale du site est parfois nécessaire. (Badri L., Badri M., Belkhiter et Malak, 2001-2002).
Les applications web doivent avoir une qualité optimisée (Malak,, Belkhiter, Badri M et Badri L, 2001-2002). Malak et al. ont donc dressé un tableau représentant les Caractéristiques et sous-caractéristiques de la qualité d’une application web :
1. Fonctionnalité |
– aptitude
– exactitude – interopérabilité – sécurité – conformité
|
2. Fiabilité | – maturité
– tolérance aux fautes – possibilité de récupération
|
3. « Utilisabilité » | compréhensibilité
– facilité d’apprentissage – attractivité
|
4. Rendement | – performance (temps)
– ressources
|
5. Maintenabilité | – facilité d’analyse
– facilité de modification – stabilité – testabilité
|
6. Portabilité | – facilité d’adaptation
– facilité d’installation – conformité – interchangeabilité
|
Caractéristiques et sous-caractéristiques de la qualité. Source : Malak et al.
Outre les caractéristiques définis par Malak et al., plusieurs auteurs ont également mené des études sur la qualité des applications web.
Jakob Nielsen propose une approche de la qualité des applications web entièrement focalisée sur l’utilisabilité, sans pour autant laisser de côté les autres critères. Ainsi, il définit une « loi de Jakob sur l’expérience des utilisateurs » dans laquelle il stipule que le « les utilisateurs passent la plus grande partie de leur temps sur d’autres sites que le vôtre, et c’est là qu’ils construisent leur expérience et apprennent à se faire une idée du mode de fonctionnement du web… ». (Nielsen, 1990).
Dans cette optique, Nielsen offre des conseils pratiques et des instructions concernant l’utilisabilité des sites web, ces recommandations sont pour la plupart fondées sur ses propres recherches et ne comportent pas de dimensions quantitatives.
Chignell et Keevil ont également adopté l’utilisabilité pour traduire la qualité d’une application web, plus précisément d’un site web. Leurs recherches s’orientent vers la rédaction du contenu web qui doit se faire dont le style d’écriture doit être précis, objectif et exact. Leurs travaux se sont alors orientés vers les recherches de Nielsen grâce auxquels ils ont dressé une check-list ou liste de vérification comportant 203 focalisées sur les utilisateurs des sites web. Cette liste de vérification contient des instructions issues des travaux de Nielsen et englobe des critères tels que :
- la facilité à retrouver l’information recherchée,
- la compréhensibilité de l’information,
- la capacité à répondre aux besoins de l’utilisateur, la capacité à présenter une information exacte et
- la présentation de l’information.
La capacité des sites web à remplir ces critères et à les appliquer permet d’affirmer qu’ils sont de qualité. Outre l’utilisabilité, ces deux auteurs préconisent également l’actualisation régulière du site web et de leur contenu ainsi que l’usage de techniques interactives. De ce fait, ils invitent les développeurs de sites web à échanger avec leurs utilisateurs dans les sites, comme c’est le cas pour les blogs ou tout simplement en incluant un espace dédié aux commentaires dans les pages contenant des articles.
Cette pratique permet de mettre en valeur l’utilisateur et de lui montrer que le site est bien à son service pour lui fournir ce qu’il attend. Pour détecter les besoins des utilisateurs, poser un questionnaire en ligne est une solution envisageable, à condition que les questions soient fermées et nécessitent donc une réponse catégorique entre oui ou non. Le but d’un tel questionnaire est de minimiser les réponses trop subjectives de la part des utilisateurs et de privilégier leur objectivité afin d’améliorer la qualité du site web.
Dans le cadre de l’utilisabilité, Chignell et Keevil mettent l’accent sur la présentation de la page web ou du site avec une langue et un style rédactionnel impeccables, un format adéquat, etc. La liste d’évaluation qu’ils proposent permettra de recueillir des avis objectifs de la part des utilisateurs. Pour ce faire, les deux auteurs recommandent de poser des questions bien détaillées.
Guay et Poulin (2001) ont également étudié la façon d’optimiser la qualité des applications web, notamment des SIW. Ils ont alors conçu u prototype expérimental d’évaluation quantitative des SIW en se basant sur les travaux de plusieurs chercheurs. A cet effet, ils ont orienté leurs recherches uniquement sur l’utilisabilité des SIW en s’identifiant aux recherches de Chignell et de Keevil. Ils préconisent alors l’usage des métriques pour accentuer la qualité des SIW.
Pour Guay et Poulin, les SIW sont un ensemble de logiciels, de données, d’information et du design graphique, de plus, ils caractérisent les SIW comme étant l’expérience différente pour chaque visiteur. En outre, ils proposent aussi d’optimiser la qualité des SIW en prenant en compte ces quatre dimensions :
- l’utilisation
- la maintenance
- le développement et
- la technologie (Guay, Poulin, 2001)
Cornela Boldyreff a également dirigé des recherches sur la qualité d’une application web. Dans cette mesure, elle a distingué les différences entre un site web, une page web et un composant : « un site peut comprendre un certain nombre de pages, et une page peut être composée d’un ou de plusieurs composants…Nous croyons (les auteurs) que la présentation apparente à l’utilisateur est un facteur important du succès ou de l’échec d’un site Web. Ainsi, il est vital de comprendre l’apparence d’une page Web et non pas de la réduire simplement à ses composants. »
Boldyreff et son équipe ont également identifié huit dimensions suivant lesquelles les sites web et les pages web peuvent être classifiés :
- la taille,
- le domaine,
- l’objectif,
- la technologie,
- la fonctionnalité,
- l’âge,
- le taux de changement, et
- la stratégie d’évolution. (Boldyreff, 2000).
Luis Olsina est un autre chercheur ayant comparé et mesuré la qualité des applications web, surtout durant leur phase opérationnelle. Cet auteur préconise l’orientation vers le génie logiciel afin d’améliorer, d’analyser et de comprendre la qualité des applications web. Olsina rappelle la complexité des exigences et contraintes liées à la qualité des applications web qui requièrent.
Il recommande alors de mettre en place des processus et des dispositifs pour l’évaluation de la qualité des applications web en usant de l’ingénierie d’application web, mais aussi en usant d’outils appropriés à cette tâche.
A noter qu’Olsina a fait équipe avec l’Ecole d’ingénierie à UNLPam en Argentine pour approfondir ses recherches qui sont fondées sur les normes IEEE et ISO/IEC. Ces travaux certifiés concernent majoritairement les instructions et conseils sur la qualité du logiciel et sur les métriques existantes. En 1998, du fait de leurs recherches, Olsina et son équipe ont conçu le Website Quality Evaluation Method afin d’analyser les caractéristiques de la qualité d’un SIW ou Système d’Information Web.
Ainsi, nous voyons donc que l’efficacité et la qualité d’une application web sont déterminatifs de leur réussite. De nombreux auteurs ont lancé des recherches en la matière et décrivent une approche centrée sur :
- l’utilisateur et ses besoins, c’est-à-dire qu’e les développeurs des applications web doivent prendre en compte à un certain degré les exigences et attentes des utilisateurs et façonner les SIW, les sites web, les pages web et leurs composants en fonction de ces derniers.
- La présentation, c’est-à-dire le format, le contenu, le style, la rédaction et tout ce qui concerne l’aspect visuel de la page web. Cette dernière est également à modeler suivant les attentes des utilisateurs sur certains points.
- Les développeurs web qui doivent mettre leur inventivité et leur imagination au profit d’idées nouvelles. A cet effet, ils doivent également mettre continuellement à jour le contenu des sites web et s’informer sur les tendances du moment pour ne pas se laisser dépasser par la concurrence.
Outre ces critères, on remarque aussi que la qualité d’un SIW ou d’une application web repose aussi sur l’utilisation des métriques et des techniques certifiées telles que celles indiquées dans les normes IEEE et ISO/EP ou d’outils tels que des logiciels issus du génie logiciel.
- Architecture de ligne de produits pour le design des applications web
Peu de travaux relatent l’implication des lignes de produits dans la conception des systèmes d’information. Cependant, les lignes de produits sont une approche très répandue dans les applications web d’aujourd’hui. Pour preuve, l’article que nous allons étudier ici, une retranscription écrite des travaux de Balzerani, Di Ruscio, Pierantonio et De Angelis en 2005, traite d’une architecture de lignes de produits pour les applications web. Nous allons alors baser cette partie sur l’étude de cet article intitulé A Product Line Architecture for Web Applications.
Dans cette optique, nous parlerons du modèle Koriandol, un outil permettant de développer, de déployer et de maintenir des familles d’applications web.
Actuellement, les applications Web sont de plus en plus utilisées dans des environnements similaires pour accomplir des tâches similaires et rendre uniformes et équitables les éléments de conception de l’hypermédia. Le partage d’une infrastructure commune et la réutilisation des actifs de déploiement et le développement des services récurrents qui se répètent plusieurs fois peuvent être considérés comme un avantage en termes d’importance économique et de qualité globale.
Ainsi, il peut être opportun de concevoir des applications Web en tant que membres d’une famille de produits et de les classer hiérarchiquement dans une catégorie englobant toutes les applications relatives à la création de site web. Le document présent illustre Koriandol, une architecture élémentaire de la gamme de produits conçue pour développer, déployer et maintenir une concordance entre les éléments d’applications Web. Contrairement aux composants ordinaires dont les systèmes sont basés sur les composants, Koriandol prescrit que les mécanismes de manipulation de variabilité sont le reflet d’une garantie de construction et d’élaboration du web.
- Introduction
Au cours des dernières années, les systèmes Web progressent allant de la collection des pages statiques non évolutives vers des applications complexes. La pertinence économique et la complexité croissante de ces applications nécessitent des techniques modernes convenables et des modèles qui peuvent offrir un meilleur retour sur les temps de développement et les facteurs de qualité. Par contre, les méthodes traditionnelles sont souvent basées sur les simples compétences des programmeurs individuels et n’appliquent pas toujours les principes du génie logiciel et les apports des techniciens web.
Comme les applications Web ont souvent des comportements similaires, mettre l’accent sur le déplacement de la conception d’applications simples et individuelles vers celle de la famille de systèmes est un moyen efficace pour poursuivre la réutilisation du logiciel et sa pérennité. En particulier, les systèmes basés sur le Web peuvent être considérés comme des produits logiciels issus d’une infrastructure et des biens communs qui capturent l’ abstraction spécifique dans le domaine, par exemple le panier, la caisse, et l’enregistrement de l’utilisateur dans un système de vente en ligne.
- Architectures de ligne de produits
La réutilisation de logiciels est une vision simple mais puissante qui vise à créer des systèmes de logiciels artefacts existants plutôt que de construire des systèmes en partant du début de la conception. Exploiter les points communs entre les membres d’une famille de produits ainsi que les familles de produits similaires devient un moyen efficace pour poursuivre la réutilisation du logiciel et assurer son efficacité. Une ligne de produit logiciel se compose généralement d’une architecture de lignes de produit ou Product Line Architecture (PLA), un ensemble de composants réutilisables et un ensemble de produits dérivés des ressources partagées en commun.
Chaque produit hérite en architecture de la PLA, sollicite et configure un sous-ensemble des composants de la ligne de produit et contient généralement un code de produit spécifique permettant une meilleure catégorisation et différenciation. Le potentiel majeur pour la PLA est de simplifier la conception et l’entretien des familles des programmes et de répondre aux besoins des applications hautement personnalisables de manière rentable.
En utilisant une ligne de produits logiciels, les développeurs sont en mesure de se concentrer sur des questions spécifiques sur chaque produit plutôt que sur les questions qui sont communes à tous les produits (Van Gurp, Bosch. Svahnberg., 2001). En résumé, une PLA est un modèle pour une famille d’applications dépendantes qui vise à une réutilisation des applications pour pouvoir assurer une durabilité et une efficacité. Le concept clé du développement des familles est la variabilité du système, comme la capacité destinée à dériver divers produits à partir de la famille de produit.
La variabilité est caractérisée par et associée aux points de variation, c’est-à-dire que des lieux de conception et une mise en œuvre sont nécessaires pour atteindre un intervalle de fonctionnalité. Chaque point de variation a un ensemble de variantes qui expriment sa variabilité, les points ne sont pas liés jusqu’à une variante particulière et sont sélectionnés, jusqu’à ce qu’ils doivent être liés à cette variante.
L’association à chaque point de variation est un temps de liaison, durant lequel la résolution du point de variation a lieu. Les Temps de liaison typiques sont la configuration et la réalisation de l’architecture ainsi que de la sélection des composants de paramétrage. La configuration des composants de paramétrage vise à instaurer les différents paramètres tandis que le temps de démarrage et d’exécution constitue l’implémentation du site
La Manipulation de la variabilité est une rude tâche du fait que les différences entre les produits d’une même famille de produits peuvent être décrites en termes de fonctionnalités et de caractéristiques de chaque produit. Une caractéristique est une unité logique de comportement qui est spécifiée par un ensemble d’exigences fonctionnelles et de qualité.
Par conséquent, les caractéristiques réalisent un moyen de faire abstraction des exigences et cela encore grâce à la catégorisation. Les exigences sont liées aux caractéristiques d’une relation n-to-n. La modélisation d’entité est une approche importante pour la capture des points communs et des variabilités dans les familles de systèmes et les lignes de produits.
Plusieurs méthodes ont été proposées pour identifier les modèles, parmi elles figure l’analyse de domaine FODA ou Feature Oriented Domain Analysis qui est souvent désignée comme l’une des plus émergentes et fiables car elle fournit à la fois un processus pour déterminer les caractéristiques communes et les variables d’instances du concept ainsi que leur interdépendance et une notation pour les représenter dans des modèles longs constitués de longs diagrammes d’informations avec quelques données supplémentaires telles que les courtes descriptions sémantiques de chaque fonction, les contraintes mais surtout la dépendance par défaut de règles.
Les produits et éléments au sein d’une famille de produits sont généralement développés dans les étapes qui ont tendance à être asynchrone et indépendantes, c’est à dire une ingénierie de domaine et une ingénierie d’application en cours d’exécution en même temps. Cet asynchronisme est dû au fait que les produits sont des milieux d’édification et d’identification ; c’est plutôt à partir de la famille de produits que l’on procède à l’exécution.
L’ingénierie de domaine implique, entre autres, l’identification des points communs et des différences entre les produits membres de la famille et la mise en œuvre d’un ensemble de logiciels partagés de telle sorte que les points communs peuvent être exploités économiquement, tout en préservant en même temps la possibilité de faire varier les produits ou de les conserver.
Au cours de cette phase de variation, les points de variation sont conçus et un ensemble de variantes est associé à chacun d’eux pour effectuer les tâches ensemble. Les différents procédés d’ingénierie du domaine sont des composants logiciels fondamentalement réutilisables et dont les configurations et analyses des modèles de conception sont exigées. En général, aucun produit réutilisable ne dénomme une ressource réutilisable.
Pendant l’ingénierie d’application, des produits individuels sont dérivés de la famille de produits et construits en utilisant un sous-ensemble des artefacts logiciels partagés. Il est d’autant plus nécessaire de créer des actifs spécifiques aux produits supplémentaires ou de remplacement.
C’est dans cette phase que chaque point de variation est lié à une variante spécifique choisie dans l’ensemble de ses variantes associatives comme nous a montré l’étape précédente. Les étapes mentionnées ci-dessus constituent deux cycles de développement indépendant relatif c’est-à-dire un développement du point de vue de la réutilisation connu sur le terme technique de produit d’instanciation et de la ligne de produit elle-même. Une mise à jour des applications est maintenue par l’institut de génie logiciel
- KORIANDOL, une PLA spécifiquement conçue pour le web
Selon le modèle d’organisation fourni par Koriandol, une application Web peut être considérée comme une association de plusieurs pages. Une application Web est un produit consistant en un certain nombre de pages qui sont hiérarchisées d’après leur contenu et leur ordre de priorité. Chacune d’elles recueille un contenu de façon dynamique fourni par les composants sélectionnés.
Comme il est mentionné précédemment, les composants sont génériques, c’est-à-dire qu’ils sont conçus pour capturer les points communs et les variabilités d’une classe de comportement dans un des domaines d’application. Par exemple en tant que fonctionnalités typiques d’un système de vente en ligne, le panier, le catalogue, et la caisse sont réalisés à différents degrés de complexité. Chaque méthode offre une autre fonctionnalité et les valeurs admises pour ses paramètres formels sont représentatifs pour les variantes de fonctionnalité dont la sélection résout un point de variation à un seul bond.
De manière analogue, les méthodes choisies dans une page sont liées une fois que tous leurs points de variation aient été résolus. Un composant est un composant lié dès qu’une partie de sa méthode est choisie dans le produit.
Comme il est dit ci-dessus, les composants de Koriandol incarnent aussi une intégrité dans le mécanisme de la manipulation de la variabilité d’application dynamique qui permet aux ingénieurs de lier dynamiquement chaque point de variation à la variante appropriée. Selon les sélections de l’utilisateur précédent, le mécanisme révèle à travers l’introspection applicable les points de variation et leurs variantes associées. Ceci permet de naviguer et d’opérer un modèle de fonctionnalité sur le composant.
La composante englobe deux méthodes d’application qui sont le résumé d’un article affichant une liste de nouvelles et d’un article de contenu respectif. Elle est représentée en tant que solution de rechange pour les sous-composants du composant, on ne peut donc sélectionner qu’un composant à la fois. Le résumé à son tour, a une obligation de sous-fonction qui spécifie le nombre de nouvelles à résumer, et une autre en option qui applique un filtre de catégories.
.
Une correspondance entre la notation de longs diagrammes et de widgets HTML dont des cases à cocher ou des boutons radio a été définie. En exploitant cette cartographie, la gestion de la variabilité et les mécanismes peuvent être générés automatiquement à partir des spécifications déclaratives. Des diagrammes de fonction spécifiques à un domaine ont été proposés afin de fournir un texte commode de représentation.
Le temps de liaison typique pour le composant et la méthode de sélection composent la configuration d’architecture. Dans notre approche, la détermination de la variabilité peut être réalisée à la fois pendant la phase de post-déploiement ou période d’exécution ainsi que pendant la phase d’instanciation, ce qui rend les applications largement reconfigurables.
L’une des principales contributions de Koriandol depuis cette approche est d’améliorer les capacités de gestion post-déploiement de la variabilité de la phase d’ingénierie d’application. En outre, au cours de l’édification du produit d’instanciation, la variation non révélée précédemment peut offrir une variabilité supplémentaire à l’application des ingénieurs. Théoriquement, cela signifie qu’ils ont la possibilité de décider du nombre de variabilité à exploiter une tâche de conception qui est généralement limitée à l’ingénierie de domaine.
L’architecture proposée peut être utilisée pour développer une large gamme d’applications en fonction des domaines dont les abstractions et leurs relations sont capturées par marque actifs. Bien entendu, la nature des produits dépend nécessairement des composants disponibles et au cas où certains comportements manquent, le concepteur devrait se soucier de leur analyse, leur conception et leur réalisation.
Associations among the assets in a product
- Outil de support
Le système Koriandol compose des modules de logiciels spécialisés qui réalisent l’infrastructure commune du produit de l’architecture de la ligne décrite dans les sections précédentes. De plus, certains modules auxiliaires, principalement pour la gestion et la manipulation de configuration sont aussi fournis. Les unités de base suivantes sont parmi les plus importantes:
- la gestion
- le module de configuration,
- le terme de l’environnement en temps et
- le moteur de présentation.
Quand une demande de l’utilisateur arrive, le module d’exécution interprète grâce à WRT la spécification de la page correspondante. En d’autres termes, il valide les privilèges et exigences des utilisateurs afin d’accéder à la page et, au cas où les utilisateurs ont accès libre à la page. Le module identifie les composants qui doivent être invoqués pour servir cette demande particulière. Chaque fonctionnalité de la page est récupérée par une composante, c’est à dire un appel de méthode pour le composant sélectionné et configuré au cours de la variabilité pour la détermination de l’instanciation de la page.
La méthode renvoie le code XML qui est passé au moteur XSLT, un modèle qui génère du code HTML au moyen de feuilles de transformation. Une fois tous les composants et les demandes réalisés, les segments HTML obtenus sont mis ensemble et renvoyés à l’utilisateur.
Koriandol system
- Management/Configuration du module
Le management du module de gestion prévoit un soutien administratif des tâches tel que l’utilisateur, les composants et la comptabilité du produit entre autres. Ce sont des fonctionnalités assez habituelles mais qui requièrent la gestion et la configuration des composants. En fait, chaque composant doit être enregistré et validé avant d’être utilisé, suivant des prescriptions établies proposées par Koriandol comme une spécification d’interface. Le mécanisme de détermination de la variabilité est inclus dans une telle spécification afin d’accorder les possibilités de configuration du système.
Le système aide le concepteur de l’application dans les décisions d’enregistrement et d’entrée des directives, comme la préparation et la mise en option à utiliser dans une page. Cette opération et d’autres semblables qui ne sont pas décrites en raison de limitations de l’espace peuvent être réalisées au moyen d’une assistance interactive. Une fois qu’un composant est sélectionné, le système est capable de récupérer les fonctionnalités disponibles à travers la réflexion.
|
|
|
|
|
|
|
|
|
|
|
|
Ce ne sont pas toutes les méthodes qui peuvent être consultées au cours de cette étape mais seulement celles qui ont mis en œuvre une fonction, la plupart des autres sont soit utilisées localement pour le composant ou directement invoquées par le système. Une fois qu’une méthode est sélectionnée, le système met à la disposition du concepteur de l’application la partie inférieure de la forme obtenue par une autre méthode de la composante et présente tous les paramètres de la conception à offrir afin de déterminer les coordonnées désignant la variante souhaitée.
Feature diagram for a news component
- Environnement Run-time
La portée de l’environnement d’exécution coordonne d’une part toutes les activités entre les modules une fois la demande arrivée de l’extérieur et, d’autre part, récupère les fonctionnalités des contenus et services dynamiques qui sont demandées par les pages étant servies. Ces fonctionnalités sont dynamiquement récupérées par l’identification des méthodes de composant et la transmission des informations pertinentes qui sont évaluées selon les directives données par le concepteur lors de la détermination de la variabilité de cette instanciation spécifique.
- Présentation du moteur
Chaque composant est capable de produire des contenus qui sont structurés et donnés en XML. Les contenus sont livrés indépendamment de tout aspect de présentation qui porte principalement sur l’aspect d’une application. Le système fournit un moteur de présentation qui permet au concepteur d’associer à chaque fonction et chaque méthode dans un composant une autre feuille de style de transformation XSL ou encore un HTML.
Les feuilles de transformation XSL sont hiérarchiquement disposées selon la relation parentale entre les actifs, par exemple une feuille de style associée à un produit peut être substituée par une autre associée à une baisse des actifs en la hiérarchie, telle que celle associée à un composant ou une fonction. Ainsi, le concepteur de composants peut prendre des décisions importantes indépendamment des contraintes éventuelles qui pourraient être imposées par les aspects de présentation.
- Exemple
Les applications Web développées en utilisant le système Koriandol sont composées de services et de contenus transmis dans les pages qui sont arrangées hiérarchiquement. L’outil discuté dans la section précédente fournit les installations pour créer et organiser de manière cohérente les exigences de l’application en cours d’élaboration.
La page d’accueil implique trois composantes dont les fonctions de recherche de produits, une vitrine, et un formulaire d’authentification, respectifs. Chaque fonctionnalité est instanciée avec des paramètres qui sont spécifiques à l’exploitation intégrée dans la détermination de la variabilité de la réflexion mécanique. Par exemple, le composant fournissant l’installation de la vitrine peut avoir un certain nombre de points de variation, comme les catégories et les fréquences, qui sont utiles pour les produits et pour affiner les stratégies des fournisseurs. Dans ce cas, le système Koriandol fait une introspection du composant et récupère une forme similaire qui est utilisée pour lier une telle variation avec l’une des variantes disponibles.
- Travaux connexes
La plupart des études sur les produits logiciels pour ne citer que quelques-unes se concentrent sur la technologie et le processus qui sont liés au développement du produit, bien que l’effet du coût de développement des applications web soit peut-être un des domaines les plus difficiles de l’ingénierie du logiciel.
Dans une société spécialisée en architecture appelée OOHDM, Java2, est accordée au développement des applications Web. La famille de système définie par OOHDM est représentée par l’ensemble de la classe des applications Web possibles, des applications très générales et qui dérivent du modèle depuis les points communs. La principale différence avec Koriandol est dans l’absence de mécanismes de détermination de la variabilité dans car ils sont systématiquement traités pendant la conception de l’application. Effectuer une analyse de domaine correcte est essentiel pour un bon développement du logiciel produit.
Parmi les différentes approches, c’est la FODA qui a fondé ses bases sur une étude approfondie de l’analyse des domaines techniques. Le concept de fonctionnalité orientée introduit par FODA est basé sur l’accent mis par les méthodes sur l’identification de caractéristiques importantes ou distinctives dans une classe de systèmes liés à des logiciels. Ces caractéristiques conduisent à la création d’un ensemble de produits qui définit le domaine.
Koriandol se rapporte à FODA puisque les mécanismes de détermination de variabilité qui sont donnés à l’intérieur des composantes sont générés au moyen d’un langage spécifique de domaine, qui est une donnée de prolongement intensif d’une version textuelle de la fonctionnalité des diagrammes.
Abstractions featured by an e-commerce
- Conclusions
Le document décrit une architecture de la gamme de produits pour les applications Web, qui sont obtenues par une composition de composants réutilisables. Par le biais de mécanismes appropriés, qui sont assemblés directement dans les composants, les produits peuvent être instanciés et gérés avec un degré plus élevé de flexibilité.
En fait, chaque composant peut être mis à profit de manière interactive en reliant ses points de variation aux variantes spécifiques. Le plus important est que cette activité de configuration peut être réalisée pendant l’instanciation du produit, mais également après que l’application ait été déployée. Cela est dû à la détermination de la variabilité des mécanismes des composants et peut directement être appelé par le système par le biais de techniques de réflexion.
Par conséquent, les étapes d’analyse des caractéristiques et des variations de déterminations, sont globalement effectuées durant le domaine d’analyse qui peut être différé lors de l’ingénierie d’application. L’architecture a été totalement mise en œuvre conjointement avec les outils de gestion qui permettent à l’utilisateur d’administrer à la fois le système et les produits dérivés.
- Interprétation du document
Ce papier intitulé A Product Line Architecture for Web Applications (Balzerani, Di Ruscio, Pierantonio et De Angelis, 2005) représente un modèle de conception d’application web à travers la conception d’une ligne de produits. Pour ce faire, les auteurs prennent l’exemple de l’usage d’un outil dénommé Kordiandol permettant de concevoir une famille d’application web.
Les applications web peuvent donc être modélisées en se basant sur la conception d’une ligne de produits logiciels. Ici, les applications web sont des pages web censées diffuser des informations. La diffusion d’information se fait via une interface web qui doit être nourrie par des informations et des actualités diverses.
- Illustration à l’aide du cas du site de commerce en ligne Amazon.fr
En prenant le cas d’un site de commerce en ligne, on peut très bien illustrer cette affirmation. Les sites de vente en ligne doivent être présentés sur des interfaces ou des pages web. Toutes ces pages sont reliées par un lien hypertexte, un peu comme le concept du référencement. L’idée, pouvoir voguer d’une page à une autre sans avoir à ouvrir le volet recherche mais juste en cliquant sur le lien hypertexte d’un mot, d’une phrase ou d’une expression entière.
La page de produits à vendre à ligne doit à tout prix être vendeur et accrocheur, le design doit alors être bien pensé et requiert les compétences d’un développeur web. La conception d’une page passe avant tout par son design. Ce design doit être le plus convaincant possible, sans toutefois tendre vers le ridicule. A cet effet, le designer web use d’applications et surtout d’une stratégie de ligne de produit. Dans cette optique, il utilise le lien hypertexte comme étant une caractéristique commune renvoyant vers une autre page similaire à la précédente dans sa configuration mais différente du point de vue contenu. Cette seconde page présente alors des variabilités pour être différenciée de la première.
Plusieurs pages constituent un site ou une application web. Ici, l’application web en question est un système d’information web puisque le site informe sur des produits, leur prix et leurs caractéristiques en usant du web et d’internet. Lorsque la page web est ouverte à tous, elle n’est alors protégée par aucun mot de passe et ne nécessite pas de manipulations fastidieuses pour être consultée. Il suffira à son utilisateur de surfer sur Internet, de se référer au lien menant à la page qu’il souhaite accéder et de commencer ses activités.
Cependant les variabilités que nous avons précédemment évoquées stipulent la présence d’éléments neufs dans la conception des pages, c’est-à-dire que toutes les pages web sont similaires dans la mesure où elles appartiennent au même site. Leur similitude réside dans leur architecture, par exemple dans la présentation des pages qui est la même qu’il s’agisse de la page d’accueil ou de celle renfermant les articles à vendre, la page de contact, la page de renseignements, la page de services additionnels, etc.
Les variabilités sont alors illustrées par des variantes et des options telles que le volet contenant l’accessibilité de l’utilisateur à une interface personnelle ou à un espace spécialement dédié à ses activités dans le site. Ce volet est souvent aperçu sur la page d’accueil du site et requiert la connexion de l’usager à son compte personnel pour profiter d’avantages réservés aux membres du site. Il s’agit ici d’une option qui ne sera pas présente dans toutes les pages web et qui sera donc vue comme étant une « différence » par rapport au contenu des autres pages.
Page d’accueil et de présentation du site amazon.fr
Outre la page d’accueil, chaque page constituant le site d’e-commerce contiendra des différences tout en étant similaires dans leur architecture de base. On peut citer, en exemple, la page de renseignement sur le site ou la société ou le particulier qui propose des ventes en ligne à travers le site. A cet effet, cette page est éditée par une personne travaillant au sein de la société chargée de la promouvoir ou d’améliorer son image.
Page de renseignement du site de commerce en ligne amazon.fr
Outre la page de renseignement, on peut aussi trouver une page de contact dont le contenu et l’agencement architectural diffèrent également des autres pages. Cette dernière contiendra les coordonnées des concepteurs ou des hébergeurs du site, ou de la société qu’il représente.
La page de présentation des produits est tout à fait différente aussi tout en conservant des traits communs avec les autres. On peut par exemple trouver sur cette page les différentes offres disponibles, les promotions, le prix des articles, leur état et des options supplémentaires comme le panier dans lequel l’usager du site pourra stocker ses articles préférés pour faciliter son choix lors du prochain achat en ligne.
Page d’aide d’amazon.fr
Il va sans dire que chacune de ces pages doit être conçue par des professionnels compétents car leur contenu est unique alors que leur présentation, leur design et leur architecture sont conçues sur une même base et de la même manière. Ces professionnels sont des développeurs d’application web formés et expérimentés conscients des exigences et des besoins des clients et qui orientent la présentation de la page dans ce sens. En même temps, ils doivent aussi prendre en considération les types d’articles à vendre et leur usage pour ne pas dévier dans la conception des pages.
Leur but est donc d’attirer les clients et de leur indiquer rien qu’avec le design de la page web ce qu’ils proposent ou produisent. Pour améliorer cette présentation, certains sites n’hésitent pas à proposer un petit volet « boîte à idées » dans les pages afin de recueillir les avis des clients, de mener une étude approfondie en se basant sur eux et d’apporter les modifications nécessaires.
L’interface réservée aux concepteurs web et au développeur est différente de celle qui est visible du côté de l’usager du site, pourtant, il s’agit bien des mêmes pages. De ce fait, la manipulation par les concepteurs et par les utilisateurs est tout à fait différente. Les concepteurs les manipule de sorte à ce qu’ils accèdent aux données centrales et confidentielles du site pour pouvoir insérer les nouvelles offres, les nouveaux prix ou pour modifier le contenu ou le design de la page. L’utilisateur entre dans le site et se connecte sur son compte pour effectuer les activités qu’il a l’habitude de faire en visitant le site.
L’utilisateur n’a donc pas accès à la manipulation du site et n’a aucun pouvoir de changement direct sur celui-ci. On peut, par exemple, prendre le cas d’un site de vente de livres en ligne. Si les utilisateurs aperçoivent les offres, les titres des ouvrages, les prix et tous les détails nécessaires à l’achat, les concepteurs, eux voient bien au-delà puisqu’ils sont chargés d’implémenter ces données dans les pages.
Par conséquent, les concepteurs doivent aussi se mettre un peu à la place des visiteurs du site pour détecter leurs préférences ou leurs besoins et orienter les offres et le design des pages en fonction de ces éléments. Les concepteurs ont un rôle clé puisqu’ils sont chargés de mettre à jour les informations contenues dans le site, de les supprimer ou d’en insérer des nouvelles au fil du temps.
Les utilisateurs n’ont pas d’influence directe sur la conception des pages. Cependant, il faut avouer que les concepteurs agencent et arrangent la disposition des composants du site afin de les rendre cohérents mais surtout pour faciliter la recherche des clients. En prenant en compte cette affirmation, on peut partir de l’exemple où le concepteur trie les différentes offres et les différents produits selon leurs caractéristiques, leur type, leur usage, leur âge et leur utilité en fonction de la saison.
Après avoir effectué ce triage, ils se livrent alors à l’édification du site en classant les différents produits suivant leurs caractéristiques. En voici un exemple :
Pour que les utilisateurs d’un site de vente en ligne de livre, le site qui la propose peut classer les livres suivant leur caractéristique et créer des étagères virtuelles. Tous les livres seront alors agencés selon :
- leur titre,
- leur date de publication,
- le thème ou le sujet,
- le public ciblé par la lecture,
- le genre littéraire,
- le prix,
- les notes et commentaires attribués par les lecteurs/les critiques d’autres auteurs ou de journalistes sur les livres,
Lorsque l’utilisateur visitera le site, il pourra donc trouver d’emblée ce qu’il cherche grâce à cet agencement ordonné et structuré.
Page de connexion au compte ou d’ouverture de session sur amazon.fr
En prenant l’exemple du site de vente en ligne Amazon.fr, nous voyons clairement que les quatre pages présentées dans les figures que nous avons choisies sont similaires dans leur architecture. Sur chacune d’elles, le logo du site apparait, on note aussi l’usage de la couleur jaune orangée dans toutes les pages, nuancée avec le bleu et le noir. Le fond de toutes les pages a une même couleur : le gris. Il s’agit ici des similarités, ce sont éléments sont présents sur toutes les pages et permettent de reconnaitre d’un trait les pages du site.
Trois des pages que nous illustrons ici contiennent les options supplémentaires :
- accessibilité au compte sur amazon.fr
- adhésion à premium,
- panier,
- liste d’envies.
A priori, la plupart des pages du site contiennent ces options affichées en haut à droite de chaque page. Seulement, il s’agit ici d’une variabilité statique puisqu’elle n’apparait pas sur toutes les pages, comme c’est le cas pour la page de renseignement du site amazon.fr. Outre ces variabilités, on note aussi des variabilités représentées par le contenu de chaque page. En effet, chaque page a son propre contenu, ce qui peut constituer une variabilité.
Cette variabilité est alors illustrée par un titre différent pour chaque contenu :
- pour la page de renseignement, le titre est : « A propos d’Amazon
- pour la page d’ouverture de compte ou de session dans le site, le titre est : « Ouverture de session. »
- pour la page d’aide, le titre est : « Aide »
Le fait de donner un titre différent pour chaque page permet de se référencer à son contenu et de se rendre compte à première vue que toutes les pages ne sont pas unanimement identiques. Le titre choisi doit refléter le contenu et doit être disposé de la même manière dans toutes les pages pour informer le client sur ce qu’il trouvera dans la page. Ces titres peuvent donc être pris comme des variabilités.
Les lignes de produits au service du SIW sont donc traduites par la conception de plusieurs pages web pour un site web. Les pages web sont architecturées de la même manière avec un logiciel spécifique et présente des points communs comme le logo ou la couleur dans les exemples que nous avons présentés ci-dessus. Elles possèdent aussi un contenu et un titre diversifiés en fonction de ce que la page doit présenter. Il s’agit ici des variabilités.
Le système des lignes de produits basé sur la réutilisation est très visible dans ce SIW. En effet, on voit très bien que les pages web sont les produits ou les modèles. Il s’agit ici d’applications web. Les concepteurs ou développeurs web conçoivent alors ces pages autour d’un seul principe : la réutilisation, c’est-à-dire la possibilité d’user d’un ou de plusieurs éléments appelés assets ou composants réutilisables.
Ces assets, définis en ingénierie de domaine, sont des éléments pouvant être :
- Des logiciels,
- une interface,
- un logo, une couleur de page,
- une dimension,
- une structure,
- un design,
- une forme,
Grâce à ces assets, on peut voir que toutes les pages appartiennent à la même famille, dans le cas de l’exemple que nous avons choisi dans ce chapitre, il s’agit de la couleur de la page et du logo du site qui est Amazon.fr. Toutes les pages détenant ces mêmes caractéristiques sont donc issues de la même famille de produits.Le but de ces similarités est de permettre aux utilisateurs du site de reconnaitre immédiatement les pages qui le composent.
Outre ces similarités, les pages disposent également de variabilités représentées par la différence dans les titres ou dans les contenus des pages web. Ces variabilités décrivent l’unicité des pages, c’est-à-dire qu’elles permettent de voir d’un trait que toutes les pages ne sont pas intégralement identiques bien qu’elles soient similaires.
Grâce à ces variabilités et à ces similarités, on peut aisément comprendre la conception des pages qui repose essentiellement sur l’approche des lignes de produits. Afin de détecter, on use généralement des features ou caractéristiques telles que FODA.
Si nous concevons un diagramme de FODA pour le site Amazon.fr, on peut l’élaborer comme suit :
Les différentes pages sont ici les produits ou modèles.
Les similarités ou caractéristiques obligatoires sont le logo du site, la couleur de fond des pages et la couleur jaune orangée, la couleur noire et la couleur bleue utilisées dans le site
Les variabilités sont le titre et le contenu.
Pour en revenir aux rôles des concepteurs et développeurs web dans la gestion du site web ou du SIW, de son contenu ou de sa longévité, nous nous rendons également compte que les professionnels de l’information y ont aussi un rôle primordial à jouer.
- Rôle des différents intervenants dans la conception des SIW à partir des LdP
Des études se sont intéressées aux tâches et rôles des professionnels de l’information et des autres intervenants dans les SIW. Christine Dufour, dans sa thèse sur l’ « Étude du rôle des professionnels de l’information dans les systèmes d’information Web du gouvernement fédéral canadien », souligne plusieurs tâches et familles de tâches relatives à l’intervention des professionnels de l’intervention dans les SIW. Les tableaux ci-dessous sont issus cette thèse et expliquent en détail les tâches qui sont assignées aux intervenants dans la conception, le suivi et l’application des SIW.
FAMILLES | TÂCHES |
Politiques liées aux SIW |
• Gestion des politiques Définition : Gestion, coordination de différentes politiques et normes sur les SIW Exemple(s) : Coordination de l’ensemble des politiques pour le ministère • Développement de politiques Définition : Élaboration et mise à jour de politiques liées aux SIW et s’appliquant à différents niveaux organisationnels (unité, ministère, division, gouvernement) Exemple(s) : Politique sur les métadonnées pour le ministère
|
FAMILLES TÂCHES Contenu du SIW |
• Gestion du contenu Définition : Gestion, coordination du développement, de la sélection du contenu; inclut tout type de contenu (par ex. périodiques et bases de données en ligne, sites Web externes) Exemple(s) : Coordination des ressources Web mises sur une page thématique de l’intranet d’un service d’information • Création et mise à jour du contenu Définition : Création et mise à jour du contenu (informations primaires et secondaires) sans considération technologique comme le codage; inclut la traduction et la révision linguistique du contenu Exemple(s) de contenu : Documents élaborés dans le cadre du travail, textes sur le SIW, liens vers des sites Web externes d’intérêt, formations en ligne, contenu de bases de données et/ou catalogue en ligne • Organisation du contenu Définition : Organisation, classification, indexation du contenu Exemple(s) : Organisation du contenu dans les pages Web • Vérification de la qualité du contenu Définition : Vérification de la qualité, de la pertinence du contenu Exemple(s) : Vérification de la pertinence et de la qualité du contenu développé par les fournisseurs de contenu • Définition des métadonnées Définition : Définition des métadonnées pour les pages Web d’un SIW Exemple(s) : Définition des métadonnées pour le titre, l’auteur et les mots-clés des pages Web incluses sur le site Web externe d’un ministère • Élaboration de la navigation Définition : Élaboration et mise en place de la navigation du SIW, des moyens d’accéder au contenu Exemple(s) de moyens de navigation : Barres de menu, carte du site
|
Technologies |
• Gestion des technologies Définition : Gestion, coordination des différentes technologies Exemple(s) de technologies : Bases de données, réseau informatique, logiciels, matériel • Intervention technologique générale Définition : Intervention technologique générale par rapport aux différentes technologies utilisées Exemple(s) d’intervention : Assistance technique, évaluation de logiciels, sécurité technologique, mise en place et maintien de logiciels et de matériel (serveur, bases de données, réseau, moteur de recherche, système intégré de gestion de bibliothèques, catalogue en ligne, réseau de produits d’information) • Intervention au niveau des pages Web Définition : Intervention par rapport aux pages Web d’un SIW Exemple(s) d’intervention : Développement des pages Web utilisant différentes technologies plus ou moins avancées (html, javascript, cgi, perl, pages Web dynamiques), mise en ligne des pages Web sur le serveur, vérification de l’accessibilité des pages Web (liens hypertextes actifs, etc.), numérisation de certains contenus
|
Interface graphique |
• Élaboration du design Définition : Élaboration du « look », du design général du SIW et conception des éléments graphiques Exemple(s) : Agencement des éléments, choix des couleurs, élaboration des logos et des icônes
|
FAMILLES TÂCHES Utilisateurs |
• Interaction avec les utilisateurs Définition : Interaction avec les utilisateurs dans différentes circonstances Exemple(s) : Développement d’une compréhension de qui sont les utilisateurs et comment ils cherchent l’information pour définir un SIW orienté-utilisateurs, formation sur l’utilisation d’un système ou sur un des aspects des SIW, traitement des courriers électroniques provenant des utilisateurs (réponse, redirection, etc.)
|
Général / Transversal |
• Gestion d’un SIW ou d’un projet lié aux SIW Définition : Gestion, coordination d’un SIW ou d’un projet lié aux SIW Exemple(s) de projets liés aux SIW : Projet de métadonnées, projet de taxonomie, bureau du Gouvernement en direct • Planification d’un SIW ou d’un projet lié aux SIW Définition : Planification générale d’un SIW ou d’un projet lié aux SIW Exemple(s) : Planification globale, état de la question pour définir les objectifs, définition des orientations, des stratégies • Conseils, suggestions, recommandations Définition : Conseils, suggestions, recommandations sur certains aspects des SIW Exemple(s) : Recommandations sur l’utilisation des politiques, sur les métadonnées, conseils sur l’organisation du contenu, suggestions sur la sélection du contenu • Mise à niveau des connaissances de l’intervenant Définition : Mise à niveau des connaissances sur différents aspects liés aux SIW Exemple(s) : Mise à niveau des connaissances sur les technologies, sur les politiques • Conformité aux politiques Définition : Vérification de l’application des politiques ou mise à niveau d’un SIW pour respecter les politiques Exemple(s) : Développement de pages Web en respectant les politiques, vérification des SIW pour s’assurer du respect des politiques • Évaluation de la performance des SIW Définition : Évaluation de la performance du SIW par différents moyens Exemple(s) : Statistiques d’utilisation du SIW, tests d’utilisabilité, sondage sur la satisfaction des usagers • Développement de collections électroniques Définition : Identification, mise en place et maintenance des périodiques électroniques et bases de données en ligne accessibles par le biais du SIW Exemple(s) : Sélection des collections électroniques, mise en ligne des collections électroniques • Promotion, sensibilisation Définition : Promotion, sensibilisation à un SIW ou un des aspects d’un SIW par différents moyens Exemple(s) : Participation à l’élaboration d’un bulletin d’information sur les développements d’un SIW, démonstrations du SIW, participation à des conférences ou des congrès, sensibilisation aux métadonnées • Participation à des comités40 Définition : Participation, à divers titres, à différents regroupements liés aux SIW Exemple(s) : Participation à titre d’observateur dans un comité Internet, participation comme membre d’un groupe de travail sur les métadonnées
|
Tableau Tâches des autres intervenants dans les SIW. Source : Dufour (2003)
• La famille des tâches liées au contenu fait appel principalement à différents groupes et individus en charge de la gestion des SIW. Ils vont ainsi contribuer à plusieurs niveaux : gestion du contenu, création et mise à jour du contenu, organisation du contenu, vérification de la qualité du contenu, élaboration de la navigation. D’autres groupes et individus assument des tâches spécialisées dans un des aspects du contenu, soit la traduction et la révision du contenu ainsi que la vérification de la qualité du contenu.
|
• Les groupes et individus spécialisés dans les aspects technologiques (par exemple les groupes technologiques) sont ceux qui interviennent le plus sur le plan des technologies, particulièrement pour les technologies avancées et l’infrastructure technologique globale. Certaines tâches technologiques sont aussi prises en charge par d’autres intervenants impliqués dans la gestion des SIW ou au niveau de l’interface graphique, de la sécurité et de l’accessibilité des SIW.
|
• L’élaboration du design s’ajoute aux fonctions de certains intervenants spécialisés dans les communications ou les technologies ou relève d’un groupe dédié au graphisme.
|
• L’interaction avec les utilisateurs fait principalement référence à de la formation. Les tâches reliées sont assumées par les services d’information, les webmestres ainsi qu’une compagnie spécialisée dans la formation et utilisée par le gouvernement fédéral pour ses employés.
|
Pour les tâches générales et transversales, les intervenants se regroupent en fonction des tâches couvertes, les principales étant la gestion des SIW, la planification des SIW et la conformité aux politiques des SIW. La gestion des SIW revient aux différents groupes et individus en charge de SIW. La planification relève des entités qui ont un rôle de coordination globale comme les groupes de communications et le bureau du Gouvernement en direct. Les tâches associées à la conformité des SIW aux politiques, c’est-à-dire sa vérification ainsi que sa prise en compte lors du développement, sont réparties entre plusieurs intervenants qui ont un rôle dans la gestion des SIW, dans leur développement technologique ou qui sont dédiés à la vérification de la conformité des SIW aux politiques.
|
Tableau Caractérisation des tâches des autres intervenants impliqués avec des professionnels de l’information dans des SIW. Source : Dufour, 2003
FAMILLES
INTERVENANTS |
POLITIQUES | CONTENU | TECHNOLOGIES | INTERFACE GRAPHIQUE | UTILISATEURS | GÉNÉRAL/ TRANSVERSAL |
Service d’information
|
X | X |
X |
X |
||
Webmestre
|
X | X |
X |
X |
||
Division du ministère
|
X | X |
X |
|||
Gestionnaire de programmes de contenu
|
X | X |
X |
|||
Fournisseur de contenu (interne et externe)
|
X | X | ||||
Groupe de traduction
|
X | |||||
Traducteur (externe)
|
X | |||||
Gestionnaire
|
X |
X |
||||
Groupe en charge de l’approbation des contenus
|
X | X |
X |
|||
Groupe de communications
|
X | X |
X
|
X |
||
Bureau du Chef de l’information
|
X |
X |
||||
Bureau du Gouvernement en direct
|
X |
X |
||||
Groupe sur les politiques
|
X | |||||
Compagnie offrant de la formation sur des aspects Web
|
X
|
|||||
Groupe de gestion de l’information et des technologies
|
X |
X |
X |
|||
Groupe technologique
|
X
|
X |
X
|
X |
||
Technologue
|
X |
X
|
X |
|||
Compagnie en technologie (externe)
|
X |
X |
||||
Consultant en technologie (externe)
|
X | |||||
Groupe de sécurité
|
X | |||||
Groupe de graphisme
|
X |
X
|
||||
Service d’accessibilité SIW
|
X |
X |
Tableau Familles de tâches couvertes par les différents intervenants impliqués avec les professionnels de l’information dans des SIW. Source : Dufour, 2003
La thèse de Dufour portait exclusivement sur l’exemple du SIW dans le gouvernement pancanadien, l’intervention des professionnels est donc considérée à ce niveau. Toutefois, ces tableaux nous aident dans la compréhension du rôle du concepteur ou du développeur web dans la réalisation, la conception et le suivi des applications web. En effet, nous comprenons donc que le professionnel de l’information qui est ici concepteur du site ou de la page web intervient dans plusieurs dimensions du SIW et doit gérer des tâches diverses rivalisant de complexité.
Outre la gestion du site et de son contenu, le concepteur du site est également un acteur essentiel puisqu’il entre aussi en interaction avec les utilisateurs via la page web.
En nous basant sur ces analyses, nous pouvons donc dégager plusieurs catégories d’intervenants humains dans les SIW :
- Les concepteurs ou développeurs web :
Ces derniers se chargent de toute la partie technique dans l’élaboration des SIW et s’occupent donc de l’ingénierie de domaine ou de l’ingénierie d’application lorsque l’approche par la ligne de produit est adoptée dans le SIW.
- Les professionnels de l’information :
Ce sont des intervenants censés gérer le contenu des sites ou des SIW, le moduler, l’actualiser et l’inventer. Leur rôle ne diffère pas beaucoup de celui des concepteurs web, sauf pour le fait qu’ils ne s’occupent pas uniquement des techniques et technologies associées au SIW.
- L’utilisateur
L’utilisateur est un acteur externe qui détient quand même une influence considérable dans le SIW. En effet, le SIW est modelé suivant ses exigences et en accord avec ses besoins. C’est pour cette raison que de nombreux professionnels n’hésitent pas à mener des études ou des enquêtes afin de détecter ces besoins et de façonner les SIW en fonction d’eux.
Malak et al. identifient deux types d’acteurs concernés par les applications web
Les utilisateurs finaux qui sont surtout à la recherche d’information ou de produits à acheter. Ils ont un comportement qui est fortement affecté par leur culture, leur langage, leur niveau de connaissances antérieures dans le domaine et leur expérience sur le Web. Ils interagissent avec les sites Web via une couche de technologie qu’ils ignorent, qui n’est pas sous le contrôle du concepteur du site et qui comporte : les navigateurs, les protocoles, les plug-ins, les systèmes d’exploitations, les plate-formes, les dispositifs d’interaction (écrans, multimédia…) et les connexions réseaux ;
|
Les développeurs et les professionnels de la maintenance qui essayent d’offrir un site de qualité en maintenant le caractère opérationnel du système ou en l’améliorant. Ils font face à une technologie qui évolue très rapidement et à un système qui a un cycle de vie très rapide. La maintenance d’un site Web se fait avec un rythme plus important que les autres produits logiciels à cause de la pression du marché et de l’absence d’une barrière de distribution. En plus, la portée de la maintenance devient souvent tellement large qu’une refonte totale du site est parfois nécessaire.
|
- Les avantages des LdP dans la conception des SIW
Comme nous l’avons déjà vu auparavant, les lignes de produits prodiguent des avantages variés, surtout dans le domaine des SIW en effet, user des lignes de produits pour concevoir un système d’information web est une pratique de plus en plus répandue bien qu’elle ne fasse l’objet que de peu de publications ou d’études sérieuses.
Pour rappel, les LdP permettent sont une composition de logiciels ou de produits appelés modèles qui sont similaires sur certains points et opposés sur d’autres le principe de le LdP est la conception massive d’un même produit présentant des traits communs et des traits distinctifs durant une durée déterminée, suivant une qualité optimisée et un coût de production inférieur
Dans les SIW, on peut dire que les LdP pourvoient donc au développement d’outils de diffusion d’information qui peuvent être des sites internet ou des applications web. Ces SIW sont conçus en se basant sur les LdP, c’est-à-dire qu’ils contiendront plusieurs éléments de composition et de modélisation obtenus à partir de la réutilisation. Dans cette optique, chaque SIW membre d’une gamme de produits contiendra des éléments de ressemblance et des éléments de différenciation.
Le premier avantage que nous constatons est celui de la vitesse de production qui augmente en même temps que le nombre des produits. La LdP pourvoit alors à la conception d’une famille ou d’un ensemble de logiciels, de produits, d’applications web ou de systèmes d’information web. Cette multitude de produits créés permet une diffusion plus fluide et plus rapide des informations et donc une grande efficacité des SIW.
Cette efficacité repose cependant sur la mise en application et le suivi régulier et pointilleux des démarches et processus de conception des LdP. A cet effet, passer par l’ingénierie de domaine et par l’ingénierie d’application est non seulement évident mais aussi obligatoire. Plus les exigences et contraintes rencontrées lors de ces ingénieries sont maitrisées et dépassées, plus la qualité des LdP est assurée, plus l’efficacité des SIW est garantie.
Outre la production, on constate aussi des avantages du point de vue du temps. Ces bienfaits se traduisent par une minimalisation du délai de production et par le respect de ce dernier. De ce fait, les lignes de produits sont utiles pour les SIW tels que les sites internet. En effet, elles favorisent la conception de plusieurs pages à la fois, ce qui permet de suivre la tendance en matière de chiffres et d’objectifs à atteindre. Cela permet aussi de tenir face à la concurrence et d’actualiser en permanence le contenu des sites web.
A part la réduction du temps de production, on peut également assister à une réduction du coût de production. Une telle baisse du coût de production se traduit par la réutilisation qui empêche la conception à zéro des pages web. En d’autres termes, on peut créer plusieurs pages à partir d’un seul modèle qui détient l’architecture de base de tous les produits. Cette stratégie permet de ne plus se focaliser sur une seule page à la fois mais plutôt de créer plusieurs modèles en se basant sur les caractéristiques obligatoires qu’elles doivent contenir.
Pour faciliter l’accès aux pages, la création d’un lien hypertexte permettant de relier les pages entre elles est la solution la plus adoptée par les concepteurs de SIW. Chaque page contiendra :
- un mot,
- une URL,
- une expression
- une image,
- une vidéo,
Chaque page doit alors contenir ce lien hypertexte qui renverra automatiquement le visiteur du site vers d’autres pages appartenant à ce même site. Ces pages contiendront les éléments similaires évoqués ci-dessus et présenteront un contenu différent. Le coût de la production se voit diminué grâce à la possibilité de créer plusieurs pages en un trait sans avoir à recommencer le processus à zéro.
Nous avons vu dans ce chapitre que les lignes de produits peuvent contribuer à la conception et au développement des applications web ou des SIW. Un système d’information web est une application basée sur le web dont les vocations sont orientées vers la diffusion, le stockage, la sauvegarde, l’échange et la manipulation d’informations via le web.
Le développement en force du web actuellement a permis le développement des SIW, si bien qu’ils peuvent à présent cerner plusieurs domaines tels que la santé, les études, les recherches scientifiques, etc. Ainsi, la communication, les échanges d’information, les demandes de renseignements et le contrôle des flux d’information sont facilités par les SIW qui n’ont pas de frontières que ce soit en termes d’espace ni de temps.
En effet, les SIW permettent les échanges d’information sur le web et donc par Internet, un réseau numérique disponible partout dans le monde et utilisé par un public de tous âges. Les applications web sont surtout conçues pour communiquer des informations, pour es stocker et pour les gérer. De ce fait, elles doivent être de bonne qualité et prendre en considération des dimensions telles que les utilisateurs ou les développeurs.
Les développeurs web ont un rôle primordial dans la conception et développement des applications web et des SIW. Pour faciliter leurs tâches, ils ont adopté les approches par les lignes de produits qui consistent à maximiser la production des applications web. La conception des SIW se fait donc en suivant les règles de conception des LdP. Cela signifie qu’en prenant l’exemple d’un site web, on peut alors concevoir plusieurs pages web en même temps.
Cette technique pourvoit à la production massive des pages web membres d’une seule famille ou d’un seul site. Ces pages web possèdent des spécificités telles que les similarités qui sont des caractéristiques communes à chaque page comme la dimension ou la couleur de fond (cf. l’exemple sur le site de commerce en ligne Amazon.fr). Elles détiennent aussi des éléments de variabilité tels que le contenu, les titres, etc.
Le but des similarités est de permettre aux utilisateurs de reconnaitre une page web et le site qui la promeut rien qu’en la regardant. Les similarités permettent de distinguer toutes les pages d’une même famille d’applications web et de prouver qu’il s’agit bien de pages différentes. Dans ce contexte, l’élaboration d’une interface utilisateur et d’une interface pour le développeur est requise.
L’interface utilisateur est disponible et accessible aux utilisateurs comme aux développeurs. Les utilisateurs y effectuent leurs activités habituelles sur le site. Par contre, l’interface du développeur n’est disponible que pour lui ou pour les personnes ayant le droit d’y accéder. Il s’agit de la partie immergée de l’iceberg qui gère les informations à communiquer aux utilisateurs et qui réalisent le suivi du site web ou du SIW.
On peut alors dire que le développeur web joue un rôle primordial dans la conception et le développement des SIW du fait qu’il est en charge de tout ce qui concerne la gestion. En même temps, l’utilisateur est aussi un acteur primordial dans la mesure où le SIW lui est destiné et qu’il peut aussi formuler des requêtes ou des critiques afin de l’améliorer.
Ce chapitre dédié à l’état de l’art et à la contribution des LdP dans les SIW a permis de constater que les SIW peuvent être grandement avantagés par l’adoption de la technique des LdP dans leur conception. Pour illustrer cette affirmation, l’exemple du Koriandol, un outil de développement, de déploiement et de maintenance des familles d’applications web.
Ce genre d’outil permet de créer plusieurs applications web en même temps avec un coût de production minimal et une qualité maximale. La production massive et le coût de production qui diminue s’expliquent par la réutilisation, un processus permettant de créer plusieurs applications en usant de composants réutilisables. Cela pourvoit à ne plus créer une application à partir de zéro, ce qui permet de concevoir rapidement plusieurs SIW à moindre coût du fait que les matières et ressources requises sont aussi diminuées.
La qualité des SIW conçus à partir des LdP se traduit par me souci de trouver des variabilités afin de distinguer toutes les applications membres d’une seule ligne, gamme ou famille. Cela se fait en effectuant plusieurs études et en optimisant le développement de chaque application.
Une fois que nous avons vu cet état de l’art et cette contribution des LdP dans les SIW, nous allons maintenant illustrer nos hypothèses par une application dans le dernier chapitre de notre travail.
Chapitre 4. Application
Cette section présente l’application relative à l’usage du concept des lignes de produits au service du système d’information web.
Avec les progrès récents de la technologie mobile et de la technologie de réseau sans fil, les systèmes embarqués sont largement utilisés dans la société moderne d’aujourd’hui. Un système de soins à domicile est un système intégré en réseau dont les principales fonctions consistent à contrôler les processus de la maladie et à aider les patients à maintenir leur indépendance et leur niveau maximum de la fonction au sein de leurs propres foyers et communautés.
Concevoir un système qui permettrait de soutenir les patients et leurs fournisseurs de soins de santé dans le processus de traitement serait vraiment bénéfique. Néanmoins, peu de travail concernant les systèmes embarqués avec Internet pour le soutien des patients, ont été réalisés à ce jour.
SIDI MOHAMED O. MOULAYE ABDELLAHI, et MBAYE SENE de l’université Cheikh Anta Diop du Dakar et de l’université et MOHAMED T. KIMOUR de l’Université Badji Mokhtar-Annaba d’Algérie, ont pourtant mené des études dans ce sens et ont publié, dans trois articles, la conception d’un Système d’Information de Santé basé sur les SIW.
Dans ces articles, ils nous montrent comment concevoir un système de soins de santé pour appuyer la gestion de l’état des patients atteints de maladies chroniques. Ce système est construit autour des dispositifs embarqués en réseau sans fil, et intègre la technologie Internet pour une télésurveillance de la santé et de la notification des médecins du patient pour lesquels des mesures d’urgence sont nécessaires. Aussi, les patients eux-mêmes peuvent spécifier des alertes personnelles pour les questions liées à leur état.
En d’autres termes, le système dont nous allons parler dans ce chapitre est basé sur les technologies web et sur un réseau sans fil à la fois. La technologie web est requise pour la surveillance permanente des patients et permet aussi d’établir un contact avec eux. Le réseau sans fil relie le dispositif domestique au dispositif mère qui est chez le médecin.
Cette partie-ci du mémoire sera exclusivement consacrée aux travaux de ces chercheurs, aux études et expérimentation qu’ils ont menées afin de tirer des conclusions. Cette partie a surtout la prétention de dégager l’application liée aux lignes de produits utilisées au service des systèmes d’information.
- A Product Line Approach to Design and Embbeded Web system for Healthcare et Designing Embedded Websystems for Healthcare
Dans ces deux articles, ces scientifiques exposent en détail la conception de ce système d’information de santé.
Les récents progrès dans la technologie des communications (TIC) de l’information ont rendu possible l’intégration d’une importante puissance de traitement de la communicabilité dans presque tous les appareils que nous utilisons dans notre vie quotidienne. Ces dispositifs embarqués sont hétérogènes, distribués partout dans l’environnement, et capables de communiquer via des interfaces filaires ou sans fil.
Les systèmes embarqués d’aujourd’hui sont omniprésents, mobiles, et dans de nombreux cas, connectés en permanence. L’explosion du nombre de dispositifs intelligents embarqués connectés et leur intégration dans l’espace Internet présenteront aux fournisseurs des services et de nouvelles opportunités pour déployer des services Internet innovants dans un large éventail de segments de marché jusque-là inexploitées. (Patrick, Griswold, Raab, et. S., 2008)
On peut citer les appareils de communication mobiles tels que le portable ou la connexion par réseau via Internet. L’ère numérique que nous vivons permet la conception de plusieurs systèmes de communication qui se perfectionnent de jour en jour. Ces SI basés sur la nouvelle technologie proposent des services variés et agissent dans des domaines variés et contrastés tels que le domaine militaire, le domaine éducatif, le domaine de la santé, etc.
Les TIC sont utilisées dans la télésurveillance des patients en établissant un lien virtuel entre les patients et leurs aidants pour soutenir la prestation en temps opportun des données relatives à la santé. Les progrès de la technologie de l’Internet permettent d’assurer à distance et d’accéder en permanence à l’information du patient et permet de nouvelles orientations dans le développement de l’e-santé.
Ces progrès sont favorables à la conception d’un système qui permettrait de soutenir les patients et leurs fournisseurs de soins de santé dans le processus de surveillance et de traitement des patients. Cependant, peu de travaux sur les systèmes embarqués avec Internet pour le soutien des patients; ont été réalisés à ce jour. [Chenhui., Huilong , Xudong, 2008] [Lee, H., Lee, S., Ha,, Jang, , Chung, Kim,, Chang, et Yoo, 2008] [Spasov, et Petrova, 2008]
Ces articles nous montrent comment concevoir un système de santé à domicile (HHS) pour soutenir la gestion de l’état des patients atteints de maladies chroniques. Ce système comprend un réseau local à la résidence du patient qui se connecte sans fil à divers capteurs qui fournissent en continu des mesures importantes sur le corps du patient à un serveur de base de données du portail Web, situé au centre de surveillance, qui est accessible par les cliniciens comme les médecins, les infirmières , etc.
Le champ d’application de la HHS comprend non seulement le diagnostic et le traitement médical, mais aussi l’éducation des patients en auto-soins, la surveillance médicale prolongée et la supervision. Avec un HHS,
citoyen sera capable d’être seul responsable de sa propre santé et de gérer le processus de livraison de santé (Lee, H et al.) En même temps, les cliniciens auront à leur disposition des données plus précises de la surveillance continue des patients dans leur environnement naturel et pourront donner des prescriptions plus précises.
Grâce à l’utilisation de capteurs embarqués dans l’environnement domestique, le patient peut être surveillé continuellement qu’importe la pièce où il se trouve dans sa résidence. Les données physiologiques, tels que la pression sanguine et le rythme cardiaque, les activités effectuées par le patient, comme la marche, le sommeil et l’exercice, et les conditions environnementales, comme la température et l’humidité, peuvent être collectées constamment.
Cependant, il ya des questions liées aux besoins et aux préférences des patients, qui peuvent changer en fonction de l’évolution des problèmes de santé. Par exemple, l’hypertension peut évoluer vers l’insuffisance cardiaque, nécessitant un nouveau capteur physiologique approprié, et de nouvelles ressources logicielles.
En outre, ces systèmes dépendent de la qualité et de la disponibilité des ressources (par exemple, des capteurs, des appareils), car ils peuvent être ajoutés, supprimés, ou ne peuvent tout simplement pas échouer dans leur fonction. Un système de soins à domicile (HHS) devrait s’adapter aux changements en ce qui concerne les besoins des patients et aux variations de l’environnement résidentiel.
Dans le développement de leur HHS, Mohamed et al. ont adopté la stratégie de gamme de produits et un processus d’architecture orientée; inspiré des processus les plus performants tels que les développements web comme WebML (Ceri, Fraternali, Bongio, 2000) et UWE (Koch, Kraus, 2002) et des méthodes dédiées aux systèmes distribués embarqués (Gomaa, 2000).
Une gamme de produits (PL), également appelée famille de système, est un ensemble de systèmes logiciels de partage, un ensemble commun composé de fonctionnalités qui répondent aux besoins spécifiques d’un segment particulier du marché ou de la mission et qui sont élaborées à partir d’un ensemble commun de biens essentiels d’une manière prescrite
Une gamme de produits détient des points communs ou commonalités pour tous les membres de la famille et des variabilités pour chaque membre unique de la famille. Mohamed et al. ont conçu l’architecture du système d’une manière à prendre en charge les personnalisations avant le déploiement (variabilité statique) et les changements pendant le fonctionnement du système (variabilité dynamique). Ils présentent une approche globale dans laquelle les deux types de variabilités sont décrits en fonction des points de variation et d’une table de décision, les éléments de base d’une architecture de ligne de produits.
A noter qu’une gamme de produits est un ensemble de systèmes logiciels, qui part d’une architecture logicielle commune et un ensemble de composants réutilisables.
Pour mieux comprendre le concept des systèmes embarqués ou Embedded Systems, les auteurs proposent en premier lieu un éclaircissement du sujet.
Contrairement aux préjugés, les systèmes embarqués ne sont pas toujours des dispositifs autonomes. Beaucoup de systèmes embarqués sont composés de plusieurs petites parties informatisées dans un dispositif plus large qui sert un objectif plus général.
Ils sont conçus pour exécuter une tâche spécifique, plutôt que d’être un ordinateur à usage général pour les tâches multiples. Certains ont aussi des contraintes de performance en temps réel qui doivent être remplies, pour des raisons telles que la sécurité et la convivialité. Les systèmes embarqués contiennent des cœurs de traitement qui sont généralement des microcontrôleurs ou des processeurs de signaux numériques (DSP). Ils ont beaucoup évolué dans des domaines tels que
- la mobilité,
- la communication sans fil,
- l’intégration avec Internet,
- les performances accrues en calcul,
- la sécurité largement renforcée, etc.
Ils offrent de nouvelles applications dans des domaines variés. L’un des plus importants d’entre eux est le système de santé. Par exemple, en tant que système intégré, le téléphone mobile est de plus en plus utilisé comme un outil précieux pour le suivi des patients. En fait, la téléphonie mobile a connu de nombreuses avancées notamment dans les ressources utiles, tels que les ports série et les connexions Internet. Par conséquent, les téléphones peuvent interagir avec des dispositifs électromédicaux comme les biocapteurs des patients, et transmettre des signaux vitaux via des protocoles Internet, tels que TCP / IP et UDP.
Grâce à cette technologie, les patients peuvent être orientés et aidés à réaliser une grande variété de tâches médicales qui ont été réalisées par un personnel médical qualifié dans le passé. Ces tâches peuvent varier d’un patient diabétique qui contrôle sa / son niveau de glucose dans le sang 2 à 4 fois par jour et ajuste la dose d’insuline appropriée, à la détection des paramètres médicaux essentiels tels que la pression artérielle, la glycémie pour le diabète et les envoyer sur le téléphone portable au bureau du médecin local ou à un centre de surveillance à distance.
Un plan de soins guide le patient en ce qui concerne les mesures qui doivent être faites (par exemple, la pression artérielle), les médicaments qui doivent être pris, et d’autres recommandations personnalisées en fonction du traitement [Loques, Sztajnberg, 2010] [Carvalho et al. 2012] [Sztajnberg, Rodrigues, Bezerra, Loques, Copetti, Carvalho, 2009].
.
Cette application ou système embarqué est donc basée sur Internet est divisé en deux serveurs : un serveur domestique destiné à l’accompagnement des patients et un serveur du côté des soignants pour leur usage.
A typical architecture for a home health monitoring system
Une fois le concept des systèmes de santé embarqués éclairci, les auteurs se livrent alors à une présentation de la conception des systèmes de soins à domicile. Les systèmes de soins à domicile sont de plus en plus complexes et dynamiques. L’activité de conception fournit la description de l’architecture du système conforme au modèle de composant utilisé. Dans la conception de ces systèmes, les meilleures pratiques actuelles imposent l’utilisation de modèles architecturaux répartis de façon hiérarchique. Pour ce faire, Mohamed et al. emploient deux niveaux distincts de décomposition structurelle: le niveau du sous-système et le niveau des composants.
Au premier niveau, le système est conçu comme un ensemble de sous-systèmes parallèles, éventuellement à communiquer les uns avec les autres. Les sous-systèmes sont la conception des pièces du système ou des unités de mise en œuvre qui peuvent être développées indépendamment, avec des fonctionnalités complexes stockées dans un référentiel et réutilisées dans de multiples applications.
Le niveau de sous-système comprend la décomposition suivant une cohésion logique entre les fonctionnalités offertes. Le deuxième niveau concerne le modèle de composants utilisé pour la modélisation de petites parties d’une fonctionnalité de contrôle.
En utilisant deux niveaux de granularité pour la conception du système, le flot de conception est composé de quatre étapes:
- Une vue d’ensemble du système,
- Un modèle de contexte,
- Un modèle de sous-système et
- Un modèle de composant.
Les sous-systèmes et les modèles de composants sont fournis avec leurs points de vue statiques et comportementaux. Lors de la première étape, Mohamed et al. construisent un aperçu du système dans lequel ils explicitent en langage naturel les différentes fonctionnalités du système et de ses interactions avec les utilisateurs. Ensuite, ils modélisent le cadre du système dans lequel le système est considéré comme une boîte noire en interaction avec des entités extérieures à son environnement. À cette étape, les exigences de bout en bout sont représentées en particulier par les exigences de synchronisation.
En troisième lieu, le modèle de sous-système indique les sous-systèmes et leurs interactions. Quatrièmement, pour chaque sous-système, Mohamed et al. définissent ses composants (matériel ou logiciel). Pour promouvoir la réutilisation qui est à la base de la conception d’une ligne de produit, ils conçoivent le HHS en adoptant une stratégie de combinaison entre le composant orientation et le concept de la gamme de produits.
1.1. Vue d’ensemble du système
Le Home Healthcare System proposé (HHS) doit constamment surveiller l’état de santé des patients et les en informer pour qu’ils puissent effectuer des tâches nécessaires telles que les mesures de la pression artérielle et le niveau de glucose. Il devrait communiquer ces mesures à un centre de suivi médical à distance et éventuellement aviser le médecin en cas de situation critique. Il devrait aider les patients à la maison (en particulier les personnes âgées) quand ils ont à gérer des tâches médicales spécifiques.
Il doit garder une trace de leur régime de médicaments et de rendez-vous médicaux et doit vérifier les paramètres tels que le sucre dans le sang ou la tension artérielle. Le personnel médical (médecins, infirmières et médecins) a la possibilité de surveiller à distance les activités quotidiennes des patients et d’ajuster son plan de soins en fonction des progrès du traitement. Pour le patient, cela peut signifier un plus petit nombre de visites chez le médecin et des périodes plus courtes d’hospitalisation.
De plus, ce système permet une autonomisation de la prise en charge du patient puisqu’il n’a pas à attendre les secours ni le personnel médical pour prendre soin de lui à n’importe quelle heure de la journée. Il bénéficie alors d’une certaine autonomie, une indépendance vis-à-vis des médecins pour ce qui est de son traitement à domicile.
Dans cette optique, le HHS devrait être composé de deux parties principales, reliées par Internet: l’un à la maison du patient, pour le suivi de patients locaux (Local Patient Monitoring), et l’autre au centre de soins de santé, appelé Centre de Santé (Healthcare Center). A la LPM, en utilisant des dispositifs mobiles appropriées (capteurs), les mesures de patients tels que le niveau de glucose, le poids, la pression artérielle sont constamment enregistrés à la passerelle domestique.
Un PC, un PDA, ou même un téléphone intelligent peut être telle une passerelle qui télécharge automatiquement (via l’infrastructure Internet) les mesures du patient à un serveur (centre de santé) pour l’accès des fournisseurs de santé (cliniciens).
A cette fin, un réseau sans fil à domicile ou réseau local sans fil (WLAN) est nécessaire dans un système de soins à domicile. La communication est généralement basée sur l’une des normes sans fil IEEE 802.15 de la famille du réseau sans fil. Les messages d’avertissement pour le patient doivent être présentés dans un ou plusieurs dispositifs d’affichage tels que
- la télévision,
- le téléphone cellulaire,
- la tablette,
- le PC,
- l’affichage de la PHS,
La porte d’entrée est équipée d’un module radio qui reçoit les données de capteurs en réseau du patient, exécute les algorithmes de contrôle, déclenche les alarmes si les paramètres médicaux sont supérieurs aux limites et envoie les résultats vers le serveur de base de données (en HC). Il est relié à la HC par un Internet, un GSM ou une connexion commutée.
La passerelle exécute les algorithmes de contrôle et envoie le résultat au système de HC via la connexion Internet. Dans le cas où le patient est dans un mauvais état et qu’il a besoin d’une assistance médicale d’urgence, la passerelle peut envoyer à l’HC, et d’ici à un service d’ambulance, les coordonnées précises du patient.
Le système de HC comprend un centre de soins de santé pour surveiller à distance un grand nombre de patients, et les interfaces pour l’utilisation par les médecins, les soignants, et les proches des patients. Recueillies à la LPM et téléchargées sur le système HC, les mesures du patient concerné interprétées en temps réel. Dans le cas de l’identification d’un état du patient anormal, le système de HC peut activer le dispositif local d’un LPM (un téléviseur ou un téléphone intelligent, par exemple), augmenter la fréquence des contrôles, ou, en fonction de la gravité des affections, envoyer une alarme.
Le système de HC, qui devrait être un portail Internet de suivi des lectures, permet au patient de régler l’utilisation de l’insuline, en consultation avec son médecin, d’analyser son état de santé en fonction du temps et d’avoir des rappels pour les tests et les traitements, et des alertes en cas de conditions potentiellement dangereuses.
Pour accroître l’interopérabilité et l’interface commune aux services médicaux du front-end, le HCS pourrait être réalisé comme un portail Web Médical. Cela pourrait être implémenté en utilisant les meilleures pratiques éprouvées pour la conception d’applications Web. La fonction de ce système comprend :
- le contrôle de l’échange de données depuis la maison,
- de la gestion et du soutien de base de données avec les dossiers médicaux électroniques,
- l’interface à divers services médicaux et non médicaux,
- le raisonnement global sur les données du BSN et les informations pour le patient.
Pour résumer, le HHS est donc un Système d’Information de santé basé sur les technologies d’Internet. Il dispose de deux variétés : le LPM qui est un système à domicile et le réseau relié au LPM qui se trouve au centre médical. Le LPM permet de surveiller les patients à l’aide d’Internet et en se servant d’une passerelle représentée par un portable, un poste téléviseur, etc. La passerelle permettra la communication des informations médicales aux patients.
Le LPM est à la disposition du patient. Il se trouve dans son local et est censé lui faciliter les tâches médicales primaires. Il lui servira de guide du point de vue soins médicaux et mémorisera ses données, ses rendez-vous pour des consultations, etc. Le LPM diffuse aussi les informations sur l’état de santé des malades au système embarqué du côté des médecins ou dans le centre médical.
Le système dans le centre médical est à l’usage des soignants. Il englobe tous les renseignements leur permettant de suivre à distance le cas de plusieurs patients à la fois. Il s’agit ici du serveur principal qui alimente tous les autres LPM et qui stockera toutes les données dans son disque dur. Pour que le LPM ou que le système au Centre Médical soit efficace, un référentiel ou un plan de soin a été admis dans leur système afin de leur indiquer les instructions à prodiguer aux patients suivant telle ou telle pathologie.
- Contexte du modèle
Il est très important de comprendre la portée de l’ensemble du système. Mohamed et al. l’ont modélisé à l’aide d’un diagramme de contexte, qui est un diagramme de classes UML avec des stéréotypes. À cette étape, ils démontrent explicitement les interactions externes entre le système (matériel et logiciel), modélisé comme une boîte noire, et l’environnement. Ils identifient également les acteurs en interaction qui sont en dehors du système.
The context diagram of the HHS
Un diagramme de contexte du système présente de manière explicite la limite entre le système et l’environnement extérieur. Seuls les utilisateurs et les systèmes externes sont à l’extérieur du système, tandis que les composants matériels et logiciels sont internes au système. Ainsi, les dispositifs d’E / S font partie du matériel du système et apparaissent par conséquent à l’intérieur de l’ensemble du système.
Pour différencier les différents types d’entités externes, les stéréotypes sont utilisés. En utilisant le diagramme de classes UML, le contexte du système est représenté montrant le système en tant que classe globale avec le stéréotype «système», et l’environnement externe est représenté sous forme de classes externes auxquelles le système doit interfacer. Afin de faciliter la décomposition du système, le diagramme de contexte attirera non seulement les acteurs extérieurs et l’ensemble du système, mais aussi les parties en réseau du système.
Deux types d’acteurs externes sont alors visibles, d’après la figure ci-dessus. Il s’agit des patients et des soignants qui sont reliés entre eux par le HHS. Ces acteurs sont interdépendants mais sont totalement isolés du système interne du HHS. En d’autres termes, le HHS agit suivant les informations fournies par les acteurs mais ne peut être influencé par leurs actes ni par leurs décisions. Les acteurs externes n’interfèrent donc pas directement dans le dans le diagnostic ou dans les agissements des HHS qui sont contrôlés par des applications internes et non par des ordres extérieurs.
- Modèle du sous-système
Le point de vue du sous-système spécifie un modèle de composant utilisé pour la modélisation de composants indépendants distribués avec des fonctionnalités complexes. Il est basé sur deux concepts importants: la séparation des préoccupations et de la distribution. La séparation des préoccupations favorise la compréhension et le système de réutilisation; donc de réduire les coûts et les délais de développement.
Un diagramme de contexte est utilisé pour identifier les sous-systèmes, en regroupant les cas de cohésion du flux de l’extérieur et de l’intérieur. Dans notre HHS, et sur la base de la séparation des préoccupations principales, certains sous-systèmes peuvent être identifiés comme la surveillance du diabète, le plan de soins, la surveillance de la fréquence cardiaque, etc.
Le sous-système de surveillance du diabète invite la personne diabétique à mesurer son taux de glycémie régulièrement à la maison, et fournit des soins à distance pour les personnes ayant toutes les infos sur la mesure du patient. Le test de glycémie est essentiel pour le contrôle du diabète, et il est efficace pour réduire le risque de complications et améliorer la qualité de vie.
Le plan sous-système de soins est un élément clé de la HHS. L’objectif est de guider le patient sur la base de mesures locales qui devraient être faites au système de LPM (par exemple, la pression artérielle), les médicaments qui doivent être pris, et d’autres recommandations personnalisées en fonction du traitement.
Il peut informer le patient pour lui rappeler d’un événement (comme un rendez- vous avec le médecin à telle ou telle date pour une consultation) ou envoyer un message au médecin. Cette fonction est intéressante pour augmenter le traitement de l’adhésion du patient, l’avertissant des tâches quotidiennes comme prendre un médicament, ou se rappeler qu’il est temps de mesurer la pression artérielle.
L’objectif le plus fondamental lors de la division des logiciels en modules est de garantir l’échange des pièces. Le génie logiciel est inspiré d’autres disciplines d’ingénierie matures pour permettre la décomposition du logiciel en composants et l’utilisation des composants déjà développés pour construire des systèmes de logiciels. Par exemple, dans l’ingénierie mécanique, un ingénieur construit un produit par décomposition. Il décompose un problème en sous-problèmes jusqu’à ce que l’on arrive au problème de base pour lequel les éléments de base de la solution peuvent être choisis.
Pour être en mesure de construire des systèmes de logiciels à partir de composants réutilisables, on a besoin d’un modèle de composant. Un modèle de composant est principalement basé sur les concepts de composant, le port, l’interface et le connecteur. Pour chaque sous-système, Mohamed et al. identifient les composants avec trois types : les composants de données, les composants de contrôle et les composants de l’interface.
Un élément de données contient des informations persistantes d’enregistrement de l’état du patient ou de sa situation. Un composant d’interface est défini pour chaque dispositif d’entrée ou de sortie tel que le capteur, l’actionneur, le dispositif d’affichage, etc.
A product line architecture of the LPM subsystem.
En outre, pour permettre l’adaptabilité au moment de l’exécution, Mohamed et al. permettent la personnalisation grâce à l’utilisation de la stratégie de la gamme de produits, en termes du patient et de la résidence (la disposition de la résidence, la distribution et le type de capteurs et de dispositifs, etc.)
Cependant, des changements dans la situation de santé du patient pendant le fonctionnement du système peuvent entraîner des modifications de la configuration des ressources, tels que des capteurs médicaux ou la modification du plan de soins. Dans ce cas, une reconfiguration de l’architecture du produit lors de l’exécution est nécessaire. Dans le cas de la disponibilité des différents appareils à la maison (TV, PC, iPad, etc.), ils pourraient être choisis et liés à l’exécution. Cette sélection repose sur des règles de contexte qui devraient être définies au moment du déploiement.
Pour ce faire, Mohamed et al. représentent la variabilité au niveau architectural en l’associant à une table de décision en vue de formaliser les règles de contexte de la sélection au moment de l’exécution.
Ces règles de contexte doivent être définies au moment du déploiement dans le but de soutenir cette sélection. Un exemple de règle peut être sélectionné lors de l’exécution du dispositif qui est le plus proche du patient. Par conséquent, en termes de l’architecture de la gamme de produits, ces dispositifs peuvent être définis comme des variabilités dont les éléments d’architecture peuvent être liés au moment du déploiement ou à l’exécution.
Les variabilités dynamiques devraient être clairement et explicitement décrites au niveau architectural, en précisant les adaptations et les règles en vertu desquelles ces adaptations doivent avoir lieu à l’exécution. Cette stratégie réduit les risques inhérents au processus de cartographie. Dans l’approche HHS de Mohamed et al., les variabilités sont décrites comme des éléments et conditions de variation d’architecture, qui déterminent les mesures d’adaptation architecturales.
Ainsi, ils identifient les composants et leur connexion chez chaque sous-système en fonction du flot de conception, tout en soulignant les points communs et les variabilités. Pour les raisons de limitation de l’espace, Mohamed et al. décomposent le sous-système de la surveillance locale des patients (LPM). Ceux restant pourraient être développés de la même manière.
En effet, le sous-système de LPM sera décomposé en fonction de la séparation des principes, menant aux trois types de composants dans les systèmes embarqués mentionnés ci-dessus. En effet, l’on décompose comme sous-système dans un composant (informations permanentes concernant l’état du patient et d’états historiques) :
- un composant d’interface pour la manipulation des capteurs du corps du patient,
- un composant d’interface pour l’entrée et l’affichage de l’utilisateur, et
- une composante de surveillance locale pour la manipulation de la logique de l’application à la base de données du sous-système de LPM.
Pour être en mesure de tirer le produit au moment de l’exécution, Mohamed et al. définissent la composante de variabilité pour faire face à la description de la variabilité et de la table de décision du produit dérivé. La description de la variabilité définit les informations de contexte d’un composant optionnel (par exemple, un PDA), telles que son emplacement, représenté par une valeur numérique indiquant la pièce de la maison où il se trouve, et son type (TV, téléphone portable, etc.)
Dans la composante de variabilité, la table de décision indique par exemple que le système sélectionne le dispositif seulement si le patient, situé par un service de localisation de la composante de surveillance local est dans la même chambre que l’appareil.
Mohamed et al. Ont alors adopté une conception orientée vers les lignes de produit. Pour ce faire, ils ont défini une architecture commune lors du déploiement des systèmes et des variabilités. Ces variabilités peuvent être représentées par des options telles que le choix du composant optionnel ou de la passerelle, son emplacement dans la maison, ou son type.
Du point de vue de la création, le système en question est basé sur l’approche par les lignes de produit, c’est-à-dire que les applications sont conçues en grand nombre et que les variabilités et les points communs sont aussi présents. Dans cette optique, on peut définir l’architecture du HHS comme étant une commonalité. Dans cette architecture, on note la présence d’ne feuille de soin qui est une caractéristique obligatoire chez chaque HHS et qui représente donc aussi une similarité.
Cette similarité peut toutefois être modifiée en fonction de la variation, de l’amélioration ou de la dégradation d’un patient. Cela signifie que les données que le HHS détient actuellement ne sont relatives qu’à un usage actuel, lorsque l’état de santé du patient change, cela dépasse le système qui devra passer par une reconfiguration pour convenir au nouvel état du patient. La similarité est représentée par la table de décision proposée par Mohamed et al.
- Travaux connexes
Une variété d’approches existantes propose l’intégration de la variabilité dans les systèmes informatiques de manière à insérer l’ingénierie de la gamme de produits dans les systèmes embarqués. Le principal défi est de trouver une représentation efficace pour faciliter la capacité d’adaptation et de reconfiguration dynamique du produit au moment de l’exécution. A cet effet, la fonction de modélisation a été utilisée pour la modélisation de la variabilité.
Cependant, comme les caractéristiques n’ont pas de sémantique (Czarnecki, Antkiewicz, 2005), leur utilisation dans l’adaptation automatique n’est pas garant de comportement correct.
L’une des propositions importantes, l’approche SPLIT (Coriat, Jourdan, Boisbourdin, 2000) estime des points de variation pour avoir des attributs et utilise donc le classificateur UML, pour représenter un point de variation. Le modèle de point de variation permet à la variabilité d’être visible dans le modèle UML. Chaque point de variation est associé à un mécanisme permettant de définir la transformation nécessaire par le processus de dérivation.
Toutefois, l’utilisation de cette technique nécessite systématiquement le développement de scripts et de programmes spécifiques pour la gérer, car elle n’est pas intégrée dans l’UML, ni dans les outils de conception UML. Les attributs de point de variation fournissent des informations pour un développeur afin de choisir une variante (Capilla, Topaloglu, 2003)
D’autres auteurs [Cavalho, Murta, Loques] (2012) et Capilla et Topaloglu (2003) ont présenté un modèle d’architecture logicielle pour les systèmes de soins à domicile. Un tel modèle prend en charge les personnalisations avant le déploiement (variabilité statique) et les changements au cours du fonctionnement du système (de la variabilité dynamique). Les deux types de variabilités sont décrits au moyen de contrats.
Cependant, il est difficile de savoir si la spécification de comportement adaptatif est faite pour faire face aux changements liés à la disponibilité et à la qualité des ressources et des besoins des utilisateurs, tel que proposé dans l’approche de Mohamed et al. dans laquelle les informations d’adaptation sont isolées des éléments architecturaux à l’aide de la table de décision, y compris les propriétés et les politiques d’adaptation telles que les fonctions d’utilité. Cette caractéristique facilite l’évolution indépendante de l’architecture et les enjeux de l’adaptation des variabilités dynamiques.
- Conclusions et travaux futurs
Pour conclure, ces dossiers intitulés A Product Line Approach to Design an Embedded Web System for Healthcare et Designing Embedded Websystems for Healthcare présentent la conception d’une architecture de système de soins à domicile par les auteurs Sidi MohamedO., Moulaye Abdellahi, Mohamed T. Kimour et Mbaye Sene. Ce dispositif de santé basé sur l’architecture des lignes de produit permet au patient d’être seul responsable de sa propre santé à son domicile et de gérer le processus de prestation de soins à distance.
Il permet aussi aux médecins d’être informés à tout moment des données les plus précises grâce à une surveillance continue des patients dans leur environnement naturel et de fournir les prescriptions les plus précises. Cela permettra d’améliorer la qualité globale des soins de santé tout en réduisant les coûts.
Dans la conception architecturale du système, Mohamed et al. ont adopté les meilleures pratiques de conception, inspirées de la plus remarquable des systèmes embarqués et des processus de développement d’applications web, tout en traitant minutieusement le concept de la gamme de produits pour gérer les variabilités dans le modèle de l’architecture et de permettre une adaptation dynamique. Loin de se contenter des résultats actuels, Mohamed et al. prévoient d’utiliser le support de l’environnement pour la validation du système et la génération automatique de code pour une plate-forme cible.
- An architecture Framework to Design a Healthcare Information System
Cet article toujours présenté par Mohamed et al. présente un cadre d’architecture pour guider la conception des systèmes de santé embarqués. Après les meilleures pratiques et les lignes directrices issues des meilleures techniques de processus de développement web, ces auteurs tiennent compte des dernières avancées dans les technologies du Web et de la mobilité.
Comme dans d’autres systèmes d’information dans les organisations, les systèmes d’information de soins de santé bénéficient de plus en plus de progrès récents dans la technologie mobile et les réseaux sans fil. Cette constatation les a amenés à concevoir un système qui permettrait de soutenir les patients et leurs fournisseurs de soins de santé dans le processus de traitement.
Néanmoins, sur le terrain, le système d’information de soins de santé est encore à ses balbutiements, et une pauvreté des travaux intégrant les systèmes embarqués avec Internet pour le soutien des patients réalisés à ce jour se fait voir.
Systèmes d’information de santé (SIS) sont importants pour les individus et les gouvernements, et le coût croissant de l’économie a contribué à faire de ces systèmes un domaine important de recherche et de développement. En plus des appareils en réseau intégrés dans des équipements cliniques et de diagnostic, le SA offre un moyen de capturer, stocker, traiter et communiquer des informations en temps opportun aux décideurs pour une meilleure coordination des soins de santé au niveau individuel et de la population.
Les progrès de la technologie de l’Internet permettent d’assurer à distance l’accès à l’information au patient et permet de nouvelles orientations dans le développement constant du SA. Un SIS doit être conçu de manière à aider les patients et leurs fournisseurs de soins de santé dans le processus de surveillance et de traitement des patients.
Cet article présente un cadre d’architecture pour la conception de systèmes d’information de santé pour faciliter le suivi de l’état des patients atteints de maladies chroniques et le suivi à distance du patient pour établir un lien virtuel entre les patients et leurs aidants pour soutenir la prestation en temps opportun de données relatives à la santé. Il s’agit d’un travail d’extension des recherches et travaux présentés dans l’article précédent en identifiant les composants fonctionnels du côté du patient et de celui du clinicien.
Son contenu étant parfaitement identique à celui des articles étudiés précédemment, on peut donc épargner son étude et se focaliser entièrement sur l’approfondissement et l’interprétation des études menées par ces chercheurs.
- Interprétation
Les travaux menés par Mohamed et al. attestent de la possibilité d’utiliser le système des lignes de produit afin de développer un système d’information web. Dans leurs études, ces chercheurs ont mis au point un dispositif de santé capable de faire interagir les acteurs de la santé avec les patients à distance.
Dans cette optique, ils ont développé ce qu’on appelle un SIS ou Système d’Informations de <santé capable de gérer un flux minimal et un flux maximal d’informations échangées entre un ou plusieurs patients avec leur médecin. Ce dispositif a pour but ultime de faciliter le traitement des patients, surtout des personnes âgées. En faisant donc une étude approfondie d’un tel système, nous pouvons catégoriser les acteurs touchés par ce système en deux parties : les patients et les soignants.
Les patients sont eux aussi classés en plusieurs sous-catégories. On note les patients âgés, ceux qui sont les plus ciblés par la mise en place d’un tel dispositif. Les patients âgés sont les plus sujets aux risques en termes de traitement de maladie. Pour éviter de les interner à l’hospice ou de les garder en surveillance à l’hôpital pour une durée permanente, l’assistance octroyée par le SIS leur permet de veiller sur leur santé et d’appliquer les premiers gestes qui sauvent en cas de cas d’extrême urgence.
Les patients âgés de plus de 75 ans sont les plus avantagés par ce dispositif, en effet, la plupart d’entre eux sont dépendants sans pour autant vouloir passer leur journée dans un lit d’hôpital ou dans un hospice. Donc, ils sont plutôt favorables à l’idée de se fier à un appareil capable de les relier à leur médecin de façon indirecte mais permanente. En effet, le SIS présenterait plusieurs avantages de taille.
Le dispositif recueillerait des données relatives à l’état de santé des patients afin de faire réagir les professionnels de santé en charge de leur cas en leur communiquant les directives à suivre en cas de maladie (les médicaments à prendre, les gestes à accomplir, etc. Outre l’intervention médicale, les professionnels de santé peuvent aussi suivre et vérifier régulièrement la santé des patients, surtout celui des patients d’un certain âge dont la fragilité est reconnue.
Le SIS baptisé Home Healthcare System (HHS) effectuera même une série de déduction sur l’état de santé d’un ou de plusieurs patients afin de diagnostiquer leur maladie et envoie les résultats aux médecins en permanence. Les médecins peuvent alors guider leurs patients à distance, les rassurer et, en cas d’urgence, leur indiquer les premiers gestes à faire en attendant l’arrivée des secours.
Vu dans ce sens, le HHS n’est pas uniquement un dispositif de santé, mais surtout un système de transmission d’information à deux sens avec un dispositif au domicile du patient et un autre au lieu où se trouve le médecin ou les soignants qui l’accompagnent. Le but de cette transmission d’informations est de faciliter la gestion de l’état de santé des patients, mais aussi de tester ce genre de dispositif pour connaitre ses failles et ses limites, améliorer ses performances et le mettre sur le marché afin de le vulgariser et de le rendre accessible à tous.
Concernant les patients âgés concernés de près par l’utilisation d’un tel système de santé, ils sont surtout avantagés par la mise en place du HHS car ils ne sont plus obligés de se déplacer vers leurs médecins ni d’attendre leur intervention à domicile pour faire quelques examens et contrôles de routine tels que la prise de pouls, le suivi du rythme cardiaque, la surveillance du taux de glycémie pour les diabétiques, etc.
Les personnes âgées dépendantes ou celles qui sont handicapées sont également favorisées par la mise en place du HHS. En effet, elles ne seront plus contraintes de se déplacer contre leur gré pour faire quelques tests et pourront voir de leurs yeux l’évolution de leur état de santé à travers les diagnostics fournis par ce dernier.
Outre les personnes âgées, tous types de patients peuvent être traités à distance grâce au HHS. Cela permettrait aux médecins de réduire leur action et de ne pas se déplacer pour des questions de routine qui pourraient être résolues à distance. Cependant, le HHS est aussi doté d’une fonctionnalité d’alerte, un moyen de communication permettant aux soignants d’agir au plus vite en cas d’urgence.
Comme ce dispositif est à base d’approche par les lignes de produits, il est alors conçu dans le respect des règles de conception des LdP. Il fonctionne alors à l’aide de plusieurs logiciels intégrés qui détiennent des commonalités et des variabilités. Dans le cas du HHS proposé par Mohamed et al., les traits communs et les points de variation sont modelés dans l’architecture. Comme les auteurs l’ont signalé, l’usage d’UML et de stéréotypes.
Dans cette optique, les variabilités sont visibles au niveau de l’architecture. Elles sont caractérisées par la présence d’options supplémentaires dans le logiciel. Le fonctionnement du HHS sous –entend l’usage de matériels et de dispositifs spécifiques. Mohamed et al. notent la présence d’une feuille de soins dans le programme. Cette feuille de soins est obligatoire et représente un des composants essentiels de l’architecture.
En effet, elle regroupera toutes les informations médicales nécessaires au système afin de mémoriser l’état de santé de chaque patient et de lui recommander les médicaments relatifs à sa maladie. Cependant, il ne faut pas négliger la nécessité pour les concepteurs d’un tell système de doter ces systèmes des informations les plus précises et les plus actualisées concernant tout type de maladie afin qu’il puisse réagir en conséquence. En outre, lui doter d’un système permettant de détecter les symptômes d’une ou de plusieurs maladies est aussi à prévoir.
Plusieurs critères sont donc à considérer durant la création d’un système d’information de santé afin d’optimiser ses performances et son utilisation. Il ne faut pas non plus confondre son utilité et ses compétences avec celles du médecin ou des soignants. En effet, le SIS n’est pas conçu pour supplanter les soignants ou leur présence.
Le but du SIS est d’informer les soignants sur l’état de santé des patients, de leur communiquer les données et les chiffres les plus récents afin qu’ils puissent réagir. L’objectif premier du SIS est donc d’alléger les tâches des professionnels de la santé afin qu’ils puissent s’occuper d’autres malade sou qu’ils aient un semblant de répit dans leur profession.
Installer le SIS chez le patient et le relier à un réseau de SIS du côté du médecin permettrait donc de diminuer les efforts physiques des médecins qui n’interviendront qu’en cas d’extrême urgence et qui se verront aidés dans leur fonction. Cependant, une révision et un suivi régulier du SIS est bénéfique pour éviter toute transmission de données erronées ou détériorés.
- Les avantages du SIS ou du HHS
Le SIS au service de la santé présente plusieurs types d’avantages. En premier lieu, on peut dire que ce système d’information de santé est conçu avec une technique de conception de ligne de produits, il est alors conçu dans la meilleure qualité avec un coût de production des moindres et un temps de conception des plus raisonnables.
Cela sous-entend également que plusieurs modèles peuvent être produits en même temps grâce au principe de réutilisation sur lequel repose la conception des lignes de produit. Cela signifie qu’un bon nombre de patients atteints de maladie chronique peuvent être suivis quotidiennement avec ce système.
Les avantages du SIS sont partagés entre les patients et les soignants. En ce qui concerne les soignants, les avantages sont détectés au niveau de leur tâche qui se voit réduite tout en restant optimisée. En effet, le SIS peut :
- suivre quotidiennement le patient,
- Diagnostiquer son état,
- Recueillir des données en fonction du diagnostic
- Etablir une fiche médicale,
- Dresser une liste de possibilité de traitement,
- Etablir les prescriptions utiles au traitement,
- Renseigner les médecins sur l’évolution ou la régression de l’état de santé du patient,
- Prévenir les médecins en cas de situation d’urgence,
- Alerter les soignants en cas de rendez-vous préalablement défini,
Il est donc clair que les tâches de base et les rôles primaires des médecins sont tous effectués par ce dispositif qui tend à remplacer les professionnels de la santé de ce point de vue. Les médecins disposent alors de plus de temps pour s’occuper d’autres patients et ne sont plus obligés d’effectuer des visites au domicile des patients en permanence.
Les patients sont aussi avantagés par l’adoption du SIS dans le domaine sanitaire. En effet, ils peuvent aisément prendre soin d’eux-mêmes du point de vue contrôle de routine ou confier leur santé à leurs proches qui, grâce aux instructions prodiguées par le SIS, pourront facilement appliquer les soins qu’il faut à leurs proches.
En outre, ils ne sont pas non plus exposés à une obligation de devoir exiger la présence permanente d’une infirmière ou d’un ou de plusieurs soignants à leur côté. En effet, ils peuvent choisir de traiter leur pathologie individuellement en s’appuyant sur les prescriptions du SIS. Le SIS est alors un dispositif :
- d’accompagnement,
- d’aide,
- de diagnostic de l’état de santé,
- de conseil,
- de prescription de traitement ou de médicament,
- d’alerte en cas de cas de maladie grave,
Si les avantages fusent du côté des patients et des soignants, leur intervention est aussi requise puisque le SIS n’est pas capable de les supplanter. Ainsi, le SIS ne peut pas administrer un médicament par voie orale ni faire des piqûres, de même, il n’est pas non plus en mesure de prendre le pouls ni d’effectuer des gestes manuelles ou physiques.
Le SIS n’est donc pas un robot à tout faire du point de vue sanitaire, mais plutôt un mécanisme servant à partager, à diffuser, à stocker, à rassembler et à traiter les informations.
Outre le système d’information de santé, les lignes de produits peuvent aussi contribuer à la conception de systèmes d’information issus d’autres domaines tels que la vente en ligne ou la gestion d’information en entreprise. Dans cette optique, les LdP permettront de concevoir des logiciels ou des applications utiles afin de renforcer les échanges et la transmission d’informations au sein d’une société.
On peut alors trouver des sites Internet d’entreprise ou de simples sites basés sur le système de la ligne de produits. Pour ce faire, leur concepteur misent sur une architecture globale des pages afin qu’elles aient un ou plusieurs points communs dans leur présentation et des points de variabilités. Pour identifier ces derniers plusieurs méthodes sont adoptées. L’usage d’UWE, de FODA ou de WebML peut être cité comme méthode, toutefois, les différences peuvent aussi être visibles à l’œil nu.
UWE reste l’outil de développement des applications web le plus performant et le plus utilisé dans la conception des applications web. Il permet de concevoir systématiquement les SIW tout en assurant une personnalisation de ces derniers. Avec UWE, le développement du SIW est assuré, ce qui amène les développeurs à priser son utilisation.
Cependant, les lignes de produit rencontrent plusieurs difficultés, surtout celles liées aux variabilités. Dans le cas d’un site web, les variabilités ne sont pas trop difficiles à cernées du fait qu’elles peuvent être représentées par des éléments tout à fait inattendus comme le titre, le contenu, etc. Par contre, elles sont problématiques dès qu’il s’agit d’un produit ou d’un objet comme le téléphone portable par exemple. En effet, le fait d’appartenir à une seule famille suppose que plusieurs modèles de téléphones mobiles sont compris issus d’une seule gamme, ce qui signifie qu’ils doivent donc posséder des éléments communs et des éléments de variabilité qui seront identifiés à l’aide du FODA ou d’UWE.
Les systèmes d’information doivent cibler un public ou des spectateurs bien définis. Les personnes ciblées sont catégorisées en deux catégories, d’après Villanova-Oliver. Il s’agit des groupes et des utilisateurs. Dans sa thèse, cet auteur dévoile ces deux groupes, nous allons retranscrire cette présentation des cibles des SIW dans un tableau issu de ladite thèse.
MotivationsLes SIW sont destinés à un public varié composé d’individus ne présentant pas les mêmes besoins à l’égard du système, n’ayant pas les mêmes droits sur les données de celui-ci, faisant preuves d’expériences ou de connaissances variées, exprimant des préférences diverses, etc. L’identification de différents groupes d’utilisateurs est un moyen de réduire la complexité sous-jacente à une telle hétérogénéité. Néanmoins, bien qu’appartenant à un même groupe, les utilisateurs présentent des caractéristiques individuelles variant parfois dans une large mesure. En ce sens, que le système soit capable de s’adapter à différents groupes n’est pas suffisant. La prise en compte d’un utilisateur en tant qu’individu est également nécessaire. L’objectif est de proposer en priorité des adaptations basées sur des spécifications personnelles ; en l’absence de celles-ci, les spécifications des groupes sont alors utilisées. Enfin, un utilisateur donné peut également, d’une fois à l’autre, avoir des besoins différents, préférer une option à une autre, etc. A cet égard, on ne peut se satisfaire d’une représentation figée dans le temps de l’utilisateur pour mettre en œuvre l’adaptabilité. En matière de modélisation des utilisateurs, notre approche vise trois objectifs : i) considérer la représentation de différents groupes, ii) représenter les utilisateurs individuellement et iii) garantir la possibilité d’exprimer toute évolution de ces représentations. Ceci contribue, selon nous, à tendre vers de meilleures capacités d’adaptation du système.
|
Une distinction basée sur une approche fonctionnelle
Le concept de Groupe d’utilisateurs (ou groupe) permet de fédérer les informations relatives à plusieurs utilisateurs qui partagent certaines caractéristiques. Dans notre approche, le critère de regroupement des utilisateurs individuels est fondé sur le concept de Rôle Fonctionnel présenté dans la section 6.2. La Figure 6.9 propose un diagramme de classes pour illustrer cette modélisation. Une instance de la classe Groupe est associée à une instance de la classe Rôle Fonctionnel, cette dernière étant constituée de Fonctionnalités. Tous les membres de la classe Groupe (i.e. donnés par la classe Utilisateur) ont ainsi en commun le fait d’avoir accès à l’ensemble des Fonctionnalités qui constituent le Rôle Fonctionnel associé à ce groupe. L’identification d’un groupe dans le Modèle des Utilisateurs relève donc de celle des différents Rôles Fonctionnels (ceux-ci étant directement obtenus à partir des cas d’utilisation – cf. section 6.2.1). Un Utilisateur peut appartenir à un ou plusieurs groupe(s), et peut, en conséquence, remplir les différents Rôles Fonctionnels associés aux groupes dont il est membre. L’Espace Fonctionnel dont un Utilisateur est propriétaire est constitué de ces Rôles Fonctionnels. L’association est_constitué_de entre un Espace Fonctionnel et des Rôles Fonctionnels est ainsi déductible de l’association appartient entre les classes Utilisateur et Groupe.
|
Profils de groupes et d’utilisateursAprès avoir introduit les notions de Groupe et d’Utilisateur, nous décrivons les informations les concernant. Notons que nous ne mentionnons pas, par souci de clarté, un certain nombre d’informations qui ont vocation à identifier et qualifier les instances des classes Groupe et Utilisateur. Il s’agit classiquement d’attributs tels que nom et description pour les groupes, ou pour les utilisateurs, d’attributs pour l’authentification (login, mot de passe), l’identification (nom, prénom de l’utilisateur qui permettent une personnalisation très simple par affichage de ces données dans la page d’accueil et donne le sentiment à l’utilisateur d’être un interlocuteur privilégié [Kram00]), etc. Les autres types d’informations modélisées sont répartis en différentes catégories que nous appelons profils. La Figure 6.10 illustre la prise en compte de tels profils dans le Modèle des Utilisateurs. Notons que les profils considérés dans le cadre de ce travail sont ceux directement en rapport avec les deux modèles que nous avons présentés précédemment, i.e. le Modèle des Fonctionnalités et le Modèle de l’Hypermédia. La classe Groupe est liée par une composition à trois profils de groupe modélisés par la classe G_Profil. Celle-ci se spécialise en G_AccèsProgressif, G_Préférences et G_Comportement. De façon similaire, la classe Utilisateur est liée par une composition à, au plus, trois profils d’utilisateurs que modélise la classe U_Profil. Une spécialisation de cette classe, similaire à celle de la classe G_Profil est proposée : on distingue les classes U_AccèsProgressif, U_Préférences et U_Comportement. Les profils de groupe entretiennent des relations avec les profils correspondants décrits pour les utilisateurs. Ces relations sont représentées par les associations entre les sous-classes de G_Profil et U_Profil dans la Figure 6.10. |
Modèle des Utilisateurs : distinction entre Groupes et Utilisateurs basée sur les concepts du Modèle des Fonctionnalités
Modèle des Utilisateurs : distinction entre Groupes et Utilisateurs basée sur les concepts du Modèle des Fonctionnalités
Le fait de pouvoir classer le public cible des SIW en deux catégories permet de constater sa polyvalence. De même, le fait de rencontrer plusieurs types d’applications web dans plusieurs domaines signifie que les lignes de produit participent à leur développement et que leur approche est donc bénéfique pour les SIW.
Nous constatons alors que les applications web connaissent un tournant plus révolutionnaire et une évolution indiscutable. En même temps, Internet et le web ne cessent de s’améliorer, ce qui pourrait contraindre les concepteurs web à chercher de nouvelles approches adaptées à ces évolutions pour rester dans la course.
A la fin, mettre un modèle précis de ligne de produits
Le dernier chapitre de notre mémoire présente une illustration des lignes de produits dans la conception, le développement et la mise sur marché d’un système d’information web. Nous avons alors pris l’exemple du SIS ou Système d’Information de Santé proposé par Mohamed et al. Avec cette approche, ces auteurs ont mis en exergue la possibilité de créer un système d’information au service de la santé en se focalisant sur les familles de produits.
Les auteurs et concepteurs de ce SIS révolutionnaire ont alors mis en place ce système d’information qu’ils ont divisé en sous-systèmes et en composants. Ces sous-systèmes et composants renferment les commonalités et les variabilités pour chaque modèle de SIS. Dans cette approche, le principal avantage du Système d’Information de Santé conçu avec les ingénieries des LdP est la conception de plusieurs modèles de SIS à la fois.
En effet, étant basé sur la réutilisation, les LdP permettent la réalisation d’un nombre supérieur de modèles issus d’une même famille de produit tout en économisant en temps et en argent. De cette manière, les soignants et les médecins peuvent suivre plusieurs patients à la fois sans avoir à leur rendre visite à domicile et en optimisant leur prise en charge et leur soin.
Cela est possible grâce au SIS qui joue le rôle du médecin dans le traitement de l’état de santé de malades chroniques. Le SIS, pourvu d’une feuille de soins censée lui permettre de guider les patients dans leur traitement à domicile, peut alors effectuer des tâches exclusivement réservées aux professionnels de la santé telles que la prise du pouls, la mesure et le suivi de la tension, du taux de glycémie chez le diabétique, du rythme cardiaque, etc.
Une fonctionnalité alerte en cas de situation d’urgence nécessitant l’intervention in extremis d’un médecin est également combinée au SIS baptisé HHS ou Home Healthcare System. Le HHS dispose d’ailleurs de deux types : le LPM ou Local Patient Monitoring, le dispositif de santé à domicile du patient qui lui permet d’effectuer des soins primaires pour son état de santé ou de gérer son agenda de rendez- vous avec son médecin ; et le SIS du côté du centre médical ou chez me médecin grâce auquel il peut suivre de près et de façon qualitative l’état du patient en question.
Le HHS fonctionne à l’aide d’Internet qui permet une télésurveillance des patients. Les variabilités contenues dans le SIS sont illustrées par les passerelles qui sont des outils ou des connecteurs tels que l’ordinateur, le téléphone portable ou le poste de télévision qui servent à communiquer aux malades les prescriptions du médecin.
Ces matériels sont considérés comme des variables du fait qu’ils peuvent changer d’un foyer à un autre. Dans le diagramme de contexte du HHS, Mohamed et al. Définissent l’implication des acteurs et intervenants tels que le patient et le médecin dans le système externe du dispositif. Ces derniers n’influencent pas directement le HHS qui agit de façon automatique.
Cependant, le HHS n’est pas conçu pour supplanter les médecins, de ce fait, les patients nécessitant des aides d’urgence doivent donc quand même attendre l’arrivée du médecin et n’effectuer que des consultations ou des contrôles et des diagnostics de routine avec le HHS. Puisque l’état d’un ou de plusieurs patients est variable, le HHS doit donc être reconfiguré suivant ce changement d’état et sa feuille de soins doit être rééditée en conséquence.
CONCLUSION
Ce mémoire dont le thème est les « Lignes de Produits pour les Systèmes d’Information Web », entend proposer un modèle de lignes de produits pour les Systèmes d’informations. Les lignes de produits sot un concept permettant de créer plusieurs modèles d’un produit spécifique à la fois, des modèles identiques qui seront compris dans ce qu’on appelle une famille de produits.
Les caractéristiques principales d’une ligne de produit est de renfermer des points ou traits communs et des variabilités. Les similarités sont modelées durant la phase de l’ingénierie de domaine qui permet de créer les softwares reuse ou assets ou les composants réutilisables. Les assets sont la clé de la conception des LdP puisqu’ils sont la base de toute l’architecture des différents modèles de la LdP.
Durant l’étape de l’ingénierie de domaine, les éléments réutilisables seront conçus pour pouvoir apparaitre dans chaque produit formant une LdP afin d’attester leur appartenance à cette gamme de produits. Les variables, les exigences et les contraintes des LdP seront développées dans l’ingénierie d’application qui repose entièrement sur l’ingénierie de domaine.
Les LdP possèdent des atouts inqualifiables, surtout en termes d’économie. En effet, elles permettent de concevoir durant un temps record un grand nombre de produits avec une qualité supérieure et un coût de production réduit. Toutes ces qualités de la LdP sont développées et promues durant les ingénieries citées ci-dessus et permettent au concepteur de faire d’énormes économies et de ne plus être obligé de réaliser un produit à partir de zéro chaque fois qu’il en concevra un.
L’approche par les lignes de produits n’est pas un concept nouveau. De grandes entreprises telles que Nokia les utilisent et tirent les avantages que nous venons d’énumérer. Dans les années 2000, Nokia a même réussi à créer 25 à 30 téléphones mobiles en une année grâce aux LdP. Dans cette optique, chaque modèle de portable détient la même forme ou les mêmes traits. Mais les applications et les options chez chaque modèle diffèrent. Il s’agit ici des commonalités et des variabilités.
Pour détecter ces caractéristiques, le diagramme de FODA est la méthode la plus efficace et la plus utilisée. Elle permet de classer les composants d’un produit suivant des caractéristiques obligatoires, optionnelles ou alternatives, permettant de le disséquer et de comprendre quels éléments sont communs et lesquels sont différents chez chaque produit.
L’approche par les lignes de produits est tout de même soumise à des contraintes de taille qui restent toutefois difficiles à résoudre. Il s’agit de l’identification et de la création des variabilités pour chaque produit. Cependant, le LdP logiciels est moins confronté à ces contraintes que les LdP classiques. Le fait de savoir jouer avec ces contraintes, de savoir les intégrer et les adapter au LdP fait aussi partie de l’art de la conception des LdP.
Comprendre le fonctionnement de LdP pour pouvoir concevoir une LdP spécifique aux SIW. Les SIW ou Systèmes d’information Web sont des systèmes permettant la diffusion, le partage, l’échange, la collecte et la sauvegarde d’informations en usant des capacités du Web. Ils sont conçus et développés par des développeurs web aux compétences particulières et sont destinés à un large public de tous âges.
Les SIW ont évolué à grande échelle depuis que le Web a connu une évolution époustouflante. L’apparition de SIX au service de tous les domaines tel que celui de la santé est alors normal. Dans ce mémoire, nous avons voulu tenter de mettre en place une approche des lignes d produits pour les SIW, c’est-à-dire de dégager si les LdP contribuent réellement à la production et au développement des SIW et si elles peuvent les améliorer dans un quelconque sens.
Pour ce faire, nous avons pris l’exemple du SIS ou Système d’information de santé ou HHS (Home Healthcare System). Ce SI a été conçu en intégrant les LdP, ce qui lui permet des fonctionnalités plus qu’intéressantes et une fonction très appréciée que ce soit chez les patients ou chez les médecins.
Le HHS permet au patient de suivra un traitement à domicile pour des maladies chroniques, permanentes ou répétitives. Son rôle est d’aider les médecins dans leurs tâches tout en apportant une certaine autonomie aux malades pour qu’ils puissent s’occuper d’eux-mêmes à la maison, sans attendre le déplacement et l’intervention des médecins à chaque fois.
Ce système proposé et expérimenté par Mohamed et al. a été construit en respectant les règles de conception des LdP et présente donc des avantages de taille comme la production massive des SIS en usant d’un minimum de temps, d’argent et d’énergie.
Ce système permet la télésurveillance des malades grâce à Internet et à un serveur local et un réseau sans fil. Nous avons alors compris que les SIW d’aujourd’hui, surtout ceux liés étroitement au web, sont tous dépendants de la LdP dans la mesure où ils doivent être représentés sur des interfaces utilisateur et des interfaces pour les développeurs. Les tâches des concepteurs consistent à améliorer la présentation de cette interface et à relier entre elles les pages web entre elles.
L’utilisateur se sert des SIW pour prendre et échanger de informations, d’où la nécessité de mettre constamment à jour les pages et les sites web. Ce mémoire nous a alors permis de constater que les LdP sont bénéfiques pour les SIW puisqu’elles permettent de concevoir plusieurs applications web de bonne qualité tout en favorisant l’évolution des SIW.
Cependant, face à un environnement numérique en perpétuel mouvement et en perpétuelle évolution, les LdP assureront-elles à elles seules la promotion et l’évolution des SIW ou devront-elles être appuyées par d’autres technologies ou même être supplantées par d’autres techniques ?
BIBLIOGRAPHIE
Ouvrages
Villanova-Oliver M. (2002) : Adaptabilité dans les systèmes d’information sur le web : Modélisation et mise en œuvre de l’accès progressif. Thèse pour l’obtention du grade de docteur en informatique, Institut National Polytechnique de Grenoble
Carvalho S.T., Murta L., Loques O. (2012): Variabilities as First-Class Elements in Product Line Architectures of Homecare Systems, SEHC, June.
Gomaa H. (2000): Designing Concurrent, Distributed, and Real-Time Applications with UML, Addison Wesley, 2000.
Ceri P. Fraternali and Bongio A. (2000): Web Modeling Language (WebML): a Modeling Language for Designing Web sites, Computer Networks, 33(1–6), pp. 137–157.
Adnane G. (2006) : Test des applications web: modélisation et génération de séquences de test basées sur le contrôle.
Malak G., Belkhiter N., Badri M et Badri L (2001-2002) : Evaluation de la Qualité des Applications Web : Etat de l’Art
Dufour C. (2003) : Étude du rôle des professionnels de l’information dans les systèmes d’information Web du gouvernement fédéral canadien, Faculté des arts et des sciences, Université de Montréal
Ben Rhouma Aouina T. (2012) : Composition des modèles de Lignes de produits logiciels, Université Paris-Sud, Ecole doctorale d’informatique
Suarez D. (2011) : Modélisation de l’Aspect Dynamique de la Variabilité dans les Lignes de Produits, Rapport de Stage.
Kraiem N, Selmi S. S., Ben Ghezala H. H. B. (2010): A Situational Approach for Web Applications Design, RIADI Laboratory, National School of Computer Sciences, University Campus, Manouba, Tunisia
Balzerani L., Di Ruscio D., Pierantonio A., A Product Line Architecture for Web Applications Dipartimento di Informatica Universit _adegli Studi di L’Aquila, Italy
Al-hakim L (2007): Web and Mobile-Based Applications for Healthcare, Management, Hershey, PA: IRM Press.
Czarnecki K. and Antkiewicz M. (2005):Mapping Features to Models: A Template Approach Based on Superimposed Variants. 4th International Generative Programming Conference, Springer, LNCS, 3676, Tallinn, Estonia, October,pp.422–437.
Capilla R. and Topaloglu N.Y. (2003): Representing Variability Issues in Web Applications: A Pattern Approach. In Computer and Information Sciences, ISCIS 2003, LNCS, 2869, pp. 1035–1042.
Chenhui Z., Huilong D., Xudong L. (2008): An integration Approach of Healthcare Information System, Proc. IEEE Conf. on Biomedical Engineering and Informatics, pp.606-609.
Clements P., Northrop L. (2002): Software Product Lines: Practices and Patterns, SEI Series in Software Engineering, Addison-Wesley.
Coriat M., Jourdan J., Boisbourdin F. (2000): The SPLIT Method, SPLC1, Kluwer Academic, pp. 147-166.
Kimour M.T., Boudour R., and Ghanemi S. (2012): Closing the gap between the requirements specification and the design model for embedded systems, Second International Symposium on Modeling and Implementation of Complex Systems (MISC 2012), Constantine, Algeria, may 2012.
Kirovski D.; Oliver N.; Sinclair M.; Tan D. (2007): Health-OS: A Position Paper, In Proceedings of the 1st ACM SIGMOBILE International Workshop on Systems and Networking Support for Healthcare and Assisted Living Environments, San Juan, Puerto Rico, June 11, pp. 1–3.
Ko E.J.; Lee H.J.; Lee L.W. (2008): Ontology and CDSS based Intelligent Health Data Management in HealthCare Server, In Proceedings of World Academy of Science Engineering and Technology, Vienna, Austria, August 13–15, pp. 119–123.
Sitographie
http://www.requitim.com/?mod=Requirements_Management
http://www.requitim.com/?mod=Data_Model_Editor
Nombre de pages du document intégral:211
€24.90