maxime.morand.free.frmaxime.morand.free.fr/CRM/Rapport/Memoire.w2003.doc · Web view3. Impacts sur les méthodes de développement 25. 4. Impact sur les performances générales

SOMMAIRE

INTRODUCTION............................................................................................................................................. 1

I. PRÉSENTATION DE LA SOCIÉTÉ.............................................................................................................. 5

1. LE GROUPE INFOTEL......................................................................................................................................5

2. LES ACTIVITÉS...............................................................................................................................................7

3. DOMAINE D’EXPERTISE...................................................................................................................................9

4. LES CHIFFRES CLÉS......................................................................................................................................10

5. LA DIVISION SUD OUEST..............................................................................................................................11

II. L’UTILITÉ DES LOGICIELS ORM............................................................................................................. 13

1. LE PROBLÈME.............................................................................................................................................13

2. PRINCIPES DE LA PERSISTANCE.......................................................................................................................16

3. IMPACTS SUR LES MÉTHODES DE DÉVELOPPEMENT.............................................................................................25

4. IMPACT SUR LES PERFORMANCES GÉNÉRALES....................................................................................................34

5. VERS UNE SOLUTION UNIQUE........................................................................................................................38

III. DÉVELOPPEMENT ET MISE EN PLACE D’UN OUTIL DE GRC...................................................................41

1. CONTEXTE.................................................................................................................................................41

2. L’APPLICATION...........................................................................................................................................45

3. L’ARCHITECTURE TECHNIQUE.........................................................................................................................51

4. L’ARCHITECTURE.........................................................................................................................................56

IV. LE PROJET DADS-U.............................................................................................................................. 70

1. PRÉSENTATION DU LOGICIEL..........................................................................................................................70

2. MISE À JOUR DU PROJET..............................................................................................................................75

3. LA RÉSOLUTION DE BUGS.............................................................................................................................77

CONCLUSION............................................................................................................................................... 79

1. BILAN DU STAGE.........................................................................................................................................79

2. Bilan personnel......................................................................................................................................80

Mémoire

Développement d’un ERP de GRC Date : 13/09/2007

2/32

Mémoire


Introduction

Dans le cadre de ma formation du cycle d’ingénierie génie logiciel de l’EPSI de

Bordeaux, j’ai effectué mon stage de fin d’étude chez Infotel Bordeaux, pendant six mois

consécutifs. L’objectif initial de ce stage était la refonte totale d’une application de gestion de

la relation client (GRC). Il est à noter que ce stage s’inscrit dans la continuité de mon stage

précédent, effectué pour la même entreprise.

L’année précédente, Infotel m’avait pris en tant que stagiaire, ainsi qu’un autre élève

d’une école différente mais de même année, pour réaliser toute la partie précédant le codage

d’une application. Nous avons ainsi recueilli les besoins, élaboré les spécifications - générales

dans un premier temps - et recherché dans le monde de l’open source une solution existante

ayant une bonne couverture fonctionnelle. Cette dernière tâche s’est révéler partiellement

infructueuse. Infructueuse car aucun logiciel ne répondait aux besoins spécifiques d’Infotel en

matière de GRC. De plus, en ne considérant que les logiciels bâtis autour de la technologie

qui nous intéressait, le J2EE, le choix était plutôt restreint.

Nous avons ainsi décidé de ne pas construire le projet à partir d’une application

existante. Pour cela, nous avons réalisé conjointement une maquette, accompagné des

spécifications détaillées. Une fois cela réalisé, nous avons fait un premier pas dans l’univers

J2EE en créant l’étude de l’architecture. A cette époque, mon collègue et moi-même étions

tous deux novices dans ce domaine. Nous nous sommes donc appuyés sur les conseils des

experts Infotel pour achever ce dossier.

Notre premier stage s’acheva ainsi, et nous savions donc parfaitement ce qui nous

attendait cette année. Nous aurions à débuter le codage de l’application presque

immédiatement après l’entrée en stage, puis aurions à entamer une phase de tests, suivi de

toute une phase de migration de l’ancien système. Pour la fin du stage, si nous disposions

d’assez de temps, notre maître de stage avait également prévu de nous faire refaire une partie

1/8

Mémoire


de l’application en .NET, dans le double but de nous former sur cette technologie et de

comparer les méthodes de développement avec une environnement J2EE.

C’est ainsi que mon deuxième stage chez Infotel débuta, le 1er mars 2007. Le sujet

principal de mon stage était donc bien celui décidé l’année précédente : concevoir une

application de gestion de la relation client.

D’un point de vue développement, nous sommes ainsi partis d’un projet vide. La

structure de celui-ci était donc laissée complètement à notre charge. Celle-ci se devait d’être

la plus claire et la plus souple possible, pour deux raisons majeure :

- Deux nouveaux stagiaires nous ont rejoints sur le projet au cours de notre stage,

respectivement un et deux mois après le début du développement. Pour qu’ils puissent

rapidement se familiariser avec notre structure, nous avons essayé de respecter

certaines règles et certains standards. De manière générale, l’évolutivité et la

maintenabilité d’une application repose avant tout sur sa structure. C’est donc un des

principaux facteurs à prendre en compte lorsque l’on début un nouveau projet.

- L’évolution fonctionnelle : tout au long du projet, certaines fonctionnalité ont du être

revue, ajoutées, ou même supprimer. Pour diminuer au maximum l’impact que

peuvent avoir de tels changements, nous avons veillé à avoir une structure

relativement souple.

Malgré cela, nous jouissions d’une certaine liberté sur ce projet. Notre principal objectif étant

de répondre aux besoins. Les choix techniques, même si ils devaient être justifiés, étaient

laissés à notre jugement.

La seconde phase de mon stage me laissait d’un côté moins libre de mes actions, mais était

d’un autre côté nettement plus organisé. Cette fois ci, nous étions sous les ordres du chef de

projet d’Infotel Bordeaux : monsieur Hervé Plagelet. Nous avons ainsi abordé un autre aspect

du développement, aspect que l’on aborde rarement dans une formation académique, bien

2/8

Mémoire


qu’elle représente une part conséquente du métier d’ingénieur d’étude : la maintenance d’une

application existante.

En effet, lorsqu’une application est mise en production, cela ne signe pas nécessairement la

fin du projet, bien au contraire. Les logiciels n’ayant jamais à subir de correctifs ou de mises à

jour sont en réalité assez rare. C’est dans ce genre d’opération que l’on se rend compte de

l’importance de la clarté d’une structure, d’un code. Ainsi, j’ai été amené pendant les deux

derniers mois de mon stage à effectuer quelques mises à jour sur le logiciel DADS-U

(Déclaration Automatisé des Données Sociales – Unifiée).

Qui plus est, au cours des premières semaines de développement de l’application GRC,

l’utilisation d’un outil de mapping objet / relationnel (ORM) s’est présenté comme étant

incontournable. Le nom de Hibernate revenait sur un grand nombre de forums et était

préconisé par les experts d’Infotel. Peu familier avec la structuration en couche, je me

demandais alors à quoi pouvait bien servir un tel outil. Après une petite étude, j’ai rapidement

compris son rôle. Hibernate, ou tout outil ORM, est utilisé pour lié nos objets dans le code de

notre application à nos tables dans notre base de données. A première vue, la solution qu’il

propose semble très élégante et pratique, mais on est droit de se demander ce qu’il se passe en

réalité. En effet, Hibernate réalise un ensemble d’opérations invisibles pour le développeur.

Même si cela est le cas pour chaque framework, les accès aux bases de données sont des

opérations délicates car coûteuses en ressources. Les performances d’un système dépendent

en grande partie des ses accès aux données. J’ai donc décidé, conjointement avec mon maître

de stage de mener une recherche sur ce sujet.

Ce mémoire sera donc scindé en deux sous partie :

Dans un premier temps, je chercherais à prouver ou à infirmer l’utilité d’Hibernate dans une

application structurée en couche. Un tel framework peut avoir un impact à deux niveau : au

niveau du temps de développement et de la clarté du code et au niveau des performances. Un

développement plus rapide et une maintenance plus aisée signifie un gain de temps, donc

3/8

Mémoire


d’argent en milieu professionnel. Des performances à la baisse peuvent entrainer une perte

d’argent sur certains systèmes. J’étudierai donc l’utilité d’un ORM dans un système

d’information et suivant ces deux axes.

Dans un second temps, je parlerais de mon stage. Cette partie sera donc séparée en deux

parties, chacune décrivant mon activité sur les deux projets sur lesquels je suis intervenu

durant mon stage. La première décrira ma méthode de travail sur l’application GRC et la

deuxième sur l’application DADS-U.

4/8

Mémoire


I. Présentation de la société

1. Le groupe Infotel

1.1. Historique

Infotel a été créée fin 1979, par des professionnels de l’informatique.

Cette société de services a été fondée par Messieurs Bernard LAFFORET, actuel Président,

Michel KOUTCHOUK actuel Directeur Général et Alain HALLEREAU actuellement

directeur des produits France. Dès son origine, Infotel a développé des activités de service, de

formation et de recherche progicielle.

A ses débuts, cette société était spécialisée dans le secteur des grands systèmes. Au fil du

temps, elle a évolué et a su se diversifier vers de nouveaux secteurs informatiques tout en

maintenant son niveau d’expertise.

À la fin de l’année 2005, le groupe Odaxys a rejoint Infotel.

L’objectif d’Infotel a toujours été, depuis sa création, d’apporter à sa clientèle, en majorité

composée de grandes entreprises, des solutions techniques leur permettant de mettre en place

des applications performantes en temps réel avec de très grandes bases de données :

aujourd’hui, le web-to-database en est l’expression.

1.2. Implantations géographiques

Infotel est un acteur indépendant européen de réputation mondiale : ses progiciels sont vendus

dans le monde entier, soit directement pour la France et certains pays d'Europe, soit via des

accords de distribution mondiaux signés avec IBM.

Le siège de la société Infotel est actuellement localisé en région parisienne à Bagnolet.

5/8

Mémoire


Présente en France au travers de ses bureaux parisiens et de ses agences à Toulouse,

Bordeaux, Lyon, Nantes et Rennes, Infotel est également représentée à l’étranger via ses

filiales (situées aux USA, Royaume-Uni et Allemagne).

Figure 1.1 : Infotel dans le monde

1.3. Organisation juridique

Infotel SA est la société mère. Elle exerce deux activités opérationnelles: la formation et les

progiciels.

Infotel Conseil exerce les activités de prestation de services du Groupe et est basé à Neuilly-

sur-Seine ; l’activité du grand Sud-Ouest du Groupe est réalisée sur les sites de Toulouse,

Bordeaux., Nantes et Rennes.

6/8

Mémoire


Figure 1.2 : Infotel en France

Infotel Corp. (Tampa - Floride) assure le support technique aux États-Unis et gère certains

distributeurs.

Infotel GmbH (Moers) distribue en Allemagne.

Infotel Software Ltd (Leeds) distribue au Royaume-Uni.

Figure 1.3 : Organisation juridique d’Infotel

7/8

Mémoire


2. Les activités

Depuis son origine, le cœur du métier d’Infotel se concentre autour de 3 activités principales :

les services ;

les formations ;

les progiciels.

2.1. Services

Infotel fournit des prestations de conseil, d'étude, d'audit de systèmes informatiques et de

TMA (Tierce Maintenance Applicative). La société conçoit et réalise des projets

d'informatique de gestion, en régie ou au forfait. Elle met en œuvre des méthodes et

techniques avancées allant du Web jusqu'aux bases de données.

Ces prestations couvrent la totalité du cycle de vie des applications, depuis leur conception

initiale jusqu’à leur évolution après leur mise en production.

Les équipes d’Infotel interviennent :

dans les phases d’étude, au niveau des choix d’architecture, des choix

méthodologiques, des spécifications et de la conception ;

dans les phases de réalisation, en prenant en charge partiellement ou totalement (au

forfait) la construction des applications et en assurant les tests et la recette ;

durant le fonctionnement opérationnel, en assurant la maintenance des applicatifs

(TMA), les audits de performances et les actions d’optimisation qui permettent de tirer

le meilleur parti des investissements consentis.

8/8

Mémoire


Figure 1.4 : Activités d’Infotel

2.2. Formations

Le catalogue de formation inter-entreprise couvre des filières allant du grand système (MVS,

DB2, CICS) au client/serveur.

Pour répondre aux besoins de souplesse et de spécificité de certains clients, Infotel construit

des cours intra-entreprise sur demande.

Des séminaires thématiques apportent également des éléments de réflexion sur les grands

sujets d’actualité tels que le passage à l’Euro, ou encore Intranet.

2.3. Progiciels

Les progiciels développés par Infotel ont une réputation internationale (plus de 700 licences

dans le monde).

Cette activité est maîtrisée dans son ensemble (conception, réalisation et commercialisation).

Les produits développés par la société appartiennent à la catégorie des « utilitaires »

permettant d’assurer automatiquement la gestion et la maintenance automatique des bases de

9/8

Mémoire


données. Ils contribuent à améliorer les performances et la qualité des services informatiques,

répondant à une demande précise du marché.

Infotel est spécialisé sur les bases de données DB2 d’IBM, ainsi que le système MVS d’IBM,

système d’exploitation des mainframes d’IBM.

3. Domaine d’expertise.

L'expertise d'Infotel s'étend sur toutes les couches du système d'information de l'entreprise, du

poste de travail au serveur central :

Figure 1.5 : Domaine d’expertise

au niveau du poste client (front-end), avec les navigateurs, les langages comme HTML,

XML, Javascript, Java ;

au niveau des serveurs intermédiaires (middle-end), avec la maîtrise des middlewares,

des couches réseau et des pare-feu, des systèmes d’exploitation comme Windows ou

Unix, des serveurs d’applications comme Websphere ou Tomcat, de Java (J2EE) et des

EJB, etc. ;

au niveau des serveurs centraux, avec une expertise reconnue des systèmes

d’exploitation comme z/OS, des moniteurs TP (CICS, IMS), des SGBD (IMS, DB2,

Oracle), des langages et des applications.

10/8

Mémoire


4. Les Chiffres clés

4.1. Humain

En 2007, l’effectif du groupe Infotel comprend 750 personnes, dont 190 au Sud-Ouest.

Qualification : les effectifs du Groupe sont caractérisés par une forte qualification. En effet,

Infotel compte 90 % d’ingénieurs (dont environ la moitié est issue de grandes écoles et l’autre

de formations universitaires).

Infotel mise sur la fidélisation de ses collaborateurs, et jouit d’un taux de turn-over très faible

(2006 : 2,9 %, 2005 : 2,5%, 2004 : 3,5%).

Figure 1.6 : Graphe d’évolution du nombre de collaborateur et du C.A.

4.2. Financier

Le chiffre d’affaire est en constante croissance depuis la création de la société. Cette

augmentation a été ralentie par la crise (1993-1995) qui a frappé l’économie mondiale.

11/8

Mémoire


Figure 1.7 : Evolution du C.A.

5. La division Sud Ouest

La division sud ouest d’Infotel a vu le jour avec la création de l’agence d’Infotel Toulouse le

1er août 1989. Ses premiers pas se firent dans un environnement parfaitement maîtrisé par

Infotel : DB2 / IBM.

Actuellement, cette agence est dirigée par Monsieur Jérôme ANSTROUSSE.

Elle comprend environ 190 employés dont la majeure partie travaille sur des activités de

recherches et de services auprès des clients.

5.1. L’agence de Bordeaux

Emanation de l’agence de Toulouse, l’agence d’Infotel Bordeaux a vu le jour en janvier 2004.

Actuellement, cette agence est dirigée par Monsieur Jean-Phillipe Aurin, ingénieur d’affaire,

mon maître de stage.

Elle fait travailler plus d’une trentaine d’employés sur des activités de service auprès de

clients aquitains.

12/8

Mémoire


5.2. Les projets Bordelais

Projets Client : L’agence de Bordeaux compte parmi ses clients de nombreux grands comptes

de la région mais aussi de sociétés de taille moyenne (Siemens Health Services, AGIRC-

ARRCO, Crédit Agricole, l’UNEDIC, Le Gan, la caisse d’épargne, l’armée de terre, Lectra,

rectorat de Bordeaux …).

Projets en interne : La société développe également des applications en interne sur lesquelles

elle s’appuie pour améliorer son fonctionnement (ex : la gestion des affaires, la gestion de la

relation client…).

13/8

Mémoire


II. L’utilité des logiciels ORM

1. Le problème

Le langage de programmation Java, ainsi que la plupart des langages utilisés

actuellement pour le développement d’applications professionnelles sont de type Orientés

Objet (OO). D’un autre, la majorité des systèmes de bases données (SGBD) actuels sont de

type relationnel. Ces deux types d’approche de la modélisation des données peuvent poser

problème lorsque l’on essaie de les faire coexister au sein d’une même application. Procédons

tout d’abord à un rapide descriptif de ces deux modèles.

1.1. Le modèle relationnel

Pour illustrer ceci, imaginons un système de gestion des emprunts de livres dans une

bibliothèque. Il va donc nous falloir modéliser des personnes, avec leurs informations

personnelles, ainsi que des livres et leurs informations propres. Voici une représentation

simplifiée que l’on peut se faire pour ces deux entités :

Figure 2.1 : Schéma de 2 entités

14/8

Personne

- Identifiant

- Nom

- Prénom

- Adresse

Livre

- Identifiant

- Référence

- Titre

- Auteur

Mémoire


Schématisons maintenant la façon dont notre SGBD va les stocker :

Figure 2.2 : MCD des 2 entités

Cela signifie qu’une Personne peut posséder de 0 à n livres, et qu’un livre peut être

posséder par 0 ou 1 Personne. Afin de savoir quelle personne est en possession de quelle livre,

nous avons effectué une migration de d’identifiant. Dans les informations du livre, il y a

désormais un emplacement que nous pourront remplir avec l’identifiant de la personne ayant

emprunté le livre. Ce type de champ est appelé une clef étrangère. Dans notre base de

données, chaque entité sera en réalité représenté sous forme d’un tableau, où à chaque

colonne sera associé un champ, et à chaque ligne une nouvelle personne par exemple :

Figure 2.3 : Stockage dans la base de données

Voyons maintenant les différences et les problèmes que cela entraine avec une

représentation objet.

1.2. Le modèle objet

Dans le modèle relationnel, le type est obligatoirement un de ceux qu’implémente le

SBDG. Par exemple, le champ IdPersonne de la table Livre est un entier. Or, en Objet, un

15/8

Personne

- IdPersonne

- Nom

- Prénom

- Adresse

Livre

- IdLivre

- Référence

- Titre

- Auteur

- IdPersonne

0, n0,1

IdPersonne Nom Prénom Adresse

1 Dupont Pierre 3 rue du moulin

2 Martin Jean 15 avenue Thiers

Mémoire


programmeur peut définir à volonté de nouveau type de champs, et les utiliser selon son bon

vouloir.

Nous allons construire deux Objets, Personne et Livre :

Figure 2.4 : Représentation objet simplifiée des deux entités

Le champ réservé pour connaître l’emprunteur d’un livre est donc maintenant de type

personne. Ce champ va directement pointé sur l’instance d’une personne.

Pour retrouver les informations d’un emprunteur dans le modèle relationnel, il faut

parcourir notre table jusqu’à ce que l’on trouve la personne avec le bon identifiant. En

représentation objet, on y accède directement. On peut également remarquer qu’une personne

possède un tableau de livre, pour connaitre directement tous les livres empruntés par une

personne sans effectuer de recherche, ce qui n’est pas possible avec le modèle relationnel.

Maintenant que nous avons vu les différences entre ces modèles, il suffit de comparer

les schémas 1.3 et 1.4 pour se rendre compte du problème soulevé par la liaison des ces deux

univers.

1.3. Les logiciels ORM

Comme nous venons de la voir, un logiciel de Mapping Objet / Relationnel (MOR ou

ORM, pour Object/Relationnal Mapping en anglais) est une couche de persistance connectant

les objets d'un système orienté-objet à des données stockées dans une base de données

16/8

Personne

- IdPersonne : entier

- Nom : chaîne

- Prénom : chaîne

- Adresse : chaîne

- Livre : tableau de Livres

Livre

- IdLivre : entier

- Titre : chaîne

- Auteur : chaîne

- référence : chaîne

- emprunteur : Personne

n 1

Mémoire


relationnel. L'usage du Mapping Objet / Relationnel permet d'appliquer une analyse et une

modélisation orienté-objet proprement en cachant les spécificités liées à l'usage d'un système

relationnel.

Le MOR est très populaire dans le monde Java, et même s'il est assez peu connu dans le

monde .NET, il existe déjà beaucoup de logiciels – commerciaux ou libres – comme le très

célèbre Hibernate.

2. Principes de la persistance

Dans le monde Java, on parle de persistance d’informations. Ces informations peuvent

être des données ou des objets. Même s’il existe différents moyens de stockage

d’informations, les bases de données relationnelles occupent l’essentiel du marché.

Les bases de données relationnelles, ou SGBDR (Système de gestion de bases de données

relationnelles), les plus connues sont Oracle, Sybase, DB2, Microsoft SQL Server et MySQL.

Les applications Java utilisent l’API JDBC (Java DataBase Connectivity) pour se connecter

aux bases de données relationnelles et les interroger.

Les applications d’entreprise orientées objet utilisent les bases de données relationnelles

pour stocker les objets dans des lignes de tables, les propriétés des objets étant représentées

par les colonnes des tables. L’unicité d’un enregistrement est assurée par une clé primaire.

Les relations définissant le réseau d’objets sont représentées par une duplication de la clé

primaire de l’objet associé (clé étrangère).

L’utilisation de JDBC est mécanique. Elle consiste à parcourir les étapes suivantes :

- Utilisation d’une java.sql.Connection obtenue à partir de java.sql.DriverManager ou

javax.sql.DataSource.

- Utilisation de java.sql.Statement depuis la connexion.

- Exécution de code SQL via les méthodes executeUpdate() ou executeQuery(). Dans le

second cas, un java.sql.ResultSet est retourné.

- En cas d’interrogation de la base de données, lecture du résultat depuis le resultset

avec possibilité d’itérer sur celui-ci.

- Fermeture du statement.

17/8

Mémoire


- Fermeture de la connexion.

Comme on peut le constater, même sans saisir tout le sens de ces étapes, l’interrogation

d’une base de données est une tâche rébarbative et couteuse en temps de développement. Il est

ainsi nécessaire de mettre en place une couche de persistance. La persistance peut être réalisée

de manière transparente ou non transparente. La transparence offre d’énorme avantages,

comme nous allons le voir dans les sections suivantes.

2.1. La persistance non transparente

Comme l’illustre la figure 2.5, une application n’utilisant aucun framework de persistance

délègue au développeur la responsabilité de coder la persistance des objets de l’application.

Figure 2.5 : Charge des développeurs sans framework

A moins de le mettre soit même en place, ce type d’architecture ne gère ni cache, qu’il

soit de premier ou second niveau, ni concurrence, ni clé primaire. De plus, ne traitant aucune

sorte d’association, il est d’autant plus lourd que le modèle métier est fin est complexe. En ce

qui concerne la lecture, le chargement se fait probablement au cas pas cas, avec une

duplication partielle de méthode selon le niveau de chargement requis.

Sous outil de mapping objet-relationnel, le développeur a la charge de coder lui-même

tous les ordres SQL et de répéter autant que de besoin ce genre de méthode.

18/8

Mémoire


Dans de telles conditions, la programmation orientée objet coûte très cher et soulève

systématiquement les même questions : si des objets sont associés entre eux, faut il propager

les demandes d’insertion, de modification ou de suppression en base de données ? Lorsque

nous chargeons un objet particulier, faut il anticiper le chargement des objets associés ?

La figure 2.6 illustre le problème de gestion de la persistance des instances associées à

un objet racine. Elle permet d’appréhender la complexité de gestion de la persistance d’un

graphe d’objets résultant d’une modélisation orientée objet.

Figure 2.6 : Problème lié aux objets fils

Pour utiliser une stratégie de persistance non transparente, le développeur doit avoir une

connaissance très avancée du SQL mais aussi de la base de données utilisée et de la syntaxe

spécifique de cette base de données.

2.2. La persistance transparente

Avec un framework de persistance offrant une gestion de des états des instances

persistantes, le développeur utilise la couche de persistance comme un service rendant

abstraite la représentation relationnelle indispensable au stockage final de ses objets.

19/8

??? ???

Mémoire


Figure 2.7 : Charge des développeurs avec un ORM

La figure 2.7 illustre comment le développeur peut se concentrer sur les problématiques

métier et comment la gestion de la persistance est déléguée de manière transparente à un

framework. Un outil ORM permet de réduire considérablement le volume de code nécessaire

pour interroger une base de données. Il reste cependant nécessaire de posséder de bonnes

bases en SQL, afin de mieux comprendre les mécanismes de dialogue avec la base de

données.

Les avantages d’une solution de persistance vont plus loin que la facilité et l’économie

de code. La notion de « persistance par accessibilité » (persistence by reachability) signifie

non seulement que l’instance racine sera rendue persistante mais que les instances associées à

l’objet racine pourront aussi, en toute transparence, être rendues persistantes.

Cette notion fondamentale supprime la difficulté mentionnée précédemment pour la

persistance d’un réseau ou graphe d’objets complexe, comme l’illustre la figure 2.8.

Figure 2.8 : Relations entre objets pères et fils

20/8

Mémoire


2.3. Le mapping objet-relationnel

Le principe du mapping objet-relationnel est simple. Il consiste à décrire une

correspondance entre un schéma de base de données et un modèle de classes. Pour cela, nous

utilisons des métadonnées, généralement incluses dans un fichier de configuration. Ces

métadonnées peuvent être placées dans les sources des classes elles-mêmes, comme le

précisent les annotations de la JSR 220 (EJB 3.0).

La correspondance ne se limite pas à celle entre la structure de la base de données et le

modèle mais concerne aussi celle entre les instances de classes et les enregistrements des

tables comme illustré à la figure 2.9.

Figure 2.9 : Correspondance entre une représentation relationnelle et objet.

21/8

Mémoire


En haut de la figure, nous avons deux tables liées par la colonne ID_METIER. Dans le

diagramme de classes situé en dessous, les instances de Personne et Metier sont des entités

alors que celles d’Adresse sont considérées comme des valeurs (cette nuance est détaillée plus

tard). Dans la partie basse de la figure, un diagramme d’instances permet de visualiser le

rapport entre instances et enregistrements, aussi appelés lignes ou tuples.

En règle générale, une classe correspond à une table. Si on souhaite opter pour un modèle de

granularité plus fine, une seule table peut reprendre plusieurs classes, comme la classe

Adresse.

Les colonnes représentent les propriétés d’une classe, tandis que les liens relationnels entre

deux tables (duplication de valeur d’une table à une autre) forment les associations de notre

modèle objet.

Contrairement au modèle relationnel, qui ne définit pas de navigabilité, la conception du

diagramme de classes propose une ou plusieurs navigabilités. Dans l’absolu, il y a, au niveau

relationnel, une relation « PERSONNE * ------ 1 METIER », qui peut se lire dans le sens inverse :

« METIER 1 ------- * PERSONNE ». C’est là une des différences entre les mondes objet et

relationnel. Dans notre exemple, l’analyse a abouti à la définition d’une seule navigabilité

Personne * ----- 1 Metier.

Les différences entre les deux mondes sont nombreuses. Tout d’abord, chacun possède son

propre système de types. Ensuite, la très grande majorité des bases de données relationnelles

ne supporte pas la notion d’héritage, à la différence de Java. En Java, la notion de suppression

est gérée par le garbage collector alors qu’une base de données fonctionne par ordre SQL. De

plus, dans la JVM, les objets vivent tant qu’ils sont référencés par un autre objet.

Les règles de nommage sont également différentes. Le nommage des classes et attributs Java

n’est pas limité en taille, alors que, dans une base de données, il est parfois nécessaire de

nommer les éléments au plus court.

22/8

Mémoire


2.4. Historique de la persistance des données en Java

La persistance d’objets en Java n’a été qu’une suite d’échecs et de déceptions. Avant

d’aboutir à des solutions telles qu’Hibernate, que nous verrons plus en détail au chapitre

suivant, le monde Java a dû subir la lourdeur de plusieurs solutions. Il est important de revenir

sur ce passé pour bien comprendre ce qui se joue dans le choix d’un framework de

persistance.

2.4.1. Les EJB (Enterprise JavaBeans)

Le souvenir le plus traumatisant sur ce thème sensible de la persistance dans les

applications orientées objet reste sans aucun doute la première version des EJB, il y a dix ans.

Il existait peu de frameworks de persistance à cette époque, et les entreprises se

débrouillaient avec JDBC. Les applications étaient orientées selon un modèle tabulaire et une

logique purement relationnelle plutôt qu’objet.

Les grandes firmes du monde Java ont fait un tel forcing marketing autour des EJB que

les industries ont massivement adopté cette nouvelle technologie.

Les EJB se présentent alors comme le premier service complet de persistance. Ce

service consiste en la gestion de la persistance par le conteneur, dit CMP (Container-Managed

Persistence). Bien que personne à l’époque ne parvienne réellement à faire fonctionner CMP,

l’engouement pour cette technologie est tel que les développeurs la choisissent ne serait-ce

que pour l’ajouter à leur CV.

Techniquement, CMP se révèle incapable de gérer les relations entre entités. De plus, les

développeurs sont contraints d’utiliser les lourdes interfaces distantes (remote). Certains

développeurs en viennent à implémenter leur propre système de persistance géré par les

Beans, ou BMP (Bean-Managed Persistence). Déjà décrié pour sa laideur, ce pattern

n’empêche cependant nullement de subir toute la lourdeur des spécifications imposées par les

EJB.

23/8

Mémoire


2.4.2. TopLink et JDO

A la fin des années 90, aucun framework de persistance n’émerge. Pour répondre aux

besoins des utilisateurs des EJB, TopLink, un mappeur objet-relationnel propriétaire de

WebGain, commence à se frayer un chemin.

TopLink a pour principaux avantages la puissance relationnelle et davantage de

flexibilité de d’efficacité que les EJB, mais au prix d’une relative complexité de mise en

œuvre. Le problème de TopLink est qu’il s’agit d’une solution propriétaire et payante, alors

que le monde Java attend une norme de persistance transparente, libre et unique. Cette norme

universelle voit le jour en 1999 sous le nom de JDO (Java Data Object).

En décalage avec les préoccupations des développeurs, le mapping objet relationnel

n’est pas la préoccupation première de JDO. JDO fait abstraction du support de stockage des

données. Les bases de données relationnelles ne sont qu’une possibilité parmi d’autres, aux

côtés des bases objet, XML, etc. Cette abstraction s’accompagne d’une nouvelle logique

d’interrogation, résolument orientée objet mais aussi très éloignée du SQL, alors même que la

maîtrise de ce langage est une compétence qu’une grande partie des développeurs ont acquise.

D’où l’autre reproche fait à JDO, le langage d’interrogation JDOQL (JDO Query Langage) se

révélant à la fois peu efficace et très complexe.

En 2002, après trois ans de travaux, la première version des spécifications JDO connaît

un échec relatif. Jugeant la spécification incomplète, aucun des leaders du marché des

serveurs d’applications ne l’adopte, même si TopLink propose pour la forme dans ses API une

compatibilité partielle avec JDO.

Du côté des EJB, les déceptions des clients sont telles qu’on commence à remettre en

cause la spécification. Le version 2.0 vient à point pour proposer des remèdes, comme les

interfaces locales ou la gestion des relations entre entités. On parle alors de certains succés

avec des applications développées à partir d’EJB CMP 2.0. Ces quelques améliorations ne

suffisent toutefois pas à gommer la mauvaise réputation des EJB, qui restent trop intrusifs (les

entités doivent toujours implémenter des interfaces spécifiques) et qui brident la modélisation

des applications en ne supportant ni l’héritage ni le threading. A ces limitations s’ajoutent de

nombreuses difficultés, comme celles de déployer et de tester facilement les applications ou

24/8

Mémoire


d’utiliser les classes en dehors d’un conteneur (serveur d’applications). L’année 2003 est

témoin que les promesses des leaders du marché J2EE ne seront pas tenues.

Début 2004, la persistance dans le monde Java est donc un problème non résolu. Les

deux tentatives de spécification ont échoué. EJB 1.x est un cauchemar difficile à oublier pour

les développeurs et JDO 1.x un essai manqué. Quant à EJB 2.0, si elle résout quelques

problèmes, elle hérite de faiblesses trop importantes pour s’imposer.

2.4.3. Un exemple d’ORM : Hibernate

Le 19 janvier 2002, Gavin King fait une modeste publication sur le site

theserverside.com pour annoncer la création d’Hibernate.

Hibernate est lancé sous le numéro de version 0.9. Depuis lors, il ne cesse d’attirer les

utilisateurs, qui forment une réelle communauté. Le succés étant au rendez-vous, Gavin King

gagne en popularité et devient un personnage incontournable dans le monde de la persistance

Java. Coécrit avec Christian Bauer, l’ouvrage Hibernate in Action sort l’année suivante et

décrit avec précision les problématiques du mapping objet-relationnel.

Pour comprendre l’effet produit par la sortie d’Hibernate, il faut s’intéresser à l’histoire

de son créateur, Gavin King.

Avant de se lancer dans l’aventure Hibernate, Gavin King travaillait sur des applications

J2EE à base d’EJB 1.1. Lassé de passer plus de temps à contourner les limitations des EJB

qu’à solutionner des problèmes métier et déçu de voir son code ne pas être portable d’un

serveur d’application à un autre et de ne pas pouvoir le tester facilement, il crée le framework

de persistance Open Source Hibernate.

Hibernate ne va cesser de s’enrichir de fonctionnalités au rythme de l’accroissement de

sa communauté d’utilisateurs. Le fait que cette communauté interagisse avec les développeurs

principaux est une des causes du succés d’Hibernate, et des projets Open Source en général.

Des solutions concrètes sont ainsi apportées très rapidement au noyau du moteur de

persistance, certains utilisateurs proposant même des fonctionnalités auxquelles des

développeurs confirmés n’ont pas pensé.

25/8

Mémoire


Les fonctionnalités clés d’Hibernate mêlent subtilement la possibilité de traverser un

graphe d’objets de manière transparente et la performance des requêtes générées. Critique

dans un tel outil, le langage d’interrogation orienté objet, appelé HQL (Hibernate Query

Language), est aussi simple qu’efficace, sans pour autant dépayser les développeurs habitués

au SQL. C’est d’ailleurs lui que nous avons utilisé pour interroger notre base de données dans

notre application.

La transparence est un autre atout d’Hibernate. Contrairement aux EJB, les POJO (Plain

Old Java Object) ne sont pas couplés à l’infrastructure technique. Il est de la sorte possible de

réutiliser les composants métier, chose impossible avec les EJB.

Dans l’interview d’octobre 2004, Gavin King évoque les limitations de JDO et des EJB.

Pour le premier, les problèmes principaux viennent du langage d’interrogation JDOQL peu

pratique, et de la volonté de la spécification d’imposer la manipulation du bytecode. Pour les

EJB 2.0, les difficultés viennent de l’impossibilité d’utiliser l’héritage, du couplage

relativement fort entre le modèle de les classes métier et l’infrastructure technique, ainsi que

du problème de performance connu sous le nom de n + 1 select.

En septembre 2003, Hibernate rejoint JBoss. A l’époque, l’annonce fait couler beaucoup

d’encre, des rumeurs non fondées prétendant qu’Hibernate ne pourra plus être utilisé qu’avec

le serveur d’application JBoss.

Ce rapprochement vise à encourager les grandes entreprises à adopter un outil Open

Source. Il est en effet rassurant pour ces dernières de pouvoir faire appel à des sociétés de

services afin de garantir le bon fonctionnement de l’outil et de bénéficier des formations. Au-

delà des craintes, JBoss a très certainement contribué à accroitre la pérennité d’Hibernate.

3. Impacts sur les méthodes de développement

Le rôle d’un outil de mapping objet-relationnel tel qu’Hibernate est de faire abstraction

du schéma relationnel qui sert à stocker les objets métier. Les fichiers de mapping permettent

de faire le lien entre le modèle de classes métier et le schéma relationnel. Avec Hibernate, le

26/8

Mémoire


développeur d’application n’a plus à se soucier en théorie de la base de données. Il lui suffit

d’utiliser les API d’Hibernate, notamment l’API Session, et les interfaces de récupération

d’objets persistants.

Les développeurs qui ont l’habitude de JDBC et des ordres SQL tels que SELECT,

INSERT, UPDATE et DELETE doivent changer leur façon de raisonner au profit du cycle de

vie de l’objet. Depuis la naissance d’une nouvelle instance persistante jusqu’à sa mort, en

passant par ses diverses évolutions, ils doivent considérer ces étapes comme des éléments du

cycle de vie de l’objet et non comme des actions SQL menées sur une base de données.

Toute évolution d’une étape à une autre du cycle de vie d’une instance persistante passe

par la session Hibernate.

Tout comme la plupart des frameworks de l’univers J2EE, Hibernate se configure

entièrement à partir de fichiers XML. Le but d’Hibernate étant de lié une table d’une base de

données relationnelle à une classe, cette dernière doit être la plus simple possible. Elle doit

être simplement constituée de plusieurs attributs représentant chaque champ de la table, et des

méthodes permettant de donner une valeur, ou de retrouver une valeur, de ces attributs. Ce

type de classe est connu sous le nom de Plain Old Java Object (POJO). Nous étudierons cette

notion plus en détails un peu plus tard.

Pour ensuite faire correspondre un champ d’une table à un attribut d’un POJO, il faut

crée un fichier de configuration au format XML : un fichier de mapping. Ce type de fichier est

propre à chaque table, il faut donc créer un fichier de mapping par table.

Figure 2.10 : Structure simplifiée d’Hibernate

27/8

Mémoire


Nous verrons donc par la suite la structure et la composition d’un tel fichier.

3.1.1. Les POJOs

Les POJOs ne sont en rien réservés au domaine d’Hibernate. On peut dire que le

principe est aussi vieux que ne l’est la programmation, mais le nom n’a été donné que bien

plus tard.

Après l’apparition des EJBs avec J2EE en 1999, certains développeurs critiquèrent leur

trop grande complexité. Parmi eux, Martin Fowler, qui décida de donner un nom aux objets

basiques en suivant cette pensée : « Nous nous sommes demandés pourquoi tout le monde

était autant contre l'utilisation d'objets simples dans leurs systèmes et nous avons conclu que

c'était parce que ces objets simples n'avaient pas un nom sympa. Alors, on leur en a donné un

et ca a pris tout de suite. »

3.1.2. Les fichiers de mapping

Afin de savoir comment relier nos classes à nos tables dans notre base de données,

Hibernate va aller lire ses fichiers de mapping.

Chaque fichier de mapping doit renseigner précisément pour chaque attribut d’une

classe à quel champ de quel table il doit se référer.

Ces fichiers contiennent donc en quelques sortes une liste des attributs, indique leur rôle

par rapport à la base de données (clef primaire, étrangère ou autre) et bien entendu le nom de

la table et du champ attaché.

Etudions un exemple :

28/8

Mémoire


Figure 2.11 : Exemple d’un fichier de mapping

La racine du fichier est la balise <hibernate-mapping>, indispensable à ce type fichier.

A l’intérieur, la balise <class> indique quelle classe on s’apprête à décrire. Notons qu’il est

possible d’avoir plusieurs classes décrites dans un même fichier dans le cas de classes

dépendantes d’une autre, comme les classes héritées par exemple.

Encore à l’intérieur, la balise <id> décrit l’identifiant de la table et sa méthode

d’incrémentation.

En dessous, une première propriété, une simple chaine de caractères.

Finalement, la dernière balise, est une des plus spécifiques au principe du MOR, et peut être

l’une des plus intéressantes. Comme nous l’avons vu précédemment, une relation (1, n)

entraîne non seulement une migration de la clef d’un côté, mais également une migration

d’une collection d’objets liée à l’instance de l’objet de l’autre côté.

Cela peut être très utile. Dans notre exemple ci-dessus, la table Typesite est une table de

paramètres. Si on cherche, à un moment donné, à charger toutes les sociétés d’un certain type,

pour reprendre l’exemple ci-dessus, il nous suffira de faire une recherche sur le type, qui

possédera une collection de toutes les sociétés appartenant à ce type.

29/8

Mémoire


Il nous est donc possible de récupérer la liste des sociétés en deux lignes de codes.

Habituellement, il faudrait soit passer une requête SQL, soit parcourir la liste des sociétés et

ne sélectionner que celles dont le type correspond.

Toutefois, afin de ne pas effectuer de requêtes inutiles, tout ce qui a un rapport avec une table

étrangère n’est pas chargé par défaut. Il faut spécifier manuellement ce que l’on veut charger.

Cela s’appelle le lazyloading, et nous l’aborderons plus tard.

3.2. Gestion de la session Hibernate

La maîtrise des fichiers de mapping est une chose, l’utilisation correcte d’une API en est

une autre. Dés que l’on sort des exemples simples et que l’on désire essayer d’utiliser

Hibernate dans une application quelque peu complexe, la gestion des instances de

SessionFactory, Session, Transaction et même Configuration1 devient vite délicate.

Il est courant que les utilisateurs se déportent vers des frameworks tels que Spring parce

qu’ils proposent des automatismes de gestion de la session Hibernate. Basculer vers un tel

framework uniquement pour cette raison - même si elle représente un certain confort - est un

mauvais choix. On multiplie de la sorte les dépendances avec d’autres frameworks et on

allonge les délais de mise à jour des frameworks de niveaux inférieurs. En clair, Si une

nouvelle version d’Hibernate est disponible le jour J du début du développement, étant donné

que l’on dépend aussi de Spring, qui encapsule Hibernate, il sera nécessaire d’attendre le

support de cette nouvelle version d’Hibernate par Spring pour profiter des dernières

fonctionnalités.

3.2.1. La session Hibernate

Comme l’explique le manuel de référence d’Hibernate, une session Hibernate a une

durée de vie courte, en accord avec un traitement métier, et, surtout, est threadsafe. Il ne faut

pas considérer la session hibernate comme un cache global. Si deux traitements, ou threads,

1 Objets de l’API Hibernate permettant de gérer les connexions avec la base de données.

30/8

Mémoire


parallèles venaient à utiliser une même session, Hibernate ne pourrait garantir les données. Il

s’agit là non d’une limitation mais d’un choix intentionnel de conception.

Dans les applications web, un thread est facilement identifiable. Une requête du

navigateur s’effectue via une requête HTTP, laquelle s’exécute dans un thread. Comme la

durée de traitement d’une requête HTTP peut être considérée comme très courte dans notre

contexte, il paraît légitime d’associer la durée de vie d’une session Hibernate au traitement

d’une requête HTTP. La courte durée de vie et le fait que la session ne soit pas threadsafe sont

donc respectés.

Un filtre de servlet associé à une classe utilitaire permettent de gérer la session de

manière transparente. Ce couplage est une variante du pattern Thread Local ou encore du

pattern Open Session in View.

La fonction de ces deux patterns très proches est de garantir une bonne gestion de la

session. Leur principal avantage est de permettre à la session de rester ouverte jusqu’à ce

qu’une vue (JSP) soit rendue. Cela s’avère primordial si on injecte des objets persistants dans

nos pages et que certains d’entre eux soient des proxy non initialisés, puisque ce système

permet le chargement tardif des proxy au rendu de la JSP.

3.2.2. La classe utilitaire HibernateUtil

La classe HibernateUtil est une classe qu’il est fortement recommandé d’utiliser lorsque

l’on utilise Hibernate. Elle est basée sur le pattern Singleton. Elle est donc instanciée une

seule fois, et partagée pour toute l’application.

Cette implémentation, que l’on pourrait considérer comme quelques peu banale, est en

réalité un moyen de contourner un « problème » d’Hibernate. Une session s’obtient à partir

d’un objet SessionFactory. Or, cet objet a besoin de recourir aux fichiers de mapping lors de

sa création. Il est donc inconcevable qu’à chaque fois qu’un utilisateur se connecte à

l’application, ou pire, à chaque fois qu’il effectue une requête, que l’application charge à

nouveau les différents fichiers de mapping. L’impact sur les performances serait désastreux,

voire même fatale pour le serveur.

31/8

Mémoire


Cette classe, non présente dans Hibernate, mais recommandée jusque dans la

documentation officielle, s’impose donc de fait. D’un côté, son absence peut paraître étrange

au premier abord, mais d’un autre côté, cela rend la gestion des sessions et des transactions

plus souple.

3.3. Le cycle de vie d’un objet manipulé par Hibernate

3.3.1. Les différents états

Pour être persistant, un objet doit pouvoir être stocké sur un support lui garantissant une

durée de vie potentiellement infinie. Le plus simple des supports de stockage est un fichier qui

se loge sur un support physique. La sérialisation permet, entre autres, de transformer un objet

en fichier.

Hibernate ne peut se brancher sur une base de données objet mais peut travailler avec

n’importe quelle base de données qui dispose d’un pilote JDBC de qualité. Une nouvelle

fonctionnalité permet à Hibernate de traiter des supports XML comme source de donnée.

Les concepts que nous allons aborder ici sont communs à toutes les solutions de

mapping objet relationnel, fondées sur la notion d’état.

La figure 2.12 illustre les différents états d’un objet. Les états définissent le cycle de vie

d’un objet.

32/8

Mémoire


Figure 2.12 : Différents états d’un objet.

Un objet persistant est un objet qui possède son image dans le datastore et dont la durée

de vie est potentiellement infinie. Pour garantir que les modifications apportées à un objet

sont rendues persistantes, c'est-à-dire sauvegardées, l’objet est surveillé par un « traqueur »

d’instances persistantes. Ce rôle est joué par la session dans Hibernate.

Un objet transient est un objet qui n’a pas son image stockée dans le datastore. Il s’agit

d’un objet temporaire, qui meurt lorsqu’il n’est plus utilisé par personne. En Java, le garbage

collector le ramasse lorsqu’aucun autre objet ne le référence.

33/8

Mémoire


Un objet détaché est un objet qui possède son image dans le datastore, mais qui échappe

temporairement à la surveillance opérée par la session. Pour que les modifications

potentiellement apportées pendant cette phase de détachement soient enregistrées, il faut

réattacher manuellement cette instance à la session.

3.3.2. Entités et valeurs

Pour comprendre le comportement, au sens Java, des différents objets dans le contexte

d’un service de persistance, nous devons les séparer en deux groupes : les entités et les

valeurs.

Une entité existe indépendamment de n’importe quel objet contenant une référence à

cette entité. C’est là une différence notable avec le modèle Java habituel, dans lequel un objet

non référencé est un candidat pour le garbage collector. Les entités doivent être explicitement

rendues persistantes et supprimées, excepté dans le cas où ces actions sont définies en cascade

depuis un objet parent vers ses enfants. Les entités supportent les références partagées et

circulaires. Elles peuvent être versionnées.

Un état persistant d’une entité est constitué de références vers d’autres entités et

d’instances de type valeur. Les valeurs sont des types primitifs, des collections, des

composants et certains immuables. Contrairement aux entités, les valeurs sont rendues

persistantes et supprimées par référence (reachability).

Puisque les objets de types valeurs et primitifs sont rendus persistants et supprimés en

relation avec les entités qui les contiennent, ils ne peuvent être versionnés indépendamment

de ces dernières. Les valeurs n’ont pas d’identifiant indépendant et ne peuvent donc être

partagées entre deux entités ou collections.

Tous les types Hibernate, à l’exception des collections, supportent la sémantique null.

Jusqu’à présent, nous avons utilisé les termes classes persistantes pour faire référence

aux entités. Cependant, dans l’absolu, toutes les classes persistantes définies par un utilisateur

et ayant un état persistant ne sont pas nécessairement des entités. Un composant, par exemple,

est une classe définie par l’utilisateur ayant la sémantique d’une valeur.

34/8

Mémoire


3.4. Configuration

La configuration d’Hibernate – les informations de connexion à la base données,

l’emplacement des divers fichiers de mapping, et bien d’autres choses – se fait, comme on

aurait pu le deviner, grâce à un fichier XML.

Voici un aperçu d’un fichier de configuration :

Figure 2.13 : Exemple d’un fichier de configuration

On peut remarquer une chose, nous avons nommé une balise <session-factory>, avec un

attribut nom.

Cette session factory est en charge de nous fournir une session, comme son l’indique, afin

d’accéder à notre base de données. Le nom que nous lui avons donné permet de la retrouver

grâce à JNDI.

3.5. L’outil Hibernate Tools

L’outillage disponible autour d’Hibernate sous le nom d’Hibernate Tools permet

d’accroître la productivité.

L’éditeur de mapping simplifie l’écriture des fichiers de mapping. De leur côté, les

requêtes sont testées rapidement grâce à Hibernate Console tandis que le schéma de base de

données est généré rapidement avec SchemaExport.

35/8

Mémoire


Globalement, il existe deux moyens principaux de développer un projet informatique

selon que l’entreprise possède un historique de conception orientée objet fondé sur la

modélisation du schéma relationnel ou que l’application à développer est destinée à utiliser ou

enrichir un schéma relationnel existant. Dans le premier cas, notre point de départ est la

conception fonctionnelle et dans le second le schéma de base de données.

Si UML est ancré dans l’entreprise, après les spécifications fonctionnelles commencent

les spécifications techniques. Parmi les différents diagrammes entrant en jeu pendant les

phases de modélisation techniques, le diagramme de classes nous permet de modéliser notre

modèle métier.

Un outil de modélisation UML générera assez facilement les sources de nos classes

persistantes. En le personnalisant, il serait possible de générer directement les fichiers de

mapping. Cette personnalisation par un métamodèle définissant

4. Impact sur les performances générales

4.1. Test de performances

Les tests unitaires ne sont pas les seuls à effectuer dans un projet informatique. Ils

garantissent la non-régression de l’application et permettent de tester un premier niveau de

services fonctionnels. Ils doivent en conséquence être complétés de tests fonctionnels de plus

haut niveau.

Ces deux types de tests ne suffisent pas, et il faut éprouver l’application sur ses cas

d’utilisations critiques. Ces cas critiques doivent résister de manière optimale (avec des temps

de réponse cohérents et acceptables) à un pic de montée en charge. On appelle ces derniers

tests « tests de montée en charge » ou « stress test » en anglais. Ils permettent généralement de

tester aussi l’endurance des applications. Load runner de Mercury est une solution qui permet

de tester efficacement la montée en charge des applications. Il existe d’autres solutions, dont

certaines sont gratuites.

36/8

Mémoire


Les stratégies de test de performance des solutions de persistance sont complexes à

mettre en œuvre, car elles doivent mesurer l’impact d’un composant (par exemple, le choix

d’un framework) donné sur une architecture technique physique.

Les éléments à prendre en compte lors d’une campagne de tests de performance sont les

suivants :

flux réseau ;

occupation mémoire du serveur d’applications ;

occupation mémoire de la base de données ;

charge CPU du serveur d’applications ;

charge CPU de la base de données ;

temps de réponse des cas d’utilisation reproduits.

Figure 2.14 : Architecture du test

Cet exemple simplifié vaut pour des applications de type web uniquement. Dans le cas de

client riches, il faudrait aussi intégrer des sondes de mesure sur les clients.

Le site Torpedo (http://www.middlewareresearch.com/) propose une étude comparative des

solutions de persistance. Ce benchmark ne se fonde cependant que sur les le nombre de

requêtes générées par les différents outils pour une application identique. De plus, le cas

d’utilisation employé est d’une grande simplicité, puisqu’il consiste en la manipulation d’un

modèle métier de moins de cinq classes persistantes.

Un tel comparatif est d’un intérêt limité. En effet, les outils de persistance sont bien plus

que de simples générateurs de requêtes SQL. Ils gèrent un cache et la concurrence et

permettent de mapper des modèles de classes relativement complexes. Ce sont sur ces

37/8

Mémoire


fonctionnalités qu’il faut les comparer. De plus, un outil générant deux requêtes n’est pas

forcement moins bon que son concurrent qui n’en gère qu’une. Enfin, une requête SQL

complexe peut s’exécuter dix fois plus lentement que deux requêtes successives pour un

même résultat.

Dans cette optique, le test de performance suivant permet de constater qu’une mauvaise

utilisation d’Hibernate peut impacter dangereusement les performances d’une application. Il

démontrera à l’inverse qu’une bonne maîtrise de l’outil permet d’atteindre des performances

proches d’une implémentation à base de JDBC. Ce test a été réalisé par Anthony Patricio, un

des membres de l’équipe d’Hibernate

La figure 2.15 illustre une portion du diagramme de classes d’une application métier

réelle qui entre en jeu dans un cas d’utilisation critique. Ce qui est intéressant ici est que ce

graphe d’objets possède plusieurs types d’associations ainsi qu’un arbre d’héritage.

Figure 2.15 : Modèle objet ayant servit au test

La base de données stocke :

38/8

Mémoire


- 600 instances de la classe A.

- 7 instances de la classe B.

- 50 instances de la classe C.

- En moyenne, 5 instances de la classe D sont associées par instance de la classe A.

- 150 instances de la classe E.

- 10 instances de la classe F, dont 7 de F2 et 3 de F1.

- 20 instances de la classe G et 1 de H.

Comme on peut le constater, la base de données est volontairement peu volumineuse.

Concernant l’architecture logicielle, l’objectif est de mesurer l’impact d’une mauvaise

utilisation d’Hibernate sur le serveur et les temps de réponse. Les testeurs ont donc optés pour

une implémentation légère à base de servlets (avec Struts) et d’Hibernate, le tout tournant sur

Tomcat. Les configurations matérielles des machines hébergeant le serveur Tomcat et la base

de données relationnelles (Oracle) sont de puissance équivalente. La problématique réseau est

masquée par un réseau à 100 Mbit\s.

L’objectif est de mesurer l’impact d’une mauvaise utilisation d’Hibernate avec un petit

nombre d’utilisateur simulés (une vingtaine).

L’énumération des chiffres des résultats du test n’est pas importante en elle-même. Ce

qui compte est avant tout leur interprétation. Alors que le nombre d’utilisateurs est faible, une

mauvaise utilisation d’Hibernate double les temps de réponse, multiplie par quatre les allers-

retours avec la base de données et surcharge la consommation CPU du moteur de servlets. Il

est facile d’imaginer l’impact en pleine charge, avec plusieurs centaines d’utilisateurs.

Il est donc essentiel de procéder à une expertise attentive d’Hibernate pour ses

applications. Mal maîtrisé, un tel outil peut apporter plus de problèmes qu’en résoudre dans

un projet. Dans le cas contraire, il peut apporter des gains de temps en développement

considérables sans pour autant freiner de manière excessive les performances.

4.2. Les caches

39/8

Mémoire


Hibernate propose deux niveaux de cache. Le premier niveau est spécifique à chaque session

crée par Hibernate. Le second est partagé entre toutes les sessions Hibernate en cours :

Cache de niveau 1 : Hibernate stocke tous les objets persistants dans une zone de travail

propre à chaque session. Il permet de limiter le nombre d’accès en base de données pour

une session donnée. Ce cache ne peut être désactivé mais vider à la demande.

Cache de niveau 2 : contrairement au précédent cache, celui-ci est optionnel et commun à

toutes les sessions Hibernate. Il est possible de choisir en plusieurs implémentations de

cache niveau 2 – EHCache, JBossCache, OSCache… Ce cache permet d’accroître les

performances sur les points les plus sollicités de l’application. Il propose des stratégies en

lecture seule ou lecture et écriture.

5. Vers une solution unique

Gavin King, qui a crée Hibernate pour pallier les lacunes des EJB 1.1, a depuis lors rejoint

le groupe d’experts chargé de la spécification JSR 220 des EJB 3.0 au sein du JCP (Java

Community Process).

La figure 2.16 illustre l’historique de la persistance en mettant en parallèle EJB, JDO et

Hibernate. Les blocs EJB Specs et JDO Specs ne concernent que les spécifications et non les

implémentations, ces dernières spécifications (JSR 243 pour JDO 2.0 et JSR 220 pour EJB

3.0) ne sont pas encore finalisées au premier trimestre 2005. Les détails sont consultables à

l’adresse http://www.jcp.org/en/jsr/all.

40/8

Mémoire


Figure 2.16 : Historique des solutions ORM.

Deux raisons expliquent la coexistence des spécifications EJB et JDO. La première est

qu’EJB couvre beaucoup plus de domaines que la seule persistance. La seconde est que

lorsque JDO est apparu, EJB ne pas efficacement aux attentes de la communauté Java.

Depuis la donne a changé. Il paraît désormais inutile d’utiliser conjointement EJB 3.0 et

JDO 2.0. C’est la raison pour laquelle la proposition de spécification JSR 243 a été refusée

par le JCP le 23 janvier 2005. Le problème est qu’en votant non à cette JSR, le JCP ne

garantissait plus la pérennité de JDO, alors même qu’une communauté existe déjà. La réaction

de cette communauté ne s’est pas fait attendre et a nécessité un second vote, cette fois

favorable, le 7 mars 2005.

L’existence des deux spécifications est elle une bonne chose ? A l’évidence, il s’agit d’un

frein à l’adoption d’une seule et unique spécification de persistance. Certains estiment

toutefois que le partage du marché est sain et que la concurrence ne fera qu’accélérer l’atteinte

d’objectifs de qualité. Un effort important est cependant déployé pour que les deux

spécifications finissent par se rejoindre à moyen terme.

Pour atteindre cet objectif, l’adhésion des vendeurs de serveurs d’applications sera

décisive. Historiquement, ils ont déjà renoncé à JDO et sont liés aux EJB. Leader du marché,

JBoss implémente déjà la plupart des spécifications EJB 3.0. Oracle, propriétaire actuel de

TopLink, a également produit une implémentation des EJB 3.0 pour son serveur

d’application.

L’apparation des EJB 3.0 a solutionné les problèmes suivant :

41/8

Mémoire


Les classes persistantes ne sont plus liées à l’architecture technique puisqu’elles n’ont plus

besoin d’hériter de classes techniques ni d’implémenter d’interfaces spécifiques.

La conception objet des applications n’est plus bridée et l’héritage est supporté.

Les applications sont faciles à tester.

Les métadonnées sont standardisées.

42/8

Mémoire


III. Développement et mise en place d’un outil de GRC

1. Contexte

1.1. Relation du stage précédent

Ce stage est la continuité de celui que j’avais entrepris l’année dernière, dans le cadre de

ma deuxième année d’ingénierie. Pendant ce stage, j’avais été amené à réaliser toute la partie

analyse et étude du besoin pour la conception d’un outil de gestion de la relation client

(GRC), en collaboration avec un autre stagiaire d’une autre école.

Infotel dispose actuellement d’un outil, nommé « Sales », pour que ses commerciaux

puissent gérer leurs contacts et leurs affaires. Mais les performances de ce dernier laissant à

désirer, et étant bâti autour d’une technologie vieillissante – MS Access – Infotel Toulouse à

décidé d’entreprendre la création d’un nouvel outil et d’en confier le développement à son

antenne de Bordeaux.

Mon stage de l’année précédente consistait donc dans un premier temps à réaliser une

étude du besoin et à rechercher dans le monde de l’open source si un outil pouvant répondre

au besoin. Après avoir passé en revu de nombreux logiciels, nous en sommes venu au fait que

très peu d’entre eux pouvaient répondre au besoin assez spécifique d’Infotel. Nous en avons

néanmoins sélectionné une demi-douzaine, pour les étudier plus en détails. Bien que leur

couverture fonctionnelle était assez pauvre vis à vis de notre projet, certaines de leurs

caractéristiques étaient assez intéressantes pour être reprises et inclut dans nos spécifications

détaillées.

Au final, nous avons décidé de partir d’un projet vide, basé sur la technologie J2EE,

avant tout dans un but pédagogique. Nous avons donc réalisé un dossier d’architecture – sorte

de nomenclature des différents outils de développements et technologies utilisés – et conçu

43/8

Mémoire


une première maquette de l’application. Nous avons ainsi fait les premières étapes d’un cycle

en V précédant le codage :

Figure 3.1 : Cycle en V

1.2. Objectifs du stage

Avant de commencer ce stage, il était clair que l’objectif principal de celui-ci serait

d’achever l’application de gestion de la relation client. Toutefois, nous avons très vite appris

que l’application de GRC n’était pas la seule en cours de restructuration.

A l’initiative d’Infotel Toulouse et en collaboration avec Infotel Bordeaux, les

développements internes ont été normalisés et mutualisés. Un document avait même était crée

pour établir certaines normes de choix techniques, mais également certains éléments plus

basique de programmation : utilisation de pattern, proscription d’anti-pattern.

Ainsi, en plus de devoir respecter certaines normes de développement, notre application

et les autres en cours de développement se devaient de partager des composants communs. A

terme, Infotel souhaite pouvoir créer rapidement de nouvelles applications à partir des

anciennes, en réalisant par exemple un framework interne.

Toutefois, notre objectif principal restait d’achever le développement de cette application,

jusqu’à sa mise en place sur un serveur de production. Cela ne se résume donc pas

simplement à de la programmation. Une phase importante de tests, la reprise des données de

44/8

Mémoire


l’ancien système d’information et la rédaction de la documentation utilisateur et de la

documentation technique sont autant d’aspects à ne pas négliger.

Dans son ensemble, sur une durée totale de neuf mois, j’aurais ainsi pu aborder

l’ensemble des phases de gestion d’un projet.

1.3. L’équipe de développement

J’ai effectué la totalité de ce stage en collaboration avec au moins une personne.

Contrairement à l’année précédente, l’équipe a été en constante évolution tout au long du

stage.

Pendant les premières semaines, j’étais avec le même collègue que mon stage de l’année

dernière, un élève en 3ème année d’ingénierie. Puis très vite, nous avons été mis en contact

avec une stagiaire d’Infotel Toulouse en master 2 en informatique. L’équipe de Toulouse a

par la suite grossit pour atteindre quatre stagiaire, répartis sur deux projets internes. De notre

côté, un étudiant en master 1 en informatique nous a rejoint en mai, suivi par un élève de

deuxième année d’ingénierie de l’EPSI en juin. Le premier des deux arrivants ayant déjà une

expérience de développement en J2EE, il a pu participer au développement. En revanche le

deuxième, arrivé plus tardivement et n’ayant pas de réels expérience dans ce domaine nous a

prêté main forte sur les taches de fin de projet.

D’un point de vue commutation, il n’y a pas eu de réels soucis à Bordeaux. Nous

occupions une salle, séparée de l’équipe de développement salariée. Nous pouvions donc

parler librement, nous déplacer, ou nous montrer nos écrans. Cela fut forcément un peu plus

délicat pour Toulouse. En effet, nous avions la possibilité de communiquer soit par courrier

électronique, soit par téléphone, et pouvions échanger des documents et des données via un

serveur commun ou un espace nous était réservé. Malgré cela, les projets, des deux côtés,

étant en constante évolution, il n’était pas toujours aisé de tenir au courant l’équipe

toulousaine des changements et de l’évolution des spécifications fonctionnelles et

réciproquement. Le point le plus épineux résidait dans le développement de composants

communs, qui devaient répondre aux besoins de plusieurs applications. Ces composants ne

45/8

Mémoire


pouvaient être développés que par une équipe simultanément. Nous nous sommes donc

partagés la création des ces composants.

1.4. Les ressources matérielles

En ce qui concerne le matériel, nous disposions bien entendu chacun d’un ordinateur

personnel, relié au réseau de l’entreprise. Nous avions également accès au serveur CVS

(Concurrent Versions System).

Le principe d’un serveur CVS est de déposer les sources d’un projet sur un serveur

unique et centralisé. De ce fait, il évite aux développeurs de devoir s’échanger manuellement

les fichiers qu’ils viennent de créer, modifier.

Un serveur de démonstration a également été mis en place, pour que toutes les

personnes concernées par le projet puissent avoir accès à n’importe quel moment à notre

prototype. Ce serveur a été mis en place au cours du mois de mai, dés la réalisation d’un

prototype possédant déjà un certain nombre des fonctionnalités demandées.

1.5. Portée du stage

A l’origine, cette application devait uniquement remplacé l’ancienne application de

gestion de la relation client – Sales – pour les raisons citées précédemment. Cependant, nous

avons appris, mon collègue et moi-même, que cette application serait également utilisé sur les

sites de Nantes et Rennes, qui ne disposait à ce jour ni de Sales, ni de réel outil de GRC. Ce

nouveau besoin a été confié à mon maître de stage par m. Jean-Marie Meyer, directeur

d’Infotel Grand Ouest (Toulouse, Bordeaux, Nantes et Rennes) se situant à Toulouse.

1.6. La gestion du projet

Comme il l’a été dit précédemment, nous avons adopté un cycle en V pour créer ce projet.

Un des points très appréciable et très enrichissant de ce stage fut que la gestion du projet nous

46/8

Mémoire


avait été confiée. Bien entendu, nous n’étions responsable du travail de personne, ni ne

donnions de tâches à personne. Mais nous étions tenus de tenir certains délais, d’établir et de

présenter un planning de développement à notre maître de stage et de nous répartir les taches

entre nous quatre. Cela ne paraît pas évident à première vue, et ne l’est en effet pas toujours !

Estimer avec justesse une tache de développement relève de l’empirisme. Or, quand on

aborde un terrain inconnu, ici le J2EE et ses multiples frameworks et bibliothèques, il ne reste

que l’expérience passé sur d’autres projets et sur d’autres technologies.

Nous avions également une relative liberté d’un point de vue choix technologiques.

Relative, car nous avions certaines contraintes en rapport avec les serveurs de production

d’Infotel. Certaines parties n’en avaient en revanche aucune et nous laissait donc le choix.

Dans cette partie, après avoir présenté l’application réalisée au cour de ce stage, nous

parcourrons les cinq dernières étapes du cycle en V. Pour la partie codage, je parlerai

principalement de l’architecture choisie et des frameworks utilisés pour développer

l’application, car cela représente une partie significative de mon stage. Je ne traiterais pas le

code produit par ceux-ci, mais plutôt l’apport qu’ils apportent en termes de gestion de projet.

2. L’application

2.1. Genèse du projet

Le principal rôle d’une application de gestion de relation client est de conserver une

trace de tout événement ayant eu lieu avec un client ou un contact de l’entreprise. La GRC a

pour but de fidéliser le client et de lui fournir une qualité de service optimale. La finalité est

donc de lui procurer un sentiment de service personnalisé. En clair, cela signifie

principalement de pouvoir enregistrer un maximum d’informations pertinentes concernant un

client et de pouvoir y accéder simplement.

Des logiciels de ce type existent évidemment déjà sur le marché, dans le monde du libre

comme dans celui du payant. Une étude menée l’an passé nous a révélée que chacun de ces

logiciels ne dispose que d’une pauvre couverture fonctionnelle et d’une architecture trop

lourde pour être reprise efficacement. L’application réalisée au cours de ce stage a été

développé depuis un projet vide, de manière à parfaitement s’adapter aux exigences d’Infotel.

47/8

Mémoire


2.2. Les besoins fonctionnels

Les commerciaux d’Infotel disposent d’un accès à un logiciel de GRC avec une base de

données commune à toutes les agences. Un commercial est lié à une et une seule agence.

Cette agence gère plusieurs sociétés, et assigne à chacune au moins un commercial, ou

plusieurs dans le cas de clients importants. Un commercial peut s’occuper de plusieurs

sociétés en même temps. Ces sociétés possèdent toutes au moins un contact avec qui les

commerciaux communiquent. Une société peut bien entendu posséder plusieurs contacts.

Lorsqu’un commercial d’une agence et un contact d’une société échangent des

informations de quelque manière que ce soit (e-mail, téléphone, rendez-vous…), cela donne

lieu à un événement. Un événement s’inscrit dans un contexte que l’on appelle une affaire.

Une affaire est donc en réalité un ensemble d’événements, de même type (prospection, vente

d’un logiciel), relatifs à une société. Un événement n’est donc lié qu’à un seul commercial et

un seul contact. Une affaire, elle, n’est pas liée aux contacts et seuls les contacts de la société

et les commerciaux gérant celle-ci pourront générer un événement dans cette affaire.

Chaque affaire possède une plate forme technologique, c'est-à-dire un ensemble de

détails techniques qu’il est nécessaire de connaitre lors de l’affaire. En bref il s’agit du

matériel et de l’ensemble des technologies mis à disposition par la société pour l’affaire. La

durée maximale d’une affaire étant indéfinie, une société peut changer de plateforme

technologique, ou en posséder de nouvelles au fil du temps. C’est pour cela qu’une affaire, et

par conséquent une société, peuvent posséder plusieurs plateformes technologiques.

Il est possible qu’une société appartienne à un ensemble de sociétés : un groupe. Une

société n’étant désignée que pour une seule adresse géographique, il peut s’agir simplement

d’une des agences de cette société (un exemple : France Télécom Bordeaux lac, membre du

groupe France Télécom).

Nous avons réalisé la conception du MCD (cf. Annexe I) et du MPD (cf. Annexe II) de

cet existant.

48/8

Mémoire


2.3. Ergonomie

L’ergonomie de l’application fut un point très discutée de l’application sur laquelle nous

avons du revenir à plusieurs reprises pour toujours satisfaire les exigences d’Infotel. Une

première maquette avait été réalisée un an auparavant, en version statique (HTLM, CSS et

javascript). Nous n’avions eu des retours sur celle-ci de la part de seulement deux

commerciaux. Au début de stage, nous avons heureusement eu les impressions de l’ensemble

des commerciaux toulousains et bordelais, ainsi qu’une contrainte supplémentaire

d’homogénéisation des applications internes à Infotel. L’interface a donc complètement été

repensée, comme en témoigne les annexes I et II.

Le premier gros changement s’est effectué au niveau de la navigation par pop-up. En

effet, un système de navigation sur différentes fenêtre est en règle générale plus adaptée à un

interface d’un client lourd qu’à celle d’une application web. Les pop-up ont donc été

supprimés. Leur contenu devant désormais s’afficher dans la fenêtre principale.

Le deuxième changement notable s’est fait sur le menu. A l’origine disposé en haut de

l’application, horizontalement, il a été déplacé sur la gauche et devait s’affiché alors

verticalement. Nos anciens pop-up contenant des onglets, il a fallu trouver une alternative à

ceux-ci : chaque point de menu devait disposer alors d’un sous menu, donc chaque partie

représente un onglet.

Enfin, on notera également que l’entête a subi une forte diminution de hauteur, de

manière à ne pas occuper une trop grande proportion de l’écran pour les faibles résolutions, et

l’apparition d’un pied de page.

Nous avons ensuite élaboré les différents composants de la maquette (tables, barre de

recherche, formulaires, etc…) en intégrant et en mélangeant les divers composants crées dans

les précédentes maquettes des logiciels de GDA, développé par l’équipe toulousaine et de

GRC.

49/8

Mémoire


2.3.1. La barre de recherche

Cette barre de recherche est l’origine fortement inspirée d’un logiciel de GRC libre :

vTiger. Elle a toutefois subit quelques modification pour coller parfaitement au besoin

d’Infotel.

Le principe de cette barre est très simple. Elle est tout d’abord constitué de trois champs

texte, chacun associé à un combo box, contenant une liste de champs de recherche – comme

par exemple nom, ville, code postal, etc…. Il est donc possible d’effectuer grâce à cette barre

une recherche en précisant simultanément trois critères. Pour une recherche plus rapide, il est

également possible de n’afficher que des entités ne commençant que par une lettre donnée de

l’alphabet, en cliquant sur un des 26 boutons prévus à cet effet.

Le but de cette barre est avant tout de trouver et d’accéder rapidement à une

information, et non d’afficher une quelconque liste statistique.

2.3.2. Le fil d’Ariane

Ce composant est présent sur de nombreux sites, car il présente deux gros atouts pour

l’utilisateur :

Il permet de se situer dans l’application : après avoir ouvert et refermer plusieurs

sections, il n’est pas toujours évident de savoir où l’on se situe par rapport à la racine

de l’application.

Il permet de revenir rapidement en arrière : une fois l’information acquise, il est

possible grâce à cet élément de revenir à n’importe quel endroit de l’application

précédemment ouvert.

Remarque : ce composant est en général présent sur des sites tels que les forums.

50/8

Mémoire


2.3.3. Le menu

Le menu possède une petite particularité donc il est intéressant de parler ici. Bien que

statique à première vue, ce menu peut ouvrir un sous menu en fonction du point de menu sur

lequel l’utilisateur a cliqué. En effet, les liens contenus dans les sous menu n’auraient aucun

sens si un certain contexte n’avait pas été ouvert préalablement.

Prenons par exemple le point de menu « Sociétés ». En cliquant dessus, l’application

affiche la liste des sociétés connus. Le menu reste pour l’instant inchangé. En revanche, en

cliquant sur une des sociétés de la liste affiche les informations relatives à celle-ci, ainsi que le

sous menu « Société », contenant des liens supplémentaire permettant d’afficher les contacts

de cette sociétés, sa liste d’affaire ou des informations sur sa plateforme technologique.

Si l’utilisateur clique ensuite le point de menu « Affaires », le sous menu se ferme, et le

menu revient à son état initial.

Ce type de menu permet donc de regrouper les informations concernant une entité en

différentes catégories, à la manière des onglets.

2.4. Fonctionnalités

On peut diviser l’application en trois sections distinctes :

2.4.1. Section accès aux données

Cette partie regroupe les points de menu « Sociétés », « Contacts », « Affaires » et

« Evénements ». A l’intérieur de cette section, chaque rubrique se comporte grosso modo de

la même manière. Chacune d’entre elles permet soit de visualiser des informations saisies

dans la base de données, soit d’en insérer de nouvelles.

Le schéma de navigation se déroule toujours de la même manière : en cliquant sur une

des rubriques, une première page contenant une barre de recherche – décrite précédemment -

et une table de données vide s’affiche. En effet, l’application n’effectue aucune requête non

51/8

Mémoire


spécifiée par l’utilisateur. Ainsi, à partir de cette page, il est possible soit d’ajouter une

nouvelle entité soit d’effectuer une recherche afin d’accéder à une information particulière.

Dans le cas d’un ajout, un formulaire permettant d’enregistrer une nouvelle entité

s’affiche alors.

Dans le cas d’une recherche, les entités répondant aux critères spécifiés seront affichés

sur la même page, dans la table qui était jusqu’à présent vide. Les résultats sont paginés sur un

nombre prédéfini dans les spécifications de manière à ne pas surcharger le serveur et à garder

une bonne lisibilité pour l’utilisateur. Un clic sur une des lignes de cette table affichera les

informations détaillées sur l’entité représentée par ces lignes. Ces informations sont

présentées dans un formulaire similaire à celui de l’ajout, mis à part que les champs sont bien

entendu remplis.

2.4.2. Section états et statistiques

Actuellement, cette partie permet seulement d’afficher et d’imprimer des états, via la

rubrique « Reporting » du menu. Elle a été nommée ainsi en prévision de futures fonctions,

notamment l’affichage de statistiques, qui pourraient être demandées dans une prochaine

version.

En réalité, cette partie ne permet donc pour l’instant que d’afficher une liste d’états. Ces

états peuvent être affichés sous différents formats (PDF, Excel, Word) ou être imprimés

directement.

2.4.3. Section administration

Cette section est, comme son nom l’indique, réservée aux administrateurs. Elle permet

de modifier les tables de paramètres, comme par exemple la table « civilité », de gérer les

comptes utilisateurs et les différentes agences d’Infotel.

L’application GRC comporte une douzaine de tables de paramètres. Il a été décidé de ne

pas laisser aux utilisateurs la possibilité d’enrichir ces tables, pour éviter qu’elles deviennent

trop volumineuse et donc difficilement utilisables. C’était par exemple le cas dans l’ancienne

52/8

Mémoire


application, « Sales ». On pouvait y recenser plus de cinquante fonctions de salariés

différentes.

3. L’architecture technique

D’un point technique, ce projet possède une seule contrainte, celle de réaliser un client

léger. Plusieurs type d’architecture sont possibles pour réaliser une application de ce genre :

PHP/MySql, J2EE, Ruby on Rails, Ajax, DotNet etc.…

Dans un but pédagogique, afin que nous nous formions et acquérions une nouvelle

expérience pendant ce stage, il a été décidé que nous développerions ce logiciel autour d’une

architecture très populaire à l’heure actuelle : J2EE.

3.1. Introduction à J2EE.

3.1.1. Définition.

Comme son nom l’indique, Java 2 Enterprise Edition est destiné aux gros systèmes

d’entreprises. Les logiciels employés à ce niveau ne fonctionnent pas sur un simple PC mais

requièrent une puissance beaucoup plus importante. Pour cette raison, les applications doivent

être constituées de plusieurs composants pouvant être déployés sur des plates-formes

multiples afin de disposer de la puissance de calcul nécessaire.

En effet cette technologie, qui est totalement gratuite, fournit un ensemble de composants

standardisés facilitant le déploiement des applications, des interfaces définissants la façon

dont les modules logiciels peuvent être interconnectés, et les services standards grâce

auxquels ces modules peuvent communiquer.

53/8

Mémoire


3.1.2. Pourquoi J2EE ?

J2EE met à la disposition du développeur toute une infrastructure, une multitude de services,

nécessaires au développement d’applications d’entreprise. Un grand nombre de

fonctionnalités sont mises à contribution au niveau système de façon à produire des

applications robustes, sûres, faciles à entretenir et susceptibles d’accompagner

l’accroissement des besoins.

Concevoir une infrastructure distribuée n’est pas une mince affaire. C’est pourquoi les

architectures basées sur J2EE sont intéressantes. Tous les éléments fondamentaux sont déjà en

place. Concevoir une infrastructure spécialement adaptée à des besoins spécifiques

nécessiterait un temps et un investissement considérables. De plus, même en cas de succès,

cette infrastructure ne pourrait recevoir aucun composant standardisé et ne pourrait interagir

avec aucune autre application développée par ailleurs. Cela impliquerait donc un travail

considérable pour une solution non satisfaisante.

3.1.3. L’architecture multitiers

Une des thèmes récurrent du développement d’applications J2EE est la décomposition

de celles-ci en plusieurs niveaux, ou tiers (de l'anglais tier, signifiant étage ou niveau). Il

s’agit là d’une des pierres angulaires de J2EE, ce qui justifie une petite explication.

Une application est composée de trois couches fondamentales.

La première a pour rôle d’afficher les données pour l’utilisateur, et de collecter les

informations qu’il saisit. Cette interface est appelée couche de présentation car sa

fonction consiste à présenter les données à l’utilisateur et à lui permettre de fournir des

informations au système. La couche de présentation est la partie de l’application

responsable de la création et du contrôle de l’interface présentée à l’utilisateur et de la

validation de ses actions.

Sous cette couche de présentation, on trouve la logique métier qui permet à

l’application de fonctionner et de traiter les données. Dans une application de paye par

exemple, la logique métier multiplie les heures travaillées par la salaire horaire pour

54/8

Mémoire


déterminer combien chaque employé doit toucher. La logique métier est mise en

œuvre à partir des règles métiers. Cette partie de l’application constitue l’essentiel du

tiers médian.

Toutes les applications d’entreprise ont besoin d’écrire et de lire des données. Cette

fonctionnalité est assuré par la couche d’accès aux données également appelée

couche de persistance, qui assure la lecture et l’écriture à partir de différentes sources.

L’architecture J2EE est basée sur une la notion d’application n-tiers. Grâce à cette

architecture, il est facile de construire des applications performantes et fiables basées sur des

applications à 2, 3 ou n-tiers (généralement 5). J2EE fournit toute l’infrastructure nécessaire.

Figure 3.2 : Architecture 5-tiers

3.2. Choix du serveur Web/applicatif J2EE.

Nous n’avions que peu d’expérience vis-à-vis des différents serveurs applicatifs J2EE.

Le rapport d’architecture que nous avions pour référence préconisait l’utilisation de JBoss, un

55/8

Interface utilisateur

Modèle métier

Règles métier

Correspondance Objets

métier/sources de données

Accès aux données

Mémoire


logiciel libre et gratuit. En effet, dans le domaine des serveurs d’applications libre, seuls

existent JOnAS et JBoss AS.

JBoss est soutenu par une large communauté de développeurs, et on peut ainsi trouver

beaucoup d’informations à son sujet sur Internet. Il met en œuvre la technologie JMX

Microkernel pour la gestion et l’administration du serveur Applicatif. Cette technologie le

rend modulaire, extensible, et permet l’administration de l’ensemble des services activés dans

JBoss sous une interface Web unique.

Le serveur Applicatif JBoss qui intègre le moteur de servlet Tomcat présente les

caractéristiques suivantes :

Bonne performance ;

Serveur application largement répandu et Open Source ;

Multi plateforme

Support complet de la norme J2EE 1.4 (serveur applicatif certifié)

possibilité d’administration de l’ensemble des services au travers d’une interface Web

unique ;

déploiement à chaud d’applications ou de composants.

Au vue de ses qualités, nous l’avons donc choisi pour notre projet.

3.3. Choix de la version de la machine virtuelle Java (JVM).

La plate-forme J2EE définit un ensemble de services normalisés (JDBC, JCA, Servlet,

JSP, JDO, JavaMail, EJB, JMS, JNDI, XML, Web Services, …) qui permettent de

standardiser le développement des systèmes d’information d’entreprise en java. L’utilisation

de ces services garantit aux applications la pérennité et leur assure la compatibilité avec la

totalité des serveurs d’application conformes à la norme.

On définit plusieurs niveaux de version pour la plate-forme J2EE, celle-ci étant

considérée habituellement comme suffisamment complète et mâture à partir de la version 1.2.

La conformité à la norme J2EE 1.2 est donc un seuil minimal à respecter. La dernière norme

publiée par Sun est J2EE 1.5 (JEE 5.0).

56/8

Mémoire


Or, le serveur applicatif choisi, JBoss AS, est certifié compatible J2EE 1.4 depuis juillet

2004. Toutefois il a depuis implémenté un support partiel de la JVM 1.5, surtout avec les EJB

3, qui incluent les génériques et les annotations.

Pour cette raison, nous choisissons J2EE 1.5.

3.4. Choix de la base de données.

En ce qui concerne la base de données, notre choix s’était rapidement tourné vers

PostgreSQL. Ce système de gestion de base de données est un produit libre, basé sur une large

communauté de développeurs et d’entreprise, et était de plus préconisé pour les applications

internes à Infotel. Cependant, il nous a été communiqué au cours du développement que le

SGBD utilisé sur les serveurs de recette et de production est en réalité MySQL. Nous avons

ainsi du effectuer une rapide migration.

Pour accéder à ses données, il nous un système qui assure la couche de persistance des

données. Il nous a été conseillé d’utiliser le Framework Hibernate, qui est également libre et

Open Source. En effet, il est parfaitement compatible avec notre serveur applicatif, et ne

restreindra pas les fonctionnalités de celui-ci.

Pour finir, nous utiliserons les drivers de l’API Java DataBase Connectivity propre à

notre SGBD.

3.5. Synthèse de l’étude.

L’architecture proposée se base sur les éléments suivants:

le moteur de servlets Tomcat 5.5 ;

le serveur EJB JBoss 4.0.4 ;

le serveur web Apache 2.2.3

un ensemble de pages JSP (dynamiques) ;

une base de données MySQL.

Cette architecture présente les caractéristiques suivantes :

57/8

Mémoire


multiplateforme;

évolutivité;

coût de licence nul (utilisation de logiciels libres);

respect de la norme J2EE 1.4.

Le schéma ci-dessous présente l’architecture retenue:

Figure 3.3 : Schéma de l’architecture de la GRC.

4. L’architecture

La phase de codage à proprement parler a commencé un mois après le début de mon

stage et a duré trois mois. Je présenterais les différentes parties du développement en fonction

des couches à laquelle elles appartiennent, et non dans l’ordre chronologique de leur

traitement. Les spécifications pouvant rapidement évolué, nous avons du revenir de temps à

autre sur certaines d’entre elles.

En présentant l’architecture partie par partie, je vais donc montrer ce qu’aurait était un

développement fait « d’un bloc », avec des spécifications fixes. En effet, structurer un

programme en couches permet d’améliorer sa maintenabilité et de mieux répartir les

ressources humaines.

58/8

Mémoire


Lors du début du développement nous n’étions que deux et avions besoin de voir tous

les aspects d’une application 5-tiers. La répartition des taches s’est donc fait par modules,

plutôt que par couche.

4.1. Interface utilisateur

4.1.1. La maquette

L’objectif dans un premier temps était de concevoir une interface utilisateur dont

l’ergonomie conviendrait à toutes les applications interne en cours de développement. Lors de

la réunion du 22 mars, nous avons présenté notre maquette aux commerciaux d’Infotel

Toulouse et celle-ci n’a pas fait l’unanimité. La navigation a été tout d’abord remise en

cause : basée sur un système de pop-up et d’onglets, elle ne suivait pas les standard du web

pour certains. Bien que cette spécification n’ait pas été la seule à avoir été discuté, elle seule

suffisait pour nous faire refaire une autre maquette et de repenser complètement l’ergonomie.

Nous avons pu profiter de cette journée à Toulouse pour avoir un aperçu d’un des projets

toulousains – la gestion des candidatures (GDC) – et nous apercevoir des grosses divergences

d’un point de vue interface. D’une manière générale, seulement quelques spécifications

générales furent modifiées, mais une grosse partie des spécifications détaillées était à revoir.

A notre retour nous avons donc dans un premier temps réalisé une maquette, ou plutôt ce

que nous appellerons des modèles. Ces modèles sont en réalité deux ou trois pages d’exemple,

montrant la disposition des différents éléments d’une page (menu, fil d’Ariane, barre de

recherche, etc…), la structure elle-même des pages et de manière plus basique, les couleurs,

les polices et tout autre effet de style.

Du fait que nous n’ayons eu que quelques pages à réaliser, et que nous nous sommes

inspirés du meilleur des deux précédentes maquettes, celles de la GRC et de la GDC, cette

tache fut accompli en l’espace d’une semaine, bien plus rapidement que l’année précédente. A

la fin du premier mois de stage, nous étions donc presque aptes à commencer le

développement. Presque, car le framework à utiliser pour la couche présentation n’avait

toujours pas été décidé, et celui devait faire l’objet d’une étude.

59/8

Mémoire


4.1.2. Choix d’un framework de présentation

Une des tâche que nous devions accomplir dans les plus brefs délais était de choisir un,

ou plusieurs, frameworks de présentation. Pendant la réunion de Toulouse, nous en avions

retenu trois : Struts, JSF et Shale.

4.1.2.1. Struts

Struts est né d’un besoin de séparation entre l’interface utilisateur, les données, et les

actions. Il fait partie du projet Jakarta de l’Apache Sotfware Foundation. Il est de ce fait open-

source et bénéficie d’apports constants des développeurs de part le monde.

Ce framework permet la conception et l'implémentation d'applications Web de taille

importante et d'être gérées par différents groupes de personnes. En d'autres termes, les

designers, développeurs de composants logiciels peuvent gérer leur propre part du projet de

manière découplée. De plus, Struts est basé sur le design pattern MVC2.

D’un point de vue isolation des couches, il est très intéressant, car il s’appuie sur

l’architecture Modèle Vue Contrôleur (MVC) :

La vue représente ce que l’utilisateur voit. Aucun traitement n’est effectué dans cette

partie

Le contrôleur fait le lien entre la vue et le modèle. Il ne doit lui non plus effectué

aucun traitement. Il doit intercepter les différents événements levés par une vue,

appelé si nécessaire une méthode du modèle, et renvoyer une vue à l’utilisateur.

Le modèle est donc en charge d’effectuer tous les traitements : accès aux données,

traitement des données saisies par l’utilisateur ainsi que toutes les interactions avec la

base de données. Il représente

Voici un schéma qui illustre l’intégration d’une architecture MVC dans une architecture

5-tiers :

60/8

Mémoire


Figure 3.4 : Principe du modèle MVC

4.1.2.1.1 Avantages de struts

Les avantages de Struts sont les suivants :

- validation automatique des formulaires du côté serveur,

- l’utilisation des taglibs permet de ne plus avoir de code Java dans les pages JSP,

- internationalisation facilitée,

- pour les applications complexes, Struts permet de voir l’application comme une suite

de composants de base : Vues, Actions, Modèles,

- lisibilité du code plus simple,

- permet de gagner en évolutivité,

- augmentation constante du nombre de personnes compétentes pour exploiter Struts,

- framework structuré,

- la librairie Tiles permet la structuration des pages,

- prend en compte les problèmes de sécurité et de performance.

61/8

Mémoire


4.1.2.1.2 Inconvénients de Struts

Ce framework n’a pas que des avantages :

- pour des applications Web très simple, Struts introduit un niveau de complexité et de

mise en route trop important.

- changement de version assez rapide

- nécessite un container de JSP à partir de la version 1.1 et de Servlet à partir de la

version 2.2

4.1.2.2. Java Server Faces

JavaServer Faces (JSF) est un framework d’applications web basées sur java EE qui a

pour but de simplifier le développement des interfaces utilisateur. JSF s’utilise conjointement

avec des JavaServer Pages, mais peut tout aussi bien se servir de d’autres technologies

d’affichage, telle que XUL.

4.1.2.2.1 Avantages de JSF

Les avantages de JSF sont les suivants :

- Architecture structurée autour des composants. Permet de créer des composants

personnalisés.

- Système de navigation statique et dynamique très souple.

- Personnalisation des labels (internationalisation, messages d’erreurs).

- JSF a été créé dans le but de permettre des développements de type RAD (liaison

champ/donnée).

- Séparation claire de la couche métier, permettant un prototypage efficace.

- Possibilité d’initialiser certains paramètres dans un fichier de configuration grâce

aux managed beans.

62/8

Mémoire


- framework structuré.

- JSF est une spécification javaEE.

- génère une forte dynamique et une communauté grandissante.

4.1.2.2.2 Inconvénients de JSF

Ses désavantages sont les suivants :

- Framework relativement récent, et donc pas encore mûr.

- Documentation peu riche, du fait de sa maturité.

- Validation coté serveur uniquement.

4.1.2.3. Choix

Struts a été le premier de son genre à voir le jour. De ce fait, et de par l’aide

considérable qu’il apporte au développement d’applications web, il a su s’imposer en tant que

référence.

D’un autre côté, JSF a été créé en prenant ce dernier comme modèle, et a su garder ses

bons points, tout en améliorant certains autres. L’engouement autour de JSF est important,

mais n’est pas encore parvenu s’imposer comme standard. JSF est un projet encore jeune, ce

qui le fait souffrir d’un certain manque de documentation, et de quelques bugs (la version 1.2

non supporté par JBoss 4 par exemple).

Techniquement, les deux se valent. D’un point de vue méthode, un léger avantage se fait tout

de même sentir pour JSF, qui parait plus souple d’utilisation que son ainé.

En considérant de plus les avis des experts techniques d’Infotel, notre choix se porte

donc sur Struts.

63/8

Mémoire


4.1.3. Construction de la couche présentation à l’aide de Struts

La couche présentation est constitué d’un ensemble de pages appelées Java Server

Pages, ou plus simplement jsp. Ces pages sont en quelque sorte des pages HTML, enrichit

grâce à du pseudo-code java. A l’instar du PHP ou de Ruby on Rails, il est possible de rendre

dynamique ces pages qui sont à la base statique.

Plus précisément, ces pages doivent être contenues sur un serveur possédant un moteur

de jsp, tel que le célèbre Tomcat. Quand une page de cette sorte est demandée, le serveur

effectué un traitement prenant en entrée une page et restituant en sortie une page constituée

uniquement d’HTML, avant d’être renvoyée à l’utilisateur. C’est grâce à cela que les

applications web peuvent être ouvertes depuis n’importe quel navigateur, sans avoir besoin

d’installer un plugin, un framework autre machine virtuelle.

Struts possède quelques outils afin de faciliter la création de telles pages

4.1.3.1. Struts Tiles

En règle général, les pages d’une application web, ou même d’un site web, possède des

parties communes. Le plus souvent, ces parties sont l’entête, le menu et le pied de page. Mais

inclure ces parties dans chaque page est une solution à éviter.

En effet, le moindre changement sur une de ces parties impacterait de modifier

l’ensemble des pages contenant cette partie. Le code redondant est à bannir, car il est

difficilement maintenable, et cela vaut aussi pour les pages web.

Tiles propose une solution simple, et très efficace pour éviter ce problème : le

découpage des pages jsp en plusieurs jsp. Il est ainsi possible créer une page jsp, simplement

en en assemblant d’autre. Pour cela, il faut tout d’abord définir que ce que l’on appelle des

layout. Ils sont en réalité l’ossature de la page. Un layout va définir est agencer plusieurs

zones. Ensuite, à l’aide d’un fichier XML, les pages sont créées en définissant pour chaque

chacune :

un layout,

les pages jsp devant remplir chaque zone de la page

un nom, afin que l’on puisse l’appeler depuis le reste de notre application.

64/8

Mémoire


Ce système gère également un système d’héritage, qui permet de définir des modèles de

pages. Par exemple, on crée une page que l’on appellera « .exemple », constituée d’une partie

entête, menu, pied de page et corps. On définit la page jsp associée à chaque partie. Si l’on

souhaite par la suite crée une page « .exemple2 », dont seul le corps diffère de « .exemple », il

suffit de faire hériter « .exemple2 » de cette dernière, et de redéfinir sa partie corps.

4.1.3.2. Struts Taglib

Comme nous l’avons vu, les pages JSP sont constitué d’HTML et de pseudo-code java

appelé scriptlet. Le problème avec ces scriptlets et qu’il a très vite tendance à rendre difficile à

lire une page jsp en mélangeant deux types de syntaxes complètement différentes.

Dans le but de rendre plus compréhensibles les pages JSP, Struts fournit quatre librairies

de balises à incorporer directement dans nos pages web permettant de remplacer en majeur

partie les actions faites par les scriptlets :

Bean, permet d’effectuer des actions des entités java. Elle sert principalement à

récupérer des données.

HTML, permet uniquement de générer des composants HTML.

Logic, permet de remplacer toutes les structures de contrôles que l’on pourrait trouver

dans des scriptlets.

Nested est la réunion des trois librairies décrites ci-dessus. Elle n’apporte rien de plus

si ce n’est de toutes les regrouper.

4.1.3.3. L’intertionalisation

Même si l’application n’est pas destinée à être utilisée à l’étranger, il est d’usage de

prévoir une éventuelle traduction et de séparer complètement les libellés du code. Cela peut

être utile si le libellé venait tout simplement à être renommé, pour ne pas avoir à le traquer

dans toute l’application.

65/8

Mémoire


Struts permet cela grâce à la création d’un fichier de ressource, externe au code,

contenant tout les libellés. La structure de fichier est on ne peut plus simple, chaque ligne est

basée sur le même modèle : Une clé = un libellé, par exemple « menu.company = Société ».

Il suffit ensuite d’utiliser la clé associée au libellé souhaité dans nos pages JSP.

4.1.4. La sous-couche contrôle

Lors de l’envoi d’un formulaire au serveur, la première étape avant de traiter les

données est de vérifier que celles-ci soient conformes, comme par exemple le format des

dates, la présence des champs obligatoire, etc… Ce genre d’action est appelée la validation et

est gérée par une couche sous jacente de la couche présentation : le contrôleur.

Avec Struts, la validation peut s’effectuer de deux manières totalement différentes :

Côté client : la validation s’effectue à l’aide de contrôles réalisés en JavaScript, évitant

ainsi de trop nombreux échanges entre le client et le serveur, à l’aide du plugin

« Validator » de Struts. Le code JavaScript est généré automatiquement mais peut

bien entendu être remplacé par un script personnalisé. Toutefois, une validation côté

client reste en général superficielle. D’une part car elle peut ne pas avoir été effectué

(JavaScript désactivé, plantage du script), et d’autre par car elle ne peut avoir un accés

direct aux données présentes dans la base de données. Les contrôles d’intégrité des

données ne sont pas faisables par exemple. C’est pourquoi il est très fortement

recommandé d’effectuer systématiquement une validation côté serveur, et

accessoirement côté client.

Côté serveur : la validation s’effectue donc une fois que l’utilisateur a envoyé ses

données, qu’elles aient été pré-validées ou non (pour les raisons susmentionnées). Ce

contrôle consiste à implémenter une méthode qui sera appelée à chaque chargement du

formulaire.

Dans notre, nous nous sommes contentés d’effectuer une validation côté serveur

uniquement. Le serveur n’ayant pas à subir une charge trop importante, le serveur peut être

sollicité sans crainte d’une baisse trop importante des performances. Qui plus est, le

66/8

Mémoire


JavaScript est langage auquel nous essayions de recourir le moins possible, du fait des

problèmes qu’il pose en terme de compatibilité entre navigateurs.

4.2. Le modèle de données

La couche métier contient un ensemble de classes représentant les entités dans la base de

données, mais modéliser sous forme d’objet. Pour simplifier au maximum le modèle de

données, une entité est représentée par une table dans la base de données et par une classe

dans notre application.

Ces classes n’effectuent aucun traitement des données à proprement parler. Leur unique

but est de stocker et de restituer un ensemble de valeurs dans des variables. Les méthodes, on

peut plus basique, permettant d’effectuer ces types d’actions sont appelées des getters (de

l’anglais to get qui signifie obtenir) et des setters (de l’anglais to set qui signifie définir). Une

classe uniquement constituée de variables, de getters et de setters est communément appelée

un Plain Old Java Object (POJO).

Notre couche modèle n’est donc en réalité qu’un ensemble de POJOs qui servent à relier

notre couche de logique métier avec celle d’accès aux données. Ces deux couches vont ainsi

communiquer uniquement via ces objets, et resteront donc relativement indépendante l’une de

l’autre :

- Dans un sens, après avoir effectué les traitements nécessaires, la couche de logique

métier va enregistrer les données une classe de type modèle et la transmettre à la

couche d’accès afin qu’elle y soit enregistrée.

- Réciproquement, si la couche de logique métier désire obtenir des données

provenant de la base, elle va les demander à la couche d’accès aux données qui les

retournera sous forme d’un ou plusieurs POJOs.

Cette structure permet ainsi de travailler sur chacune de ses couches sans se soucier de

quelconques dépendances. Les seules possibles sont en fonction du modèle de données, qui

est en général établit bien avant la construction de ces couches.

67/8

Mémoire


4.3. La couche de logique métier

La couche de logique métier est la partie de l’application qui la rend spécifique à un

besoin. C’est ici que toutes les règles métier vont prendre un sens et être activées. Jusqu’à ce

stade de l’application, l’utilisateur n’a saisi que des données brutes, en remplissant un

formulaire ou effectuant une action, comme cliquer sur un bouton « supprimer » par exemple.

Mais ce type d’action peut avoir une ou plusieurs conséquences sur le comportement de

l’application.

Prenons une règle métier simple provenant de l’application GRC :

« La création d’une société entraîne automatiquement la création d’une affaire de type

prospection pour celle-ci ».

D’un point de vue utilisateur, la création d’une société ne doit pas changer : il doit se

contenter de remplir un formulaire. Une fois les données saisies et contrôlées, la couche de

logique métier va donc devoir se charger de cette tâche.

Toujours dans le but d’éliminer les dépendances entre couches, les données en entrée ne

sont non pas des formulaires, mais des POJOs. Les formulaires sont en effet gérés de manière

bien spécifique dans Struts comme nous venons de le voir. Si l’application devait changer de

framework de présentation, la couche logique métier ne serait donc pas à revoir.

4.4. Le framework Spring.

Il nous a vivement été conseillé par les experts techniques d’Infotel d’utiliser le

framework Spring. Celui-ci a vu le jour suite à la réaction de quelques développeurs par

rapport à la complexité de l’utilisation de certains éléments de J2EE, comme notamment les

EJBs. En effet, plutôt que d’avoir à implémenter une ou plusieurs interfaces ou d’hériter pour

chaque classe de notre application, Spring propose de les gérer par le biais de fichiers de

configuration. L’impact sur le code en est donc fortement réduit. Cette mise en œuvre simple

et efficace, qui lui vaut l’appellation de conteneur dit « léger », nous permet donc de

conserver notre architecture basée sur les POJOs.

68/8

Mémoire


Spring est constitué des modules suivants :

Figure 3.5 : Modules du framework Spring

Il permet d’intégrer trois différents concepts :

4.4.1. L’inversion de contrôle

Le pattern d’inversion de contrôle est aussi appelé principe d’Hollywood car il fait

référence à la phrase "Ne nous appelez pas, c'est nous qui vous appellerons".

En principe, une application fait appel à un ou plusieurs framework. Ici, l’inverse se

passe : c’est le framework qui fait appel à l’application. Le flot d’exécution du logiciel est

ainsi géré par le framework, ce dernier faisant appel à des blocs de code de l’application. Cela

n’a aucun impact sur le code à proprement parler, si ce n’est l’utilisation de quelques classes

spécifiques à

Ce principe permet de mettre en œuvre un autre principe, celui d’injection des

dépendances. Etant donné que le framework a le contrôle sur les instanciations d’objet, il

peut égaler « injecter » pour un objet père tous les objets fils dont il dépend. Ces dépendances

ont simplement besoin d’être décrites dans un fichier de configuration.

69/8

Mémoire


4.4.2. La programmation orientée aspect

Voici une définition tirée de Wikipédia : « La programmation orientée aspect (POA, en

anglais aspect-oriented programming - AOP) est un paradigme de programmation qui permet

de séparer les considérations techniques (aspect en anglais) des descriptions métier dans une

application. Par exemple, le principe de l'inversion de contrôle (en anglais, IOC, Inversion Of

Control) peut être implémentée par AOP.

La programmation orientée aspect est une technologie transversale et n'est pas liée à un

langage de programmation particulier mais peut être mise en œuvre aussi bien avec un

langage orienté objet comme Python qu'avec un langage impératif comme le C, le seul

prérequis étant l'existence d'un tisseur d'aspect pour le langage cible.

4.4.3. La couche d’abstraction

La couche d'abstraction permet d'intégrer d'autres frameworks et librairies avec une plus

grande facilité. Cela se fait par l'apport ou non de couches d'abstraction spécifique à des

frameworks particuliers. Il est ainsi possible d'intégrer un module d'envoi de mails en toute

facilité.

Ce framework, grâce à sa couche d'abstraction, ne concurrence pas d'autres frameworks

dans une couche spécifique d'un modèle architectural MVC mais s'avère un framework multi-

couches pouvant s'insérer au niveau de toutes les couches; modèle, vue et contrôleur. Ainsi il

permet d'intégrer Hibernate pour la couche de persistance ou encore Struts pour la couche

présentation.

70/8

Mémoire


4.4.4. Intégration de Spring à l’application

Lors du commencement du développement, l’intégration de Spring n’avait pas encore

été évoquée. Cela ne nous a été spécifié qu’environ un mois plus tard pour un souci

d’homogénéité et de mutualisation des applications internes. Cette intégration tardive ne nous

aura au final que peu handicapé. D’une part car nous devions assimiler le fonctionnement de

deux autres frameworks – Struts et Hibernate – et d’autre part car Spring est relativement

léger à mettre en œuvre dans un projet.

La première étape fut de décrire tous nos objets métier pour les instancier à l’aide du

framework (cf. paragraphe L’inversion de contrôle). Pour cela nous avons du effectuer un

léger refactoring (réécriture de certaines parties du code), notamment dans la partie contrôle –

gérée – Struts, afin d’éliminer presque totalement les dépendances avec la couche de logique

métier.

En second lieu, la couche d’abstraction aura permit d’utiliser plus facilement Hibernate,

en nous permettant de supprimer les appels à la classe HibernateUtil afin d’initialiser une

transaction.

Au final, l’intégration de Spring à notre projet nous a permit de mieux isoler les couches

applicatives, de clarifier certaines parties du code et de simplifier l’initialisation de notre

source de données.

71/8

Mémoire


IV. Le projet DADS-U

1. Présentation du logiciel

1.1. La norme DADS-U

La Déclaration Automatisée des Données Sociales (DADS) est une formalité obligatoire

que les entreprises ont a effectuer chaque année. Cela consiste grosso modo pour une société à

déclarer ses salariés, leur nombre d’heures travaillées ainsi que le salaire qui leur a été versé.

Les informations individuelles transmises aux organismes de protection sociale leur

permettent de calculer les droits liés à chaque salarié.

Deux types de déclarations étaient réalisés par les entreprises, la DADS-TDS et la

DADS-CRC (caisses de retraite complémentaire).

Dans le cadre de la simplification administrative et de la modernisation des déclarations

sociales, le rapport du secrétaire d'état aux PME, au commerce et à l'artisanat auprès du

ministre de l'économie, des finances et de l'industrie, sous le titre "Simplifions : 37 mesures

pour les PME", prévoyait, dans sa mesure n°13, la fusion de la DADS-TDS et de la Dads-

CRC :

L'unification de ces normes a abouti à la DADS-U : Déclaration Automatisée de

Données Sociales-Unifiée. Elle permet aux entreprises d’utiliser un seul type de déclaration

unifiée pour l’ensemble des organismes.

1.1.1. Avantages

La déclaration par l'entreprise sous une forme unifiée, des seules informations utiles, induit

différents avantages :

72/8

Mémoire


Une économie de temps et de travail administratif.

Grâce à une norme unifiée intégrée dans son système de paie, l’entreprise peut accomplir

en une seule fois plusieurs déclarations nominatives des données sociales.

Une grande fiabilité grâce à une offre gratuite de services associés :

o une fonction de contrôle est disponible sur net-entreprises (www.net-entreprises.fr)

pour tester, qualifier les données avant l’envoi du fichier définitif et permettre un

meilleur traitement de la DADS-U dès sa réception en limitant les rejets.

o l’envoi d’un compte rendu d’exploitation et des solutions aux anomalies

d’identification des salariés facilitent une communication plus performante et

devancent les difficultés de gestion.

Un langage commun.

Tenu par des interlocuteurs clairement identifiés qui assurent une meilleure relation client

au travers des échanges entre l’entreprise et les différents organismes destinataires (Centres

Régionaux TDS, Institutions de Retraite Complémentaire, Institutions de Prévoyance et

Caisses de Congés Payés du Bâtiment et des Travaux Publics).

1.1.2. Le circuit de déclaration

Une déclaration implique plusieurs acteurs :

L’émetteur est la personne, morale ou physique habilitée à déposer au titre d’une ou

plusieurs entreprises la DADS-U. L’émetteur peut être l’entreprise ou un tiers

déclarant (SSII, cabinet comptable, centre de gestion agréé ...).

Les centres de dépôt sont les organismes chargés de réceptionner les DADS-U. Ces

centres sont en charge d’effectuer des contrôles de formes, mais également des

contrôles métier sur les déclarations. Si une anomalie est détectée lors de ces

contrôles, la DADS-U est refusée. Il existe 3 types de centres de dépôts différents :

73/8

Mémoire


o Centres de Transfert des Données Sociales (TDS) : sites de gestion des

déclarations pour les partenaires TDS. Ils recueillent les DADS, les traitent et

diffusent les informations vers tous les partenaires TDS concernés

o Le portail net-entreprises est un Site de dépôt de déclaration mis en place par

les principaux organismes sociaux pour faciliter et privilégier la

dématérialisation des déclarations sociales via Internet

o Le site Sintia est un site de dépôt des déclarations pour les sociétés

d’assurances, ils recueillent les déclarations, traitent et diffusent les

informations vers tous les partenaires concernés.

Les organismes destinataires sont tous les partenaires concernés par la norme DADS

dont voici une liste non exhaustive : les organismes de sécurité sociale (l’URSSAF,

l’ACOSS, le CNAV..), les services fiscaux (la DGI, le CDI et les CDA), les

organismes de l’assurance chômage (l’Unédic et les Assedic), les organismes des

régimes de retraite du personnel des fonctions publiques territoriales et hospitalières

(CNRACL et IRCANTEC), les institutions de retraites complémentaires (Agirc-

Arrco)...

L’annexe V présente un schéma du circuit de déclaration.

1.2. Présentation technique du projet

1.2.1. L’architecture du logiciel

Le projet initial a été achevé il y a maintenant 2 ans. La solution proposée consiste en un

client lourd, bâti autour d’un environnement J2SE 1.3. L’interface a été entièrement réalisée

avec l’API Swing. Du fait des changements de la législation, l’application a besoin d’être

mise à niveau annuellement.

Le logiciel est composé de plusieurs modules, qui ne permettent pas seulement de créer

le message à envoyer. Il est possible de gérer toutes les données présentes dans la base de

74/8

Mémoire


données, créer diverses éditions, ou effectuer les contrôles préalables afin de savoir si les

données sont bien conformes à la norme DADS-U.

Le schéma suivant illustre l’architecture du logiciel.

Figure 4.1 : Modules de DADSU

Un des points intéressants de l’application et qui mérite une explication est le processus

d’extraction des données.

75/8

Solution

DADS

2005

Fichiers de travail

PRSO

Fichiers de travail

PPUB

Module d’extraction des données

Base de données

Regroupement des

données utiles issues

de l’application

PRSO ou PPUB (selon

statut de l’entreprise)Module de génération du fichier DADS-U

Génération du fichier DADS-U

Expédition

Editions diverses et sauvegardes

Soumission de l’extraction

Données à extraire pour la constitution du

fichier DADS-U

Paramétrage

Contrôles des données et mises à

jour

Mémoire


1.2.2. Le mécanisme d’extraction

Afin de pouvoir conserver les données déjà saisies par tous les clients de Siemens, un

mécanisme d’extraction des données un serveur AS400 a été mis en place. Ce processus

nécessite une phase de préparation :

Une fois le logiciel installé, il est tout d’abord impératif de procéder au paramétrage de

l’application. Ce paramétrage consiste en générale à renseigner certaines équivalences entre la

codification de l’établissement et la codification DADS. En effet, les hôpitaux, relevant du

public, et les cliniques, relevant du privé, disposent de codes différents pour désigner une

même valeur. Un exemple concret : si la civilité « Monsieur » est désignée par le code « M »

par les hôpitaux, elle est représentée par « 01 » par les cliniques. La norme DADS possède

quant à elle sa propre codification. Pour chaque code du public, appelé la nomenclature

PPUB, ou chaque code du domaine privé, appelé nomenclature PRSO, il faut faire

correspondre un code de la nomenclature DADS. Cette dernière est obtenue en lançant un

processus : la préparation à l’extraction. Une fois le paramétrage effectuée, l’extraction peut

être lancée.

Toute demande d’extraction soumise depuis l’application DADS-U déclenche une série

d’opérations. En premier lieu, un service RPG, crée par Siemens, est exécuté sur l’AS400 afin

d’extraire toutes les données dans fichiers au format CSV (fichiers textes). Ces fichiers sont

mis sur un répertoire partagé de l’AS400. L’utilisateur peut suivre l’avancement de

l’extraction depuis l’application grâce à un système impliquant différents fichiers CSV

(« Extracti.CSV ») sollicités uniquement pour témoigner de la progression du processus.

Une fois l’extraction terminée, l’application peut désormais importer les fichiers CSV

dans sa base de données, grâce à un mécanisme d’importation.

Le schéma suivant illustre le mécanisme d’extraction des données depuis l’application

DADSU.

76/8

Mémoire


Figure 4.2 : Fonctionnement de l’extraction

2. Mise à jour du projet

Les mises à jour du projet à réaliser concernent la quasi-totalité des modules, mis à part

celui de l’extraction. Le service RPG est en effet mis à jour directement par Siemens. Les

tâches sont regroupées de la manière suivante :

mise à exécution du cahier des charges.

Rédaction de plan de tests.

Rédaction des spécifications techniques.

résolution de bugs des versions précédentes.

Dans un premier temps, afin de me familiariser à l’environnement DADS, j’ai était

assigné sur le module d’édition, dont les changements ne provoquent aucun impact sur les

autres modules. La spécificité de cet environnement provient non seulement de la norme

DADS elle-même, et de son regroupement des données en structures et sous structures, mais

77/8

Mémoire


également de la structure de l’application, techniquement parlant. L’application a été à la base

conçue en tenant compte des futures mises à jour que les modifications de la législation

entraînent. Ainsi, la majorité des classes à modifier héritent « en cascade » d’autres classes, et

peuvent implémenter plusieurs interfaces. Cela oblige à garder une certaine homogénéité du

code.

Dans un second temps, j’ai ensuite travaillé sur des modifications plus délicates, telles

que la modification du message à envoyer aux centres de dépôts, ou l’ajout de nouvelles

structures dans l’application. De telles modifications ne sont pas anodines, et requiert un petit

moment de recherche et de réflexion. Pour ne pas oublier, et surtout pour ne pas que chacun

ait à effectuer ce travail, nous mettions régulièrement un site interne de type wiki.

Une fois suffisamment familiarisé avec le logiciel, j’ai pu commencer à rédiger un

document technique à l’attention de Siemens.

2.1. Rédaction des spécifications techniques

Les spécifications techniques doivent constituer une aide pour les potentiels futurs

développeurs ayant besoin de réaliser diverses modifications sur l’application. Pour cela, ce

document doit résumer le fonctionnement technique de l’application, fournir des exemples

d’opérations susceptibles d’être refaites plus tard – tels que la modification d’une édition,

l’ajout d’un champ dans l’interface utilisateur, etc.

J’ai donc eu à réaliser ce document qu’après avoir effectuer plusieurs tâches sur des

modules différents. La partie des spécifications techniques que j’ai rédigée ne concernait bien

entendu que les parties auxquelles j’avais du précédemment apporté des modifications, et

donc comprendre le fonctionnement.

2.2. Rédaction de plan de test

Les plans de test sont un document résumant l’ensemble des vérifications qui ont été

faîtes après chaque modification. Deux aspects ont été testés à chaque fois :

78/8

Mémoire


L’aspect fonctionnel : s’assurer de la cohérence entre le résultat fournit par

l’application et le résultat attendu après une manipulation.

L’aspect technique : consiste en générale à des tests unitaires. On doit s’assurer que

l’application reste stable en cas d’erreur de manipulation.

L’aspect performance : dans une moindre mesure, des tests de performances ont du

être réalisés. Ceux-ci ne constituaient pas une préoccupation majeure pour ce projet.

Ces plans de test devaient être livrés à Siemens afin qu’il puisse contrôler ce qui a été

vérifié, et ce qui ne l’a pas été. De son côté, Siemens devait également réaliser des tests avant

d’accepter le projet. Les anomalies constatées au cours de ces derniers donnent lieux à des

retours, qui, si elles s’avèrent réelles, sont recensées en tant que bug.

3. La Résolution de bugs

Des bugs, ou anomalies, trouvés par Siemens ou par ses clients sur les versions

précédentes se devaient d’être résolu. Il existe en général trois niveaux de sévérité pour un

bug :

Mineur : bug ne provoquant aucun blocage. Il représente simplement un défaut.

Majeur : bug entraînant l’échec d’une des fonctionnalités. L’application peut

cependant toujours remplir sa tâche.

Bloquant : comme son l’indique, bloque le déroulement de l’application et empêche

celle-ci de fournir le résultat attendu.

Pour mieux organiser le recensement et la résolution des bugs, Siemens dispose d’un outil

open-source nommé Mantis.

79/8

Mémoire


3.1. Le système de Mantis

Mantis propose une solution complète afin de résoudre les bugs détectés de manière la

plus efficace possible.

Tout d’abord, un utilisateur ayant trouvé un bug la soumet au système Mantis. Son état

alors définit tel que « En attente ». La saisie d’un mantis se doit d’être la plus complète

possible afin que l’équipe de développement puisse reproduire et identifié le bug. Pour cela

des informations sur la reproductibilité du bug et sur les conditions de son apparition peuvent

être saisie. Des documents peuvent également être attachés afin de décrire plus en détail le

bug.

Le responsable de l’équipe de développement (MOE), après avoir constaté le bug,

change son statut en « Accepté », signifiant qu’il est pris en considération. Un nombre de

jour / homme est alors fixé en accord avec la MOA. Le chef de projet assigne ensuite le

mantis à un développeur, modifiant ainsi son statut en « Assigné », signifiant que le bug est

en cours de traitement.

Une fois le bug résolu, son statut change en « Résolu ». La MOA peut ainsi constater si

le bug a bien été éliminé ou non.

80/8

Mémoire


Conclusion

1. Bilan du stage

La première des applications sur laquelle j’ai travaillé, la gestion de la relation client, a

été achevée dans les temps. L’application est fonctionnelle et actuellement sur un serveur de

recette afin que les différents commerciaux puisse la tester. L’actuel manque de retours

l’empêche pour l’instant de passer sur un serveur de production, et d’effectuer la migration.

D’un point de vue fonctionnel, quelques points prévus l’année dernière ont été

abandonnés pour l’instant et réservés pour une éventuelles versions 2, tel que la

synchronisation des contacts avec Outlook. Cela avait été décidé avant le démarrage du

développement, lors de notre réunion à Toulouse. Quelques fonctionnalités additionnelles ont

en revanche été ajoutées.

D’un point de vue performance, l’application ne souffre pour l’instant d’aucun

ralentissement notable. Pour nos tests, nous avons converti, puis importé une partie de la base

de données de la GRC. Celle-ci concerne toutes les sociétés et les contacts gérés par les

agences de Toulouse et Bordeaux, ce qui représente environ 2000 contacts. De ce côté-là,

l’objectif est donc atteint.

En ce qui concerne l’application DADSU, le projet a été livré dans les délais prévus. Les

retours émis par Siemens me sont pour l’instant inconnus. L’ensemble du cahier des charges a

été exécuté, les plans de tests et les spécifications ont été accepté, et la totalité des bugs

résolus. Une réserve cependant à ce sujet ; la livraison d’une nouvelle version entraînera

certainement la détection de nouvelles anomalies à résoudre.

81/8

Mémoire


2. Bilan personnel

A tous points de vue, ce stage aura été pour moi une réussite. Premièrement, j’ai

découvrir, en profondeur, l’univers du J2EE. Possédant auparavant une très faible expérience

dans ce domaine, je connais désormais plusieurs frameworks, intervenant sur des aspects

différents de l’application. Dans une moindre mesure, j’ai également consolidé mon

expérience en ce qui concerne le développement d’interfaces web. Toujours d’un point de vue

technique, j’ai pu appris énormément quant au développement en Java, et à l’utilisation de

l’IDE Eclipse.

Mon sujet de recherche ainsi que les deux projets sur lesquels j’ai travaillé m’auront

permis de réellement me rendre compte de l’apport d’une solution MOR dans un projet. Si la

complexité d’un tel framework peut rebuter de prime abord, le gain considérable de temps

qu’il apporte n’est pas en reste.

Plus humainement, ce stage m’aura permis de vraiment apprécié le travail d’équipe. J’ai

pu me rendre compte comment le travail en équipe pouvait avoir des conséquences sur ma

manière de programmer, d’aborder des problèmes, et de les résoudre. J’ai également pu

apprécier d’être supervisé par un chef de projet de qualité, ce qui a quelques peu changé ma

vision sur ce métier.

Au final, ce stage aura également été une réussite, car j’ai ainsi pu trouver l’entreprise

dans laquelle débuter ma carrière. La transition c’est effectué sans aucun problème, et je tiens

à remercier encore une fois toute l’équipe d’Infotel Bordeaux pour leur accueil chaleureux.

82/8

Mémoire


Glossaire

API :

Framework :

1/8

Mémoire


Nomenclature des figures

Figure 1.1 : Infotel dans le monde (p6).

Figure 1.2 : Infotel en France (p7).

Figure 1.3 : Organisation juridique d’Infotel (p7).

Figure 1.4 : Activités d’Infotel (p9).

Figure 1.5 : Domaine d’expertise (p10).

Figure 1.6 : Graphe d’évolution du nombre de collaborateur et du C.A. (p11).

Figure 1.7 : Evolution du C.A. (p12).

Figure 2.1 : Schéma de 2 entités (p14).

Figure 2.2 : MCD des 2 entités (p15).

Figure 2.3 : Stockage dans la base de données (p15).

Figure 2.4 : Représentation objet simplifiée des deux entités (p16).

Figure 2.5 : Charge des développeurs sans framework (p18).

Figure 2.6 : Problème lié aux objets fils (p19).

Figure 2.7 : Charge des développeurs avec framework (p20).

Figure 2.8 : Relations entre objets pères et fils (p20).

Figure 2.9 : Correspondance entre une représentation relationnelle et objet. (p21).

Figure 2.10 : Structure simplifiée d’Hibernate (p27).

Figure 2.11 : Exemple d’un fichier de mapping (p29).

Figure 2.12 : Différents états d’un objet. (p33).

Figure 2.13 : Exemple d’un fichier de configuration (p35).

Figure 2.14 : Architecture du test (p37).

Figure 2.15 : Modèle objet ayant servit au test (p38).

Figure 2.16 : Historique des solutions ORM. (p41).

Figure 3.1 : Cycle en V (p44).

Figure 3.2 : Architecture 5-tiers (p55).

Figure 3.3 : Schéma de l’architecture de la GRC. (p58).

Figure 3.4 : Principe du modèle MVC (p61).

2/8

Mémoire


Figure 3.5 : Modules du framework Spring (p69).

Figure 4.1 : Modules de DADSU (p75).

Figure 4.2 : Fonctionnement de l’extraction (p77).

3/8

Mémoire


Tables des matières

INTRODUCTION............................................................................................................................................. 1

I. PRÉSENTATION DE LA SOCIÉTÉ.............................................................................................................. 5

1. LE GROUPE INFOTEL......................................................................................................................................5

1.1. Historique.......................................................................................................................................5

1.2. Implantations géographiques.........................................................................................................5

1.3. Organisation juridique....................................................................................................................6

2. LES ACTIVITÉS...............................................................................................................................................8

2.1. Services...........................................................................................................................................8

2.2. Formations......................................................................................................................................9

2.3. Progiciels.........................................................................................................................................9

3. DOMAINE D’EXPERTISE.................................................................................................................................10

4. LES CHIFFRES CLÉS......................................................................................................................................11

4.1. Humain.........................................................................................................................................11

4.2. Financier.......................................................................................................................................11

5. LA DIVISION SUD OUEST..............................................................................................................................12

5.1. L’agence de Bordeaux...................................................................................................................12

5.2. Les projets Bordelais.....................................................................................................................13

II. L’UTILITÉ DES LOGICIELS ORM............................................................................................................. 14

1. LE PROBLÈME.............................................................................................................................................14

1.1. Le modèle relationnel...................................................................................................................14

1.2. Le modèle objet............................................................................................................................15

1.3. Les logiciels ORM..........................................................................................................................16

2. PRINCIPES DE LA PERSISTANCE.......................................................................................................................17

2.1. La persistance non transparente...................................................................................................18

2.2. La persistance transparente..........................................................................................................19

2.3. Le mapping objet-relationnel........................................................................................................21

2.4. Historique de la persistance des données en Java.........................................................................23

2.4.1. Les EJB (Enterprise JavaBeans).................................................................................................................23

4/8

Mémoire


2.4.2. TopLink et JDO..........................................................................................................................................24

2.4.3. Un exemple d’ORM : Hibernate...............................................................................................................25

3. IMPACTS SUR LES MÉTHODES DE DÉVELOPPEMENT.............................................................................................26

3.1.1. Les POJOs.................................................................................................................................................28

3.1.2. Les fichiers de mapping............................................................................................................................28

3.2. Gestion de la session Hibernate....................................................................................................30

3.2.1. La session Hibernate.................................................................................................................................30

3.2.2. La classe utilitaire HibernateUtil...............................................................................................................31

3.3. Le cycle de vie d’un objet manipulé par Hibernate........................................................................32

3.3.1. Les différents états...................................................................................................................................32

3.3.2. Entités et valeurs......................................................................................................................................34

3.4. Configuration................................................................................................................................35

3.5. L’outil Hibernate Tools..................................................................................................................35

4. IMPACT SUR LES PERFORMANCES GÉNÉRALES....................................................................................................36

4.1. Test de performances...................................................................................................................36

4.2. Les caches.....................................................................................................................................40

5. VERS UNE SOLUTION UNIQUE........................................................................................................................40

III. DÉVELOPPEMENT ET MISE EN PLACE D’UN OUTIL DE GRC...................................................................43

1. CONTEXTE.................................................................................................................................................43

1.1. Relation du stage précédent.........................................................................................................43

1.2. Objectifs du stage.........................................................................................................................44

1.3. L’équipe de développement..........................................................................................................45

1.4. Les ressources matérielles.............................................................................................................46

1.5. Portée du stage.............................................................................................................................46

1.6. La gestion du projet......................................................................................................................46

2. L’APPLICATION...........................................................................................................................................47

2.1. Genèse du projet...........................................................................................................................47

2.2. Les besoins fonctionnels................................................................................................................48

2.3. Ergonomie....................................................................................................................................49

2.3.1. La barre de recherche..............................................................................................................................50

2.3.2. Le fil d’Ariane...........................................................................................................................................50

2.3.3. Le menu....................................................................................................................................................51

2.4. Fonctionnalités.............................................................................................................................51

2.4.1. Section accès aux données.......................................................................................................................51

5/8

Mémoire


2.4.2. Section états et statistiques.....................................................................................................................52

2.4.3. Section administration.............................................................................................................................52

3. L’ARCHITECTURE TECHNIQUE.........................................................................................................................53

3.1. Introduction à J2EE.......................................................................................................................53

3.1.1. Définition..................................................................................................................................................53

3.1.2. Pourquoi J2EE ?........................................................................................................................................54

3.1.3. L’architecture multitiers...........................................................................................................................54

3.2. Choix du serveur Web/applicatif J2EE...........................................................................................55

3.3. Choix de la version de la machine virtuelle Java (JVM).................................................................56

3.4. Choix de la base de données.........................................................................................................57

3.5. Synthèse de l’étude.......................................................................................................................57

4. L’ARCHITECTURE.........................................................................................................................................58

4.1. Interface utilisateur......................................................................................................................59

4.1.1. La maquette.............................................................................................................................................59

4.1.2. Choix d’un framework de présentation....................................................................................................60

4.1.2.1. Struts.............................................................................................................................................60

4.1.2.1.1 Avantages de struts....................................................................................................................61

4.1.2.1.2 Inconvénients de Struts..............................................................................................................62

4.1.2.2. Java Server Faces...........................................................................................................................62

4.1.2.2.1 Avantages de JSF........................................................................................................................62

4.1.2.2.2 Inconvénients de JSF..................................................................................................................63

4.1.2.3. Choix..............................................................................................................................................63

4.1.3. Construction de la couche présentation à l’aide de Struts.......................................................................64

4.1.3.1. Struts Tiles.....................................................................................................................................64

4.1.3.2. Struts Taglib...................................................................................................................................65

4.1.3.3. L’intertionalisation.........................................................................................................................65

4.1.4. La sous-couche contrôle...........................................................................................................................66

4.2. Le modèle de données..................................................................................................................67

4.3. La couche de logique métier.........................................................................................................68

4.4. Le framework Spring.....................................................................................................................68

4.4.1. L’inversion de contrôle.............................................................................................................................69

4.4.2. La programmation orientée aspect..........................................................................................................70

4.4.3. La couche d’abstraction............................................................................................................................70

4.4.4. Intégration de Spring à l’application.........................................................................................................71

IV. LE PROJET DADS-U.............................................................................................................................. 72

6/8

Mémoire


1. PRÉSENTATION DU LOGICIEL..........................................................................................................................72

1.1. La norme DADS-U.........................................................................................................................72

1.1.1. Avantages.................................................................................................................................................72

1.1.2. Le circuit de déclaration...........................................................................................................................73

1.2. Présentation technique du projet..................................................................................................74

1.2.1. L’architecture du logiciel..........................................................................................................................74

1.2.2. Le mécanisme d’extraction.......................................................................................................................76

2. MISE À JOUR DU PROJET..............................................................................................................................77

2.1. Rédaction des spécifications techniques.......................................................................................78

2.2. Rédaction de plan de test.............................................................................................................78

3. LA RÉSOLUTION DE BUGS.............................................................................................................................79

3.1. Le système de Mantis....................................................................................................................80

CONCLUSION............................................................................................................................................... 81

1. BILAN DU STAGE.........................................................................................................................................81

2. BILAN PERSONNEL.......................................................................................................................................82

GLOSSAIRE.................................................................................................................................................... 1

NOMENCLATURE DES FIGURES...................................................................................................................... 2

Bibliographie..........................................................................................................................................................8

7/8

Mémoire


Bibliographie

Gavin King & Christian Bauer « Hibernate in action », Broché, 2004.

Livre coécrit par le père d’Hibernate en personne. Ce livre, en plus de présenter

techniquement les possibilités d’Hibernate, traite notamment du délicat problème du mapping

objet-relationnel, qui est à l’origine de la création d’Hibernate.

Documentation d’Hibernate (http://www.hibernate.org/hib_docs/v3/reference/fr/html/)

Documentation extrêmement riche, en particulier pour un projet open-source. Elle m’a permis

de répondre à un grand nombre d’interrogations techniques.

Tutoriel Jakarta Struts par Serge Tahé (format PDF)

Ce tutoriel très complet m’a fournit une aide précieuse quant à l’apprentissage du framework.

8/8

Documents

maxime.morand.free.frmaxime.morand.free.fr/CRM/Rapport/Memoire.w2003.doc · Web view3. Impacts sur les méthodes de développement 25. 4. Impact sur les performances générales