?" title="Home"/> ?" title="Index"/> ?" title="Site map"/> ?" title="Site map"/> ?" title="Site map"/> ?" title="Help"/> ?#copy" title="Copyright"/> Développement des applications href="../styles/.css" type="text/css" media="screen, projection,print"/> href="../styles/medium.css" type="text/css" media="screen, projection,print"/>

Développement des applications

 

A partir des données...

L'analyse a permis de définir la structure des données, leur mode de stockage et les accès requis. Elle a aussi permis de déterminer de manière très précise la terminologie de l'application: celle-ci est essentielle pour le choix des noms des objets, de leurs attributs et de leurs méthodes de traitement.

Stockage et repérage

La première étape est alors de créer les bases de données nécessaires (DDL: Data Definition Language: SQL, XSD ou Seconde) et d'établir les conversions et passerelles pour l'intégration des données existantes dans ces bases de données. Ces conversions peuvent être:

  • une simple copie d'informations existantes dans un autre système: ce type de transfert ne peut être utilisé que pour des données permanentes rarement sinon jamais modifiées.
  • un flux de mises-à-jour périodiques d'informations existantes dans un autre système: une procédure doit alors être prévue pour garantir la cohérence entre les deux.
  • un accès en temps réel du nouveau système à des données d'un autre système: il faut être attentif à la pérennité de ce lien et à la charge qu'il peut induire sur l'ancien système.
  • une transformation des données de l'ancien vers le nouveau: dans ce cas, on doit souvent découvrir "sur le tas" des combinaisons de données qui doivent être converties différemment du cas général. C'est ici que ?">Adapt montre tout son intérèt

On confronte ainsi la conception de l'application avec la réalité des données existantes: les erreurs d'interprétation sont immédiatement visibles et on peut aussi tester la rapidité des différents modes d'accès prévus.

Les outils de développement donnent souvent automatiquement une interface utilisateur de base qui permettent de visualiser et de corriger les données au besoin. L'utilisation de clients et de serveurs SRU/SRW (Zing, évolution de Z39.50) permet de créer facilement des applications intégrant les fonctionnalités requises dans la plupart des applications documentaires: langage de requète simplifié, historique des recherches, combinaison de résultats, application de traitements sur les ensembles obtenus.

Cette étape garantit que l'on a des données récupérées et bien structurées pour implanter les traitements.

A partir des cas d'utilisation...

Cette étape est très itérative: à partir des cas d'utilisation identifiés et décrits lors de l'analyse, on définit des prototypes de formulaires d'accès et de mise-à-jour de plus en plus fonctionnels et complets tout en les soumettant aux utilisateurs à chaque itération.

Interface Utilisateur

L'analyse aura sans doute fourni quelques maquettes des formulaires requis pour les différentes transactions de recherche et de traitement des informations.

Il faut définir des interfaces fonctionnelles en séparant:

  • la "façade" (ou "skin") qui définit la mise en page et la présentation des différents types d'éléments de présentation. En HTML, ceci correspond aux "Cascading Style Sheet" (CSS) qui doivent préciser la présentation exacte (fonte, taille de caractères, couleurs, bords, disposition, etc.) de chaque élément. On sera attentif à nommer ces éléments de manière systématique en concaténant:
    • le nom de la famille de formulaire concernée (recherche, mise-à-jour, traitement, etc.)
    • le nom de la division standard dans l'affichage du formulaire (entête, pied de page, contenu principal, copyright, etc.)
    • le nom de la famille de composants concernés (liste, arbre, éditeur de texte, etc.)
    • le nom du sous-composant (niveau 1, niveau 2, titre, sélection, etc.)
  • les composants de chaque formulaire et leur séquence dans le formulaire: cette façon de faire est promue par le logiciel Tapestry qui ramène la définition des pages et de leur enchaînement, à une suite d'appels de composants prédéfinis. NetAgora est différent et se base sur le HTML et ses formulaires (ce en quoi il est proche des pages J2EE JSP).

Logique de traitement

Les classes Java "POJO" (le plus souvent sous forme de JavaBeans) ont notre faveur pour un environnement souple et léger exploitable aussi bien par Tapestry que par des pages JSP.

Pour les accès ne nécessitant pas les fonctionnalités offertes par Zing SRU/SRW, un ORB (Object Request Broker) comme Cayenne ou iBatis permet une interface simple et efficace avec MySQL ou PostgreSQL.

Remonter au début

Applications paramétrables:

Programmation:

Persistence: