Réalisation en Java

Réalisation basée sur l'architecture trois tiers

Nous avons vu que toute application est constituée de trois parties: les données, la logique applicative et la présentation. Nous cherchons donc à conserver la ``logique trois-tiers'' dans la structure de l'application. En fait, le seul tiers nécessitant une phase de programmation importante est le serveur d'application. L'objectif lors de la programmation du serveur applicatif est de rester suffisamment proche de l'architecture trois tiers pour faciliter la maintenance du système. Le codage de l'application nécessite la réalisation de plusieurs tâches directement en lien avec chacun des trois tiers:

• l'accès aux données (JDBC, Java beans)
• la logique applicative ou traitements sur les données (peu importante ici)
• la génération et la diffusion du code nécessaire à la présentation (JSP, Servlets)

L' évolutivité du système sera directement liée à la séparation nette de ces différentes parties. En effet chacune de ces parties peut-être modifiée séparément du reste du système. On peut par exemple décider de modifier la page HTML de présentation sans modifier le reste. La séparation nette entre la présentation et le reste permet d'effectuer les modifications sans être perdu dans le code applicatif et d'accès à la base de données mais également sans risquer d'effectuer de modification inopportune sur ce code. En pratique on constate un lien très fort entre la logique applicative et les données. En fait la logique applicative nécessite parfois de réaliser des actions spécifiques sur les données (requêtes SQL spécifiques et/ou optimisés ). Cette remarque peut également être liée au principe de la conception objet. Dans une méthode de conception objet, on conçoit des méthodes dans les objets et non des traitements manipulant des entités externes comme c'est le cas dans la méthode merise. Dans un système conçu objet, la logique applicative est donc en grande partie implantée dans des méthodes des classes gérant l'accès aux données. Le lien entre les méthodes est d'autant plus fort ici que le système est très orienté vers la structure relationnelle des données.

Génération de la structure du code JAVA

Nous venons de voir le point sur lequel nous avons commencé à nous éloigner de la méthode Merise: les méthodes sont associées à des classes et ne sont donc pas conçues de façon indépendante des données stockées. Ce n'est pas là le seul intérêt de l'utilisation d'UML dans le cadre de notre projet. En effet, l'objectif de l'étape suivante est la réalisation en langage JAVA de l'application destinée à être déployée sur le serveur d'application WebLogic. La structure du code sera bien entendu basée sur les classes conçues dans le diagramme statique UML. Nous avons donc une correspondance entre une classe et une table de la base de données. Tout l'intérêt d'un atelier de génie logiciel comme Rational Rose est d'assurer cette correspondance. Rose permet la génération du code JAVA correspondant aux classes conçues en UML. Nous obtenons ainsi des fichiers JAVA stockés dans une arborescence correspondant aux packages UML. Chaque fichier contient:

• l'instruction package correspondant au package UML contenant la classe
• les instructions import pouvant être déduites du modèle UML
• la déclaration de la classe qui contient:
  • la déclaration des attributs
  • le constructeur par défaut
  • les méthodes set et get précodées pour tous les attributs
  • la déclaration des autres méthodes présentes dans le modèle UML

Le squelette du code ainsi obtenu nous permet de nous pencher sur les parties de codage intéressantes sans avoir à nous soucier des petits problèmes de compilation liés aux erreurs sur les méthodes set et get en particulier. Nous nous penchons en particulier sur la manipulation des champs de formulaires ainsi que sur le lien avec la base de données.

Structuration des accès à la base de données

L'objectif est ici d'obtenir des objets correspondant au mapping des tables de la base de données et directement utilisable pour la présentation (page JSP). Ces objets peuvent posséder des méthodes qui constituent la logique applicative. Ce but est celui des EJB, toutefois ils présentent plusieurs inconvénients. En effet les EJB sont destinés à la mise en place d'une architecture distribuée, ce qui signifie qu'ils proposent une structure répondant aux besoins d'une telle architecture. Ceci implique une mise en place relativement complexe prenant en compte de nombreux fichiers (Interface HOME, bean, classe de clé primaire, descripteur de déploiement sous la forme d'un fichier XML). De plus l'intérêt et la qualité des EJB reste relativement contestée (en tout cas chez Kallisto). Nous avons donc choisi une autre approche pour la réalisation de notre application. Les tâches à réaliser dans le bean sont les suivantes:

• récupération des champs du formulaire
• exécution de requêtes SQL (recherche, insertion, mise à jour)
• gestion des erreurs liées à ces requêtes
• création d'un bean à partir du résultat d'une requête SQL

Ces fonctions sont donc réparties dans plusieurs fonctions: rechercher, insérer, initialiser,... Les accès à la base de données se situent tous dans ces fonctions. En particulier la gestion des transactions et l'éxecution des requêtes SQL se trouvent ici. Ainsi les requêtes de recherche se trouvent dans les fonctions rechercher, les requêtes d'insertion dans les fonctions insérer, etc... Cette organisation très simple permet à chaque programmeur de se retrouver plus facilement dans le code y compris lorsqu'il n'en est pas l'auteur. Une chose est également importante: rendre le bean directement utilisable dans la page JSP.

Gestion de la présentation

En effet une autre partie importante du travail est l'affichage des formulaires et de leurs résultats. Ceci est réalisé à l'aide de pages JSP (Java Server Page). Une page JSP est une page HTML dans laquelle il est possible d'écrire du code Java à l'aide de balises spécifiques. En particulier on peut insérer la valeur de retour d'une fonction dans la page HTML. En pratique on cherche à obtenir une page JSP la plus compréhensible possible. Pour cela elle doit contenir le moins de code Java possible et permettre de faire ressortir la structure de la page. Nous avons déjà vu que le code Java était situé dans des beans ce qui améliore considérablement la lisibilité de la page JSP. Le langage HTML utilisé ici est le HTML 4.0. La quasi totalité des utilisateurs potentiels dispose de Internet Explorer version 5 ou supérieur, la compatibilité avec d'autres navigateurs n'est donc pas la priorité. Le HTML 4.0 permet l'utilisation de feuilles de styles css (cascading styles sheets), les détails de la présentation sont donc placés dans une feuille de styles. Cette feuille contient tous les détails de la présentation: polices et tailles de caractères, couleurs et images de fonds,... Ceci permet de faciliter la lecture du code HTML, mais aussi de proposer une présentation plus intéressante pour l'utilisateur. Le Java-script quand à lui nous permet de controler les entrées de l'utilisateur dans le formulaire HTML avant d'envoyer la requête au serveur. Nous évitons ainsi les requêtes multiples dues aux informations erronées entrées par l'utilisateur. Les problèmes résolus à l'aide du Java-script sont les champs ne pouvant pas être vides, la validité du format des dates ou encore les valeurs numériques.