Vous êtes sur la page 1sur 63

Sommaire

Table des matières

Sommaire

Introduction générale

6

Chapitre 1 : Présentation du cadre de projet

7

Introduction

7

1.1. Présentation de l’organisme d’accueil

7

1.2. Etude de l’existant

8

1.3. Solution proposée

10

1.4. Démarche méthodologique

10

Conclusion

14

Chapitre 2 : Analyse et spécification des besoins

15

Introduction

15

2.1. Etude préliminaire

15

2.2. Capture des besoins fonctionnels

16

2.3. Capture des besoins techniques

25

2.4. Capture des besoins non fonctionnels

29

Conclusion

32

Chapitre 3 : Conception

33

Introduction

33

3.1. Conception préliminaire

33

3.2. Conception détaillée

35

Conclusion

47

Chapitre 4 : Réalisation

48

Introduction

48

4.1. Environnement de travail

48

4.2. Etapes de mise en œuvre

52

4.3. Vue de l’interface du portail

53

ESPRIT

Page 1

Sommaire

4.4. Evaluation

58

4.5. Problèmes rencontrés

60

Conclusion

60

Conclusion générale

61

Références

62

ESPRIT

Page 2

Liste des tableaux

Liste des tableaux

Tableau 1 : Etude comparative sur les méthodologies de développement

12

Tableau 2 : Description des acteurs

16

Tableau 3 : Identification des cas d’utilisation

17

Tableau 4 : Description textuelle de cas « créer projet »

20

Tableau 5 : Description textuelle de cas « consulter matériel »

21

Tableau 6 : Description textuelle de scénario « créer CV »

22

Tableau 7 : Description textuelle de cas d’utilisation « consulter projets associés »

24

Tableau 8 : Tableau comparatif SPRING vs EJB3.0

27

Tableau 9 : Tableau comparatif entre JSF et STRUTS

28

Tableau 10 : Classes candidates par cas d’utilisation

34

ESPRIT

Page 3

Liste des figures

Liste des figures

Figure 1 : Organisation de l’IRESA

8

Figure 2 : Schéma d’architecture de l’application NAIS

9

Figure 3 : Projection d’XP et 2TUP sur la matrice de RUP

12

Figure 4 : Phases de processus 2TUP

13

Figure 5 : Diagramme de contexte statique

15

Figure 6 : Diagramme des cas d’utilisation

18

Figure 7 : Diagramme de séquence système de scénario « créer projet »

20

Figure 8 : Diagramme de séquence système de scénario « consulter matériel »

21

Figure 9 : Diagramme de séquence système de scénario « créer CV »

23

Figure 10 : Diagramme de séquence système de scénario « consulter portefeuille »

24

Figure 11 : Architecture 3-tiers

25

Figure 12 : Etats constitutifs d’une authentification

30

Figure 13 : Les critères de succès d’un site web selon les utilisateurs

31

Figure 14 : Diagramme de classe d’analyse

33

Figure 15 : Prototype d’interface

35

Figure 16 : diagramme de classe singleton

36

Figure 17 : Diagramme de classe de pattern DAO

36

Figure 18 : Le pattern MVC

37

Figure 19 : Interaction entre les composants de MVC

37

Figure 20 : Diagramme de package

38

Figure 21 : Diagramme de classe de package « persistence»

39

Figure 22 : Diagramme de classe de package « Service »

40

Figure 23 : Diagramme de classe de package « DAO »

41

Figure 24 : Diagramme de classe de package « présentation »

42

Figure 25 : Diagramme de séquence de « création de CV »

43

Figure 26 : Diagramme de séquence de scénario « création de projet »

44

Figure 27 : diagramme d’état transition scénario création projet

45

Figure 28 : Diagramme de séquence « consulter portefeuille »

45

Figure 29 : Diagramme d’activité scénario « réserver matériel »

46

Figure 30 : Panneau de commande de gestion des organisations

54

Figure 31 : Formulaire d’ajout du projet

54

Figure 32 : Administration des projets

55

ESPRIT

Page 4

Liste des figures

Figure 33 : Créateur des CV

56

Figure 34 : Portefeuille des projets associés à un chercheur

56

Figure 35 : Inventaire d’un équipement

57

Figure 36 : Interface réservation équipements

58

Figure 37 : Panneau de commande gestion des utilisateurs

59

ESPRIT

Page 5

Introduction générale

Introduction générale

Face à l’évolution de la recherche scientifique agricole et à l’accroissement de la complexité des projets envisagés dans ce domaine, les tâches de gestions et d’administrations sont devenues de plus en plus complexes.

C’est dans ce sens que l’Institution de la Recherche et de l’Enseignement Supérieur Agricole vise à mettre en place un portail web afin d’offrir un canal d’information unique et personnalisé pour les différentes organisations sur le plan national.

En effet, un portail web permet de centraliser l’accès à l’information pour les utilisateurs d’une part et offre un point unique de contrôle et d’administration aux personnels d’autre part. De même, un portail web offre un système de publication de contenu facile à utiliser même pour des auteurs non-informaticiens. Sans oublier les moyens de collaborations qui peuvent être offerts par un portail dont l’objectif est de susciter la collaboration, de permettre le partage de l’information et le développement des connaissances.

Dans le cadre de notre formation d’ingénieurs à l’Ecole Supérieure Privée d’Ingénierie et de Technologie, nous avons eu l’occasion de faire notre projet de fin d’études au sein de l’Institution de la Recherche et de l’Enseignement Supérieur Agricole.

Le présent document est organisé comme suit :

Le premier chapitre contiendra une description de notre projet, une étude de l’existant avec la solution proposée.

Dans le deuxième chapitre, nous présenterons la phase d’analyse et de capture des besoins fonctionnels, non fonctionnels et techniques.

En ce qui concerne le troisième chapitre, il sera réservé à la formulation de la phase de conception de la solution déjà décrite dans le premier chapitre selon une étude statique et dynamique.

Enfin, dans le dernier chapitre, nous exposerons la phase de réalisation avec la description des étapes de mise en œuvre et l’environnement de travail

ESPRIT

Page 6

Présentation du cadre de projet

Chapitre 1 : Présentation du cadre de projet

Introduction

Dans ce chapitre, nous allons présenter le cadre général du projet, l’organisme d’accueil, une critique de l’existant, la solution proposée et la méthodologie de développement adoptée.

1.1. Présentation de l’organisme d’accueil

L’institution de la recherche et de l’enseignement supérieur agricole, crée par la loi 90- 72 du 30 juillet 1990, est un établissement public à caractère administratif doté de la personnalité civile et de l’autonomie financière. Elle est placée sous la tutelle du ministère de l’agriculture et de l’environnement. Elle est chargée d’accomplir les missions suivantes :

Veiller à la promotion de la recherche agricole dans le cadre de la politique générale de l’état dans ce domaine, en assurant la liaison entre les établissements de recherche et de l’enseignement supérieur agricole d’une part et la vulgarisation agricole et les producteurs d’autre part.

Elaborer les programmes de recherche agricole et les budgets nécessaires pour leurs réalisations, suivre l’exécution de ces programmes et en assurer l’évaluation tout en veillant à la coordination et à la complémentarité entre les établissements de recherche et l’enseignement supérieur dans les domaines agricoles.

Veiller à ce que les établissements de recherche et d’enseignement supérieur agricoles soient au service de la production agricole et de développement.

En plus des directions centrales, les services extérieurs, érigés en Pôles Régionaux de Recherche et de Développement Agricoles (PRRDA) et centres régionaux, constituent les relais régionaux qui permettent à l'Institution, d'opérer un rayonnement de la recherche agricole sur le plan national, au niveau de la circonscription territoriale de chaque pôle et centre.

Deux PRRDA et quatre centres régionaux couvrent l'ensemble du territoire du pays selon un découpage territorial, basé sur un critère pédoclimatique, se présentant comme suit :

ESPRIT

Page 7

Présentation du cadre de projet

Centre Régional de Recherche en Agriculture Oasienne de Degueche (Tozeur)

Centre Régional de Recherche en Horticulture et Agriculture Biologique de Chott Mariem (Sousse).

Centre régional des recherches agricoles (Sidi Bouzid).

Centre régional des recherches en grandes cultures (Béja).

PRRDA du Nord Est (Mornag).

PRRDA du Nord Ouest semi-aride (Le Kef). [1]

La figure ci-dessous indique comment est organisé l’IRESA

La figure ci-dessous indique comment est organisé l’IRESA Figure 1 : Organisation de l’IRESA 1.2. Etude

Figure 1 : Organisation de l’IRESA

1.2. Etude de l’existant

Notre étude consiste à présenter l’architecture du système existant et l’évaluer. Aussi, à travers cette étude, nous visons à déterminer les besoins métiers aux seins du système d’information.

1.2.1. Description de l’existant

Le nombre exact des établissements qui sont spécialisés dans le domaine de la recherche scientifique est 20 établissements qui participent dans plusieurs projets agricoles. La solution

ESPRIT

Page 8

Présentation du cadre de p rojet

actuelle pour gérer ces éta blissements avec leurs projets est une a pplication nommée « NAIS » (National Agricultu ral Information System) qui est une applicati on web basée sur le principe de système de gestio n de contenu (CMS). L’application « NAIS » est composée de deux parties :

Une partie privée : P ermettant aux administrateurs, après l’auth entification et avec des droits d’accès bie n précis, de gérer le contenu (les publicati ons, les projets de recherche, les établisse ments…). L’administration se fait selon un processus d’affaire, en effet, chaque publi cation ou projet ajouté ne sera pas directem ent publié qu’après une validation.

Une partie publique : qui permet aux visiteurs de consulter les informations sur les pr ojets.

publications et les

La figure ci-dessous pré sente l’architecture de l’application NAIS:

Adm inistrateur Front o ffice Back office Entr epôt de données
Adm
inistrateur
Front o
ffice
Back office
Entr
epôt de données
Front o ffice Back office Entr epôt de données Visiteurs Figu re 2 : Schéma d’architecture

Visiteurs

Figu re 2 : Schéma d’architecture de l’application NAI S

1.2.2. Crit ique de l’existant

La solution actuelle prés ente plusieurs limites qu’on va citer:

Absence d’un espace chercheur d’avoir son

ne permet pas à un

propre compte pour enrichir son profil sci entifique (Création

d’un CV, choix des c atégories, portefeuille des projets, compéte nces) et suivre les projets qui lui sont ass ociés.

réservé aux chercheurs : Cette solution

ESPRIT

Page 9

Présentation du cadre de projet

Absence des moyens de collaboration : Manque des moyens qui permettent de faciliter le travail en équipe.

Administration centralisée : Dans ce cas, les établissements ne peuvent pas avoir leurs propres espaces personnalisables et ne peuvent pas gérer leurs propres contenus à partir d’un espace d’administration. De ce fait, tout est géré au niveau de l’établissement mère (IRESA).

Absence des

outils

de suivi des

avancement des projets.

projets : Résultat

de projet,

Etat

de projet,

Absence des outils de gestion de matériel scientifique : Réservation matériel, Demande matériel, Suivi de matériel, Maintenance, Pannes…

Absence d’un gestionnaire des ressources documentaires.

1.3. Solution proposée

Notre solution est de mettre en place un portail permettant aux diverses organisations agricoles d’avoir leurs propres espaces personnalisables et qui offre une gestion simple des projets et de matériel scientifique avec des moyens de collaboration facile à utiliser.

Ainsi, chaque établissement pourra gérer son propre contenu en profitant des moyens de collaboration utiles offerts par le portail pour faciliter la communication entre les différents types d’acteurs.

La solution proposée a pour objectif de permettre aux utilisateurs de pouvoir créer des profils scientifiques et de leurs faciliter les tâches administratives des projets de recherche tout en offrant des outils de suivi pour les projets réalisés.

1.4. Démarche méthodologique

Cette partie contiendra une comparaison entre quelques méthodologies de développement, ensuite une explication de notre choix méthodologique et enfin une description de la méthodologie choisie.

ESPRIT

Page 10

Présentation du cadre de projet

1.4.1. Etude comparative

Les systèmes de nos jours sont de plus en plus complexes. Le génie logiciel tente à

remédier à cette complexité en offrant une démarche à suivre avec des étapes bien précises.

C’est le principe des méthodologies de développement.

Le but de développement d’un logiciel c’est d’avoir un logiciel de qualité qui répond

aux standards et aux normes de développement. Pour cela, nous sommes obligés de suivre une

méthodologie de développement afin de garantir une bonne qualité pour notre application.

Le tableau ci-dessous contient un comparatif entre les principaux méthodologies de

développement que nous avons choisit vue la diversité de ces méthode : [2]

Méthodologie

 

Description

 

Points forts

 

Points faibles

Cascade

Les phases sont déroulées

Distingue

clairement

les

-Non Itératif

d’une

manière

phases projet.

séquentielle.

 

-Ne propose pas des modèles pour les documents.

RUP

(Rational

-Elaboré par rational.

 

- Itératif.

-couteux

à

Unified Process)

 

personnaliser :

-Le RUP est à la fois une méthodologie et un outil prêt à l’emploi

-Intéragir les différents intervenant du projet (Les livrable, les plannings, les prototypes …)

Batterie

de

 

consultants.

-Peu de place pour le développement et la technologie.

-Cible de projet : Plus de 10 personnes.

-propose des modèles de documents pour des projets type.

XP

(eXtreme

-Ensemble des bonnes

-Itératif

-Assez flou dans sa mise en œuvre

Programming)

pratiques

 

de

développement (Travail en équipe, transfert de

-Donne une importance aux aspects techniques :

-Ne couvre pas les

 

compétence …).

 

Règles de développement.

phases en amont et en

-Cible :

Moins

de

10

-Innovant :

aval développement :

au

personnes.

 

Programmation en duo

 

Capture des besoins, maintenance …

2TUP(Two

 

-Itératif

 

Truck

Process)

Unified

-Propose un cycle de développement en Y.

-Cible

toutes tailles

des

projets

de

-Fait un large place à la technologie et à la gestion des risques.

-Définit les profils des intervenants, les livrables, les plannings,

-Plutôt superficiel sur les phases

situées en amont et aval

en développement :

capture des besoins, support, maintenance, gestion du changement…

du

ESPRIT

Page 11

Présentation du cadre de projet

les prototypes -Ne propose pas de documents types
les prototypes -Ne propose pas de documents types

les prototypes

-Ne propose pas de documents types

Tableau 1 : Etude comparative sur les méthodologies de développement

La figure ci-dessous montre phases dans un projet.

une projection de ces méthodologies sur les différentes

une projection de ces méthodologies sur les différentes Figure 3 : Projection d’XP et 2TUP sur

Figure 3 : Projection d’XP et 2TUP sur la matrice de RUP

En effet, Le RUP couvre l’ensemble du processus (Spécification des besoins, la conception, le développement et les tests) en spécifiant les interactions entre chacun des phases, XP se concentre sur la phase de développement, tandis que 2TUP fait une large place à l’analyse et à l’architecture.

Après l’étude comparative faite sur quelques processus de développement, nous avons optés d’éliminer le RUP car il ne donne pas une importance à la technologie et aux contraintes techniques ce qui présente une grande partie de notre projet. Aussi nous inhibons l’utilisation de CASCADE car c’est un processus séquentiel et non itératif, par conséquence si une fonctionnalité ajoutée ou un besoin technique qui se présente, il y aura des problèmes d’intégration. De même, nous éliminons l’XP qui néglige, de sa part, la phase de capture des besoins fonctionnels et techniques. De plus XP donne une grande importance à la phase de développement contrairement à la phase de conception.

ESPRIT

Page 12

Présentation du cadre de projet

1.4.2. Méthodologie adoptée: 2TUP

Nous avons optés pour le processus 2TUP pour des raisons multiples. D’une part, 2TUP donne une grande importance à la technologie ce qui est important pour notre projet, d’autre part, 2TUP est un processus en Y qui contient une branche technique et autre fonctionnelle. Ces deux branches peuvent êtres exploités en parallèle. De ce fait, si la technologie évolue ou lors de déroulement du projet il y a eu apparence d’un besoin technique, la branche technique peut être traitée puis réintégrée dans le projet facilement. De même si une nouvelle fonctionnalité se présente, seule la branche fonctionnelle va être traitée sans toucher à l’autre branche. [2]

Principe :

Ce processus commence par une étude préliminaire qui permet d’identifier les acteurs du système à mettre en œuvre qui est considéré comme une boite noir tout en présentant les différents messages entre les utilisateurs et ce système et d’élaborer le cahier des charges. La figure 4, montre les différentes étapes de processus 2TUP :

4, montre les différentes étapes de processus 2TUP : Figure 4 : Phases de processus 2TUP

Figure 4 : Phases de processus 2TUP

D’après la figure 4, on remarque que 2TUP est composé essentiellement de trois étapes :

ESPRIT

Page 13

Présentation du cadre de projet

Une branche fonctionnelle (à gauche) :

Capture des besoins fonctionnels, qui produit les modèles des besoins en se basant sur le métier des utilisateurs. Cette étape élimine le risque d’avoir un système inadapté aux besoins des utilisateurs.

L’analyse qui consiste à étudier les besoins fonctionnels de manière à obtenir une idée de ce que va réaliser le système en terme métier.

Une branche technique (à droite) :

Capture des besoins techniques, cette étape permet de recenser les contraintes de choix de dimensionnement et de conception du système. Les outils selectionnés ainsi que les contraintes d’intégration avec l’existant(pré requis d’architecture technique).

L’étape conception générique définit ensuite les composants nécessaires à la construction de l’architecture technique. Cette conception est complètement indépendante des aspects fonctionnels.

Une branche de réalisation (au mileu) :

La conception préliminaire, c’est une étape un peut délicate, car elle intègre le modèle d’analyse fonctionnel dans l’architecture technique de manière à tracer la cartographie des composants du système à développer.

La conception détaillée, qui permet d’étudier comment réaliser chaque composant.

L’étape de codage, qui est ensuite l’étape de production de ces composants ainsi que les tests unitaires au fur et à mésure sur chaque composant.

L’étape de recette, qui consiste enfin à la validation des différentes fonctionnalitées du système.

Conclusion

Dans ce chapitre, nous avons présentés le cadre de projet, cités les limites du système actuelle, la solution que nous proposons ainsi que le processus de développement que nous allons utiliser. Dans le chapitre suivant, nous allons spécifier et analyser les besoins fonctionnels et techniques de système à réaliser.

ESPRIT

Page 14

Analyse et spécification des besoins

Chapitre 2 : Analyse et spécification des besoins

Introduction

Le présent chapitre présentera la phase d’analyse et de spécification des besoins. Nous allons commencer tout d’abord, par l’étude préliminaire dans laquelle nous allons identifier les acteurs de notre système. Ensuite, nous procèderons à l’étude fonctionnelle et technique de notre projet.

2.1. Etude préliminaire

L’étude préliminaire est la première étape dans le processus 2TUP. cette étape consiste à faire l’identification et la description des acteurs.

2.1.1. Identification des acteurs

Un acteur représente une abstraction d’un ensemble des rôles joués par des entités externe et qui intéragit directement avec le système (Utilisateur, autre système, dispositif…). La figure ci-dessous présente le diagramme de contexte statique qui permet de tirer les différents acteurs qui intéragissent avec le système qui est considéré comme une boite noire dans cette étape.

qui est considéré comme une boite noire dans cette étape. Figure 5 : Diagramme de contexte

Figure 5 : Diagramme de contexte statique

ESPRIT

Page 15

Analyse et spécification des besoins

2.1.2. Description des acteurs

Le tableau ci-dessous contient la description des acteurs de notre système :

Acteur

 

Description

 

Administrateur

Cet acteur est le super administrateur appartenant à l’IRESA. Son rôle est de gérer les utilisateurs, les règles d’accès aux services ainsi que les organisations.

Administrateur organisation

Pour chaque organisation, il y à un administrateur qui peut gérer son contenu (projet, matériel, publications) et personnaliser son affichage.

Fonctionnaire

Appartient à une organisation et bénéfice des services d’ajout de contenu (projet, publications).

 

Les

chercheurs

appartiennent

aux

Chercheur

organisations et

peuvent

bénéficier

des

services de collaboration et projets.

de

suivi

des

Tableau 2 : Description des acteurs

2.2. Capture des besoins fonctionnels

Nous allons commencer dans cette partie par l’identification des cas d’utilisation par

acteur.

2.2.1. Identification des cas d’utilisation

Le tableau ci-dessous contient une classification des cas d’utilisation par acteur :

Acteur

Cas d’utilisation

Administrateur

Gérer organisation

Gérer utilisateur et rôle

ESPRIT

Page 16

Analyse et spécification des besoins

 

Gérer les publications Gérer les projets Créer projet Gérer matériel organisation Gérer demandes matériels

Administrateur organisation

 

Gérer publications Créer projet Affecter chercheur Affecter matériel

Fonctionnaire

 

Suivi projet Déposer document Créer CV Réserver matériel Signaler panne matériel Consulter projets associés

Chercheur

Tableau 3 : Identification des cas d’utilisation

2.2.2. Analyse

2.2.2.1. Diagramme des cas d’utilisation

Les fonctionnalités globales sont illustrées dans le diagramme des cas d’utilisation, qui est présenté dans la figure ci-dessous :

ESPRIT

Page 17

Analyse et spécification des besoins

Analyse et spécification des besoins Figure 6 : Diagramme des cas d’utilisation 2.2.2.2. Description des cas

Figure 6 : Diagramme des cas d’utilisation

2.2.2.2. Description des cas d’utilisation

Cette partie contient une description textuelle avec des diagrammes de séquence système des cas d’utilisation les plus importants de notre projet.

a. Description du scénario création d’un projet

SOMMAIRE DE CREATION DES PROJETS

Titre

Créer un projet

ESPRIT

Page 18

Analyse et spécification des besoins

But

   

La création des projets

Résumé

 

La création des projets est une tâche partagée entre l’Administrateur organisation et le fonctionnaire. En effet, le fonctionnaire peut ajouter un projet en affectant des ressources matériel et des chercheurs. l’Administrateur organisation, il peut consulter ces projets, supprimer un projet et choisir de publier ou de rejeter un projet.

Acteur

   

Administrateur organisation, fonctionnaire

 

DESCRIPTION DES ENCHAINEMENTS

 

Pré conditions

   

Post conditions

L’administrateur organisation ainsi que fonctionnaire doivent s’authentifier

Choisir une action à faire Opération effectué Le projet ajouté est par défaut non publié

Choisir le service gestion des projets

 

Pour

l’ajout

d’un

projet

au

moins

un

chercheur doit être affecté.

   
 

Scénario principal

 

1. Le fonctionnaire choisit d’ajouter un projet et remplit le formulaire

2. Le système valide le formulaire et effectue l’opération d’ajout

3. Le fonctionnaire affecte l’ensemble des chercheurs au projet

4. Le système retourne un message de satisfaction

 

5. L’administrateur organisation choisit de consulter la liste des projets

6. Il choisit de publier un projet

 

7. Le système effectue l’opération et retourne un message de satisfaction

 

Enchainnements alternatifs

 

E1 : Projet n’existe pas

 
 

1. Le système affiche un message d’erreur

 

2. L’administrateur corrige les erreurs et valide E2 : Affectation matériel

 

1. Le fonctionnnaire choisit d’affecter un matériel à un projet

ESPRIT

Page 19

Analyse et spécification des besoins

2. Chercher le matériel désiré

3. Le système vérifie la disponibilité du matériel

4. Le système effectue l’opération et retourne un message de satisfaction E3 : Matériel non disponible

1. Le système retoune un message de non satisfaction

2. Le fonctionnaire contacte l’administrateur de l’organisation

Tableau 4 : Description textuelle de cas « créer projet »

La figure ci-dessous montre le diagramme de séquence concernant le scénarion « créer projet »

de séquence concernant le scénarion « créer projet » Figure 7 : Diagramme de séquence système

Figure 7 : Diagramme de séquence système de scénario « créer projet »

b. Description de scénario « consulter matériel »

SOMMAIRE DE CONSULTATION MATERIEL ORGANISATION

Titre

Consulter matériel

But

Consultation de la liste des équipements scientifiques propre à une organisation.

Résumé

L’administrateur organisation peut consulter les fiches d’inventaires pour un équipement choisit. Une fiche d’inventaire contient toutes les réservations

ESPRIT

Page 20

Analyse et spécification des besoins

sur un équipement avec les pannes associées à cet équipement s’il existe

Acteur

Administrateur organisation

DESCRIPTION DES ENCHAINEMENTS

Pré conditions

Post conditions

L’administrateur organisation doit s’authentifier Choisir le service de consultation matériel

Choisir une action à faire Opération effectué

Scénario principal

1. L’administrateur organisation choisit le service de consultation de matériel

2. Le système lui retourne la liste des équipements propre à l’organisation

3. L’administrateur organisation choisit de consulter la fiche d’inventaire

4. Le système lui retourne la fiche pour le matériel choisit

Enchainnements alternatifs

E1 : Matériel n’existe pas

1. Le système affiche un message d’erreur

2. L’administrateur corrige les erreurs et valide

Tableau 5 : Description textuelle de cas « consulter matériel »

La figure ci-dessous correspond au diagramme de séquence système de cas d’utilisation gérer matériel scientifique :

de cas d’utilisation gérer matériel scientifique : Figure 8 : Diagramme de séquence système de scénario

Figure 8 : Diagramme de séquence système de scénario « consulter matériel »

ESPRIT

Page 21

Analyse et spécification des besoins

c. Description de scénario créer CV

 

SOMMAIRE CREATION DES CVs

Titre

 

Créer CV

But

 

La création d’un CV

Résumé

Le chercheur peut créer un CV. Un CV peut être publique visible par tout les utilisateurs ou privée.

Acteur

 

Chercheur

 

DESCRIPTION DES ENCHAINEMENTS

 

Pré conditions

 

Post conditions

Le chercheur doit s’authentifier Consulter le service créateur de CV

Choisir une action à faire Opération effectué

 

Scénario principal

 

1. Le chercheur choisit d’afficher la liste de ces CV.

 

2. Le système retourne la liste des CV

 

3. Le chercheur choisit un CV

4. Le système retourne le CV choisit

5. Le chercheur choisit d’ajouter des informations à son CV

6. Vérification système

 

7. Le système met le CV à jour et retourne un message de satisfaction

 

Enchainnements alternatifs

 

E1 :

Champs obligatoires invalides et/ou vides

1. Le système affiche un message d’erreur

 

2. L’utilisateur corrige les erreurs et valide

Tableau 6 : Description textuelle de scénario « créer CV »

ESPRIT

Page 22

Analyse et spécification des besoins

La figure ci-dessous illustre le diagramme de séquence système pour le cas d’utilisation gérer CV :

séquence système pour le cas d’utilisation gérer CV : Figure 9 : Diagramme de séquence système

Figure 9 : Diagramme de séquence système de scénario « créer CV »

d. Description de scénario « consulter projet associé »

SOMMAIRE DE CONSULTATION PORTEFEUILLE

Titre

Consulter projets associés

But

La consultation de ses propres projets

Résumé

Un portefeuille contient tous les projets affectés à un utilisateur. L'utilisateur consulter ces propres projets et ajouter des notifications pour un projet choisit

Acteur

Chercheur

DESCRIPTION DES ENCHAINEMENTS

Pré conditions

Post conditions

L’utilisateur doit s’authentifier Consulter le service portefeuille

Choisir une action à faire

ESPRIT

Page 23

Analyse et spécification des besoins

Opération effectué

Scénario principal

1. L’utilisateur consulte son portefeuille

2. Il choisit d’ajouter une notification

3. Remplir le formulaire

4. Vérification Système

5. Retourner un message de satisfaction

Enchainnements alternatifs

E1 :

Champs obligatoires invalides et/ou vides

1. Le système affiche un message d’erreur

2. L’utilisateur corrige les erreurs et valide

Tableau 7 : Description textuelle de cas d’utilisation « consulter projets associés »

La figure ci-dessous illustre le diagramme de séquence système de cas d’utilisation « consulter portefeuille » :

de cas d’utilisation « consulter portefeuille » : Figure 10 : Diagramme de séquence système de

Figure 10 : Diagramme de séquence système de scénario « consulter portefeuille »

ESPRIT

Page 24

Analyse et spécification des besoins

2.3. Capture des besoins techniques

La capture des besoins techniques concerne les spécifications logicielles et la structure matérielle. Dans cette partie, nous allons décrire le modèle d’architecture adopté pour notre système, tout en présentant nos choix technologiques avec une étude comparative entre quelques technologies.

2.3.1. Modèle d’architecture

L’architecture 3-tiers est un modèle logique d’architecture applicative. Le but de ce modèle est de présenter ce système comme un empilement de trois couches ou niveaux comme l’indique la figure ci-dessous :

couches ou niveaux comme l’indique la figure ci-dessous : Figure 11 : Architecture 3-tiers Les couches

Figure 11 : Architecture 3-tiers

Les couches de ce modèle communiquent entre elles via un modèle d’échange bien définit. En effet, chaque couche propose un ensemble de services rendus, les services d’une couche sont mis à disposition de la couche supérieure. Par conséquent, il est interdit qu’une couche invoque les services d’une couche plus basse que la couche immédiatement inférieure ou plus haute que la couche immédiatement supérieure. Ainsi, chaque niveau communique seulement avec ses voisins immédiats. Chaque couche de ce modèle a un rôle bien précis :

La couche présentation associé au client qui est dit « léger » car il n’est responsable d’aucun traitement à la différence de l’architecture 2-tiers.

La couche de traitement des données, c’est la partie fonctionnelle ou dite « métier» de l’application. Elle contient toutes les règles de gestion et de mise en œuvre. Cette couche est dans des nombreux cas un serveur web muni d’extension applicative.

La couche d’accès aux données lié au serveur base de données (SGBD).

Parmi les avantages de l’architecture 3-tiers on peut citer:

ESPRIT

Page 25

Analyse et spécification des besoins

Allègement du poste de travail client : On parle de « client léger » contrairement aux applications classiques client/serveur.

Prise en charge de l’hétérogénéité des plates-formes (serveurs, clients, langage…).

Amélioration de la sécurité des données : en supprimant la relation directe entre le client et les données.

La modularité : En effet, les modifications dans une application 3-tiers se font couche par couche. On peut donc modifier dans une couche sans toucher aux autres, en particulier la couche présentation (IHM ou interface homme machine) n’est pas intriquée dans le traitement. [3]

2.3.2. Choix technologique

Afin de bien expliquer nos choix technologiques, nous avons recours à une étude comparative entre les technologies qui peuvent être utilisées durant notre projet.

Avant de commencer notre étude comparative, on doit tout d’abord définir un Framework. En effet, un Framework est un ensemble des libraries, chaque librarie est constituée d’un ensemble des classes ou interfaces techniques permettant d’atteindre une fonctionnalité bien définit. En réalité, un Framework est un ensemble d’interfaces à implémenter et des classes à réutiliser.

2.3.2.1. La couche métier

Le tableau ci-dessous contient une comparaison entre EJB3.0 et SPRING [4]

Critère

 

EJB3.0

   

Spring

 

Injection de dépendance

Prise en charge de l’injection des types primitifs via le JNDI

Supporte l’injection de quoi que se soit

Persistence

Par defaut, il utilise le JPA mais il peut utiliser d’autres

Basé sur JDBC, JPA, iBatis et Hibernate.

 

Support

de

JTA

mais

peut

Supporte

JTA,

JDBC

et

Transaction

supporter d’autres basés sur JTA

Hibernate transaction.

 

ESPRIT

Page 26

Analyse et spécification des besoins

XML et annotation

Support de la configuration avec XML et les annotations

 

Présence de stateful session

Support indirect qui dépend de

Gestion des états

beans.

conteneur web Spring met

l’accent sur l’état stateless

 
 

Limité aux intercepteurs

Supporte

AspectJ

et

AOP

AOP

alliance

 

Conteneur

lourd :

Présence

Conteneur léger : Il suffit d’avoir

Conteneur

d’un conteneur d’EJB.

un conteneur de servlet.

 

Tableau 8 : Tableau comparatif SPRING vs EJB3.0

Après cette étude comparative, nous avons choisit le Framework spring pour le

développement de la couche métier car il est le plus adopté pour notre projet. La raison la plus

importante c’est que SPRING est un conterneur léger.

2.3.2.2. La couche présentation

Le tableau ci-dessous présente une étude comparative entre Struts et JSF [5]

Critère

 

Struts

 

JSF

 

Un

seul

évènement

par

Peut avoir

plusieurs

Fléxibilité de contrôleur

requête utilisateur

gestionnaires d’évènements aux

 

seins d’une seule page.

 
 

JSF propose un dispositif de navigation plus flexible que celui de

Navigation

Struts

 

Struts est extensible via la

Dispose d’une fonctionnalité

classe RequestProcessor qui

similaire que struts. De plus il a

Extensibilité

implémente les appels

l’avantage de découpler la phase

nécessaires qux méthodes

de rendement de contrôleur.

surant le cycle de vie d’une

requête.

 
 

-

Par comparaison avec

-

JSF

facilite

la

une application JSF, la configuration est plus complexe.

combinaison

des

GUI’s

Développement

complexe aux seins d’un seul composant.

-

Le

module

de

-

JSF fait partie de J2EE

validation est plus efficace.

donc

il

bénéfice

d’une

spécification standard.

-

Le

développement

ne

ESPRIT

 

Page 27

Analyse et spécification des besoins

nécessite pas d’étendre des classes ou d’implémenter des interfaces spécifiques.

Intégration

JSF n’est pas limité à HTML et http mais aussi d’autre

aussi à d’autre technologies et protocoles.

Tableau 9 : Tableau comparatif entre JSF et STRUTS

Après l’étude faite dans ce tableau comparatif, on peut dégager que JSF nous intéresse

pour développer la couche présentation de notre application.

 

2.3.2.3.

Choix de la solution portail

a.

Jahia : [6]

Jahia est un portail J2EE qui dispose d’une licence collaborative payante. Jahia intègre

l’aspect des modules applicatifs appellés webbapps, qui respectent l’API des portlets sous la

norme JSR 168 (Java specification request : c’est une norme java pour le développement des

portlets). Jahia contient plusieurs webbapps qui sont prête à l’mploi.

Sans oublier que Jahia offre toutes les fonctionnalités classiques de gestion de contenu :

gestion de l’arborécence, des contributions, des workflow, des templates et des droits.

Parmi les points forts de portail Jahia, on peut citer :

L’intégration proprement dite de la notion d’ECM (Entreprise Content Management).

Une ergonomie performante.

Une gestion de workflow, des droits et de personnalisation fines et puissantes

Neau moins Jahia à des inconvénients :

License payante.

Jahia possède une faible communauté : seule la société Jahia développe le projet.

La solution ne gère pas les imports XML ni les métadonnées.

b. Liferay : [6]

Liferay est un portail J2EE à base d’une license libre (open source). Liferay respecte les

principaux standards d’intéropérabilité, ce qui permet un deploiement facile sur diverse

serveurs d’applications et bases de données.

ESPRIT

Page 28

Analyse et spécification des besoins

Liferay fournit des nombreux modules qui sont prêtes à être utilisés : Calendrier, agenda, messagerie instantannée, messagerie, flux RSS, gestionnaire des documents…

Dans ces nouvelles versions, Liferay propose son propre outil de gestion de contenu WCM (Web Content Management) qui est un système de gestion de contenu basé sur le principe de workflow et de versionning.

De même liferay donne la mains aux administrateurs de créer des sous-portail totalement personnalisable. En effet, liferay permet d’avoir plusieurs espaces personnalisables pour plusieurs organisations sur un même serveur. L’authentification entre ces diverses portails s’effectue en SSO (Single Sign On) grâce à l’intégration du connecteur CAS (Central Authentification Service). Différents connecteurs peuvent permettre une synchronisation avec les annuaires LDAP et Exchange ce qui permet une intégration facile de ces dernières. On peut citer parmi les points forts de liferay :

Installation et déploiement facile.

La simplicité d’utilisation des portlets.

Respect des plusieurs standards : JSR 168, 170, Web services …

Outils de gestion de contenu très utile.

Parmi les points faibles de liferay :

Documentation insuffisante pour certaines fonctionnalités.

Après cette étude comparatif entre jahia et liferay, nous avons opté de choisir liferay comme un portail J2EE open source pour développer notre application.

2.4. Capture des besoins non fonctionnels

Chaque système informatique à un certain point dans son cycle de vie, doit considérer des besoins non fonctionnels et leurs tests. Ces besoins demandent plus ou moins de travaille selon le système à mettre en évidence.

Ainsi, notre solution portail devra être sécurisée afin de contrôler l’accès aux différentes ressource. Aussi, les interfaces IHM doivent être conforme à la charte graphique de la société, faciles à utiliser et adaptées aux différents profils des utilisateurs.

ESPRIT

Page 29

Analyse et spécification des besoins

2.4.1. Sécurité

La sécurité en informatique est l’ensemble des techniques à mettre en œuvre dans le but de s’assurer que les ressources du système d’information matériel ou logiciel sont utilisées dans le cadre ou il est prévu qu’elles le soient. Parmi ces techniques on peut citer l’authentification et l’autorisation (ou la disponibilité). Se sont ces deux techniques qui nous intéressent pour la mise en place de notre système.

2.4.1.1. Authentification

L’authentification

est le mécanisme de vérification de l’identité dont une entité

(personne ou machine) se réclame. Elle vise essentiellement à :

Contrôler l’accès à des ressources ou des services d’un système d’information.

Garantir une imputabilité avec vérification de l’identité.

La figure ci-dessous illustre les états constitutifs d’une authentification

3.4.1.1.
3.4.1.1.

Figure 12 : Etats constitutifs d’une authentification

La figure montre que l’authentification tourne autour de quatres états :

Etat initial : Non authentifié, dans ce cas le système doit interdire les actions qui nécessitent une authentification

Phase de connexion : C’est la phase d’ouverture du canal (session). Elle se résume dans le contrôle de l’identité d’un acteur

Etat authentifié : Cet état a une durée bien déterminée, elle constitue la session authentifiée pendant laquelle l’acteur a l’accès aux ressources et aux services. La

ESPRIT

Page 30

Analyse et spécification des besoins

session peut être fermé à la demande de l’utilisateur ou automatiquement par le système après un temps bien déterminé d’inactivité.

Phase de déconnexion : C’est la phase de retour à l’état initial.

Tous les états peuvent potentiellement engendrer une erreur qui peut générer une alarme. [7]

2.4.1.2. Autorisation

L’autorisation est le mécanisme qui définit comment les utilisateurs ont le droit d’accéder à certaines ressources ou services. En effet, la gestion des rôles permet de gérer les autorisations, en spécifiant les ressources auxquelles les utilisateurs peuvent accéder.

Chaque rôle contient un ensemble des règles d’accès ou des permissions qui permettent de préciser quelle sont les droits d’un utilisateur sur un service ou sur des ressources. Ainsi grâce aux rôles, la gestion de droits d’accès se fait indépendamment des utilisateurs. Ainsi, se présente l’objectif de l’utilisation des rôles qui consistent à faciliter la gestion des règles d’accès pour les utilisateurs.[8]

2.4.2. Ergonomie

Parmi les critères de succès d’une application web, se trouve un critère qui ne doit pas êtres négligé, c’est l’ergonomie de l’application. Plusieurs études et enquêtes sont faites concernant ce sujet. On peut citer l’enquête effectuée par « Forrester Research » auprès des utilisateurs web, montre l’importance de ce critère comme l’illustre la figure ci-dessous :[9]

de ce critère comme l’illustre la figure ci-dessous :[9] Figure 13 : Les critères de succès

Figure 13 : Les critères de succès d’un site web selon les utilisateurs

ESPRIT

Page 31

Analyse et spécification des besoins

Pour qu’un site web soit ergonomique, il doit être à la fois utile, c'est-à-dire il répond aux besoins des utilisateurs, et utilisable, c'est-à-dire facile à apprendre et à utiliser. Le critère d’utilité reste le critère le plus fondamental de succès d’un site web. En effet un site qui est utile et qui présente des problèmes sur le plan de son utilisabilité sera comme même utilisé s’il répond d’une façon adéquate et unique aux besoins des utilisateurs.

Sans oublier qu’un site qui est peut utilisable qui présente des lacunes sur le plan de conception (une mauvaise architecture de l’information) ou sur le plan technologique (téléchargement trop long) et dont le contenu n’est pas unique risque trop d’être ignoré par les utilisateurs.

Une démarche ergonomique est basée sur une philosophie de conception qui se concentre essentiellement sur les utilisateurs, les tâches et les besoins. Ce qui implique que la perspective ergonomique doit être integrée dans tous les phases de processus de développement dans le but de garantir l’amélioration d’une façon significative le degré d’utilité et d’utilisabilité de l’application à mettre en œuvre.

Conclusion

Dans ce chapitre, nous avons essayé de faire l’étude fonctionnelle et technique de notre projet afin de déterminer les différents intervenants de l’application ainsi que les services que nous devons fournir. Ainsi, grâce à l’étude technique nous avons reussit à dégager le composant techniques qui vont intervernir dans notre projet. Et enfin nous avons essayés de faire la capture des besoins non fonctionnels de notre projet.

Le chapitre suivant contiendra la phase de conception de notre application. Cette phase se dévise en deux grandes parties : conception préliminaire et conception détaillée.

ESPRIT

Page 32

Conception

Chapitre 3 : Conception

Introduction

A ce niveau, la conception est décomposée essentiellement de deux étapes : la

conception préliminaire qui est la phase de croisement entre la branche fonctionnelle et technique. Elle contient essenetiellement le diagramme de classe d’analyse et le prototype d’interface de notre application, et la conception détaillée qui contient une description des patrons de conception avec une étude statique et dynamique de notre application.

3.1. Conception préliminaire

Un diagramme de classe présente un ensemble des classes et d’interfaces avec leurs relations. Le diagramme de classe peut se présenter dans la phase d’analyse et de conception.

En effet, dans la phase d’analyse, le diagramme de classe met en œuvre seulement les

classes qui servent à décrire les objets de l’application. Or dans la phase de conception, le diagramme de classe contient toutes les classes utiles en terme de dépendance afin d’assurer le fonctionnement de l’application.

3.1.1. Diagramme de classe d’analyse

La figure ci-dessous présente le diagramme de classe d’analyse de notre projet.

le diagramme de classe d’analyse de notre projet. Figure 14 : Diagramme de classe d’analyse E

Figure 14 : Diagramme de classe d’analyse

ESPRIT

Page 33

Conception

Afin de construire le diagramme de classe, nous avons identifié les classes candidates

par cas d’utilisation. Aussi, nous avons procédé par retro-ingénierie pour décrire les classes

« User » et « Organization »

Le tableau ci-dessous présente les classes candidates par cas d’utilisation.

Cas d’utilisation

Classes candidates

 

- User : cette classe est extraite de la base de données Liferay

- Resume : La classe qui contient les CV d’un chercheur

Créer CV

- Diplome : Nécessaire pour la création d’un CV, un CV contient plusieurs diplômes.

- Experience : Un CV contient plusieurs expériences

 

- Project : C’est la classe responsable des projets scientifiques

Créer projet

- Organization : Cette classe est extraite de La base de données de Liferay, une organisation contient plusieurs projets

 

- Equipment : C’est la classe responsable de matériel scientifique

Gérer matériel

- Fournisseur : Un fournisseur peut fournir plusieurs équipements scientifiques

- Panne : Cette classe sert à déclarer une ou plusieurs pannes dans un équipement

Gérer demande

- Demande : La classe « Demande » sert à ajouter des demandes concernant les équipements scientifiques.

matériel

Tableau 10 : Classes candidates par cas d’utilisation

3.1.2. Prototype d’interface

Liferay présente plusieurs modèles d’interfaces prédifinies. De plus, il nous donne la

possibilité pour développer nos propres modèles. Dans notre projet, nous avons choisit le

prototype situé dans la figure ci-dessous pour la plupart de nos interfaces IHM.

ESPRIT

Page 34

Conception

Logo et bannière

20%

Menu 10%

Contenu de page

60%

Pied de page 10%

Figure 15 : Prototype d’interface

La partie menu de l’interface contient le menu relatif à l’utilisateur connecté. Ce menu lui permet d’accéder aux différentes pages dans la partie contenu de page. La disposition de contenu de la page diffère d’un utilisateur à un autre. En outre, Le menu permet à un utilisateur d’accéder à des pages dans le contenu de page.

3.2. Conception détaillée

3.2.1. Les patrons de conceptions

génie logiciel, un patron de conception ou motif de conception est un concept qui

vise à résoudre plusieurs problèmes selon l’approche orienté objet. Un modèle de conception peut être vu comme un document contenant la description de la structure d’un ensemble de

classes permettant de répondre à une situation particulaire.

En

Le but principal des patrons de conception est de minimiser le temps de développement d’un logiciel tout en augmentant la qualité de résultat, notamment en appliquant des solutions et des meilleurs pratiques qui sont déjà existantes à des problèmes courants de conception.

Les motifs de conceptions les plus connus sont au nombre de 23 et ils sont classifiés selon trois grandes familles (Création, Structuration, Comportement). [10]

ESPRIT

Page 35

Conception

Dans cette partie, nou s allons citer et décrire les design patter n que nous allons appliquer durant notre projet.

Singleton :

de conception est de restreindre l’instanciatio n d’une classe à un

seul objet. Il est utile lorsq ue nous avons besoin d’un seul objet po ur coordonner des

opérations dans un système. singleton : [10]

La figure ci-dessous illustre le diagramme d e classe du pattern

L’objectif de ce patron

le diagramme d e classe du pattern L’objectif de ce patron Figure 16 : diagramme de

Figure 16 : diagramme de classe singleton

DAO :

Access Object) est un pattern qui permet de f aire le lient entre la

couche métier contenant les s ervices et la couche persistante. En effet, le p attern DAO permet de centraliser les mécanismes de mapping entre le système de stockage (B ase de données) et

les objets. Ainsi un changem ent d’un système de stockage à un autre e st facile grâce à ce pattern. La figure ci-dessous p résente le diagramme de classe de pattern D AO : [10]

Le pattern DAO (Data

de classe de pattern D AO : [10] Le pattern DAO (Data F igure 17 :

F igure 17 : Diagramme de classe de pattern DAO

ESPRIT

Page 36

Conception

MVC (Model-Vi ew-Controller) :

de l’organisation de

l’interface homme machine (I HM) d’un logiciel. Le principe de ce modèl e de conception est de déviser l’IHM en trois part ies comme l’illustre la figure ci-dessous :

Le modèle vue contrôle ur est un modèle de conception responsable

vue contrôle ur est un modèle de conception responsable Figure 18 : Le pattern MVC En

Figure 18 : Le pattern MVC

En résume, lorsqu’un u tilisateur envoie une requête, elle va être en voyée par la vue et

analysée par le contrôleur. E nsuite, le contrôleur demande au modèle ap proprié d’effectuer l’ensemble des traitements ne cessaires et notifie la vue que la requête est effectuée. Enfin la

La figure ci-dessous

vue notifiée va faire une notifi cation vers le modèle pour se mettre à jour.

illustre les différentes intéract ion entre la vue, le modèle et le contrôleur. [1 0]

ion entre la vue, le modèle et le contrôleur. [1 0] Fig ure 19 : Interaction

Fig ure 19 : Interaction entre les composants de MVC

ESPRIT

Page 37

Conception

Invesion de control (IoC) et injection de dépendance (ID) :

L’inversion de contrôle est un patron de conception commun à tous les Framework. Il garantit que « le flot d’éxécution n’est plus sous le contrôle direct de l’application mais du Framework ou de la couche logicielle sous-jacente ».

En faite, l’inversion de contrôle est un terme générique qui peut être appliqué selon plusieurs formes. Le plus connu de ces formes et ce qui nous interesse le plus est l’injection de dépendances.

L’injection de dépendances (en anglais Dependancy Injection) consiste à la création dynamique ou l’injection des dependances entre les différentes classes en se basant sur une description (fichier de configuration). De ce fait, les dependances seront déterminées dynamiquement à l’exécution sans avoir recours à les declarer statiquement. [10]

3.2.2. Etude statique

Cette partie contiendra une étude concernant la vue statique de notre projet. Elle s’interesse en général à la struture statique du système par l’intermédiaire des objets, des classes, des attributs, des opérations et des relations. Elle inclut le diagramme de package et le diagramme de classe.

3.2.2.1. Diagramme de package

Le digramme de package permet de représenter la dépendance fonctionnelle entre les différents packages du système. La figure ci-dessous illustre le diagramme de package de notre application.

illustre le diagramme de package de notre application. Figure 20 : Diagramme de package E S

Figure 20 : Diagramme de package

ESPRIT

Page 38

Conception

Cette décomposition des paquets est dégagée à partir de modèle de développement en couche proposé par l’architecture 3-tiers. Ainsi, notre application est composée essentiellement de quatre paquets :

Le paquet « persistance » contient les classes qui sont en relation direct avec la base de données, cette relation est gérée par l’API JPA. Hibernate permet de gérer la communication de ce paquet avec la base de données quelque soit le type de cette dernière.

Le paquet « DAO » contient des classes composés des méthodes d’accès à la base de données.

Le troisième paquet est le paquet « service » qui contient les classes des services qui manipulent les méthodes d’accès aux données.

Le dernier paquet « presentation » et le paquet responsable de l’interface graphique. Il importe des éléments du paquet service pour les utiliser dans la vue.

Les autres packages sont des dépendances des Framework utilisés.

3.2.2.2. Diagramme de classe par package

a. Diagramme de classe de package « persistence » :

a. Diagramme de classe de package « persistence » : Figure 21 : Diagramme de classe

Figure 21 : Diagramme de classe de package « persistence»

ESPRIT

Page 39

Conception

Le package « persistence » contient les entités qui sont en relation avec la base de données. Ces entités servent au mapping relationnel-objet.

b. Diagramme de classe de package « service » :

Le paquet Service contient les classes des services offerts par notre application. Ces classes ont besoins des classes du paquet DAO afin d’invoquer les méthodes nécessaires pour l’implémentation des différents services. Ce qui prouve la relation de dépendance entre ces classes. La figure ci-dessous illustre le diagramme de classe de package service.

illustre le diagramme de classe de package service. Figure 22 : Diagramme de classe de package

Figure 22 : Diagramme de classe de package « Service »

ESPRIT

Page 40

Conception

c. Diagramme de classe de package « DAO » :

Le paquet DAO contient les classes d’implémentation des méthodes qui sont responsable de l’accès à la base de données (Les méthodes CRUD). Pour pouvoir implémenter ces méthodes, nous avons recours à une sessionFactory à partir de Hibernate. Ainsi, nous expliquons la dépendance entre les différentes classes de notre paquet DAO et la classe SessionFactory de Hibernate. La figure ci-dessous présente le diagramme de classe de package DAO.

ci-dessous présente le diagramme de classe de package DAO. Figure 23 : Diagramme de classe de

Figure 23 : Diagramme de classe de package « DAO »

ESPRIT

Page 41

Conception

d. Diagramme de classe de package « présentation »

Ce package contient les différents contrôleur dont le rôle est essentiellement l’appelle des méthodes du package service. Pour cela, les contôleurs ont besoins des classes du package service afin d’assurer l’appelle des différentes méthodes. Ainsi nous expliquons la dépendance entre les classes illustré dans la figure ci-dessous :

entre les classes illustré dans la figure ci-dessous : Figure 24 : Diagramme de classe de

Figure 24 : Diagramme de classe de package « présentation »

ESPRIT

Page 42

Conception

3.2.3. Etu de dynamique

La vue dynamique inte rvient après la définition du modèle statiq ue. Elle permet de

représenter le comportement

évidence les relation inter-obj ets.

dynamique du système. En effet cette visi on sert à mettre en

Pour

cela,

le

modèle

d’activités,de collaborations

scénarios de notre système.

dynamique

pourra

inclure

des

diagram mes

sequences,

présenter quelques

de

et d’états. Dans cette section, nous allons

3.2.3.1. Scénario de « création de CV » :

La figure ci-dessous déc rit le diagramme de séquence de création d’u n CV

déc rit le diagramme de séquence de création d’u n CV Figur e 25 : Diagramme

Figur e 25 : Diagramme de séquence de « création de CV »

Le chercheur accède au données sont envoyées vers

vérifier les données : S’ils s ont erronés un message d’erreur va être af fiché au chercheur.

et le remplit. Les

le contrôleur «ResumeBean». Le contrôle ur, va à son tour,

formulaire d’ajout CV « FormulaireCV »

Sinon le contrôleur va assurer l’enregistrement de ce CV dans la table «R esume». Ensuite, le

chercheur va être redirigé

responsable d’ajout des diplô mes et des expériences. Le chercheur saisi les informations de

qui est l’interface

vers

l’interface

« formulaireComplete »

ESPRIT

Page 43

Conception

diplôme et valide, ces informations vont être envoyées au contôleur qui va les vérifier. S’il sont valides il va assurer l’enregistrement du diplôme associé au CV ajouté précédement dans la table diplôme. De même pour l’ajout d’une expérience.

3.2.3.2. Scénario de création de projet

La figure ci-dessous décrit le diagramme de séquence d’ajout d’un projet :

décrit le diagramme de séquence d’ajout d’un projet : Figure 26 : Diagramme de séquence de

Figure 26 : Diagramme de séquence de scénario « création de projet »

Le fonctionnaire choisit d’ajouter un projet, le contrôleur fait une vérification des données si les données sont valides il contacte l’entité « Project » sinon le système affiche un message d’erreur. Si le fonctionnaire choisit d’affecter des chercheurs à un projet, le contrôleur « ProjectBean » lui retourne la liste des utilisateurs par organisation. Ainsi, il peut associer des chercheurs. Ces projets qui sont ajoutés de la part du fonctionnaire sont par défaut à l’état non publié. C’est l’administrateur organisation qui choisit de les publier ou non. Si un projet passe à l’état publié, l’administrateur organisation peut dans ce cas ajouter les résultats atteintes par ce projet.

ESPRIT

Page 44

Conception

Pour mieux comprendre les états d’un projet nous avons fait un diagramme d’état transision pour ce scénario qui est présenté dans la figure ci-dessous

ce scénario qui est présenté dans la figure ci-dessous Figure 27 : diagramme d’état transition scénario

Figure 27 : diagramme d’état transition scénario création projet

3.2.3.3. Scénario de consultation des projets associés :

La figure ci-dessous illustre le diagramme de séquence de consultation des projets associés (portefeuille) et d’ajout d’une notification à un projet :

et d’ajout d’une notification à un projet : Figure 28 : Diagramme de séquence « consulter

Figure 28 : Diagramme de séquence « consulter portefeuille »

ESPRIT

Page 45

Conception

Le chercheur consulte l’interface « InterfaceProfil » pour afficher ces propres projets, le contrôleur envoie l’identifiant de l’utilisateur vers l’entité « Project » afin de retourner la liste des projets appropriés. Puis, il retourne le résultat vers le chercheur. Le chercheur choisit un projet parmi la liste et consulte l’interface d’ajout notification « FormulaireNotification » remplit le formulaire et valide. Les données sont envoyées par l’interface vers le contrôleur « NotificationBean », ensuite ce dernier contacte l’entité « Notification » afin d’enregistrer la notification.

3.2.3.4. Diagramme d’activité scénario réserver matériel :

La figure ci-dessous montre le diagramme d’activité de scénario résarvation matériel

diagramme d’activité de scénario résarvation matériel Figure 29 : Diagramme d’activité scénario « réserver

Figure 29 : Diagramme d’activité scénario « réserver matériel »

Le fonctionnaire choisit un équipement parmi la liste, ensuite, il peut réserver un matériel pour un projet. Le contrôleur « ReservationBean » va effectuer une vérification de disponibilité sur l’équipement choisit de point de vue date et stock. Si l’équipement est disponible, alors le contrôleur contacte l’entité « Reservation » pour effectuer l’opération. Sinon, le fonctionnaire peut faire une sur un équipement.

ESPRIT

Page 46

Conception

Conclusion

Dans le but d’avoir une image prête à fabriquer de notre système, nous avons essayés dans ce chapitre tout d’abord de produir le modèle de conception système afin d’organiser notre application en composants. Ensuite, nous avons essayés de décrire comment réaliser chaqu’un de ces composants.

Il nous reste maintenant d’expliquer comment nous avons réalisés notre système, ceci est l’objectif de chapitre suivant.

ESPRIT

Page 47

Réalisation

Chapitre 4 : Réalisation

Introduction

Nous terminerons notre rapport par le chapitre réalisation qui a pour objectif de décrire comment nous avons réalisés notre projet et d’exposer le travail achevés. Pour cela, nous commencerons par une étude sur le l’environnement de travail. Ensuite nous citerons les étapes de mise en œuvre de notre application, puis nous allons faire des captures d’écrans pour quelques scénarios des services offerts par notre application.

Après, on va évaluer notre application selon les fonctionnalités attendues et les besoins non fonctionnels qui ont été cités dans le chapitre analyse et spécification des besoins. Enfin, nous citerons les problèmes que nous avons rencontrés tout le long de notre projet.

4.1. Environnement de travail

4.1.1. Environnement logiciel

4.1.1.1. IDE : Eclipse JEE Helios

Eclipse est un environnement de développement integré libre extensible et polyvalant qui permet la création des projets avec n’importe quel language. L’architecture d’eclipse et totalement fondu sur la notion de plugin : c'est-à-dire que toutes les fonctionnalités de cet atelier logiciel sont développées en tant que plugin.

La version que nous avons utilisée (Java EE Helios), c’est une version d’eclipse permettant la création des projets Java EE et des applications web.

4.1.1.2. Liferay IDE et Liferay plugin SDK

Liferay IDE est une extension pour la plateforme eclipse qui supporte le développement des plugin pour le portail Liferay. Cette extension est disponible sous forme des plugins installable à partir d’un entrepôt de mise à jour. Liferay IDE nécessite l’utilisation d’un plugin SDK de liferay qui est un environnement de développement et de deploiement des plugins pour liferay. Il existe quatre types de plugins liferay :

Les portlets : En général, une protlet est un composant web qui peut s’intégrer dans un conteneur de portlet (portail). Chaque portlet peut être considérée comme une

ESPRIT

Page 48

Réalisation

application web appart. Les portlets se basent sur un API définie selon la spécification JSR 168 supporté par le portail Liferay. Liferay contient plusieurs portlets prédéfinis prêtes à être utilisées. Les Hooks : Un hook est une action qui peut être exécutée après un événement bien précis. Liferay donne la possibilité de développer des Hooks de plusieurs types par exemple : Hook avant ou après authentification, un événement après l’exécution d’un service… Les thèmes : Liferay donne la possibilité de création des thèmes qui permettent de contrôler l’interface IHM vues par l’utilisateur. De ce fait, l’interface de portail peut être complètement personnalisée. Aussi, liferay permet à chaque organisation d’avoir son propre thème personnalisé. Layout templates : Liferay permet de développer des plugins qui permettent de contrôler la disposition de la page. Sans oublier qu’il fournit des layouts par défaut qui peuvent être utilisés. [11]

4.1.1.3. Apache Ant

Ant est un projet open source de la fondation apache ecrit en java. Ant est l’abréviation de « Another Neat Tool » en français « un autre chouette outil ». Ant est essentiellement utilisé pour L’automatisation des opérations répététives au cours de développement (nétoyage de projet, compilation, génération de la documentation, versionning, test, deploiement

…).[13]

4.1.1.4. Outil de test unitaire :JUnit

Dans la vie d’un logiciel, les tests unitaires interviennent dans deux périodes : d’une part, tout le long de construction des fonctionnalités de l’application et d’autre part l’or de l’ajout d’un service. Parmi les outils de test unitaires, on trouve le framework libre JUnit qui permet d’écrire et d’éxécuter des tests en langage java facilement. [17]

4.1.1.5. StarUML

StarUML est un logiciel de modélisation UML qui est devenu open source après son exploitation commertiale sous une license modifié de GNU GPL. StarUML permet de créer la plupart de diagramme UML 2.0 et propose plusieurs générateurs de codes. Il est ecrit en Delphi, pour cela, il dépend des composants Delphi propriétaires, ce qui explique peut être qu’il n’est plus mis à jour. [18]

ESPRIT

Page 49

Réalisation

4.1.1.6. MySQL 5.0

MySQL est un système de gestion de base de données qui a une licence libre qui peut être propriétaire selon le type de l’application. Il est parmi les logiciels de gestion de base de données le plus utilisés au monde autant par le grand public à travers les applications web principalement que par de professionnels.

MySQL est un serveur de base de données relationnelles SQL multi-thread et multi- utilisateur développé afin d’augmenter la performance de lecture des données. Ainsi il est orienté vers le service de données déjà en place que vers celui de mise à jour fréquentes et sécurisées. [16]

4.1.2. Environnement technologique

4.1.2.1. Framework SPRING

Spring est une plate-forme java qui fournit une infrastruture complète pour développer des applications java. Spring est totalement un conteneur dit «léger». Il prend en charge la création et la mise en relation des objets avec un fichier de configuration qui contient simplement la description des objets à fabriquer.

L’avantage le plus important par rapport aux serveurs d’applications est qu’avec Spring les classes de l’application n’ont pas besoin d’implémenter une interface quelconque pour être pris en charge par le Framework. C’est pour cela que Spring est qualifié de conteneur « léger». Aussi, Spring propose tout un ensemble d’abstraction permettant de gérer :

Le mode transactionnel. L’appel des EJBs. La création des EJBs. La persistance des objets. La création d’une interface web. L’appel et la création de web services. [19]

4.1.2.2. Hibernate

Hibernate est un Framework libre permettant de gérer la persistance des objets en base de données relationnelle. Il est un Framework adaptable qui peut être utilisé aussi bien dans

ESPRIT

Page 50

Réalisation

un développement client lourd, que dans un environnement web léger. Hibernate peut être utilisé pour créer la couche d’accès aux données (DAO) ainsi que pour gérer la persistance des objets. [15]

4.1.2.3. JPA

Java Persistence API (JPA) est un Framework qui permet aux développeurs d’organiser les données relationnelles dans les applications utilisant la plateforme java. JPA est issue de travail du groupe d’expert dans la spécification JSR 220. La persistance dans le contexte de JPA tourne autour de trois zones :

L’API elle-même, définie dans le package javax.persistence. Le langage Java Persistence JQuery (JPQL). Le/les objet(s) métadonnées relationnelles. [14]

4.1.2.4. Java Server Faces

Java Server Faces (JSF) est un Framework java ayant pour objectif le développement des applications web. JSF est un Framework MVC basé sur la notion des composants, c'est-à- dire que l’état d’un composant est enregistré lors de rendu de la page, pour être ensuite restauré au retour de la requête. Il est constitué essentiellement de :

Un ensemble d’APIs pour la représentation et la gestion des composants, de leurs états, des événements, de la validation des entrées, la conversion des sorties et l’internationalisation et l’accessibilité ainsi que la navigation entre les vues.

Deux jeux de composants standards HTML et Core.

Deux bibliothèques de balises JSP pour la construction de vues JSF.

Un modèle événementiel coté serveur.

Les Managed-Beans qui présentent la couche de contrôle de JSF.

Langage d’expression Unifié (EL) qui sert à la liaison entre la vue et les managed- beans.

Il existe plusieurs composants additionnels qui peuvent être utilisés avec JSF on peut citer JBOSS Richfaces et Ajax4JSF qui sont composés d’un ensemble de composants riches libre et supportant Ajax. [12]

ESPRIT

Page 51

Réalisation

4.2. Etapes de mise en œuvre

La mise en œuvre de notre application tourne autour des phases que nous allons citer dans cette partie.

1. Configuration Liferay:

Cette phase concerne la configuration et la préparation de l’environnement de travail. Durant cette étape, nous avons integré la base de données de Liferay dans MySQL.Ensuite, nous avons configuré Liferay pour travailler avec MySQL par l’intermédiaire de fichiers « properties ». Après nous avons installés Lieray IDE à partir de l’entrepôt de mise à jour de la version Eclipse Helios. Et enfin, nous avons integré le plugin SDK de Liferay dans eclipse.

2. Configuration Spring :

Cette étape consiste à préparer le fichier de configuration SPRING nommé fichier de contexte, c’est le fichier qui est responsable de la configuration de l’injection de dépendance.

Nous avons choisit de travailler avec les annotations SPRING. Dans ce cas, Le fichier de contexte va contenir seulement les informations de la base de données Liferay (chemin, pilote, nom utilisateur, mot de passe…), le nom des entités qui vont être persistés dans la base et la declaration de gestionnaire des transactions responsable de l’injections des instances.

3. Développement de la couche métier :

Durant cette étape nous avons développés les packages de la couche métier : En premier lieu, nous avons commencé par la couche persistante, c'est-à-dire les entités et les rélations entre eux, nous avons utilisés pour cela JPA comme nous l’avons indiqués précedement.

Ensuite nous avons développés les interfaces et les classes d’implémentations de la couche DAO et service afin de mettre en œuvre les services de notre application.

4. Développement de la couche présentation :

C’est l’étape de préparation des contrôleurs (Le modèle MVC) et les interfaces IHM. Les interfaces IHM. Nous avons utilisés les composant « richfaces » et « Ajax4JSF » avec JSF afin d’avoir des inerfaces riches. Les contrôleurs sont des classes Java qui invoquent les services pour assurer la communication entre le modèle et la vue (IHM).

5. Intégration :

ESPRIT

Page 52

Réalisation

C’est durant cette phase que nous avons integrés notre projets dans liferay. Pour cela, nous avons configurés nos portlets selon la spécification JSR168 et les règles de Liferay.Ceci est assuré grâce aux fichiers de configuration que propose Liferay pour le développement des plugins de type portlet.

6. Développement d’un HooK :

Durant notre projet, nous avons eu recourt à developper un HOOK qui permet de faire la redirection d’un utilisateur vers sa propre organisation. Ce Hook se présente comme une action qui s’éxécute après l’authentification de l’utilisateur.

7. Développement d’un thème :

Après l’intégration du projet dans liferay, nous avons développé un thème selon la spécification des thèmes de Liferay (velocity).

8. Deploiement des plugins avec ANT :

Nous avons utilisés dans cette phase le plugin de ANT présent dans Eclipse et le plugin SDK de liferay pour le deploiement des différents plugins développés dans les étapes précédentes.

4.3. Vue de l’interface du portail

4.3.1. Gestion organisation

La gestion des organisations est un prédéfinie dans Liferay. En effet, Liferay nous offre la possibilité d’avoir plusieurs organisations complètement personnalisables. Les organisations sont ajoutées par le super administrateur. Ensuite, chaque organisation peut être administrée par l’administrateur qui lui appartient.

L’administrateur organisation peut créer les pages de son organisation avec des permissions, choisir un thème pour son organisation, il peut même affecter des utilisateurs.

La

figure

organisation :

ESPRIT

ci-dessous

présente

le

panneau

Page 53

de

commande

d’administration

d’une

Réalisation

Réalisation Figure 30 : Panneau de commande de gestion des organisations 4.3.2. Scénario de création d’un

Figure 30 : Panneau de commande de gestion des organisations

4.3.2. Scénario de création d’un projet

A partir de formulaire ci-dessous, le fonctionnaire peut ajouter un projet. Par defaut, le projet crée est à l’état non publié. Le fonctionnaire peut aussi à partir de cet interface, accéder aux formulaires d’affectation des équipement et des chercheurs.

d’affectation des équipement et des chercheurs. Figure 31 : Formulaire d’ajout du projet E S P

Figure 31 : Formulaire d’ajout du projet

ESPRIT

Page 54

Réalisation

La figure ci-dessous illustre l’interface d’administration des projets. A partir de cet interface, l’administrateur organisation peut visualiser toutes les informations concernant le projet et de choisir de le valider ou non.

concernant le projet et de choisir de le valider ou non. Figure 32 : Administration des

Figure 32 : Administration des projets

4.3.3. Espace de profil scientifique

Cette espace permet à un chercheur d’ajouter ou de visiter un CV ainsi de voir et d’ajouter des notifications pour les projets qui lui sont associés. La figure ci-dessous illustre l’espace de créateur de CV.

ESPRIT

Page 55

Réalisation

Réalisation Figure 33 : Créateur des CV La figure suivante, présente un projet de portefeuille d’un

Figure 33 : Créateur des CV

La figure suivante, présente un projet de portefeuille d’un chercheur :

présente un projet de portefeuille d’un chercheur : Figure 34 : Portefeuille des projets associés à

Figure 34 : Portefeuille des projets associés à un chercheur

ESPRIT

Page 56

Réalisation

4.3.4. Espace d’administration des équipements scientifiques

L’administrateur organisation peut avec l’interface illustrée dans la figure ci-dessous afficher l’inventaire concernant un équipement choisit. L’inventaire contient les information sur le fournissseur de ce matériel, ainsi que la liste réservations récentes et la liste des pannes declarés.

réservations récentes et la liste des pannes declarés. Figure 35 : Inventaire d’un équipement Les réservations

Figure 35 : Inventaire d’un équipement

Les réservations des équipements scientifiques sont faites par le fonctionnaire qui peut après la création d’un projet réserver des équipements propres à son organisation. Notons bien que le stock est géré automatiquement et que l’ajout d’une réservation ne sera validé que lorsque le système vérifie la disponibilité de l’équipement. La figure ci-dessous illustre l’interface d’ajout des réservations :

ESPRIT

Page 57

Réalisation

Réalisation Figure 36 : Interface réservation équipements 4.4. Evaluation Cette partie contiendra une évaluation de

Figure 36 : Interface réservation équipements

4.4. Evaluation

Cette partie contiendra une évaluation de notre application selon les besoins non fonctionnels et les fonctionnalités attendues décritent dans le chapitre d’analyse et spécification des besoins.

4.4.1. Sécurité

Pour assurer la sécurité à notre portail, nous avons utilisés le plugin de l’authentification et de gestion des utilisateurs de Liferay. En effet, un utilisateur qui veut accéder au back- office de portail, il doit avoir un compte dans liferay avec un rôle qui groupe un ensemble des droits d’accès.

Ainsi, l’espace d’administration de portail ne peut être accessible que par des utilisateurs qui sont authenetifiés et qui ont des droits d’accès sur les applications présentes dans cet espace. La figure ci-dessous présente le panneau de commande de gestion des utilisateurs dans Liferay :

ESPRIT

Page 58

Réalisation

Réalisation Figure 37 : Panneau de commande gestion des utilisateurs 4.4.2. Ergonomie Parmi les étapes de

Figure 37 : Panneau de commande gestion des utilisateurs

4.4.2. Ergonomie

Parmi les étapes de mise en œuvre de notre projet, nous avons essayé de développer un thème selon la spécification de Liferay pour pouvoir garantir l’ergonomie à notre portail. De même, nous avons utilisé les layouts pré-installés dans Liferay dans le but d’avoir des interfaces ordonnées et faciles à utiliser. Notons bien qu’avec liferay chaque organisation peut avoir son propre thème.

4.4.3. Tests unitaires

Afin de s’assurer qu nos services fonctionnent correctement, nous avons utilisés JUnit pour effectuer nos tests unitaires. En effet chaque service achevé est testé avant d’être invoqué à partir de la couche présentation. Les services que nous avons assurés tournent autour de trois modules :

La gestion des profiles scientifiques (Création des CV, portefeuille de projet).

La gestion des projets à base d’un workflow de validation.

La gestion de matériel scientifique (Réservation, inventaires, déclaration des pannes).

ESPRIT

Page 59

Réalisation

4.5. Problèmes rencontrés

Durant la réalisation de notre projet, et comme les pluparts des projets, nous avons rencontré quelques problèmes :

Problème lors de capture de la phase d’analyse : Durant cette phase, il n’avait pas un cahier des charges bien définis. Pour cela, nous avons étudiés le SI existant afin de bien dégager les besoins fonctionnels et techniques.

Problème des ressources matérielles : Les ordinateurs mis à notre disposition, ont une performance moyenne, ceci constitue une contrainte pour le déploiement et l’exécution de Liferay.

Conclusion

Au cours de ce chapitre nous avons présenté l’ensemble des étapes de mise en œuvre de la solution portail ainsi que quelques captures d’écrans IHM. Ensuite, nous avons effectué une évaluation de notre solution et ce en se basant sur les besoins fonctionnels et non fonctionnels.

ESPRIT

Page 60

Conclusion générale

Conclusion générale

L’objectif de ce projet de fin d’études consiste à la conception et la réalisation d’un portail pour la recherche scientifique agricole.

Afin d’atteindre cet objectif, nous avons fait une étude des besoins fonctionnels et techniques. Ainsi nous avons pu dégager l’architecture de notre application, les outils nécessaires pour la réalisation et la mise en œuvre.

Au

cours

de

ce

projet,

nous

compréhension du contexte.

avons

rencontré

plusieurs

problèmes

liés

à

la

Sans doute, cette expérience nous a été bel et bien fructueuse sur plusieurs plans. D’une part, nous avons pu activement contribuer à l’activité de développement au sein de fournisseur des services informatiques à l’IRESA. D’autre part, elle nous a permis d’appliquer et de consolider nos connaissances acquises durant nos années d’études. De plus, nous avons pu nous familiariser avec plusieurs nouvelles technologies et approches, essentiellement, Les portlets, Les portail web, SPRING, JSF-RichFaces

Enfin, à travers ce projet, nous avons eu la chance d’améliorer nos aptitudes à communiquer et à travailler en collaboration ce qui nous aidera, sans doute, à bien nous intégrer dans le milieu professionnel.

Les perspectives pour ce projet sont diverses. En effet, nous projetons de mettre en place un portail qui engloberait toutes les applications de FSI avec un réseau social professionnel.

ESPRIT

Page 61

Références

Références

Neto graphie

[1] : http://iresa.agrinet.tn/index.jsp?pg=02&rub=01

[2] : http://www.freewebs.com/fresma/Formation/UML/Processus%20Unifie.pdf

[3] : http://fr.wikipedia.org/wiki/Architecture_trois_tiers

[5] : http://soaj2ee.blogspirit.com/archive/2005/05/18/comparatif_jsf_struts.html

[6] : Core-Techs, Livre Blanc de 11 solutions de gestion de la connaissance.pdf

[7]:http://www.ssi.gouv.fr/archive/fr/politique_produit/catalogue/pdf/authentification_robuste

sse_standard_v0-13.pdf

[8] : http://msdn.microsoft.com/fr-fr/library/5k850zwb%28v=vs.80%29.aspx

[9] : http://www.crim.ca/fr/r-d/documents/GuideErgonomique.pdf

[10] : http://fr.wikipedia.org/wiki/Patron_de_conception

[12] : http://fr.wikipedia.org/wiki/JavaServer_Faces#Constituants_de_JSF

[13] : http://fr.wikipedia.org/wiki/Apache_Ant

[14] : http://fr.wikipedia.org/wiki/Java_Persistence_API

[15] : http://fr.wikipedia.org/wiki/Hibernate

[16] : http://fr.wikipedia.org/wiki/MySQL

[17] : http://www.iut-orsay.fr/dptinfo/Pedagogie/Roger.Astier/app_java/javaTest.html

[18] : http://fr.wikipedia.org/wiki/StarUML

[19] : http://fr.wikipedia.org/wiki/Spring_framework

Bibliographie

[4] : Priya Thinagar, EJB3.0 vs Spring

[11] : Connor McKay, Jorge Ferrer Development Documentation

ESPRIT

Page 62

Références

Livre blanc, le portail d’intégration lifray version 1.0.

Arnaud Cogoluègnes,Thierry Templier,Julien Dubois, Jean-Philippe Retaillé, Spring par la pratique 2 ème édition.

Lotfi Mellouk Développer des applications RIA avec richfaces.

ESPRIT

Page 63