Sommaire

Table des matières
Sommaire
Introduction générale ......................................................................................................... 6 Chapitre 1 : Présentation du cadre de projet .................................................................. 7 Introduction ......................................................................................................................... 7
1.1. 1.2. 1.3. 1.4. Présentation de l’organisme d’accueil ............................................................................. 7 Etude de l’existant ........................................................................................................... 8 Solution proposée .......................................................................................................... 10 Démarche méthodologique ............................................................................................ 10

Conclusion ......................................................................................................................... 14 Chapitre 2 : Analyse et spécification des besoins .......................................................... 15 Introduction ....................................................................................................................... 15
2.1. 2.2. 2.3. 2.4. Etude préliminaire ......................................................................................................... 15 Capture des besoins fonctionnels .................................................................................. 16 Capture des besoins techniques ..................................................................................... 25 Capture des besoins non fonctionnels ........................................................................... 29

Conclusion ......................................................................................................................... 32 Chapitre 3 : Conception ................................................................................................... 33 Introduction ....................................................................................................................... 33
3.1. 3.2. Conception préliminaire ................................................................................................ 33 Conception détaillée ...................................................................................................... 35

Conclusion ......................................................................................................................... 47 Chapitre 4 : Réalisation ................................................................................................... 48 Introduction ....................................................................................................................... 48
4.1. 4.2. 4.3. Environnement de travail .............................................................................................. 48 Etapes de mise en œuvre ............................................................................................... 52 Vue de l’interface du portail .......................................................................................... 53

ESPRIT

Page 1

Sommaire
4.4. 4.5. Evaluation ...................................................................................................................... 58 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 9072 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

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 projet actuelle pour gérer ces établissements avec leurs projets est une application nommée « NAIS » (National Agricultural Information System) qui est une application web basé sur le basée principe de système de gestion de contenu (CMS). L’application « NAIS » est composée de deux parties : Une partie privée : P Permettant aux administrateurs, après l’authen l’authentification et avec des droits d’accès bien précis, de gérer le contenu (les publications, les projets de recherche, les établissements…). L’administration se fait selon un processus d’affaire, en effet, chaque publication ou projet ajouté ne sera pas directement publié qu’après directement une validation. Une partie publique : qui permet aux visiteurs de consulter les publications et les informations sur les projets. La figure ci-dessous présente l’arc dessous l’architecture de l’application NAIS:

Administrateur

Front office

Back office

Visiteurs

Entrepôt de données

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

1.2.2. Critique de l’existant
La solution actuelle présente plusieurs limites qu’on va citer: Absence d’un espace réservé aux chercheurs : Cette solution ne permet pas à un chercheur d’avoir son propre compte pour enrichir son profil scientifique (Création d’un CV, choix des catégories, portefeuille des projets, compétences) et suivre les projets qui lui sont associés. ui

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 projets : Résultat de projet, Etat de projet, avancement des projets. 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 Cascade Description Points forts Points faibles

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. - Itératif. -couteux à RUP (Rational -Elaboré par rational. personnaliser : Unified Process) -Le RUP est à la fois une -Intéragir les différents Batterie de méthodologie et un outil intervenant du projet (Les consultants. prêt à l’emploi livrable, les plannings, les prototypes …) -Peu de place pour le -Cible de projet : Plus de développement et la 10 personnes. -propose des modèles de technologie. documents pour des projets type. -Assez flou dans sa XP (eXtreme -Ensemble des bonnes -Itératif pratiques de mise en œuvre Programming) développement (Travail -Donne une importance en équipe, transfert de aux aspects techniques : -Ne couvre pas les compétence …). Règles de développement. phases en amont et en aval au -Cible : Moins de 10 -Innovant : développement : personnes. Programmation en duo Capture des besoins, maintenance … -Plutôt superficiel -Propose un cycle de -Itératif 2TUP(Two sur les phases développement en Y. Truck Unified -Fait un large place à la situées en amont et aval du -Cible des projets de technologie et à la en Process) développement : toutes tailles gestion des risques. capture des besoins, support, maintenance, -Définit les profils des gestion du intervenants, les changement…

livrables, les plannings,

ESPRIT

Page 11

Présentation du cadre de projet les prototypes
-Ne propose pas de documents types

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

La figure ci-dessous montre une projection de ces méthodologies sur les différentes phases dans un projet.

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 :

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.

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 Administrateur Description 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. Pour chaque organisation, il y à un administrateur qui peut gérer son contenu (projet, matériel, publications) et personnaliser son affichage. Appartient à une organisation et bénéfice des services d’ajout de contenu (projet, publications). Les chercheurs appartiennent aux organisations et peuvent bénéficier des services de collaboration et de suivi des projets.
Tableau 2 : Description des acteurs

Administrateur organisation

Fonctionnaire

Chercheur

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 Gérer organisation Gérer utilisateur et rôle

Administrateur

ESPRIT

Page 16

Analyse et spécification des besoins

Gérer les publications Gérer les projets Administrateur organisation Créer projet Gérer matériel organisation Gérer demandes matériels Gérer publications Fonctionnaire Créer projet Affecter chercheur Affecter matériel Suivi projet Déposer document Chercheur Créer CV Réserver matériel Signaler panne matériel Consulter projets associés
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

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 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 Résumé 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 L’administrateur organisation ainsi que fonctionnaire doivent s’authentifier Choisir le service gestion des projets Pour l’ajout d’un projet au moins un chercheur doit être affecté. Scénario principal Choisir une action à faire Opération effectué Le projet ajouté est par défaut non publié Post conditions

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 »

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 Consultation de la liste des équipements scientifiques propre à une organisation. L’administrateur organisation peut consulter les fiches d’inventaires pour un équipement choisit. Une fiche d’inventaire contient toutes les réservations

But

Résumé

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 L’administrateur s’authentifier Choisir le service de consultation matériel Scénario principal organisation doit Post conditions Choisir une action à faire Opération effectué

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 :

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 But Créer CV La création d’un CV Le chercheur peut créer un CV. Un CV peut être publique visible par tout les utilisateurs ou privée. Chercheur DESCRIPTION DES ENCHAINEMENTS Pré conditions Le chercheur doit s’authentifier Consulter le service créateur de CV Post conditions Choisir une action à faire Opération effectué Scénario principal

Résumé

Acteur

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 :

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 But Consulter projets associés La consultation de ses propres projets Un portefeuille contient tous les projets affectés à un utilisateur. Résumé L'utilisateur consulter ces propres projets et ajouter des notifications pour un projet choisit Acteur Chercheur DESCRIPTION DES ENCHAINEMENTS Pré conditions L’utilisateur doit s’authentifier Consulter le service portefeuille Post conditions

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 » :

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 :

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

Prise en charge de l’injection Supporte l’injection de quoi que Injection de dépendance des types primitifs via le se soit JNDI Persistence Par defaut, il utilise le JPA Basé sur JDBC, JPA, iBatis et mais il peut utiliser d’autres Hibernate. JTA, JDBC et

Support de JTA mais peut Supporte Transaction

supporter d’autres basés sur Hibernate transaction. JTA

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 AOP Limité aux intercepteurs Supporte alliance Conteneur lourd : Présence Conteneur léger : Il suffit d’avoir Conteneur d’un conteneur d’EJB. un conteneur de servlet. AspectJ et AOP

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 Un Fléxibilité de contrôleur seul Struts évènement par Peut avoir JSF plusieurs

requête utilisateur

gestionnaires d’évènements aux seins d’une seule page.

Navigation

JSF propose un dispositif de navigation plus flexible que celui de Struts Struts est extensible via la Dispose d’une fonctionnalité

classe RequestProcessor qui similaire que struts. De plus il a Extensibilité implémente nécessaires les qux appels l’avantage de découpler la phase méthodes de rendement de contrôleur.

surant le cycle de vie d’une requête. - Par comparaison avec une application JSF, la configuration est plus complexe. - Le module de validation est plus efficace. - JSF facilite la combinaison des GUI’s complexe aux seins d’un seul composant. - JSF fait partie de J2EE donc il bénéfice d’une spécification standard. - Le développement ne

Développement

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.

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]

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.

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 Créer projet Classes candidates User : cette classe est extraite de la base de données Liferay Resume : La classe qui contient les CV d’un chercheur 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 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 Fournisseur : Un fournisseur peut fournir plusieurs équipements scientifiques Panne : Cette classe sert à déclarer une ou plusieurs pannes dans un équipement Demande : La classe « Demande » sert à ajouter des demandes concernant les équipements scientifiques.

Créer CV

Gérer matériel Gérer demande 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
En 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. 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, nous allons citer et décrire les design pattern que nous allons crire appliquer durant notre projet. Singleton : L’objectif de ce patron de conception est de restreindre l’instanciation d’une classe à un seul objet. Il est utile lorsque nous avons besoin d’un seul objet pour coordonner des opérations dans un système. La figure ci dessous illustre le diagramme de c ci-dessous classe du pattern singleton : [10]

Figure 16 : diagramme de classe singleton

DAO : Le pattern DAO (Data Access Object) est un pattern qui permet de f faire le lient entre la couche métier contenant les services et la couche persistante. En effet, le pattern DAO permet tier de centraliser les mécanismes de mapping entre le système de stockage (Base de données) et les objets. Ainsi un changement d’un système de stockage à un autre est facile grâce à ce pattern. La figure ci-dessous présente le diagramme de classe de pattern DAO : [10] DAO

Figure 17 : Diagramme de classe de pattern DAO

ESPRIT

Page 36

Conception MVC (Model-View View-Controller) : Le modèle vue contrôleur est un modèle de conception responsable de l’organisation de l’interface homme machine (IHM) d’un logiciel. Le principe de ce modèle de conception est de déviser l’IHM en trois parties comme l’illustre la figure ci ci-dessous :

Figure 18 : Le pattern MVC

En résume, lorsqu’un utilisateur envoie une requête, elle va être envoyée par la vue et analysée par le contrôleur. Ensuite, le contrôleur demande au modèle approprié d’effectuer l’ensemble des traitements necessaires et notifie la vue que la requête est effectuée. Enfin la vue notifiée va faire une notification vers le modèle pour se mettre à jour. La figure ci ci-dessous illustre les différentes intéraction entre la vue, le modèle et le contrôleur. [10] raction

Figure 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.

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 » :

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.

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.

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 :

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

ESPRIT

Page 42

Conception

3.2.3. Etude dynamique
La vue dynamique intervient après la définition du modèle statique. Elle permet de représenter le comportement dynamique du système. En effet cette vision sert à mettre en évidence les relation inter-objets. objets. Pour cela, le modèle dynamique pourra inclure des diagrammes de sequences, d’activités,de collaborations et d’état Dans cette section, nous allons prés d’états. présenter quelques scénarios de notre système. 3.2.3.1. Scénario de « création de CV » : La figure ci-dessous décrit le diagramme de séquence de création d’un CV dessous diagramme

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

Le chercheur accède au formulaire d’ajout CV « FormulaireCV » et le re remplit. Les données sont envoyées vers le contrôleur « «ResumeBean». Le contrôleur, va à son tour, ». vérifier les données : S’ils sont erronés un message d’erreur va être affiché au chercheur. Sinon le contrôleur va assurer l’enregistrement de ce CV dans la table «Resume». Ensuite, le chercheur va être redirigé vers l’interface « formulaireComplete » qui est l’interface responsable d’ajout des diplômes et des expériences. Le chercheur saisi les informations de .

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 :

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

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 :

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

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 multiutilisateur 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 managedbeans. 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 ci-dessous présente le panneau de commande d’administration d’une organisation :

ESPRIT

Page 53

Réalisation

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.

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.

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

Figure 33 : Créateur des CV

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

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.

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

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 backoffice 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

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 avons rencontré plusieurs problèmes liés à la compréhension du contexte. 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

Sign up to vote on this title
UsefulNot useful