Outil de Demande de Backup Système

10, Place Alfonse Jourdain 31000 Toulouse

05 34 45 22 00

AFPA TOULOUSE 1, allées Jean Griffon

B.P 4426

31046 TOULOUSE Cedex 9

Outil de Demande de Backup Système ( Backup On Tape Requirements ⁾

Rapport de stage du 15.10.2007 au 21.12.2007

Destinataires :

M. Geoffroy DESSEMON , Maître de stage M. Serge GASTON, Formateur AFPA M. Dominique REAU, Formateur AFPA

M. Pascal DANGU, Formateur AFPA M. Sylvain SABOURAUD, Formateur AFPA

M. Xavier PRUNCK, Stagiaire Promotion D.I. 2008-1

Sommaire

SOMMAIRE ...2

REMERCIEMENTS ...4

INTRODUCTION ...5

1. L’ENTREPRISE INFOTEL CONSEIL...6

1.1. PRESENTATION GENERALE...6

1.1.1. Une société de services et de conseil en haute technologie ...6

1.1.2. Éditeur de logiciels dits « utilitaires de bases de données »...6

1.2. F^{ICHE D}’^IDENTITE...7

1.3. ENVIRONNEMENT DES SERVICES INFOTEL AU SEIN D’AIRBUS...8

2. PRESENTATION DU PROJET ...9

2.1. V^{UE D}’^ENSEMBLE...9

2.1.1. Périmètre d’utilisation ...9

2.1.2. Objectifs...9

2.2. L’EXISTANT...10

2.3. LES PRINCIPALES FONCTIONNALITES...11

2.3.1. Création/Modification d’une demande de backup ...11

2.3.2. Consultation d’une demande de backup...11

2.3.3. Vérification de l’implémentation d’une demande...11

2.3.4. Copier les informations d’une demande « standard » pour saisir une nouvelle demande...11

2.3.5. Marquer une demande de backup comme standard ...11

2.3.6. Authentification et droits ...11

2.3.7. Interface avec l’outil d’échange et de suivi Airbus « change »...11

2.3.8. Requêtes prédéfinies...11

2.4. ARCHITECTURE...12

2.4.1. Architecture utilisée ...12

a. Principes généraux ...12

b. Station de travail ( Utilisateur final ) ...12

c. Serveur web et applicatif...12

d. Base de données ...13

2.4.2. Mise en œuvre de l’architecture...13

a. Architecture de l’application ...13

b. Architecture de la base de données...13

3. CONCEPTION...14

3.1. CREATION D'UN MCD ...14

3.2. CHOIX DU CONCEPT MAPPING OBJET-RELATIONNEL...14

3.2.1. Utilisation du pattern Data Access Object (DAO)...15

3.3. CONCEPTION D’UN DIAGRAMME DE CLASSE METIER...15

3.4. CHOIX DU CONCEPT MODELE VUE CONTROLEUR (MVC) ...16

4. DEVELOPPEMENT...17

4.1. LE LANGAGE DE DEVELOPPEMENT...17

4.1.1. Frameworks de persistance Hibernate ...17

4.2. ENVIRONNEMENT DE DEVELOPPEMENT...17

4.3. IMPLEMENTATION DU MODELE DE DONNEE AVEC HIBERNATE...18

4.3.1. Configuration d’Hibernate ...18

4.3.2. Les fichiers de mapping ...18

a. Optimiser le mapping ...18

b. Problème de jointure externe non résolue ...19

4.3.3. Les Beans...19

4.3.4. Les Managers ...19

4.4. IMPLEMENTATION DES SERVLETS ET JSP ...20

4.4.1. Les Servlets ...20

4.4.2. Les JSP ...20

4.5. DEBUGAGE...20

4.6. CONSTRUCTION ET COMPILATION AVEC LE FICHIER ANT...21

4.7. GESTION DE VERSION...21

5. DIFFICULTES RENCONTREES ...21

6. CONCLUSION...22

7. BIBLIOGRAPHIE ...23

8. ANNEXES ...24

8.1. ANNEXE 1 : MODELE CONCEPTUEL DES DONNEES. ...24

8.2. ANNEXE 2 : DIAGRAMME DE CLASSES METIERS. ...24

8.3. A^NNEXE 3 : QUELQUES CAPTURES D’^ECRANS. ...24

Remerciements

Je tiens à remercier M. Hubert FOUCART, service Manager, pour m’avoir accueilli au sein du service.

Monsieur Laurent FOUILLERON, chef de projet, pour m’avoir donné les moyens et l’assistance nécessaires à la réalisation et l’avancement de l’application.

Monsieur Benoit FENAUX pour ses précieux conseils d’ordre technique, ses critiques constructives ainsi que son aide pour le démarrage.

Monsieur Geoffroy DESSEMON, maître de stage, de m’avoir aiguillé et missionné sur ce projet, et d’avoir veillé au bon déroulement de mon stage.

Je souhaite également faire part de ma reconnaissance à toute l’équipe d’InfoTel Conseil pour son accueil.

Introduction

.

Dans le cadre du Titre de Développeur Informatique, un stage en entreprise de 8 semaines a été effectué du 15 Octobre 2007 au 21 Décembre 2007 dans l’entreprise Infotel pour valider mon année de formation.

Mon stage chez Infotel consistait à créer un référentiel et une application de gestion de demande de backup système pour le client Airbus.

Mon stage c’est déroule au sein du service de développement de logiciel d’InfoTel basé chez Airbus.

Les spécifications étant déjà très avancées, mon rôle était de concevoir le référentiel et l’application, puis de la développer.

De la tester, la débuguer et commencer la phase de récupération des données existantes.

Je commencerai le rapport par une présentation de l'entreprise et de son implantation au sein d’Airbus dans laquelle j'ai effectué mon stage. Je présenterai ensuite plus en détails le projet en lui-même avec un tour d’horizon de l’existant, puis la présentation des méthodes et outils utilisés lors de la conception et du développement. Enfin, je rendrai compte des problèmes rencontrés avant d'aborder la conclusion générale du stage.

1. L’entreprise INFOTEL CONSEIL 1.1. Présentation générale

Fondée en 1979, Infotel présente un double profil : d’une part celui de prestataire de services informatiques et d’autre part celui d’éditeur de logiciels spécialisés dans la gestion de bases de données.

Plutôt que de tenter de couvrir un large spectre de prestations, à l’instar des SSII généralistes leaders sur le marché français, Infotel a opté pour un positionnement de niche, le « web-to-database » : ensemble de solutions permettant d’accéder, depuis le web, aux données et aux applications résidant sur les serveurs centraux.

1.1.1. Une société de services et de conseil en haute technologie

Infotel fonde sa notoriété sur une parfaite connaissance des systèmes d’exploitation des grands systèmes IBM (mainframe) et en particulier du système MVS devenu

aujourd’hui z/OS.

Grâce à ces compétences multiples et à sa forte expertise technique, Infotel maîtrise totalement la chaîne complexe allant des terminaux Web aux grands serveurs et aux bases de données des entreprises, en passant par les serveurs intermédiaires (serveurs d’application et middlewares).

Infotel est fortement implantée dans le secteur de la finance (21%), des assurances et de la retraite (26%), des services (23%) et de l'industrie (30%).

1.1.2. Éditeur de logiciels dits « utilitaires de bases de données »

maintenance des bases de données des services informatique des grands comptes.

1.2. Fiche d’identité

Raison sociale : Infotel

2 pôles d’activités :

- Services : résolution des problèmes complexes de programmation en informatique de gestion et de conception d’applications, mise en place d’architectures Web-To-Database (reliant le Web et les bases de données) et formation.

- Logiciels : la gamme de logiciels est destinée à la maintenance informatique et à l’amélioration des bases de données (optimisation de la gestion des ressources, sécurité de l’exploitation, aide à la conception des applications et utilitaires pour bases de

données).

Date de création : 1979

Quelques références : Groupe PSA (Peugeot – Citroën), Air France, BNP Paribas, AGME (Groupe Mornay), Groupama, Gan, Crédit Agricole, Caisse d’épargne, Banque Populaires, European Patent Office, Airbus…

Secteurs d’activités de son portefeuille clients : Infotel intervient dans le secteur de la finance (21%), des assurances et de la retraite (26%), des services (23%) et de l’industrie (30%).

C.A. 2003 : 34,8 M€ pour un résultat net de 1,95 M€.

C.A. prévisionnel 2004 : de l’ordre de 36,9 M€.

Équipe dirigeante : Le comité de direction est composé de : Bernard Connes-Lafforet Président-Directeur général, Michel Koutchouk, Directeur général délégué, Alain Hallereau, Directeur général délégué, Josyane Muller, Directeur général délégué, Patrick Allouche, Directeur Logiciels, Jean-Marie Meyer, Directeur Sud-Ouest, Éric Fabretti, Directeur Services.

Effectif : 420 personnes avec un plan de recrutement de 80 personnes sur le 1er trimestre 2005.

Siège social : Tour Gallieni II – 36, avenue du Général de Gaulle – 93175 Bagnolet Cedex.

Bureaux commerciaux : Paris, Neuilly-sur-Seine, Toulouse, Bordeaux, UK, Allemagne, USA.

Répartition géographique du chiffre d’affaires 2003 : France (83.1 %), USA (9.6 %), Union européenne (7.3 %).

Site Web: www.infotel.com

1.3. Environnement des services Infotel au sein d’Airbus

Les services Infotel chez Airbus font tampon entre Airbus et HP.

Infotel joue un rôle de conseiller et d’accompagnateur des managers Airbus dans leur réalisation de demande de backup système, base de données ou applicatif.

A travers Infotel, HP a une meilleur vision et interprétation des besoins de sauvegarde des projets Airbus.

Infotel créé aussi des logiciels d’aide au déroulement et au suivi des opérations.

Airbus :

Service Informatique Système (OIOD)

Service Informatique Applicatif (OIOC)

Service Informatique Technique (OIOT) Infotel :

Service Demande de backup système (BTR)

Service Demande de backup BD et Applicatif (SRS)

Service Indicateur d'incidents

HP : Service

d'Implémentation Backup

2. Présentation du projet 2.1. Vue d’ensemble

2.1.1. Périmètre d’utilisation

Cet outil est utilisé par les Managers du service Backup Système d’Airbus, qui ont pour tache de réaliser des demandes de backup système, ainsi que l’équipe HP en charge de l’implémentation de ces backups.

Les outils de Backup concernés sont Time Navigator « Tina » (Atempo) et NetBackup (Veritas).

2.1.2. Objectifs

• Construire un référentiel de demandes de backup système.

• Gérer la saisie d’une demande.

• Permettre une consultation des demandes et des implémentations

• Comparer les demandes et les implémentations

2.2. L’existant

Les managers Airbus responsables de la mise en œuvre des backups système utilisent un document Excel pour chaque demande.

Sur ce fichier Excel sont représentées toutes les données correspondantes au besoin de sauvegarde des systèmes d’un projet Airbus.

Le classement et l’intégrité des données reposent uniquement sur la maîtrise et le savoir faire des responsables.

Une fois la demande transcrite dans un fichier Excel, elle est directement envoyée aux équipes HP pour l’implémentation.

Les managers Airbus n’ont alors aucun moyen de contrôle pratique et fiable de l’implémentation de leur demande.

Jusqu'à ce qu’Infotel livre un logiciel de remontée d’indicateur des backups effectués quotidiennement, ainsi qu’un logiciel de suivi de problèmes et de leurs solutions.

Ces logiciels ont démontré des problèmes d’interprétations entre les demandes de sauvegardes et leurs réalisations.

C’est ainsi qu’est apparu le besoin de créer une application spécifique aux besoins des Responsable en charge des demandes de backup system.

2.3. Les principales fonctionnalités

2.3.1. Création/Modification d’une demande de backup

Les "strategy" Tina ou les "policy" NetBackup sont uniques par serveur.

Après chaque enregistrement, l’implémentation de la demande est vérifiée dans NetBackup ou Tina. Le résultat est sauvegardé avec la demande.

2.3.2. Consultation d’une demande de backup

Une liste des demandes de backup est disponible avec un filtre et des tris.

Les informations complètes sont accessibles pour chaque demande.

2.3.3. Vérification de l’implémentation d’une demande

Cette fonction est utile pour contrôler que chaque demande a bien été implémentée.

2.3.4. Copier les informations d’une demande « standard » pour saisir une nouvelle demande.

Pour faciliter la phase de récupération des demandes existantes, l’utilisateur peut créer une nouvelle demande de backup à partir d’une demande marquée comme standard et préalablement saisie avec l’outil.

2.3.5. Marquer une demande de backup comme standard

2.3.6. Authentification et droits

L’application est utilisable dans la zone LAN pour tous les managers Airbus.

La consultation est libre, mais différents profils sont nécessaires pour pouvoir créer, modifier, supprimer ou vérifier une demande.

2.3.7. Interface avec l’outil d’échange et de suivi Airbus « change »

Une Url est construite pour chaque demande, qui ouvrira la page de détail de la demande choisie.

L’utilisateur peut copier la sortie Excel ou l’URL directement dans le « change »

2.3.8. Requêtes prédéfinies

Une sélection de requêtes prédéfinies est accessible.

2.4. Architecture

2.4.1. Architecture utilisée

Principes généraux

BTR est une application web / J2EE implantée sur une architecture physique à 3 niveaux :

Le niveau Client (ou Poste de Travail) où se situe l’utilisateur ;

Le niveau Serveur Applicatif qui répond, en collaboration avec le Serveur de Données, aux demandes émises par le niveau Client ;

Le niveau Serveur de Données qui héberge le SGBD et la base de données.

b. Station de travail ( Utilisateur final )

Le poste de l’utilisateur nécessite un navigateur internet. L’application est compatible avec tous les navigateurs récents (Internet explorer comme Firefox).

Bien que faiblement utilisé, le JavaScript doit être activé. IE est le standard AIRBUS.

c. Serveur web et applicatif Serveur en production :

Le niveau Middleware s’appuie sur le logiciel Iplanet 6.0 SP5 (serveur HTTP et moteur Servlets / JSP) et les technologies J2EE (Servlets / JSP / JDBC).

d. Base de données

Le niveau Serveur de Données s’appuie sur le noyau ORACLE 9, sans option d’installation particulière.

2.4.2. Mise en œuvre de l’architecture

a. Architecture de l’application

L’architecture correspond au modèle MVC.

Elle est basée sur 3 couches :

Couche graphique : ce sont les JSP

Couche modèle/contrôleur : ce sont les servlets ;

Couche de données, mise en œuvre de Hibernate pour la persistance.

Toute page JSP appelle une ou plusieurs servlets. Ce sont elles qui redirigent ensuite vers une page JSP, après avoir réalisé leurs actions associées (sauvegarde en base, réalisation de contrôles, chargement de données, …).

b. Architecture de la base de données

Tous les objets database sont définis dans le schéma BTR.

Les données externes à ce schéma sont accessibles via des synonymes dans le schéma OIOC.

3. Conception

3.1. Création d'un MCD

Création d'un schéma de base de données dédié au projet.

J’ai réalisé un référentiel regroupant toutes les données utiles et nécessaires aux informations d'une demande, ainsi qu'a la réalisation du projet.

Le dictionnaire de données s’appuie sur la collecte d’informations dans les fichiers Excel, ainsi que sur les retours des utilisateurs (informations complémentaires de la part d’Airbus, connaissances de HP sur les informations utiles à la mise en place d’un backup système).

Et en dernier lieu, des informations nécessaires à certaines fonctionnalités de l’application.

Schéma : annexe 8.1 page 25

3.2. Choix du concept Mapping Objet-Relationnel

Les difficultés de cohabitation entre les mondes objets et relationnels sont résolues grâce au concept de Mapping objet-relationnel (O/R Mapping), qui est le nom donné aux techniques de transformation des modèles objets en modèles relationnels.

Nous avons donc choisi une séparation en différentes couches de l’application.

Ces couches devant être indépendantes, leur développement pourra se faire en parallèle, et la maintenance de l’application n’en sera que plus aisée.

endroits de l’application, par exemple pour lire tous les clients présents dans la base de données.

Au minimum, cette couche se doit de prendre en compte l’ensemble des interactions possibles avec la base de données, c’est-à-dire la création, la lecture, la modification ou la suppression des enregistrements dans chacune des tables de la base de données. Il est commun de créer une classe pour chaque table existante, et de créer des méthodes possédant autant de paramètres que la table possède de champs.

3.2.1. Utilisation du pattern Data Access Object (DAO)

Quel que soit le système sur lequel vous développez, vous pourrez toujours accéder à vos données relationnelles. Vous utiliserez alors des API telles que JDBC, ADO, ADO.Net, et pourrez alors exécuter des requêtes SQL, ou obtenir des objets représentant des tables et leurs champs.

Ces outils sont suffisants mais ne permettront jamais à eux seuls une vraie abstraction de la base de données sous-jacente. Par exemple vous ne pourrez pas obtenir toutes les commandes d’un client donné avec une seule ligne de code. De plus, chaque fois que vous voudrez supprimer un client, vous devrez supprimer manuellement son adresse, alors que cela pourrait être fait automatiquement.

Tous ces problèmes doivent être gérés par une couche d’accès aux données chargée de communiquer avec le serveur de bases de données, et de renvoyer des objets métiers au programmeur. Ce denier n’aurait alors plus besoin de taper des requêtes SQL, comprendre les relations entre les tables, ou connaître tous les paramètres des procédures stockées, ou encore d’autres éléments. Lorsqu'on parle de séparation des couches par responsabilité, il y a va également de la séparation des compétences de chaque développeur.

C’est à cela que servent les DAO. Ils sont créés pour simplifier au maximum le travail du programmeur avec le système de données en encapsulant les accès à la base via les frameworks tels qu’ADO.Net. Les programmeurs utilisent par exemple une méthode Save() pour sauvegarder une entité. Cette méthode créera une requête SQL d’insertion ou de mise à jour si nécessaire. On peut également imaginer que les DAO nous permettent d’accéder à des entités qui sont en relation, effectuant les jointures en base de données automatiquement.

3.3. Conception d’un diagramme de classe métier

Le modèle du domaine constitue l'ensemble des entités persistantes de L’application. C'est une résultante de la conception et de l'analyse système. Par définition, le modèle du domaine ne doit en aucun cas contenir de lien avec un quelconque Framework technique. Le risque serait d'exposer le modèle métier aux évolutions techniques et remettre en cause la pérennité du modèle. Une équation loin d'être évidente à résoudre surtout lorsqu'on sait que les API d'accès en base font aussi partie de ces conditions.

Schéma : annexe 8.2 page 28

3.4. Choix du concept Modèle Vue Contrôleur (MVC)

Le Model-View-Controller (MVC) est un modèle de conception logicielle très répandu et fort utile. Créé dans les années 80 par Xerox PARC pour Smalltalk-80, il est aujourd’hui fortement recommandé dans l’univers J2EE. Néanmoins il faut retenir que c’est un modèle de conception, et il est donc indépendant du langage de programmation.

Le MVC est un modèle de conception qui repose sur la volonté de séparer les données, les traitements et la présentation. Ainsi l’application se retrouve segmentée en trois composants essentiels :

• le modèle

• la vue

• le contrôleur

Chacun de ces trois composants a un rôle bien défini.

Le modèle représente les données et les règles métiers. C’est dans ce composant que s’effectuent les traitements liés au cœur du métier. Les données peuvent être liées à une base de données, des EJBs, des services Web, … Il est important de noter que les données sont indépendantes de la présentation. En d’autres termes, le modèle ne réalise aucune mise en forme. Ces données pourront être affichées par plusieurs vues.

Du coup le code du modèle est factorisé : il est écrit une seule et unique fois puis réutilisé par chaque vue.

La vue correspond à l’IHM. Elle présente les données et interagit avec l’utilisateur. Dans le cadre des applications Web, il s’agit d’une interface HTML, mais n’importe quel

composant graphique peut jouer ce rôle.

Le contrôleur, quant à lui, se charge d’intercepter les requêtes de l’utilisateur, d’appeler le modèle puis de rediriger vers la vue adéquate. Il ne doit faire aucun traitement. Il ne fait que de l’interception et de la redirection.

Le MVC favorise le développement et la maintenance du code. Sur de gros projets et/ou avec de grandes équipes de développement, l’application d’un tel modèle de conception se révèle très performant.

4. Développement

4.1. Le langage de développement

Un certain nombre de critères sont envisagés pour réaliser ce choix : - Le caractère Open Source du langage.

- Le partage de code avec d'autres projets.

La principale difficulté d'un projet de développement en gestion réside dans le volume du code à gérer, lors du développement et surtout lors de la maintenance de l'outil.

Pour assurer la pérennité du projet, il faut un langage "structurant" qui incite à produire du code lisible et maintenable.

Sur ce point le caractère objet du langage Java le rend adapté à un développement de grande envergure. Il permet une bonne division du travail entre les développeurs grâce au principe de l'encapsulation.

Le langage Java dispose de nombreux outils d'accès aux bases de données, grâce à l'interface JDBC et à l'existence de drivers pour toutes les bases de données relationnelles.

Il dispose de bibliothèques commerciales permettant d'asseoir le projet sur une conception objet pure et de déléguer les problèmes de stockage des objets à ces bibliothèques ("persistance").

Le langage sélectionné est donc Java.

4.1.1. Frameworks de persistance Hibernate

Les frameworks de persistance sont plus que de simples wrappers de tables proposant l'accès aux champs de celles-ci. Il s’agit en général d’outils permettant de modéliser un système de données, en UML ou en XML par exemple, et de générer tous les DAO ainsi que les objets métiers permettant d’exploiter au maximum un système de données.

De plus, ils prennent en charge des concepts avancés comme le cache des objets, la concurrence, les transactions distribuées, le chargement des données via des requêtes objets, et peuvent également offrir une totale indépendance vis-à-vis du serveur de bases de données.

Ils créent des systèmes complètement autonomes de gestion du système

d’information, autorisent un fort découplage avec la base de données, améliorent les performances et apportent une grande simplicité d’utilisation.

4.2. Environnement de développement

Pour le développement, j’ai utilisé le moteur de servlets « Tomcat 4.1 » ainsi que l’éditeur Eclipse 3.2.1 WTP (web tools platform). Le plugin’ de Sysdeo «Tomcat plugin»

qui permet de lancer le serveur Tomcat directement depuis Eclipse.

4.3. Implémentation du modèle de donnée avec Hibernate

4.3.1. Configuration d’Hibernate

La configuration d’Hibernate est réalisée par le biais d’un fichier XML.

Avec les éléments de connexion a la base de données, le langage SQL a utilisé et les fichiers ressource de mapping XML des objets.

4.3.2. Les fichiers de mapping

Hibernate a besoin de savoir comment charger et stocker des objets d'une classe persistante. C'est là qu'intervient le fichier de mapping Hibernate. Il indique à Hibernate à quelle table dans la base de données il doit accéder, et quelles colonnes de cette table il devra utiliser.

Un fichier de mapping XML est donc en général constitué d’une partie identificatrice de l’objet et d’une partie listant les propriétés de cet objet.

Certaines propriétés peuvent provenir d’une association et être elles-mêmes un objet, ou même encore être une liste d’objets.

Les propriétés en relation deviennent des agrégations d’objets.

Il est donc possible de charger un objet qui agrège d’autres objets et l’on charge alors plusieurs objets en cascade.

a.

Optimiser le mapping

Le pattern Lazy-loading permet de contrôler ce niveau de chargement.

Communément appelé chargement paresseux (car un attribut lazy= « false »), ce pattern va automatiquement charger les objets en cascade quand on utilisera la méthode load() d’Hibernate.

Cela veut dire que si nous désirons un niveau de chargement en cascade différent de celui programmé dans le mapping, il faudra utiliser le langage HQL d’Hibernate et signifier quelles sont les liaisons désirées dans ces requêtes.

Ce qui rend plus lourd la réalisation de celles-ci.

Une autre solution est de mettre un attribut fetch= « join » au niveau des liaisons du mapping. Ces liaisons seront prises en charge au niveau de la méthode get()

J’ai donc opté pour une solution qui est de na pas utiliser les attributs lazy ni fetch, mais de contrôler le niveau de chargement par la méthode get(), et de faire un getObject() uniquement sur les objets dont j’ai besoin.

Ce qui rend le développement du code et la maintenance plus simple.

b.

Problème de jointure externe non résolue

L’attribut found= « ignore » sur les jointures dans le mapping génère des objets vide si besoin est.

Mais ceci oblige Hibernate à lancer une requête SQL à chaque occurrence, et ralentit énormément les temps de chargement.

Je n’ai pas trouvé de solution au niveau du code pour éviter d’utiliser cet attribut.

4.3.3. Les Beans

Les beans sont simplement les Classes représentant les futurs objets persistants.

A chaque Bean correspond un fichier mapping.

Chaque objet Bean possède : - un constructeur par default.

- les propriétés privées de l’objet.

- les méthodes Getteurs et Setteurs pour y accéder.

- la méthode hashCode pour déterminer l’identificateur de l’objet (possibilité sur plusieurs propriétés).

- la méthode equals() pour faire des comparaisons d’objets.

4.3.4. Les Managers

Les Classes Managers ont la responsabilité de la transaction entre la base de donnés et les objets beans.

A chaque objet beans correspond un manager.

Possibilité de loader un objet en lui renseignant son identifiant, de supprimer, de sauvegarder ou de modifier des objets ou de charger des listes correspondant a des critères suivant les besoins de l’application.

4.4. Implémentation des Servlets et JSP 4.4.1. Les Servlets

Les servlets sont des classes qui vont permettre de contrôler l’application.

Leur rôle sera :

- de prendre en compte des paramètres (provenant en général de l’url généré par les jsp).

- de contrôler, grâce aux classes managers, des sauvegardes, des modifications ou des suppressions si besoin

- de charger des objets nécessaires au besoin de l’enchainement suivant.

En fonction des résultats (sécurité, erreur, choix) elle lancera un jsp en pouvant lui passer en paramètre n’importe quel objet utile.

Une servlet peut aussi lancer une autre servlet suivant les enchaînements prévus.

4.4.2. Les JSP

Les JSP servent uniquement aux vues. Ils n’auront aucun traitement à effectuer.

Leur rôle est donc d’afficher les informations, d’acquérir les renseignements et actions de l’utilisateur.

Pour cela j’ai utilisé du JavaScript qui rend l’application dynamique coté utilisateur, comme l’affichage de nouveau formulaire suivant la saisie de l’utilisateur, ou encore l’utilisation d’un calendrier dynamique.

JavaScript me permit aussi de collecter et de vérifier les renseignements avant de lancer la servlet suivante.

J’ai récupéré un fichier CSS qui avait été créé pour d’autres applications Infotel (charte graphique), que j’ai légèrement modifié pour des besoins spécifique de l’application, mais qui reste standard Infotel.

4.5. Débugage

Pour le débugage j’ai utilisé l’API Log4j.

Pour l’utilisation, il faut paramétrer un fichier log4.properties.

On paramètre également des objets de sortie. Pour ce projet, j’ai réalisé :

- une sortie pour le développement avec Tomcat en local, avec affichage des infos dans la console Eclipse et un niveau de traçage commençant au debug

4.6. Construction et compilation avec le Fichier Ant

Le fichier Ant permet de valoriser les paths et les environnements, de pouvoir construire des répertoires temporaires permettant la compilation et de réaliser la livraison de l’application (soit en local, développement, soit en environnement d’intégration ou même par FTP en environnement de production).

Tous ces éléments sont générés de manière automatique par Ant.

4.7. Gestion de version

Pour gérer les versions des fichiers, et travailler a plusieurs sur un projet, nous avons installé un plugin d’Eclipse, Subversion, qui est l'évolution de CVS, un autre système de gestion de version. SVN est un des systèmes de gestion de versions les plus élaborés.

5. Difficultés rencontrées

Les difficultés majeures ont été le temps imparti à la réalisation de l’intégralité du projet.

Des phases de recherche on été possible, mais l’utilisation d’Hibernate aurait mérité d’aller plus loin. Surtout pour l’optimisation du mapping.

6. Conclusion

Je retire de ce stage une pleine satisfaction, car le projet est arrivé à terme.

La livraison et l’acceptation de l’application se sont très bien déroulées.

Cette réalisation de projet au sein de la société Infotel a été très enrichissante.

J’ai pu mettre en pratique mes connaissances acquises lors de la formation, et j’ai aussi profité de la compétence de mon entourage tant en matière technique que dans le savoir faire et le suivi du bon déroulement d’un projet.

J’ai aussi découvert le milieu et le contexte du métier très riche de la gestion de sauvegarde de projet dans un cadre aussi gigantesque qu’Airbus.

Ce stage a renforcé ma motivation de réalisation et de création au sein d’une équipe.

A ce jour, mon partenariat avec Infotel continue. L’entreprise m’a en effet proposé un contrat pour la réalisation de nouveaux projets.

7. Bibliographie

http://www.Hibernate.org/hib_docs/v3/reference/fr/html/index.html Documentation de référence d'Hibernate

http://www.dotnetguru.org

Source d’info sur la persistance des données.

http://java.developpez.com/

Source d’info sur les techniques java et Hibernate.

8. Annexes

8.1. Annexe 1 : Modèle Conceptuel des Données.

8.2. Annexe 2 : Diagramme de classes métiers.

8.3. Annexe 3 : Quelques captures d’écrans.

Annexe : Modèle Conceptuel de données

Annexe : Diagramme de classes métiers

Annexe : Quelques captures d’écrans

Le filtre de recherche de requirement :

L’éditeur de requirement et son pop-up check :

L’éditeur de policy et sa pioche de catalogue Tina :

L’éditeur de Schedule :