Vous êtes sur la page 1sur 95

Dédicace

Je dédie ce travail
A
Mes chers parents
Pour tout le bonheur qu’ils m’apportent, pour leur soutien moral, matériel et affectif.
Pour leur encouragement durant mes études et tout au long de la réalisation de ce
travail. Qu’ils trouvent dans ce travail le fruit de leurs sacrifices consentis pour mon
éducation et l’expression de mon amour et ma gratitude pour tout leur encouragement
qui m’a toujours poussé vers l’avant. Que Dieu le tout puissant leur protège et leur
procure santé et longue vie.
A
Mes sœurs
Je leur souhaite tout le succès et le bonheur du monde.
A
Tous les membres de ma famille, pour les encouragements et les conseils qu’ils n’ont
cessé de me prodiguer, plus spécialement mes chères Ines Maalej, Mouna Mallouli et son
mari Sabeur, Pour leur patience, leur confiance et leur affection.
Qu’ils trouvent avec ce travail l’expression de ma sincère gratitude et de mon affection.
A
Tous mes ami(e)s, notemment Zyed Triki, Ayoub Zayeti et Aladdin El Gharbi.
A
Ma chère amie Chikhrouhou Monia.

Rim
Dédicace

Je me permet d’exprimer ma plus profonde reconnaissance à :

Mon père Ahmed : Qui n’a jamais cessé de me soutenir, m’assister et m’encourager
depuis mes premiers jours du primaire jusqu’aujourd’hui. A celui qui a sacrifié ses
belles années pour embellir les miennes.

Ma mère Majda : Qu’aucune expression de gratitude ne suffisait pour témoigner de


l’étendue des sentiments que j’éprouve à son égard, pour sa bienveillance même
avant que je vit la lumière et pour son affection et son amour avec lesquels elle m’a
comblé. A celle que je sacrifierai mon âme pour regarder son sourire celeste.

Mes sœurs Sara et Maroua : Que personne ne peut égaler leurs places dans mon
cœur, pour les magnifiques moments passés ensemble. Je leur souhaite une belle vie
et qu’Allah les protège.

Ma fiancée Yosr : Pour ses encouragements et son support durant la période du


stage. Je lui souhaite la réussite dans ses études et dans sa vie entière.

Lina : La perle qui ne cesse pas de sèmer la joie et la gaı̈té dans la maison. Qu’Allah la
garde pour ses parents.

A toute la famille et tous mes amis, qui m’ont toujours poussé vers la réussite, qu’Allah
leur offre le bonheur et nous rassemble dans ses paradis.

Akram
Remerciements

Qu’il nous soit permis de remercier les membres du jury, pour l’honneur qu’ils me font
de juger ce modeste travail.

Nos vifs remerciements s’adressent à Monsieur Walid Sadfi pour l’honneur qu’il nous
fait en acceptant d’encadrer notre projet de fin d’études. Votre haute compétence, votre
dynamisme, votre amour de métier et de vos étudiants, et votre sens de l’humain qu’on a
tant admiré, sont pour vous le meilleur guide. Vous êtes pour nous le maı̂tre dont je suis
fier d’être l’élève.

Nous présentons nos remerciements les plus sincères à tout le corps enseignant de
l’Ecole Nationale des Sciences de l’Informatique auxquels nous devons nos instructions.

Au terme de ce travail, nous présentons notamment notre profonde gratitude à Mon-


sieur Hakim Harzallah, Directeur de développement du Groupe Laceramic SA, pour sa
bienveillance de nous avoir accueilli au sein de la société, pour la confiance qu’il nous a
accordé, pour son assistance et son suivi.

Nous citons en particulier nos encadreurs professionnels Messieurs Sofiène Bchir et Bilel
El Ghali dont l’aide et l’encouragement continu nous ont permis de défier les entraves et
de travailler avec acharnement. Nous espérons être à la hauteur de leur confiance. Qu’ils
trouvent dans ce travail l’expression de notre profonde gratitude.

Nous remercions spécialement tous ceux qui ont croisé pour quelques temps notre
route au sein de LACERAMIC, nous pensons notamment à l’équipe des stagiaires qui ont
animé ces quatre mois de travail, notamment notre collègue Hsis Mos’ab.

Enfin, nous exprimons notre sympathie à toutes les personnes qui ont contribuées de
près ou de loin au bon déroulement de ce travail.
Table des matières

Introduction 1

1 Présentation générale 3

1.1 Présentation de Laceramic S.A . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Activités principales de Laceramic . . . . . . . . . . . . . . . . . . 3

1.1.2 Dispersion géographique du groupe LACERAMIC . . . . . . . . . . 4

1.2 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Etat de l’art 9

2.1 Le E-Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Généralités sur le E-Learning . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Processus du E-Learning . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.3 Situation du E-Learning en Tunisie . . . . . . . . . . . . . . . . . . 12

2.2 Les outils du E-Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Les outils de gestion des formations (LMS) . . . . . . . . . . . . . . 14

2.2.2 Les outils de gestion des contenus de formation (LCMS) . . . . . . 18

3 Analyse et spécification des besoins 23

3.1 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Quelques méthodes agiles de développement . . . . . . . . . . . . . 24

3.1.2 Méthodologie retenue . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Standard UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25


viii TABLE DES MATIÈRES

3.3 Définition des acteurs du système . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Analyse des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 27

3.5 Analyse des besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . 27

3.6 Les diagrammes des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 28

3.6.1 Cas d’utilisation de l’apprenant . . . . . . . . . . . . . . . . . . . . 28

3.6.2 Cas d’utilisation de l’adminstrateur . . . . . . . . . . . . . . . . . . 30

3.7 Plan de navigation de la plateforme . . . . . . . . . . . . . . . . . . . . . . 30

3.8 Les diagrammes d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.8.1 Espace de collaboration . . . . . . . . . . . . . . . . . . . . . . . . 31

3.8.2 Gestion des supports de formation . . . . . . . . . . . . . . . . . . 33

4 Conception 35

4.1 Conception générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.1 Architecture multi-tiers . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.2 Diagramme de paquetages . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.1 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.2 Diagrammes de classes . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.3 Conception de la base de données . . . . . . . . . . . . . . . . . . . 45

5 Réalisation 49

5.1 Environnement logiciel du travail . . . . . . . . . . . . . . . . . . . . . . . 49

5.2 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.1 Côté apprenant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.2 Côté administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.3 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 Conclusion et perspectives 60
TABLE DES MATIÈRES ix

Netographie 65

Glossaire 66

A Le standard J2EE 66

B Le framework JSF 71

C DAO et Hibernate 73
Table des figures

1.1 Dispersion géographique du groupe LACERAMIC . . . . . . . . . . . . . . 4

2.1 Processus du E-Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Comparaison des LMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Comparaison des fonctionnalités des CMS . . . . . . . . . . . . . . . . . . 21

3.1 Le processus XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Cas d’utilisation d’un apprenant . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Cas d’utilisation de l’administrateur . . . . . . . . . . . . . . . . . . . . . . 30

3.4 Plan de navigation de la plateforme . . . . . . . . . . . . . . . . . . . . . . 31

3.5 Espace de collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.6 Gestion des supports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Diagramme de paquetages de l’application . . . . . . . . . . . . . . . . . . 37

4.3 Evaluation des acquis des apprenants . . . . . . . . . . . . . . . . . . . . . 39

4.4 Suppresion de formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5 Suivi des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6 Diagramme de classes du paquetage Utilisateurs . . . . . . . . . . . . . . . 43

4.7 Diagramme de classes du paquetage Formations . . . . . . . . . . . . . . . 43

4.8 Diagramme de classes du paquetage Evaluation . . . . . . . . . . . . . . . 44

4.9 Diagramme de classes du paquetage Collaboration . . . . . . . . . . . . . . 45


xii TABLE DES FIGURES

4.10 Schéma conceptuel de la base de données . . . . . . . . . . . . . . . . . . . 46

4.11 Conception de la base de données du forum . . . . . . . . . . . . . . . . . 47

5.1 Architecture du framework JSF . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Position d’Hibernate dans une application web . . . . . . . . . . . . . . . . 51

5.3 Les modules réalisés de la plateforme . . . . . . . . . . . . . . . . . . . . . 52

5.4 Authentification des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . 52

5.5 Accueil d’un apprenant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.6 Livre interactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.7 Evaluation par QCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.8 Participation au forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.9 Accueil de l’administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.10 Gestion des modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.11 Ajout d’un support de formation . . . . . . . . . . . . . . . . . . . . . . . 60

5.12 Ajouter un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.13 Chronogramme des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

A.1 Architecture N-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


Introduction

D e nos jours, le monde vit une situation économique de criticité indéniable. En effet les
mutations inéluctables de l’industrie mondiale mettent les entreprises devant le problème
de l’inadéquation de ses employés avec leur environnement économique, chose qui les
empêche d’évoluer dans le rythme international.

Maı̂triser et non subir ces changements est alors un enjeu qui est hors question de le
perdre. Pour cela la majorité des établissements dans le monde a concentré plein d’effort
autour de son maı̂tre d’œuvre qui n’est personne autre que l’employé puisque développer
son sens créatif, sa capacité à apprendre et à évoluer et maintenir ses compétences sont
devenus vitaux pour accroı̂tre l’agilité et la flexibilité de l’entreprise.

En Tunisie, la formation professionnelle continue est organisée par le code de travail


(article 339) et qui la considère comme service comprenant l’acquisition d’éléments essen-
tiels de culture générale et celle d’une technique professionnelle, théorique et pratique, le
perfectionnement professionnel, le reclassement professionnel et la formation profession-
nelle accélérée.

La compétitivité est encore plus d’actualité et le temps de travail reste fixe alors que
le besoin en formation augmente ce qui ne favorise pas la productivité recherchée. En
effet partir en formation nécessite le regroupement d’un nombre maximal d’apprenants
avec le formateur dans une période convenable à tout le monde, d’où la difficulté de la
planification. Comme  le temps, c’est l’argent  , les sociétés se trouvent dans une course
contre la montre et avec des budgets sans cesse optimisés.

Avec leur apparition, les technologies de l’information et de la communication


représentaient l’arche de Noé pour les entreprises. En effet, que ce soit via Internet ou
l’intranet, les moyens de formation, d’apprentissage, d’accompagnement et d’informations
2 INTRODUCTION

se développent ; faits principalement liés au gain de temps et à l’augmentation du public


touché.

C’est ainsi que le concept de la formation à distance a vu le jour. Néanmoins, la e-


formation n’est pas un luxe qui peut attendre l’arrivée des jours meilleurs de l’économie,
bien au contraire, elle fait partie intégrante du processus susceptible de conduire à ces
jours.

C’est dans ce contexte que s’intègre notre travail et qui consistait à la conception et la
réalisation d’une plateforme de formation à distance au sein de LACERAMIC S.A qui a
inclus l’E-Learning dans sa stratégie pour faire face aux défis du marché et aux nouvelles
circonstances qui viennent de s’imposer.

Le présent document est un rapport descriptif synthétisant tout le travail que nous
avons effectué dans cette perspective. Il est organisé en chapitres comme suit :
– Le premier donne une présentation générale du projet : l’organisme d’accueil ainsi
que les objectifs à atteindre.
– Dans le second, nous exposons l’état de l’art du domaine du E-Learning afin de bien
se mettre dans le contexte.
– Le troisième chapitre intitulé ” Analyse et spécification des besoins ” présente les
différents besoins fonctionnels et non fonctionnels que doit satisfaire l’application à
réaliser.
– La conception générale et la conception détaillée font ensuite l’objet du quatrième
chapitre.
– Le dernier chapitre décrit les tâches accomplies durant le stage en titre de réalisation.

Enfin nous donnons une conclusion récapitulant le travail réalisé ainsi que des pers-
pectives futures.

Le rapport est muni aussi de quelques annexes représentant les détails techniques de
la conception et de la réalisation ainsi que quelques concepts théoriques indispensables
pour la bonne compréhension du rapport.
CHAPITRE

1 Présentation générale

Ce chapitre a pour objectif de situer notre projet dans son contexte général à savoir
l’organisme d’accueil et le sujet à traiter. Dans la première section nous donnons une brève
présentation de l’organisme d’accueil ’LACERAMIC S.A’. Dans la deuxième section, nous
décrivons le sujet à traiter et les objectifs à atteindre.

1.1 Présentation de Laceramic S.A

Pour bien se mettre dans le contexte du stage, nous avons jugé nécessaire de présenter
l’organisme qui nous a accueilli en mettant en relief ses activités diverses et l’étendu
géographique de ses sites en Tunisie.

1.1.1 Activités principales de Laceramic

Fondée en 1931, ”La Céramique Tunisienne”, c’est ainsi que la société s’appelait ini-
tialement, a été rebaptisée LACERAMIC après son rachat par le groupe éponyme.

LACERAMIC, signifiant un groupe et un label, a profité de sa privatisation pour re-


vendiquer le titre d’entreprises pionnières et innovatrices dans leurs domaines : les produits
rouges, réfractaires et les carreaux de faı̈ence. LACERAMIC vient, ces dernières années,
de diversifier ses activités pour toucher d’autres secteurs afin de continuer et accentuer sa
participation dans la construction de la Tunisie en prenant en charge les secteurs dont le
pays a le plus besoin. C’est ainsi que le groupe LACERAMIC a créé MAS, (Mediterranean
Air Service) l’opérateur aérien spécialisé en matière de frêt aérien. C’est dans ce contexte
qu’il a également mis sur pied MEDSOFT, une société de service et d’ingénierie informa-
tique dont le champ de compétences est l’étude technique et le conseil en informatique.
4 CHAPITRE 1. PRÉSENTATION GÉNÉRALE

LACERAMIC s’est aussi intéressée à la finance avec la création de MEDINVEST, une


société à capital risque.

1.1.2 Dispersion géographique du groupe LACERAMIC

Le groupe touche un effectif d’un millier de personnes entre cadres, ingénieurs, tech-
niciens, agents techniques, agents de maı̂trise et ouvriers, travaillant dans les divers sites
de produits rouges et de carreaux de faı̈ences situés à Fouchana, Jendouba, El Hamma,
Kasserine, Bizerte et à Tajerouine comme le montre la figure 1.1.

Figure 1.1 — Dispersion géographique du groupe LACERAMIC


1.2. PRÉSENTATION DU SUJET 5

1.2 Présentation du sujet

Une étude de cas a révélé l’obligation de certaines formations pour les différents agents
de LACERAMIC. D’où le besoin à un parcours professionnel avec des formations obliga-
toires dans le cadre d’une Validation des Acquis Professionnels (VAP) afin de permettre
aux agents de partir en formation malgré un manque de personnel, d’où la favorisation
du remplacement de la stratégie de formation.

Vu la richesse de son système d’information et sa volonté d’amélioration, LACERAMIC


a opté pour la réalisation de sa propre plate-forme de formation à distance. C’est ainsi
qu’elle pourra dépasser les obstacles posés par la formation professionnel classique dont
les principaux sont :

– Le manque de disponibilité du personnel.


– La dispersion géographique des différents sites du groupe.
– Le coût important de la planification et d’exécution.

La solution est donc de diversifier le système d’apprentissage en développant l’utili-


sation des nouvelles technologies. Il s’agit surtout de mettre en place une solution qui
accompagnera les apprenants dans le nouveau dispositif de formation et qui vise à at-
teindre les objectifs suivants :
– Libérer les professionnels intervenant dans la formation.
– Toucher une tranche de population plus large.
– Evaluer les connaissances et les aptitudes de chacun dans la maı̂trise des différents
applicatifs de l’entreprise.
– Mettre à jour les contenus et méthodes afin d’optimiser l’impact de la formation sur
les apprenants.
– Permettre une individualisation de la formation.
– Développer l’autonomie des apprenants, tout en offrant une grande souplesse : le
E-Learning laisse le choix aux apprenants quant au moment et au lieux auxquels ils
désirent se former.
– Permettre la formation juste à temps : les employés changent fréquemment d’em-
plois, de postes, de projets et les informations deviennent obsolètes de plus en plus
rapidement. Avec le E-Learning, l’employé peut consulter le cours(ou la partie du
cours) juste avant d’accomplir la tâche voulue ou avant de résoudre un problème.
6 CHAPITRE 1. PRÉSENTATION GÉNÉRALE

– Assurer un suivi et un contrôle de la formation plus efficacement.


– Accélérer l’apprentissage : permettre de former rapidement une multitude de per-
sonnes (employés, clients, partenaires) réparties dans des lieux différents.
– Créer des espaces de communication et de collaboration ( forums et mails).
1.2. PRÉSENTATION DU SUJET 7

Pour chacune des formations, les niveaux de compétence visent à attribuer aux appre-
nants une des qualifications suivantes :

– sensibilisation : avoir des notions sur des concepts choisis.


– familiarisation : appliquer les bases des concepts choisis dans des situations
connues.
– maı̂trise : avoir des connaissances approfondies et les appliquer dans des situations
connues mais complexes.
– expertise : appliquer l’ensemble des connaissances dans des situations nouvelles et
être capable d’analyser et d’évaluer ces situations

Conclusion

Dans ce premier chapitre nous avons pu situer le projet dans son cadre général en
présentant l’organisme d’accueil et les buts de l’application. Dans le chapitre suivant,
nous allons procéder à une étude détaillée des principaux concepts en relation avec notre
sujet.
CHAPITRE

2 Etat de l’art

Avant d’entamer l’élaboration de notre projet, nous avons jugé primordial de présenter
les objectifs généraux d’une telle application à partir de ses éléments moteurs, à savoir le
concept et les les outils communément utilisés dans l’E-Learning .

2.1 Le E-Learning

Le but de cette section est de s’initier à la notion du E-Learning. Pour cela, nous
commençons par définir ce concept et présenter ses principes. Ensuite, nous définissons le
processus de développement d’un système de formation à distance. Enfin, nous exposons
l’expérience tunisienne dans l’apprentissage à distance.

2.1.1 Généralités sur le E-Learning

Définition

La définition du E-Learning varie selon le plan de vision de ce concept. en effet deux


plans principaux ont contribuer à une définition.

Pédagogiquement, le E-Learning peut se définir comme un ensemble de méthodes de


formation permettant de suivre un programme de formation à distance en ayant recours
à Internet ou Intranet.

l’E-Learning, du point de vue informatique, est la mise en œuvre des outils multimédia
(son, image, vidéo) au sein d’un système réparti grâce aux supports de distribution de l’in-
10 CHAPITRE 2. ETAT DE L’ART

formation (PC, Internet, Intranet, Extranet . . .) pour permettre à l’apprenant d’accomplir


un ensemble de formation et aux responsables de gérer le contenu de la formation.

Les formes du E-Learning

L’E-Learning peut se présenter de trois façons :


– La formation asynchrone : méthode de formation s’appuyant sur la guise de
l’apprenant. Elle ne l’oblige pas à être connecté à une heure précise mais plutôt le
laisse le choix.
– La formation synchrone : permet plus d’interactivité entre les apprenants et les
responsables des formations grâce à la communication en temps réel entre eux.
– L’apprentissage mixte : c’est la combinaison entre les deux façons déjà évoquées.
Elle donne à l’apprenant une période limitée pour acquérir une formation tout en
offrant les outils nécessaires de collaboration en temps réel.

Principes du E-Learning

Le concept du E-Learning se base essentiellement sur trois principes :


– Utilisation des nouvelles technologies : le premier principe porte sur l’utilisation des
TIC 1 interactives et accessibles à un très large public.
– Organisation du contenu : le second principe concerne l’organisation du contenu
pédagogique. Ce contenu est découpé en modules de telle sorte que l’on puisse
construire des parcours d’apprentissage adaptés aux apprenants en fonction de leurs
connaissances de base, de leurs expériences, de leurs objectifs . . .Il s’agit de définir
des sous ensembles ou modules cohérents et de définir une progression logique (un
chemin d’apprentissage) d’un module à l’autre de telle sorte que les conditions sui-
vantes soient satisfaites :
[-] Chaque module apporte à l’apprenant un ensemble de connaissances qui
viennent s’ajouter, de manière cohérente, aux connaissances acquises dans les mo-
dules précédents.
[-] L’assimilation du contenu de chaque module doit être évaluée par des tests
en fin de module. Ces tests seront proposés à l’apprenant sous forme de ques-

1. Technologies de l’Information et de la Communication


2.1. LE E-LEARNING 11

tions/réponses, de questionnaires à choix multiples, de problèmes à résoudre, de


simulation, d’études . . .
[-] Les pré-requis d’un module doivent être contenus dans le(s) module(s)
précédent(s) (sauf, bien entendu, pour le premier module du cours).
[-] La redondance de certains modules, dans leur contenu, permet à l’apprenant
de se rafraichir la mémoire et de revoir sous une autre forme ce qui n’a pas été bien
assimilé.
– La collaboration entre apprenants : par rapport à une formation classique, les ap-
prenants d’un cours dispensé par E-Learning ne sont plus physiquement rassemblés
dans un même local. Comme il est important de ne pas perdre la valeur ajouté
que représente la communication formelle et informelle entre les apprenants, les pla-
teformes de E-Learning fournissent des outils qui permettent de créer des classes
virtuelles ou des groupes d’apprenants vont pouvoir ” se rencontrer ”, échanger des
idées, confronter leurs expériences.

2.1.2 Processus du E-Learning

Le processus de développement des plateformes de formation à distance est


généralement décomposé en cinq phases principales qui sont organisées en boucles afin
de garantir une démarche itérative. En effet les différentes phases sont :
– L’analyse : elle constitue la base sur laquelle les objectifs et les fonctionnalités de
la plateforme seront éclaircis.
– La modélisation (Design) : c’est la phase dans laquelle les développeurs mettent
en place les spécifications des modules de formation, des dépendences entre eux ainsi
que des formats et des contenus des supports de formation.
– L’implémentation : c’est là où l’équipe de développement travaille sur la trans-
formation du modèle en un système fonctionnel. Cette phase doit alors produire des
métadonnées sur les formations, les supports et sur l’évaluation des connaissances.
– Le test et l’intégration : c’est la mise en œuvre de la totalité ou d’une partie du
système afin de le tester et de recueillir les remarques et les votes de ses utilisateurs
directs.
– L’évaluation et la maintenance : après avoir identifié les défauts du système
et ses sources de plantages éventuelles il est nécessaire de passer par une phase de
12 CHAPITRE 2. ETAT DE L’ART

maintenance permettant de réparer et le rendre opérationnel.


Les différentes phases de ce processus sont décrites par la figure 2.1.

Figure 2.1 — Processus du E-Learning

2.1.3 Situation du E-Learning en Tunisie

Les principaux pays actuellement exportateurs de services de formation par Inter-


net sont les Etats-Unis, les pays européens, l’Australie et le Canada. Les réalisateurs au
Etats-Unis et au Canada sont énormes et diversifiés. En effet c’est vu l’importance qu’ils
l’accordent à ce nouveau mode d’éducation que nous assistons ces jours là à une croissance
vertigineuse du E-Learning . L’Australie et les pays européens investissent moins dans ce
secteur que les pays de l’Amérique de Nord, mais ils réagissent rapidement à l’évolution
de la formation ouverte et à distance. Ils y affectent des crédits importants et se dotent
des structures nécessaires pour le développement de ce secteur. Dans le cadre de la mo-
dernisation et de la mondialisation, les pays en cours de développement commencent bien
2.1. LE E-LEARNING 13

à s’incliner devant cette nouvelle méthode d’apprentissage virtuel. Seulement, certains


sont encore en phase d’hésitation car la transaction vers ce nouveau mode d’éducation est
délicate. En Tunisie, les initiatives dans le secteur professionnel et éducatif du E-Learning
ont débuté avec la création de ces trois principaux sites : l’école virtuelle Tunisienne,
l’école virtuelle de la poste tunisienne et l’université virtuelle de Tunis.

L’école virtuelle Tunisienne

Depuis le 28 janvier 2002, la phase expérimentale de l’école virtuelle tunisienne a


débuté. Cette école s’organise autour de trois axes : accompagnement et encadrement,
apprentissage de la langue arabe et formation aux TIC. L’école virtuelle constitue un
espace d’échange de ressources éducatives, d’expériences et d’idées et veut offrir l’oppor-
tunité de débattre dans le cadre de forums de discussion à propos de sujets divers.

L’école virtuelle de la poste tunisienne

L’école virtuelle de la poste tunisienne ouvre dans une première étape un ensemble de
cycle de formation à distance à l’intention des apprenants qui remplissent les conditions
de participation. Le déroulement de la formation effectue conformément aux étapes es-
sentielles suivantes (apprentissage, auto-évaluation, examen d’évaluation à distance, exa-
men final présentiel). Les cours de l’école virtuelle portent sur des thèmes à caractère
académique tel que la comptabilité, les finances, la gestion, l’économie, le droit, l’informa-
tique, les langues et les thèmes à caractère professionnel postal comme l’épargne postale
des chèques postaux, les nouveaux services.

L’université virtuelle de Tunis.

L’université virtuelle de Tunis(UVT) a démarré ses activités le 28 janvier 2002 en par-


tenariat avec les Instituts Supérieurs des Etudes Technologiques (ISET). L’enseignement
au sein de l’UVT est modulaire, il se fait, essentiellement, avec une dose en présentiel
de 20%. L’UVT se propose d’offrir différents types de formation ouverte et à distance
(FOAD)en utilisant les nouvelles technologies de l’information et de la communication :
– Formations initiales
– Formations spécialisés post-maı̂trise
14 CHAPITRE 2. ETAT DE L’ART

– Formations courtes à vocation professionnelle


Cette expérience a débuté avec la plate-forme ACOLAD 2 , par la suite, à partir de
février 2004, elle a migré vers la plateforme INES 3 .

2.2 Les outils du E-Learning

Dans une plateforme typique d’apprentissage à distance, nous trouvons des outils de
gestion des formations (LMS=Learning Management System), des outils de création des
modules de cours (LCMS=Learning Content Management System) et des outils destinés
aux différentes formes de communication.

2.2.1 Les outils de gestion des formations (LMS)

L’appellation Learning Management System(LMS), en français ”plate-forme de


gestion de la formation” , désigne une solution logicielle axée sur l’intégration, la diffusion
et la gestion de contenu pour la formation à distance.

Les principales fonctionnalités d’un LMS sont :


– La gestion des apprenants : il s’agit de la principale fonctionnalité d’un LMS. Elle
permet aux responsables de la formation de définir, avec l’aide de l’administrateur,
les différents types de profils avec leurs droits associés. Elle administre l’inscription
et l’identification des apprenants aux formations, de façon individuelle ou groupée :
respect d’un circuit d’approbation prédéfini, prise en compte éventuelle des pré-
requis nécessaires pour suivre une formation. Certains LMS gèrent également la
notion de  domaine  , segmentant l’accès aux formations selon les profils des
apprenants et/ou les entités concernées.
– La conception des cours : les LMS intègrent le plus souvent des outils simples de
création de contenu, permettant la création de cours, d’exercices et d’évaluations, en
assemblant les différents supports pédagogiques créés par le concepteur (documents,
animations, multimédia). Il est possible de définir un scénario et une arborescence
2. Apprentissage COLLaboratif A Distance
3. Interactive E-Learning System
2.2. LES OUTILS DU E-LEARNING 15

de cours.
– le suivi des cursus de formation : les LMS permettent de suivre les temps consacrés à
la formation et aux exercices, ainsi que d’affecter des rôles aux différents apprenants.
Il est possible d’évaluer les performances des apprenants et de leur délivrer des
certifications si certaines conditions d’obtention sont remplies.
– le suivi et le bilan de la formation : les LMS intègrent des outils de reporting et
de statistiques permettant de suivre de façon synthétique, par apprenant ou groupe
d’apprenants, le temps passé en formation, les résultats obtenus, etc. Cela autorise
notamment le suivi et la gestion des coûts de formation.

Etude de quelques LMS

Il existe deux choix pour mettre en place une plateforme de E-Learning :


– soit choisir parmi les géants des LMS car ils sont riches et proposent des fonction-
nalités standards.
– soit déployer son propre LMS qui répond exactement aux besoins du client.
La solution LMS retenue doit pouvoir permettre le développement d’un contenu E-
Learning facile à utiliser et adaptable. Une personne sans connaissance technique parti-
culière doit être en mesure de développer du contenu E-Learning et de le mettre en ligne
sur la plate-forme pédagogique. Les critères fonctionnels à prendre en compte dans le
choix d’une plateforme LMS sont :
– Simplicité de l’installation et de l’utilisation : un LMS doit avoir une grande simpli-
cité pour qu’il soit jugé convenable à la mise en place d’une plate-forme d’appren-
tissage à distance.
– Adaptabilité : c’est la capacité d’un LMS de s’intégrer avec les éléments du système
d’information de l’entreprise.
– Modularité : un gestionnaire de formation modulaire est un système dont l’architec-
ture est développée en module, ce critère favorise alors l’extension de la plate-forme
en lui ajoutant d’autres modules.
– Scalabilité : c’est la caractéristique d’un système à évoluer en cas d’augmentation
du nombre d’utilisateurs et/ou de la taille son contenu.
– Respect des normes et des standards du E-Learning : pour faciliter les échanges
entre les différents systèmes d’apprentissage à distance, des normes sont mis en
16 CHAPITRE 2. ETAT DE L’ART

place. Mais le problème réside au fait que les travaux de normalisation sont en cours
et donc les spécifications changent fréquemment.
– Ergonomie des vues : afin d’intensifier la motivation des apprenants ainsi que celle
des tuteurs, les LMS doivent avoir des interfaces interactives et ergonomiques.
Notre stratégie d’évaluation consistait à consulter la documentation de référence en
ligne ainsi que les comparatifs, les analyses et les retours d’expériences des experts. Nous
effectuerons une étude comparative de quatre LMS (Claroline, Dokeos, Ganesha, Moodle)
et qui vise l’identification des caractéristiques ergonomiques, techniques, pédagogiques qui
répondent au mieux à nos contraintes.

Claroline : est une plate-forme Open Source de formation à distance et de travail col-
laboratif. Elle permet aux formateurs de créer des espaces de cours en ligne et de
gérer des activités de formation sur Internet. Elle est simple à installer et à utiliser
grâce à la documentation riche et claire contenue dans le site officiel. Cependant,
elle a quelques points faibles comme l’espace très limité pour les documents et les
liens d’un groupe et l’ergonomie modeste de la messagerie instantannée. De plus, la
possibilité de créer plusieurs comptes avec le même e-mail et de créer des comptes
avec des adresses fausses existent. Ceci pose un problème de statistique quant au
nombre exacte d’utilisateurs. La création de parcours pédagogique est aussi un peu
rigide (difficultés de revenir en arrière suite à une erreur de création).

Dokeos : Dokeos est une plate-forme d’apprentissage à distance. D’une grande simpli-
cité de mise en oeuvre et très intuitive pour ses utilisateurs (professeurs, formateurs,
élèves, auditeurs de la formation continue, etc. . .). Dokeos propose de nombreux ou-
tils destinés à organiser les apprentissages et laisse toute latitude à la créativité du
développeur pour élaborer des cours réellement attractifs, interactifs et multimédias.

Ganesha : est un LMS présentant un ensemble d’outils à des fins pédagogiques. Cette
plateforme est développée à sources ouvertes en 2001 par la société Anema. Ganesha a
été la première plateforme de téléformation gratuite sous licence GNU GPL. Plusieurs
autres plateformes telle que AnaXagora ont été conçues en se basant sur Ganesha. Elle
intègre les standards d’E-Learning SCORM 1.2 4 , SCORM 2004, AICC 5 et LOM 6 .
Ces standards sont à la base de la construction des contenus, de l’insertion de ces
4. Sharable Content Object Reference Model
5. Aviation Industry CBT Committee
6. Learning Object Metadata
2.2. LES OUTILS DU E-LEARNING 17

contenus dans un LMS et de la communication entre ces contenus et le LMS.

Moodle : Moodle est un LMS à code ouvert sous licence GNU GPL et développé par
Martin Dougiamas en 2003 permettant de créer des communautés d’apprenants au-
tour de contenus et d’activités pédagogiques. La modularité de Moodle lui permet
de s’adapter à toutes les structures. Un des points forts de Moodle c’est qu’il est
centré sur la classe devenue communauté d’apprenants qui doivent partager leurs
connaissances pour apprendre. Avec Moodle il est possible de créer et rassembler les
apprenants dans des groupes simulant ainsi des classes classiques.

Tableau comparatif

Le tableau 2.2 récapitule notre évaluation de ces différents LMS.

Figure 2.2 — Comparaison des LMS

Cette comparaison favorise l’adoption de l’un de Dokeos et Moodle. Or chacune de


ces solutions présente des points faibles qui nous ont mené à les écarter. En premier lieu,
Moodle présente les défauts suivants :
– Pas de création des chemins d’apprentissage.
– Pas d’outil de feedback pour la génération des rapports, fonctionnalité réquise pour
l’évaluation des apprenants.
18 CHAPITRE 2. ETAT DE L’ART

– Incapacité de créer des contenus hiérarchiques.


En second lieu, Dokeos est éliminé pour les raisons suivantes :
– Orienté entreprise ne prenant pas suffisamment en compte les besoins spécifiques de
l’apprenant.
– N’offre pas de latitude dans le paramétrage de l’interface.
– Système lent ce qui pose des problèmes lors de la mise en ligne des cours.
– Sa prise en main n’est pas facile.
– La création des parcours pédagogiques est assez rigide.
– Sa prochaine orientation vers l’aspect commercial.
A la fin de cette étude nous avons choisi d’opter à développer notre propre gestionnaire
de formation qui s’adapte bien aux besoins de l’Université Virtuelle de LACERAMIC
(UVL).

2.2.2 Les outils de gestion des contenus de formation (LCMS)

Nous pouvons définir les outils de création de cours comme ceux qui offrent les fonc-
tionnalités nécessaires à l’assemblage en modules des pages de contenu et à la création du
cours à partir de ces modules. Nous y trouvons donc :
– Des facilités d’assemblage des pages en modules avec construction automatique de
la navigation à l’intérieur du module.
– Des aides à la création des différents types de tests (questionnaires à choix multiples,
tests, navigation à l’intérieur du module).
– Des outils permettant de construire plus ou moins facilement la logique de navigation
d’un module à l’autre en fonction de la filière de cours et des résultats aux tests de
fin de module.
Les LCMS sont principalement basés sur les systèmes de gestion de contenu (CMS)
qui ont pour but de simplifier la création et la gestion du contenu en ligne. Ils permettent
une meilleure fréquence des mises à jour des ressources déjà publiées et à moindre coût.
Cela repose sur le principe de séparation de la forme et du fond ainsi les auteurs doivent
pouvoir se concentrer uniquement sur leur contenu. Ils disposent pour ce faire de modèles
de présentation prédéfinis spécifiques à chaque élément qui compose le document (en-tête,
format du titre, emplacement d’une image, intégration d’un fichier multimédia etc.)[N1]
2.2. LES OUTILS DU E-LEARNING 19

Etude de quelques CMS

Il y a énormément de choses à vérifier avant de choisir un CMS, mais en voici les plus
décisives :

Personnalisation du front office : elle consiste à créer la structure éditoriale et à


ajouter des modules fonctionnels spécifiques (sondages, annuaires, . . .).

Personnalisation graphique du front office : si ce critère est prépondérant, il est


strictement conseillé de choisir un CMS se basant sur l’architecture des templates
graphiques car elle détermine une part importante des coûts de maintenance et
d’évolution.

Multilinguisme : c’est la capacité du CMS à gérer plusieurs langues. Ce critère est le


premier à prendre en compte dans les projets internationaux.

Personnalisation du back office : c’est la finesse qu’offre le CMS au niveau de ges-


tion des droits utilisateurs et de personnalisation des workflows offerts par la solu-
tion. Certaines solutions obligent l’entreprise à s’adapter à leur logique et d’autres
lui laissent le choix et ce dans le cas des projets où le but n’est pas de publier les
informations seulement mais de les bien partager.

Flxibilité : c’est la capacité des gestionnaires de contenu à s’intégrer au système d’in-


formation déjà existant. Plus le projet est autonome des autres projets de l’entreprise
plus il sera facile de trouver des solutions répondant précisément aux besoins, notam-
ment parmi les CMS open source.

Capacité à monter en charge : la plupart des CMS proposent un système de cache


qui répond au problème en précalculant les pages et les stockant au format HTML.
Dans ce cas, les éléments à analyser sont l’architecture du cache et ses performances
réelles, via des tests de montée en charge par exemple. Dans le cas contraire, il faut
s’assurer qu’un système externe peut être ajouté sans difficultés.

Appropriation : en pratique, il s’agit de mesurer l’écart entre les habitudes des futurs
utilisateurs et les nouveaux processus. En fonction des cultures d’entreprise, ce critère
peut être le facteur clef de succès, la bonne ou la mauvaise volonté des utilisateurs
pouvant à elle seule faire avorter ou non le projet.

La pondération de ces critères dépend essentiellement de la nature du projet à réaliser.


Une expression du besoin très précise et une grande objectivité sont donc incontournables
20 CHAPITRE 2. ETAT DE L’ART

à ce stade. Une étude de certaines solutions de gestion de contenu est alors nécessaire.
Pour cela nous avons choisi d’étudier de près trois CMS open source vu le coût de création
et le coût de possession qu’obligent des solutions payantes.

Corinis CCM : Corinis CCM est un système de gestion de contenu open-source basé
sur le langage Java. Il combine à la fois la puissance d’une solution professionnelle de
gestion de contenu (éditeur WYSIWIG, gestion de version, assurance de qualité basée
sur le rôle, . . .) avec facilité d’utilisation d’un framework communautaire. La concep-
tion modulaire du système encourage le développement d’extensions réutilisables
(comme le forum, le vote ou les modules d’album photo). Par ailleurs, le code Java et
l’utilisation de XML comme format de données garantissent l’interopérabilité. L’uti-
lisation de Corinis CCM dans un environnement Internet ou Intranet permettra de
réduire les coûts, les niveaux de compétence exigés et le temps requis pour sa mise
en place tout en s’assurant d’avoir un outil fiable et un développement ouvert de
plate-forme.

Alfresco CMS : Alfresco (Originellement Fresco - FRont-End for Sequence COmpari-


son mais ce nom a déjà été pris) est une référentielle open source pour la gestion de
contenu d’entreprise et des portlets (CMS). C’est un projet multiplateformes, utili-
sant des standards ouverts, et massivement basé sur la technologie J2EE. Alfresco a
développé une architecture moderne qui utilise les derniers outils open-source pour
optimiser les performances, et la Programmation Orienté Aspect (AOP) 7 facilitant
ainsi la modularité et l’adaptabilité de l’application. Il comprend la gestion de do-
cuments, la gestion de contenu Web, la collaboration, la gestion des enregistrement
ainsi que des images. Son architecture modulaire utilise les dernières technologies
Java open source : Spring, Hibernate, Lucene et JSF. Cet outil favorise de sa sim-
plicité pour atteindre sa mission : ”ouvrir le monde de la gestion de contenu afin
d’augmenter les innovations grâce à la participation de la communauté et au libre
accès au code source, et viser à fournir une application complète à moindre coût ”

dotCMS : dotCMS est un système open-source de gestion de contenu dédié aux entre-
prises qui intègre les meilleures fonctionnalités de gestion de contenu. Il permet de
créer des structures de données pour diverses entités et ainsi que des liens entre eux
pour faciliter la création de bases de données générées dynamiquement sous forme
7. Aspect-Oriented Programming
2.2. LES OUTILS DU E-LEARNING 21

de données en cours de validation à l’aide de l’outil perl facile à modifier. En outre,


il permet de créer des conteneurs inclus dans des templates qui génèrent des pages.
On peut utiliser les macros rapides inclus dans les templates qui supportent Ajax à
travers XML-RPC, la pagination, la recherche, le diaporama et les fonctions gale-
rie. Entre autres macros disponibles dotCMS présente les galeries de photos, le MP3
Player Streaming, le dépôt de fichiers, l’exécution des requêtes SQL et beaucoup
d’autres macros.

Tableau comparatif Une étude comparative a été alors élaborée dans le but de faire le
bon choix. la figure 2.3 récapitule la comparaison effectuée. En premier lieu les choix

Figure 2.3 — Comparaison des fonctionnalités des CMS

de Corinis CCM et d’Alfresco CMS se sont écartés vu que le premier ne peut pas
intégrer la connexion au serveurs d’annuaire LDAP (qui est une fonctionnalité sur
laquelle l’authentification à la plateforme doit se baser) et que la richesse technolo-
gique et fonctionnelle de la deuxième induisent une légère compléxité d’utilisattion
pour les développeurs ainsi que pour les utilisateurs finaux. Enfin nous nous sommes
concentré sur l’étude de dotCMS qui consistituait une solution parfaite de gestion
de contenu. Cependant, le problème de dotCMS c’est qu’il requiert un accès com-
plet au serveur, car il nécessite l’installation personnalisée d’Apache Tomcat comme
serveur d’application , alors que la majorité des possesseurs de domaines internet
n’ont pas cet accès à leur serveur, ils ne possèdent que le domaine dans le nuage In-
ternet. D’autre part, tellement dotCMS est puissant dans sa manière d’architecturer
ses données et dans sa manière de considérer le contenu qu’il nécessite un serveur
de dernière génération au niveau des ressources matérielles, ce qui n’est encore pas
22 CHAPITRE 2. ETAT DE L’ART

du ressort du grand public. Par ailleurs, le grand défaut de dotCMS reste sa do-
cumentation. En effet, la politique de dotMarketing (l’entreprise qui gère dotCMS)
est d’ailleurs très explicite sur ce point, en libérant le code source, mais en faisant
payer toute aide et support. Enfin comme tout autre CMS, dotCMS présente certains
inconvénients parmi lesquels nous citons :
– La structure en 3 colonnes immuables.
– La rigidité des thèmes (ou templates) téléchargeables gratuitement et qui
nécessitent de conserver un lien visible sur le site développeé vers le site de leur
concepteur, et la création de nouveaux thèmes même si elle est possible parfois elle
sera coûteuse.
– L’uniformité de la diffusion de l’information donne des sites semblables.
– Les CMS sont un peu des usines à gaz puisqu’ils cachent les détails concrêts de
réalisation.
– La scalabilité n’est pas toujours assurée.
– Les risques de sécurité venant du fait que tout le monde connaı̂t le code source du
site et peut engendrer d’éventuels risques de sécurité et des vulnérabilités.
– Les modules complémentaires, souvent développés par des tiers et mis à la disposi-
tion de la communauté des utilisateurs du CMS, peuvent être source d’instabilité
du site.

Conclusion

Dans ce chapitre nous avons pu dégager et étudier les différents concepts surlesquels se
base la FOAD. Le chapitre suivant aura pour but de décortiquer les besoins fonctionnels
et non fonctionnels que notre application doit satisfaire.
CHAPITRE

3 Analyse et spécification
des besoins

La réussite de tout projet dépend de la qualité de son départ. De ce fait, l’étape de


spécification constitue la base de départ de notre travail. En outre, l’adéquation de toute
l’application à réaliser, aux besoins des utilisateurs et aux traitements envisagés au niveau
de ses opérations assurera la réussite de l’application et son utilité future. Pour assurer
ces objectifs, il est essentiel que nous parvenions à une vue claire des différents besoins
escomptés de notre projet.

Dans ce chapitre, nous commençons par définir notre processus de développement ainsi
que standard de modélisation adopté. Nous détaillons ensuite les besoins fonctionnels et
non fonctionnels du système. Enfin, nous proposons quelque diagrammes expliquant les
aspects statiques et dynamiques de l’application.

3.1 Méthodologie de développement

Vu la diversité des méthodologies de conception et de développement, il était indis-


pensable de faire un choix judicieux afin d’assurer la bonne conduite du projet.

C’est dans ce contexte que s’inscrivent les méthodes agiles de développement visant à
réduire le cycle de vie en adoptant une approche itérative basé sur l’écoute continue du
client. Les méthodes agiles sont conçues pour s’adapter au changement, en assurant un
plan macroscopique précis et adaptatif.
24 CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS

3.1.1 Quelques méthodes agiles de développement

Les méthodes agiles les plus connues sont :

RAD 1 : développement rapides d’applications.

DSDM 2 : développement des systèmes dynamiques.

RUP 3 : méthode de développement de processus unifié de Rational Software.

XP 4 : eXtreme Programming.

2TUP 5 : propose un cycle de développement en Y, qui dissocie les aspects techniques


des aspects fonctionnels.

3.1.2 Méthodologie retenue

Après une étude des différents processus de développement et de gestion de projets il


nous est apparu favorable d’adopter le modèle XP, et ce vu ses points forts suivants :
– Communication : la communication dans XP est un point central à tous les niveaux
(client-équipe, intra-équipe).
– Intégration continue : l’intégration continue permet de connaı̂tre l’état du logiciel
à tout moment, en compilant, lançant les tests unitaires et fonctionnels à chaque
commit de développeurs.
– Refactoring : le code doit être remanié de façon continue afin de le rendre plus
maintenable et d’améliorer sa qualité.
– Le travail en binôme : dans XP, le travail en binôme est la règle.

La figure 3.1 montre l’aspect itératif du modèle XP et la fréquence de chaque itération.


3.2. STANDARD UML 25

Figure 3.1 — Le processus XP

3.2 Standard UML

UML est un langage de modélisation unifié standardisé par l’OMG. C’est un langage
d’analyse et de conception orientée objet. Il couvre l’aspect statique et dynamique d’un
système selon ses différents diagrammes. Son but est de spécifier, visualiser, construire,
et documenter les systèmes informatiques. Pour cela, il définit des diagrammes qui sont
subdivisés en des vues statiques (qui représentent ”physiquement” le système à modéliser
au moyen de diagrammes d’objets, de classes, de cas d’utilisation, etc.) et des vues dyna-
26 CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS

miques (qui montrent le fonctionnement du système au moyen de diagrammes de séquence,


de communication, d’états transitions et d’activités). UML est purement un langage, Il
n’induit aucune méthodologie. Basé sur une démarche guidée par les besoins des utilisa-
teurs et centrée sur l’architecture logicielle, UML offre un environnement de conception
solide et efficace ainsi que des méthodes de représentation claires et concises. UML a
été réalisé pour matérialiser des stratégies et des heuristiques, bien comprendre et bien
répondre aux spécifications, analyser le risque, organiser le travail et concevoir des ar-
chitectures réutilisables extensibles efficaces. L’approche de la modélisation des besoins
par cas d’utilisation se prête très bien à un processus itératif de développement. Pour ces
avantages de UML, nous l’avons adopté comme langage de modélisation tout au long du
processus de développement.

3.3 Définition des acteurs du système

Cette application vise tous les employés de la société Laceramic, du simple ouvrier
jusqu’au cadre, dirigeant et directeur. Après avoir identifié les objectifs généraux de UVL
, nous avons pu dégager les acteurs qui vont interagir avec l’application. En effet ils sont
en nombre de deux à savoir : l’administrateur et les apprenants.
– L’administrateur : c’est le gérant du système qui a tous les privilèges et qui a la
responsabilité de la gestion des formations et de la mise en ligne des différents sup-
ports. Ce super utilisateur contribue en outre à l’enrichissement de la bibliothèque
virtuelle en déposant différents types de supports utiles pour les formations à court
et à long terme (articles, images, vidéos . . .) Par ailleurs, il est chargé de diriger les
utilisateurs à savoir la définition du cursus approprié à chaque membre.
– L’apprenant : c’est l’acteur principal sur lequel est basé tout le processus de for-
mation à distance. Il possède un espace privé depuis lequel il a accès aux diverses
activités d’apprentissage et aux ressources nécessaires qui lui permettent de mener
à bien sa formation.
3.4. ANALYSE DES BESOINS FONCTIONNELS 27

3.4 Analyse des besoins fonctionnels

L’analyse des besoins fonctionnels consiste à définir d’une manière complète les diverses
fonctions de l’application à réaliser, ainsi que les informations manipulées. Il s’agit de
traduire les besoins du client en fonctionnalités du système à concevoir.

Nous proposons dans ce travail de réaliser une plateforme E-Learning se reposant sur
trois axes complémentaires à savoir :

– La formation professionnelle continue des employés indépendamment de leur locali-


sation géographique.
– L’évaluation et le suivi du personnel de la société dans le but d’assurer une évolution
légale sur l’échelle fonctionnelle et donc une réponse à des besoins individuels
(carrière, employabilité, rémunération . . .). Pour ce faire un générateur de ques-
tions à choix multiples aléatoires doit être mis en place assurant une équitabilité
entre les différents candidats.
– La collaboration entre les différentes catégories d’utilisateurs par l’échange d’idées
et le partage du savoir faire afin de réduire l’isolement professionnel, encourager une
participation plus active entre eux et de développer un esprit critique et synthétique
stimulé par le dialogue entre agents venant d’horizons différents.

Les solutions du E-Learning doivent miser, en outre, sur l’interaction pour susciter
l’attention des participants tout en assurant leur fiabilité, leur pertinence, leur portabilité
ainsi que leur maintenabilité.

3.5 Analyse des besoins non fonctionnels

Les besoins non fonctionnels décrivent toutes les contraintes aux quelles est soumis le
système pour son bon fonctionnement.

Besoin de fiabilité et de performance : le système devra être opérationnel d’une


façon continue. En outre, il doit garantir un temps de réponse minimal : le site
devra se charger rapidement et chargement d’une page Web dans le navigateur ne
devrait pas dépasser 6 secondes en condition normale.

Besoin d’ergonomie des interfaces : l’interface de l’application doit être simple et


28 CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS

pratique afin que l’utilisateur puisse l’exploiter sans se référer à des connaissances
particulières. En d’autres termes, les informations doivent être lisibles et faciles à
accéder par n’importe quel utilisateur.

Besoin de sécurité : différents niveaux d’accès possibles au système pour les diverses
catégories d’utilisateurs du système. Ce besoin est assuré via une authentification.
Par ailleurs, le système doit garantir l’intégrité des données de la plateforme quels
que soientt leurs types.

Besoin de flexibilité et de l’évolutivité : le système doit s’adapter aux divers chan-


gements exigés par la société. Il doit être modulaire garantissant ainsi une évolutivité
de la future solution.

Besoin de portabilité : le système doit être multiplateforme, c’est à dire capable à


fonctionner facilement dans les différents environnements matériels et logiciels dans
le but de couvrir tous les ordinateurs des employés tenant compte de leurs diversités.

3.6 Les diagrammes des cas d’utilisation

Un cas d’utilisation permet de mettre en évidence les relations fonctionnelles entre


les acteurs et le système étudié. Il centre l’expression des exigences du système sur ses
utilisateurs. La détermination et la compréhension des besoins sont souvent difficiles car
les intervenants sont noyés sous de trop grandes quantités d’informations. Il faut clarifier
et organiser les besoins des clients (les modéliser). Pour cela, les cas d’utilisation identifient
les utilisateurs (acteurs) et leurs interactions avec le système.

3.6.1 Cas d’utilisation de l’apprenant

Au sein de la plateforme à réaliser, le cas d’utilisation attribué à l’apprenant est la


formation sur les différents composants du système d’information de LACERAMIC. Ce
cas d’utilisation représente l’ensemble des services mis à la disposition des utilisateurs à
savoir le recours aux différents supports de cours, des livres de la bibliothèque, l’évaluation
des acquis et encore la communication avec d’autres utilisateurs. Ce cas d’utilisation est
donné par la figure 3.2.
3.6. LES DIAGRAMMES DES CAS D’UTILISATION 29

Figure 3.2 — Cas d’utilisation d’un apprenant

L’apprenant peut à partir de la plateforme s’inscrire à des modules de formation, se


former en consultant les supports de formations recommandés et doit ensuite passer une
évaluation à travers un QCM de durée de réponse limitée. Ce QCM doit être générer
aléatoirement et sans reprise pour chaque utilisateur. Pour enrichir leurs connaissances,
le système offre à ses utilisateurs la possibilité de consulter une bibliothèque riche en
documents de tous les formats et de participer aux discussions du forum. Tous ces services
ne sont accessibles qu’après l’authentification de l’utilisateur.
30 CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS

3.6.2 Cas d’utilisation de l’adminstrateur

Afin de bien veiller sur le bon fonctionnement de la plateforme et son intégrité, celle-ci
nécessite un utilisateur ayant plus de privilèges pour la gérer correctement. Cet utilisateur
est nomé ”‘administrateur”’. La figure 3.3 montre les tâches dont l’administrateur en est
responsable.

Figure 3.3 — Cas d’utilisation de l’administrateur

3.7 Plan de navigation de la plateforme

La navigation dans la plateforme se fait comme l’indique la figure 3.4 :

3.8 Les diagrammes d’activité

Les diagrammes d’activité décrivent le comportement d’un système, tout en mettant


l’accent sur les traitements. Ils sont donc particulièrement adaptés à la modélisation du
3.8. LES DIAGRAMMES D’ACTIVITÉ 31

Figure 3.4 — Plan de navigation de la plateforme

cheminement de flots de contrôle et de flots de données (les workflows). Ils permettent ainsi
de représenter graphiquement le comportement d’une méthode ou le déroulement d’un cas
d’utilisation. Par ailleurs, ils peuvent comporter des synchronisations pour représenter
les déroulements parallèles. La notion de couloir d’activité décrit les responsabilités en
répartissant les activités entre les différents acteurs opérationnels.

3.8.1 Espace de collaboration

La figure 3.5 représente le diagramme d’activité relatif à l’intégration de l’utilisateur


dans l’espace collaboratif offert par la plateforme. A travers cet espace l’apprenant a la
possiblité de consulter les différentes catégories du forum afin de poser des questions en
relation avec son cursus, s’informer auprès des responsables de quelques détails concernant
le déroulement des formations ou afin de répondre à des problèmatiques postées par
d’autres utilisateurs. La communication via le mail est aussi offerte par l’UVL. C’est ainsi
que les apprenants peuvent contacter l’administrateur du site pour des demandes privées
ou concernant leurs informations personnelles. Dans cet espace l’administrateur agit en
contrôllant les messages du forum, répondant à ceux qui le concernent et supprimant ceux
qui portent du vandalisme dans leurs contenus.
32 CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS

Figure 3.5 — Espace de collaboration


3.8. LES DIAGRAMMES D’ACTIVITÉ 33

3.8.2 Gestion des supports de formation

La figure 3.6 présente le diagramme d’activité relatif à la gestion des supports de


formations de la plate-forme. L’administrateur choisit l’opération, qui soit une suppression
soit un ajout, à effectuer sur un support en précisant la formation concernée et en insérant
les informations nécessaires.

Figure 3.6 — Gestion des supports


34 CHAPITRE 3. ANALYSE ET SPÉCIFICATION DES BESOINS

Conclusion

Dans cette partie, nous avons cerné les objectifs du système cible. Ces objectifs doivent
tenir comptes des exigences citées. Cette phase va nous permettre de bien élaborer le
modèle de conception de l’application qui sera le sujet du chapitre suivant.
CHAPITRE

4 Conception

Dans ce présent chapitre nous entamerons une partie cruciale du développement logiciel
et qui constitue un pont entre la spécification et la réalisation. Elle comporte la conception
de l’application ainsi que la conception de la base de données.

4.1 Conception générale

Dans cette section, nous donnerons un aperçu sur l’architecture globale de l’ap-
plication, ensuite nous allons explorer l’ensemble de composants de l’application à
réaliser. En fait, l’UVL est une plateforme qui se base essentiellement sur trois modules
complémentaires, à savoir, le module d’apprentissage, le module d’évaluation ainsi que le
module de collaboration.

4.1.1 Architecture multi-tiers

L’architecture multi-tier est mise en œuvre dans notre application afin de bien séparer
tous ses niveaux et nous offrir la possibilité d’utilisation des composants graphiques riches
pour le niveau présentation. Cette approche ne divise pas l’application en un nombre
indéterminé de niveaux de service comme le fait penser son appellation, mais plutôt elle
la décompose en trois couches de services subdivisées elles-même en multiple services.
36 CHAPITRE 4. CONCEPTION

L’architecture de notre application intégrant les framework JSF et Hibernate est


schématisée par la figure 4.1.

Figure 4.1 — Architecture de l’application

4.1.2 Diagramme de paquetages

La notion de paquetages (ou de packages) permet de séparer le modèle en conteneurs


logiques, et décrire leurs interactions à un haut niveau. Le diagramme de paquetages est
donc utilisé pour refléter l’organisation des paquetages et leurs éléments. La figure 4.2
montre cette organisation au sein de notre application.
4.1. CONCEPTION GÉNÉRALE 37

Figure 4.2 — Diagramme de paquetages de l’application

Le paquetage ”Utilisateurs” : les utilisateurs de la plate-forme sont, comme déjà


cité, l’administrateur et les apprenants. Ces derniers commencent le cycle de forma-
tion avec un nombre de points ” jetons ” initial et qu’ils les perdent en fonction de la
formation et le résultat de l’évaluation.Le but est donc de consommer tous les jetons.

Le paquetage”Formations” : les formations proposées sont en relation avec les di-


verses activités de la société comme le système d’information, l’administration, la
gestion. . .Ces formations sont organisées sous forme de cursus personnalisés. En effet,
cette personnalisation est basée sur plusieurs paramètres comme les postes remplis
par l’utilisateur, son poste actuel, son niveau éducatif, son expérience, son âge. . .
A chaque formation est attribué un nombre de jetons qui sera retiré de l’apprenant
lorsqu’il la passe avec succès. En plus, le temps alloué à une formation est prédéfini
afin d’encourager les apprenant à la prendre au sérieux. En cas de dépassement du
délai sans réussir la formation l’administrateur sera notifié et il peut intervenir soit
pour donner une autre chance à l’apprenant soit pour lui proposer un autre cursus
plus adapté à son profile.
38 CHAPITRE 4. CONCEPTION

Une formation est généralement décomposée en des sous formations afin de définir
des différents niveaux de compétences et pour rendre plus performant le suivi de
l’évolution de la formation.

Les apprenants ont besoin, sans doute, de supports de formation dans lesquels ils
trouvent toutes les informations nécessaires pour acquérir des compétences en premier
lieu, et pour réussir l’évaluation en second lieu. Dans l’UVL les utilisateurs peuvent
trouver l’information dans deux emplacements différents : au sein du module de
formation et dans la bibliothèque virtuelle mise pour la raison.

Le paquetage ”Evaluation” : ce module est basé sur les questionnaires à choix mul-
tiples (QCM) générés aléatoirement et sans reprise avec un temps de réponse bien
déterminé et à ne pas dépasser. La plateforme offre trois chances à l’apprenant de
passer un QCM pour la même formation.

Le paquetage ”Collaboration” : comme partager les connaissances ne fait que les


accroı̂tre, le module de collaboration de l’UVL offre un forum de discussion dans lequel
les utilisateurs peuvent faire des suggestions, demander de l’aide ou bien résoudre
des problèmes pour les autres formés. Ils peuvent aussi utiliser la plateforme pour la
communication par mails.

4.2 Conception détaillée

La conception détaillée vise à transformer le modèle d’analyse (spécification : haut


niveau d’abstraction) en un modèle concrêt, de bas niveau d’abstraction et à partir duquel
le programmeur peut directement implémenter le système.

4.2.1 Diagrammes de séquences

Un diagramme de séquence est une structure de représentation des interactions entre


objets comme une série d’étapes séquentielles dans le temps. Il est utilisé pour décrire
le flux de travail, le passage du message, et de quelle manière les éléments en général
coopèrent avec le temps pour obtenir un résultat. Dans ce qui suit nous allons détailler
les cas d’utilisation présenté dans le chapitre précédent.
4.2. CONCEPTION DÉTAILLÉE 39

Evaluation des acquis des apprenants

La figure 4.3 met en relief le déroulement de l’évaluation des apprenants. Le scénario


d’évaluation peut se déclencher du moment où l’utilisateur commence sa formation. Cette
dernière est caractérisée par une durée que l’utilisateur n’est pas obligé de tout consommer
et une fois épuisée, un échec lui sera accordé avec une notification à l’administrateur. Si

Figure 4.3 — Evaluation des acquis des apprenants

les délais sont bien respectés, un nouveau test se crée déclenchant un générateur de QCM
qui provoque la sélection de questions aléatoires et l’internaute est chargé d’y répondre
pendant une durée qui lui est permise. Le système vérifie alors la validité des réponses
40 CHAPITRE 4. CONCEPTION

et lui affiche le résultat et la correction. Deux cas de figures peuvent avoir lieu : soit un
échec causant la perte de jetons de l’utilisateur, soit un succès et le système met à jour le
score de l’apprenant et lui propose la formation suivante dans son cursus.

Suppresion de formation

Le diagramme de séquence présenté par la figure 4.4 explique comment doit procéder
un administrateur afin de supprimer une formation. Cette dernière peut être un module
ou un sous module. Notre acteur, ayant les permissions nécessaires pour accéder à l’admi-
nistration des modules doit sélectionner la formation à supprimer, le système lui demande
alors de confirmer sa demande.

Figure 4.4 — Suppresion de formation

Une fois effectuée, le système met à jour un par un les cursus des apprenants dont la
formation choisie en fait partie (et ceci en réglant les ordres respectifs des autres formations
avant de supprimer le module sélectionné du cursus). Les apprenants concernés seront alors
4.2. CONCEPTION DÉTAILLÉE 41

notifiés par ces changements. Par la suite le système se charge de supprimer la formation
sélectionnée tout en l’indiquant à l’administrateur.

Suivi des utilisateurs

Le diagramme de séquence illustré par la figure 4.5 résume le scénario de consulta-


tion des informations et le suivi des utilisateurs par l’administrateur qui commence par
rechercher les utilisateurs.

Figure 4.5 — Suivi des utilisateurs


42 CHAPITRE 4. CONCEPTION

L’espace d’administration sera sollicité par cette demande et l’action correspondante


sera invoquée. Cette action sera par la suite transmise à la couche Contrôle qui exige
l’entité Apprenant de retrouver les postes ainsi que les diverses directions présentes dans
la base. Le système affiche alors les critères de choix par lesquels notre internaute peut
filtrer la liste demandée, tout en énumérant l’ensemble de tous les utilisateurs. Du moment
où l’administrateur introduit ses critères, le système se charge de recenser la nouvelle liste,
afin que cet acteur fasse de nouveau son choix. Une fois l’utilisateur sélectionné, tous ses
détails seront chargés, le cursus obligatoire qui lui est affecté ainsi que les formations qu’il
a déjà élaboré permettant ainsi d’assurer le suivi de l’apprenant.

4.2.2 Diagrammes de classes

Un diagramme de classes montre la structure interne du système en fournissant une


représentation abstraite des objets du système qui vont interagir ensemble pour réaliser
les cas d’utilisation.

Il s’agit d’une vue statique car il ne tient pas compte du facteur temporel dans le
comportement du système. Le diagramme de classes modélise les concepts du domaine
d’application ainsi que les concepts internes créés de toutes pièces dans le cadre de
l’implémentation d’une application.

Diagramme de classes du paquetage Utilisateurs

La figure 4.6 illustre les différentes classes conçues pour la réalisation du paquetage
Utilisateurs. La classe Apprenant représente un apprenant de la plateforme. Elle contient
toutes les informations de ce dernier ainsi que les méthodes permettant sa bonne gestion.
De cette classe hérite la classe Administrateur qui représente un utilisateur ayant les
privilèges de gestion de la plateforme.
4.2. CONCEPTION DÉTAILLÉE 43

Figure 4.6 — Diagramme de classes du paquetage Utilisateurs

Diagramme de classes du paquetage Formations

Les formations dans l’UVL sont organisées en modules se composant eux même d’un
nombre de sous modules. Chaque utilisateur a son propre cursus, représenté par la classe
Cursus, qui est l’agrégation ordonnée d’un ensemble de formations obligatoires, classe
SousModule du diagramme.

Figure 4.7 — Diagramme de classes du paquetage Formations


44 CHAPITRE 4. CONCEPTION

Les formations sont enrichies par des différents supports permettant aux appre-
nants d’acquérir certaines connaissances. Cette richesse vient du fait que la plate-forme
propose plusieurs types de supports (PDF, présentation PPT, Flash, livres interactifs,
vidéos)représentés par la classe Support élément du paquetage Bibliothèque et utlisée
par le paquetage Formation. Ces différentes classes et relations sont illustrées dans la
figure 4.7.

Diagramme de classes du paquetage Evaluation

Dans les délais de chaque formation, les apprenants doivent s’évaluer, et ce, à travers
un QCM (classe QCM dans le diagramme) comportant un ensemble de questions générées
automatiquement à partir de la classe CatalogQCM qui contient toutes les questions
en relation avec la formation en cours. Afin d’éviter les répétitions des questions pour un
même apprenant nous avons eu recours à la classe QCMPassé pour sauvegarder toutes
les évaluations des utilisateurs. La figure 4.8 montre comment ces classes sont organisées
au sein du paquetage Evaluation.

Figure 4.8 — Diagramme de classes du paquetage Evaluation

Diagramme de classes du paquetage Collaboration

Le partage de connaisances entre les apprenants se fait essentiellement à travers le


Forum mis à leur disposition. La plate-forme offre aussi la possiblité de contacter l’ad-
4.2. CONCEPTION DÉTAILLÉE 45

ministrateur par mail. Les différentes formes de collaboration sont données par la figure
4.9.

Figure 4.9 — Diagramme de classes du paquetage Collaboration

4.2.3 Conception de la base de données

Le modèle relationnel de données est un modèle de données comme d’autres existants


ayant pour but la description e monde réel à partir des informations et des données qu’on
peut en extraire et se différencient par la nature des associations qu’ils permettent de
modéliser. L’objectif essentiel du modèle relationnel était d’accroı̂tre l’indépendance vis-
à-vis du niveau de représentation des données. Du point de vue utilisateur, une base de
données peut être considérée comme un ensemble de tables manipulables par des langages
de haut niveau dont la caractéristique principale est d’être des langages non procédéraux.

A ce niveau de l’application et tout en tenant compte des besoins déjà spécifiés, nous
avons envisagé un certain nombre de tables pour le stockage des données nécessaires pour
la bonne gestion de la plateforme.

Les tables conçues et les relations qui les inter-relient sont données par les figures 4.10
et 4.11.
46 CHAPITRE 4. CONCEPTION

Figure 4.10 — Schéma conceptuel de la base de données


4.2. CONCEPTION DÉTAILLÉE 47

Figure 4.11 — Conception de la base de données du forum


48 CHAPITRE 4. CONCEPTION

Conclusion

Dans ce chapitre nous avons déterminé les différents objets de l’application contri-
buants à assurer les fonctionnalités souhaitées par ses utilisateurs.

Cette phase était alors une préparation à la phase de codage qui constituera l’objet
du chapitre suivant.
CHAPITRE

5 Réalisation

Après avoir achevé l’étape de conception de l’application, nous entamons dans ce


chapitre la phase de réalisation. Nous commençons par présenter les outils, les technologies
et les frameworks utilisés lors de la réalisation de la plate-forme. Ensuite, nous donnerons
un aperçu sur le travail accompli à travers des captures d’écran de l’application. Enfin,
nous illustrons, via un chronogramme, la répartition temporelle des tâches tout au long
du stage.

5.1 Environnement logiciel du travail

Dans cette section nous donnons les caractéristiques logicielles de l’environnement de


réalisation de la plate-forme d’apprentissage en ligne.

Entreprise Architect

Enterprise Architect (EA) est un Atelier de Génie Logiciel (AGL) s’appuyant sur le
langage de modélisation unifié UML 2.1, langage qui constitue un moyen efficace pour
recenser, structurer et formaliser les besoins recueillis par l’Analyste.

Netbeans

Netbeans est un environnement de développement intégré (IDE 1 ) pour le


développement des application java/j2ee, C++, python, Ruby. . .Il rassemble toutes les
caractéristiques d’un IDE moderne (éditeur de code en couleur et permettant l’auto-
compélation, projets multilangages, refactoring, édition graphique d’interfaces . . .).
1. Integrated Development Environment
50 CHAPITRE 5. RÉALISATION

Microsoft SQL Server 2005

SQL Server 2005 est le premier produit Microsoft pour la gestion des bases de données
relationnelles. Il est considéré comme le ”Big brother” de Microsoft Access, mais il vise
des bases de données d’entreprises plus sérieuses. SQL Server 2005 se base sur le langage
Transact-SQL pour la manipulation des données.

Le framework JSF

JSF ou Java Server Faces est un framework java pour le développement de clients
riches pour les applications web. JSF est basé sur la notion de composants, il reprend le
modèle d’autres frameworks pour l’IHM tel que Swing ou SWT où l’état d’un composant
est enregistré lors du rendu de la page pour être ensuite restauré au retour de la requête.
JSF met en œuvre le modèle MVC basé sur une seule servlet nommée Faces Servlet faisant
office de contrôleur et des pages JSF pour l’IHM. L’application de ce modèle permet la
séparation du mode web en trois parties distinctes : le modèle, la vue et le contrôleur.
L’architecture de JSF est donnée par la figure 5.1.

Figure 5.1 — Architecture du framework JSF

Le framework Hibernate

C’est un framework qui donne une solution pour le mapping objet/relationnel et la


gestion de la couche de persistence. Hibernate permet la gestion automatique de la struc-
ture de la base de données : création et mise à jour. Il utilise un langage simple pour
5.2. TRAVAIL RÉALISÉ 51

l’interrogation de la base de données appelé HQL 2 et qui fournit une couche d’abstrac-
tion SQL. Hibernate vient se positionner entre la couche métier de l’application et les
données auxquelles elle a besoin comme représenté dans la figure 5.2.

Figure 5.2 — Position d’Hibernate dans une application web

5.2 Travail réalisé

A cette étape, nous rappellons, à travers la figure 5.3, la structuration fonctionnelle


de la plate-forme. Nous exposerons ensuite le travail réalisé à travers des captures d’écran
relatives aux principaux modules implémentés.

5.2.1 Côté apprenant

Authentification des utilisateurs

La page d’authentification des utilisateurs, représentée par la figure 5.4, est le point
d’entrée à la plate-forme. A travers son login et son mot de passe, l’utilisateur est identifié
par le système. En fait, il peut être soit un apprenant qui veut accéder pour se former
et s’évaluer, soit un administrateur voulant exécuter des tâches de gestion dans la plate-
forme.

2. Hibernate Query Language


52 CHAPITRE 5. RÉALISATION

Figure 5.3 — Les modules réalisés de la plateforme

Figure 5.4 — Authentification des utilisateurs


5.2. TRAVAIL RÉALISÉ 53

Accueil d’un apprenant

Après avoir été reconnu par le système, l’apprenant se trouve dans la page d’accueil
qui lui propose de continuer la formation en cours s’il y en a une ou de s’inscrire dans la
formation suivante de son cursus sinon. La figure 5.5 illustre cette page.

Choix et consultation des supports de formation

L’apprenant est amené ensuite à consulter les différents supports de formation de


différents formats relatives à la sous formation en cours. A travers la page de formation,
l’utilisateur choisit le support à consulter. Un des supports disponibles au sein de l’UVL
est le livre interactif à feuilleter représenté dans la figure 5.6. En effet c’est dans le but
d’attirer les apprenants que ce type de support est mis en place.

L’évaluation par QCM

Les utilisateurs sont invités à un QCM pour valider leurs connaissances acquises durant
la formation. L’interface de cette évaluation est donnée par la figure 5.7. Le test contient
cinq questions à deux, trois ou qutre propositions et l’apprennant doit l’y répondre et
valider sa réponse avant l’écoulement des dix secondes allouées.
54 CHAPITRE 5. RÉALISATION

Figure 5.5 — Accueil d’un apprenant


5.2. TRAVAIL RÉALISÉ 55

Figure 5.6 — Livre interactif

Figure 5.7 — Evaluation par QCM


56 CHAPITRE 5. RÉALISATION

Participation au forum

A l’aide d’un forum, l’apprenant peut communiquer avec d’autres utilisateurs afin de
poser des questions ou de répondre à d’autres posées par d’autres apprenants.
5.2. TRAVAIL RÉALISÉ 57

Figure 5.8 — Participation au forum

5.2.2 Côté administrateur

Un administrateur doit s’authentifier pour pouvoir accéder au site. Ce super utili-


sateur jouit de plusieurs fonctionnalités. Il a la possibilité de gérer toutes les bases de
données de la plate-forme. Cette figure montre l’administration des apprenants, des mo-
58 CHAPITRE 5. RÉALISATION

dules, des QCMs, des divers supports de cours. Par ailleurs l’administrateur peut accéder
aux différents rubriques du site tel que le forum et la bibliothèque.

Accueil de l’administrateur

La figure 5.9 donne un aperçu sur la première page de l’administration de la plate-


forme à partir de laquelle l’administrateur effectue

Figure 5.9 — Accueil de l’administrateur


5.2. TRAVAIL RÉALISÉ 59

Gestion des modules

La figure 5.10 montre l’interface de modification des modules. Cette interface inclue
la modification des divers champs relatifs à ce module. Par ailleurs, un administrateur a
la possibilité d’ajouter un sous module, changer les données concernant ce dernier tel que
la durée de formation . . .Il peut éventuellement supprimer un sous module.

Figure 5.10 — Gestion des modules

Ajout d’un support de cours

L’ajout d’un document électronique est une tâche aussi simple. Tout d’abord, l’admi-
nistrateur doit choisir le module et le sous module auxquels est lié le support de formation.
Une fois choisi, le système se charge automatiquement d’extraire le nom, le type du fichier
et sa taille afin de les insérer dans la base de données. La figure 5.11 montre l’interface
à partir laquelle l’administrateur peut ajouter un document à une formation.
60 CHAPITRE 5. RÉALISATION

Figure 5.11 — Ajout d’un support de formation

Ajout d’un utilisateur

La figure 5.12 illustre l’interface d’ajout d’un utilisateur. Cette dernière demande le
remplissage ses coordonnées relatives. L’administrateur est alors sollicité de recenser les
formations qui lui sont obligatoires. Dès qu’il commence le système met à jour le cursus
de formation et l’affiche au fur et à mesure que l’administrateur le définit.
5.3. CHRONOGRAMME 61

Figure 5.12 — Ajouter un utilisateur

5.3 Chronogramme

Il est nécessaire de tracer un diagramme qui décrit la répartition temporelle des tâches
du travail durant deux mois afin de montrer les différentes phases par lesquelles notre
projet a passé.

– Documentation et études théorique : elle consiste à rechercher une documentation


sur le sujet et à étudier les objectifs généraux du stage.
– Spécification et analyse de besoins : elle consiste à étudier l’état actuel du processus
62 CHAPITRE 5. RÉALISATION

de travail de l’entreprise ainsi que ses besoins réels.


– Conception : elle vise à modéliser le système selon une vue bien claire.
– Implémentation : elle s’occupe du développement du codes des différentes fonctio-
nalités du système comme modélisé dans la conception.
– Rédaction du rapport : elle collecte toutes les informations nécessaires et autorisées
à être publiées.

Le chronogramme suivant donne la répartition de ces différentes phases :

Figure 5.13 — Chronogramme des tâches

Conclusion

Dans cet ultime chapitre nous avons présenté l’environnement de la mise en œuvre de
notre application. Nous avons présenté aussi le travail réalisé à l’aide de quelques captures
d’écran.
CHAPITRE

6 Conclusion et
perspectives

Au terme de ce rapport nous rappelons les objectifs du stage et les différentes étapes
par lesquelles l’application a passé pour aboutir à son état actuel.

Ce présent document est le rapport de la mémoire de fin d’études effectué au sein


de Laceramic SA et qui avait pour objectif de développer une plateforme de formation à
distance baptisée ”Laceramic Virtual University” permettant aux différents employés de
laCeramic de suivre à distance des formations concernant le système d’information de la
société afin de gagner en terme de temps et d’argents.

Nous avons commencé par une mise en contexte à travers une introduction et une
présentation générales. Ensuite une étude théorique a été effectuée afin de nous permettre
de bien définir les concepts théoriques en relation avec le domaine de l’apprentissage à
distance. La partie suivante a mis en relief les besoins spécifiques de LACERAMIC qui
l’ont fait penser à une solution de formation à distance. La conception est venu ensuite
pour traduire les spécifications recensées en un modèle logique présentant l’architecture
générale de l’application. La réalisation, où nous avons transformé le modèle théorique en
un système fonctionnel, a constitué la clôture du rapport.

En guise de conclusion, ce projet nous a permis de travailler sur un produit d’avenir


au moins en Tunisie(les plate-formes du E-Learning). Il a été bénifique aussi bien sur le
plan théorique que sur le plan pratique. En effet le développement de cette application
nous a donné l’occasion de se familiariser avec les notions et les outils de la mise en œuvre
des architectures web, notamment l’architecture J2EE.

En outre le travail accompli durant le stage contribuera dans l’amélioration du ren-


61

dement des employés de Laceramic SA travaillant sur son système d’information. C’est
alors que dans cet esprit qu’en perspective notre application peut être perfectionner en
la migrant vers un portail d’apprentissage à distance sans oublier bien évidemment de lui
ajouter d’autres formes de collaboration comme un tableau blanc ou un wiki.
Bibliographie

[1] Olivier Debas, Christine Deffaix Rémy Applications Web Java Servlets et JSP,2004

[2] David GearyCore, Cay Horstmann JavaServer Faces, Second Edition,2007

[3] Giulio zambon Begining JSP, JSF and Tomcat web devloppement.Apress 2007

[4] Eric Sarrion. UML 2 pour la pratique .4ème édition, Septembre 2005

[5] G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language User Guide
.WESLEY, 1999

[6] Som Naidu. E-Learning – A Guidebook of Principles, Procedures and Practices .se-
cond Revised Edition, CEMCA, 2006

[7] Terry Anderson. Theory and Practice of Online Learning .AU Press, 2008
Netographie

[N1] http://www.elearning-developer.com/2008/ consulté le 02 fevrier 2009


[N2] http://www.leprojetweb.com consulté le 27 février 2009
[N3] http://www.institut.minefi.gouv.fr/e-formation/ consulté le 25 février 2009
[N4] http://cmsreport.com/category/dotcms consulté le 27 février 2009
[N5] http://cms.epfl.ch/ consulté le 28 février 2009
[N6] http://claroline.up.univ-mrs.fr consulté le 01 mars 2009
[N7] http://fr.wikipedia.org/wiki/Alfresco consulté le 02 mars 2009
[N8] http://dev.corinis.org/corinis consulté le 02 mars 2009
[N9] http://www.jsftoolbox.com/documentation/ consulté le 10 mars 2009
[N10] https://javaserverfaces.dev.java.net/ consulté le 20 mars 2009
[N11] http://www.jsfcentral.com/ consulté le 7 avril 2009
[N12] http://www.netbeans.org/ consulté le 10 avril 2009
Glossaire

2TUP : 2 Track Unified Process

ACCOLAD : Apprntissage COLLaboratif A Distance

AJAX :

AOP : Aspect-oriented programming

API : Application Programming Interface

ASP : Active Server Page

CMS : Content Management System

CORBA : Common Object Request Broker Architecture

CGI : Common Gateway Interface

DNS : Domain Name Service

DSDM : Dynamic System Development Method

EJB : Enterprise Java Beans

EVT : Ecole Virtuelle Tunisienne

FOAD : Formation Ouverte A Distance

GNU :

GPL :

HQL : Hibernate Query Language

HTML : HyperText Markup Language

IDE : Integrated Development Environment

IHM : Interface Homme Machine

INES : INteractive E-Learning System


GLOSSAIRE 65

ISET : Institut Supérieur des Etudes Technologiques

J2EE : Java 2 Entreprise Edition

J2SE : Java 2 Standard Edition

JDBC : Java DataBase Connectivity

JMS : Java Messaging Service

JNDI : Java Naming and Directory Interface

JSF : Java Server Face

JSP : JavaServer Pages

JTA : Java Transaction API

LCMS : Learning Content Management System

LDAP : Lightweight Directory Access Protocol

LMS : Learning Management System

MAS : Mediterranean Air Service

MP3 : Mpeg Audio Layer-3

MVC : Model-View-Controller

NIS : Network Information Services

OMG : Object Management Group

PDF : Portable Document Format

PPT : PowerPoinT

QCM : Questionnaire à Choix Mutiples

RAD : Rapid Application Development

RPC : Remote Procedure Call

RUP : Rational Unified Process

SA : Société Anonyme

SQL : Structured Query Language

SWT :

TIC : Technologies de l’information et de la communication


66 GLOSSAIRE

UML : Unified Modeling Language

UVL : Université Virtuelle de LACERAMIC

UVT : Université Virtuelle Tunisienne

VAP : Validation des Acquis Professionnels

WYSIWYG : What You See Is What You Get

XML : eXtensible Markup Language

XP : Extreme Programming
ANNEXE

A Le standard J2EE

J2EE signifie signifie Java 2 Entreprise Edition et repose donc sur Java, le fameux
langage objet conçu pour être ”portable” (”Write Once, Run Anywhere”).

J2EE a pour but de crédibiliser le statut de Java en tant que plateforme pour la
programmation en entreprise.

Architecture système

Il existe de nombreuses architectures possibles pour les applications d’entreprise, nous


allons passer en revue les plus connues et nous verrons à quelle problématique J2EE tente
de répondre.

Architecture à deux niveaux

Pour simplifier, on peut dire que, dans ce type d’architecture, les traitements sont sur
le client et la base de données est sur le serveur. Le plus gros problème est celui de la
maintenance : La moindre modification oblige à mettre à niveau chaque poste client. De
plus les performances de l’application sont pour beaucoup en fonction des ressources des
clients.

Architecture à trois niveaux

A cause des problèmes de l’architecture à deux niveaux, on a rajouté un autre niveau.


Ainsi une application est divisée en trois niveaux logiques :

1. Niveau présentation : l’interface graphique pour l’utilisateur.


67

2. Niveau métier : Recouvre la logique métier ( aussi appelée logique applicative).

3. Niveau données : Les données de l’application ( serveur de base de données, docu-


ments XML, serveur LDAP . . .).

Le niveau métier contient le code appelé (via le niveau présentation) par l’utilisateur
pour extraire et traiter les données de la troisième couche. Cette séparation en couches
améliore la souplesse de l’application. Il devient facile de déployer de nombreuses interfaces
utilisateur sans devoir modifier la logique applicative.

Architecture à n niveaux

Ce genre d’architecture se compose de différents niveaux que l’on peut subdiviser


comme le montre la figure suivante :

Figure A.1 — Architecture N-tiers

– Interface utilisateur ou vue : Couche chargée de gérer les interactions entre l’utilisa-
teur et l’application (Application de bureau, navigateur WAP, Browser Internet. . .)
– Logique de présentation ou contrôleur : Elle permet de définir ce que doit afficher
l’interface utilisateur et la manière dont les requêtes doivent être traitées.
– Logique métier : Modélise les règles métiers de l’entreprise.
– Service d’infrastructure ou classes d’accès aux données : Fonctionnalités fournies
aux composants (connexions, transactions. . .).
68 ANNEXE A. LE STANDARD J2EE

– Données : Données de l’entreprise.


Ce genre d’architecture suit le modèle Modèle Vue Contrôleur (Voir les explications
du pattern MVC sur le site de sun ), c’est ce modèle que J2EE suit.

La plateforme J2EE

En fait, J2EE est une norme qui va spécifier à la fois l’infrastructure de gestion de vos
applications et les API des services utilisées pour concevoir ces applications. La plateforme
J2EE est essentiellement un environnement fournissant :
– Une infrastructure d’exécution pour faire tourner les applications.
– Un ensemble de services accessibles via l’API J2EE pour vous aider à concevoir les
applications.

Les API J2EE

La spécification de la plateforme J2EE prévoit un ensemble d’extensions Java standard


que chaque plate-forme J2EE doit prendre en charge :
– JNDI : JNDI est une extension JAVA standard qui fournit une API uniforme per-
mettant d’accéder à divers services de noms et de répertoires. Derrière un nom JNDI,
il peut y avoir un appel à des services CORBA, DNS, NIS, LDAP . . .En fait, JNDI
permet de localiser et d’utiliser des ressources.
– JDBC : Java Database Connectivity est une API qui permet aux programmes Java
d’interagir avec les bases de données SQL.
– Servlet : Un servlet est un composant coté serveur, écrit en Java, dont le rôle
est de fournir une trame générale pour l’implémentation de paradigmes ” requête-
réponse ”. Ils remplacent les scripts CGI tout en apportant des performances bien
supérieures.
– JSP : La technologie JSP (JavaServer Pages) est une extension de la notion de
servlet permettant de simplifier la génération de pages web dynamiques. Elle se
sert de balises semblables au XML ainsi que de scriplets Java afin d’incorporer la
logique de fabrication directement dans le code HTML. JSP est un concurent direct
de l’ASP et du PHP.
69

– JMS : Java Messaging Service est à la fois une ossature et une API permettant
aux développeurs de construire des applications professionnelles qui se servent de
messages pour transmettre des données.
– JTA : La spécification JTA (Java Transaction API) définit des interfaces standards
entre un gestionnaire de transactions et les éléments impliqués dans celles-ci : L’ap-
plication, le gestionnaire de ressources et le serveur.
– EJB : Chaque instance d’un EJB se construit dans conteneur EJB, un environnement
d’exécution fournissant des services (Sécurité, Communications, Cycle de vie...). Un
client n’accède JAMAIS directement à un composant. Il doit pour cela passer par une
interface locale et une interface distance. L’interface locale décrit le cycle d’existence
du composant en définissant des méthodes permettant de le trouver, de le créer, de
le détruire. Et L’interface distante spécifie les méthodes que ce composant présente
au monde extérieur.

Les conteneurs J2EE

Un conteneur J2EE est un environnement d’exécution chargé de gérer des composants


applicatifs et leur donner accès aux API J2EE.

L’architecture des conteneurs J2EE doit comporter :


– Les composants applicatifs : Les servlets, les JSP, les EJB. . .. En somme les compo-
sants de votre application.
– Descripteur de déploiement : C’est un fichier XML décrivant vos composants appli-
catifs et qui fournit des informations au conteneur sur vos composants applicatifs
(droit d’accès, transaction . . .).
L’architecture d’un conteneur, quand à elle, se divise en quatre parties :
– Les interfaces des composants : Ensembles d’interfaces spécifiées par le conteneur et
que vos composants applicatifs doivent implémenter.
– API des services du conteneur : Services supplémentaires fournies par le conteneur
– Services déclaratifs : Services introduits par le conteneur sur vos applications.
– ” Autres services du conteneur : Il s’agit des services tels que le garbage collector,
le pooling des connexions base de données . . .
70 ANNEXE A. LE STANDARD J2EE

Processus de développement d’application J2EE

Une application J2EE commence par la création de composants J2EE. Ces composants
sont ensuite regroupés en modules auquel on associe des descripteurs de déploiement. Ces
modules J2EE peuvent ensuite être déployés comme application à part entière ou être as-
semblés avec un descripteur de déploiements J2EE et être déployés en tant qu’application
J2EE. ( voir la spécification de sun au format PDF )

Création de composants applicatifs

Durant cette phase, nous modélisons les règles métiers sous la forme de composants
applicatifs. Ces composants applicatifs seront groupés selon leur type ( Web, EJB.. )
avec un descripteur de déploiement pour donner un module J2EE. Ces modules J2EE
composeront l’application J2EE.

Assemblage de l’application

Une application J2EE peut être constituée d’un ou plusieurs module J2EE et un
descripteur d’application J2EE. L’application J2EE est packagée dans un fichier ayant
l’extension .ear ( Entrerpise Archive ).

Déploiement

Le déploiement d’applications consiste à installer et à personnaliser des modules empa-


quetés sur une plateforme J2EE. Ce processus se compose de deux étapes :l’installation(On
installe l’application sur le serveur J2EE) et la configuration (On paramètre l’application
pour qu’elle s’intègre à l’infrastructure sur laquelle elle vient d’être installée : mot de passe
base de données, factory de connexions, utilisateurs, droits . . .).
ANNEXE

B Le framework JSF

JSF - ou JavaServer Faces - est une spécification Sun pour le développement d’inter-
faces utilisateur enrichies pour les applications Web.

Un des principaux avantages de JSF, c’est qu’il est à la fois un standard de Java Web
user-interface et un framework qui suit fermement le Modèle-Vue-Contrôleur (MVC) de-
sign pattern. Cela fait que les applications JSF sont beaucoup plus gérables car le code
d’interface utilisateur (Vue) est nettement séparé des données et de la logique métier
(modèle). Afin de préparer le contexte JSF, qui fournit l’accès des données aux pages,
et pour protéger contre les accès non autorisés ou impropres des pages, toutes les inter-
actions de l’utilisateur avec l’application sont traitées par un front-end ”Faces” Servlet
(Contrôleur).

FacesServlet est l’élément contrôleur dans le framework JSF à travers lequel toutes les
demandes des utilisateurs vont passer. FacesServlet examine les demandes et les appels
des différentes actions sur le modèle utilisant les managed beans. Les Managed beans sont
un exemple du modèle. Les composants de JSF User Interface (UI) représentent la couche
vue.

Le cycle de vie de JSF

Le contrôleur Faces servlet sert comme un lien entre l’utilisateur et l’application JSF.
Il fonctionne dans le cadre d’un du cycle de vie de JSF bien défini qui décrit l’ensemble du
flux d’événements entre les requêtes des utilisateurs. Par exemple, lors d’une initialisation
d’une application JSF, le contrôleur Faces Servlet gère la requête par préparation du
contexte JSF, qui présente un objet Java détenant toutes les données d’application. Le
72 ANNEXE B. LE FRAMEWORK JSF

contrôleur redirige ensuite l’utilisateur à la page demandée. La page rend habituellement


les données à partir du contexte de JSF utilisant un langage simple d’Expression (Ce
langage permet de lier les composants aux managed-beans). Le contrôleur effectue alors
des mises à jour de tout type de données, tout en fournissant les nouvelles données. Ceci
permet aux développeurs de JSF d’avoir accès à l’ensemble du cycle de vie JSF, tout au
long de son exécution, offrant ainsi un degré élevé de contrôle sur le comportement de
l’application.

Les composants User-Interface de JSF

Le point fort de JavaServer Faces réside dans son modèle de composants User-
Interface(UI), où les applications sont simplement construites à partir de collections de
composants qui peuvent se présenter de diverses manières pour plusieurs types de clients.
Vaguement semblable à d’autres technologies propriétaires tels ASP.Net, la technologie
de composants UI propose une productivité illimitée permettant aux développeurs de
construire des interfaces Web utilisant des composants pré-construit plutôt que d’avoir
à construire l’interface utilisateur entièrement à partir de zéro. Les composants JSF UI
prennet de nombreuses formes et peuvent être aussi simple qu’un outputLabel (compsant
qui affiche du simple texte) ou aussi complexe qu’un DataTable (composant qui peut
représenter un tableau de données à partir de collections de données telles que la table
d’une base de données.

La spécification de JavaServer Faces fournit un ensemble de composants de base de


l’interface utilisateur qui sont très utiles. Il s’agit notamment de deux bibliothèques de
composants tels que la bibliothèque ”HTML” de composants, qui s’inspire largement de
la contribution des éléments HTML standard, avec une bibliothèque ”Core” qui aide les
tâches communes de développement d’application telles que l’internationalisation, la va-
lidation / conversion des données d’entrée... En plus de la bibliothèque de base ” User
Interface Components ”, l’API de JSF offre la possibilité d’étendre et de créer des com-
posants UI offrant des fonctions supplémentaires qui dépassent les composants de base.
ANNEXE

C DAO et Hibernate

Quelque soit le choix du programmeur de la plateforme et du serveur de base de


données, la tendance actuelle veut que le développement soit fait dans un langage objet
et utilise une base de données relationnelle.

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

Séparation des couches

Le choix d’une architecture multi-tiers pour les diverses applications, où la séparation
entre couches est mise en relief, est en train de plus en plus s’accentuer. Ces couches
devant être indépendantes. Dès que les spécifications fonctionnelles de chacune d’entre
elles soient établies, leur développement pourra se faire en parallèle, et la maintenance de
l’application n’en sera que plus aisée.

La couche d’accès aux données (Data Access Layer ou DAL), prend en charge toutes
les interactions entre l’application et la base de données. Si une telle couche n’existait
pas, il sera inévitable de réécrire les mêmes lignes de code à différents endroits de l’appli-
cation. En effet, cette couche prend en compte l’ensemble des interactions possibles avec
la base de données, c’est-à-dire la création, la lecture, la modification ou la suppression
des enregistrements dans chacune des tables de la base de données. Il est commun de
créer une classe pour chaque table existante, et de créer des méthodes possédant autant
de paramètres que la table possède de champs.
74 ANNEXE C. DAO ET HIBERNATE

Objectifs d’une couche d’accès aux données

Quel que soit le système de développement, il est toujours possible d’accéder aux
données relationnelles. L’utilisation des API telles que JDBC, ADO, ADO.Net put servir
à exécuter des requêtes SQL, ou à obtenir des objets représentant des tables et leurs
champs,. . .

Ces outils sont suffisants mais ne permettent jamais à eux seuls une vraie abstraction
de la base de données sous-jacente. Par exemple l’obtention de toutes les commandes
d’un client donné avec une seule ligne de code est impossible. De plus, la suppression
d’un client exige sa suppression manuelle par l’intermédiaire de son adresse, alors qu’elle
pourrait être faite automatiquement.

Tous ces problèmes doivent être gérés par une couche d’accès aux données chargée de
communiquer avec le serveur de bases de données, et de renvoyer des objets métiers au
programmeur ; Ce denier n’aurait alors plus besoin de taper des requêtes SQL, comprendre
les relations entre les tables, ou connaı̂tre tous les paramètres des procédures stockées, ou
encore d’autres éléments.

C’est le but des DAO. Ils sont créés pour simplifier au maximum le travail du program-
meur avec le système de données en encapsulant les accès à la base via les frameworks tels
qu’ADO.Net. De plus, les DAO permettent d’accéder à des entités qui sont en relation,
effectuant les jointures en base de données automatiquement.

Limitations

Fonctionnalités : Les DAO n’ont pas pour objectif de gérer des concepts plus com-
plexes tels que les transactions ou la concurrence. De ce fait, la réalisation de la
couche métier restera quand même plus ou moins complexe à réaliser suivant le
modèle de base de données.

Couplage : Vis-à-vis du programmeur des classes métiers, le découplage avec la base de


données est réalisé. Cependant, d’autres programmeurs devront se charger du codage
de l’ensemble de ces classes, et la moindre modification de la base de données obligera
à revoir l’implémentation des DAO correspondants.

Taille des projets : Même s’il existe aujourd’hui de nombreux générateurs de classes
75

DAO qui utilisent des bases de données existantes, leur utilisation pour des projets
volumineux s’avère limitée, car nécessitant des fonctionnalités plus avancées.

Frameworks de persistance

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

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

Ils créent des systèmes complètement autonomes de gestion du système d’information,


autorisent un fort découplage avec la base de données, améliorent les performances et
apportent une grande simplicité d’utilisation. Le seul inconvénient est qu’il s’agit sou-
vent de solutions commerciales plus ou moins coûteuses suivant les fonctionnalités ou la
plateforme d’utilisation.

Avantages des Framework de persistance

Indépendance : On n’a plus à se soucier des problèmes liés aux bases de données telles
que le mapping, ou les méthodologies d’accès aux différents serveurs de bases de
données.

Performances : L’utilisation d’un cache objet performant permet d’améliorer sensible-


ment les caractéristiques de montée en charge des applications.

Modélisation objet : Elle est d’autant plus facile qu’elle est objet, permettant une
meilleure compréhension du système de données grâce à l’UML, et une réutilisation
d’autant plus facile de modèles préexistants.

Savoir-faire : En informatique, personne n’est spécialiste dans tous les domaines, et


l’exploitation des bases de données est un domaine vaste. Les frameworks de per-
sistance permettent à n’importe qui d’exploiter des méthodologies d’accès avancées,
76 ANNEXE C. DAO ET HIBERNATE

avec une simplicité d’utilisation déconcertante.

Temps de développement : Les temps de développement sont énormément réduits,


encore plus si il y a peu de logique métier à votre application. Par exemple, un outil
de persistance a permis de réduction du nombre de lignes de codes de 850 000 lignes
de codes à 300 000.

Exemple de framework de persistance : Hibernate

Hibernate permet d’alléger de façon importante le développement de la persistance


de données. Cette librairie a été développée à la base par une équipe de développeurs
Java mené par Gavin King et ensuite fournie par JBoss. Elle permet de faire du mapping
relationnel/objet. C’est un outil de persistence puissant et performant permettant le lien
entre les objets d’une application et les tables d’une base de données tout en éxécutant
des requêtes.

Concrêtement, Hibernate permet de lier/mapper un objet défini en Java avec une table
dans une base de données, via un fichier déclaratif de mapping. Le système peut s’occuper
de la création des tables en fonction des fichiers de configuration et mettre aussi à jour
les tables si nécessaire lors d’un changement dans l’un des fichiers de configuration.

Hibernate posséde plusieurs moyens pour effectuer des requêtes. Il est possible d’expri-
mer des requêtes en SQL, ou en HQL (language propre à Hibernate) ou encore en critéres
orienté objet.

La nouvelle version d’Hibernate (version 3) a apporté de nouvelles fonctions. Une de


ces nouvelles fonctions est la gestion temporelle des données en sous-ensembles. Dans
les versions antérieures, le développeur devait écrire lui-même les requêtes lui permettant
d’accéder à des données d’une certaine période. Le classement en sous-ensembles se fait via
des filtres définis déclarativement. Cela permet de définir quels sont les droits d’accès d’un
utilisateur donné. La dernière version d’Hibernate est liée étroitement avec la spécification
des EJB 3 permettant ainsi une meilleure implémentation des EJB dans JBoss.