Nouvelle implantation

 

En prenant en compte d'une part les remarques après la première mise en place et d'autre part l'évolution des méthodes et pratiques de l'ingénierie informatique^5.10, nous avons précisé davantage les objectifs et modifié quelques choix effectués pendant le premier cycle du développement :

• Le modèle statique doit être conçu indépendamment de la partie qui s'occupe de l'interaction avec l'utilisateur lors d'une application concrète. Il doit concerner la mise en place et la cohérence des données sans se préoccuper (et même sans connaître) les scénarios d'interaction avec l'utilisateur.

  Pendant la première phase de développement, nous avons élaboré en parallèle le modèle de données et l'application et même si nous avons insisté sur leur séparation nous avons remarqué qu'à la fin le modèle était un peu trop bien adapté à l'application et que l'application connaissait un peu trop la structure interne du modèle.

  Pour faciliter l'abstraction des données et permettre une applicabilité efficace nous proposons de bien structurer le modèle en pensant le moins possible aux particularités d'une éventuelle application.

• Vu les progrès dans le domaine de la communication en réseau (nouvelles plate-formes de développement qui permettent la construction des applications qui peuvent être exécutées à distance et sur différents types de machines, à travers le réseau internet) nous avons choisi de développer davantage le positionnement d'une anagnose selon le lecteur et permettre un accès à distance. Nous pouvons ainsi parler d'un système multi-utilisateur qui peut rapidement augmenter sa base d'informations sémiques à travers une utilisation par différentes personnes situées à différents endroits physiques, chacune travaillant sur le même modèle statique.

• Le cadre orienté-objet de notre approche, les doutes que nous avons exprimées sur l'utilisation du langage C++ ainsi que les considérations d'une accessibilité à distance au modèle statique et peut-être aussi à l'application interactive, à travers le réseau, nous ont conduit à considérer Java comme un langage prometteur.

  La version 1.1 de Java [23], nettement améliorée sur quelques points importants, notamment le traitement des événements (event handling) qui introduit la possibilité d'utiliser des patrons de type écouteur/adaptateur, ainsi que la possibilité de linéariser^5.11 les objets (cf. le point suivant et la section 5.5.2) a finalement été sélectionnée comme plate-forme de développement informatique unique. Nous évitons ainsi les passages complexes entre C++, Hush et Tcl/Tk que nous devions effectuer pendant le développement de la version précédente.

• Contrairement à C++, Java 1.1 offre les moyens pour une sauvegarde et un chargement d'un graphe d'objets. Le processus de linéarisation permet l'écriture dans un fichier d'un objet ou d'un graphe d'objets dépendant l'un de l'autre. En lisant ensuite ce fichier et à travers un processus inverse, tout le graphe est reconstitué et l'application peut pratiquement recommencer à son état avant l'écriture.

  L'objectif d'une persistance rapidement implantable et sans une mise en place manuelle est ainsi atteint. Les détails de ce mécanisme et quelques points délicats sont examinés un peu plus loin (cf. p.).

• Concernant la convivialité (cf. le commentaire dans 5.1) de l'application interactive, nous insistons ici seulement sur un point générique issu des remarques sur l'ergonomie du premier prototype (cf. p.). Nous proposons la mise en place de fenêtres qui ont une relative autonomie : une fenêtre représentant, par exemple, un texte doit facilement donner accès à son contexte de positionnement, notamment l'anagnose englobante et peut-être à quelques informations concernant le positionnement de l'anagnose, e.g. le lecteur/utilisateur qui l'a créée, la date de création, etc. Il n'est donc pas nécessaire d'avoir en même temps plus d'une fenêtre correspondant à des entités appartenant à une même branche dans l'arbre de positionnement textuel (cf. la fig.4.3).

  Il faut remarquer que les points relatifs à la facilité de l'utilisation (ergonomie) sont la responsabilité de l'application particulière et dépendent de ses propres objectifs et surtout des besoins qui sont soulevés par le contexte spécifique de l'interaction avec l'utilisateur. En tout cas, il ne faut pas les aborder de manière générique. Nous en donnons quelques indices à travers l'interface prototypique et générique présenté dans l'annexe A.

La mise en uvre de ces choix apparaît dans la conception du modèle de ce deuxième prototype applicatif.