Ingénierie Web

Michael Bieber
Département informatique
Ying Wu College of Computing
Institut de technologie du New Jersey
University Heights, Newark, NJ 07102 États-Unis
[email protected]
http://web.njit.edu/~bieber

ABSTRAIT
Nous adoptons une approche en deux étapes pour la conception d’applications pour le World Wide Web. En premier lieu, l’ingénieur logiciel effectue une analyse relation-navigation en analysant une application existante ou nouvelle spécifiquement en termes de relations intra et inter. Cela le conduit à mieux comprendre la complexité et la richesse de l’application et à mieux fournir le type d’accès et de métaconnaissance souhaité par les utilisateurs. Deuxièmement, un moteur hypermédia dynamique (DHymE) génère automatiquement des liens pour chacune de ces relations et éléments de métaconnaissance au moment de l’exécution, ainsi que des techniques de navigation sophistiquées que l’on ne trouve pas souvent sur le Web (visites guidées, aperçus, requêtes structurelles, etc.) sur haut de ces liens. Les liens et la navigation, ainsi que les fonctions d’annotation, complètent les fonctionnalités principales de l’application.
Motivation
À mesure que le Web et ses outils de programmation mûrissent, nous trouvons de plus en plus d’applications analytiques dotées d’interfaces Web et d’autres sites Web dont le contenu est généré au lieu d’être créé manuellement. Cela inclut la grande classe de systèmes hérités que les organisations se dépêchent de convertir en interfaces Web [Be95]. Ce document concerne la conception d’applications pour tous ces systèmes. Il aborde également le risque que les développeurs dotent ces systèmes d’une pénurie de liens au lieu de les embellir avec la riche couche de liaisons et de possibilités de navigation que le Web pourrait prendre en charge [BV97].

En outre, les développeurs de ces applications analytiques ont souvent du mal à présenter des informations complexes de la manière la plus compréhensible pour les utilisateurs. Les développeurs s’appuient souvent sur des techniques de visualisation perspicaces et sur une bonne conception de l’interface utilisateur. Ces approches ne sont pas anodines et, pour certaines applications, ne peuvent pas transmettre des informations simplement suffisantes à tous les utilisateurs, en particulier les étudiants, les novices et ceux qui connaissent mal les détails de bas niveau du domaine de l’application (comme un gestionnaire non technique qui doit prendre des décisions en fonction un travail de développeur). Même pour les applications avec des affichages d’informations simples, les utilisateurs peuvent toujours avoir des questions sur la signification d’un élément particulier ou sur la manière dont il a été déterminé. Logiquement, chaque élément d’une application Web peut être considéré comme un point de départ potentiel pour l’exploration d’informations. La possibilité d’explorer plus en détail un élément d’information pourrait aider les utilisateurs à résoudre leurs doutes ou simplement à mieux comprendre cet élément, ainsi que l’analyse ou l’affichage dont il fait partie. Les utilisateurs peuvent souhaiter approfondir les valeurs de données et les symboles qu’ils voient, les étiquettes sur les graphiques ou les formulaires de saisie, les options dans les listes contextuelles, les informations saisies par les utilisateurs en entrée (avant de les soumettre), ou même les commandes de menu et autres commandes. ils peuvent invoquer.

Pour compliquer le travail du développeur, les utilisateurs ont souvent des modèles mentaux d’application (et de son domaine sous-jacent) différents de ceux du développeur (analyste des applications ou ingénieur en logiciel). Même lorsque les développeurs travaillent en étroite collaboration avec les utilisateurs, le résultat final peut ne pas être aussi intuitif pour tous les utilisateurs, ni servir les tâches individuelles de chaque utilisateur. Un utilisateur peut souhaiter accéder à un affichage, une fonction ou une information particulière qui, à son avis, est immédiatement pertinente pour la tâche à exécuter, mais que le système ne rend pas accessible depuis l’écran actuel ou les environs immédiats.

L’un des principaux objectifs de l’hypermédia est de fournir des liens qui représentent des relations d’application qui permettent à l’utilisateur d’accéder à ses souhaits. Nous adoptons une approche en deux étapes pour la conception d’applications pour le World Wide Web. Tout d’abord, le développeur effectue une analyse relation-navigation en analysant une application existante ou nouvelle spécifiquement en termes de relations intra et inter. Cela le conduit à mieux comprendre la complexité et la richesse de l’application et à mieux fournir le type d’accès et de métaconnaissance souhaité par les utilisateurs. Deuxièmement, un moteur hypermédia dynamique (DHymE) génère automatiquement des liens pour chacune de ces relations et éléments de métaconnaissance au moment de l’exécution, ainsi que des techniques de navigation sophistiquées que l’on ne trouve pas souvent sur le Web (visites guidées, aperçus, requêtes structurelles, etc.) sur haut de ces liens. Les liens et la navigation, ainsi que les fonctions d’annotation, complètent la fonctionnalité principale de l’application [BK95, Bi98].

Analyse relation-navigation
La technique d’analyse relation-navigation (ARN) comprend 5 étapes:

(1) analyse des parties prenantes
(2) analyse d’éléments
(3) analyse des relations et des métaconnaissances
(4) analyse de navigation
(5) analyse de la relation et de la mise en œuvre des connaissances

L’ARN a deux objectifs principaux. À elle seule, une analyse des relations aidera le développeur à mieux comprendre l’application. Cela se produit principalement aux étapes 1 à 4. Le développeur doit ensuite décider laquelle de ces relations doit réellement être mise en œuvre. Certains peuvent ne fournir qu’un avantage marginal. D’autres peuvent être très coûteux ou difficiles à mettre en œuvre. Ces décisions ont lieu à la dernière étape.

Bien que très utiles dans leur forme actuelle, nous avons l’intention de développer davantage la technique de l’ARN en produisant des directives spécifiques pour chaque étape et en réduisant la gamme d’options que le développeur doit prendre en compte aux étapes 2 et 3 de l’analyse. Ces améliorations devraient rendre l’analyse plus systématique et plus facile à réaliser, tout en lui permettant de rester nécessairement ouverte.
Étape 1: Analyse des parties prenantes
L’analyse des parties prenantes a pour but d’identifier l’audience de l’application. Le fait de savoir qui sera intéressé par une application aide le développeur à déterminer de manière globale l’ensemble des éléments et relations importants, puis à se concentrer spécifiquement sur ceux-ci. En particulier, les applications avec accès Web public ont un éventail d’acteurs beaucoup plus large que ce que beaucoup imaginent. En fait, de nombreux développeurs trouvent que cette partie de l’ARN est la plus éclairante. Le développeur doit également identifier et comprendre les tâches que chaque type d’utilisateur voudra effectuer dans l’application. Cela aidera le développeur à se concentrer sur des domaines spécifiques au cours des étapes suivantes de l’ARN.

Étape 2: Analyse des éléments
Ici, le développeur énumère tous les éléments d’intérêt potentiels de l’application. À un niveau, ils incluent tous les types d’éléments affichés dans n’importe quel affichage en ligne (écrans d’information, formulaires, documents et tout autre type d’affichage), ainsi que les écrans, formulaires et documents eux-mêmes. Le moyen le plus simple de commencer consiste à examiner chaque écran (ou maquette) et à identifier chaque valeur et étiquette qu’il contient. Notez que le développeur doit identifier les types ou classes d’éléments, et non des instances individuelles. Les types de relation dont nous discutons à l’étape 3 sont tous destinés à des types d’éléments spécifiques. Dans le domaine de l’analyse décisionnelle, par exemple, ils incluent « modèle » et « valeur de données » par opposition à des modèles ou valeurs de données spécifiques.
Étape 3: Analyse de la relation
L’analyse relationnelle concerne les interrelations, les intra-relations et les métaconnaissances. Le développeur doit considérer chaque élément d’intérêt identifié à l’étape précédente en termes de chacun des types de relations généraux suivants, pour chaque groupe de parties prenantes. Certaines relations ne seront utiles qu’à certaines parties prenantes et le moteur hypermédia les filtrera. Les relations peuvent mener à des informations à l’intérieur et à l’extérieur de l’application. Les développeurs ne doivent pas se sentir limités par des considérations concrètes de disponibilité, de coût de mise en œuvre et d’effort. Dans cette étape, ils doivent exercer leur créativité aussi pleinement que possible. Ce n’est qu’à l’étape 5 qu’ils devraient réfléchir à la manière de mettre en œuvre les relations et méta-connaissances trouvées.

L’ARN aide actuellement les développeurs à identifier les types de relations et métaconnaissances suivants au sein d’une application: relations de schéma, de processus, d’opération, structurelles, descriptives, paramétriques, statistiques, collaboratives et d’ordre. [Bi98] donne plus de détails pour chacun. Bieber et Vitali [BV97] montrent comment plusieurs de ces types de relations générales peuvent compléter une facture en ligne. [Bi98] montre comment ils peuvent compléter un système d’aide à la décision basé sur une modélisation mathématique.
Étape 4: Analyse de la navigation
Une fois que nous avons identifié les relations, nous pouvons penser à la manière dont l’utilisateur pourrait y accéder. La mise en œuvre la plus simple ferait de chaque relation un lien, puis fournirait une traversée simple (les utilisateurs sélectionnant une ancre et un lien et le système affichant la destination du lien). Mais certains types de relations se prêtent à une navigation plus sophistiquée. Le concept d’hypermédia comprend de nombreuses autres fonctionnalités de navigation basées sur des relations ou des liens. Celles-ci incluent des visites guidées et des sentiers, des aperçus généraux et des requêtes structurelles [BVA97, Ni95]. Au cours de cette étape de l’ARN, le développeur doit choisir les fonctions de navigation qui répondent le mieux aux besoins des parties prenantes.

Étape 5: Analyse de la mise en relation et de la navigation
Clairement, l’étape 3 peut générer beaucoup de relations et l’étape 4 peut générer beaucoup d’opportunités de navigation possibles. À cette étape, le développeur doit décider lequel mettre en œuvre. Cette étape n’est pas la mise en œuvre réelle, mais simplement la décision logique de mettre en place les relations. Les concepteurs doivent prendre en compte les coûts et les avantages (réels et marginaux) de leur mise en œuvre et de leur affichage. Nous séparons cette étape des étapes 3 et 4 afin que le concepteur puisse y exercer tous ses talents créatifs sans contrainte de la part du monde réel. Le concepteur écrit ensuite une règle de mappage (en utilisant notre format spécifié) pour chacune des relations à implémenter. Les règles de mappage spécifient les commandes ou les algorithmes permettant de trouver le point de terminaison de chaque relation.

DHymE (moteur hypermédia dynamique)
Le moteur hypermédia DHymE s’exécute séparément de l’application cible. Nous écrivons un programme d’emballage pour chaque application afin de l’intégrer à notre architecture de moteur. Les applications ou leurs wrappers se connectent ensuite à DHymE via un serveur proxy Web. DHymE intercepte tous les messages échangés entre l’application et l’interface utilisateur et utilise les règles de mappage spécifiées ci-dessus pour mapper chaque élément approprié du message sur un nœud ou une ancre hypermédia. Notre enveloppe de navigateur Web intègre ces ancres dans le document en cours d’affichage et les transmet au navigateur Web de l’utilisateur via le serveur proxy. Lorsque l’utilisateur sélectionne une ancre, l’encapsuleur de navigateur la transmet à DHymE, qui renvoie une liste de liens possibles (un pour chaque relation appropriée, telle que déterminée par les règles de mappage). Si l’utilisateur sélectionne une commande d’application normale (mappée sur un lien d’opération), DHymE la transmet à l’application pour traitement. Si l’utilisateur sélectionne un lien de moteur hypermédia (par exemple, pour créer une annotation), DHymE le traite entièrement. Si l’utilisateur sélectionne un schéma, un processus, une opération, une structure, une description, des informations ou des relations supplémentaires entre occurrences, DHymE en déduit les commandes d’application appropriées, les opérations de méta-application (par exemple, au niveau des systèmes d’exploitation ou du schéma) ou des opérations de moteur hypermédia. produire l’information désirée. Si l’utilisateur sélectionne une annotation créée par l’utilisateur, DHymE la récupère. Ainsi, DHymE fournit automatiquement tous les liens hypermédia (ainsi que la navigation) aux applications, qui ne connaissent pas l’hypermédia et sont en fait souvent totalement inchangées. Nous intégrons actuellement plusieurs applications à DHymE, en donnant automatiquement à chacune une interface Web ou en complétant son interface Web existante: un système de suivi des demandes de personnel, un système de gestion de base de données relationnelle, un système de gestion des modèles mathématiques, un système d’analyse du tableur de transport et un système multicritère outil d’analyse d’aide à la décision. [Bi98] décrit ces idées et un prototype plus ancien, non Web, de DHymE de manière plus détaillée. [Bi97, CB97] fournissent également des informations de base sur le moteur.

Conclusion
Nous espérons que notre contribution la plus durable consiste à convaincre les développeurs d’applications Web (nouvelles et transférées d’autres environnements informatiques) de tirer pleinement parti de la liaison dans leurs applications. Les concepteurs nous ont répété maintes fois que l’ARN leur avait montré des liens qu’ils n’avaient jamais imaginés dans leurs propres applications. Leur identification est le premier pas nécessaire vers la mise en œuvre. Mis en œuvre de manière réfléchie, les fonctions de liaison et de navigation du Web peuvent grandement réduire la complexité des applications pour les utilisateurs. L’ARN fournit aux développeurs un outil d’identification des opportunités de liens supplémentaires au sein des applications. Le moteur hypermédia DHymE génère automatiquement ces liens, avec peu ou pas de modification de l’application.

Remerciements
Nous remercions avec gratitude le financement de cette recherche par le programme de bourses de recherche NASA JOVE, le Centre de recherche multimédia du New Jersey, le Centre national des transports et de la productivité industrielle du New Jersey Institute of Technology (NJIT), par le New Jersey Department of Technology. Transportation, par la Commission de la science et de la technologie du New Jersey, ainsi que des subventions de la Fondation Sloane et de la Fondation AT & T, ainsi que du programme NJIT SBR.

Références
[Be95] BENNETT, K. Systèmes hérités: réussir le succès. Logiciel IEEE, janvier 1995, 19-23.

[Bi97] BIEBER, M., Moteur hypertexte: Prise en charge d’applications informatiques, Note technique, 1997.

[Bi98] BIEBER, M., Compléter des applications avec Hypermedia, sous présentation, 1998.

[BK95] BIEBER, M. ET KACMAR, C. Conception du support hypertexte pour les applications informatiques. Communications de l’ACM 38 (8), 1995, 99-107.

[BV97] BIEBER, M. et VITALI, F. (1997). Vers le support de l’hypermédia sur le World Wide Web. IEEE Computer 30 (1), 1997, 62-70.

[BVA97] BIEBER, M., VITALI, F., H. ASHMAN, H. BALASUBRAMANIAN V. et OINAS-KUKKONEN, H. Hypermédia de quatrième génération: des liens manquants pour le World Wide Web. Revue internationale d’études en informatique humaine 47, 1997, 31-65.

[CB97] CHIU, C. ET BIEBER, M., Un wrapper générique de mappage dynamique pour la prise en charge de systèmes hypertexte ouverts d’applications analytiques, Hypertext’97 Proceedings, ACM Press, New York, NY, avril 1997, 218-219.

[Ni95] NIELSEN, J. Multimédia et hypertexte: Internet et au-delà. AP Professional, 1995.

Page source: https://web.njit.edu/~bieber/web-engineering.html


Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *