P. 1
Rapport GesFormJ2ee

Rapport GesFormJ2ee

|Views: 942|Likes:
Published by ymas00
Gestion de formation en JEE
Gestion de formation en JEE

More info:

Published by: ymas00 on Jan 06, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/14/2014

pdf

text

original

Projet de Fin d’Etudes

Pour l’Obtention du Titre

d’Ingénieur d’Etat en Informatique
Option : Génie logiciel

Sujet

Etude et mise en œuvre d’une solution pour la gestion de la formation en intranet à base des frameworks J2EE

Réalisé par : M. Abdellah SKAL M. Omar BEL LAKHDAR

Sous la direction de : Mme. Bouchra BERRADA M. Youssef EL MAZOURI M. Mourad ZEKRAOUI

Année Universitaire 2003/2004

Dédicace

A mes très chers parents, Aucun terme et aucune langue ne pourra exprimer mon amour et mes sentiments envers vous. A mes chères sœurs et frères, Je ne sais comment vous remercier pour tout ce que vous faites pour moi. A toute ma famille. A tous mes chers amis du Maroc et de la France, A mes chers sœurs, frères et amis de l’ENSIAS et de la cité Souissi II, Pour tout le soutien que vous m’avez offert, je vous dis MERCI. A tous ceux qui m’aiment. A tous les martyrs, je dédie ce travail…

Abdellah

Dédicace

A mes très chers parents, Aucun mot ne pourra exprimer mes sentiments envers vous. A mes chères sœurs, A mon cher frère, Je ne sais comment vous remercier pour tout ce que vous avez fait pour moi. A toute ma famille. A tous mes chers amis de Kelaa, A mes chers amis de l’école, A mes très chers frères et amis de la cité universitaire Souissi II, Pour tout le soutien que vous m’avez offert, je vous dis MERCI. A tous ceux qui m’aiment. A tous les musulmans à travers le monde, je dédie ce travail…

Omar

Remerciements
Il nous est agréable de nous acquitter d’une dette de reconnaissance auprès de toutes les personnes, dont l’intervention au cours de ce projet, a favorisé son aboutissement. Ainsi, nous exprimons notre profonde gratitude et tenons à remercier tout le personnel de l’Administration des Douanes et Impôts Indirectes et plus précisément l’équipe RIAD, pour leur soutien et pour leur générosité considérable quant à l’offre de l’information. Nous tenons à exprimer nos gratitudes à M. Youssef EL MAZOURI, notre encadrant à l’Administration, qui nous a proposé un sujet très intéressant. Nos remerciements les plus sincères vont à Mme. Bouchra BERRADA, notre encadrant à l’ENSIAS, pour les conseils qu’elle nous a prodigué, son judicieux encadrement ainsi que son assistance pour la rédaction du rapport. Nos remerciements s’adressent également à M. Abdelhamid EL MAAZOUZI, M. Mourad ZEKRAOUI, M. Ali BEZGOURI, M. Mohamed DADSI, Mounir SEFIANI, Hicham ELIMAM, Chakir ETTAYEBI, Mlle Fatiha ID MHAMED et Mme Asmaa RETBI, pour avoir été toujours à l’écoute, et pour leurs conseils et éclaircissements. Que messieurs les membres de jury trouvent ici l’expression de nos reconnaissances pour avoir accepté de juger notre travail. Que tous ceux et celles qui ont contribué de près ou de loin à l’accomplissement de ce travail trouvent l’expression de nos remerciements les plus chaleureux.

Résumé
Le présent document constitue le fruit de notre travail accompli dans le cadre du Projet de Fin d’Etudes au sein de l’Administration des Douanes et Impôts Indirects (ADII). L’objectif de ce projet est la mise en place d’une solution pour la gestion de la formation continue en intranet sur la plate forme Java2 Entreprise Edition (J2EE). Cette solution sera intégrée dans le projet stratégique de l’ADII, RIAD (Ressources Intégrées de l’Administration des Douanes) Notre mission a consisté en l’étude du processus de gestion de la formation au sein de l’ADII, ainsi que la réalisation de l’ensemble des phases du développement de ce projet, depuis l’établissement des cahiers des charges jusqu’à l’intégration dans RIAD. Quant à l’aspect technique, l’utilisation du framework Struts a facilité la gestion des Interactions Homme Machines (IHM), et permis la migration du Design Pattern MVC vers MVC2. L’adoption de ce dernier apporte un remède aux faiblesses de sécurité dans les applications basées sur MVC. Le mapping ainsi que la gestion de la persistence ont été réalisés en utilisant le framework TopLink 9i d’Oracle. Ce rapport comporte trois parties. La première partie définit le contexte général du projet. Elle est composée de deux chapitres : la présentation de l’organisme d’accueil et les objectifs de notre projet. La deuxième partie, présente l’analyse des besoins et la conception des différentes composantes du système à développer. La troisième partie décrit les différentes étapes de la mise en œuvre du projet selon l’approche en « Y ». A la fin du rapport, nous présentons en complément les différentes annexes ayant trait du Plan d’Assurance Qualité (PAQ), de la grille des compétences, du processus Y, des types des Design Patterns et du frameworks TopLink.

Tables des matières
Liste des abréviations ---------------------------------------------------------------- ii Liste des figures ----------------------------------------------------------------------- ii Listes des tableaux ------------------------------------------------------------------- iii Introduction---------------------------------------------------------------------------- 4 PARTIE I : CONTEXTE GENERAL DU PROJET Chapitre1 : Présentation de l’organisme d’accueil ---------------------------- 7
Introduction ------------------------------------------------------------------------------------ 7 1. Activités principlaes de l’ADII ----------------------------------------------------------- 7 2. Organisation de l’ADII -------------------------------------------------------------------- 8 2.1. Organigrame de l’ADII -------------------------------------------------------------------- 8 2.2. Service de la Programmation et de l’Evaluation ------------------------------------- 8 2.3. Infrastructure technique du projet RIAD ---------------------------------------------- 9 Conclusion -------------------------------------------------------------------------------------- 9

Chapitre2 : Présentation du projet ---------------------------------------------- 10
Introduction ----------------------------------------------------------------------------------- 10 1. Politique de la formation continue ------------------------------------------------------ 10 2.1. La régionalisation de la formation continue ----------------------------------------- 11 2.2. Processus de gestion de la formation -------------------------------------------------- 11
2.2.1. Identification des besoins de formation ---------------------------------------------- 11 2.2.2. Elaboration des plans ------------------------------------------------------------------- 12 2.2.3. Mise en œuvre des actions de formation --------------------------------------------- 12 2.2.4. Evaluation des actions de formation-------------------------------------------------- 13

3. Contexte et but du projet ----------------------------------------------------------------- 13 4. Conduite du projet------------------------------------------------------------------------- 14 4.1. Processus de développement ------------------------------------------------------------ 14 4.2. Planification du projet -------------------------------------------------------------------- 14 Conclusion ------------------------------------------------------------------------------------- 15

PARTIE II : ANALYSE ET CONCEPTION DU PROJET Chapitre3 : Analyse et spécification -------------------------------------------- 17
Introduction ----------------------------------------------------------------------------------- 17 1. Fonctionnalités principales -------------------------------------------------------------- 17 2. Analyse du contexte ----------------------------------------------------------------------- 19 2.1. Les rôles ------------------------------------------------------------------------------------- 19 2.2. Identification des acteurs ----------------------------------------------------------------- 19 2.3. Hiérarchisation des rôles ----------------------------------------------------------------- 20 2.4. Interactions acteurs - système et les messages échangés -------------------------- 21 2.5. Diagrammes de contexte ----------------------------------------------------------------- 22 Conclusion ------------------------------------------------------------------------------------- 24

Chapitre4 : Conception de la solution ------------------------------------------ 25
Introduction ----------------------------------------------------------------------------------- 25 1. Décomposition du système --------------------------------------------------------------- 25 2. Choix du formalisme UML --------------------------------------------------------------- 26 3. Packages du système ---------------------------------------------------------------------- 27 3.1. Package grille ------------------------------------------------------------------------------- 27 3.2. Package plan -------------------------------------------------------------------------------- 31 3.3. Package action ------------------------------------------------------------------------------ 35 3.4. Package évaluation ------------------------------------------------------------------------ 40 4. Architecture technique du système ------------------------------------------------------ 44 Conclusion ------------------------------------------------------------------------------------- 45

PARTIE III : MISE EN ŒUVRE DU PROJET Chapitre5 : Technologies et outils utilisés ------------------------------------ 47
Introduction ----------------------------------------------------------------------------------- 47 1. L’architecture J2EE ----------------------------------------------------------------------- 47 2. Les technologies J2EE -------------------------------------------------------------------- 48 3. Design Patterns MVC et MVC2 --------------------------------------------------------- 49 4. Framework « Struts » --------------------------------------------------------------------- 50 4.1. Choix du framework Struts -------------------------------------------------------------- 50 4.2. Architecture et fonctionnement du Framework Struts ----------------------------- 51 5. Framework « TopLink » ------------------------------------------------------------------ 52 5.1. La problématique de la persistance objet --------------------------------------------- 52 5.2. La solution « Oracle9iAS TopLink »-------------------------------------------------- 53 6. Oracle 9i Application Server ------------------------------------------------------------ 54 7. Environnement de développement JDeveloper 10g ----------------------------------- 55 Conclusion ------------------------------------------------------------------------------------- 55

Chapitre6 : Mise en œuvre de la solution et intégration dans RIAD ----- 56
Introduction ----------------------------------------------------------------------------------- 56 1. Architecture Applicative ------------------------------------------------------------------ 56 2. Réalisation des couches applicatives --------------------------------------------------- 57 2.1. La couche Données ------------------------------------------------------------------------ 57 2.2. La couche Métier -------------------------------------------------------------------------- 57 2.3. La couche Mapping et persistance ----------------------------------------------------- 58 2.4. La couche Présentation ------------------------------------------------------------------- 59 2.5. La couche Services ------------------------------------------------------------------------ 60 3. Intégration avec le projet RIAD --------------------------------------------------------- 60 Conclusion ------------------------------------------------------------------------------------- 61

Conclusion et Perspectives -------------------------------------------------------- 62 Bibliographie ------------------------------------------------------------------------ 63 ANNEXES---------------------------------------------------------------------------- 65

Annexe 1 : Plan d’Assurance Qualité ------------------------------------------Annexe 2 : Grille de Compétences----------------------------------------------Annexe 3 : Processus Y -----------------------------------------------------------Annexe 4 : Types de Design Patterns ------------------------------------------Annexe 5 : TopLink ----------------------------------------------------------------

66 70 71 72 74

Listes des abréviations

Liste des abréviations
Abréviation Désignation ADII Administration des Douanes et Impôts Indirects EJB GIPE IDE J2EE JDBC JDO JNDI JSP JTS MVC ODMG OJB PAQ RMI RO SGBD UML XML Entreprise JavaBean Gestion Intégrée du Personnel de l’Etat Integrated Development Environment Java 2 Enterprise Edition Java Data Base Connectivity Java Data Object Java Naming and Directory Interface Java Server Pages Java Transaction Service Model View Controller Object Data Management Standards Object Java Bridge Plan d’Assurance Qualité Remote Method Invocation Relational Object Systèmes de Gestion de Bases de Données Unified Modelling Language eXtensible Markup Language

Projet de Fin d’Etudes / ENSIAS 2004

i

Listes des figures

Liste des figures
Figure 1 : Organigramme de l’ADII------------------------------------------------------------------- 8 Figure 2 : Processus « 2TUP »------------------------------------------------------------------------ 14 Figure 3 : Hiérarchisation des acteurs humains ---------------------------------------------------- 20 Figure 4 : Hiérarchisation du rôle du responsable immédiat ------------------------------------- 20 Figure 5 : Hiérarchisation des systèmes ------------------------------------------------------------- 21 Figure 6 : Digramme de contexte : Vue Humaine -------------------------------------------------- 23 Figure 7 : Digramme de contexte : Vue Système---------------------------------------------------- 23 Figure 8 : Décomposition du système en sous modules -------------------------------------------- 26 Figure 9 : Diagramme de cas d’utilisation du package « Grille » ------------------------------- 28 Figure 10 : Diagramme d’objets du cas d’utilisation «Gestion des grilles » ------------------- 29 Figure 11 : Diagramme de classes du package « Grille » ----------------------------------------- 30 Figure 12 : Diagramme de séquences du scénario « Création d’une grille »------------------- 31 Figure 13 : Diagramme de cas d’utilisation du package « Plan » ------------------------------- 32 Figure 14 : Diagramme d’objets du cas d’utilisation « Gestion des plans régionaux » ------- 33 Figure 15 : Diagramme de classes candidates du package « Plan »----------------------------- 34 Figure 16 : Diagramme de séquences de « création de plan régional » ------------------------- 35 Figure 17 : Diagramme de cas d’utilisation du package Action ---------------------------------- 36 Figure 18 : Diagramme d’objets de « Planification d’une action de formation» -------------- 38 Figure 19 : Diagramme de classes candidates du package « action » --------------------------- 39 Figure 20 : Diagramme de séquences de planification d’une session de formation ----------- 40 Figure 21 : Diagramme de cas d’utilisation du package Evaluation ---------------------------- 41 Figure 22 : Diagramme d’objets de « Elaboration du rapport d’évaluation» ------------------ 42 Figure 23 : Diagramme de classes candidates du package «Evaluation»----------------------- 43 Figure 24 : Diagramme de séquences de l’élaboration du rapport d’évaluation -------------- 44 Figure 25 : Architecture technique du système de gestion de la formation --------------------- 44 Figure 26 : Technologies J2EE ----------------------------------------------------------------------- 48 Figure 27 : Modèle MVC2 ----------------------------------------------------------------------------- 49 Figure 28 : Modèle MVC2 ----------------------------------------------------------------------------- 50 Figure 29 : Principe de fonctionnement du framework Struts ------------------------------------ 52 Figure 30 : Composantes principales du framework ----------------------------------------------- 54 Figure 31 : Architecture applicative du système de gestion de formation ----------------------- 57 Figure 32 : Arborescence des packages métier ----------------------------------------------------- 58 Figure 33 : Outil de mapping des classes vers les tables de la BD ------------------------------- 59 Figure 34 : Page d’accueil du système de gestion de formation ---------------------------------- 60 Figure 35 : Planning détaillé du déroulement du projet ------------------------------------------- 68 Figure 36 : Evaluation du modèle de persistance EJB --------------------------------------------- 78 Figure 37 : Evaluation du modèle de persistance JDO -------------------------------------------- 79 Figure 38 : Evaluation du modèle de persistance Oracle9iAS TopLink ------------------------- 80

Projet de Fin d’Etudes / ENSIAS 2004

ii

Listes des tableaux

Listes des tableaux
Tableau 1 : Planning global de réalisation du projet ---------------------------------------------- 15 Tableau 2 : Liste des messages échangés entre le système et les acteurs ------------------------ 22 Tableau 3 : Comparaison de quelques frameworks en terme de puissance et de complexité - 51 Tableau 4 : Les participants au projet côté ADII --------------------------------------------------- 66 Tableau 5 : Les participants au projet côté ENSIAS ----------------------------------------------- 66 Tableau 6 : Membres du comité de pilotage --------------------------------------------------------- 67 Tableau 7 : Membres du comité de projet ----------------------------------------------------------- 67 Tableau 8 : Les livrables par phase ------------------------------------------------------------------ 69

Projet de Fin d’Etudes / ENSIAS 2004

iii

Introduction

Introduction
Après quelques décennies, la formation continue, plutôt sporadique et inégalement répartie, est reconnue comme un prolongement naturel et indispensable de l'école. Les mutations et les évolutions récentes de l’économie mondiale accentuent cette tendance et rendent nécessaire une réflexion profonde et renouvelée sur la formation continue. Les organismes conscients de l’importance de la formation continue comme étant un pilier de toute stratégie de gestion des ressources humaines d’une part, et un enjeu clé pour accompagner les changements émanant des évolutions d’autre part, ont développés leurs politiques de formations qui leurs permettent de diagnostiquer et par conséquent enrichir leurs référentiels de compétences. Cet enrichissement permet d’avoir un rendement important et de palier aux dysfonctionnements à court, moyen et long terme. Dans ce sens et conformément à sa stratégie de veille technologique et économique, l’ADII a jugé nécessaire l’élaboration de sa politique lui permettant de diagnostiquer les compétences disponibles afin de les faire évoluer. Ainsi, notre projet a pour but de doter les responsables de la formation continue au sein de l’administration d’un système transactionnel (Web) leurs permettant la gestion des différentes composantes de la formation à savoir : • • • Grille de compétences, Plans de formations, Rapports d’évaluation.

Le présent rapport comporte trois parties. La première partie, composée de deux chapitres, définit le contexte général du projet. Elle débute par la présentation de l’organisme d’accueil. La présentation de notre projet et la démarche suivie feront l’objet du deuxième chapitre de cette partie. Dans la deuxième partie, nous exposons les concepts de modélisation de notre projet. Ainsi, le premier chapitre est consacré à l’analyse et la spécification des besoins afin d’énumérer les fonctionnalités principales du système à développer et de délimiter le périmètre fonctionnel de ce futur système. Le deuxième chapitre fera l’objet de la phase de conception du projet en utilisant le standard UML. Quant à la troisième partie, elle présente les aspects techniques du projet. Elle décrit les différentes technologies et outils utilisés ainsi que les étapes de la mise en œuvre de ce projet selon la démarche choisie. Dans le premier chapitre, nous allons décrire l’architecture et les technologies J2EE, les outils ainsi que les frameworks utilisés pour la concrétisation de notre projet : Struts, TopLink, JDevelopper 10g et le serveur d’applications Oracle 9i AS. Le
Projet de Fin d’Etudes / ENSIAS 2004

4

Introduction

deuxième chapitre abordera l’étape de la mise en œuvre du projet tout en présentant la mise en place de chaque couche de l’architecture technique du système. A la fin du rapport, nous présentons un complément dans les différents annexes traitant le plan d’assurance qualité, la grille de compétences, le processus de développement, les types des Design Patterns et le framework TopLink.

Projet de Fin d’Etudes / ENSIAS 2004

5

Partie 1 : Contexte général du projet

PARTIE 1 : CONTEXTE GENERAL DU PROJET

Cette partie comprend deux chapitres :

Le premier chapitre introduit l’organisme d’accueil, ses activités et son organigramme.

Le deuxième chapitre présente le sujet du projet et traite les différents aspects de la politique de gestion de la formation dans l’ADII. Il précise également l’objectif et la conduite du projet ainsi que le planning général de la réalisation.

Projet de Fin d’Etudes / ENSIAS 2004

6

Chapitre 1 : Présentation de l’organisme d’accueil

Chapitre1 : Présentation de l’organisme d’accueil

Dans ce chapitre nous présentons l’organisme d’accueil : Administration des Douanes et Impôts indirects. Nous exposons d’abord, les activités de l’ADII puis son organisation ainsi que son infrastructure technique.

Introduction
Comme nous l’avons indiqué auparavant, notre projet s’est déroulé au sein de l’ADII, dont le fonctionnement est axé autour de plusieurs activités, et se base sur un système d’information mature.

1. Activités principales de l’ADII
L’Administration des Douanes et Impôts Indirects (ADII), est un organe du ministère de l’économie, des finances et de la privatisation. Elle participe à la définition de la politique douanière nationale et en assume la mise en oeuvre à travers les missions suivantes : La promotion de l’investissement L’ADII contribue au développement économique du Maroc. Son intervention dans la promotion de l’investissement revêt plusieurs aspects, en particulier : • • • • L’application des dispositions relatives aux avantages fiscaux accordés aux matériels, outillages et autres équipements importés ; La promotion des régimes économiques en douanes, notamment l’admission temporaire et l’entrepôt industriel franc ; La simplification des procédures de dédouanement ; La mise en place d’une organisation efficiente des services douaniers basés sur un recours de plus en plus accru au traitement automatique rendu possible grâce à la généralisation de l’outil informatique.

La protection du consommateur Dans le cadre de la mise en application de certaines législations particulières, l’ADII veille, aussi bien à l’importation qu’à l’exportation, au respect d’un certain nombre de règlements en matière de contrôle de la qualité, des normes techniques, des mesures sanitaires, vétérinaires et photo sanitaires, de la protection de la propriété intellectuelle et de contrôle de la répression des fraudes. Cette protection s’exerce également à travers le contrôle des ouvrages en métaux précieux. La protection de l’économie nationale Avec le démantèlement tarifaire, la protection de l’économie nationale intervient davantage à travers la maîtrise des règles d’origine et la lutte contre le dumping. Le développement des accords tarifaires bilatéraux et multilatéraux fait de l’origine de la marchandise une des

Projet de Fin d’Etudes / ENSIAS 2004

7

Chapitre 1 : Présentation de l’organisme d’accueil

conditions essentielles pour l’octroi des avantages prévus par lesdits accords. De même une attention particulière est accordée à la valeur des marchandises importées pour prévenir toute action de dumping pouvant porter préjudice à la production nationale. L’équité fiscale L’ADII veille à ce que les importations d’une même marchandise (même origine, même valeur, etc..) acquittent les mêmes droits et taxes quelque soit l’importateur ou le bureau d’importation. L’équité fiscale implique également une lutte contre la contrebande et la fraude sous toutes ses formes.

2. Organisation de l’ADII
L’ADII est organisée en services centraux et services extérieurs. Le nombre du personnel au sein des services Centraux et Extérieurs s’élève à 4795 répartis sur des échelles et des catégories diverses.

2.1. Organigramme de l’ADII

ADII

Directions centrales Divisions centrales

Division de l’audit

Directions régionales Circonscriptions

Services centraux

Brigade

Recette

Ordonnancements

Figure 1 : Organigramme de l’ADII Les services centraux sont placés sous l'autorité du directeur général de l'administration, assisté des directeurs centraux et des chefs de division. L'organisation des services centraux repose sur quatre directions, groupant dix divisions, et une division de l’audit rattachée directement au directeur général.

2.2 Service de la Programmation et de l’Evaluation
Notre projet s’est déroulé dans le service de la programmation et de l’évaluation. Ce service appartient à la division de la programmation et de la communication composée de trois services : • Service de la Programmation et de l'Evaluation ; • Service de la Gestion de l'Information ; • Service de la Communication.

Projet de Fin d’Etudes / ENSIAS 2004

8

Chapitre 1 : Présentation de l’organisme d’accueil

La division de la programmation et de la communication est sous l’autorité de la direction des ressources et de la programmation. Le service de la programmation et de l’évaluation est chargé de la réalisation du projet stratégique RIAD.

2.3. Infrastructure technique du projet RIAD
Vu l’importance accordée par l’ADII au projet RIAD, une infrastructure technique très riche a été mise à disposition de l’équipe RIAD composée des membres du service de la programmation et de l’évaluation. Cette infrastructure s’articule autour des technologies J2EE et se base sur un spectre d’outils très puissant. Les principales composantes de l’infrastructure de RIAD sont : • • • • • Serveur de bases de données Oracle Serveur d’applications 9i Application Server (9iAS) Moteur Workflow Serveurs Web Progiciel GIPE

Conclusion
Dans le présent chapitre, nous avons présenté l’organisme d’accueil en terme d’activités et d’organisation. Le Service de la Programmation et de l’Evaluation, dans lequel s’est déroulé notre projet, a été situé dans l’organigramme de l’ADII avant de présenter le projet RIAD. Le chapitre suivant présente le sujet du projet, son but et la démarche adoptée pour sa réalisation.

Projet de Fin d’Etudes / ENSIAS 2004

9

Chapitre 2 : Présentation du projet

Chapitre2 : Présentation du projet

Dans ce chapitre, nous décrivons la politique de l’ADII en matière de gestion de la formation continue ainsi que l’objectif de notre projet. Nous terminons par présenter la démarche adoptée et le planning général suivi pour la réalisation de notre projet.

Introduction
La politique de formation adoptée par l'ADII entre dans le cadre du plan d’action stratégique du ministère de l’économie et des finances, qui a inscrit la formation parmi ses priorités. Dans cette même optique, l'administration a entrepris un programme de réformes et de modernisation, où la formation professionnelle servirait cette même mission.

1. Politique de la formation continue
Cette politique vise à définir : • d'une part les objectifs opérationnels généraux que les actions de formation doivent permettre de réaliser, et la démarche permettant d'assurer une meilleure adéquation formation – emploi ; • et d'autre part, le cadre général de la régionalisation de la formation, ainsi qu'une démarche d'identification des besoins et d'élaboration des plans de formation internes, régionaux et nationaux. La transmission ainsi que l’amélioration des savoir-faire sont réalisées au moyen de deux types de formation : la formation de base et la formation continue. La formation de base vise à doter le stagiaire de connaissances générales, théoriques et pratiques sur toutes les composantes de l’environnement douanier, lui permettant ainsi, d’intégrer facilement le milieu professionnel avec un minimum d’opérationnalité, au terme de sa formation. Quant à la formation continue, elle permet de faire évoluer d’une part, les compétences des agents pour la bonne maîtrise des opérations, qui contribuent à la production d’une plus-value au sein de l’ADII, et d’autre part leurs savoir-faire. La politique de formation continue de l’ADII vise à atteindre les objectifs suivants : • développer la polyvalence des agents ; • atténuer la vulnérabilité des services et accompagner la politique de redéploiement du personnel poursuivie par l’administration d’une part ; • et d’assurer l'unification du langage avec les partenaires de l'administration.

Projet de Fin d’Etudes / ENSIAS 2004

10

Chapitre 2 : Présentation du projet

Afin d’atteindre ces objectifs, l’ADII a engagé une politique de déconcentration et de régionalisation de la formation continue.

2.1. La régionalisation de la formation continue
La régionalisation de la formation continue est dictée par le souci de généraliser le bénéfice de la formation à l'ensemble des douaniers à moindre coût et d’assurer une meilleure adéquation entre les emplois qu’ils occupent et les formations qu’ils possèdent. Une telle politique ne peut être efficace que si elle permet une bonne identification des besoins. Celle-ci doit se baser sur une analyse fine des écarts entre les compétences disponibles et les compétences exigées, aussi bien à court terme, pour corriger les dysfonctionnements actuels, qu'à long terme, pour accompagner les évolutions futures. Cette démarche permet l’élaboration et la mise en œuvre d’actions de formation répondant aux besoins stratégiques de l'administration, de ses agents et de ses partenaires. Ainsi, l’ADII a adopté une approche scientifique qui consiste à approfondir la connaissance de l'existant, écouter les intéressés, et les associer étroitement à la préparation des plans de formation les concernant, et enfin, à mettre en adéquation les orientations générales de l'administration. L’approche adoptée par l’ADII en matière de formation continue est inspirée de la méthode de formation intégrée mise au point par l’Institut de Socio économie des Entreprises et des Organisations (ISEOR) en France.

2.2. Processus de gestion de la formation
L’approche précitée se décompose en quatre phases principales : 2.2.1. Identification des besoins de formation Cette phase repose sur deux étapes essentielles :
• Diagnostic des compétences

Le diagnostic des compétences vise le repérage des "points de fragilité" tant au niveau de la polyvalence du personnel qui compose l'entité qu’au niveau de la vulnérabilité des postes de l'entité elle même. Les dysfonctionnements sont localisés au moyen de trois sources d’information : entretiens qualitatifs, analyse de quelque documents (notes d’orientations générales, compte rendus de réunions, rapports d’audit et d’inspection…) et Observation directe.
• Etablissement des grilles de compétences

Une grille de compétences se présente sous forme d’un tableau synoptique à double entrée (Annexe 2) constituant un véritable tableau de bord de pilotage des compétences, fortement visualisé permettant, grâce au degré de noircissement des symboles utilisés pour la cotation, d’apprécier le niveau des compétences disponibles au sein de l’unité. Elle est établie par le supérieur hiérarchique qui recense les compétences existantes, aussi bien sur les opérations liées aux activités de l’unité ou de l’équipe, que sur les savoir-faire particuliers des personnes qui y constituent. Cette phase d’identification des besoins se termine par la cotation des agents qui se fait sur la base de la qualité de la réalisation effective d’une opération par un individu et non sur la base du jugement de ses capacités potentielles à son éventuelle exécution.

Projet de Fin d’Etudes / ENSIAS 2004

11

Chapitre 2 : Présentation du projet

Sur la base de cette cotation, les deux indicateurs : Indicateur de Polyvalence, qui mesure la polyvalence des agents, et Indicateur de Vulnérabilité, qui mesure le niveau de vulnérabilité d’un service, sont calculés pour pouvoir identifier les besoins en formation (Annexe 2). 2.2.2. Elaboration des plans Les besoins de formation identifiés au moyen du diagnostic sont comblés par le biais de trois types de plans de formation :
• Plan interne de formation

Le plan interne de formation, élaboré par le responsable immédiat qui est le chef de l’unité, est destiné à combler les besoins individuels spécifiques des agents. Il est mis en œuvre sur le lieu de travail, au niveau des services locaux et centraux, sous la responsabilité de la hiérarchie directe. Ce plan est intégré dans la même grille de compétences ayant servi à identifier les besoins individuels en formation. • Plan régional de formation Chaque Direction Régionale a un plan de formation qui vise à satisfaire les besoins collectifs en formation, décelés dans différents services locaux relevant de la même Direction Régionale. Les plans régionaux sont élaborés par les structures régionales chargées de la gestion de la formation. Le responsable immédiat, après avoir réalisé le diagnostic des compétences, au niveau de sa structure, doit distinguer les besoins individuels de ceux collectifs. Ces derniers doivent faire l’objet d’une remontée aux cellules régionales chargées de la gestion de la formation, aux fins de leur intégration dans les plans régionaux. • Plan national de formation Le plan national de formation est élaboré par le service de la formation. Il intègre les besoins en formation : collectifs des agents de l’Administration Centrale; des formateurs régionaux chargés d’animer les formations inscrites dans les plans régionaux; concernant les thèmes jugés stratégiques par l’Administration. Une note d’orientations générales doit permettre au Service de dégager des axes stratégiques de formation qui seront également intégrés dans le plan national de formation. 2.2.3. Mise en œuvre des actions de formation Les actions de formation retenues dans les différents plans sont mises en oeuvre selon le type du plan. La mise en œuvre des formations internes suppose l’implication active de la hiérarchie directe tout en donnant la possibilité à l’agent concerné de pratiquer réellement l’opération sur laquelle il a besoin d’être formé et désigner le formateur adéquat, celui-ci doit être choisi parmi l’encadrement le plus proche de l’agent à former. Les actions de formation retenues dans les plans régionaux sont animées par les formateurs régionaux et sont mises en œuvre dans les espaces pédagogiques relevant des différentes directions régionales sous la responsabilité directe du directeur régional. Enfin, les actions de formation retenues dans le plan national en faveur des formateurs régionaux qui vont assurer les mêmes formations à leurs collègues dans le cadre des plans

Projet de Fin d’Etudes / ENSIAS 2004

12

Chapitre 2 : Présentation du projet

régionaux, sont mises en œuvre ou bien par des formateurs internes à l’administration, ou bien par des formateurs externes provenant des organismes de formations spécialisés. 2.2.4. Evaluation des actions de formation Trois évaluations, quantitative, qualitative et financière sont nécessaires pour apprécier l’efficacité et l’efficience des actions de formation engagées par l’administration.
• Evaluation quantitative

Elle a pour objectif de mettre en évidence l’effort quantifié de formation. Elle porte sur : Le nombre d’agents formés (par catégorie, sexe, structure, etc.) ; Le nombre de jours de formation par agent et par an ; Le nombre d’actions de formation réalisées au niveau central, régional, et local.
• Evaluation qualitative

L’évaluation qualitative a pour objectif de vérifier, d’une part, le degré de mise en œuvre effective des connaissances acquises dans les situations réelles de travail et, d’autre part, le degré de satisfaction des agents formés, aussi bien par rapport à la qualité de la formation, que par rapport aux conditions de son déroulement.
• Evaluation financière

Si l’évaluation qualitative permet de s’assurer de l’efficacité de la formation, l’évaluation financière permet de rendre compte de son efficience. Ainsi, au moyen de cette évaluation, doivent être appréciés les coûts financiers générés par la formation, tout en les rapportant à sa qualité.

3. Contexte et but du projet
Consciente de l’importance de l’informatique, l’ADII accorde aujourd’hui une attention particulière à son système d’information et adopte une démarche de « gestion par projet » émanant d’un schéma directeur. Le dernier projet soumis est celui des Ressources Intégrées de l’Administration des Douanes, baptisé RIAD. Pour ce projet initié en l’an 2000, il avait été envisagé plusieurs scénarii : l’achat d’un progiciel de gestion, le recours à un prestataire et le développement spécifique ou en interne. En raison des difficultés d’ordre technique et financier que présentent les deux premiers scénarii, l’administration a retenu le développement spécifique comme choix stratégique. Le projet RIAD couvre quatre domaines : • Ressources humaines ; • Ressources matérielles ; • Ressources financières ; • Le self-service. Relevant du domaine des RH, le projet qui nous a été assigné comprend trois phases : • Etude et modélisation du processus de gestion de la formation, qui est l’un des piliers de la stratégie de la gestion des ressources humaines dans l’administration ; • La mise en œuvre d’une solution répondant aux différentes exigences fonctionnelles et techniques ; • L’intégration de la solution dans le projet RIAD. Ainsi, notre travail consiste à gérer les composantes des quatre phases du processus de la formation précitées : l’élaboration des grilles de compétences, l’élaboration des plans de

Projet de Fin d’Etudes / ENSIAS 2004

13

Chapitre 2 : Présentation du projet

formation, la planification et la mise en œuvre des actions de formation, et enfin l’élaboration des fiches et des rapports d’évaluation.

4. Conduite du projet
4.1. Processus de développement
Traditionnellement, la modélisation des systèmes se base sur les trois hypothèses suivantes : • Les fonctionnalités d'un système sont stables, elles n'évoluent pas avec les temps; • Les besoins relatifs à un système sont donnés au départ; • La validation des besoins peut se faire en référence aux fonctionnalités du système [CORCA01]. Aujourd'hui, il est clair que ces hypothèses ne sont plus valides. Ainsi, une séparation entre le fonctionnel et le technique, lors du développement, est dictée par le besoin d'un produit extensible. Pour livrer un produit qui respecte les besoins des utilisateurs tout en s'adaptant aux futurs changements, nous avons optés pour le processus 2TUP (Two «2» Tracks Unified Process). C'est un processus unifié qui apporte une réponse aux contraintes de changement continuel imposées aux systèmes d'information de l'entreprise. "2 Tracks" signifie littéralement que le processus suit deux chemins. Il s'agit des chemins "fonctionnel" et "d'architecture technique", qui correspondent aux deux axes de changement [ROVA00]:

Figure 2 : Processus « 2TUP » 2TUP est un processus qui répond également aux caractéristiques ci-après: • Un processus incrémental piloté par les risques • Un processus pilotés par les exigences des utilisateurs • Un processus de modélisation avec UML (Annexe 3)

4.2. Planification du projet
La planification du projet est parmi les phases d'avant projet. Elle consiste à prévoir le déroulement du projet tout au long des phases constituant le cycle de développement. Grâce aux réunions tenues avec nos encadrants au sein de l’administration, nous avons été éclairés
Projet de Fin d’Etudes / ENSIAS 2004

14

Chapitre 2 : Présentation du projet

sur les différentes étapes du projet ainsi que leur séquencement. Cela consistait en trois grandes étapes: la première est une phase d'analyse et de spécification dont les objectifs est de bien cerner le sujet d'une part et de délimiter le périmètre du projet d'autre part. La seconde est consacrée à la conception de la solution et quant à la troisième étape, elle traite la mise en oeuvre de la solution. Le tableau suivant présente sommairement le planning des étapes du déroulent de notre projet, le planning détaillé figure dans le Plan d'Assurance Qualité (Annexe 1) Phase Lancement du Projet Analyse et spécification 20% Estimation (%) Début 09/02/04 13/02/04 Fin 12/02/04 04/03/04 Livrable PAQ - Cahier des charges utilisateur (CDCU) - Cahier des charges fonctionnel (CDCF) - Dossier de conception générale - Dossier de conception détaillée - Système développé et testé. - Dossier de validation fonctionnelle

Conception de la solution Mise en œuvre de la solution Validation fonctionnelle

40% 35% 5%

05/03/04 15/04/04 21/05/04

14/04/04 20/05/04 25/04/04

Tableau 1 : Planning global de réalisation du projet Ce planning était un fil conducteur tout au long du projet. Il nous a permis d’ajuster les dérives et de maîtriser la gestion du temps alloué pour la réalisation du projet. Les livrables des différentes phases de ce planning servent de documentation pour le projet et nous ont servis à la rédaction de ce rapport.

Conclusion
Dans ce chapitre, nous avons présenté la politique de formation adoptée par l’ADII. Cette politique n’est autre que le processus de gestion de la formation au sein de l’administration. La présentation du but du projet est la seconde partie de ce chapitre suivie de la description du processus de développement 2TUP que nous avons adopté pour le développement du système de gestion de la formation. A base de ce processus que nous avons établi un planning de travail afin de bien maîtriser les ressources allouées au projet. Le chapitre suivant est consacré à l’analyse et la spécification du sujet.

Projet de Fin d’Etudes / ENSIAS 2004

15

Partie 2 : Analyse et conception du projet

PARTIE 2 : ANALYSE ET CONCEPTION DU PROJET

Cette partie traite les deux phases les plus importantes et les plus critiques de tout cycle de développement. Ce sont l’analyse et la conception. Un premier chapitre présente la phase d’analyse dont le but est de délimiter le périmètre du projet en identifiant les fonctionnalités auxquelles le système doit répondre, ainsi que les entités externes (acteurs humains et systèmes) qui réagissent avec le système. Les résultats de la phase d’analyse sont la base de la phase de conception traitée par un deuxième chapitre. Ce dernier commence par une décomposition du système en packages fonctionnels ce qui permet de maîtriser sa conception avec le formalisme UML.

Projet de Fin d’Etudes / ENSIAS 2004

16

Chapitre 3 : Analyse et spécification

Chapitre3 : Analyse et spécification

Ce chapitre décrit la phase d’analyse et de spécification du projet. Dans un premier temps, nous identifions les fonctionnalités auxquelles le système de gestion de la formation doit répondre. La seconde partie traite de l’analyse du contexte du projet permettant d’identifier les interactions entre le système et le monde extérieur afin de délimiter le périmètre fonctionnel.

Introduction
Lors de cette phase nous avons effectué une étude des besoins des utilisateurs du système à développer. Ces besoins ont été identifiés lors des réunions tenues avec ces utilisateurs. Cette première phase du cycle de développement avait comme livrables, le cahier des charges utilisateur et le cahier des charges fonctionnel. Dans le présent chapitre nous présentons la synthèse de ces deux livrables.

1. Fonctionnalités principales
Cette partie est réservée à l’énumération ainsi qu’à la description des différentes fonctionnalités que le système de gestion de la formation doit assurer. Une analyse profonde du cahier des charges utilisateur établie suite aux réunions avec nos encadrants, nous a mené à dégager les sept fonctionnalités suivantes : 1. Sécurisation des accès au système Lors de sa connexion, chaque utilisateur du système doit être reconnu par un login et un mot de passe et la fonction qu’il occupe. La gestion des mots de passe et des profils des utilisateurs est assurée par le système de gestion des habilitations. 2. Gestion des opérations et des savoir-faire L’activité principale d’une unité organisationnelle (UO) s’articule autour d’un certain nombre d’opérations qui représentent le cœur de son métier. En outre, les agents d’une unité peuvent avoir des compétences supplémentaires qualifiées de savoir-faire. Le système doit fournir au responsable de l’unité la possibilité de gérer les opérations et les savoir-faire relatifs à sa structure et de les classer selon leurs natures. 3. Gestion des grilles de compétences En vu d’identifier les besoins en formation dans une unité organisationnelle, le responsable de l’unité organisationnelle procède à un diagnostic des compétences disponibles dans son unité en remplissant la grille des compétences. 17

Projet de Fin d’Etudes / ENSIAS 2004

Chapitre 3 : Analyse et spécification

Ainsi, le système doit permettre le remplissage da la grille et calculer automatiquement les indicateurs de polyvalence pour chaque agent et de vulnérabilité du service par rapport à chaque opération. Le responsable de l’unité peut également créer, modifier et supprimer une grille. La validation d’une grille la rend visible par le formateur régional concerné. 4. Elaboration des plans de formation Plan interne Une fois les besoins sont identifiés et hiérarchisés, le responsable d’une UO entame la phase de l’élaboration du plan interne contenant les formations visant à satisfaire les besoins individuels au niveau de sa structure et qui seront dispensées en interne. Le système permettra au responsable de gérer ses plans internes tout en saisissant les formations ainsi que les dates prévues pour la réalisation de chacune de ces formations. La validation d’un plan interne le rend accessible par le formateur régional. Plan régional Chaque formateur régional consulte les plans internes des UO relevant de son autorité afin de dégager les besoins en formation à caractère régional. Le système lui permet d’élaborer un plan régional de formation contenant les formations répondant aux besoins dégagés des plans internes. Dans le cas où une circonscription est directement attachée à la direction centrale, le chef de circonscription joue le même rôle que celui du formateur régional : il établit le plan régional des UO qui sont sous son autorité. Plan national Quant au plan national, le service central de la formation procède à un regroupement des besoins exprimés dans les plans régionaux en vue de tirer ceux à caractère national, ensuite il recense les besoins des services de l’administration centrale. Enfin, tenant compte des orientations générales du comité directeur, le service élabore le plan national en précisant les formations répondant aux besoins ainsi identifiés. Ce plan doit être remis au comité pédagogique pour la planification et une éventuelle modification. Tous ces aspects doivent être gérés par notre système à développer. 5. Programmation des sessions de formation Une session de formation est mise en place pour satisfaire un besoin mentionné dans un plan interne, régional ou national. Cette réalisation nécessite la mise en place d’un planning de réalisation de la session, la détermination du lieu, des participants, des dates et des animateurs ou formateurs. Notre système doit pouvoir offrir un outil pour programmer les sessions de formations. 6. Traitement et synthèses des résultats de formations Le système doit gérer les résultats issus des différentes fiches d’évaluation : Fiches d’évaluation remplies par un jury, elles permettent d’évaluer les acquis des participants à la formation, Fiches d’appréciation remplies par les participants pour apprécier la formation. L’évaluation est aussi effectuée au niveau financier. En effet, cet axe financier permet d’optimiser les ressources lors des prochaines réalisations.

Projet de Fin d’Etudes / ENSIAS 2004

18

Chapitre 3 : Analyse et spécification

L’opération d’évaluation a pour résultat l’élaboration d’un rapport d’évaluation qui permet de donner une vision synthétique sur les formations réalisées au profit des agents de l’administration. 7. Intégration au Système d’Information de l’ADII : Vu l’importance étroite de l’interopérabilité entre les applications du SI d’un même organisme, le système de gestion de la formation doit être bien conçu pour être intégré facilement au SI de l’ADII en s’interfaçant avec les applications qui le constituent. Le système de gestion de la formation est un module du projet RIAD ce qui nécessite son intégration dans le projet via des interfaces avec les autres modules. Les systèmes avec lesquels nous devons assurer un interfaçage sont : Le système de gestion du personnel de l’ADII (GIPE) Le système de gestion des profils et des compétences de l’ADII Le système de gestion des habilitations Le système de gestion organisationnelle de l’administration Le système de gestion budgétaire. L’identification de ces fonctionnalités, nous permet maintenant de procéder à une analyse du contexte du système à développer.

2. Analyse du contexte
L’analyse du contexte a pour objectif l’identification des différentes entités qui interagiront avec le système. Ces entités seront regroupées par la suite sous forme de rôles dont chacun englobe un ensemble d’entités. Le regroupement sera effectué en se basant sur les interactions.

2.1. Les rôles
Un rôle réfère à une mission et à des responsabilités assumées par des entités externes au système étudié. Ces entités ou acteurs (utilisateur, dispositif matériel ou autre système) interagissent (communiquent) directement avec le système étudié. Un acteur peut consulter et/ou modifier directement l’état du système, par émission et/ou réception de messages éventuellement porteurs de données. L’étude de la typologie des rôles a conduit à la classification suivante : Rôles joués par des acteurs humains : • • Agents de l’ADII.

Rôles joués par des systèmes (acteurs non humains) Systèmes internes à l’ADII

2.2. Identification des acteurs
Un acteur peut consulter et/ou modifier directement l’état du système, par émission et/ou réception de messages éventuellement porteurs de données. Les acteurs que nous avons identifiés à partir de la description des fonctionnalités ci-dessus sont les suivants :

Projet de Fin d’Etudes / ENSIAS 2004

19

Chapitre 3 : Analyse et spécification

• • • • • • • • • • • •

Responsable immédiat Formateur régional Chef de circonscription Cadre du service de formation central Fonctionnel de formation Comité directeur Comité pédagogique Système de gestion du budget Système de gestion des profils et compétences Système d’Habilitation Système de gestion organisationnel Système de gestion du personnel GIPE

2.3. Hiérarchisation des rôles
L’identification de la majorité des rôles pertinents à retenir a permis de concevoir l’arborescence des rôles, en utilisant la représentation graphique fondée sur le formalisme UML.

Figure 3 : Hiérarchisation des acteurs humains Afin de préciser les acteurs qui pourront jouer le rôle du responsable immédiat nous avons procédé à l’hiérarchisation de ce rôle :

Figure 4 : Hiérarchisation du rôle du responsable immédiat Les systèmes sont aussi hiérarchisés de la manière suivante :

Projet de Fin d’Etudes / ENSIAS 2004

20

Chapitre 3 : Analyse et spécification

Figure 5 : Hiérarchisation des systèmes Ces acteurs systèmes sont tous des modules du projet RIAD auquel doit être intégré le système à développer et ce à travers les interfaces de communication avec ces systèmes.

2.4. Interactions acteurs - système et les messages échangés
Un message représente ici la spécification de haut niveau d’une interaction (communication) entre acteurs et système, avec l’intention (métier) de déclencher une activité chez le récepteur. La réception d’un message est normalement considérée comme un événement. Il faut se demander : • Pour chaque acteur, quels sont les messages qui déclenchent un comportement attendu par l’acteur du système, dans le cadre de son activité; • Pour le système, quels sont les messages émis à l’attention d’un acteur particulier et qui portent une information utilisée par ce destinataire; L’identification des interactions des acteurs avec le système consiste à l’identification des différents messages échangés par ces acteurs avec le système à développer. Les messages que nous avons identifiés après l’analyse des rôles des acteurs listés ci-dessus sont résumés dans le tableau de la page suivante :

Projet de Fin d’Etudes / ENSIAS 2004

21

Chapitre 3 : Analyse et spécification

Acteurs

Le responsable immédiat

Formateur régional Chef de circonscription

Message(s) émis par les acteurs La grille de compétences à remplir, la liste des opérations et des savoir-faire et la liste des agents d’une UO Les grilles de compétences et les plans internes de formation

Message(s) reçus par les acteurs La création, la modification et la suppression de grille et de plan interne La création, la modification et la suppression du plan régional de formation

Les grilles de compétences et les plans internes de formation Cadre du service de Le plan régional de formation La création, la modification formation et la suppression du plan national de formation Les plans régionaux de Les données de suivi et Fonctionnel de formation formation validés par les d’évaluation de la session formateurs régionaux de formation Système de gestion du Les estimations des coûts des La validation des budgétaire formations estimations des coûts de formation Système de gestion des Résultats de l’évaluation des profils et compétences formations Système de gestion des Les login et les mots de passe Habilitations Système de gestion La position de chaque UO organisationnel dans l’organigramme de l’ADII Système de gestion du Les données administratives personnel GIPE des participants Comité directeur Orientations générales Plan National validé Comité pédagogique Validations des programmes Programmes et plannings Tableau 2 : Liste des messages échangés entre le système et les acteurs

2.5. Diagrammes de contexte
Au cours de ce paragraphe nous procédons à une modélisation du contexte général du système sous formes de deux diagrammes de contexte selon deux vues différentes : « Vue Humaine » et « Vue Système », et ce afin de ne pas surcharger cette modélisation.

Projet de Fin d’Etudes / ENSIAS 2004

22

Chapitre 3 : Analyse et spécification

Vue Humaine

Figure 6 : Digramme de contexte : Vue Humaine Sur ce diagramme nous avons regroupé les différents acteurs humains et leurs interactions avec le système. Les acteurs potentiels sont le cadre de formation, le responsable immédiat et le formateur régional. • Vue Système

Figure 7 : Digramme de contexte : Vue Système
Projet de Fin d’Etudes / ENSIAS 2004

23

Chapitre 3 : Analyse et spécification

Ce deuxième diagramme de contexte, montre les interactions du système avec les autres modules du projet RIAD. Ces interactions permettent de concevoir les interfaces nécessaires à l’intégration du système au projet RIAD. Parmi les système qui figurent sur le diagramme ceux qui sont déjà mis en place à savoir : GIPE, Système des habilitations et le système de gestion des organisations. Les deux autres sont en cours de développement.

Conclusion
Au cours de ce chapitre, nous avons présenté les différentes fonctionnalités auxquelles doit répondre le système de gestion de la formation. Cela nous a permis par la suite d’identifier les différentes entités composant l’environnement d’interactions du système, à savoir : les acteurs humains, les acteurs systèmes et les messages échangés avec ces acteurs. Le chapitre suivant est consacré à la présentation de la phase de conception du système de gestion de la formation, et donc nous allons passer de l’étude de l’environnement externe du système à l’étude de sa structure interne.

Projet de Fin d’Etudes / ENSIAS 2004

24

Chapitre 4 : Conception de la solution

Chapitre4 :

Conception de la solution

Ce chapitre traite de la conception de la solution. Nous présentons la décomposition du système en sous modules. Ensuite, nous présentons le formalisme UML (Unified Modeling Language) adopté pour l’élaboration des diagrammes des différents packages issus de la décomposition suivi de l’architecture technique du système.

Introduction
« Diviser pour régner », c’est un principe appliqué presque partout. Cette fois, on le trouve très pratique lors de la conception du système de gestion de la formation. Vu la taille du système à développer, nous avons jugé très utile sa décomposition en sous modules à faible couplage afin de bien maîtriser les aspects de modélisation.

1. Décomposition du système
Après avoir élaborer les diagrammes de contexte (Vue humaine et système), le regroupement des messages et des interactions par catégories permet la décomposition du système selon les différentes phases du processus de gestion de la formation dans l’ADII à savoir : • Identification des besoins • Elaboration des plans de formation • Réalisation des actions de formation • Evaluation des formations Lors de cette décomposition en sous modules, nous nous sommes fixés l’objectif suivant : le flux d’échange entre les sous modules doit être minimale tout en répondant à la totalité des besoins identifié lors de la phase d’analyse des besoins. Ainsi, cet aspect de modularité n’était en aucun cas au détriment des fonctionnalités auxquelles le système doit répondre. Le schéma ci-après, présente la décomposition du système (les acteurs ne sont pas tous représentés pour ne pas surcharger le diagramme) :

Projet de Fin d’Etudes / ENSIAS 2004

25

Chapitre 4 : Conception de la solution

Figure 8 : Décomposition du système en sous modules Le Référentiel a pour but la mise en place des fonctionnalités d’archivage et de stockage de données importantes pour la gestion des formations à l’administration telles que les formateurs disponible sur le marché, les pôles de formation. Le sous-module Services Communs est conçu pour assurer les différentes fonctionnalités communes à tous les acteurs telles que les éditions et les consultations ainsi que l’accès aux données. Le sous module Interface permet à notre système de s’interfacer correctement avec les autres système des projet RIAD. Dans l’optique de concevoir un système extensible, évolutif, modulaire et orienté objet, le formalisme UML s’est imposé comme l’outil le plus approprié pour ce projet. En effet, UML permet de mener la phase d’analyse et de conception tout en bénéficiant de la puissance et de la simplicité de ses diagrammes.

2. Choix du formalisme UML
Rappelons-nous que la plate forme technique du projet RIAD se base sur l’architecture J2EE. C’est pourquoi nous avons opté pour UML comme langage de modélisation car la notation

Projet de Fin d’Etudes / ENSIAS 2004

26

Chapitre 4 : Conception de la solution

UML est la plus appropriée pour des projets orientés objet. Ce choix peut être justifié également par plusieurs raisons : • Le processus de développement adopté se base sur les diagrammes UML • La notation UML facilite la compréhension et la communication d’une modélisation objet ; • UML est aujourd’hui un standard, adopté par les grands constructeurs de logiciel du marché. Pour organiser le modèle de spécification fonctionnel d’une part et respecter la décomposition précédente d’autre part, nous avons opté pour l’utilisation des packages, qui représentent les besoins d’une entreprise vis-à-vis d’un système informatique.

3. Packages du système
Dans l’optique de s’aligner avec le choix du formalisme UML, les sous modules de la décomposition sont traduit en cinq packages essentiels à savoir : • Package grille • Package plan • Package action • Package évaluation • Package interface permettant de communiquer avec les autres systèmes. Dans la suite de ce chapitre, nous allons nous focaliser sur les quatre packages métier et essentiellement sur les composantes principales de chacun de ces packages. Pour mieux expliciter ces composantes, nous nous sommes appuyés sur la méthodologie suivante : 1. Elaboration du diagramme de cas d’utilisation (use cases) 2. Description textuelle de chaque cas d’utilisation : la fiche de description textuelle d’un cas d’utilisation n’est pas normalisée par UML. Nous préconisons pour notre part la structuration suivante : a. Sommaire d’identification (obligatoire) : inclut titre, but, résumé, dates, acteurs, responsables, version… b. Description des scénarios (obligatoire) : décrit les scénarios principaux et ceux secondaires, mais aussi les pré conditions et les post-conditions. c. Besoins d’IHM : ajoute éventuellement les contraintes d’interfaces hommemachine. 3. Identification des objets pour aboutir à un diagramme d’objets. 4. Etablissement des diagrammes des classes candidates à partir des diagrammes d’objets. 5. Elaboration des diagrammes de séquences des scénarios principaux.

3.1. Package grille
Ce package répond aux différentes fonctionnalités relatives à l’élaboration des grilles de compétences permettant l’identification des besoins en formation de l’administration. Après avoir analyser les fonctionnalités à ce package, nous constatons l’existence de trois cas d’utilisations à savoir : 1- Gestion des opérations ; 2- Gestion des savoir faire ; 3- Gestion des grilles.

Projet de Fin d’Etudes / ENSIAS 2004

27

Chapitre 4 : Conception de la solution

Le diagramme suivant montre les interactions entre les cas d’utilisation de ce package et les utilisateurs du système :

Figure 9 : Diagramme de cas d’utilisation du package « Grille » Les acteurs interagissant avec le système dans le cadre de ce package sont le responsable immédiat qui établit les grilles de compétences et le cadre de formation qui valide l’ajout de nouveaux savoir-faire et des opérations. Description du cas d’utilisation « Gestion des grilles de compétences » Sommaire d’identification : Gestion des grilles de compétences : Ce cas d’utilisation permet au responsable immédiat d’élaborer la grille de compétences de sa structure. Résumé : Création d’une nouvelle grille de compétence ainsi que la mise à jour de cette dernière. Acteurs : Responsable immédiat. Date de création : 19/02/2004 Date de mise à jour : 22/02/2004 Version : 1.0 Responsable : Omar BEL LAKHDAR Description des scénarios Pré condition : 1. Le responsable immédiat est authentifié. Enchaînement : Ce cas d’utilisation commence lorsque le responsable immédiat demande au système de créer, modifier ou supprimer une grille. Scénario principal : 1. Création d’une nouvelle grille Après diagnostic des compétences disponibles au sein de sa structure, le responsable immédiat fournit les informations du diagnostic à savoir: Titre But

Projet de Fin d’Etudes / ENSIAS 2004

28

Chapitre 4 : Conception de la solution

• •

Pour chaque agent, son degré de maîtrise d’une opération Son savoir-faire : maîtrise de certaines langues.

Une fois validée, le système calcule les deux indicateurs qui servent à l’élaboration des plans internes. Scénarios secondaires : 2. Mise à jour d’une grille Le responsable immédiat peut mettre à jour une grille sélectionnée tout en : enlevant une opération, un agent et/ou modifiant les compétences mentionnées dans la grille. 3. Suppression d’une grille Le responsable immédiat peut également supprimer une grille existante. Post condition La grille ne contient que les opérations effectuées au sein de la structure ainsi que les agents de cette dernière. Besoins d’IHM Le responsable immédiat doit pouvoir : a. Lister les opérations qui s’effectuent au sein de sa structure. b. Lister les agents de sa structure par ordre alphabétique ou autre. c. Lister les savoir-faire existants dans sa structure. Diagramme d’objets

Figure 10 : Diagramme d’objets du cas d’utilisation «Gestion des grilles » Ce diagramme montre qu’une fois une instance de grille est créée, il y a automatiquement création de plusieurs instances de « Savoir-faire », « Opération » et « Agent ».

Projet de Fin d’Etudes / ENSIAS 2004

29

Chapitre 4 : Conception de la solution

Diagramme de classes Pour ne pas surcharger le diagramme, nous avons opté à présenter les classes sans méthodes.

Figure 11 : Diagramme de classes du package « Grille » Sur ce diagramme figurent les classes candidates du package grille. La classe grille est une classe d’association entre les opérations et les agents car elle permet d’évaluer le degré de maîtrise effective des opérations par l’agent. Diagramme de séquence Nous allons présenter celui de la création d’une grille parce qu’il constitue le noyau de tout le package :

Projet de Fin d’Etudes / ENSIAS 2004

30

Chapitre 4 : Conception de la solution

Figure 12 : Diagramme de séquences du scénario « Création d’une grille » Sur ce diagramme, nous illustrons les différentes interactions entre les objets participant à la création d’une grille de compétences. La création des grilles de compétences déclenche la deuxième phase du processus de gestion de la formation qui est l’élaboration des plans. La partie suivante, montre la conception du package « Plan ».

3.2. Package plan
Ce package regroupe toutes les fonctionnalités visant à satisfaire le besoin de définir les actions de formation à entreprendre et à l’établissement des plans internes, régionaux et nationaux. Pour pouvoir gérer les différentes sortes de plans, nous identifions les trois cas d’utilisation suivants : 1. Gestion des plans internes ; 2. Gestion des plans régionaux ; 3. Gestion des plans nationaux. Le diagramme suivant montre les interactions entre les utilisateurs responsables de l’établissement des plans de formations et les cas d’utilisation de ce package :

Projet de Fin d’Etudes / ENSIAS 2004

31

Chapitre 4 : Conception de la solution

Figure 13 : Diagramme de cas d’utilisation du package « Plan » Les acteurs cette fois-ci sont : le responsable immédiat, le cadre de formation, le chef de circonscription et le formateur régional. Ces deux derniers jouent le même rôle et ce dans le cas où la circonscription est attachée directement à la direction centrale. Description de la «Gestion des plans régionaux» Sommaire d’identification Titre But : Gestion des plans régionaux. : Ce cas d’utilisation permet au responsable de formation (*) d’élaborer le plan régional de formation de la direction ou de la circonscription. Résumé : Création, mise à jour et suppression d’un plan régional. Acteurs : Responsable de formation (*) Directeur régional. Date de création : 19/02/2004 Date de mise à jour : 24/02/2004 Version : 1.0 Responsable : Omar BEL LAKHDAR (*) : Responsable régional est soit un formateur régional ou un chef de circonscription dans le cas où la circonscription est attachée directement à la direction centrale.

Projet de Fin d’Etudes / ENSIAS 2004

32

Chapitre 4 : Conception de la solution

Description des scénarios Pré condition : 1. Le responsable de formation est authentifié. 2. Les plans internes sont validés. Enchaînement : Ce cas d’utilisation commence lorsque le responsable de formation demande au système de créer, modifier ou supprimer un plan régional. Scénario principal : 1. Création d’un nouveau plan régional Le responsable de formation sélectionne les plans internes et élabore son plan régional en se basant sur le plan provisoire offert par le système. Il est appelé à fournir les informations nécessaires à la finalisation du plan régional. Une fois le plan est validé par le Directeur régional, une notification est envoyée au cadre de formation. Scénarios secondaires : 2. Mise à jour d’un plan Le responsable de formation peut mettre à jour un plan tout en le sélectionnant de la liste. 3. Suppression d’un plan Le responsable de formation peut également supprimer un plan existant. Post condition : Les formations qui figurent dans le plan régional peuvent être parmi celles des plans internes. Besoins d’IHM Le responsable de formation doit pouvoir : a. Lister les plans internes par structure. b. Lister tous les plans internes. c. Lister les plans régionaux pour la modification et la suppression. Diagramme d’objets Nous prenons comme exemple, celui du cas d’utilisation « gestion des plans régionaux » :

Figure 14 : Diagramme d’objets du cas d’utilisation « Gestion des plans régionaux »

Projet de Fin d’Etudes / ENSIAS 2004

33

Chapitre 4 : Conception de la solution

Ce diagramme sert de base pour l’implémentation du diagramme de classes suivant : Diagramme de classes

Figure 15 : Diagramme de classes candidates du package « Plan » Le diagramme de classe ci-dessus, illustre la structure du package « Plan ». Un plan de formation est composé d’une ou plusieurs formations dont chacune peut prendre en charge des axes de notes d’orientations générales.

Projet de Fin d’Etudes / ENSIAS 2004

34

Chapitre 4 : Conception de la solution

Diagramme de séquences

Figure 16 : Diagramme de séquences de « création de plan régional » Sur ce diagramme, s’illustre la séquence d’actions à entreprendre pour la création d’un plan régional de formation. Une fois les plans de formation sont élaborés, la programmation et la planification des actions de formation commencent. L’étude du package « Action » est l’objet de la partie suivante.

3.3. Package action
Ce package, comme l’indique son nom, vise à répondre au besoin de la programmation des actions ou sessions de formation. Les cas d’utilisation de ce package sont les suivants : 1. 2. 3. 4. 5. Gestion des formateurs ; Gestion des formations ; Gestion des participants ; Gestion des organismes de formation ; Planification des actions de formation ;

Le diagramme suivant montre les interactions entre les cas d’utilisation de ce package et les utilisateurs du système :

Projet de Fin d’Etudes / ENSIAS 2004

35

Chapitre 4 : Conception de la solution

Figure 17 : Diagramme de cas d’utilisation du package Action Les interactions entre les entités composant ce diagramme, permettent de mettre en place les programmes de mise en place des formations retenues dans les plans régionaux et national. Description de la « Planification d’une action de formation » Sommaire d’identification : Planification d’une action de formation : Mise en place d’un planning de réalisation d’une action de formation et affectation des ressources nécessaires à l’action de formation Résumé : Détermination du lieu et des dates de réalisation d’une action de formation ainsi que les formateurs qui vont assurer l’animation de cette action. Les moyens matériels nécessaires à la mise en place de l’action de formation doivent être réservés Acteurs : Responsable de formation Date de création : 19/02/2004 Date de mise à jour : 24/02/2004 Version : 1.0 Responsable : Abdellah Skal Titre But

Projet de Fin d’Etudes / ENSIAS 2004

36

Chapitre 4 : Conception de la solution

Description des scénarios Pré condition : 1. Le responsable de formation est authentifié 2. L’action de formation doit être prévue dans un plan de formation Enchaînement : Ce cas d’utilisation commence lorsque le responsable de formation demande la création, la modification ou la suppression d’un planning de réalisation d’une action de formation. Scénario principal : 1. Création d’un planning Le responsable de formation sélectionne une action de formation prévue dans un plan de formation puis crée un planning de réalisation de l’action. Dans le planning, il précise : a. le lieu de déroulement b. les dates de début et de fin c. l’heure de début et de fin de chaque séance et sa durée d. l’animateur de l’action… Scénarios secondaires : 2. Modification d’un planning Le responsable de formation sélectionne une action de formation et modifie les éléments figurant dans le planning de l’action de formation en modifiant un ou plusieurs des éléments cités dans la description du scénario précédent. 3. Suppression d’un planning Le responsable de formation sélectionne une action de formation et supprime son planning créé auparavant. Post condition ; Besoins d’IHM Afin de pouvoir créer, modifier ou supprimer un planning d’une action de formation, le responsable doit pouvoir sélectionner l’action dans une liste d’actions de formation. Il peut ordonner cette liste selon : a. Les plans de formation b. l’ordre alphabétique c. Autres critères à déterminer. Le responsable de formation doit pouvoir imprimer le planning de l’action de formation.

Projet de Fin d’Etudes / ENSIAS 2004

37

Chapitre 4 : Conception de la solution

Diagramme d’objets

Figure 18 : Diagramme d’objets de « Planification d’une action de formation» Les objets figurant sur ce diagramme sont des instances des classes constituant le diagramme de classes suivant :

Projet de Fin d’Etudes / ENSIAS 2004

38

Chapitre 4 : Conception de la solution

Diagrammes de classes

Figure 19 : Diagramme de classes candidates du package « action »

Projet de Fin d’Etudes / ENSIAS 2004

39

Chapitre 4 : Conception de la solution

Diagramme de séquences

Figure 20 : Diagramme de séquences de planification d’une session de formation Sur ce digramme nous trouvons la logistique nécessaire pour la mise en place d’une session de formation. Une fois les formations sont réalisées, alors la phase importante de l’évaluation commence. Lors de cette phase, les fiches résultantes des différentes sessions de formations sont synthétisées pour évaluer ces formations. La partie suivante montre la conception du package « Evaluation » qui prend en charge les fonctionnalités de cette phase.

3.4. Package évaluation
Le package « évaluation » se charge des différentes fonctionnalités permettant l’analyse des résultats de la phase de mise en place des actions de formation. Les cas d’utilisation de ce package sont les suivants : 1. 2. 3. 4. Gestion des fiches d’évaluation ; Gestion des fiches d’absences ; Gestion des fiches d’appréciation ; Elaboration du rapport d’évaluation.

Le diagramme suivant montre les interactions entre les cas d’utilisation de ce package et les utilisateurs participants à la réalisation de la phase d’évaluation des résultats :

Projet de Fin d’Etudes / ENSIAS 2004

40

Chapitre 4 : Conception de la solution

Figure 21 : Diagramme de cas d’utilisation du package Evaluation

D’après ce diagramme, il est clair que l’évaluation s’effectue essentiellement à base des fiches d’appréciation remplies par les participants aux formations, des fiches d’évaluation permettant le contrôle du niveau d’apprentissage des participants et des fiches de présences. La synthèse de ces fiches constitue le noyau du rapport d’évaluation qui est le fruit final de cette phase. Description du cas d’utilisation « Elaboration du rapport d’évaluation » Sommaire d’identification Titre But : Elaboration du rapport d’évaluation : Elaboration de la synthèse d’une formation ce qui permet l’évaluation de ses résultats. Résumé : Le rapport d’évaluation d’une formation est destiné à l’analyse des résultats d’une formation, en synthétisant les données des fiches d’évaluation et des fiches d’appréciation ainsi que les fiches d’absences. Date de mise à jour : 19/02/2004 Responsable : Abdellah Skal

Acteurs : Cadre de formation Date de création : 19/02/2004 Version : 1.0

Projet de Fin d’Etudes / ENSIAS 2004

41

Chapitre 4 : Conception de la solution

Description des scénarios Pré condition : 1. Le cadre de formation est authentifié Enchaînement : Ce cas d’utilisation commence lorsque le cadre de formation demande la création, la modification ou la suppression d’un rapport d’évaluation d’une formation. Scénario principal : 1. Création d’un rapport d’évaluation Le cadre de formation sélectionne un plan de formation et choisit une formation, puis crée un rapport d’évaluation de la formation. Scénarios secondaires : 2. Modification d’un rapport d’évaluation Le cadre de formation sélectionne un rapport d’évaluation et modifie son contenu. 3. Suppression d’un rapport d’évaluation Le cadre de formation sélectionne une formation et supprime son rapport d’évaluation. Post condition : 1. Le rapport à créer doit concerner une formation déjà réalisée Besoins d’IHM Le plan de formation est choisi à partir d’une liste de plans qui peut être ordonnée selon l’année pour laquelle le plan est élaboré. Lors de la création du rapport d’évaluation d’une formation, le cadre de formation doit pouvoir accéder directement aux fiches d’évaluation et d’appréciation.

Diagramme d’objets

Figure 22 : Diagramme d’objets de « Elaboration du rapport d’évaluation»
Projet de Fin d’Etudes / ENSIAS 2004

42

Chapitre 4 : Conception de la solution

Ce diagramme et ceux concernant les autres cas d’utilisation de ce package, constituent la base du digramme de classes suivant : Diagramme de classes candidates

Figure 23 : Diagramme de classes candidates du package «Evaluation» Ce diagramme traduit les relations entre les classes constituant le package « Evaluation ».

Projet de Fin d’Etudes / ENSIAS 2004

43

Chapitre 4 : Conception de la solution

Diagramme de séquences

Figure 24 : Diagramme de séquences de l’élaboration du rapport d’évaluation Ce dernier diagramme montre l’aspect dynamique des composants de ce package. En effet, il décrit les interactions entre les objets participant à l’élaboration du rapport d’évaluation d’une formation.

4. Architecture technique du système
Après avoir achevé la conception du système, nous avons mis en place l’architecture technique du système qui permet de le décomposer en plusieurs couches. Cette décomposition permet de maîtriser le développement du système. L’architecture technique du système que nous avons mis en place est schématisée comme suit :
Système de gestion de la formation

Client

Figure 25 : Architecture technique du système de gestion de la formation
Projet de Fin d’Etudes / ENSIAS 2004

44

Chapitre 4 : Conception de la solution

Cette architecture comporte cinq couches dont chacune a un rôle bien déterminé : • Couche Présentation : Elle regroupe les interfaces de l’application du système qui reçoivent les actions des utilisateurs ; • Couche Services : Cette couche traduit les scénarios identifiés lors de la phase de conception sous forme de services mis à disposition des utilisateurs ; • Couche Métier : Cette couche est constituée des objets métier identifiés lors de la phase de conception après l’élaboration des diagrammes de classes des différents packages ; • Couche Mapping et Persistance : Cette couche se charge de la persistance des objets et du mapping (association des objets avec les éléments de la BD relationnelle) ; • Couche Données : Cette dernière couche assure le stockage des données manipulées par les utilisateurs.

Conclusion
Dans ce chapitre, nous avons exploré les différents packages métiers qui ont été identifiés lors de la décomposition du système étudié et nous avons mis en place l’architecture technique du système de gestion de la formation. La conception présentée dans ce chapitre est la base de la phase de réalisation du système qui fera l’objet de la partie suivante.

Projet de Fin d’Etudes / ENSIAS 2004

45

Partie 3 : Mise en œuvre du projet et intégration dans RIAD

PARTIE 3 : MISE EN ŒUVRE DU PROJET ET INTEGRATION DANS RIAD

La dernière phase de du cycle de développement adopté est la réalisation du système et son intégration avec l’existant. Ainsi, cette partie est composée de deux chapitre : le premier passe en revue les différentes technologies et outils utilisés pour la réalisation, et établit des comparaisons entre ces technologies et outils et d’autres choix disponibles et concurrents. Le deuxième chapitre présente l’architecture applicative du système suivie par l’explication du déroulement des différentes étapes de la phase de réalisation. La dernière partie de ce chapitre est consacrée à la présentation des différentes interfaces permettant l’intégration du système dans le projet RIAD, et par la suite son déploiement.

Projet de Fin d’Etudes / ENSIAS 2004

46

Chapitre 5 : Technologies et outils utilisés

Chapitre5 :

Technologies et outils

utilisés

Compte tenu de la richesse de l’infrastructure support du projet RIAD, nous avons réservé le présent chapitre pour la présentation de cette infrastructure selon les axes suivants : l’architecture, les technologies, les modèles et les outils.

Introduction
L’infrastructure informatique mise à disposition par l’ADII pour la réalisation du projet RIAD, est basée sur l’architecture et les technologies J2EE. Ainsi, les frameworks et les Design Patterns open source en plus du pack Oracle9i AS sont les piliers de cette infrastructure.

1. L’architecture J2EE
Les entreprises recherchent, de plus en plus, des solutions qui permettent la diminution des coûts des applications et la réduction du temps de développement tout en respectant les standards de qualité logicielle. Typiquement, les applications qui répondent à ces besoins doivent combiner entre les systèmes d’information existants et les nouvelles fonctions métiers qui apportent des services à un large intervalle des utilisateurs. Ces services doivent assurer : • Une haute disponibilité, pour répondre aux besoins actuels de l’environnement métier ; • La sécurisation des applications et des données. • Une meilleure fiabilité, pour s’assurer que les transactions sont exécutées d’une manière exacte et prompte. Pour répondre à ces critères, ces services sont conçus à base d’applications multicouches reposant sur plusieurs niveaux à savoir la couche client, la couche donnée et plusieurs couches intermédiaires [wwwSUNJ2EE]. L’architecture J2EE (Java 2 Entreprise Edition) promue par SUN® MICROSYSTEMS définit et fournit un modèle de programmation multi tiers basé sur des composants. Avec ce modèle, des applications légères peuvent interagir facilement avec le système d'information et les composants implantant la logique d'entreprise sur des serveurs d'applications. L’architecture J2EE consiste en trois parties : • Components : les composants qui prennent en charge la présentation et la logique métier ; • Containers : fournit un contexte aux composants ; • Connectors : fournit l’accès aux sources de données de l’entreprise.

Projet de Fin d’Etudes / ENSIAS 2004

47

Chapitre 5 : Technologies et outils utilisés

2. Les technologies J2EE
Les technologies J2EE définissent la norme de développement des applications d’entreprise distribuées et multi tiers. Elles permettent de simplifier les applications d'entreprise en les basant sur des composants modulaires normalisés tout en fournissant un ensemble complet de services et en gérant automatiquement un grand nombre de détails sur le comportement des applications. Ces technologies qui sont regroupées en trois catégories : composant, service et communication [wwwSUNJ2EE]. Technologies de type composant Les technologies de type composant sont utilisées par les développeurs afin de créer des composants logiciels d’une application d’entreprise notamment l’interface utilisateur et la logique métier. Elles permettent de développer des modules réutilisables qui peuvent être intégrés dans d’autres applications. De plus, elles sont supportées par les services d’infrastructures de la plate-forme J2EE qui simplifient le développement des applications et permettent d’adapter les composants aux besoins des ressources de l’environnement de déploiement. Technologies de type service Etant donné que la plupart des applications d’entreprise ont besoin d’accéder aux systèmes d’information d’entreprise, la plate-forme J2EE offre un ensemble de services tels que l’accès aux bases de données (JDBC), nommage (JNDI), transaction et services de Messagerie. Technologies de type communication La plate-forme J2EE fournit un ensemble de technologies permettant la communication entre clients et serveurs, et entre les objets qui collaborent dans les différents serveurs, telles que les connecteurs aux systèmes d’information existants et l’invocation des méthodes distantes à travers RMI. Les technologies présentées ci-dessus peuvent être positionnées comme suit : Tools Application Programming Model

Container Messaging Mail

Applets

Java 2 SDK, Standard Edition CORBA RMI Database Naming/Directory

Figure 26 : Technologies J2EE

Connectors

Transactions JavaBeans

Projet de Fin d’Etudes / ENSIAS 2004

48

Chapitre 5 : Technologies et outils utilisés

3. Design Patterns MVC et MVC2
Comme nous l’avons signalé, l’infrastructure de RIAD intègre le Design Pattern MVC pour la conception des applications développées dans le cadre du projet RIAD. Dans cette partie, nous allons définir le terme Design Pattern avant de procéder à une comparaison entre les deux Design Patterns : MVC et MVC2 suivant lequel nous avons conçu le système de gestion de la formation. Un Design Pattern donne un nom, isole et identifie les principes fondamentaux d'une structure générale, pour en faire un moyen utile à l'élaboration d'une conception orientée objet réutilisable [GAMMA95]. Ce type de Patterns, également appelés Patterns de conception orientés objet, sont les Patterns les plus utilisés. Trois catégories des Design Patterns sont définies [wwwECKEL]: les patterns de création, les patterns structuraux et les patterns de comportement (Annexe 4). Le modèle MVC est un type de Design Patterns de la catégorie « Patterns structuraux ». Il est simple mais en même temps très utile, il permet essentiellement de concevoir une application en utilisant les trois niveaux suivants : • MODEL : c’est le noyau de l’application. Il maintient l’état et les données que l’application représente. Quand des changements significatifs apparaîtront dans le modèle, les vues aussi seront changées ; • CONTROLLER : il définit le comportement de l’application et gère l’interaction avec l’utilisateur. Il fait appel au modèle des composants pour répondre aux requêtes de l’utilisateur • VIEW : l’interface utilisateur qui est la représentation visuelle du « modèle ».
Servlet JSPs Servlet JSPs Servlet JSPs

Application Web

Contrôleur

Modèle

NAVIGATEUR

Classes Métiers

BD, fichiers

Vue

Figure 27 : Modèle MVC Cette architecture qui sépare le contrôle des actions utilisateurs, la couche métier et la couche de présentation favorise le développement et la maintenance d'une application. Malgré cet apport, il présente un inconvénient majeur : la multiplication des points d'entrée (pages JSP et servlet) dans l'application. La mise en place de services comme la sécurité, l'internationalisation, ou la personnalisation devient alors complexe avec cette architecture. Le modèle MVC 2 propose de palier à cet inconvénient en utilisant un seul point d’entrée pour chaque application. Ainsi, une application contient un seul contrôleur frontal sous la forme d'un servlet d'entrée unique.
Projet de Fin d’Etudes / ENSIAS 2004

49

Chapitre 5 : Technologies et outils utilisés

Le modèle ci dessus devient ainsi comme suit :
Servlet Frontal niq e

Application Web

Contrôleur

Modèle

NAVIGATEUR
JSPs JSPs

Classes Métiers

BD, fichiers

Vue JSPs

Figure 28 : Modèle MVC2 C'est sur ce modèle que plusieurs frameworks sont conçus afin d'aider les développeurs à construire la couche de présentation de leur applications web. Dans la communauté java, c'est le projet Jakarta Struts qui fait référence

4. Framework « Struts »
Un framework est un ensemble d'outils et de composants qui aident au développement d'application, pour un contexte donné. Cela inclut : • Un ensemble de Design Patterns ; • Un ensemble d’interfaces et d’implémentations ; • Des outils associés.

4.1. Choix du framework Struts
Pour remédier aux inconvénients du modèle MVC, nous avons proposé au comité de pilotage du projet RIAD de concevoir le système de gestion de la formation selon le modèle MVC2. La proposition a été retenue et nous avons choisi de bénéficier des atouts du framework Struts qui seront listés dans cette partie. Le projet Struts est géré au sein de la communauté « Apache Software Foundation » dans le cadre des projets « Jakarta ». La motivation de ce projet est de fournir à la communauté Java un framework basé sur le design pattern MVC2 tout en utilisant les technologies J2EE standards : JSP/Servlet, JavaBean, XML. Cependant, Struts n‘est pas le seul framework permettant la gestion de la couche présentation. En effet, d’autres frameworks ont été conçus pour le même objectif, tels que Barracuda, Hammock, Tapestry et Webwork. L'apport le plus significatif de Struts est la structuration de la couche de présentation des applications Internet/Intranet suivant le pattern MVC2. Le développeur est bien mieux guidé dans sa tâche. En général, il lui suffit de personnaliser les actions pour les traitements adéquats des requêtes. Il en découle un développement plus efficace mais également une meilleure homogénéisation du code des applications.

Projet de Fin d’Etudes / ENSIAS 2004

50

Chapitre 5 : Technologies et outils utilisés

Le tableau suivant résume une comparaison entre plusieurs frameworks MVC2 [wwwAS] : Framwork Version Barracuda Hammock Tapestry Webwork Struts PR2 1.0 0.2.9 0.95 1.1 URL
http://barracuda.enhydra.org/ http://www.oop.com/TechnologiesHammock.jsp http://sourceforge.net/projects/tapestry http://sourceforge.net/projects/webwork/ http://jakarta.apache.org/struts

Puissance Complexité +++ +++ ++ + +++ +++ +++ +++ + ++

Tableau 3 : Comparaison de quelques frameworks en terme de puissance et de complexité Ainsi, l’atout principal qui fait la force de Struts est la complexité réduite par rapport aux autres Frmework de même degré de puissance. Le manque d'expertise technique sur les technologies web de Java n'est plus un frein pour aboutir à une application robuste, évolutive et maintenable : on peut utiliser Struts pour la couche de présentation avec un niveau d'expertise minime.

4.2. Architecture et fonctionnement du framework Struts
La structure du framework Struts découle du modèle MVC2 (cf. la figure 28). Selon ce modèle, on retrouve dans Struts un contrôleur, des vues et l'accès au modèle. Contrôleur Le contrôleur du framework Struts est chargé de faire le lien entre la vue et le modèle. Il réceptionne toutes les requêtes clientes et les redirige vers des actions spécifiques. Ces correspondances (mapping) sont décrites dans un fichier de configuration « strutsconfig.xml ». Le contrôleur principal est matérialisé par un unique servlet offert par le framework : « ActionServlet ». Les autres actions sont des modules actions construits à partir de classes Struts « Action ». Chaque action accède au modèle pour récupérer les données nécessaires au traitement de la requête cliente. La centralisation des accès à l’application permet un contrôle fin et personnalisé des traitements des requêtes. La gestion de la navigation est déclarative et n’est pas figée dans le code java. Cette solution est très flexible. Vue La vue est un ensemble de pages JSP. Afin de faciliter leur construction, le framework struts propose plusieurs librairies de "tag" (ou balise). Un tag permet de séparer le code java du rendu de la page. L'écriture du tag repose sur deux composants : les classes de gestion de tag et le fichier de description des tags. Les tags peuvent ensuite être utilisés dans les JSPs. On évite ainsi la présence de code java au sein même de la page JSP. Aujourd'hui, Struts 1.1 intègre quatre bibliothèques de tags : • La librairie de tag « Bean » pour la manipulation des beans ; • La librairie de tag « Html »pour la création et la manipulation des formulaires html ; • La librairie de tag « logic » pour mettre en œuvre des traitements conditionnels et itératifs ; • La librairie de tag « Template » pour la création et la gestion de modèles.
Projet de Fin d’Etudes / ENSIAS 2004

51

Chapitre 5 : Technologies et outils utilisés

Modèle Suivant le pattern MVC2, le modèle est indépendant du contrôleur. Le framework Struts n'en impose aucun. Le choix technologique incombe au développeur (JDBC, EJB, JDO, XML, Composant métier maison ...) suivant ses besoins.
Serveur d’application Framework Struts

Contrôleur
1

2

1
7

Action servlet
6 5

3 Action Action Action

Modèle EJB, CORBA, JDO, JDBC, XML,…

4

Vue
Navigateur JSP JSP JSP

Struts-config.xml

Figure 29 : Principe de fonctionnement du framework Struts L'interaction entre les trois composants est orchestrée par le contrôleur principal. Afin de mieux comprendre le fonctionnement du framework, on détaille le cycle de vie d'une requête HTTP, schématisé dans la figure 29 : 1. Le client envoie sa requête HTTP à l'application. Cette requête est prise en charge par le contrôleur principal, en l'occurrence ActionServlet; 2. La requête est redirigée vers le contrôleur adéquat; 3. Le contrôleur choisi prend en charge le traitement de la requête. Un dialogue avec les services métiers est entamé si nécessaire; 4. Le modèle fournit les données demandées; 5. Le contrôleur principal est notifié du résultat du traitement. En cas de succès, les données sont encapsulées dans des JavaBean (ActionForm) et transmis à la JSP sélectionnée par le contrôleur; 6. La JSP construit la réponse suivant les données transmises; 7. La réponse est envoyée au navigateur.

5. Framework « TopLink »
5.1. La problématique de la persistance objet
Si le modèle objet offre des capacités de modélisation et d’abstraction avancées, il est en revanche handicapé par une grave limitation : il se focalise exclusivement sur les aspects dynamiques de l’exécution des programmes, sans couvrir réellement la problématique de la persistance des objets.

Projet de Fin d’Etudes / ENSIAS 2004

52

Chapitre 5 : Technologies et outils utilisés

Par contraste, dans le modèle relationnel, les données sont persistantes : une fois que la structure du schéma relationnel a été définie, les données qui y sont ajoutées restent accessibles durablement, tant qu’elles ne sont pas explicitement supprimées. La durée de vie des données est donc totalement indépendante du cycle de vie des sessions applicatives qui les manipulent. Pour apporter ce caractère de durabilité des données au modèle objet, il convient donc de trouver un moyen de prolonger l’existence des objets au-delà de l’existence d’une session applicative. Pour désigner cette capacité des objets à survivre en dehors du contexte d’exécution applicatif, on parle de persistance objet. La problématique de la persistance objet consiste donc à élaborer et à mettre en œuvre les mécanismes permettant de sauvegarder de façon fiable et durable l’état des objets manipulés par une application. Techniquement, il existe plusieurs approches pour implémenter la persistance objet [SQLI03]: • sérialisation : La sérialisation consiste à sauvegarder l’état (les valeurs d’attributs) d’un objet comme un flux d’information unidimensionnel (sériel) dans un fichier texte (fichiers XML par exemple) ou binaires (fichiers binaires). • mapping objet/relationnel : cette technique vise à définir et utiliser un schéma en base de données relationnelle pour assurer la persistance de l’état des objets. Elle consiste à définir précisément la structure d’une ou plusieurs tables qui seront utilisées pour sauvegarder les différents attributs d’un objet. • persistance en base de données objet : le problème de la persistance objet a donné lieu au développement d’un nouveau type de bases de données : les bases de données orientées objet. Contrairement aux bases de données relationnelles qui emploient des structures bidimensionnelles (les tables), les bases de données objet utilisent les mêmes représentations que les objets : des structures hiérarchiques (graphes). Il est également nécessaire d’implémenter la logique de persistance qui va permettre aux applications d’effectuer la sauvegarde et la restauration de l’état des objets manipulés. C’est le rôle de la couche de persistance (ou moteur de persistance). Le moteur de persistance expose une API aux applications pour la création, la mise à jour, et la recherche d’objets sur le support de persistance. A ce moteur de persistance, il est également nécessaire d’associer un outil de projection des objets sur le support de persistance : le rôle de cet outil est de fournir le moyen de définir les règles de transformation entre la représentation des objets en mémoire et la représentation de ces objets sur le support de persistance, avec la création des structures de données nécessaires. La persistance objet est donc une problématique très complexe, qui nécessite la mise en œuvre d’outils spécifiques et sophistiqués. Parmi ces outils, on trouve Oracle9iAS TopLink qui représente la solution la plus mature sur le marché (Annexe 5).

5.2. La solution « Oracle9iAS TopLink »
Oracle9iAS TopLink est un produit dont le noyau est le framework TopLink éprouvé en matière de persistance de modèles objets complexes en base relationnelle, et adoptant l’approche de persistance : mapping objet/relationnel. Oracle9iAS TopLink relève la problématique de persistance en établissant un lien entre les technologies orientées objet et relationnelles, ce qui permet aux applications de stocker et

Projet de Fin d’Etudes / ENSIAS 2004

53

Chapitre 5 : Technologies et outils utilisés

d’extraire des objets Java de manière transparente à l’aide d’une base de données relationnelle ou d’autres systèmes de stockage. Oracle9iAS TopLink permet aux applications Java d’accéder aux données stockées dans des bases de données relationnelles en tant qu’objets. Les développeurs d’applications peuvent travailler avec des bases de données relationnelles comme ils le feraient avec n’importe quelle application Java, indépendamment de la persistance. Oracle9iAS TopLink permet aux développeurs de se concentrer sur l’application et le modèle d’objet, plutôt que sur l’infrastructure de la base de données. Oracle9iAS TopLink peut lier des objets Java à une base de données existante (héritée) ou suggérer un nouveau schéma de base de données à partir d’un modèle d’objet (ou vice versa).Cette solution fournit un jeu de fonctionnalités étendu pour lire, écrire, supprimer et gérer efficacement les objets. Oracle9iAS TopLink ne remplace pas JDBC, mais l’utilise efficacement et isole les développeurs de ses détails. Les développeurs d’applications travaillent uniquement en langage Java avec des objets via Oracle9iAS TopLink, et non avec des lignes relationnelles et le langage SQL via des appels JDBC.

Figure 30 : Composantes principales du framework TopLink Oracle9i AS TopLink crée un ensemble de «descripteurs de mapping » (Annexe 5), ou méta données, qui définissent le mode de stockage des objets dans un schéma de base de données particulier. Oracle9iAS TopLink utilise ces descripteurs lors de l’exécution pour générer de façon dynamique les déclarations SQL requises. Les descripteurs peuvent être modifiés sans qu’il soit nécessaire de recompiler les classes qu’ils représentent. Aucune programmation SQL n’est requise. Les descripteurs de méta donnés sont indépendants du langage et de la base de données.

6. Oracle 9i Application Server
Un serveur d’applications reprend la même logique du serveur de fichiers, et applique cette logique aux applications qu’il héberge. Ainsi, les applications déployées dans un serveur
Projet de Fin d’Etudes / ENSIAS 2004

54

Chapitre 5 : Technologies et outils utilisés

d’applications deviennent disponibles pour les utilisateurs demandant l’exécution de ces applications. D’autres fonctionnalités sont offertes par les serveurs d’applications telles que la sécurité et la tolérance aux pannes. Dans l’ADII, le serveur d’applications utilisé pour le déploiement des applications du projet RIAD, est le serveur d’application d’Oracle : Oracle 9i Application Server. Oracle9iAS est une plate-forme très fiable dédiée au déploiement d’applications Internet/Intranet. Ce serveur d’applications comprend des environnements J2EE et Web Services très bien optimisés; une excellente évolutivité sur un ou plusieurs processeurs; plusieurs fonctions de haute disponibilité telles que la tolérance aux pannes, le clustering, les mises à jour et la maintenance en ligne; l’administration centralisée des systèmes et de la sécurité pour les applications Internet et les utilisateurs. Il est conçu pour réduire le coût total d’exploitation associé au développement, au déploiement et à l’utilisation des applications. Oracle9iAS, permet de : • développer et déployer des sites Web Internet/Intranet dynamiques, des applications J2EE et des Web Services ; • créer des portails personnalisés ; • rendre les sites et les applications accessibles depuis les navigateurs traditionnels et les terminaux mobiles ; • émettre des recommandations personnalisées en temps réel, analyser les journaux de flux de clics et extraire des informations de type Business Intelligence du trafic sur le Web ; • intégrer les applications, sources de données et partenaires commerciaux existants au sein d’une infrastructure e-business commune ; • redimensionner les sites Web et applications à mesure que l’entreprise se développe ; • administrer et sécuriser l’ensemble de l’infrastructure Web.

7. Environnement de développement JDeveloper 10g
JDeveloper 10g est un environnement de développement gratuit d’Oracle, adoptant les technologies J2EE. Il permet le développement de plusieurs types d’applications, et intègre plusieurs frameworks, en particulier, les deux que nous avons utilisé : Struts et TopLink.

Conclusion
Au cours de ce chapitre, nous avons présenté les différentes technologies et outils que nous avons mis en œuvre pour la réalisation du système de gestion de la formation de l’ADII. Dans le chapitre suivant, nous présentons l’architecture applicative du système, ainsi que l’implémentation de chacune des couches de cette architecture tout en utilisant les différents outils présentés ci-dessus.

Projet de Fin d’Etudes / ENSIAS 2004

55

Chapitre 6 : Mise en oeuvre

Chapitre6 :

Mise en œuvre de la solution et intégration dans RIAD

Ce chapitre a pour but la description de la phase de mise en œuvre de la solution. Nous présentons d’abord l’architecture applicative du système et détaillons ensuite les deux dernières phases du cycle de développement suivi : la réalisation et l’ intégration.

Introduction
La mise en place l’architecture technique et le choix des outils de travail présentés dans le chapitre précédant, nous ont permis de mettre en place l’architecture applicative du système de gestion de la formation. L’implémentation de cette architecture est le fruit de la phase de réalisation. La phase des tests permet de vérifier la validité du système, avant d’entamer la phase d’intégration avec les autres modules du projet RIAD.

1. Architecture Applicative
L’architecture applicative comporte les différentes couches applicatives du système, et associe à chaque couche l’outil de réalisation adéquat. Afin de bien maîtriser le développement du système, l’architecture applicative du système de gestion de la formation a été décomposée en cinq couches : • • • • • couche Présentation ; couche Services ; couche Métier ; couche Mapping et persistance ; couche Données ;

Le schéma suivant montre l’architecture applicative finale du système :

Projet de Fin d’Etudes / ENSIAS 2004

56

Chapitre 6 : Mise en oeuvre

Struts sous Jdeveloper10g Couche Présentation (JSP) Oracle9iAS TopLink Couche Services (Actions)

PowerAMC 9 Couche Métier (Packages & Beans)

Couche Mapping et persistance (Chaine de connexion et Descripteurs de tables) SGBD Oracle9i Couche Données (Base de données relationnelle)

Figure 31 : Architecture applicative du système de gestion de formation Ce schéma, associe à chaque couche l’outil utilisé pour son implémentation. Ces couches ont été développées dans l’ordre donné au début de ce paragraphe.

2. Réalisation des couches applicatives
2.1. La couche Données
Cette couche comporte le schéma de la base de données du système de gestion de la formation. Le script de ce schéma a été généré automatiquement par PowerAMC9, que nous avons utilisé pour élaborer le diagramme de classe pendant la phase de développement. Ce script a été exécuté sur le serveur de base de données RIADDB, en utilisant SQL Navigator4 qui sert à l’administration des bases de données.

2.2. La couche Métier
Cette deuxième couche comporte les beans des différents packages métier du système. Ces beans sont les implémentations des classes métier du système. Ils ont été générés automatiquement aussi par Power AMC9 à partir du digramme de classe élaboré précédemment. L’arborescence des packages métiers est la suivante :

Projet de Fin d’Etudes / ENSIAS 2004

57

Chapitre 6 : Mise en oeuvre

Figure 32 : Arborescence des packages métier Chaque package de l’arborescence comporte les beans correspondant aux classes lui appartenant. Ces beans sont appelés par les composants de la couche Services pour répondre aux requêtes des utilisateurs.

2.3. La couche Mapping et persistance
Cette couche se charge de la persistance des objets métier manipulés par les services. En effet, dans cette couche se compose des descripteurs (fichiers XML) des classes métier et des tables associées à ces classes dans la base de données. Le mapping des classes vers les tables de la base de données se fait à travers l’interface graphique WorkBench de Oracle9iAS TopLink représentée par la figure suivante :

Projet de Fin d’Etudes / ENSIAS 2004

58

Chapitre 6 : Mise en oeuvre

Figure 33 : Outil de mapping des classes vers les tables de la BD A travers cette interface graphique, on associe à chaque classe sa table correspondante, ainsi que les différentes relations entre les classes. Une fois le maping est terminé, alors on génère le code XML ou JAVA correspondant au projet de mapping achevé afin d’exécuter les fonctions de persistance. Dans notre cas, nous avons choisi de générer le code JAVA pour optimiser le temps d’exécution de l’application. En effet, le code XML que génère WorkBench est transformé en code JAVA avant d’être utilisé dans un environnement JDevelopper.

2.4. La couche Présentation
Cette couche concerne les interfaces Homme-Machine que nous avons développé en utilisant JSP et les Taglibs du framework Struts. A chacune de ces interfaces est associée une classe ActionForm permettant de passer les paramètres de l’interface à l’Action (Service).Cette opération se fait par le contrôleur « ActionServlet ». Un exemple d’interface est représenté par la figure suivante :

Projet de Fin d’Etudes / ENSIAS 2004

59

Chapitre 6 : Mise en oeuvre

Figure 34 : Page d’accueil du système de gestion de formation Cette page contient le menu principal du système permettant d’accéder aux différents services disponibles. Une présentation de la politique de formation de l’ADII figure aussi sur la même page. Ainsi, la dernière couche à implémenter est la couche Services.

2.5. La couche Services
Comme l’indique son nom, cette couche comporte les services offerts par le système à l’utilisateur. Ces services ne sont autres que l’implémentation des scénarios identifiés lors de la phase de conception. Leur rôle consiste à répondre aux requêtes des utilisateurs qui sont transmises par l’ActionServlet qui est le contrôleur frontal du système. Lors de l’appel d’un service, ce dernier fait appel aux objets métier nécessaire pour répondre à la requête de l’utilisateur.

3. Intégration dans le projet RIAD
Comme nous l’avons annoncé, et pour achever la mise en place du système de gestion de la formation, il nous reste encore deux étapes : l’interfaçage avec les autres module de RIAD et le déploiement.

Projet de Fin d’Etudes / ENSIAS 2004

60

Chapitre 6 : Mise en oeuvre

3.1 Interfaçage avec les autres applications de RIAD
Les systèmes avec lesquels notre système doit s’interfacer sont ceux qui figurent sur le diagramme de contexte (Vue système) élaboré lors de la phase de l’analyse. Ces interfaces sont les suivantes : • Interface avec le système des habilitations : cette interface a été mise en place du coté du système de gestion des habilitations. Elle s’appuie sur une matrice de privilèges constituée des différents rôles que nous avons identifiés lors de l’analyse, et des différents services offerts par le système des gestion des de la formation. Cette matrice associe chaque rôle aux services accessibles pour lui ; • Interface avec le progiciel GIPE : Cette interface est implémentée par la classe « Agent » du package « Grille ». En effet, cette classe a été mappée vers la table Agent du progiciel GIPE. Ce mapping rend les données administratives du personnel de l’ADII, gérées par le GIPE, accessible en lecture pour le système de gestion de la formation. L’option « lecture seule » a été choisie pour interdire aux utilisateurs de notre système d’agir en écriture sur ces données ; • Interface avec le système des organisations : l’interfaçage avec le système de gestion des organisations a été réalisé de la même façon qu’avec GIPE. Cette fois, la classe « Organisation » du package « Grille » a été mappée vers la table « Organisation » du système de gestion des organisations. Ce mapping a été fait toujours avec l’option « lecture seule » ; • Interface avec le système de gestion budgétaire : Cette interface doit être mise en place du côté du système de gestion budgétaire qui est en cours de réalisation. Cette interface doit permettre au système de gestion budgétaire l’accès aux coûts des formations réalisées par l’ADII. Ces coûts sont gérés par le système de gestion des formations ; • Interface avec le système de gestion des profils et compétences : Cette dernière interface doit être aussi mise en place par le système de gestion des profils et des compétences qui n’est pas encore réalisé. Le rôle de cette interface consiste en l’alimentation du référentiel des compétences par les nouvelles compétences acquises par les participants aux formations réalisées par l’ADII.

Conclusion
Dans ce chapitre nous avons présenté la dernière phase du cycle de développement du système de gestion de la formation. Cette phase a été décomposée en deux sous phases principales : la réalisation et l’intégration du système dans le système d’information de l’ADII.

Projet de Fin d’Etudes / ENSIAS 2004

61

Conclusion et Perspectives

Conclusion et Perspectives
Nous avons pu découvrir, à travers ce projet, une nouvelle approche qui facilite grandement le développement d’applications web. En effet, l’intégration des frameworks dans le développement d’applications réduit considérablement le coût de développement, grâce notamment à leur qualité d’être paramétrable. Notre travail a consisté, dans un premier temps, en l’étude et l’analyse de la politique de formation continue dans l’ADII. Dans un second temps, nous avons modélisé le processus de gestion de la formation qui est l’axe principal de cette politique de formation. L’analyse des besoins des utilisateurs, la conception, la réalisation et l’intégration du système de gestion de la formation dans le projet RIAD, ont été les phases du cycle de développement de notre projet. Au cours de la période de notre projet de fin d’études, nous avons eu l’opportunité de mettre en application les différentes connaissances acquises durant notre formation à l’ENSIAS. De plus, nous avons eu l’occasion d’acquérir de nouveaux concepts, à savoir : la technologie J2EE, les Design Patterns ainsi que l’utilisation des frameworks Struts et TopLink. Ce stage a été également l’occasion de découvrir le dynamisme et l’enthousiasme qui caractérisent l’équipe RIAD. Les réunions régulières effectuées avec les encadrants à l’ADII nous ont permis de mettre en œuvre les concepts de gestion de projets acquis à l’ENSIAS. Les difficultés majeures que nous avons rencontrées durant ce projet résident essentiellement dans la nouveauté du framework Open Source Struts, qui manque énormément de documentation. Enfin, nous précisons que la conception effectuée garantira l’extensibilité du système développé et permettra à l’ADII d’ajouter d’autres services pour réponde aux futurs besoins. Par exemple, le système peut être doté d’un outil aidant les décideurs de l’administration à mieux appréhender et répondre aux besoins en formation.

Projet de Fin d’Etudes / ENSIAS 2004

62

Bibliographie

Bibliographie
Ouvrages
[CORCA01] [BORUJA98] [ROVA00] [LAI97] [GAMMA95] [HUSTED03] [SQLI03] Corine Cauvert et al. : Ingénierie des Systèmes d’Information. 2001 Grady Booch, James Rumbaugh, Ivar Jacobson : Le Guide de l’Utilisateur UML. 1998. Pascal Roques, Frank Vallée : UML en Action. 2000 Michel LAI, UML la notation unifiée de modélisation objet, Édition InterEdition, 1997 E. Gamma et al., Design Patterns: Elements of Reusable Object Oriented Software,Addison-Wesley Professional Computing Series. 1995. Ted Husted et al. : Struts in Action. 2003 Groupe SQLI : Maîtriser la persistance objet métier au sein d’une architecture J2EE. 2003.

Adresses Internet
[wwwAPACHE] [wwwAS] [wwwONJAVA] [wwwECKEL] [wwwLEA] http://www.apache.org Site de la fondation Apache pour le développement des logiciels Open Source http://www.application-servers.com http://www.onjava.com (Introduction to Jakarta Struts framework) http://www.mindview.net/Books/TIPatterns/; Bruce ECKEL (Thinking in Patterns with Java) http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html D. Lea, Patterns Discussion FAQ. http://www.psgroup.com A. THOMAS, Java 2 Platforme Entreprise Edition http://www-106.ibm.com/developerworks/java/ (Manage complexity in large Web sites with this servlets and JSP framework) http://www.mycgiserver.com

[wwwTHOMAS]

[wwwIBM] [wwwMyCGI]

Projet de Fin d’Etudes / ENSIAS 2004

63

Bibliographie (Développement Web Java avec Struts 1.0) [wwwSTRUTS] [wwwSUNJ2EE] http://jakarta.apache.org/struts/ Site du projet Open Source Struts http://Java.sun.com/J2EE Simplified Guide to the J2EE, Sun Microsystems

Projet de Fin d’Etudes / ENSIAS 2004

64

Annexes

ANNEXES

Projet de Fin d’Etudes / ENSIAS 2004

65

Annexe1 : Plan Assurance Qualité

Annexe 1 :

Plan d’Assurance Qualité

1. Objectifs du plan Le présent Plan d’Assurance Qualité précise les éléments permettant de s'assurer de la mise en œuvre et de l'efficacité des activités prévues dans le cadre du projet. Il expose notamment : La description du projet ; L’organisation du projet ; Le planning détaillé du déroulement du projet ; La liste des livrables ; Les critères d’acceptation et contrôles qualité. 2. Description du projet Afin d’assurer la polyvalence des agents et d’atténuer la vulnérabilité des structures composants l’administration des douanes d’une part, et d’accompagner la politique de redéploiement du personnel d’autre part, l’administration opte pour une politique de régionalisation de la formation en se basant sur un méthode scientifique permettant d’extraire les besoins en formation. Ces besoins sont répertories dans trois types de plans : plans internes, plans régionaux et plan nationaux de formation. Ainsi notre projet consiste à l’automatisation de ce processus tout en gérant les différentes composantes de ce processus, à savoir :

La gestion des grilles de compétences qui nécessite à son tour la gestion des opérations des structures. La gestion ainsi que l’élaboration de tous les types de plan de formation. La programmation des actions de formations retenues dans les plans de formation
Elaboration du rapport d’évaluation 3. Rôles et responsabilités L’organisation du projet est la suivante : • Côté Administration du Douanes et Impôts Indirects :

Personne
Youssef EL MAZOURI Mourad ZEKRAOUI Mohamed LAHLOU Zouhair FADIL

Rôle

Chef du service de la formation

Tableau 4 : Les participants au projet côté ADII Côté ENSIAS :

Personne
Bouchra BERRADA Abdellah SKAL Omar BEL LAKHDAR

Rôle
Professeur Encadrant Stagiaire élève ingénieur Stagiaire élève ingénieur

Tableau 5 : Les participants au projet côté ENSIAS
Projet de Fin d’Etudes / ENSIAS 2004

66

Annexe1 : Plan Assurance Qualité

D’autre part, les comités qui seront constitués sont : Le comité de pilotage : a pour mission de suivre la progression du projet par rapport au planning déjà établi, de modifier le PAQ, de prendre, proposer des décisions correctives ou mettre en place des ajustements. Ce comité sera composé des personnes suivantes :

Personne
ENSIAS Mme Bouchra BERRADA ADII Mr. Youssef EL MAZOURI Mr. Mourad ZEKRAOUI Mr. Mohamed LAHLOU Mr. Zouhair FADIL Tableau 6 : Membres du comité de pilotage Le comité de projet : a pour mission de suivre de près l’avancement du projet et de concevoir, développer et de déployer le projet. Ce comité aura également pour rôle de préparer les réunions de pilotage et sera composé de personnes suivantes :

Personne
ENSIAS Abdellah SKAL Omar BEL LAKHDAR Tableau 7 : Membres du comité de projet 4. Organisation des Réunions Chaque réunion sera verbalisée par un compte rendu synthétisant l’état d’avancement du projet et tous les points et décisions prises. Ce compte rendu sera envoyé aux encadrants et stagiaires concernés par le projet. Périodicité : les réunions seront effectuées vers la fin de chaque phase du développement. Objectifs : • Définir les objectifs à réaliser pour prochaine phase ; • Procéder à l’évaluation de l’état d’avancement pour chacune des ressources ainsi que le niveau de réalisation des objectifs prédéfinis ; • Identifier les problèmes rencontrés et apporter les solutions qui s’imposent ; • Assurer la coordination des différentes structures et le suivi opérationnel du projet ; • Réajuster la planification en cas de nécessité. 5. Planning du projet Dans ce qui suit, le planning détaillé du déroulement du projet.

Projet de Fin d’Etudes / ENSIAS 2004

67

Annexe 1 : Plan Assurance Qualité

Figure 35 : Planning détaillé du déroulement du projet

Projet de Fin d’Etudes / ENSIAS 2004

68

Annexe1 : Plan Assurance Qualité

6. Plan de livrable Afin d’assurer une bonne qualité du produit qui va être réalisé par ce projet, chaque phase du projet va être jalonnée par un livrable comme il est indiqué ci-dessous :

Nom de la phase Lancement Analyse des besoins Conception Elaboration de la solution Application de validation de l’approche.

Livrable Plan Assurance Qualité Cahier des charges utilisateur Cahier des charges fonctionnel Dossier de conception générale Dossier de conception détaillée Implémentation et tests Présentation + Rapport

Tableau 8 : Les livrables par phase

Projet de Fin d’Etudes / ENSIAS 2004

69

Annexe2 : Grille de compétences

Annexe 2 :
Activités
OPERATIONS EXISTANTES DE GESTION -SECURITE Liquidation des droits et taxes et ordonnancement Décharge des acquits a caution Établissement et gestion des actes contentieux Prise en charge des mains levées Partielles

Grille de Compétences
SAVOIR-FAIRE EXISTANTS

DANS L’ORGANISATION, EN DEBUT DE PERIODE

DE GESTION DEVELOPPEMENT Rédaction administrative en arabe Rédaction administrative en français

POLYVALENCE

OPERATIONS ET SAVOIRSFAIRE NOUVEAUX A CREER DANS LA PERIODE (évolution de l’organisation)

Validation informatique de l'étude et reconnaissance

Étude documentaire des déclarations

FORMATIONS INTERNES PREVUES

PERIODES

Acteurs

Bureautique Informatique

Statistiques

P1 P2 P3 P4

■ ■ ◪ □

■ ◪ ◪ ■

■ ◪ ◪ ■

■ ◪ □ □

■ ■ ■ ■

◪ ■ ◪ □

◪ ◪ ◪ ◪

◪ □ ◪ ◪

◪ ■ □ □

◪ ◪ □ □
O

Forte

Moyenne

Faible

O

Anglais

Liquidation des droits et taxes et ordonnancement Etablissement et gestion des actes contentieux Liquidation des droits et taxes et ordonnancements Etablissement et gestion des actes contentieux Liquidation des droits et taxes et ordonnancements

-

Du 28/02/2000 au 03/03/2000

Faible Allemand

♦ ♦

-

O
Très faible

Du 28/02/2000 au 03/03/2000 Du 06/03/2000 au 10/03/2000 Du 06/03/2000 au 10/03/2000 Du 20/03/2000 au 24/03/2000

P5

___

___

___

___

___

___

___

♦ ♦

O
Forte Très forte

Forte

Vulnérabilité

Moyen ne

Faible

Très forte

Nulle

Forte

Forte

Forte

■ Bonne connaissance théorique et pratique courante ou occasionnelle.

□Connaissance des principes sans pratique.

◪ Connaissance des principes avec pratique occasionnelle ou bonne connaissance mais sans pratique. ━ Ni connaissance théorique ni pratique

Projet de Fin d’Etudes / ENSIAS 2004

70

Annexe3 : Processus « Y »

Annexe 3 :

Processus Y

Le processus en « Y » est un processus de développement logiciel qui se caractérise par : 1- processus incrémental piloté par les risques Définition d’incrément Un incrément constitue un ensemble d’étapes de développement qui aboutit à la construction de tout ou partie du système. Le contenu d’un incrément est porteur d’améliorations ou d’évolutions du système et il peut être évalué par les utilisateurs. Le processus de développement en « Y » se reproduit à différents niveaux d’avancement en se terminant sur la livraison d’un nouvel incrément. Il a été conçu pour gérer en priorité et en parallèle les risques de nature fonctionnelle et technique : d’une part, les risques d’imprécision fonctionnelle, et d’inadéquation aux besoins sur la branche gauche. d’autre part les risques d’incapacité d’intégrer les technologies, et d’inadéquation technique sur la branche droite. 2- processus piloté par les exigences des utilisateurs La majorité des risques proviennent de la non adéquation technique et fonctionnelle du système aux besoins des utilisateurs. Les exigences des utilisateurs sont donc prioritairement traitées dans les deux branche du processus en Y. L’enjeu du processus en Y est donc de développer le point de vue utilisateur et de construire la spécification puis la conception objet à partir des concepts maniés par les acteurs du système. 3- Processus de modélisation avec UML Il apparaît difficile d’envisager le processus 2TUP sans recourir à UML comme support. Le processus en Y utilise UML dans toutes les phases par exemple : les cas d’utilisation et les diagrammes de séquences dans la phase de spécification fonctionnelle, diagramme de classes dans la phase de structuration…

Projet de Fin d’Etudes / ENSIAS 2004

71

Annexe 4 : Types de Design Patterns

Annexe 4 :

Types de Design Patterns

1. Les modèles de création
On se trouve en programmation objet souvent confronté au problème d'évolution des classes. Une classe hérite d'une autre classe pour en spécialiser certains éléments. On aimerait donc qu'un objet puisse appartenir à telle ou telle classe (dans une même famille par héritage) sans avoir à chercher la classe de gestion de ces objets et la ligne de code qui effectue l'instanciation. Fabrique de création Une fabrique de création (ou factory) est une classe qui n'a pour rôle que de construire des objets. Cette classe utilise des interfaces ou des classes abstraites pour masquer l'origine des objets. Singleton Un singleton sert à contrôler le nombre d'instances d'une classe présent à un moment donné. C'est souvent très pratique pour les classes sans état et effectuant toujours les mêmes traitements. Builder Le Builder ou Monteur est une classe offrant des moyens de construction d'un objet. Il ne doit pas être confondu avec la Fabrique. Le problème d'une Fabrique de création, c'est qu'elle ne permet de définir comment un objet va être construit, certes, il est toujours possible de passer plusieurs paramètres dans la méthode de création d'une fabrique mais cela s'avère souvent très réducteurs voire délicat pour la maintenance.

2. Les modèles de structure
Ces modèles de conception tentent de composer des classes pour bâtir de nouvelles structures. Ces structures servent avant tout à ne pas gérer différemment des groupes d'objets et des objets uniques. Adapter L'Adapter ou Adapter est un moyen commode de faire fonctionner un objet avec une interface qu'il ne possède pas. L'idée est de concevoir une classe supplémentaire qui se charge d'implémenter la bonne interface (L'Adapter) et d'appeler les méthodes correspondantes dans l'objet à utiliser (L'adapté). Proxy

Projet de Fin d’Etudes / ENSIAS 2004

72

Annexe 4 : Types de Design Patterns

Assez proche de l'Adapter, le Proxy cherche à ajouter un niveau de redirection entre l'appel d'une méthode d'un objet et l'action associée. A cet effet, on construit une nouvelle classe implémentant l'interface de l'objet à manipuler et déportant toutes les actions sur un autre objet implémentant la même interface. Ce type de structure vise à pouvoir changer l'objet cible sans changer l'objet source (manipulé). Les Proxy sont très utilisés pour la gestion d'objets distribués (protocole RMI en Java par exemple). L'idée étant de construire des Proxy capable de communiquer avec des objets distants (usage de la sérialisation en Java) sans que l'exploitant fasse de différences entre un accès locale ou un accès distant. Composite Le modèle Composite cherche à éliminer toute différence entre un groupe d'objets et un objet. Il s'agit d'une démarche récurrente valable pour tous les problèmes qui font émerger de nouvelles structures par association.

3. Les modèles de comportement
Le modèle de comportement simplifie l'organisation d'exécution des objets. Typiquement, une fonction est composée d'un ensemble d'actions qui parfois appartiennent à des domaines différents de la classe d'implémentation. On aimerait donc pouvoir "déléguer" certains traitements à d'autres classes. D'une manière générale, un modèle de comportement permet de réduire la complexité de gestion d'un objet ou d'un ensemble d'objet. Iterator L'Itérateur ou Iterator est le plus connu des modèles de comportement. L'idée étant de limiter la vision d'une collection par un utilisateur. Typiquement une collection contient un ensemble d'objets stockés par différentes méthodes (un tableau, un vecteur...), l'exploitant qui accède au contenu de la collection ne souhaite pas être concerné par cette manière de gérer les objets. La collection offre donc un point d'accès unique sous la forme d'une interface Iterator. Template Un Template ou Patron de méthode est très utilisé dans la conception objet. Ce modèle utilise simplement les mécanismes de surcharge pour déléguer à d'autres classes certaines parties d'un algorithme. L'idée ressemble un peu au modèle Builder sauf qu'ici, il sert à construire un traitement et non un objet.

Projet de Fin d’Etudes / ENSIAS 2004

73

Annexe 5 : TopLink

Annexe 5 :

TopLink

1. Descripteur TopLink Oracle 9iAS Toplink se base essentiellement sur les descripteurs qui lui permettent de stocker les informations décrivant comment une instance d’objet peut être représenté dans la base de données relationnelle Parmi les informations nécessaires que contient un descripteur, on trouve : 1- La description des classes Java persistantes et les tables correspondantes 2- Une collection de mapping permettant la description de la façon avec laquelle les attributs et les relations vont être stocker dans la base de données 3- Les informations sur la clé primaire des tables. 2. Quelques exemples de mapping Exemple1 : Soit l’exemple suivant :

Chaque « ClasseOperation » contient une ou plusieurs « Operation ». Au niveau implémentation, dans la classe « ClasseOperation », il va y avoir une collection d’objet « Operation ». Le modèle relationnelle correspondant est comme suit :

Supposons qu’on veut récupérer les opérations d’une classe :

Projet de Fin d’Etudes / ENSIAS 2004

74

Annexe 5 : TopLink

Avec JDBC

Avec framework TopLink

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); (*)ProjetToplink prjTop=new String url = "jdbc:odbc:sourceDonnee"; ProjetToplink (); Connection maconnection = DatabaseSession sessionTop = DriverManager.getConnection(url); prjTop.createDatabaseSession(); Statement ps =maconnection.createStatement(); UnitOfWork unit = sessionTop.acquireUnitOfWork(); sessionTop.login(); String query = ‘Select * from Operation, ExpressionBuilder builder = new ExpressionBuilder(); Expression exp= builder.get("idClasseOperation").equal(valeur);

ClasseOperation where Operation.idClasseOperation= ClasseOperation.idClasseOperation And Operation.idClasseOperation=valeur’
ResultSet rs = null; rs=stat.executeQuery(query);

ClasseOperation classe = sessionTop.readObject(SavoirFaireExistant.class, exp); Collection operations=classe.getOperations() ;

(*) ProjetToplink c’est la classe java générer une fois le mapping est terminé Exemple 2 : Soit le modèle objet suivant :

Une opération peut être dans plusieurs organisations et l’activité de chaque organisation se base sur un ensemble d’opérations. Lors de l’implémentation de cette relation, on doit trouver une collection des opérations dans la classe organisation et une autre collection d’organisation dans la classe opération. Le modèle relationnel correspondant est :

Projet de Fin d’Etudes / ENSIAS 2004

75

Annexe 5 : TopLink

Supposons qu’on veut chercher les opérations d’une organisation donnée : Avec JDBC Avec framework TopLink

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); (*)ProjetToplink prjTop=new String url = "jdbc:odbc:sourceDonnee"; ProjetToplink (); Connection maconnection = DatabaseSession sessionTop = DriverManager.getConnection(url); prjTop.createDatabaseSession(); Statement ps =maconnection.createStatement(); UnitOfWork unit = sessionTop.acquireUnitOfWork(); sessionTop.login(); String query = ‘Select * from Operation, ExpressionBuilder builder = new ExpressionBuilder(); Expression exp= builder.get("idOrganisation").equal(valeur);

Organisation, OperationOrganisation where Operation.idOperation= OperationOrganisation.idOperation And OperationOrganisation.idOragnisation= Organisation. idOragnisation and Organisation.idOrganisation=valeur’
ResultSet rs = null; rs=stat.executeQuery(query);

ClasseOperation classe = sessionTop.readObject(SavoirFaireExistant.class, exp); Collection operations=classe.getOperations() ;

3. Alternatives de persistance d’objets métier dans une architecture J2EE Au sein de l’architecture J2EE, on retrouve la norme EJB, qui fait figure de standard incontournable et exclusif pour la modélisation d’objets métier persistants, tel est bien le discours tenu par Sun Microsystems. Avec le recul et l’expérience accumulés depuis quelques années, d’autres normes co-existent avec J2EE, et certaines se posent même comme potentiellement concurrentes à certaines de ses fonctionnalités. C’est le cas notamment de JDO qui se pose comme une alternative sérieuse au modèle EJB pour la persistance. Dans le domaine de la persistance objet, des produits comme Oracle9iAS TopLink, Hybernate et OJB ont été conçus de sorte qu’ils soient neutres par rapport au modèle d’architecture applicative. De plus, ces alternatives se posent non pas uniquement comme approches concurrentes à J2EE et au modèle EJB, mais également en tant que briques complémentaires dans une architecture multi-tiers J2EE pouvant mettre en œuvre le modèle d’application EJB. Dans ce qui suit, une étude comparative et objective est menée entre les trois alternatives pour la persistance d’objets métier en architecture multi-tiers J2EE : • la persistance de composants métier à travers le modèle EJB de J2EE ; • la persistance d’objets métier à travers le modèle JDO ; • la persistance d’objets métier à travers Oracle9iAS TopLink, l’un des outils de mapping objet/relationnel les plus évolués disponibles sur le marché.

Projet de Fin d’Etudes / ENSIAS 2004

76

Annexe 5 : TopLink

Cette étude procède d’une évaluation méthodique, et s’appuie sur une grille de critères détaillée qui regroupe en huit domaines les différents aspects de la problématique de persistance objet: 1. Transparence de modélisation : La Flexibilité dans la modélisation permet de modéliser le domaine métier le plus fidèlement possible ; 2. Support des sources de données pour la persistance : La capacité de prise en charge des principaux SGBD du marché maximise le potentiel de l’outil ; 3. Capacités de modélisation et de projection : La richesse de modélisation apporte souplesse de conception et simplicité de développement ; 4. Langage de requêtage objet : La puissance et la richesse du langage de requêtage objet ; 5. Potentiel transactionnel : La prise en charge de fonctionnalités transactionnelles sophistiquées ; 6. Cache objet et optimisations : La présence d’un cache objet distribué, favorise une meilleure montée en charge des applications ; 7. Environnement de développement (IDE) : La simplicité de développement permet des gains de productivité ; 8. Déploiement et intégration : La facilité de déploiement et d’intégration avec les serveurs d’application J2EE, détermine le potentiel du modèle pour l’entreprise.

4. Etude comparative entre les mécanismes de persistance
4.1. Evaluation du modèle EJB La norme EJB définit une architecture de composants transactionnels qui couvre largement le spectre de la modélisation métier : • les EJB session permettent de modéliser des processus métier ; • les EJB orienté message (message-driven beans) permettent de modéliser des processus asynchrones ; • enfin, les EJB entité permettent de modéliser des entités métier persistantes. La grille d’évaluation détaillée de la couverture fonctionnelle du modèle EJB en matière de persistance est présentée le schéma ci-dessous :

Projet de Fin d’Etudes / ENSIAS 2004

77

Annexe 5 : TopLink

Modélisation Support des sources de données Mapping
Langage de requêtage

42% 75% 55% 25% 80% 60% 63% 88%

Potentiel transactionnel Cache objet & optimisations IDE Déploiement & intégration

Figure 36 : Evaluation du modèle de persistance EJB

Ces résultats illustrent clairement les limitations du modèle EJB en termes de respect du paradigme objet, avec des capacités de modélisation et de requêtage réduites. On note également des capacités de projection (mapping) limitées, ainsi que des faiblesses au niveau du cache objet et des optimisations proposées. Enfin, ce modèle est limité en termes de déploiement à une architecture J2EE 4 tiers. En revanche, il bénéficie intrinsèquement d’un haut niveau d’intégration dans l’architecture J2EE, de la disponibilité d’outils de développement adaptés, et d’un potentiel transactionnel satisfaisant.
4.2. Evaluation de JDO JDO est une spécification qui vise à définir un standard universel pour la persistance transparente d’objets Java simples. Cette spécification constitue l’adaptation au langage Java du standard de persistance transparente défini par l’ODMG (Object Database Management Group), un consortium de fournisseurs de bases de données objet formé avant l’avènement de Java, à l’époque où SmallTalk et C++ étaient les deux principaux langages orientés objet du marché.

Le développement du standard JDO s’est produit parallèlement à l’élaboration des normes EJB et J2C, et le groupe de travail JDO a toujours estimé qu’il était important de garder JDO en ligne avec ces standards. Cependant, l’implémentation d’un modèle de persistance nonintrusif, flexible et sophistiqué mais qui reste simple d’utilisation au sein des applications, a été la considération primordiale qui a guidé l’élaboration de cette norme. La grille d’évaluation détaillée de la couverture fonctionnelle du modèle JDO en matière de persistance est présentée par le schéma ci-dessous :

Projet de Fin d’Etudes / ENSIAS 2004

78

Annexe 5 : TopLink

Modélisation Support des sources de données Mapping Langage de requêtage Potentiel transactionnel Cache objet & optimisations IDE Déploiement & intégration 50% 50% 80% 60% 88% 88%

100%

100%

Figure 37 : Evaluation du modèle de persistance JDO

Les notes obtenues par le modèle JDO sur les capacités de modélisation et de requêtage démontrent sa prise en charge complète du paradigme objet. On note également sa versatilité en termes de support de sources de données et de déploiement, ainsi que sa facilité d’intégration au sein d’une architecture J2EE. En revanche, les capacités de projection (mapping) de ce modèle restent moyennes : l’explication vient d’une part du support limité pour les relations d’association (pas de support de relations bi-directionnelles et de gestion de l’intégrité référentielle avec la prise en charge des suppressions en cascade), et d’autre part du faible niveau de compatibilité entre implémentations (mapping non-standardisé). Enfin, les implémentations JDO sont des produits encore jeunes. Bien que les produits disponibles intègrent un cache objet transactionnel sophistiqué, les possibilités de paramétrage et d’optimisation restent limitées.
4.3. Evaluation de La solution « Oracle9iAS TopLink » Oracle9iAS TopLink est un produit éprouvé en matière de persistance de modèles objets complexes en base relationnelle. Très complète, la solution Oracle9iAS TopLink est constituée de plusieurs briques.

Oracle9iAS TopLink adopte une approche non-intrusive pour l’implémentation de la persistance objet, et permet une approche de modélisation à granularité fine utilisant les paradigmes de la conception objet : héritage, composition, et polymorphisme. La logique de persistance est entièrement découplée de la logique métier et de la logique applicative. Aucun ajout de code spécifique à la persistance n’est requis, et contrairement à JDO, Oracle9iAS TopLink n’a pas recours à un mécanisme de post-traitement du code des objets métier pour l’implémentation des mécanismes de persistance. Les seules informations nécessaires à Oracle9iAS TopLink pour l’implémentation de la logique de persistance sont les mappings des attributs objet sur le support de persistance (Dans la pratique très majoritairement des bases de données relationnelles), qui sont stockés dans des descripteurs XML. La grille d’évaluation détaillée de la couverture fonctionnelle du modèle Oracle9iAS TopLink en matière de persistance est présentée par le schéma ci-dessous :

Projet de Fin d’Etudes / ENSIAS 2004

79

Annexe 5 : TopLink

Modélisation Support des sources de données Mapping Langage de requêtage Potentiel transactionnel Cache objet & optimisations IDE Déploiement & intégration 88% 88% 90%

100%

100% 100% 100%

100%

Figure 38 : Evaluation du modèle de persistance Oracle9iAS TopLink

Le modèle Oracle9iAS TopLink excelle dans la plupart des domaines. On notera tout particulièrement ses possibilités étendues en matière de requêtage objet, ses capacités de mapping exhaustives, et un potentiel transactionnel remarquable. D’autre part, Oracle9iAS TopLink inclut un cache objet transactionnel de haut niveau, qui offre des possibilités de paramétrage étendues et intègre de nombreuses optimisations pour l’amélioration des performances (optimisations au niveau de l’exécution des requêtes notamment). Enfin, ce modèle, facilement intégrable au sein d’une architecture J2EE, offre une grande versatilité pour le déploiement. Seuls points perfectibles, la richesse de l’IDE et le support des sources de données. Durant les phases de développement, un environnement de test pour les objets persistants serait un plus. D’autre part, la prise en charge des bases de données objet et des sources de données J2C serait également appréciable.

Projet de Fin d’Etudes / ENSIAS 2004

80

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->