De Wikipractice: Le site Internet des Meilleures Pratiques.

Sommaire 1 Avant-propos 2 Introduction 3 Problématique 3.1 Définition d’un framework 3.2 Présentation du modèle MVC 3.3 Présentation du framework Struts 3.4 Composants 3.4.1 Composants du contrôleur 3.4.2 Composants du modèle 3.4.3 Composants de la vue 3.5 Avantages du framework Struts 3.6 Limites du framework Struts 4 Présentation de Project Online 4.1 Fonctionnalités de Project Online 4.2 Page de login 4.3 Page d’accueil 4.4 Ressources 4.5 Projets 4.6 Babillard à messages 4.7 Outil de suivi des problèmes 4.8 Outil de suivi des tâches 4.9 Graphiques 4.10 Rapports 4.11 Changer votre mot de passe 4.12 Quitter 5 Réalisation de Project Online 5.1 Modèle de données 5.2 Contrôleur 5.3 Modèle 5.4 Vue 5.5 Fichiers de configuration et fichiers ressources 5.6 Utilitaires 5.7 Serveur 6 Améliorations possibles de Project Online 7 Conclusion 8 Références 9 Annexes 10 Commentaires 11 Évaluation 12 Collaborateurs 13 Traduction

Avant-propos

Cet essai s’adresse à des lecteurs ayant une connaissance de base du langage Javaet de la réalisation d’applications Web à l’aide des technologies Servlets et Java Server Pages (JSP). Pour ceux qui ne seraient pas familiarisés avec ces technologies, j’ai placé en référence quelques liens utiles en rapport avec les technologies utilisées dans le cadre de cet essai.

Cet essai s’inscrit dans le prolongement de celui de M. Christian Corneau intitulé « L’utilisation de l’approche orientée objet dans la conception d’applications Web » . On y retrouve une excellente introduction aux concepts de patterns et de frameworks. On y présente également le framework Struts comme illustration d’un framework de type « whitebox » basé sur une architecture MVC (Modèle-Vue-Contrôleur). Le présent essai permettra de s’attarder un peu plus en détail au fonctionnement du framework Struts de même qu’aux avantages et aux limites de celui-ci.

Introduction

La réalisation d’applications Web dynamiques pose plusieurs défis au développeur. Il n’est pas simple de savoir comment combiner les nombreuses technologies existantes (ex. : JSP, Servlets, Applets, HTML) de façon à créer une application attrayante, robuste, performante, sécuritaire, facile d’utilisation et d’entretien. Les frameworks d’application et, en particulier, le framework Struts qui sera étudié dans le cadre de cet essai, visent à offrir une structure permettant au développeur de réaliser une application de meilleure qualité en y consacrant moins de temps et d’efforts. L’objectif d’un framework comme Struts est également de faciliter la maintenance de l’application et l’évolution des fonctionnalités, le besoin échéant.

Dans cet essai, nous définirons d’abord les concepts de framework et de modèle MVC. Nous présenterons ensuite les composants du framework Struts et nous discuterons de ses avantages et de ses limites. Enfin, nous présenterons une application Web, appelée Project Online, qui a été développée à l’aide du framework Struts.

Problématique

La problématique de cet essai pourrait se résumer par la question suivante : Comment le framework Struts facilite-t-il le travail du développeur d’applications Web ? Pour tenter de répondre à cette question, nous nous appuierons à la fois sur des connaissances théoriques et sur l’expérience concrète du développement d’une application Web.

Comme le framework Struts est un framework « open source » (c’est-à-dire dont le code source est disponible et modifiable) et, par surcroît, gratuit, une autre problématique s’est présentée au cours de la réalisation de notre application : Est-il possible de réaliser une application Web de qualité uniquement à l’aide de composants open source et gratuits ? Dans le but d’apporter une réponse à cette question, nous avons opté pour réaliser notre application entièrement à l’aide de composants open source disponibles gratuitement sur internet.

Définition d’un framework

Avant d’aborder plus en détail le framework Struts, il convient de définir brièvement ce qu’est un framework d’application et, en particulier, ce qu’est le modèle MVC 2 sur lequel s’appuie le framework Struts. Pour les lecteurs qui désireraient en apprendre plus sur ces sujets, plusieurs références sont indiquées à la fin de cet essai.

La définition suivante d’un framework a été proposée par Ralph E. Johnson de l’Université de l’Illinois : “A framework is a set of classes that embodies an abstract design for solutions to a family of related problems.”

Il existe donc plusieurs types de frameworks qui visent à solutionner différents types de problèmes. Les frameworks d’application d’entreprise, comme le framework Struts, visent à apporter une solution au développement d’applications spécifiques à un domaine d’activités de l’entreprise. Le framework Struts est souvent qualifié de framework whitebox parce que le développeur doit créer ses propres classes en héritant des classes du framework. Pour ce faire, le développeur doit bien comprendre le fonctionnement des classes du framework. Au contraire, dans un framework blackbox, le développeur peut utiliser les classes du framework telles quelles, sans avoir besoin d’en connaître le fonctionnement interne. Les frameworks whitebox sont évidemment un peu plus complexes à utiliser mais sont également beaucoup plus flexibles et peuvent évoluer plus facilement avec les besoins de l’entreprise.

Voici maintenant une autre définition de Ralph E. Johnson qui permet de préciser davantage ce qu’est un framework : “A framework is a reusable, semi-complete application that can be specialized to produce custom applications.”

Grâce à cette définition, on comprend qu’un framework ne constitue pas une application complète. Il s’agit plutôt d’une structure d’application qui doit être adaptée aux besoins spécifiques d’une application concrète. On pourrait comparer un framework à une charpente de maison. La charpente est à la base de la construction de la maison : plus la charpente est solide, plus la maison sera solide elle aussi.

Les frameworks connaissent une importante popularité dans le domaine de la programmation orientée-objet parce qu’ils permettent d’améliorer la modularité, l’extensibilité et la réutilisation des composants d’une application. La modularité fait référence au degré de dépendance entre les classes ou entre les groupes de classes qui constituent l’application. Plus le degré de dépendance, appelé souvent couplage, est faible, plus l’application sera modulaire. Une défectuosité est beaucoup plus facile à détecter et à corriger dans une application modulaire car on peut aisément en isoler la cause dans un module particulier de l’application. L’extensibilité, quant à elle, concerne la facilité avec laquelle il est possible d’ajouter de nouvelles fonctionnalités à l’application ou encore d’ajouter de nouveaux utilisateurs. Une application extensible permettra d’intégrer un nouveau module sans qu’il soit nécessaire de faire de modifications importantes aux modules existants. Enfin, la réutilisation concerne la capacité de récupérer le code d’une application donnée pour développer une nouvelle application. La réutilisation permet évidemment de réduire le temps de développement ainsi que le nombre de défectuosités de l’application.

Présentation du modèle MVC

Le modèle MVC est un modèle de design d’applications qui vise à subdiviser l’application en trois composants : le modèle, la vue et le contrôleur. Le modèle correspond aux données de l’application, la vue correspond à la présentation des données de l’application et le contrôleur correspond à la logique de fonctionnement de l’application (application flow en anglais). La figure 1 montre l’interaction entre ces trois composants et l’utilisateur.

Figure 1. Modèle MVC

On constate que l’utilisateur doit passer par le contrôleur pour pouvoir avoir accès au modèle et aux vues. Le contrôleur porte donc bien son nom : c’est lui qui contrôle le modèle et les vues. Ce modèle présente plusieurs avantages qui découlent de la modularité. Une application conçue selon ce modèle est plus facile à modifier et à maintenir. On peut, par exemple, modifier la logique de l’application (contrôleur) sans devoir changer quoi que ce soit au modèle et aux vues. On peut également ajouter de nouvelles fonctionnalités à l’application, comme une nouvelle vue, sans devoir modifier en profondeur le contrôleur et le modèle.

Les modèles MVC 1 et 2 sont tout simplement des adaptations du modèle MVC aux applications Web. Les modèles 1 et 2 diffèrent cependant au niveau de leur philosophie d’implantation et des technologies Web utilisées. Dans le modèle 1, les pages JSP assument un double rôle de vue et de contrôleur. Les pages JSP sont donc responsables de recevoir les requêtes de l’utilisateur en plus de répondre aux requêtes. Dans le modèle 2, par contre, on utilise les Servlets pour jouer le rôle de contrôleur et on réserve aux pages JSP seulement le rôle de présentation des données (vue). L’architecture du modèle MVC 2 permet donc de combiner deux technologies (pages JSP et Servlets) dans le but d’obtenir une meilleure division entre le rôle de contrôleur et celui de vue. Cela permet, entre autres, de réaliser des applications dont les composants sont plus facilement extensibles et réutilisables.

Dans le modèle MVC 2, le navigateur Web de l’utilisateur envoie une requête http à un servlet contrôleur résidant sur un serveur Web. Le contrôleur décide alors s’il doit diriger l’utilisateur vers une page JSP (forward) ou s’il doit déléguer le travail à d’autres servlets (dispatch). Dans ce dernier cas, les servlets se chargent d’effectuer certaines actions, comme mettre à jour les objets du modèle (update). Les objets du modèle (Java Beans) servent ensuite à alimenter les pages JSP (extract) qui sont finalement envoyées au navigateur de l’utilisateur sous forme de réponse http.

Figure 2. Modèle MVC 2

Contrairement au modèle MVC de base (figure 1), la logique de fonctionnement de l’application est ici partagée entre le servlet contrôleur et les servlets actions. Le servlet contrôleur demeure cependant toujours l’unique point d’entrée de l’application. Toutes les requêtes en provenance de l’utilisateur doivent passer par lui. Cela permet de centraliser au maximum la logique de fonctionnement de l’application et ainsi de faciliter grandement la maintenance et l’extensibilité de l’application.

Présentation du framework Struts

Struts est un framework open source qui a été développé par le projet Apache Jakarta et qui met en application le modèle MVC 2. On y retrouve donc les mêmes composants que dans MVC 2 : le modèle, la vue et le contrôleur. Dans le framework Struts, le rôle de modèle est joué par des Java Beans, le rôle de vue par des pages JSP et le rôle de contrôleur par un servlet contrôleur et plusieurs servlets actions. Étant donné que Struts est un framework de type whitebox, le développeur doit pouvoir développer ses propres classes en héritant des classes du framework. Il doit également développer lui-même (ou utiliser un autre framework) pour assurer certaines fonctions de l’application qui ne sont pas remplies par Struts, comme l’accès à la base de données, par exemple. Dans la figure 3, les fonctions remplies par Struts sont délimitées par une ligne pointillée.

Figure 3. Framework Struts

En observant la figure 3, on constate que plusieurs éléments ont été ajoutés au modèle MVC 2 original. En effet, les fichiers XML de configuration, les librairies de tags JSP, les fichiers ressources et plusieurs classes spécialisées ont été joints à l’architecture du framework pour faciliter encore davantage le travail du développeur d’applications Web. Voyons donc plus en détail les divers composants du framework Struts.

Composants

Composants du contrôleur

ActionServlet

Cette classe constitue le cœur du framework Struts : c’est le servlet contrôleur du modèle MVC 2. Le servlet reçoit les requêtes http en provenance de l’utilisateur. Il les analyse et décide du comportement à adopter en réponse à la requête de l’utilisateur. Le comportement de l’application est défini dans un fichier de configuration (struts-config.xml). Le servlet peut opter pour diriger la requête de l’utilisateur vers une page JSP ou vers un autre servlet qui se chargera d’exécuter une action. Le servlet est aussi responsable de valider la requête si un bean de type ActionForm a été défini préalablement dans le fichier de configuration (struts-config.xml). Le servlet contrôleur est toujours unique pour assurer l’existence d’un seul point d’entrée pour l’application. Cependant, la classe ActionServlet est extensible pour permettre l’exécution de certaines méthodes au moment du démarrage de l’application.

Action

Le rôle de la classe Action est de traiter les requêtes qui lui sont envoyées par le servlet contrôleur. Quand le servlet contrôleur décide de déléguer une requête à un servlet Action, il appelle la méthode perform() de ce dernier. Le servlet Action se charge alors de mettre à jour les beans du modèle et, lorsque c’est nécessaire, de commander la mise à jour de la base de données. Quand le traitement est complété, la classe Action retourne un objet de type ActionForward qui identifie le prochain composant (ex. : page JSP) qui aura le contrôle de la requête. On peut créer autant de servlets que nécessaire en héritant de la classe Action. En général, il existe un servlet par action. L’ajout d’une commande ou la modification d’une commande peuvent, par exemple, être considérés comme des actions.

ActionForm

La classe ActionForm permet au développeur de créer un bean contenant les données saisies par l’utilisateur dans un formulaire HTML. Lorsque l’utilisateur appuie sur le bouton submit au bas du formulaire HTML, il envoie une requête au serveur contenant tous les champs du formulaire. Si le fichier de configuration struts-config.xml indique l’existence d’un bean pour le formulaire, le servlet contrôleur met à jour automatiquement les propriétés du bean avec les champs du formulaire puis il appelle la méthode validate() du bean ActionForm. Cette méthode effectue alors la validation du formulaire et retourne un objet de type ActionErrors contenant toutes les erreurs détectées. Si la validation réussit, le bean ActionForm est envoyé au servlet Action à l’aide de la méthode perform(). Par contre, si la validation échoue, la requête est dirigée cette fois vers une page JSP qui affichera la ou les erreurs de validation. (Note : Pour que le servlet contrôleur puisse mettre à jour automatiquement les propriétés du bean, il faut absolument que les champs du formulaire et les propriétés du bean possèdent le même nom.)

Web.xml

Le fichier web.xml est responsable de la configuration de l’application. Il identifie le servlet contrôleur ainsi que les librairies de tags utilisées par l’application. Au démarrage de l’application, le serveur Web lie le fichier web.xml et démarre le servlet contrôleur. Le serveur Web utilise par la suite le fichier web.xml pour déterminer quelles sont les requêtes http qu’il doit envoyer au servlet contrôleur. Toutes les requêtes qui possèdent la même extension que celle indiquée dans le fichier web.xml (en général, l’extension utilisée est « .do ») seront envoyées au servlet contrôleur. Le fichier web.xml contient également la référence aux fichiers ressources de l’application.

Struts-config.xml

Le fichier struts-config.xml permet de configurer le servlet contrôleur. Toutes les actions exécutées par l’application doivent être définies dans ce fichier à l’aide de tags XML. Le servlet contrôleur se sert de ces tags pour créer les objets de type ActionMapping qui serviront à associer la requête avec les servlets de type Action, les beans de type ActionForm, etc. Autrement dit, le fichier struts-config.xml définit le comportement que l’application doit adopter en réponse à chaque type de requête qui lui est envoyée.

ActionMapping(s)

À partir de l’information contenue dans le fichier de configuration struts-config.xml, le servlet contrôleur crée un objet de type ActionMapping pour chaque type de requête qu’il doit traiter. Lorsque le servlet contrôleur appelle la méthode perform() de la classe Action, il passe en argument l’objet ActionMapping qui correspond à la requête. De cette façon, le servlet Action aura accès aux méthodes de la classe ActionMapping pour déterminer à quel composant de l’application (ex. : page JSP) il doit donner le contrôle de la requête une fois que l’action sera terminée. La classe ActionMappings est une collection d’objets de type ActionMapping.

ActionError(s)

La classe ActionError permet de conserver les messages d’erreur générés par l’application. La classe ActionErrors est une collection de plusieurs objets de type ActionError. Les pages JSP ont accès aux messages d’erreur en utilisant les librairies de tags de Struts.

ActionForward

La classe ActionForward est utilisée pour déterminer la destination de la requête une fois l’action complétée. Pour une même action, il est possible de définir plusieurs destinations possibles dépendamment du résultat de l’action. Par exemple, si l’action login réussit, la destination sera le menu principal de l’application. Par contre, si l’action échoue à cause d’un mot de passe invalide, la destination sera la page de login. Ce mécanisme apporte beaucoup de souplesse à la logique de l’application.

Composants du modèle

Java Beans

Les Java Beans permettent de conserver les données de l’application et d’y accéder. Comme les données sont spécifiques à chaque application, il n’y a pas de classes de modèle incluses dans le framework Struts (à part les beans de type ActionForm). Chaque développeur doit donc développer ses propres beans de modèle. Un Java Bean, par définition, est constitué d’un ensemble de méthodes get et set qui permettent d’obtenir et de mettre à jour les propriétés du bean. Dans une application de magasinage en ligne, par exemple, on pourrait décider de créer un bean pour la commande et un bean pour le client. Si le nom est une propriété du client et la date une propriété de la commande, il faudrait que le bean client possèdent les méthodes getNom et setNom et le bean commande les méthodes getDate et setDate. Les servlets utilisent les méthodes setXxx pour mettre à jour les propriétés du bean de modèle. Par la suite, les pages JSP utilisent les méthodes getXxx pour afficher les propriétés du bean. L’accès aux propriétés des beans est facilité par l’utilisation des tags de Struts. Quand un développeur crée un bean, il doit également définir le scope du bean. Le scope détermine la durée de vie du bean ainsi que le contexte dans lequel le bean sera visible. Le développeur a le choix de définir le bean avec un scope de page, de requête, de session ou d’application.

Accès aux données

Comme nous l’avons déjà mentionné, Struts ne supporte pas l’accès aux données stockées dans une base de données. Par contre, le framework s’intègre bien à d’autres technologies d’accès aux données comme JDBC et JNDI.

Composants de la vue

Librairies de tags JSP

Les pages JSP ne sont pas incluses dans le framework Struts car celles-ci sont spécifiques à chaque application Web. Par contre, Struts fournit des librairies de tags JSP qui facilitent la création des pages JSP. Ils permettent de réduire au minimum le nombre de lignes de code Java nécessaires pour créer une page JSP. Les tags sont définis dans des fichiers texte avec une extension « .tld ». Ces fichiers sont identifiés dans le fichier de configuration web.xml.

Fichiers ressources

Struts offre la possibilité d’internationaliser le contenu des pages JSP. Pour chacune des langues supportées par l’application Web, le développeur doit simplement créer un fichier texte avec une extension « .properties ». Le servlet contrôleur utilise le fichier web.xml pour localiser les fichiers ressources et créer les objets de la classe ResourceBundle qui supportent l’affichage du texte en différentes langues. Un fichier ressource est conçu comme un index : chaque ligne de texte est associée à une clé. Les clés sont les mêmes dans tous les fichiers mais, bien sûr, le texte varie en fonction de la langue du fichier. Les pages JSP utilisent ces clés pour afficher le texte dans la langue choisie par l’utilisateur. Cela est possible grâce aux librairies de tags de Struts. (Note : La classe ResourceBundle n’est pas une classe spécifique à Struts. Elle fait partie du JDK.)

Avantages du framework Struts

Le choix de Struts comme framework de développement comporte de nombreux avantages liés à la modularité de l’architecture MVC :

1. L’application est extensible. Il est possible de modifier un composant ou d’ajouter de nouveaux composants sans affecter le fonctionnement des composants existants.
2. Les composants de l’application sont réutilisables. Le couplage entre les divers composants étant faible, il est possible de réutiliser les composants de l’application pour développer de nouvelles applications.
3. L’application est facile à maintenir. La division de l’application en plusieurs composants rend l’identification et la correction des défectuosités plus efficaces. De plus, le fait qu’il y ait peu ou pas de redondances entre les divers composants évite au développeur de devoir faire la même modification à plusieurs endroits.
4. L’équipe de développement peut être structurée de façon à tirer le meilleur parti des talents de chacun. Les développeurs qui sont habiles dans le design de pages web sont rarement très habiles dans la programmation Java et vice-versa. La séparation complète entre les vues et le contrôleur permet à certains développeurs de se consacrer uniquement au design des pages JSP et à d’autres de se spécialiser dans le développement des servlets et des Java Beans.
5. La division du travail est facilitée. Si tout le code d’une application était concentré dans un seul fichier, il serait impossible de diviser le travail. Avec Struts, le code de l’application est subdivisé en plusieurs actions. Les développeurs peuvent donc travailler en même temps sur des actions différentes puis intégrer le résultat de leur travail sans problème.
6. L’utilisation d’un framework force les développeurs à se conformer à certains standards de développement. Le respect des standards rend l’application plus facile à comprendre pour les autres développeurs et aussi plus facile à maintenir.
7. La présence d’un seul et unique servlet contrôleur rend la compréhension et la maintenance de l’application beaucoup plus simple. Quand la logique de l’application est intégrée dans les pages JSP, il faut consulter plusieurs pages JSP pour avoir seulement une idée du fonctionnement de l’application. Au contraire, avec Struts, la logique de l’application est centralisée en un seul endroit.

Le framework Struts offre aussi de nombreux autres avantages, tels que :

1. L’utilisation de fichiers de configuration XML rend les modifications du contrôleur beaucoup plus faciles. Le fichier de configuration évite de devoir modifier directement le code du servlet contrôleur.
2. L’utilisation de beans pour conserver l’état du modèle assure une grande flexibilité. Struts peut facilement s’adapter à n’importe quel modèle d’accès aux données et n’importe quelle source de données.

En outre, l’utilisation des beans contribue à réduire le nombre de requêtes SQL exécutées.

1. L’internationalisation de l’application est grandement facilitée par l’usage des fichiers ressources. Comme le texte est affiché dynamiquement au moment de l’exécution de la page JSP, il n’est pas nécessaire de créer des pages JSP redondantes pour chacune des langues supportées par l’application.
2. Les librairies de tags JSP rendent les pages JSP plus lisibles et plus rapides à développer. Un seul tag JSP permet de remplacer plusieurs lignes de code Java.
3. Les beans ActionForm facilitent le travail de validation des formulaires. La validation des données saisies par l’utilisateur est souvent une tâche fastidieuse pour le développeur. Struts rend le travail plus facile en mettant à jour automatiquement les propriétés du bean de formulaire et en appelant la méthode de validation.
4. Le framework Struts est open source. Il est donc possible de consulter et même de modifier le code source du framework pour l’adapter à des besoins spécifiques.
5. Le framework Struts bénéficie du support d’une communauté très dynamique et d’une visibilité de plus en plus grande dans l’industrie. La communauté contribue à améliorer continuellement la qualité du framework et peut offrir du support en cas de problèmes.
6. Struts permet aux développeurs de profiter des avantages d’une architecture MVC sans avoir à la développer eux-mêmes. Les spécialistes s’entendent pour dire que le modèle MVC est une architecture très performante pour la réalisation d’applications web. Cependant, développer les composants d’une architecture MVC à partir de zéro est une tâche complexe et coûteuse. En utilisant Struts, qui est disponible gratuitement, on contribue à réduire le temps et les coûts de développement.
7. L’utilisation d’un framework garantit une meilleure stabilité à l’application. Le framework Struts est testé et utilisé par de nombreux développeurs à travers le monde. Le code de Struts a, par le fait même, des chances d’être plus robuste que n’importe quel code développé localement.

Limites du framework Struts

Lors du choix d’un framework, il est important d’être conscients des limites de celui-ci. Un framework n’est pas, en effet, une solution miracle qui fait tout le travail à la place du développeur. Dans le but de prendre une décision éclairée concernant l’utilisation de Struts, il importe de bien comprendre ce qu’est le framework mais aussi ce qu’il n’est pas.

1. Struts n’est pas un outil de présentation. La création des vues est sous la responsabilité du développeur. Par contre, Struts s’intègre bien à plusieurs systèmes de présentation tels que Java Server Pages, Tiles, Jakarta Velocity, etc.
2. Struts n’est pas non plus un outil d’accès aux données. Le développeur doit développer sa propre solution d’accès aux données ou utiliser un autre framework existant. La création des objets du modèle (Java Beans) est également sous la responsabilité du développeur.

Si l’on décide d’adopter Struts, il ne faut pas croire que la productivité du développement va monter en flèche du jour au lendemain. Comme tout framework, Struts nécessite en effet une période d’apprentissage qui peut varier d’un développeur à l’autre. Un développeur qui est déjà familiarisé avec l’architecture MVC et le développement d’applications Web aura évidemment plus de facilité à comprendre Struts. Par contre, il aura quand même besoin d’une certaine période d’adaptation. Le modèle MVC force, en effet, le développeur à modifier ses habitudes de programmation. De plus, l’utilisation des tags JSP et des fichiers de configuration XML nécessite une période d’apprentissage pour tous les développeurs.

Quant au développeur peu expérimenté, il est fort probable qu’il aura besoin d’une période d’apprentissage plus longue que s’il travaillait sans le framework. Cela s’explique par le fait que Struts requiert l’usage de plusieurs composants et technologies différents. Or, le nombre des composants introduit une source de complexité supplémentaire.

En conclusion, une sous-estimation de l’effort nécessaire pour comprendre d’abord le framework Struts, puis pour l’adapter et l’intégrer à d’autres solutions pourrait entraîner une sous-estimation importante du coût et du temps de développement. Il est donc essentiel d’avoir des attentes réalistes par rapport à l’usage de Struts.

Présentation de Project Online

L’application Project Online a été développée à l’aide du framework Struts et de d’autres composants open source disponibles gratuitement. Nous allons d’abord présenter les fonctionnalités de l’application, puis nous discuterons de la réalisation proprement dite de l’application.

Fonctionnalités de Project Online

L’application Project Online est un outil qui vise à améliorer la gestion des projets. J’ai constaté, au cours de mes années de travail, un manque d’outils permettant d’effectuer un suivi efficace des tâches assignées aux membres des équipes de projet. Le suivi doit se faire soit par réunion, soit par téléphone ou par courriel. L’information recueillie ainsi doit ensuite être saisie par le gestionnaire de projet dans un chiffrier électronique pour pouvoir faire des calculs et des graphiques. Cela entraîne des pertes de temps et, parfois, des erreurs. J’ai remarqué également un manque d’outils permettant d’assurer un suivi adéquat des problèmes mentionnés dans les réunions, les rapports, les courriels, etc. Les problèmes sont souvent mis de côté, ignorés et même oubliés, faute d’avoir un outil pour en faire le suivi systématique. J’ai donc décidé de créer une application qui permettrait de remplir deux fonctions principales : le suivi des tâches et le suivi des problèmes. À cela, j’ai ajouté un babillard à messages qui permet de transmettre rapidement des messages destinés à l’équipe de projet, de même que quelques rapports et graphiques qui montrent l’évolution du projet.

Le choix de créer une application Web par rapport à une application traditionnelle présente, pour moi, plusieurs avantages : les membres de l’équipe peuvent avoir accès à l’application quel que soit l’endroit où ils travaillent sans avoir à installer de logiciel sur leur ordinateur. L’application peut également être intégrée à d’autres sites Web existants, comme à un intranet, par exemple.

Le logo de Project Online a été choisi parce qu’il représente une cible divisée en quatre sections qui symbolisent les quatre variables clés de la gestion de projet : l’étendue, le budget, l’échéance et la qualité. L’objectif de Project Online est de permettre au gestionnaire de projet de mieux gérer ces quatre variables qui sont responsables du succès ou de l’échec d’un projet.

Figure 4. Logo de Project Online

Page de login

La page de login permet aux utilisateurs d’avoir accès à l’application. Si un utilisateur fournit un nom d’utilisateur ou un mot de passe invalide, un message d’erreur s’affiche. Si la validation réussit, la page d’accueil de l’application s’affiche. La page de login s’affiche par défaut dans la langue du navigateur internet de l’utilisateur. Cependant, l’utilisateur a toujours la possibilité de changer la langue (anglais ou français) à partir de la page de login. Au bas de la page, on retrouve un lien « Au sujet de Project Online » et un lien « Aide ». Le premier lien donne des renseignements généraux sur l’application. Le deuxième donne des explications sur les fonctionnalités de l’application. Ces deux liens sont accessibles à partir de toutes les pages de Project Online. Si un utilisateur essaie d’accéder directement à la page d’accueil en tapant l’adresse de la page dans son navigateur, il sera automatiquement dirigé vers la page de login pour l’obliger à s’identifier. Cela est vrai aussi pour toutes les autres pages de l’application : si l’utilisateur ne s’est pas déjà identifié, il sera dirigé vers la page de login.

Page d’accueil

La page d’accueil permet d’avoir accès aux différentes fonctions de l’application. Les fonctions qui apparaissent dans les menus dépendent du type d’utilisateur. Les gestionnaires de projet ont accès à toutes les fonctions alors que les membres d’une équipe de projet ont seulement accès à certaines fonctions pour des raisons de sécurité. Les membres d’une équipe de projet ne peuvent donc pas ajouter de nouvelles tâches ou en supprimer, par exemple. Ils ne peuvent pas non plus visualiser tous les graphiques et rapports pour des raisons de confidentialité de l’information. Les cinq derniers messages et problèmes saisis dans l’application sont affichés sur la page d’accueil pour attirer l’attention des utilisateurs.

Ressources

L'option « Ressources » du menu permet aux gestionnaires de projet d'ajouter de nouvelles ressources et de modifier les profils existants. Le gestionnaire de projet assigne un nom d’utilisateur et un mot de passe temporaire à chaque nouvelle ressource. Il peut envoyer un courriel à la ressource pour l’informer de son nom d’utilisateur et de son mot de passe.

1. Ajouter une ressource : Permet d'ajouter de nouvelles ressources.
2. Voir la liste des ressources : Permet de voir la liste des ressources. À partir de la liste, on peut modifier ou supprimer le profil d’une ressource.

Projets

L'option « Projets » du menu permet aux gestionnaires de projet d'ajouter de nouveaux projets et de modifier les projets existants.

1. Ajouter un projet : Permet d'ajouter de nouveaux projets.
2. Voir la liste des projets : Permet de voir la liste des projets. À partir de la liste, on peut modifier ou supprimer un projet.

Babillard à messages

Le Babillard à messages offre une façon simple et efficace de partager de l'information avec les membres de l’équipe du projet. Dans la section « Babillard à Messages » du menu, on trouve les options suivantes:

1. Ajouter un message : Permet d'ajouter un nouveau message. Les cinq plus récents messages seront affichés sur la page d’accueil.
2. Voir les messages ajoutés par vous : Permet à un utilisateur de voir tous les messages qu’il a déjà ajoutés. À partir de la liste, il peut modifier ou supprimer un de ses messages.
3. Voir les messages par projet : Permet de voir tous les messages reliés au projet sélectionné. À partir de la liste, un utilisateur de type « Project Manager » peut modifier ou supprimer l’un des messages.

Outil de suivi des problèmes

L'outil de suivi des problèmes offre un moyen de faire le suivi des problèmes qui surviennent dans un projet. Lorsque quelqu’un ajoute un problème, il doit obligatoirement l’assigner à une ressource du projet. Cette personne devient alors responsable de faire le suivi et d’apporter une solution au problème. Il est possible d’envoyer un courriel pour avertir la personne assignée au problème. La personne qui a ajouté le problème, celle qui est assignée au problème et le gestionnaire de projet sont les seules ressources autorisées à faire des modifications au problème. Il n’est jamais possible de supprimer un problème, mais on peut en modifier le statut par les termes « annulé », « retardé » ou « fermé ». Dans la section « Outil de suivi des problèmes » du menu, on trouve les options suivantes:

1. Ajouter un problème : Permet d'ajouter un problème. Les cinq plus récents problèmes seront affichés au menu principal.
2. Voir les problèmes ajoutés par vous : Permet à un utilisateur donné de voir tous les problèmes qu’il a déjà ajoutés. À partir de la liste, il peut modifier un des problèmes.
3. Voir les problèmes assignés à vous : Permet à l’utilisateur de voir tous les problèmes qui lui ont été assignés par d'autres ressources. À partir de la liste, il peut modifier un des problèmes dont il a la responsabilité.
4. Voir les problèmes par projet : Permet de voir tous les problèmes reliés au projet qui a été sélectionné. À partir de la liste, il est possible de modifier un des problèmes si l’utilisateur est de type « Project Manager ».

Outil de suivi des tâches

L'outil de suivi des tâches offre un moyen de faire le suivi des tâches planifiées pour un projet. Le gestionnaire de projet est responsable de créer les tâches et de les assigner aux ressources. Il peut envoyer un courriel pour avertir une ressource qu’une tâche lui a été assignée. La ressource est ensuite responsable de mettre à jour la tâche régulièrement pour indiquer le nombre d’heures consacrées à la tâche, le nombre d’heures estimées pour compléter la tâche, le pourcentage de travail effectué, etc. Dans la section « Outil de suivi des tâches » du menu, on trouve les options suivantes:

1. Ajouter une tâche : Permet d'ajouter une tâche. Cette option est disponible seulement pour les gestionnaires de projet.
2. Voir les tâches ajoutées par vous : Permet de voir toutes les tâches que l’utilisateur a déjà ajoutées. À partir de la liste, il est possible de modifier ou de supprimer une tâche. Toutefois, cette option est disponible seulement pour les gestionnaires de projet.
3. Voir les tâches assignées par vous : Permet de voir toutes les tâches qui ont été assignées à l’utilisateur par les gestionnaires de projet. À partir de la liste, la ressource désignée peut modifier une de ses tâches.
4. Voir les tâches par projet : Permet de voir toutes les tâches reliées au projet qui a été sélectionné. À partir de la liste, il est possible de modifier ou de supprimer une des tâches si l’utilisateur est de type « Project Manager ».

Graphiques

Les graphiques présentent quelques indicateurs clés de la performance du projet. Dans la section « Graphiques » du menu, on trouve les graphiques suivants:

1. Graphique des problèmes par statut : Ce graphique montre le nombre total de problèmes selon le statut. Ce graphique est disponible pour tous les utilisateurs.
2. Graphique des problèmes par priorité : Ce graphique montre le nombre total de problèmes selon la priorité. Ce graphique est disponible pour tous les utilisateurs.
3. Graphique du budget par ressource : Ce graphique montre le nombre d'heures budgétées, le nombre d'heures réelles et le nombre d'heures estimées pour une ressource travaillant à un projet. Ce graphique est disponible seulement pour les gestionnaires de projet.
4. Graphique du budget par projet : Ce graphique montre le nombre d'heures budgétées, le nombre d'heures réelles et le nombre d'heures estimées pour un projet. Ce graphique est disponible pour tous les utilisateurs.
5. Graphique sommaire de la ressource : Ce graphique montre le pourcentage(%) de budget utilisé, le pourcentage (%) de temps utilisé et le pourcentage (%) de travail réalisé pour une ressource travaillant à un projet. Ce graphique est disponible seulement pour les gestionnaires de projet.
6. Graphique sommaire du projet: Ce graphique montre le pourcentage (%) de budget utilisé, le pourcentage (%) de temps utilisé et le pourcentage (%) de travail réalisé pour un projet. Ce graphique est disponible pour tous les utilisateurs.
7. Le pourcentage (%) de budget utilisé est calculé en divisant le total des heures réelles par le total des heures budgétées.
8. Le pourcentage (%) de temps utilisé est calculé en divisant le nombre de jours réels par le nombre de jours planifiés.
9. Le pourcentage (%) de travail réalisé est la moyenne du pourcentage (%) de travail complété pour chaque tâche.

Rapports

Les rapports permettent de visualiser et d'imprimer une information détaillée au sujet des projets, des ressources, des problèmes et des tâches. Dans la section « Rapports » du menu, on trouve les rapports suivants :

1. Rapport des ressources : Ce rapport est une liste de toutes les ressources contenues dans la base de données. Ce rapport est disponible seulement pour les gestionnaires de projet.
2. Rapport des projets : Ce rapport est une liste de tous les projets contenus dans la base de données. Ce rapport est disponible pour tous les utilisateurs.
3. Rapport des tâches : Ce rapport est une liste de toutes les tâches contenues dans la base de données groupées par projet et par ressource. Ce rapport est disponible seulement pour les gestionnaires de projet.
4. Rapport des problèmes : Ce rapport est une liste de tous les problèmes contenus dans la base de données groupés par projet et par ressource. Ce rapport est disponible pour tous les utilisateurs.

Changer votre mot de passe

Cette option permet à l’utilisateur de changer son mot de passe pour plus de sécurité.

Quitter

Cette option permet à l’utilisateur de quitter l’application et de retourner à la page de login.

Réalisation de Project Online

Project Online a été réalisé selon l’architecture MVC du framework Struts. Nous allons donc décrire les composants du contrôleur, du modèle et des vues de l’application. Mais avant, nous allons présenter le modèle de données de l’application.

Modèle de données

Le modèle de données a été réalisé à l’aide de Modèles Magiques, un outil CASE développé par le professeur Dzenan Ridjanovic. Modèles Magiques permet de générer automatiquement le schéma de base de données pour plusieurs systèmes de gestion de base de données (SGBD) dont MySQL, le SGBD utilisé pour la réalisation de Project Online.

Chaque table du modèle possède un identifiant unique appelé oi. L’identifiant oi constitue la clé primaire de la table. Lorsqu’il existe un lien relationnel un à plusieurs entre deux tables, l’identifiant oi devient une clé étrangère dans la table enfant de la relation. La table Sequence conserve le dernier oi utilisé pour chacune des tables du modèle. Lorsqu’une nouvelle occurrence est ajoutée à une table, on obtient le oi en incrémentant de un (1) le oi sauvegardé dans la table Sequence.

Figure 5. Modèle de données de Project Online

Contrôleur

La classe DbActionServlet du paquet struts.db.controller hérite de la classe ActionServlet de Struts. Cette classe permet d’initialiser et de détruire l’accès à la base de données au moment du démarrage et de l’arrêt de l’application. La classe initialise également les collections resourcesCollection et projectsCollection et les sauvegarde dans le contexte de l’application grâce à la méthode getServletContext(). Ces deux collections deviennent ainsi accessibles à toutes les pages JSP de l’application.

Toutes les classes du paquet struts.project.controller héritent de la classe Action de Struts. Ces classes exécutent la logique de l’application. Elles font l’ajout, la modification et la suppression des occurrences de la base de données. Elles font également la mise à jour des beans et des collections de beans qui sont utilisés par les pages JSP.

Les classes du paquet struts.project.view héritent de la classe ActionForm de Struts. Elles permettent de faire la validation des formulaires d’ajout et de modification des messages, des problèmes, des tâches, des ressources et des projets.

Modèle

La gestion de l’accès à la base de données est assurée par les classes du paquet struts.db.model développé par le professeur Dzenan Ridjanovic. Ces classes ont été développées à partir de l’interface de programmation (API) JDBC. Les classes du JDBC ont l’avantage de ne pas être dépendantes d’un SGBD en particulier. On qualifie cette approche de « générique » car elle permet au programmeur de développer une application Java sans devoir se soucier du SGBD qui est utilisé. Pour que cette approche fonctionne, il faut cependant installer un pilote JDBC spécifique à la base de données utilisée. Dans le cas de Project Online, on utilise le pilote Connector/J pour la base de données MySQL. Les classes du paquet struts.db.model gèrent, entre autres, les connexions à la base de données à travers un Connection Pool, ce qui permet d’améliorer la rapidité d’exécution des requêtes SQL. La classe Config du paquet struts.config permet de configurer l’accès à la base de données à partir du fichier de configuration config.properties. Ce fichier contient la référence au pilote JDBC utilisé par l’application de même que le nombre de connexions utilisées par le Connection Pool.

Les classes du paquet struts.project.model héritent soit de la classe DbQueryBean ou de la classe DbQuery qui appartiennent toutes deux au paquet struts.db.model. Les classes héritant de DbQueryBean sont des beans dont les propriétés correspondent aux champs d’une des tables de la base de données. On retrouve donc un bean pour la table Resource, un pour la table Project, etc. Les classes héritant de DbQuery contiennent les méthodes pour effectuer les requêtes SQL. La classe DbQuery utilise la classe PreparedStatement de l’API JDBC, ce qui facilite la formulation des requêtes SQL.

Vue

Les pages JSP ont été créées à l’aide des librairies de tags de Struts (struts-bean.tld, struts-html.tld et struts-logic.tld). Les graphiques ont été créés à partir des classes et de la librairie de tags de Cewolf (cewolf.tld). Cewolf est une solution open source qui permet d’intégrer des graphiques de toutes sortes aux pages JSP. Le développeur doit simplement créer un objet qui implémente la classe de.laures.cewolf.DatasetProducer. Cet objet produit les données du graphique et les sauvegarde dans la session de l’utilisateur. Dans la page JSP, on utilise un des tags de la librairie de Cewolf pour transformer les données en un tag HTML qui pourra être interprété par le navigateur de l’utilisateur.

Fichiers de configuration et fichiers ressources

Project Online possède ses fichiers de configuration web.xml et struts-config.xml. Le fichier web.xml se trouve dans le répertoire WEB-INF de l’application alors que le fichier struts-config.xml se trouve dans le répertoire WEB-INF/config. Les fichiers ressources ViewText_en.properties et ViewText_fr.properties se trouvent dans le répertoire WEB-INF/classes/struts/project/resources.

Utilitaires

Les classes BeanUtilities et FormUtilites du paquet util ont été développées par Vincent Dussault, l’assistant de M. Ridjanovic. La classe BeanUtilities contient la méthode copyProperties qui permet de copier automatiquement les propriétés d’un bean de formulaire dans un bean de modèle et vice-versa. La classe FormUtilities fournit, quant à elle, plusieurs méthodes qui facilitent la validation des formulaires HTML.

Serveur

Le développement de Project Online s’est effectué à l’aide du serveur open source Tomcat. Ce serveur joue le rôle à la fois de serveur Web et de serveur d’applications pour les pages JSP et les Servlets.

Améliorations possibles de Project Online

L’application Project Online pourra éventuellement bénéficier de certaines améliorations. Voici quelques-unes des améliorations à envisager :

1. Le modèle de données actuel ne permet pas de subdiviser les tâches en sous-tâches. On pourrait le modifier pour donner au gestionnaire de projet plus de flexibilité dans la façon de structurer le projet.
2. Le modèle de données actuel ne permet pas de savoir exactement combien d’heures ont été consacrées à une tâche en particulier sur une base journalière, hebdomadaire ou mensuelle. On pourrait modifier le modèle de données afin de fournir plus d’informations au gestionnaire de projet au sujet de l’occupation de ses ressources.
3. L’objectif d’éliminer complètement le code Java des pages JSP n’a pas été complètement atteint avec la version actuelle de Project Online. On pourrait évaluer la possibilité de remplacer le code Java par des tags de la librairie Tiles ou par des tags personnalisés.
4. Il existe présentement une certaine redondance entre les classes Action de la partie contrôleur de l’application. Par exemple, le même code est utilisé dans toutes les classes de type Action pour vérifier si l’utilisateur s’est déjà identifié dans la page login. Pour éviter cette redondance qui rend l’application plus difficile à comprendre et à maintenir, on pourrait créer une classe Action principale dont hériteraient les classes Action spécifiques.

Conclusion

Pour conclure cet essai, nous allons revenir sur les deux problématiques que nous avons déjà énoncées, à savoir : Comment le framework Struts facilite-t-il le travail du développeur d’applications Web ? Est-il possible de réaliser une application Web de qualité uniquement à l’aide de composants open source et gratuits ?

La réalisation de Project Online nous a permis de mieux comprendre le fonctionnement de Struts et de constater tous les avantages que représente l’utilisation d’un tel framework dans la réalisation d’une application Web. Cependant, nous sommes d’avis que l’effort (et le temps) nécessaire pour apprendre à utiliser le framework Struts n’est pas nécessairement justifié dans toutes les situations. La décision d’utiliser Struts devrait dépendre de différents facteurs comme la compétence et la taille de l’équipe de développement, la complexité et la taille de l’application à développer, la possibilité de réutiliser le framework pour développer d’autres applications, etc. Plus les membres d’une équipe de développement sont compétents et nombreux, plus ils bénéficieront de l’utilisation de Struts. De même, plus l’application à développer est complexe et de grande taille, plus l’utilisation de Struts s’avèrera judicieuse. Enfin, plus les possibilités de réutiliser Struts sont grandes, plus il vaudra la peine d’investir dans l’apprentissage de Struts. Autrement dit, si on réalise une petite application simple, l’utilisation de Struts n’est peut être pas justifiée. Par contre, il faut considérer dans notre décision qu’une petite application développée selon l’architecture MVC est toujours plus facile à faire évoluer qu’une application qui ne l’est pas.

En ce qui concerne notre deuxième problématique, la réalisation de Project Online nous a permis de constater que l’approche de développement open source est tout à fait viable, et même très souhaitable, car elle permet d’améliorer grandement la qualité, la rapidité et les coûts du développement d’applications Web. On peut en effet affirmer qu’il aurait été impossible de réaliser une application comme Project Online dans le temps alloué sans avoir accès aux classes de Struts, de Cewolf et de M. Ridjanovic. Notre expérience nous a permis, en outre, de constater que les composants open source sont d’excellente qualité et très bien documentés. Le support offert par les communautés de développement est, lui aussi, d’excellente qualité et très rapide.

Nous pouvons donc conclure en disant qu’une approche de développement fondée sur le framework Struts combiné à d’autres composants open source est garante d’une application Web de qualité réalisée plus rapidement et plus économiquement.

Références

Frameworks

• Leveraging Object-Oriented Frameworks, IBM white paper, 1993.
• Fayad, Mohamed et Douglas C. Schmidt, Object-Oriented Application Frameworks, Communications at the ACM, octobre 1997.
• Rosenthal, Arnon et Eric Hughes, What is an Application Framework?, www.mitre.org, mai 1997.

Modèle MVC

Seshadri, Govind, Understanding Java Server Pages Model 2 Architecture, JavaWorld.com, décembre 1999.

Struts

• Buisine, Arnaud, Struts, vous avez dit Struts?, [1], janvier 2002.
• Davis, Malcolm G., Struts, an open-source MVC implementation, [2], février 2001.
• Ford, Neil, Strutting Your Stuff, [3], 2002.
• Husted, Ted, Is Struts Performant?, [4].
• Jones, Kevin, Create Better Web Apps with Struts, [5]
• Kochmer, Casey, An Introduction to Struts, [6], avril 2001.
• Rusli, Harry et John Yu, Issues in Struts Adoption, [7], juillet 2002.
• Spielman, Sue, Introduction to Jakarta Struts Framework, [8], septembre 2001.
• Jakarta Struts : [9]
• Struts User’s Guide : [10]

Open Source Projects

• Site Cewolf : [11]
• Jakarta Project : [12]
• Jakarta Velocity : [13]
• Tiles : [14]

Servlets et Java Server Pages

Hall, Marty, Core Servlets and Java Server Pages, Sun Microsystems Press, PrenticeHall, 2000.

• Site officiel JSP : [15]
• Site officiel Servlet : [16]

Base de données

• Site MySQL : [17]
• Pilote JDBC : [18]

Serveur

• Site Tomcat : [19]

Annexes

Figure 6. Page de login

Figure 7. Page d’accueil du gestionnaire de projet

Figure 8. Ajouter un message

Figure 9. Ajouter un problème

Figure 10. Ajouter une tâche

Figure 11. Graphique des problèmes par priorité

Figure 12. Rapport des problèmes

Commentaires

Évaluation

Sur une échelle de 0 à 5, cet article est :

• Utile : 5
• Intéressant : 5
• Facile à comprendre : 5
• Bien rédigé : 5
• Complet : 5

Collaborateurs

Véro

Traduction

Haut de la page