Mémoire de fin d'études ESIEA - Freerastasia.free.fr/public/rapport final RKhounsamnane.pdf · Mémoire de fin d'études ESIEA Développement de modules pour un portail pour clubs

Nom : Khounsamnane RémiPromotion : 2006

Société : Ippon TechnologiesDate : Du 06/02/2006 au 31/10/2006

Mémoire de fin d'études ESIEA

Développement de modules pour un portail pour clubs sportifs

Technologies :

Java / J2EE, Struts, Spring, Hibernate, Portlet, Liferay.

Date de soutenance :Composition du jury :Maître de stage : Tuteur :

Bertrand Pinel Michel Futtersack

Mémoire de fin d'études ESIEA 1/48 Ecrit par Rémi Khounsamnane


Table des matièresIntroduction.......................................................................................................................................... 5Résumé................................................................................................................................................. 6Executive summary.............................................................................................................................. 7I.Présentation de l’entreprise................................................................................................................ 8

Le secteur d'activité.....................................................................................................................8L'entreprise..................................................................................................................................9Le service.................................................................................................................................. 11Positionnement du stage dans les travaux de l'entreprise......................................................... 12

II.Stadup............................................................................................................................................. 131.L’origine du projet...................................................................................................................... 13

Les clients................................................................................................................................. 13Le modèle économique............................................................................................................. 13

2.Présentation de la solution.......................................................................................................... 14Les principaux avantages.......................................................................................................... 14Les fonctionnalités.................................................................................................................... 14

3.L’équipe...................................................................................................................................... 17III.Les technologies de Stadup........................................................................................................... 18

4.Architecture logique................................................................................................................... 18Vue générale............................................................................................................................. 18

5.Description des composants logiques......................................................................................... 19Serveur d’application................................................................................................................ 19Couche métier J2EE..................................................................................................................19Conteneur de portlets................................................................................................................ 19Moteur de portlets..................................................................................................................... 19

6.Architecture applicative..............................................................................................................20Vue générale............................................................................................................................. 20

7.Description des composants applicatifs......................................................................................20Tomcat...................................................................................................................................... 20Spring / Hibernate et Struts.......................................................................................................20Xdoclets et Ant .........................................................................................................................23Appfuse..................................................................................................................................... 23Liferay.......................................................................................................................................23

8.Environnement de travail............................................................................................................25IV.Travail effectué............................................................................................................................. 26

9.Migrations...................................................................................................................................26Migration de l’architecture Liferay...........................................................................................27Migration d'Appfuse................................................................................................................. 28

10.Développement de fonctionnalités............................................................................................29Explications préliminaires sur les membres et les rôles de Stadup...........................................29Développement de l'interface admin.........................................................................................30Développement de la portlet SonsEntity...................................................................................33Mise à jour des tests unitaires................................................................................................... 39Développement de la portlet correspondance........................................................................... 41Rédaction de documentation.....................................................................................................45Mise en production....................................................................................................................46Résolution de bogues................................................................................................................ 47

11.Interprétation et critique des résultats.......................................................................................48Conclusion générale........................................................................................................................... 49


Bibliographie...................................................................................................................................... 50Annexes.............................................................................................................................................. 51


Introduction

Ce rapport présente l’ensemble des travaux que j’ai réalisé dans la société IPPON Technologies au cours de mon stage de fin d’études réalisé dans le cadre de ma cinquième année de cursus à l'ESIEA.

Je tiens tout d’abord à remercier l’ensemble du personnel d’IPPON Technologies pour l’accueil et la disponibilité dont ils ont fait preuve durant mes six mois de stage. Ces remerciements sont plus particulièrement dirigés vers la personne qui a le plus participé au bon déroulement de mon stage, tant au niveau technique que fonctionnel, Arthur Clément.

Comme nous allons le voir, la société IPPON Technologies possède deux grandes dominantes : d'une part elle est spécialisée dans le domaine des technologies Java/J2EE, d'autre part elle est née et s'est développée en gardant un esprit lié au monde sportif.

C'est l'association de ces deux impulsions qui a provoqué la création du projet Stadup sur lequel j'ai travaillé durant toute ma période de stage.

Dans un premier temps, nous verrons le secteur d’activité ainsi que le service proposé par l’entreprise IPPON Technologies. Puis nous étudierons en détail les spécificités du projet Stadup auquel j’ai pris part. Enfin nous analyserons les travaux que j’ai réalisé sur le projet Stadup durant ma période de stage.


Résumé

J’ai effectué mon stage de fin d’études dans la société IPPON Technologies. Ce stage de neuf mois m'a permis de valider l’ensemble de mon cursus effectué à l'ESIEA.

IPPON Technologies est une jeune société de services en ingénierie informatique spécialisée dans les technologies Java / J2EE (Java 2 Platform, Enterprise Edition) créée par un ancien sportif de haut niveau.

Parallèlement l'entreprise a choisi de diversifier quelque peu son domaine d'activité avec le développement de logiciel. C'est par le biais de la société Stadango et de son logiciel Stadup que cette activité a débuté.

Le but de ce stage fut la conception et la réalisation de nouvelles fonctionnalités sur le projet Stadup ainsi qu’un travail de migration du principal outil sur lequel se base Stadup : Liferay.

Stadup a été imaginé dans un contexte de développement des outils de gestion des clubs de sport afin de simplifier et de rendre plus efficace la gestion des activités sportives. Ce projet répond ainsi à la demande croissante en matière d’outils informatiques modernes.

Au niveau technique, Stadup est entièrement basé sur le modèle d’architecture J2EE n-tiers. Le projet s’appuie sur trois Frameworks principaux : Struts, Spring et Hibernate.

Mes travaux sur le projet Stadup se sont organisés autour de deux axes principaux : les migrations et le développement de nouvelles fonctionnalités.

J'y ai effectué différentes taches :

– Résolutions de bogues

– Développement de l'interface Admin

– Migrations des bases Open Source

– Développement de la Portlet « Entités dépendantes »

– Rédaction de documentations

– Les tests Unitaires

– Développement de la portlet Correspondance

Tous les travaux et développements qui m’ont été assignés lors de ce stage ont été menés à bien. Cependant certains problèmes ont entraîné des retards dans la réalisation de mes tâches :

– Le manque quasi total de documentation sur le portail Liferay.

– Très peu de documentation existe sur le projet au niveau de Stadup même.

Ce projet m'a tout de même permis d'appréhender de façon concrète les technologies J2EE ainsi que les nombreux Frameworks gravitant autour et s'est ainsi révélé être une expérience très enrichissante, tant au niveau fonctionnel que technique.


Executive summary

I did my last degrees internship in a computer service company called IPPON Technologies. This nine month internship has made me graduate my whole curriculum in ESIEA.

IPPON Technologies is a young company which is specialized in Java / J2EE started up by an ex-professional sportsman.

At the same time, the company choose to diversify their activities with software development. It is through Stadango (which is own by them) company and Stadup that they did it.

The purpose of this internship was new features conception and development of Stadup.

Stadup has been created through the Sport's clubs needs. It would simplify club management.

Stadup has a rich technical environnement based on the J2EE n-tiers architecture. This project hangs on three main frameworks : Hibernate, Spring and Struts.

My work has been led by two main direction :migration and development.

I have achieved differents things :

– Bugs solving

– Admin interface development

– Migration of the Open Source tools

– « SonsEntity » portlet development

– Docs writing

– Units Tests

– « Correspondance » portlet development

All tasks I had were led to success. However, certain problems has led to lateness in my planning :

– Lack of docs for Liferay Portal

– Lack of docs for Stadup itself

This project has finally made me learn J2EE technology as well as good frameworks which come with. It was a very rewarding experience in technical improvement and also in Parctical skills.


I. Présentation de l’entreprise

Le secteur d'activité

IPPON Technologies est une société de services en ingénierie informatique (SSII) intervenant dans des domaines très divers, les principaux étant l'informatique, l'industrie, les télécommunications, les services et la finance. Elle possède des clients prestigieux au regard de son jeune âge dans tous ces secteurs d'activité.

Cependant l'arrivée récente d'un nouveau directeur commercial tend à spécialiser l'entreprise dans le secteur bancaire.

Services financiers8%

Editeurs13%

Intégrateurs41%

SSII16%

Transport5%

Tourisme10%

Autre industrie7%

Figure 1 : Parts d'activité d'IPPON Technologies dans les différents secteurs


INDUSTRIE BANQUE-ASSURANCE DISTRIBUTION SERVICE

PROFESSIONNEL DE L’INFORMATIQUE

TELECOMMUNICATION

CEA

Renault

EDF

Groupe INEO

Groupe Vinci

Thales

Promotelec

Schlumberger

L’Oréal

SPEIG

BMW

RATP

BNP-Paribas

Crédit Lyonnais

Société Générale

AXA

Brico-Dépôt

Carrefour

Voyages SNCF

Club Méditerranée

Accenture

CSC

IBM

Silicomp

Fimasys

Cap Gemini

AGDF

Stadango

AT&T

Bouygues Télécom

France Télécom

Orange

Nokia

Cegetel

Webraska

Figure 2 : Clients d'IPPON Technologies classés par secteur d'activité

IPPON Technologies assure le suivi client sous deux formes : en forfait et en régie. En 2005, entre 10 et 15% des contrats étaient en forfait. En 2006 le forfait représente déjà 40% du chiffre d'affaires. Le but de l'entreprise est d'avoir 50% des contrats en forfait et 50% en régie.

L'entreprise

IPPON Technologies est une jeune SSII fondée en 2002 par Stéphane Nomis, ancien sportif de haut niveau, et Bertrand Pinel, architecte J2EE.

D'abord créée sous forme de SARL avec trois personnes à son actif, IPPON Technologies est maintenant une SAS au capital de 60 000 Euros.

En moins de quatre ans et malgré sa création en pleine crise de la bulle Internet, IPPON Technologies a réussi à atteindre un chiffre d'affaires de près de 3,9 millions d’Euros pour 2005 et à obtenir des résultats positifs dès le premier exercice.

Elle emploie actuellement 70 personnes en CDI dont des ingénieurs d'étude, des experts, des chefs de projet ainsi que des architectes.


Les prévisions 2006 tablent sur un chiffre d'affaires de 5,8 millions d’Euros avec un effectif

de 85 salariés, soit plus de 65% de croissance depuis ses débuts.

La croissance de l'entreprise est en constante hausse, ce qui entraîne une forte politique de recrutement.


PrésidentS. Nomis

DAFB. de Gaudusson

DirecteurCommercial

G. Gruel

DirecteurTechnique

B. Pinel

Directeur GénéralDélégué G. Gruel

Assistantede Gestion

K. Belda

JuridiqueLPA

RessourcesHumaines

E. Pruvost

ComptabilitéCabinet Koskas

Mkt & CommL. SaussereauC. Desassis

RecrutementL. SaussereauC. Desassis

CommercialD. Touati

Commercial jr

G. Fournel

Téléprospecteurs

Projets Clients

Consultants

Projets Clients

Sous-traitantsCommunication

Découpages

Projets

internesEquipe Stadup

Formation

Autres projets

Figure 3 : Organigramme de l'entreprise

3100

5800

3500

1600

300

50

85

40

25

10

0

1000

2000

3000

4000

5000

6000

7000

2002 2003 2004 2005 20060

10

20

30

40

50

60

70

80

90

Chiffre d'affaires Effectifs

Figure 4 : Evolution de l'entreprise depuis sa création

Le service

IPPON Technologies est tout d'abord une société de services informatiques spécialisée dans l'architecture distribuée. Son secteur d'activité est entièrement concentré autour des technologies J2EE (Java 2 Platform, Enterprise Edition) de Sun associées à l'utilisation de nombreux Frameworks tels que Struts, Spring, Hibernate, Appfuse...

IPPON Technologies assure alors le conseil, l'expertise, la conception, le design, le développement, l'intégration, la maintenance ainsi que l'administration d'applications J2EE.

Cependant tous ces services sont dans un domaine très concurrentiel en raison du nombre important de sociétés de services qui ont une offre comparable. Pour se démarquer, IPPON Technologies a fait le choix d'une niche technologique, le J2EE, ce qui lui permet de réellement se différencier et de proposer un service optimum.

Parallèlement, l'entreprise a choisi un autre domaine d'activité, le développement de logiciel. C'est par le biais de la société Stadango, présentée par la suite, que cette activité a débuté.


Positionnement du stage dans les travaux de l'entreprise

C’est dans cette dernière activité, le développement de logiciel, que mon stage a pris place. Durant mes neuf mois de stage dans la société IPPON Technologies, j’ai travaillé à l’ajout de fonctionnalités ainsi qu’à l’amélioration de l’application Stadup distribuée par Stadango.

Ce projet fait office de vitrine technologique pour IPPON Technologies tant au niveau de l’expertise J2EE qu’au niveau de Liferay.

Ce projet démontre également toute l’implication de l’entreprise dans le domaine sportif, puisque, comme nous allons le voir, il est avant tout destiné à être utilisé par des fédérations sportives.

IPPON Technologies a, dans de nombreux cas, pour ambition de recruter des étudiants réalisant leur stage de fin d’études dans le but de leur proposer ensuite une embauche. Les technologies J2EE étant rarement approfondies dans les cursus scolaires, cette méthode permet à l’entreprise de former ses futurs collaborateurs potentiels au J2EE et aux outils particuliers utilisés dans la société.

Dans ce contexte, Stadup fait également office de plateforme d’apprentissage pour de nombreux stagiaires dans l’entreprise et permet d’appréhender les nombreux mécanismes intervenant dans l’utilisation des Frameworks J2EE et, surtout, du portail très couramment utilisé dans l’entreprise, Liferay.


II.Stadup

1. L’origine du projet

Stadango est une société d'édition de logiciels qui a été créée par Stéphane Nomis, PDG d'Ippon Technologies, et qui s’occupe de la distribution de Stadup.

Stadup a été imaginé dans un contexte de développement des outils de gestion des clubs de sport, afin de simplifier et de rendre plus efficace la gestion des activités sportives. Stadup répond ainsi à la demande croissante en matière d’outils informatiques modernes.

La volonté de créer un outil pour les sportifs s'est naturellement couplée à des partenariats avec des clubs et des associations sportives, de manière à créer un logiciel adapté aux besoins des licenciés et des fédérations.

Stadup, premier logiciel de Stadango, a pour but de simplifier la vie quotidienne des fédérations sportives, des clubs et de leurs licenciés. Stadup s’articule autour de plusieurs modules, qui concernent aussi bien la gestion sportive et administrative, que la communication ou encore la réservation en ligne.

Les clients

Les principaux clients de Stadango sont les ligues sportives. Actuellement, 8 ligues en Ile-de-France ont signé pour l’utilisation de Stadup, soit près de 100 000 licenciés. En parallèle, quelques clubs ont été séduits, en Guadeloupe, Corse ou Nouvelle-Calédonie.

Développé avant tout pour les judokas, Stadup a néanmoins été présenté aux autres fédérations sportives. Malgré leur enthousiasme, la plupart d’entre elles demandent des fonctionnalités très spécifiques au sport représenté, notamment en ce qui concerne la fiche du membre.

Des fédérations telles que la FFF (football), la FFR (rugby), la FFG (golf) bénéficient déjà d’un outil créé spécifiquement pour leurs besoins, et ne sont donc, pour l’instant, pas intéressées par cette solution.

Le modèle économique

Le modèle économique de Stadango est basé sur une location de son produit en fonction du nombre d’adhérent du club intéressé, ainsi que sur un couplage avec une boutique de vente en ligne générant un revenu à la fois pour le club et pour Stadango.

Le prix de base de Stadup est simple : 1 euro par adhérent. Ce tarif étant dégressif, il peut tomber à 25 centimes dans le cas d’un club de plus de 500 adhérents.


Mais l’intérêt principal réside dans la boutique de vente en ligne. En effet, une publicité omniprésente sur le site de Stadup présente aux utilisateurs des produits liés à la pratique sportive, en vente sur la boutique. Les bénéfices engendrés par les ventes faites par ces utilisateurs sont ensuite répartis entre Stadango et le club auquel appartient cet utilisateur. Ce type de fonctionnement incite fortement les fédérations et les clubs à utiliser ce logiciel puisqu’ils peuvent, si le nombre de vente est suffisant, générer un profit non négligeable en plus de rembourser la location sans débourser le moindre centime. Tous les acteurs du système sont gagnants.

2. Présentation de la solution

Les principaux avantages

Stadup, application Web développée par IPPON Technologies, bénéficie de toute l’expertise de l’entreprise dans le domaine J2EE. Il offre de nombreux avantages pour les clubs comme pour les licenciés.

• Il est accessible au plus grand nombre de par sa nature d’application Web : un ordinateur et une connexion Internet suffisent.

• La plupart des fonctionnalités facilitent la communication et permettent de tisser un lien entre les différentes entités depuis la fédération jusqu'aux adhérents.

• Stadup est une solution toute inclue fournie par Stadango. Ce dernier s’occupe ainsi de l’hébergement et les mises à jour sont effectuées automatiquement et gratuitement.

• Selon les besoins d’une fédération, des développements spécifiques au niveau de l’interface ou du comportement du logiciel peuvent être effectués.

Les fonctionnalités

La principale fonctionnalité de Stadup est la communication entre les différentes entités composant une fédération sportive.

• Les entités peuvent dialoguer très facilement grâce à des mailing listes accessibles par de nombreux liens présents dans l'application.

• Les actualités sont présentées par rubriques. Certaines permettent aux entités de

poster une actualité pour l'ensemble des entités sous-jacentes.


Adhérent Club FédérationDéparte-ment Région Inter

régions

Figure 5 : Organisation des différentes entités d'une fédération sportive

• Le forum est accessible à tous, de l'adhérent jusqu'au membre de la fédération, et des rubriques permettent à chacun de dialoguer avec son entité ou avec n'importe quel utilisateur de Stadup.

Stadup a pour but d'impliquer davantage les adhérents dans la vie du club, de manière à ce que cette implication se ressente dans la pratique de leur sport.

La plupart des modules proposés par Stadup sont tournés vers la gestion de club :

• liste des membres et informations sur les membres ;

• gestion du personnel du club (ou plus généralement de l'entité) ;

• statistiques des équipes, des entraînements de chaque équipe, des stages d'entraînement de chaque équipe, des finances du club, des ressources matérielles du club.

Stadup se découpe en un ensemble de portlets qui correspondent chacune à une fonctionnalité particulière dont voici le détail (le concept de portlet est détaillé dans la partie architecture) :

• Actualités : Cette portlet permet la communication entre les différentes entités intégrées dans la hiérarchie des fédérations. Les dernières actualités au niveau de la fédération seront par exemple accessibles à tous les membres de la fédération, tandis que les actualités concernant la vie du club ne seront accessibles qu'aux membres de ce club.

• Calendrier : Le calendrier permet de rappeler les événements importants de la vie du club et de la fédération. Chaque utilisateur possède un calendrier personnalisé affichant ses entraînements, stages et autres compétitions.

• Recherche : Cette portlet permet de faire une recherche sur l'ensemble du portail, tant au niveau des actualités, des membres que des ressources.

• Information club : Information club est une petite portlet permettant aux dirigeants des clubs de faire passer un court message d'une ou deux phrases à tous leurs licenciés.

• Pratique : La pratique a pour objectif de faciliter la vie des usagers de Stadup en offrant divers services comme la météo, ou encore un point sur le trafic routier.

• Membre : Cette portlet permet aux dirigeants des clubs de gérer leurs membres et les informations les concernant. Ils peuvent ajouter de nouveaux membres, les renouveler lors des changements de saison, contrôler s'ils ont payé leurs cotisations, etc.

• Statistiques : La portlet Statistiques affiche une série de statistiques concernant le club. Elle propose également de créer des graphiques à l'aide d'outils, en fonction de critères prédéterminés comme l'âge des licenciés ou la discipline sportive. Chaque club a donc la possibilité de connaître des


informations précises en fonction de ses propres besoins.

• Gestion du bureau : La gestion du bureau permet l'assignation de certains membres du club à des rôles spécifiques, chacun de ces rôles offrant des droits supplémentaires aux membres en question. Citons à titre d’exemple le rôle de trésorier qui donne des droits sur la portlet Finances.

• Administration du club : Cette portlet est la plus complète du portail. Elle concerne le club dans son ensemble et fournie la carte d'identité du club en affichant les informations du club concerné : son adresse, logo, les inscriptions récentes avec la possibilité de les accepter ou de les refuser, la définition des prix de la licence et la création de différents packs (licence + kimono, etc.), ces packs étant ensuite disponibles lors de l'inscription d'un nouveau membre, les différents partenariats avec des intervenants extérieurs ou des sponsors. C’est également dans cette portlet que s’opère la gestion des différents stages proposés aux licenciés.

• Cours/Entraînements : Cette portlet permet de créer différents groupes d'entraînement et de leur attribuer des sessions à certains horaires et dates. La réservation des lieux d'entraînement est également effectuée pour éviter tout problème d'organisation interne.

• CMS (Content Management System) : La gestion des documents se fait uniquement au travers de cette portlet. Elle propose des options comme une chaîne de publication complète, un contrôle de version et des droits d'accès spécifiques pour chaque type d'utilisateur.

• Galerie d'images : Des images peuvent être partagées via la portlet Galerie d'images entre les utilisateurs de Stadup, les images y étant accessibles selon certaines restrictions choisies par leurs propriétaires.

• Finances : La portlet Finances propose un résumé des comptes du club. Elle comprend des fonctions basiques de comptabilité comme la gestion des comptes bancaires, un listing des transactions effectuées durant la saison et un suivi de l’historique des comptes.

• Forum : La communication entre les licenciés d'un même club se fait via cette portlet. Il s’agit d’un forum classique reprenant toutes les fonctionnalités courantes.

• Ressources : La portlet Ressources permet aux dirigeants du club d'établir un inventaire, de connaître des informations sur son état, sur les accessoires et autres matériels disponibles dans ce club.

• Équipes : Les différentes équipes mises en place pour les compétitions sont déterminées dans cette portlet. Chacune des équipes contient des encadrants et des compétiteurs.

• Enregistrement club/Enregistrement membre : Il s’agit du portlet d'inscription des utilisateurs et des nouveaux clubs à Stadup. Elle débute par un assistant demandant toutes les informations nécessaires et effectue une inscription soumise à validation par un tiers.

• Mail : La portlet Mail est accessible depuis n'importe quelle page du site et permet la rédaction et l'envoi d'un e-mail aux membres de Stadup.


3. L’équipe

Figure 6 : Organigramme de l'équipe Stadup

Les développeurs du projet sont, tout comme moi, des stagiaires en fin d’études d’écoles d’ingénieurs en informatique.

Le chef de projet, Arthur Clément, fut pour toute l’équipe une source régulière d’aide et de conseil. Il dispose d'un excellent niveau technique et d'une connaissance approfondie de l'architecture mise en place pour Stadup. Il s'est donc chargé d'assister notre formation en plus d'assurer la bonne continuité du développement.

Il n’a cependant pas été notre seul soutien et formateur. Tous les professionnels d'Ippon Technologies se sont avérés attentifs à chacune de nos interrogations, tant lors de notre formation J2EE que dans l'évolution de notre travail sur Stadup.


Directeur techniqueB. Pinel

DéveloppeurB. de La Jugannière

DéveloppeurF. Charles

DéveloppeurR. Kouhnsamname

DéveloppeurN. Girot

Chef de projetA. Clément

III.Les technologies de Stadup

Comme nous l’avons vu, Stadup est une application Web entièrement basée sur les technologies J2EE. Nous allons étudier l'architecture du projet de façon logique d'une part et de façon applicative d'autre part.

4. Architecture logique

Vue générale

Figure 7 : Architecture logique du proje


Serveur d’Application

Couche Service J2EE

Conteneur de Portlet(JSR 168)

Moteur de Portlet

Portlet n … Portlet 1

Utilisateur

5. Description des composants logiques

Serveur d’application

Le serveur d'application joue ici le rôle d'hébergeur logique. En effet, tous les autres composants sont déployés en son sein. Son rôle est donc déterminant et il se doit de supporter les normes des différents éléments logiques qui y seront déployés.

Couche métier J2EE

La couche métier J2EE est le lien vers la base de données. Sur une architecture correctement définie, tout accès vers une base de données se fait via une couche dite « Business Delegate » qui elle-même accède à une couche « DAO » ou « Data Access Object Layer ». Cela permet de rationaliser les accès aux données en rendant abstrait le mécanisme de récupération des données. Les « Business Delegate » servent de façade.

Conteneur de portlets

Une portlet est un élément responsable d’un fragment du contenu spécifique de chaque page. Le conteneur représente le composant du portail qui fait office de socle d'exécution des portlets. Il est préférable qu'il respecte la norme JSR168, fournie par Sun, seul le respect de cette norme pouvant garantir la future portabilité du composant ainsi développé vers une autre plateforme.

Moteur de portlets

Le moteur, quant à lui, est le coeur du portail, c'est-à-dire qu'il en assure les fonctions essentielles :

• Agrégation des contenus en provenance des différentes portlets ;

• Gestion des rôles utilisateurs en terme de configuration de l'affichage ;

• Personnalisation du rendu global.


6. Architecture applicative

Vue générale

7. Description des composants applicatifs

Tomcat

Tomcat est un serveur d’application open source qui agit comme un conteneur de servlets J2EE. Il implémente les spécifications des servlets et des JSP (Java Server Pages) de Sun et utilise le compilateur Jasper pour convertir les JSP en servlets. Tomcat est lui même une servlet, donc un programme Java tournant sur un serveur et gérant d'autres servlets et JSP.

Spring / Hibernate et Struts


TOMCAT

Spring / Hibernate

Liferay

Struts

Portlet n … Portlet 1

Utilisateur

Figure 8 : Architecture applicative du projet

Stadup est entièrement basé sur le modèle d’architecture J2EE 3 tiers. La plateforme J2EE propose un ensemble de concepts et de spécifications permettant la résolution de problématiques de développement, le déploiement et la gestion d’applications serveur multi-tiers. Une architecture 3 tiers signifie que l’architecture du logiciel peut être séparée en trois parties principales :

• La partie cliente : il s’agit dans le cas de Stadup d’un client léger, un navigateur Web ;

• La partie serveur : elle est représentée par le serveur d’application qui reçoit les requêtes clientes et exécute le programme pour répondre en conséquence.

La partie stockage des données : il s’agit de la base de données qui stocke les informations.

Figure 9 : Visualisation de l'architecture 3 tiers

Les couches J2EE s'appuient essentiellement sur les frameworks Spring, Hibernate et Struts.

Spring est le composant qui joue le rôle de « Business Delegate Layer ». Il prend en charge la création d'objets et la mise en relation d'objets par l'intermédiaire d'un fichier de configuration qui décrit les objets à fabriquer et les relations de dépendances entre ces objets.

Hibernate est un framework de persistance. Il représente l'aspect « DAO Layer ». Il s'occupe du transfert des classes Java dans les tables de la base de données (et des types de données Java dans les types de données SQL). L'accès aux données réelles de la base de données se fait par l'intermédiaire de « VO » ou Values Objects qui sont des classes métiers correspondant aux tables de la base.

Hibernate permet également de réaliser des requêtes sur les données et propose des moyens de les récupérer. Il peut donc réduire de manière significative le temps de développement qui aurait été dépensé autrement dans une manipulation des données par accès direct à l'API JDBC. En effet grâce à Hibernate, les appels JDBC sont encapsulés et effectués de manière transparente.


Navigateur Web Serveur d’application

Base de données

Client Serveur Persistance

Requêtes HTTP

HTML ou Données

SQL

Données

Figure 10 : Visualisation de l'architecture 3 tiers

Struts est un framework J2EE dédié à la gestion de l'interaction Homme/Machine dans les applications Internet. Il propose de construire des applications respectant le modèle d'architecture MVC (Modèle - Vue - Contrôleur).

Le Modèle représente le comportement de l'application avec le traitement des données, les interactions avec la base de données. Il décrit les données manipulées par l'application (VO) et définit les méthodes d'accès (DAO). Pour la communication entre les VO et Struts, ainsi qu'Hibernate, on utilise des Xdoclets.

La Vue correspond à l'interface Homme/Machine. Elle met en forme les données renvoyées par le modèle, que sont par exemple les pages JSP utilisées dans Stadup. La Vue n'effectue aucun traitement, elle se contente d'afficher les résultats des traitements effectués par le Modèle.

Le Contrôleur prend en charge la gestion des événements de synchronisation pour mettre à jour la Vue ou le Modèle. Il n'effectue aucun traitement, ne modifie aucune donnée ; il analyse la requête du client et se contente d'appeler le Modèle adéquat et de renvoyer la Vue correspondant à la demande.

Assurance de l'intégrité des données Métier

L'accès et la manipulation des données s'effectuent exclusivement par l'intermédiaire de la couche Service. Cette couche, qui s'appuie sur le framework Spring, est l'unique point d'accès aux données pour le reste de l'application.

Ce modèle permet d'obtenir une encapsulation des traitements Métier indépendants du modèle physique et des contrôles transactionnels. Cette encapsulation assure l'indépendance avec la couche de persistance proprement dite, permet de centraliser les contrôles et de se prémunir ainsi d'éventuels oublis dans le reste du code.

Par exemple, la suppression d'un membre dans Stadup entraîne la modification ou la


MODELE

VUE CONTROLEUR

Méthodes invoquées

Evénements

UTILISATEUR

Figure 11 : Visualisation de l'architecture MVC

suppression de multiples objets (groupes, membres, entités) et c'est la couche Service qui est garante de ce mécanisme.

Généralement la couche Service est directement utilisée par la couche Présentation, c'est-à-dire des portlets, si aucune validation n'est nécessaire.

Xdoclets et Ant

Deux principaux outils sont utilisés dans le développement de Stadup : les Xdoclets et Ant.

Xdoclet est un outil de génération de texte et, plus particulièrement, de code en ajoutant aux fichiers sources des balises de type Javadoc spécifiques. Cela permet, dans le cas de l'utilisation d'Hibernate, de générer des fichiers de relation entre la base de données et les VO.

Ant, quant à lui, est un outil visant à automatiser les tâches répétitives intervenant tout au long du cycle de développement d'un logiciel. Il est souvent utilisé dans le cadre de Stadup pour réaliser des compilations. Cet outil s'appuie sur des scripts écrits dans un langage proche du XML.

Appfuse

Appfuse est une sorte de « super-framework » qui fournit un environnement hiérarchisé complet permettant la mise en place rapide d’un projet J2EE comprenant Spring, Hibernate, Struts, Ant et Xdoclets. Il accélère le développement de la couche métier grâce à un système de génération de codes. Il contient tous les fichiers de configuration, les packages ainsi que tous les outils usuels comme les taglibs JSTL.

Liferay

Afin de garantir le bon fonctionnement de cette solution, un produit respectant rigoureusement la norme JSR- 168 fut choisi.

Ainsi le portail Open Source LifeRay (http://www.liferay.com) a semblé être la solution idéale dans le cadre du projet Stadup.

Ce portail, disponible en version 3.2 lors du lancement du projet, offre des fonctionnalités satisfaisantes, bénéficie d’une bonne notoriété, d’une importante communauté d’utilisateurs et repose sur une architecture moderne et évolutive.

Par ailleurs, il est livré avec de nombreuses portlets dont certaines sont des bases intéressantes pour une adaptation. Il est distribué sous une licence MIT, ce qui laisse beaucoup de liberté à l’intégrateur.

Cette solution bénéficie des avantages suivants :


http://www.liferay.com/

• Elle offre de base des possibilités de configuration à la fois en terme d’identité graphique et de contenu des pages.

• Elle offre un large choix de portlets dont certaines proposent des fonctionnalités proches de celles attendues dans Stadup.


8. Environnement de travail

L’environnement utilisé pour le développement du projet Stadup fait principalement intervenir deux outils : Eclipse et Subversion.

Eclipse est un Environnement de Développement Intégré (EDI ou IDE) qui est aujourd'hui une référence dans le monde du développement Java. Initialement développé par IBM, il est actuellement distribué gratuitement en open source. Sa particularité est son architecture basée sur des plug-in, ce qui permet l’ajout de fonctionnalités.

Enfin, un serveur Subversion (SVN) est utilisé pour la gestion des sources du projet. Il permet à chaque développeur d'être à tout moment synchronisé avec les sources des autres développeurs. C’est également un moyen performant pour sauvegarder les sources et en conserver l’historique.


IV.Travail effectué

Lors de mon arrivée sur le projet Stadup, une version final stable avait déjà été produit. Il était déjà utlisée par un club « beta-testeur » ainsi que par des clubs indépendants qui se sont inscrits spontanément via le site web.

Comme nous allons le voir, mes travaux sur le projet se sont organisés autour de deux axes principaux : les migrations et le développement de nouvelles fonctionnalités.

Les migrations concernent les outils sur lequel se base Stadup, Liferay et Appfuse.

S’agissant des nouvelles fonctionnalités, mes tâches furent très diversifiées mais toujours axées autour du sport, thème central de Stadup.

9. Migrations

Au début de ma période de stage, le projet Stadup reposait sur la version 3.2 de Liferay, version sur laquelle le projet avait débuté, aucune mise à jour n'ayant alors été effectuée. Néanmoins, la version 3.6 de Liferay était alors disponible, comportant de nombreux changements par rapport à la version 3.2, notamment au niveau de l'architecture.

Liferay étant couramment utilisé dans l'entreprise et Stadup étant pour elle une vitrine de son expertise quant à Liferay, il devenait urgent de songer à une migration du projet entier sur la dernière version de Liferay afin de bénéficier des nombreuses résolutions de bogues ainsi que des nouvelles fonctionnalités.

C'est ainsi qu'en prévision d'une migration prochaine, la première tâche que j'ai eu à réaliser sur le projet fut un thème reprenant l'interface actuelle de Stadup mais pour Liferay 3.6.

Mais lorsque la décision fut enfin prise de migrer toute l'architecture de Stadup sur la version 3.6 de Liferay, une version 4.0 était déjà en préparation et l'annonce de sa sortie était imminente.

Il apparaissait alors inutile de tenter une migration sur la version 3.6 tout en sachant qu’il faudrait la refaire ensuite sur la version 4.0. Les plans de migration furent donc changés et le développement continua dans l'attente de la sortie de Liferay 4.0.

La première version de Liferay 4.0 à sortir fut une RC (Release Candidate), et c'est sur la version 4.0 RC1 de Liferay que la migration de Stadup débuta.

Dans un projet informatique, la version RC signifie que le développement sur l'architecture et l'ajout de fonctionnalités étant terminés, cette version peut être mise à disposition du public. Les développeurs de cette version RC effectuent des tests intensifs et reçoivent des retours d'utilisateurs sur des bogues potentiels. Ces bogues sont alors éradiqués dans


la mesure du possible et, soit une nouvelle RC est réalisée, soit, si le logiciel n'a plus de problèmes majeurs, une version finale est mise à disposition.

On peut donc raisonnablement conclure qu'une version RC est identique à une version finale, les bogues en moins. C'est en partant de ce constat que la migration de Stadup sur la version 4.0 RC1 de Liferay a pu commencer.

Finalement chaque membre de l'équipe Stadup a travaillé sur cette migration et s'est occupé de migrer les portlets qui lui avaient été affectées.

Migration de l’architecture Liferay

L’application Stadup était jusqu’à présent gérée par le framework Liferay en version 3.2. Cependant, a version 4.0 est sortie corrigeant de nombreux bogues et ajoutant de nouvelles fonctionnalités.

La mission pour cette migration était donc d’étudier dans un premier temps les différences entre les deux versions. Cette étude montrant les points divergents avec l’architecture précédente des portlets mise en place.

Puis, en fonction des résultats précédents, il faut créer une procédure de migration décrivant étape par étape les modifications à apporter à chacune des portlets présentes.

Liferay fonctionne selon le principe des actions (décrit dans la partie architecture). Chaque action est liée à une méthode appartenant à la portlet et devant être exécutée, en concordance avec Struts.

Dans la nouvelle version de Liferay, il existe une distinction entre les actions ne servant qu’à la récupération et au traitement des données destinés à être affichées à l’utilisateur et les actions faisant intervenir des modifications de l’état du système. Ces types sont respectivement appelés Render et Action. Auparavant seules des Actions existaient au sein de Stadup.

Pour effectuer la migration, il a donc fallu, pour chacune des portlets existantes, déterminer quelles anciennes actions étaient des Renders ou des Actions. Et, bien entendu modifier l’architecture de la portlet en conséquence.

Il en est de même pour l’affichage des portlets : l’ancienne version limitait l’utilisation de l’espace disponible sur la page Web à uniquement deux colonnes. A présent, cette limitation n’existe plus puisqu’il est possible de créer son propre mode d’affichage des portlets à l’aide de simples templates fait en HTML. Cette modification a donc eu un impact majeur sur certaines portlets ne devant s’afficher qu’à certains moments en modifiant le type d’affichage général du site. Il a donc été nécessaire de recréer une méthode conforme à la nouvelle version pour les changements d’affichage.

De plus, l’architecture globale des portlets au sein de Stadup a également été modifiée. Auparavant, chaque portlet était séparée des autres et packagée dans des archives différentes. Cependant, au fur et à mesure des changements de version de l’application, de nombreuses interactions sont apparues entre différentes portlet. Ainsi, cette indépendance n’était plus respectée, et la séparation n’était plus justifiée. Plus encore, une portlet déployée seule sur le serveur pouvait ne pas fonctionner, ce qui est contradictoire avec la philosophie des archives J2EE. Toutes les portlets ont donc du être


regroupées en une seule archive, garantissant ainsi le bon fonctionnement de l’application et de tous ses composants.

Migration d'Appfuse

La migration d'Appfuse ne concernait que l'interface admin que j'ai développé. En effet, le fonctionnement de la couche métier n'avait pas été altéré par la mise à jour. C'est ainsi que je me suis occupé de cette migration seul. Le système d'authentification avait été revu ainsi que le système de menu. A cette époque là, une version stable de l'interface admin était terminée.

Ce travail a été long travail de recherche car personne dans le bureau n'était capable de m'aider. La documentation était présente mais peu nombreuse sur le sujet étant donnée la nouveauté de cette mise à jour.

Ce travail m'a permis de me confronter à une situation de recherche extrême : seul face à ma migration, personne à proximité pour m'aider. Il s'est composé en plusieurs étapes:

– Déterminer les nouvelles fonctionnalités : régler assez rapidement grâce au changeLog

– Déterminer où elles sont situées dans le code : il faut bien sûr au préalable faire quelques recherches sur ces nouvelles fonctionnalités

– Rechercher dans les documentations ou autres (ex : forum), le mode fonctionnement de ces fonctionnalités.

C'est ainsi que j'ai mené à bien cette tache et j'ai pu en retirer une méthodologie qui me semble optimale.


10.Développement de fonctionnalités

Explications préliminaires sur les membres et les rôles de Stadup

Tout d'abord, il faut savoir que Stadup se base sur la gestion des membres de Liferay pour gérer ses propres membres. Lorsque l'on ajoute un nouveau membre dans Stadup, un membre Liferay est alors créé qui est directement lié au nouveau membre Stadup.

Ce membre Liferay possède des informations très bas niveau sur ce nouvel utilisateur, telles que ses login et mot de passe pour accéder à l'application, la date de création du compte, la dernière fois que l'utilisateur s'est connecté, la langue qu'il utilise, etc.

Au niveau du membre Stadup, nous trouvons des informations beaucoup plus concrètes, telles que les nom et prénom de l'utilisateur, sa date de naissance, sa nationalité, ses mensurations, son adresse, etc.

D'un autre coté, nous avons les rôles de Stadup. Un rôle correspond globalement à une discipline. Chaque utilisateur enregistré dans l'application possède au minimum un rôle. Lorsque l'utilisateur s'inscrit, il doit obligatoirement choisir une discipline qu'il va exercer dans son club. Ensuite, il peut potentiellement ajouter d'autres disciplines à son profil, ce qui entraînera la création de nouveaux rôles.

Un rôle possède de nombreuses informations sur le membre et sa discipline correspondante, comme savoir s'il possède un certificat médical, s'il est surclassé dans cette discipline, à quelle catégorie il appartient, etc. (Le surclassement et les catégories sont expliqués dans la partie « notion de surclassement »).


☑Développement de l'interface admin

Cahier des charges

Lors de mon arrivée, Stadup possédait une interface admin relativement sommaire qui était implémenter dans l'application sous forme de portlet. Cette interface permettait d'administrer le strict minimum dans les besoins du moment. Le besoind'une interface admin solide fut donc emis.

Une interface faite en Appfuse pure avait été développé dans les débuts du projet mais fût laisser pour compte et était donc complétement obselète. Cette application géraient les objets métiers du début de Stadup : Au jour d'aujourd'hui, certains de ces objets n'étaient plus utilisés et au contraire, beaucoup de nouveaux objets avaient le besoin d'être administrés.

On me confia donc la tâche de remmettre cette interface d'aplomb pour en faire un outils d'administration de la base de donnée solide et complète.

Compte rendu d'activité

La première étape de mon travail fut de faire fonctionner correctement l'application. Ayant été développée dans une version antérieure d'Appfuse, il était normal que l'interface ne veuille plus démarrer. A ce stade, mon travail se résumait à de la configuration/paramétrage. Le fonctionnement du serveur d'application Tomcat m'était encore obscure à cette époque, ainsi que le fonctionnement d'Appfuse. C'est ainsi grâce à mes investigations aussi bien auprès de mes recherches sur internet qu'auprès de tous les colaborateurs présent au siège, que j'ai pu démarrer l'interface.

L'étape suivante fut de faire fonctionner l'existant. Or, de nombreux objets métier avaient subi des changements et des évolutions. J'ai tout d'abord passer en revue l'application afin de pouvoir en extraire ce qui ne fonctionnait pas. Mon analyse a révélé que la notion de multilangue était traitée d'une façon particulière et que pratiquement la totalité des objets la nécessitaient.

De là, j'ai pu commencé la remise à niveau proprement dite à l'aide des parties fonctionnantes qui m'ont servi de modèle.

Une fois l'application remise en état, je pouvais en chercher des améliorations. Pour cela, nous nous sommes réunis avec mon chef de projet. De cette discussion, les besoins furent définis de façon bien plus précise qu'auparavant : tous les objets métiers furent étudier scrupuleusement afin de ne pas oublier de besoin à couvrir. Etant donné la taille du projet, un total de trente-quatre « tables-objet » étaient à administrer.

Dans un premier temps, mon objectif était d'administrer de façon la plus sommaire les objets métiers ne nécessitant pas de fonctions particulières :

– Lister les différentes entrées d'une table


Figure 12 :Capture d'écran de la liste d'un objet métier simple

– Pouvoir éditer ou ajouter une entrée

Figure 13 :Capture d'écran de l'édition d'une entrée

Cette étape fut un moyen pour moi de pouvoir me familiariser sur des cas simples au fonctionnement de struts ainsi qu'avec les « DAO » et services, deux notions phares du développement J2EE.

Par la suite, je me suis donc interessé aux objets plus compliqués, notamment ceux nécessitant d'entrer des images dans la base de donnée mais aussi ceux nécessitant une interface particulière.


Figure 14 :Capture d'écran de l'édition d'un club

Durant le développement, des besoins de fonctions particulières furent émises comme :

– L'envoie de mail au président respectif de chaque entité

– Réévaluation de différentes informations lors d'un changement de saison notamment celles des catégories d'âge

Par la suite, cette interface fût maintenu à chaque fois que cela fut nécessaire, notamment lors d'ajout d'objet dans le modèle, d'ajout de fonctionnalité ainsi que lors des différentes migrations.

Une compréhension de la couche métier était nécessaire lors de cette tâche afin de pouvoir donner un maximum d'ergonomie à l'application. Ceci m'a permis d'acquérir une vision globale de l'application via les objets parcourus.


☑Développement de la portlet SonsEntity

Cahier des charges

Lors de mon arrivé, L'application Stadup avait déjà une version stable en ligne. Cette version était en réalité seulement disponible pour les clubs. Les autres entités étaient implémenter mais n'avaient pas subi une étude approfondie puisque que les premiers clients visés étaient des clubs.

Dans la logique fonctionnelle, une fédération se devait de pouvoir administrer ses entités fils (dans ce cas précis, on parle des interregions). Or avant mon intervention, elle n'administrait que ses propres salariés.

Dans le but d'améliorer l'ergonomie de l'application pour ces entités, le développement d'une nouvelle portlet me fut confié.

Les spécifications étaient les suivantes :

– Pouvoir voir toutes les entités fils

– Pouvoir consulter leur fiche détaillée

– Pouvoir consulter la liste des responsables

– Pouvoir leur envoyer un mail


Cette portlet paraîssait simple : Il n'y avait quasiment que des vues à développer. Pour démarrer le développement de portlet, je ne pouvais pas espérer mieux. Ceci m'a permis d'appréhender de façon claire le développement à la base des portlets.

En tout premier lieu, la première difficulté fut l'élaboration du système qui allait récupérer les entités fils : Stadup possède un système hiérarchique qui est figé. En utilisation réelle, des rangs hiérarchique n'existe pas. De ce fait, les entités fils ne sont pas forcement au niveau n-1 mais au niveau n-2, n-3, etc...

La solution trouvée fut de rajouter un booléen dans l'objet Entité afin de déterminer si il s'agit d'une entité virtuelle (rang virtuel) puis à l'aide d'une fonction adaptée, trouver les entités fils.


Figure 15 :Capture d'écran de la liste des entités fils

Après analyse de l'existant, j'ai eu l'idée de me resservir de code existant : en effet, la fiche de des entités étaient déjà développer dans la portlet « administration du club » ainsi que la liste des membres du bureau dans la portlet « gestion du bureau ». De cette façon, lorsque ces deux portlets seront modifiées (rajout de champs par exemple) la portlet sonsEntity sera mise à jour.

Après consultation de mon chef de projet pour discuter de la pertinance de mon idée ainsi que de sa faisabilité, j'ai pu commencer le développement. L'utilisation de ce concept n'était pas courant dans l'application, j'ai donc eu quelques difficultés à le mettre en place.


Figure 16 :Capture d'écran de la portlet SonsEntity

Une fois le concept implémenté, je devais trouver un moyen de personnaliser le fonctionnement des différentes parties des deux autres portlets afin qu'elles fonctionnent d'une certaine manière quand le composant est appelé par la portlet sonsEntity.

La solution trouvée fut de mettre en place un système de flag qui serait initialisé dans les actions de ma portlet. Ceci me permit de :

– Masquer des boutons

– Masquer des parties de la page que je n'avais pas besoin pour ma portlet

– Modifier le fonctionnement de certains boutons


☑Mise à jour des tests unitaires

En programmation, le test unitaire est un procédé permettant de s'assurer du fonctionnement correct d'une partie déterminée d'un logiciel ou d'une portion d'un programme.

Il s'agit pour le programmeur de tester un module, indépendamment du reste du programme, ceci afin de s'assurer qu'il répond aux spécifications fonctionnelles et qu'il fonctionne correctement en toutes circonstances. Cette vérification est considérée comme essentielle, en particulier dans les applications critiques. Elle s'accompagne couramment d'une vérification de la couverture de code, qui consiste à s'assurer que le test conduit à exécuter l'ensemble (ou une fraction déterminée) des instructions présentes dans le code à tester. Le test unitaire doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de régressions (l'apparition de nouveaux dysfonctionnements).

Dans les applications non critiques, l'écriture des tests unitaires a longtemps été considérée comme une tâche secondaire. Cependant, la méthode Extreme programming (XP) a remis les tests unitaires, qu'elle nomme maintenant Tests du Programmeur, au centre de l'activité de programmation.

La méthode XP préconise d'écrire les tests en même temps, ou même avant la fonction à tester. Ceci permet de définir précisément l'interface du module à développer. En cas de découverte d'un bogue logiciel, on écrit la procédure de test qui reproduit le bogue. Après correction on relance le test, qui ne doit indiquer aucune erreur.

Tout un environnement préparé (framework) existe dans différents langages informatiques pour réaliser facilement des tests unitaires :

– SUnit pour Smalltalk

– JUnit et TestNG pour Java

– DUnit pour Delphi

– PHPUnit pour PHP

– unittest pour Python

– Test::Unit pour Ruby

– cppunit pour C++

En ce qui nous concerne, les tests unitaires sont effectués à l’aide d’une version J2EE de Junit de Jmock :

– JUnit est une librairie contenant tous les outils pour créer un jeu de test complet et rapide de l’application. Chaque partie de l’application doit avoir son propre jeu de test,


consistant par exemple à tenter d’ajouter un utilisateur, et de vérifier qu’il est bien présent dans la source de donnée. La version J2EE de JUnit quant à elle est une application Web déployable directement sur le serveur, qui va, à la demande, lancer cette série de test directement sur le serveur, et donc dans l’environnement réel d’utilisation. Puis ces résultats seront affichés aux testeurs via un navigateur.

– JMock permet de créer des objets de substitut pour des Objets dépandants d'autres : Supposons que l'objet de type A dépende d'un objet de type B qui, quant à lui, attaque la base de données. L'idée est de créer un objet mockB qui se fait passer pour B auprès de A. Ainsi, il est possible de tester A indépendemment de B (on peut reconnaître un pattern proxy). Avec ce framework, nous pouvons demander aux mock objects de vérifier que telle méthode a bien été invoquée. Par exemple, si la méthode A.faitDesTrucs() est censée mettre à jour la base de données au moyen de B.updateDataBase(), on configure un objet mockB pour vérifier que cette méthode est effectivemet invoquée. Dans le cas contraire, le test échoue et dans les 2 cas, la base de donnée reste inchangée.

Suite à la migration, il fallait remettre sur pieds les tests unitaires. Or ils n'avaient pas été maintenus depuis un long moment, à tel point que la plupart étaient même désactivés. Le cahier des charges était simple : remettre en marche l'existant. Durant cette activité, je me suis familiarisé avec JUnit et JMock.


☑Développement de la portlet correspondance

Cahier des charges

Il s'agissait d’améliorer la fonction de correspondance ( envoi de mailing ) existante dans Stadup.

Il fallait que les utilisateurs de Stadup disposent d’une véritable application de correspondance.

Les membres d’une entité devaient être capable de correspondre simplement et rapidement avec les utilisateurs et les différents catégorie ( ou groupes ) de membres de Stadup.

La correspondance devait incorporer l’envoi de mail, le suivi des mails et la gestion des modèles utilisables.

Auparavant, Stadup possèdait une fonction de ce type. Mon chef de projet souhaitait améliorer cette fonction, car elle était, à ce jour, trop sommaire et restait trop limitée.

Par exemple, la gestion des modèles ne pouvait être faite que par des développeurs.

Un onglet spécifique serait consacré à cette fonction.

Le périmètre de cette fonction couvrirait :

- Création de mailing List sur mesure, avec critère de sélection.

- Envoi à des personnes internes

- Utilisation des modèles de mails ou rédaction d’un mail personnalisable,

- Envoi et suivi des mails (accusé de réception et visualisation des mails envoyés),

- Gestion des modèles de mails (création, modification, suppression…)

Le tout serait bien entendu, géré en fonction des droits et fonctions de chaque personne.

Les membres du bureau d'une entité supérieure à un club ne pourraient envoyer des mails que dans leur propre entité ou aux membres du bureau du n-1.


J'ai donc été le « beta-testeur » d'une nouvelle procédure de développement dans le projet. Un cahier des charges en bonne et dû forme m'a été remis. De là, j'ai du modéliser celui-ci en UML, en passant par les cas d'utilisation et le diagramme de classe jusqu'aux diagrammes d'activité.La modélisation était encore relativement abstraite à cette époque, mais de nombreuses investigations m'ont permi de mener à bien cette phase.


Figure 17 :Diagramme d'activité des membres du bureau

Après validiation de ceux-ci, une maquette en html me fut demandée. A la base, je trouvais que cela allait être assez long à réaliser dans le temps qui m'était imparti, mais c'était parce que je n'avais pas bien compris ce qu'était une maquette : c'était simplement construire l'interface en mettant tout simplement des données statiques. De plus, après quelques conseils très avisés de mon chef de projet, j'ai pu mener à bien cette étape. En effet, il suffisait de récupérer le code source html généré d'une page de l'application existante via un navigateur comme Firefox. Après plusieurs démonstrations non satisfaisantes ergonomiquement parlant, j'ai eu le feu vert pour démarrer le développement proprement dit.

La partie la plus difficile dans ce développement fut l'élaboration du système de filtrage en amont de la construction d'une mailingList. En effet, avec mes connaisances du moment, je pensais tout simplement passer par un système issu de requête HQL (hibernate query language). En discutant avec mon chef de projet, il me renvoya vers une solution plus optimale dont je ne connaissais pas l'existence : les criteria hibernate. Cet outil du framework était optimal pour nos besoins. Après quelques recherches, je me suis apperçu qu'il était très utilisé pour les systèmes de filtrages.


Figure 18 :Capture d'écran du système de filtrage

En ce qui concerne l'envoi de mail, j'ai pu m'appuyer sur la portlet Mail. En effet, l'envoi de mail est une fonctionnalité omniprésente dans Stadup. Cependant, la fonction d'envoi de mail commune, n'était point optimale : elle fonctionnait comme si nous envoyions un même mail l'un après l'autre de façon itérative. Or, ce système pouvait poser un problème de performance lors par exemple, d'un envoi d'un même mail à une très grosse maillinglist. J'ai donc du arranger cette fonction de façon à optimiser son fonctionnement, tout en ne perturbant pas l'ancien fonctionnement dont la portlet mail était dépendante. La seconde modification de cette fonction fut l'ajout de la possibilité de demander un accusé de réception. Une recherche du coté du protocole SMTP suffit à combler ce manque.

Durant le développement général, certains détails du cahier des charges n'étaient toujours pas très clairs, notamment, au niveau des filtres : Sur quels champs devait se faire le filtrage? Quelle contrainte hiérarchique? Après quelques réunions, le choix se précisa aussi bien par le biais par la demande du « client » que par les solutions du développeur.

Par souci de perfection et dû au temps qui m'était imparti, il fut choisi de faire une première version de cette portlet, en privilégiant la boîte d'envoi ainsi que la gestion des mailingLists.


☑Rédaction de documentation

Une des principales faiblesses du projet était le manque de documentation. Elle était loin d'être inexistante mais les documents dataient du début du projet, il y a un an et demi. De ce fait, les stagiaires affectés à Stadup et moi-même durent poser une avalanche de question à Arthur qui trouvait son travail personnel considérablement ralenti.

Suite à cette expérience, quand il fut décidé de délocoliser une partie du développement de l'application à la toute nouvelle filiale du Maroc, notre chef de projet décida de lancer une campagne de mise à jour de la documentation.

Non seulement chacun devait écrire de la documentation sur les nouveaux modules qu'il avait développer, mais aussi rédiger des documentation sur les modules existant où chacun avait passer beaucoup de temps. Certaines notions comme les roles devaient être expliquées dans un document.

Nous avons donc rédigé un document commun baptisé « liste des portlets ». Chacun a donc rédiger le descriptif avec pour objectif d'aider au maximum les futurs développeurs qui reprendront notre ouvrage. Ainsi, les points les plus difficiles au niveau conception furent éteillés, ainsi que les subtilités dues aux limites du langages : parfois, après étude approfondi d'un problème, nous pouvons nous apercevoir que le problème vient du langage lui-même et non pas du raisonnement. Ces cas sont très rares et afin d'éviter que le développeur suivant ne perde pas de temps à découvrir cette subtilité, il faut l'indiquer dans la documentation où au moins dans les commentaires du code.

Cette partie est bien souvent sous-estimé par de jeunes développeurs sortant des études comme moi-même. Mais dans un cadre professionnel, l'utilité de ceux-ci devient évidentes.


☑Mise en production

La mise en production est une phase très délicate. La mise en production en soi représente l'accomplissement d'un dur labeur, et apporte satisfaction auprès de l'équipe.

Mais à l'annonce d'une mise en production, c'est une pression qui s'installe au sein de chacun. Tout doit être parfait. L'application se doit d'être exent de bogues. De plus, la contrainte de temps constitue un facteur de pression en plus. Des scénarios de test sont donc attribués à chaque développeur : il faut être très rigoureux pendant cette phase, rien ne doit nous échapper. Chaque bogue trouvé doit être immédiatement traité.

Une fois l'application bien validé par le chef de projet, la mise en production peut s'effectuer.

J'ai pu vivre plusieurs mises en production durant mon stage. J'ai donc pu tester ma capacité à endurer la pression dans le cadre professionnel. Ce n'est certes pas la seule pression dans un projet mais c'est clairement la plus forte.


☑Résolution de bogues

Lors de mon arrivée sur le projet Stadup, celui-ci était déjà en phase de test dans un club de Judo présidé par un membre de l’équipe commerciale de Stadango, Alexandre Borderieux. Grâce à cette phase de beta test constante et à des tests réguliers réalisés par Alexandre et par un autre membre de l’équipe commerciale de Stadango, Sliman Khelil, de nombreux bogues ont été découverts.

En conséquence, un site web de rapport de bogues fut mis en place. Ce site basé sur Mantis (http://www.mantisbt.org) permet une gestion des bogues très avancée. Chaque rapport de bogues possède des détails sur la partie de l’application qui est concernée, sur la façon dont il peut être reproduit, et permettant de savoir si ce bogue affecte plutôt l’interface ou plutôt le fonctionnement de Stadup, etc. Les bogues peuvent alors être affectés à un développeur en particulier.

Lorsqu’un développeur veut s’occuper d’un bogue en particulier, il se l’affecte. Une fois que sa tâche est terminée, il passe le statut du bogue en « résolu ».

Entre les phases de développement que j’ai eu à réaliser sur Stadup, il y a souvent eu des périodes pendant lesquelles aucune tâche particulière ne m'avait été confiée. La consigne que tous les développeurs de l’équipe avait à suivre dans un tel cas était de s'attacher à résoudre les bugs répertoriés.

Souvent ces tâches de résolution de bogues ne prenaient pas beaucoup de temps mais permettaient d’améliorer grandement l’application.

Le système de rapport de bogues est également ouvert à tous les développeurs de Stadup. Ainsi si l’un d'entre eux trouve un bogue, alors qu'il est en train de réaliser une tâche plus urgente, ou qu'il sait qu’un autre développeur de l’équipe a déjà travaillé sur la partie concernée par ce bogue, il peut créer une nouvelle entrée sur le site Mantis et l’affecter à un membre de l’équipe.

La mise en place d’un tel outil est toujours nécessaire dans les projets informatiques atteignant une certaine ampleur. Il permet de bien cibler les problèmes potentiels de l’application et d’avoir un suivi précis.


http://www.mantisbt.org/

11.Interprétation et critique des résultats

Tous les travaux et développements qui m’ont été assignés durant ma période de stage ont été menés à bien et ont été réellement intéressants. Cependant, le fait d’avoir eu à découvrir Liferay ainsi que l'univers J2EE a certainement contribué à ce que mes réalisations soient plus longues qu’elles ne l’auraient été si j’avais déjà été familier avec cet univers.

J’ai pu approfondir mes connaissances dans le domaine du développement Web que je n’avais pas eu jusqu'à présent l’occasion de beaucoup expérimenter. J’ai pu aussi découvrir les nombreuses problématiques liées à ce type de développement, surtout au niveau de la compatibilité entre les navigateurs et leur façon de gérer les standards du Web.

Ce travail m’a malheureusement aussi fait découvrir un problème lié au portail Liferay qui fut récurrent tout au long de mes développements : le manque de documentation. En général, sur les projets Open Source tels que Liferay, ce manque est pallié par une forte communauté qui gravite autour du projet et permet d’obtenir le plus souvent des réponses. Dans le cas de Liferay, il apparaît que bien que beaucoup de personnes ainsi que d’entreprises l’utilisent, l’effet communauté demeure très restreint et se limite à un forum très peu visité.

De plus, le choix de travailler avec le portail Liferay reste discutable : en effet, il est essentiellement utilisé pour le système d'onglet servant à la navigation dans les différentes portlets. Le système de rôle peut s'avérer très complexe. Un autre défault est la portabilité des portlets developpé. Liferay se dit compatible jsr-168, mais le deploiement de portlet s'avére tres tres delicat. Même les portlets d'exemple tres simple fournit par Liferay sont difficiles à faire fonctionner. D'autres portails, beaucoup plus ciblés sur les besoins immédiat de ce projet, auraient surement pu faire l'affaire (avec documentation à l'appuie, grande communauté ayant travaillé dessus,etc...) comme JetSpeed. Mais IPPON Technologies avait le désir d'avoir une solution qui serait à la pointe de la technologie, afin de pouvoir s'en servir de vitrine ainsi que plateforme d'entraiement pour ses collaborateurs. Liferay est une merveille de technologie. Mais il faut mettre les moyens pour l'exploiter dans son sens. Ce choix a été fait pour du long terme.

Un autre problème fut le manque de cahier des charges sur Stadup. La seule personne à connaître au jour le jour l’état des fonctionnalités et celles restant à réaliser est Arthur Clément. Il nous transmettait ainsi par voie orale les grandes lignes de la tâche à réaliser, à charge pour nous d’éclaircir certains points. Ce manque de détails a contribué à nous installer dans une démarche plutôt expérimentale et incertaine puisque bien souvent des problèmes sont apparus au cours du développement, tant au niveau technique que fonctionnel, rendant nécessaires des changements qui n’avaient pas encore pu être identifiés et donc prévus jusque-là.


Conclusion générale

Ce stage fut pour moi une réelle opportunité de découvrir le monde J2EE. Pendant la recherche de ce dernier, j'étais plus intéressé par les technologies de Microsoft et plus particulièrement par .Net que par l'univers Java/J2EE. Cet intérêt est dû en partie à mon manque d'expérience. En effet la seule occasion m’ayant permis d’aborder les technologies J2EE a été la réalisation d'un petit projet scolaire.

IPPON Technologies a malgré tout fait le choix de me donner ma chance et de me permettre de participer à un projet intéressant tout en découvrant le J2EE. Le projet Stadup possède néanmoins des lacunes qui furent, de mon point de vue, très gênantes.

La première d'entres elles fut l'absence totale de réunions, et ce même si l'équipe entière de Stadup se situait dans le même bureau. Il est en effet à mon avis très important que des réunions régulières aient lieu pour informer les membres des lignes directrices du projet et d’autant plus lorsque des changements interviennent, ce qui fut notamment le cas lors de la migration.

Le deuxième point que j'ai déjà évoqué est le manque de cahier des charges sur Stadup. Sur chaque tâche à réaliser, on sait dans l'ensemble quel est le but à atteindre mais c'est à nous d'approfondir pour en découvrir les détails. Or on ne les découvre le plus souvent qu'au cours du développement, et puisque nos connaissances de Stadup sont assez limitées, cela entraîne des réalisations qui prennent plus de temps qu'elles ne le devraient.

L'entreprise a mis en place, pour tous ses stagiaires, un entretien au milieu de la période de stage. Il se tient en présence d'un responsable des ressources humaines et du responsable technique du stagiaire. C'est au cours de cet entretien que j'ai pu faire part des problèmes rencontrés quant à Stadup à Arthur Clément, chef du projet.

Néanmoins, j'ai pu voir la richesse de la technologie J2EE. J'ai pu appréhender différentes possibilités en participant à des discussions sur ce sujet. C'est pour cela que j'ai décidé de me perfectionner dans cette voie là.

IPPON Technologies m'a proposé de continuer notre collaboration. A ce moment précis, j'ai voulu voir ce que l'on pouvait me proposer ailleurs. Or je me suis vite aperçu que de nombreuses opportunités pouvaient s'offrir à moi. Après une longue réflexion, j'ai décidé d'accepter une propos


Bibliographie

http://www.ippon.fr

http://www.liferay.com

http://www.developpez.com

http://apache.org

http://java.sun.com

http://commentcamarche.net

http://fr.wikipedia.org

http://www.01net.com


http://www.01net.com/

http://fr.wikipedia.org/

http://commentcamarche.com/

http://java.sun.com/

http://apache.com/

http://www.developpez.com/

http://www.liferay.com/

http://www.ippon.fr/

AnnexesLe portail Stadup :



Documents

Mémoire de fin d'études ESIEA - Freerastasia.free.fr/public/rapport final RKhounsamnane.pdf · Mémoire de fin d'études ESIEA Développement de modules pour un portail pour clubs