Table des matières

1 Présentation Générale 3
1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Etat de l’art 5
2.1 Les ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Définition d’un ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Pour quoi les ERP ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 Les principaux éditeurs des ERP . . . . . . . . . . . . . . . . . . . . . . . 7

3 Analyse et spécification des besoins 8

3.1 Identification des Utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Les Exigences Spécifiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Les exigences non spécifiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Les cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1 Les diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Solutions techniques possibles et choix retenus 18

4.1 Solutions techniques possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.1 Technologie de développement . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . 23
4.1.3 Gestion de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Choix retenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Conception 25
5.1 Conception générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.1 La comptabilité analytique : . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.2 La gestion de la base de connaissances : . . . . . . . . . . . . . . . . . . . 25
5.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2 Diagrammes de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.3 Diagrammes de séquences détaillés . . . . . . . . . . . . . . . . . . . . . . 28
5.2.4 Conception de la base de données . . . . . . . . . . . . . . . . . . . . . . . 31

i
6 Réalisation 33
6.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.1 Page d’authentification des utilisateurs . . . . . . . . . . . . . . . . . . . . 34
6.2.2 Page d’ajout d’un document EXCEL . . . . . . . . . . . . . . . . . . . . . 35
6.2.3 Page de validation d’un documents EXCEL . . . . . . . . . . . . . . . . . 35
6.2.4 Recherche de fiches de procédures . . . . . . . . . . . . . . . . . . . . . . 36
6.2.5 Résultats de la recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2.6 Consultation des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.7 Ajout de nouveaux utilisateurs ou administrateurs . . . . . . . . . . . . . 37
6.3 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Netographie 41

A Annexe 43

ii
Table des figures

1.1 Feuille d’affectation de temps passés . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 Cas d’utilisation du directeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Cas d’utilisation du comptable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Cas d’utilisation de l’ingénieur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Cas d’utilisation du consultant simlpe . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Cas d’utilisation de l’assistant de service . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 Cas d’utilisation du responsable de département . . . . . . . . . . . . . . . . . . 15
3.7 Ajout d’un fichier EXCEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8 Consultation des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.9 Recherche de procédures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Architecture de JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Architecture de Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 Diagramme de classes de l’application . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Ajout d’un fichier EXCEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4 Consultation des statistique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5 Recherche de procédures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.6 Conception de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1 Identification des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2 Ajout d’un fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3 Validation du document EXCEL . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4 Recherche de fiche de procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.5 Résultats de la recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.6 Consultation des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.7 Ajout de nouveaux utilisateurs ou administrateur . . . . . . . . . . . . . . . . . . 37
6.8 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A.1 Architecture Simple Tiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A.2 Architecture Deux Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.3 Architecture Trois Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.4 Servlet étendant la classe javax.servlet.http.HttpServlet . . . . . . . . . . . . . . 45
A.5 Les pages JSP dans une application J2EE. . . . . . . . . . . . . . . . . . . . . . . 46

iii
A.6 Le modèle MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

iv
Introduction Générale

D e nos jours, toute entreprise est prête à investir des sommes considérables dans l’implanta-
tion des technologies logicielles afin d’améliorer ses services, d’accroı̂tre son agilité et sa flexibilité,
de réduire les coûts, d’augmenter la production et de faire face aux défis du marché. En effet,
vu la croissance des activités au sein des entreprises, la tâche de gérer efficacement toutes ces
fonctions s’avère de plus en plus complexe et difficile.

Pour surpasser ces difficultés, une entreprise doit utiliser des outils optimisés et adaptés fa-
cilitant les tâches et offrant des fonctionnalités riches et utiles. Parmi ces outils nous trouvons
les systèmes intégrés de gestion tel que les ERP(Entrprise Ressources Planning).

Les ERP sont des outils de gestion et d’analyse permettant d’optimiser la diffusion des in-
formations en interne, d’améliorer les processus de gestion et d’automatiser les tâches ce qui
augmente énormement la réactivité des entreprises et leurs agilités.

C’est dans ce contexte que s’intègre notre stage d’immersion en entreprise qui a pour ob-
jectif de concevoir et de réaliser un ERP permettant d’automatiser les différentes besognes de
la société NETCOM TUNISIE. Cet ERP doit automatiser les différents processus de gestion à
savoir la gestion des ressources humaines, la gestion de la production, la gestion commerciale et
la gestion financière.

Le présent rapport synthétise tout le travail que nous avons effectué dans cette perspective.
il est organisé en chapitres comme suit :
– Le premier chapitre donne une présentation générale du projet : l’organisme d’accueil ainsi
que les objectifs à atteindre.
– Dans le second chapitre, nous procédons à un exposé de l’état de l’art du domaine qui
nous concerne. Nous présentons dans un premier temps le système existant pour dévoiler
ses défaillances et ses limites. Nous présentons également la solution que nous proposons
afin de palier aux limites du système actuel.
– Le troisième chapitre intitulé”’Analyse et Spécification des besoins”’présente les différents
besoins fonctionnels et non fonctionnels auxquelles doit satisfaire l’application.
– Les choix technologiques retenus pour la phase de développement font l’objet du quatrième
chapitre.
– Dans le chapitre V nous présentons la conception générale et la conception détaillée du

1
 système.
– Le dernier chapitre décrit les tâches accomplies en titre de réalisation.

Enfin nous donnons une conclusion récapitulant le travail réalisé ainsi que des perspectives
futurs.

2
Chapitre 1

Présentation Générale

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

1.1 Organisme d’accueil

Activités de SATEC

SATEC a été créee en 1992 et a pu, durant 16 ans, consolider une bonne et solide assise sur le
marché tunisien en tant qu’intégrateur réseaux et sécurité de réseaux, indépendamment de tout
constructeur. SATEC Tunisie, est devenue un précurseur et un acteur majeur de l’intégration
réseau en Tunisie.

Quelques dates utiles

– 1992 : Création de SATEC Tunisie.

– 1998 : SATEC Tunisie, meilleur support Nortel : proche Orient/ Afrique du Nord, Cisco
Partner.
– 1998 : Réalisation du projet de la télé compensation, ISO 9001 version 2000.
– 2002 : Spécialisation sécurité VPN,WiFi de Cisco Systems.
– 2004 : Mise en service d’un centre de management de la sécurité.
– 2005 : Services managés Q.o.S, sécurité.

1.2 Présentation du sujet

Dans le système actuel de la société NETCOM, chaque service possède son propre système
d’information ce qui a donné lieu à plusieurs problèmes dont les majeurs sont :
– Pour collecter les informations nécessaires au processus d’administration de l’entreprise,
on constate une lenteur causée par la dispersion de différents systèmes d’informations.

3
 – Toute mise à jour suvenue sur l’un des systèmes d’informations n’est détectée par les
autres que par voie humaine, en conséquence elle ne se fait pas en temps réel et risque de
transmettre des information erronées.
Les conséquences désagréables d’une telle situation ont obligé l’entreprise à y mettre fin.
Pour cela, la meilleur solution était d’implémenter un ERP multifonctions qui vise à centraliser
le système d’information et à automatiser ses activités tout en garantissant une sécurité de haut
niveau.

Fig. 1.1 – Feuille d’affectation de temps passés

Notre mission consistait alors à concevoir et implémenter cet ERP qui doit comporter les
quatre module suivants :

– Module de gestion de ressources humaines

– Module de gestion de la production
– Module de gestion commerciale
– Module de gestion financière

Notre mission a été ensuite réduite à la réalisation de deux sous modules : implémentation
du sous module d’analyse analytique et celui de la gestion de la base de connaissance. Et cela
vu, en premier lieu, l’envergure du projet initial et l’insuffisance du temps consacré au stage, et
en second lieu l’urgence de réaliser ces deux fonctionnalités pour le client.

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 de l’existant pour dégager ses limites.

4
Chapitre 2

Etat de l’art

Introduction
Avant d’entamer l’élaboration de notre application, nous avons jugé primordial de présenter
les objectifs d’une telle application à partir des éléments moteurs par lesquels elle est constituée.

2.1 Les ERP

2.1.1 Historique
Dans les années 60 et 70, les premiers logiciels font leur apparition dans les entreprises.
Il s’agit essentiellement d’applications de comptabilité et également de MRP, pour la gestion
des approvisionnements. Ces logiciels spécifiques ne sont pas ” portables ”, c’est à dire qu’ils
dépendent du type d’ordinateur et du système d’exploitation. Dans les années 80 se développent
des progiciels qu’on personnalise, intégrants la finance, la comptabilité, la paie et la gestion de
production assistée par ordinateur. La tendance à personnaliser et à modifier complètement le
progiciel de base pour l’entreprise conduit le produit à être obsolète au bout de 5 à 10 ans. Dans
ces années apparaissent également les premiers MRP II, intégrant la gestion de production et
la gestion des approvisionnements. La petite histoire raconte qu’à la fin des années 80, trois
employés d’IBM pressentent un marché important pour les progiciels intégrés, et fondent SAP.
Peu après, SAP R/2 devient la première référence en matière d’ERP, encore fondée sur une
structure informatique centralisée et une technologie mainframe.
En 1993, SAP R/3 réalise l’intégration totale de toutes les composantes d’une entreprise, de
la finance à la production, aux ventes et aux ressources humaines... Sa structure informatique
et sa portabilité complète seront une grande raison de son succès.
Les ERP sont maintenant présents dans l’industrie et dans la grande distribution, essentiel-
lement dans les très grandes entreprises. Le marché des plus petites entreprises, le domaine de
la finance et le secteur public commencent à être touchés.
La conception et le développement des ERP ont été rendus possibles par les évolutions
technologiques : vitesse de calcul, technologies de réseaux, systèmes de gestion de bases de
données, stockage de données... se sont considérablement développés et améliorés. De plus, le
succès des ERP a été favorisé par la perte de crédibilité des informaticiens dans les entreprises
à la fin des années 80 et au début des années 90.

5
2.1.2 Définition d’un ERP
L’acronyme ERP signifie ” Enterprise Ressource Planning ” traduit en français par Progi-
ciel de Gestion Intégré ou PGI. ERP est le terme le plus couramment utilisé. Emanant d’un
concepteur unique, un ERP est un progiciel qui permet de gérer l’ensemble des processus d’une
entreprise intégrant l’ensemble de ses fonctions comme la gestion des ressources humaines, la ges-
tion financière et comptable, l’aide a la decision, la vente, la distribution, l’approvisionnement, la
production ou encore du e-commerce. Le principe fondateur d’un ERP est de construire des ap-
plications informatiques correspondant aux diverses fonctions citées précédemment de manière
modulaire sachant que ces modules sont indépendants entre eux, tout en partageant une base de
données unique et commune au sens logique. L’autre principe qui caractérise un ERP est l’usage
de ce qu’on appelle un moteur de workfow et qui permet, lorqu’une donnée est enregistrée dans
le système d’information(SI), de la propager dans les modules qui en ont l’utilité, selon une pro-
grammation prédéfinie. Ainsi, on peut parler d’ERP lorsqu’on est en présence d’un SI composé
de plusieurs applications partageant une seule et même base de donnés, par le biais d’un système
automatisé prédéfini et éventuellement paramétrable, un moteur de workfow.

2.1.3 Pour quoi les ERP ?

Concrètement, les avantages de la mise en place d’un ERP sont les suivants :
– L’intégrité et l’unicité du SI, c’est à dire qu’un ERP permet une logique et une ergonomie
unique à travers sa base de données, elle aussi unique au sens ” logique ”. Ceci se traduit par
le fait qu’il peut exister plusieurs bases de données ” physiques ” mais celles-ci respectent
la même structure. En bref, un ERP permet d’éviter la redondance d’information entre
différents SI de l’entreprise.
– L’utilisateur a la possibilité de récupérer des données de manière immédiate, ou encore
de les enregistrer. Un avantage important, les mises à jour dans la base de données sont
effectuées en temps réel et propagées au modules concernés.
– Un ERP est un outil multilingue et multidevise, il est donc adapté au marché mondial, en
particulier aux multinationales.
– Pas d’interface entre les modules, il y a synchronisation des traitements et optimisation
des processus de gestion. De même, la maintenance corrective est simplifiée car celle-ci est
assurée directement par l’éditeur et non plus par le service informatique de l’entreprise.
(Celui-ci garde néanmoins sous sa responsabilité la maintenance évolutive : amélioration
des fonctionnalités, évolution des règles de gestion, etc.).
– Un ERP permet de maı̂triser les stocks, élément important pour la plupart des entreprises
car les stocks coûtent chers.

Par conséquent, les ERP gèrent et prennent en charge plusieurs périodes ( pour les exercices
comptables par exemple), plusieurs devises, plusieurs langues pour les utilisateurs et clients,
plusieurs législations, plusieurs axes d’analyse en informatique décisionnelle. Mais l’implanta-
tion comporte plusieurs risques : des risques organisationnels (le progiciel et l’organisation de
l’entreprise doivent cohabiter), de mise en oeuvre (au niveau formation utilisateur), fonctionnels
(fonctions offertes par le progiciel par rapport aux fonctions attendues), techniques, contractuels

6
entre l’éditeur et l’entreprise et enfin des risques économiques du fait de l’investissement.

2.1.4 Les principaux éditeurs des ERP

On distingue deux types d’ERP : les ERP propriétaires, édités par des sociétés, ce qui
implique l’achat d’une licence, et les ERP open source qui sont ” gratuits ”. Les principaux
ERP propriétaires du marché sont :
– SAP (leader mondial)
– Oracle/Peoplesoft
– SAGE ADONIX
– Microsoft
– SSA Global

Conclusion
Dans ce chapitre nous avons définit c’est quoi réellement les ERP. Ce chapitre sert donc à
présenter théoriquement notre sujet pour mieux comprendre le système implémenté.
Le chapitre suivant sera consacré à l’étude des besoins fonctionnels et non fonctionnels auxquels
doit répondre notre application.

7
Chapitre 3

Analyse et spécification des besoins

Introduction
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 étudions dans un premier temps les besoins fonctionnels et non
fonctionnels de notre système, ensuite, une spécification formelle des besoins est présentée par
des diagrammes de cas d’utilisation et de séquences suivant la modélisation UML.

3.1 Identification des Utilisateurs

Notre application fournit une interaction avec plusieurs types d’acteurs, ils sont définis
comme étant des utilisateurs directs du système exploitant le logiciel à travers ses interfaces.
Nous identifions dans le cadre de ce projet six acteurs primaires :
– Le directeur qui est l’utilisateur qui a tous les privilèges au niveau de la comptabilité
analytique et au niveau de la gestion des rôles des autres acteurs.
– Le comptable qui a un accès limité au niveau de la comptabilité analytique.
– L’ingénieur qui a tout les droits au niveau de la gestion de la base de connaissance.
– Le consultant simple qui a un accès limité au niveau de la gestion de la base de connais-
sance.
– L’assistance du service qui aura l’accès pour ajouter ou modifier les documents des
ingénieurs.
– Les responsables des départements qui ont des privilèges spécifiques à chaque département.

Pour cela on va spécifier ci dessous les besoins que doit fournir le système pour chaque
catégorie d’utilisateurs.

8
3.2 Les Exigences Spécifiques
L’analyse du sujet, nous a permis de cerner les fonctionnalités à la disposition de l’utilisa-
teur.Les besoins ainsi dégagés ont été classés en fonctionnels et non fonctionnels.

3.2.1 Les besoins fonctionnels

– Le Directeur : Le système doit permettre au directeur de :
– S’identifier pour accéder à la section de la comptabilité.
– Consulter la liste détaillée des affaires et la répartition des ingénieurs correspondant par
mois.
– Effectuer des recherches selon des différents critères : par date, par ingénieur ou par
affaire.
– Ajouter une nouvelle affaire si elle n’existe pas déjà.
– Visualiser les statistiques et les courbes d’évolution.
– Télécharger un fichier EXCEL et mettre à jour la base de données.
– Valider les documents téléchargés.
– Saisir les informations du document de l’ingénieur à l’aide d’un formulaire.
– Mettre à jour les rôles de chaque profile utilisant le système.

– Le Comptable : Le système doit permettre au comptable de :

– Consulter la liste détaillée des affaires et la répartition des ingénieurs correspondant par
mois.
– Effectuer des recherches selon des différents critères .
– S’identifier pour accéder à la section de la comptabilité.
– Visualiser les statistiques et les courbes d’évolution.

– L’ingénieur : Le système doit permettre à l’ingénieur de :

– S’identifier pour accéder à la section de la gestion de la base de connaissances.
– Remplir les fiches de procédure (description, mot clé..).
– Consulter ses fiches de procédure remplies auparavant.
– Mettre à jour une fiche de procédure.

– Le consultant : Le système doit permettre au consultant simple de :

– Rechercher une fiche de procédure.
– Consulter les fiches résultantes classées.
– Imprimer la fiche des procédures.

– Le responsable de département : Le système doit permettre au responsable de département

de :
– S’identifier pour accéder à la section de comptabilité analytique.
– Ajouter et mettre â jour les profiles du département.

– L’assistance de service : Le système doit permettre à l’assistance de service de :

9
 – S’identifier pour accéder à la section de comptabilité analytique.
– Ajouter des documents des ingénieurs.
– Valider les documents des ingénieurs.

3.3 Les exigences non spécifiques

Pour le bon fonctionnement de notre application nous avons dégagé les besoins non fonc-
tionnels suivants :
– la fiabilité : le système doit être disponible à tout moment pour l’utilisateur, avec un accès
sécurisé par la définition d’un login et d’un mot de passe.
– la portabilité : le système doit tourner sur plusieurs plates-formes.
– la convivialité : le système doit présenter une interface compréhensible, facile à manipuler
ce qui nous permettera d’accroı̂tre la rentabilité et l’efficacité de notre système.

10
3.4 Les cas d’utilisation
L’étude approfondie des spécifications permet de dégager plusieurs cas d’utilisation. Un cas
d’utilisation décrit une utilisation du système par un acteur particulier.Ce qui revient à présenter
les besois fonctionnels de façon formelle.
Cas d’utilisation du directeur :

Fig. 3.1 – Cas d’utilisation du directeur

11
Cas d’utilisation du comptable :

Fig. 3.2 – Cas d’utilisation du comptable

12
Cas d’utilisation de l’ingénieur

Fig. 3.3 – Cas d’utilisation de l’ingénieur

13
Cas d’utilisation du consultant simple :

Fig. 3.4 – Cas d’utilisation du consultant simlpe

Cas d’utilisation de l’assistance de service :

Fig. 3.5 – Cas d’utilisation de l’assistant de service

14
 Cas d’utilisation du responsable de département

Fig. 3.6 – Cas d’utilisation du responsable de département

3.4.1 Les diagrammes de séquences

les diagrammes de séquences peuvent servir à illustrer un cas d’utilisation décrit précédemment.
C’est un moyen semi formel de capturer le comportement de tous les objets et acteurs impliqués
dans un cas d’utilisation. Dans ce qui suit nous allons présenter quelques scénarios de notre
applications.

Diagramme de séquence pour l’ajout d’un fichier EXCEL

Fig. 3.7 – Ajout d’un fichier EXCEL

15
Diagramme de séquence pour la consultation des statistiques

Fig. 3.8 – Consultation des statistiques

16
 Diagramme de séquence pour la recherche de procédures

Fig. 3.9 – Recherche de procédures

Conclusion
Dans ce chapitre, nous venons de présenter une analyse globale de l’application tout en
spécifiant les besoins fonctionnels et les contraintes que notre travail doit satisfaire et respecter.
La conception et ses détails seront décrits dans le prochain chapitre.

17
Chapitre 4

Solutions techniques possibles et

choix retenus

Introduction
Ce chapitre aborde une étude comparative entre les différentes technologies existantes et
prouve le choix de l’environnement de développement ainsi que le système de gestion de la base
de données.

4.1 Solutions techniques possibles

4.1.1 Technologie de développement
Microsoft .NET

Présentation : La plate-forme Microsoft .NET est une solution complète pour développer,
déployer et exécuter des application de tous types, y compris des services web. Fondée sur
des standards de l’industrie (HTTP, XML, SOAP, WDSL), la plate-forme .NET est un moyen
simple et puissant pour implémenter la coopération des services logiciels entre eux, quelle que
soit leur localisation, leur impléméntation technique, qu’ils soient internes ou externes, existant
ou à inventer.

Les composants de .NET : A travers les différentes annonces de Microsoft depuis son
lancement, les composants de .NET semblent s’organiser de la manière suivante :

1. Pour la couche présentation et logique de présentation :

– ASP .NET : c’est une nouvelle version d’ASP (Active Server Pages) qui supporte
une véritable compilation en IL, alors qu’ASP était interprété auparavant. On peut
également écrire les pages ASP dans n’importe quel langage disposant d’un compilateur
IL.
– WinForms et WebForms : ils présentent un ensemble de composants graphiques acces-
sibles dans Visual Studio .NET .
2. Pour la couche logique métier et objets intermédiaires :

18
 – CLR ( Common Language Runtime) : c’est un environnement d’exécution commun
qui exécute un bytecode écrit dans un langage intermédiaire (Microsoft intermediate
Language)
– C# : c’est nouveau langage orienté objet destiné à faciliter la programmation dans .NET,
notamment les composants, qui intègre des éléments de C, C++ et de Java en apportant
quelques innovations comme les méta-données.
– Langages quelconques qui peuvent être compilés en IL et exécutés par le CLR si un
compilateur IL existe pour ce dernier.
– Une grande bibliothèque de composants et d’objets de base accessibles par le CLR,
qui fournissent les fondations pour écrire rapidement un programme (accès réseau, gra-
phisme, accès aux données ).
– Visual Studio .NET : c’est une réfonte de l’environnement Visual Studio et de Visual
INterDev permettant aussi bien le développement d’application et de composant clas-
sique.
– Un support de terminaux mobiles avec une version compacte de l’environnement .NET
.
3. Pour la couche de données :
– ADO .NET : c’est une nouvelle génération de composants d’accès aux bases de données
ADO qui utilise XML et SOAP pour l’échange de données.

Les avantages de .NET : La plate-forme .NET comprend un modèle de programmation

homogène et des outils de développement multi langages qui accèlèrent le développement et
l’intégration de Services Web et de tout autre type d’application multi langages et intégrant
les standards, la plate-forme .NET laisse au développeur toute liberté de choisir le langage de
développement. D’autre part son support des stabndards et son approche moderne, la plate-
forme .NET est parfaitement adaptée à la construction d’une architecture orientée services. La
plate-forme .NET offre donc plusieurs avantages :
– Un développement spécifique grâce au moteur CLR .
– Une structure multi langages et extensible .
– Une exécution multi plate-forme .
– Une productivité comparable à celle des environnements Client/Serveur comme Power-
Builder ou Delphi .
– Un modèle de programmation simple et cohérent .
– Une installation automatisée des Web Services .

J2EE

Présentation : J2EE est logiquement destiné aux gros systèmes d’entreprise. Les logiciels
employés à ce niveau ne fonctionnent pas sur un simple PC mais requière une puissance beau-
coup plus importante. Pour cette raison, les applications doivent être constituées de plusieurs
composants pouvant être déployés sur des plate-formes multiples afin de disposer de la puissance
de calcul nécessaire. C’est la raison d’être des applications distribuées.
J2EE est une collection de composants, de conteneurs et de services permettant de créer et
de déployer des applications distribuées au sein d’une architecture standardisée.

19
Les composants de J2EE : J2EE fournit une gamme d’outils et d’API afin de concevoir
facilement les différentes couches.

1. Pour la couche Présentation et logique de présentation :

– Java Servlet : Une servlet est un programme écrit en JAVA qui tourne sur la machine
du serveur J2EE. Une servlet est chargée lorsque le serveur est mis en route ou lorsque
le premier client fait appel aux services de la servlet.Le serveur Web reçoit une demande
adressée à une servlet sous la forme d’une requête HTTP. Il transmet la requête à la
servlet concernée, puis renvoie la réponse fournie par celle du client . La servlet reçoit
également les paramètres de la requête envoyée par le client. Elle peut alors effectuer
toutes les opérations nécessaires pour construire la réponse avant de renvoyer celle-ci
sous forme de code HTML. Une fois chargée, une servlet reste active dans l’attente de
nouvelles requêtes. Une servlet doit soit implémenter l’interface javax.servlet.Servlet ou
étendre soit la classe javax.servlet.GenericServlet soit javax.servlet.http.HttpServlet.
– Java Server Pages (JSP) : cette extension permet de valoriser davantage les applications
web avec la plate-forme J2EE en permettant le développement d’applications web basées
sur ce modèle ; les JSP permettent grâce au moteur de servlet de produire facilement
des pages HTML.
– Struts : Jakarta Struts est un projet d’Appache software foundation qui a pour but de
fournir un cadre standard de développement web en java respectant le modèle d’archi-
tecture MVC (Model-View-Controller). Il fournit le minimum de règles pour construire
des applications web professionnelles.
– Java Server Faces (JSF) : Java Server Faces est un framework d’interface utilisateur
pour les applications web, basé sur les technologies JSP et Servlets. Le but de JSF
est d’accroı̂tre la productivité des développeurs dans le développement des interfaces
utilisateur tout en facilitant leur maintenance. JSF permet de réconcilier deux points
de vues diamétralement opposés en fornissant un framework basé sur une abstraction
complète des mécanismes d’internet tout en garantissant une totale maı̂trise du cycle de
vie du traitement d’une requête. JSF permet :
– une séparation nette entre la couche de présentation et les autres couches.
– le mapping HTML/Objet.
– un modèle riche de composants graphiques réutilisables.
– un modèle riche de composants graphiques réutilisables.
– une gestion de l’état de l’interface entre les différentes requêtes.
– une liaison simple entre les actions côté client de l’utilisateur et le code Java corres-
pondant côté serveur.
– la création de composants customs grâce à une API.
– le support de différents clients (HTML, WML, XML, ...) grâce à la séparation des
problématiques de construction de l’interface et du rendu de cette interface.

20
 Fig. 4.1 – Architecture de JSF

– Spring : C’est un framework ayant pour but de rendre facile le développement des
applications web tout en augmentant la consistance et la productivité.
2. Pour la couche logique métier et objet intermédiaires :
– Les EJB : Ce sont des composants Java pour des applications distribuées multi niveaux.
Cette extension fournit un moyen standard pour définir les composants côté serveur
et définit une vaste infrastructure d’exécution pour l’hébergement des composants côté
serveur.
– Les JavaBeans : Selon la spécification des Javabeans, une Bean est un composant logiciel
réutilisable pouvant être manipulé visuellement dans un outil de construction (builder
tool).
3. Pour la couche de données :
– JDBC Connector : JDBC (l’acronyme de JAVA Data Base Connectivity) est une API
JAVA permettant d’accéder à es base de données, de façon indépendante de la base
utilisée, à partir d’une application JAVA. La procédure sera la même quelle que soit la
base de données choisie. JDBC définit une API de bas niveau désignée pour supporter les
fonctionnalités basiques de SQL indépendement de toute implémentation SQl spécifique.
– 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 structure de la base de données : création et mise à jour. IL utilise un langage simple
pour l’interrogation de la base de données appelé HQL (Hibernate Query Language) et
qui fournit une couche d’abstraction SQL.

21
 Fig. 4.2 – Architecture de Hibernate

Les avantages de J2EE : L’approche multi niveaux adoptée par la plate-forme J2EE offre
plusieurs avantages :
– Elle réduit la compléxité du développement distribué avec une architecture simplifiée et le
partage de la charge de travail.
– C’est une solution hautement évolutive qui permet le développement des systèmes satis-
faisant de nombreux besoins rapidement modifiables.
– Les nouvelles applications peuvent s’intégrer correctement avec les systèmes d’informations
existants.
– La sécurité est améliorée.
– Les développeurs peuvent choisir parmi une diversité d’outils de développement et de
composants pour développer les applications requises.
– L’équipe de développement peut sélectionner les meilleurs solutions pour leurs besoins,
sans être verrouillée par l’offre du fournisseur unique.
– Tous les composants sont gratuits.

Comparaison entre J2EE et .NET

Dans cette section, nous allons dégager les principales différences entre la technologies J2EE
de Sun et la technologie .NET de Microsoft. En fait, nous avons limité notre étude sur ces
deux technologies car ils sont les plus appréciées au sein des entreprises qui ambitionnent avoir
des applications robustes, portables, complexes et sécurisées, d’autant plus qu’elles traitent des
données confidentielles, et font appels aux technologies les plus modernes. Le tableau suivant
expose les critères sur lesquels se basera notre choix technologique.

22
 .NET J2EE
Langages C#,multi-langage Java
Services BCL Java Core API
Présentation ASP .NET Servlet, JSP
Interprète CLR JVM
Composants graphiques WinForms, WebForms Swing
Accès à la BD ADO .NET JDBC, Hibernate, iBatis
Technologie Produit Standard

Tab. 4.1 – Tableau comparatif .NET et J2EE

4.1.2 Environnement de développement

4.1.3 Gestion de la base de données
Oracle DataBase

Oracle est un SGBDR édité par la société du même nom Oracle Corporation leader mondial
en base de données.Oracle peut assurer entre autres fonctionnalités :
– La définition et la manipulation des données
– La cohérence des données.
– La confidentialité des données.
– L’intégrité des données.

MySQL

MySQL a pour origine l’application mSQL. Cette application permettait de ce connecter à

des tables en utilisant des routines bas niveau. Cependant, après quelques tests, les développeurs
sont arrivés à la conclusion que mSQL n’était pas assez rapide et flexible pour leurs besoins. Le
serveur de bases de données MySQL est très rapide, able et facile à utiliser. Il dispose aussi de
fonctionnalités pratiques, développées en coopération avec les utilisateurs.
Les principales fonctionnalités qu’offre MySQL sont :
– Fonctionne sur de nombreuses plate-formes.
– Dispose d’API pour C, C++, Eiffel, Java, Perl, PHP, Python, Ruby et Tcl.
– Complètement multi-threadé, grâce aux threads du noyau. Cela signi e qu’on peut l’utiliser
facilement sur un serveur avec plusieurs processeurs.
– Tables B-tree très rapide, avec compression d’index.
– Système l’allocation mémoire très rapide, exploitant les threads.
– Tables en mémoire, pour réaliser des tables temporaires.
– Les fonctions SQL sont implémentées grâce à une librairie de classes optimisées, qui sont
aussi rapides que possible .

PostgreSQL

PostgreSQL est un SGBD relationnel objet Open Source implémenté par l’université de Ber-
keley. Les fonctions clés du modèle objet de PostgreSQL sont les classes, l’héritage et la surcharge.

23
PostgreSQL est un logiciel ” modulaire ” possédant un langage d’écriture de procédures similaire
à celui d’Oracle mais également d’autres interfaces de programmation. Voici les fonctions clés
du modèle orienté objet de PostgreSQL :
– Les classes : Une classe correspond à un ensemble d’objets possédant un identificateur
unique.
– L’héritage : La notion d’héritage correspond à une organisation hiérarchique des tables.
Par exemple, si deux tables se trouvent dans une relation parent/enfant, les informations
contenues dans la table parent sont également disponible dans la table enfant.
– La surcharge : On parle de ”surcharge de fonction” lorsqu’une fonction peut être définie
plusieurs fois avec des paramètres différents.

4.2 Choix retenus

La clareté de l’architecture qu’elle propose ainsi que la multitude des IDE qui peuvent la
supporter et sa gratitude, la technologie J2EE a été le choix Judicieux pour le développement de
notre application. L’IDE surlequel nous avons choisit de développer notre application est l’IDE
Eclipse. Une base de donnée MySQL est celle qui va être implémenter pour gérer les données
nécessaire à l’application.

Conclusion
Après cette étude nous avons décidé de choisir la plate-forme J2EE comme environnement de
développement (donc Java comme langage de programmation), MySQL pour l’implémentation
de la base de données et hibernate pour la couche persistence de données. Le chapitre suivant
aborde en détail la conception de l’application à réaliser.

24
Chapitre 5

Conception

Introduction
Dans ce présent chapitre nous allons entamer 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.

5.1 Conception générale

Le travail à réaliser est décomposé en deux module indépendants à savoir le module de la
comptabilité analytique et le module le gestion de la base de connaissances.

5.1.1 La comptabilité analytique :

Ce module s’intégre dans la partie de gestion financière de l’ERP à réaliser. Elle automatise
au premier lieu la tâche de pointage horaire du personnel de l’entreprise et facilite, en second lieu,
la tâche du comptable pour la réalisation des statistiques élémentaires et croisées et y dessiner
les diagrammes correspondnat afin de les bien présenter au responsable supérieur. Ce module,
à part son rôle pour réduire les temps de réalisation des tâches citées, il permet d’économiser
l’argent puisque l’être humain n’interviendra pas dans le mécanisme.

5.1.2 La gestion de la base de connaissances :

Ce module fait parti de la gestion de la productivité de l’entreprise. en effet il sert comme un
puissant outil pour la constitution d’un ensemble de connaissances dans les domaines d’activité
de l’entreprise afin de faciliter la réparation, la mise à niveau ou l’élimination d’une procédure
de travail.

5.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 program-
meur peut directement implémenter le système.

25
5.2.1 Architecture de l’application
La navigation entre les différentes parties de notre application est présentée par la figure
ci-dessous :

Fig. 5.1 – Architecture de l’application

5.2.2 Diagrammes de Classes

Le diagramme de classes permet de décrire la structure statique du système à l’aide des
classes et des relations.

26
Fig. 5.2 – Diagramme de classes de l’application

27
5.2.3 Diagrammes de séquences détaillés
Diagramme de séquence pour l’ajout d’un fichier EXCEL
Le diagramme suivant présente comment un ingénieur peut ajouter un fichier EXCEL pour le
prendre en compte par l’administration de l’entreprise.

Fig. 5.3 – Ajout d’un fichier EXCEL

28
Diagramme de séquence pour la consultation des statistiques

Fig. 5.4 – Consultation des statistique

29
Diagramme de séquence pour la recherche de procédures

Fig. 5.5 – Recherche de procédures

30
5.2.4 Conception de la base de données
Le modèle relationnel de données est un modèle de donnée comme d’autres existants ayant
pour but de décrire le 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 essen-
tiel 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 princi-
pale est d’être des langages non procéduraux. Pour ces raisons nous avons choisi d’utiliser une
base de données relationnelle.
A ce niveau de cette application et tout en considérant les besoins déjà spécifiés nous avons
envisagé un certain nombre de tables pour enregistrer les données nécessaires pour la gestion du
site. Les tables utilisées et les relations qui les inter-relient sont données par la figure 5.6

Fig. 5.6 – Conception de la base de données

31
Coclusion
Etant donné les besoins des utilisateurs de notre applications, la phase de conception vient
pour permettre la détermination des différents objets contribuant à assurer les fonctionnalités
souhaitées. Cette phase est une préparation à la phase du codage garantissant une organisation
claire et précise ainsi qu’une facilité d’implémentation des classes invoquées, des structures de
données utilisées et les relations qui existent entre les différentes classes. Nous essayons dans
le chapitre réalisation d’implémenter les différentes classes et de montrer les fonctionnalités
réalisées suite à cette implémentation.

32
Chapitre 6

Réalisation

Après avoir achevé l’étape de conception de l’application, nous entamons dans ce chapitre
la phase de réalisation. Nous allons présenter, en premier lieu, l’environnement de travail utilisé
pour le développement de l’application. Ensuite, nous allons donner un aperçu sur le travail
accompli à travers des capture d’écran. Enfin, nous montrerons le chronogramme de la réalisation
du projet.

6.1 Environnement de travail

6.1.1 Environnement matériel
Afin de réaliser ce site web dans les conditions les plus favorables, nous avons mis en dispo-
sition un ordinateur ayant la configuration suivante :

Processeur : Intel(R) Pentium(R) M 3.2GHz

Disque dur : 120Gb
RAM :1.256GB

6.1.2 Environnement logiciel

Eclipse

Eclipse est un environnement de développement intégré (Integrated Development Envi-

ronment) dont le but est de fournir une plate-forme modulaire pour permettre de réaliser
des développements informatiques. I.B.M. est à l’origine du développement d’Eclipse qui est
d’ailleurs toujours le coeur de son outil Websphere Studio Workbench (WSW), lui même à la
base de la famille des derniers outils de développement en Java d’I.B.M. Tout le code d’Eclipse
a été donné à la communauté par I.B.M afin de poursuivre son développement.
Eclipse utilise énormément le concept de modules nommés ”Plug-ins” dans son architecture.
D’ailleurs, hormis le noyau de la plate-forme nommé ”Runtime”, tout le reste de la plate-forme
est développé sous la forme de Plug- ins. Ce concept permet de fournir un mécanisme pour
l’extension de la plate-forme et ainsi fournir la possibilité à des tiers de développer des fonction-
nalités qui ne sont pas fournies en standard par Eclipse.

33
Tomcat :

Tomcat est un serveur d’application totalemet écrit en java. A partir de la version 5.0 il
implémentait les spécifications 2.4 des JavaServlet et 2.0 des JSP.
Tomcat a été développé en open source au sein du projet Apache Jakarta, dont le but est de
fournir des solutions serveur basées sur la plate-forme Java, de qualité identique aux applications
commerciales.Tomcat est un moteur d’exécution pour les servlets et les pages JSP. Il prend en
charge la partie dynamique du site et laisse la partie statique au serveur web.

6.2 Travail réalisé

A cette étape du nous donnons les captures d’écran relatives aux pages des principales
fonctions réalisées par l’application.

6.2.1 Page d’authentification des utilisateurs

Fig. 6.1 – Identification des utilisateurs

34
6.2.2 Page d’ajout d’un document EXCEL

Fig. 6.2 – Ajout d’un fichier

6.2.3 Page de validation d’un documents EXCEL

Fig. 6.3 – Validation du document EXCEL

35
6.2.4 Recherche de fiches de procédures

Fig. 6.4 – Recherche de fiche de procédure

6.2.5 Résultats de la recherche

Fig. 6.5 – Résultats de la recherche

36
6.2.6 Consultation des statistiques

Fig. 6.6 – Consultation des statistiques

6.2.7 Ajout de nouveaux utilisateurs ou administrateurs

Fig. 6.7 – Ajout de nouveaux utilisateurs ou administrateur

37
6.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 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 fonctionalité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 :

Fig. 6.8 – Chronogramme

38
Conclusion et perspectives

Avant de commencer le stage, nous en attendions essentillement à trois choses : travailler sur
un produit d’avenir au moins en tunisie (les ERP), recueillir une expérience et des compétences
professionnelles et découvrir le fonctionnement des équipes de développement au sein des entre-
prises informatiques.

L’objectif de ce stage était de concevoir et de développer deux modules faisant parti d’un
ERP destiné à une entreprise classée de PME.

Il a été aussi bénéfique aussi bien sur le plan théorique que sur le plan pratique. En effet sur
le plan pratique ce projet nous a donné une occasion de découvrir le framework JSF pour le
développement des applications web, et d’améliorer nos connaissances sur la gestion des bases
de données. Sur le plan théorique il nous a permis une familiarisation avec les notions et les au-
tomatismes de la programmation des applications Web avec l’IDE Eclipse suivant l’architecture
MVC2 ainsi que les techniques de manipulation de la couche de persistence avec Hibernate.

En perspectives, le développement du reste des modules de l’ERP et son intégration dans

l’environnement constituons le sujet du projet de fin d’études afin de voir un produit complet
pouvant automatiser plusieurs tâche dans les petites et moyennes entreprises.

39
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. Développement Web avec J2EE .O’Reilly,2005

40
Netographie

[N1] http://www.developpez.com consulté le 01 juillet 2008

[N2] http://www.coreservlets.com/JSF-Tutorial/ consulté le 09 juillet 2008
[N3] http://www.jsftoolbox.com/documentation/ consulté le 10 juillet 2008
[N4] http://www.roseindia.net/ consulté le 27 juillet 2008
[N2] http://www.myfacescomponent.com consulté le 20 août 2008
[N3] http://www.tomahawkcomponent.com consulté le 21 août 2008

41
Glossaire

Dans ce glossaire nous citons quelques termes nécessaires pour la compréhension du rapport.
ASP : Active Server Pages
CLR : Common Language Runtime
EJB : Entreprise JavaBean
ERP : Entreprise Ressource Planning
HQL : Hibernate Query Language
HTTP : Hyper Text Transfer Protocol
IDE : Integrated Development Environment
JDBC : Java Data Base Connectivity
JSF : Java Server Faces
JSP : Java Server Pages
MVC : Model-View-Controller
PGI : Progiciel de Gestion Integré
PME : Petites et Moyennes Entreprises
SI : Système d’Information
SQL : Structured Query Language
UML : Unified Modeling Language

42
Annexe A

Les Architectures Logicielles

Architecture Simple tiers
Les applications bureautiques sont conçues pour fonctionner sur un ordinateur unique. Toutes
les services fournis par l’application - interface utilisateur, persistance des données (sauvegarde
dans des fichiers propriétaires) et logique de traitement de ces données - résident sur la même
machine et sont inclus dans l’application.

Fig. A.1 – Architecture Simple Tiers.

Architecture deux tiers

Selon l’architecture deux tiers les traitements sont répartis entre le client représenté par une
station de travail utilisateur et le serveur représenté par un mainframe ou un serveur puissant.
Le client prend en charge l’ensemble des taches liées à la présentation, à la logique applicative
ainsi qu’une grande partie de la logique métier. Quant au serveur, son rôle est d’héberger les
données du système d’information et de traiter les requêtes en provenance du client.
Un des inconvénient de l’architecture deux-tiers est que la logique chargée de la manipulation
des données et de l’application des règles métiers afférentes est incluse dans l’application elle-
même. Cela pose problème lorsque plusieurs applications doivent partager l’accès à une base de
données.

Architecture trois tiers

C’est un modèle logique d’architecture applicative qui vise à séparer très nettement trois
couches logicielles au sein d’un même système.

43
 Fig. A.2 – Architecture Deux Tiers

Fig. A.3 – Architecture Trois Tiers

Selon ce modèle, toute la logique métier est extraite de l’application cliente. Celle-ci n’est
plus responsable que de la présentation de l’interface à l’utilisateur et de la communication avec
le tiers médian. Elle n’est plus responsable de l’application des règles. Son rôle est réduit à la
couche présentation.

La plate forme J2EE

J2EE est l’acronyme de Java 2 Entreprise Edition. Cette édition est dédiée à la réalisation
d’applications pour entreprises. J2EE est basé sur J2SE (Java 2 Standard Edition) qui contient
les API de base de Java. Depuis sa version 5, J2EE est renommé Java EE (Enterprise Edition).

Notion de J2EE
J2EE est logiquement destiné aux gros systèmes d’entreprise. Les logiciels employés à ce ni-
veau ne fonctionne pas sur un simple PC mais requière une puissance beaucoup plus importante.
Pour cette raison, les applications doivent être constituées de plusieurs composants pouvant être
déployés sur des plate-formes multiples afin de disposer de la puissance de calcul nécessaire.
C’est la raison d’être des applications distribuées.
J2EE est une collection de composants, de conteneurs et de services permettant de créer et
de déployer des applications distribuées au sein d’une architecture standardisée.

44
Les Conteneurs
Les conteneurs sont les éléments fondamentaux de l’architecture J2EE. Les conteneurs fournis
par J2EE sont de même type. Ils fournissent une interface parfaitement définie ainsi qu’un
ensemble de services permettant aux développeurs d’applications de se concentrer sur la logique
métier à mettre en oeuvre pour résoudre le problème qu’ils ont à traiter, sans qu’ils aient à
se préocuper de toute l’infrastructure interne. Les conteneurs s’occupent de toutes les tâches
fastidieuses liées au démarrage des services sur le serveur, à l’activation de la logique applicative,
la gestion des protocoles de communication intrinsèque ainsi qu’à la libération des ressources
utilisées.

Les Servlets
Une servlet est un programme écrit en JAVA qui tourne sur la machine du serveur J2EE.
Une servlet est chargée lorsque le serveur est mis en route ou lorsque le premier client fait appel
aux services de la servlet.Le serveur Web reçoit une demande adressée à une servlet sous la
forme d’une requête HTTP. Il transmet la requête à la servlet concernée, puis renvoie la réponse
fournie par celle du client . La servlet reçoit également les paramètres de la requête envoyée par le
client. Elle peut alors effectuer toutes les opérations nécessaires pour construire la réponse avant
de renvoyer celle-ci sous forme de code HTML. Une fois chargée, une servlet reste active dans
l’attente de nouvelles requêtes. Une servlet doit soit implémenter l’interface javax.servlet.Servlet
ou étendre soit la classe javax.servlet.GenericServlet soit javax.servlet.http.HttpServlet.

Fig. A.4 – Servlet étendant la classe javax.servlet.http.HttpServlet

Les pages Jsp

Créer des servlets consiste à construire des composants Java capables de produire du code
HTML. Dans de nombreux cas, cela fonctionne sans problème. Toutefois, il n’est pas facile, pour
les personnes chargées de concevoir l’aspect visuel des pages Web, de manipuler du code Java,
auquel elles n’ont probablement pas été formées. C’est la raison d’être des JavaServer Pages.
Les JSP sont des documents de type texte, contenant du code HTML ainsi que des scriptlets
(et/ou des expressions), c’est-à-dire des morceaux de code Java.

45
 Fig. A.5 – Les pages JSP dans une application J2EE.

Les JavaBeans
Selon la spécification des Javabeans, une Bean est un composant logiciel réutilisable pouvant
être manipulé visuellement dans un outil de construction (builder tool). Un composant possède :
– des propriétés persistantes
– des événements reconnus
– des méthodes de traitement des événements

Les Serveurs D’application

Le serveur d’application est l’environnement d’exécution des applications côté serveur. Il
prend en charge l’ensemble des fonctionnalités permettant à plusieurs utilisateurs d’exploiter
une même application. Parmi ces fonctionnalités nous pouvons citer :
– Gestion de la session utilisateur : c’est le fait de conserver pour chaque utilisateur un
contexte qui lui est propre, et cela se fait généralement en générant un identifiant unique
pour chaque client et en le transmettant lors de chaque échange HTTP.
– Gestion des montées en charge et reprise sur incident : afin de gérer toujours plus d’uti-
lisateurs, le serveur d’application doit pouvoir se déployer sur plusieurs machines et,
éventuellement, offrir des possibilités de reprise sur incident.
– Ouverture sur plusieurs sources de données : pour rendre accessible les données de l’appli-
cation, le serveur d’application doit pouvoir accéder à de nombreuses sources de données.

Le Modele MVC
Le modèle MVC (Model View Controler) a été initialement développé pour le langage Small-
talk dans le but de mieux structurer une application avec une interface graphique.
Ce modèle est un concept d’architecture qui propose une séparation en trois entités des
données, des traitements et de l’interface :

46
 Fig. A.6 – Le modèle MVC.

– Le Modèle représente les données de l’application généralement stockées dans une base de
données.
– La Vue correspond à l’IHM (Interface Homme Machine).
– Le Contrôleur assure les échanges entre la vue et le modèle notamment grâce à des com-
posants métiers.
L’utilisation du modèle MVC rend un peu plus compliqué le développement de l’application
qui le met en oeuvre mais il permet une meilleure structuration de l’application. Le principal
défaut du modèle MVC est le nombre de servlets à développer pour une application. Comme
remède à ce problème, le modèle MVC2 s’est imposé. En effet cette version du modèle propose
de n’utiliser qu’une seule servlet comme contrôleur de tiute l’application.

47