Institut de la Francophonie pour l'Informatique

Rapport du stage

Projet “ClipackSRM”
La couche de Présentation
Génération de rapports

Responsable du stage: Erwan Tesson
Stagiaire: Mai Thuy Nga

Chef de Projet
Etudiante de Promotion 7, IFI


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

TABLE DES MATIERES
REMERCIEMENTS ...............................................................................................................................5
RESUME .............................................................................................................................................6
ABSTRACT .........................................................................................................................................6
CHAPITRE 1 : INTRODUCTION ..................................................................................................7
1.
2.
3.
4.

PROBLEMATIQUE ........................................................................................................................7
MOTIVATION ..............................................................................................................................7
OBJECTIF DU STAGE ....................................................................................................................8
ENVIRONNEMENT DE STAGE .......................................................................................................8
4.1. Société Clipack...................................................................................................................8
4.2. Projet ClipackSRM ............................................................................................................9

CHAPITRE 2 : ARCHITECTURE ET SOLUTION DU PROJET............................................10
ARCHITECTURE DE L’APPLICATION CLIPACKSRM....................................................................10
DESCRIPTION DES COMPOSANTS DE L’ARCHITECTURE ..............................................................11
COUCHE DE PERSISTANCE ........................................................................................................13
3.1. Persistance avec Object Relational Mapping (ORM)......................................................13
3.2. Architecture ORM ............................................................................................................13
3.3. Oracle9iAS Toplink..........................................................................................................14
4. COUCHE METIER ......................................................................................................................14
5. COUCHE DE PRESENTATION ......................................................................................................16
5.1. Le modèle MVC................................................................................................................16
5.2. Appliquer le modèle MVC dans l’application Clipack ....................................................17
6. TECHNOLOGIES XML...............................................................................................................18
6.1. Généralités XML ..............................................................................................................18
6.2. Valider Document XML avec DTD..................................................................................18
6.3. Parseur XML (DOM et SAX) ...........................................................................................19
6.4. Généralités XSL ...............................................................................................................19

1.
2.
3.

CHAPITRE 3 : IMPLEMENTATION DE LA COUCHE DE PRESENTATION ..................20
1.

2.

VUE DU CLIENT AVEC XML/XSL.............................................................................................20
IMPLEMENTATIONS ...................................................................................................................21
2.1. Diagramme de état/activité..............................................................................................21
2.2. L’interface du client dans ClipackSRM ...........................................................................22
2.3. Les diagrammes de séquences et de classes ....................................................................23
3. MECHANISME D’INTERNATIONALISATION DE CLIPACK .............................................................26
3.1. Multilangues ....................................................................................................................26
3.2. Implémentation ................................................................................................................27
4. IMPORTER/EXPORTER DE DONNEES ..........................................................................................29
4.1. Généralité ........................................................................................................................29
4.2. Exporter données en document XML et Excel .................................................................31
4.3. Importer des données utilisant Document XML ..............................................................33
5. MENU MULTI-NIVEAUX AVEC XML/XSL ET JAVASCRIPT/CSS................................................35
5.1. Les caractéristiques de Menu multi-niveaux ...................................................................35
5.2. Implémentation ................................................................................................................37

CHAPITRE 4 : MECANISME POUR GENERER DES RAPPORT A PARTIR DE
“TEMPLATE » ................................................................................................................................40
1.

PAGINATION DES DOCUMENTS ET DES RAPPORTS.....................................................................40

MAI Thuy Nga

2/60


DEPA

2.
3.

Rapport de Projet de Fin d’Etudes

Clipack

ARCHITECTURE XSL-FO..........................................................................................................40
GENERATEUR DE RAPPORTS AVEC XSL-FO (FOP)...................................................................41
3.1. Création de Datasheet Template .....................................................................................42
3.2. Générer la source XML à partir de objets Java (DatasheetTemplate)............................46
3.3. Rapport Datasheet Template avec XSL-FO.....................................................................48
3.4. Résultats...........................................................................................................................50

CHAPITRE 5 : CONCLUSION .....................................................................................................51
ANNEXES.........................................................................................................................................52
LE FICHIER XSL POUR LE MENU MULTI NIVEAU...............................................................................52
LE FICHIER XSL FO POUR LES RAPPORTS ........................................................................................55
GLOSSAIRE.....................................................................................................................................58
BIBLIOGRAPHIE ...........................................................................................................................60

MAI Thuy Nga

3/60


DEPA

Rapport de Projet de Fin d’Etudes


Clipack

TABLE DES FIGURES
Figure 1:
Figure 2:
Figure 3:
Figure 4:
Figure 5:
Figure 6:
Figure 7:
Figure 8:
Figure 9:
Figure 10:
Figure 11:
Figure 12:
Figure 13:
Figure 14:
Figure 15:
Figure 16:
Figure 17:
Figure 18:
Figure 19:
Figure 20:
Figure 21:
Figure 22:
Figure 23:
Figure 24:
Figure 25:
Figure 26:
Figure 27:

Figure 28:
Figure 29:
Figure 30:

MAI Thuy Nga

Diagramme Multi couches dans ClipackSRM__________________________ 10
Architecture des ClipackSRM composants ____________________________ 11
Architecture ORM _______________________________________________ 13
Un exemple d’utilisation pattern Factory avec les objets BO et PState ______ 15
Modèle MVC ___________________________________________________ 16
Design Pattern MVC dans ClipackSRM ______________________________ 17
Workflow de transformation XSL ___________________________________ 20
Diagramme de état/activité ________________________________________ 21
L’interface du client dans ClipackSRM ______________________________ 22
Diagramme de séquences pour la couche de présentation ________________ 23
Diagramme de classes pour la couche de présentation __________________ 24
Schéma relationnel de la base de données pour la localisation ____________ 27
Diagramme de séquences pour la localisation _________________________ 28
Schéma pour Exporter Catégories (XML/Excel)________________________ 29
L’exemple du module Export de Catégories vers Excel __________________ 31
Export dans le format XML (généré par ClipackSRM) __________________ 32
Export vers Excel (généré par ClipackSRM) __________________________ 32
L’exemple du module Importer de Catégories _________________________ 33
Le menu multi-niveaux ___________________________________________ 36
Génération de menu multi-niveaux __________________________________ 37
Le schéma pour le document XML multi-niveaux _______________________ 38
Workflow de Transformation XSL FO _______________________________ 41
Workflow du module Génération de rapports__________________________ 42
Utilisation d’outil «Toplink Mapping Workbench» _____________________ 43

Interface de la création d’un Datasheet Template ______________________ 44
Diagramme de séquence de création DatasheetTemplate avec Toplink______ 45
Le diagramme de classes pour générer la source XML à partir de objets Java 47
Diagramme de séquences pour générer la source XML à partir de objets Java48
Diagramme de séquences pour générer un rapport _____________________ 49
Un exemple de rapport d’un Produit (générer par Clipack) ______________ 50

4/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

Remerciements
Je tiens tout d’abord à remercier Messieurs Marc Dufour et Erwan Tesson de m’avoir donné la
chance d’intégrer la société Clipack ainsi de leurs soutiens et de leur confiance.
Je cite plus particulièrement Monsieur Laurent Foret ingénieur développeur Clipack d’avoir été
présent pour répondre à mes questions. Il m’a beaucoup aidé à comprendre les problèmes
techniques.
Je remercie également Monsieur Laurent Berteau responsable informatique pour ses conseils et ses
soutiens tout au long de mon stage.
J’exprime mon entière reconnaissance à ma famille et mes amis pour leurs aides, leurs
encouragements.

MAI Thuy Nga

5/60



DEPA

Rapport de Projet de Fin d’Etudes

Clipack

Résumé
Ce rapport rend compte du stage que j’ai pu effectué pendant 6 mois dans la société Clipack. Dans
ce temps, j’ai déjà participé à l’équipe de développement du projet ClipackSRM, c’est un logiciel
utilisant les technologies Internet pour optimiser les pratiques Achats en particulier pour le secteur
CPG, Consumer Packaged Goods : agro-alimentaire, pharmacie, cosmétique, etc.
D'abord, je présente l'architecture de couches du projet, les choix de conception et d'implémentation
effectués dans chaque couche. Ensuite, je développe la couche de Présentation et les modules
concernant comme la localisation d'interface, l'importer/exporter de données entre client et système.
En fin, je construis un mécanisme pour générer les rapports en utilisant la technologie XSL-FO

Abstract
This thesis has reported my working as the final practice for 6 months at Clipack Company. During
this time, I have involved in a development team of the project ClipackSRM, pure-internet software
enables your enterprise to optimize Product Development and Purchasing processes for Consumer
Product Goods
The first assignment, I present the project’s layering architecture, the reasonable selection of the
design and implementation for each layer. Then, I develop the Presentation layer and its related
modules such as Interface localization, import/export data between client and system. And last, I
construct the reporting mechanism using XSL-FO technology that supports the system to define and
generate a printable report for its entities

MAI Thuy Nga


6/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

CHAPITRE 1 : INTRODUCTION
1. Problématique
La tendance traditionnelle est changée complètement par les technologies Internet. On a créé un
marché sans frontière sur l’Internet où permet tous les clients de chercher et acheter des
marchandises à leur bureau, particulièrement ces transactions ont lieu dans le temps réel. Ces
applications sont appelées « e-commerce application » et utilisées sur la plat-forme Web.
ClipackSRM est une de ces applications dédié aux industries du secteur CPG-Consumer Packaged
Goods (agroalimentaire, cosmétique, pharmacie, électronique grand public, etc.)…, elle fournit des
outils pour aider fournisseurs et clients à mieux se comprendre afin d’élaborer plus efficacement
leurs produits. Le but est d’établir une relation gagnant-gagnant par l’intermédiaire de ce système de
communication ouvert.
Cette application utilise la technologie J2EE, son architecture est divisée en trois couches
principales:
•

Couche de présentation

•

Couche métier


•

Couche de persistance

La couche de présentation est responsable de créer l’interface utilisateur, c’est à dire générer et
diffuser les pages Web affichées sur un navigateur. Elle joue un rôle très important dans toute
l’application, elle doit s’adapter à quelques critères comme le temps d’affichage, l’attirance, le
dynamisme,.... Nous voudrons donc trouver un mécanisme pour construire une couche de
présentation avec la meilleure performance
De plus, nous souhaitons ajouter un nouveau module qui est responsable de générer des rapports
sous forme des fichiers PDF, XML …

2. Motivation
Après avoir fini le cours DEPA en Informatique à l’IFI, nous faisons un stage d’une durée de six
mois environ. Il y a deux types du stage: développement ou recherche
Depuis longtemps, les applications d’entreprise m’intéressent beaucoup. Pour attirer plusieurs
clients, ces logiciels doivent faire concurrence aux autres, ils ont donc des solutions optimisées de
technologie.
Clipack est une jeune société, son orientation est de faciliter les relations B2B (Business-toBusiness) dans le domaine des achats, son application développée en Java s’appuie sur une base de
données accessible sur Internet et mise à jour en temps réel par et pour les utilisateurs
C’est la raison pour laquelle j’ai choisi le premier type de stage et participé à l’équipe de
développement du projet ClipackSRM.
Cela m’apporte certains intérêts:
-

Acquérir rapidement une réelle compétence pratique dans la conception d'applications J2EE

-


Apprendre les nouvelles technologies concernées par le projet: XML, XSL et XSL-FO,
Oracle, designs pattern …

-

Acquérir les expériences de travail en équipe

MAI Thuy Nga

7/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

3. Objectif du stage
Effectué dans le cadre du DEPA, ce stage a pour but de découvrir les responsabilités, les contraintes
mais aussi le déroulement d’un projet de sa conception à sa réalisation. C’est l’occasion également
de mieux appréhender les différents aspects de la vie professionnelle.
Concrètement, mes travaux à Clipack sont:
-

Saisir le business de l’application ClipackSRM

-

Faire des recherches avec l’architecture du projet.


-

Concevoir les modules logiciels utilisant UML

-

Implémenter les deux parties ci-dessous utilisant les technologies Java, XSL/XML...
o La couche de présentation de l’application
o Le mécanisme génère des rapports sous forme PDF, Excel, XML

-

Intégrer dans le projet

4. Environnement de stage
4.1. Société Clipack
Clipack est une société dédiée à l’optimisation de la gestion des achats d’article complexes (carton,
plastique, aluminium, etc.) grâce aux technologies Internet.
Créée à la fin de l’année 2000, Clipack est aujourd’hui une équipe d’une dizaine de personnes
disposant d’une double expérience de terrain dans le domaine des achats techniques complexes
(emballages notamment) et une expertise technologique de pointe
Les actionnaires principaux de Clipack sont constitués de fonds d'investissement indépendants ayant
pour objectifs d’assurer de façon pérenne le développement d’une entreprise innovante dans un
secteur en pleine mutation.
Institut Régional de Développement Industriel
Socri
Clipack a reçue dès début 2001 la qualification d' " entreprise innovante " de la part de l’Anvar
(Agence Nationale de Valorisation de la Recherche) qui participe en outre à son développement à
travers des aides financières significatives.

Le Conseil Régional d’Aquitaine a également soutenue financièrement l’entreprise dès ses débuts
Clipack a conclu divers partenariats afin d’approfondir son expertise métier et technologique,
notamment avec ;
Ecole Supérieure d’Ingénieurs en Emballage et Conditionnement.
Oracle
MAI Thuy Nga

8/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

4.2. Projet ClipackSRM
ClipackSRM est un logiciel de Supplier Relationship Management dédié aux industries du secteur
CPG-Consumer Packaged Goods (agroalimentaire, cosmétique, pharmacie, électronique grand
public, etc.). Il est destiné particulièrement à traiter les questions de création des spécifications
techniques et d’achats des articles concernés.
ClipackSRM est un logiciel collaboratif utilisant pour la communication entre utilisateurs les
technologies Internet. Il est proposé sous forme de modules pour adresser différentes fonctionnalités
:
PackStudio : pour administrer l'application et, en particulier, modéliser les règles qui seront
appliquées par les autres modules.
PackDesign : pour spécifier collaborativement (en interne et avec les fournisseurs) ses
articles en respectant un ensemble de règles (métier, validation, etc.).
PackSpecs : pour gérer toutes les spécifications (techniques, logistiques, qualité, etc.) des
articles achetés. PackSpecs permet de visualiser facilement les informations pertinentes et de

les mettre en forme.
PackIntelligence : pour analyser les données sous une forme synthétique (tableaux,
graphiques, statistiques, etc.) et prendre les bonnes décisions de développement et d’achat de
produits complexes
PackTender : pour mettre en concurrence les fournisseurs (RFI, RFQ, appels d’offres,
enchères inversées, etc.). PackTender peut être utilisé seul ou se connecter à d’autres
opérateurs (places de marché, outils de e-sourcing, etc.)
PackOrder : pour lier le système de commandes de l’entreprise avec les spécifications
techniques des articles et l’enrichir avec des fonctions de gestion collaborative
d’évènements

MAI Thuy Nga

9/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

CHAPITRE 2 : ARCHITECTURE ET SOLUTION DU PROJET
1. Architecture de l’application ClipackSRM
Aujourd’hui, les applications Web, et surtout les applications d’entreprise, sont de plus en plus
complexes et variées. Les développeurs et consultants de logiciel dépensent beaucoup de temps
pour créer des applications d’entreprise qui ont la meilleure efficacité dans la phase de
développement et ainsi dans la phase de maintient du projet.
Pour éviter de "réinventer la roue", nous devrions considérer comment on peut réutiliser et intégrer
les technologies et les composants business pour définir notre architecture.

Les composants business nous permettent de développer la logique business en utilisant un
ensemble d'interfaces et de remplacer des fonctionnalités avec des nouvelles versions. De plus, nous
pouvons utiliser les dernières implémentations supportées par les fournisseurs. Cette solution
s'assure que le projet tient à « up-to-date » avec les nouvelles technologies.
L’application d’entreprise ClipackSRM comme toute application J2EE est une architecture multicouches. L’idée de cette architecture est de séparer clairement les différents niveaux de traitements
informatiques nécessaires pour la mise en œuvre d’une application

Application
Design Level

Project
Implementation Level

Client layer

Web layer

Business layer

HTML pages
css/javascript

JSP/Servlet

Business Object
Managers

XSL Processor

Business

Objects

Database layer

ORM (Toplink)

Database

Persistence
Objects

Figure 1: Diagramme Multi couches dans ClipackSRM
Dans ce diagramme, le premier niveau désigne les principales couches du projet en phase de
développement, le deuxième niveau désigne le détail des technologies qui sont utilisées dans chaque
couche du projet
Avec ce workflow, ClipackSRM a les caractéristiques suivantes:
-

L’application est généralement divisée en trois couches principales et elles s’appliquent à
résoudre les problématiques suivantes:
+ La présentation de l’information à l’utilisateur (couche de présentation)
+ La résolution des problématiques relatives au métier des utilisateurs (couche métier)
+ La persistance des données traitées par l’application (couche de persistance)

MAI Thuy Nga

10/60


DEPA


Rapport de Projet de Fin d’Etudes

Clipack

-

Dans chaque couche et ses components, on utilise les « design pattern », par exemple MVC,
Factory pour augmenter la performance

-

Plus particulièrement, avec cette architecture, ClipackSRM peut intégrer facilement aux
autres components d’entreprise pour chaque couche et ne pas faire des influences aux autres
couches

2. Description des composants de l’architecture
Le diagramme ci-dessous présente les différents composants intervenant dans l'architecture de
l'application Clipack. Ils sont décrits ci-après en étant regroupé suivant trois groupe correspondant
aux différents éléments intégrés pour créer l'application: Akazi-Flowmind, les composants Access
Commerce et les développement spécifiques.

Akazi
Flowmind

J2EE Application (OC4J)
Business
Operations
Clipack
Application

Toplink

eConf igurator

Log4j

XSL
Processor

Clipack Database Oracle
8.1.6

CameleonVE Database
Oracle 8.1.6

CorbaCAS

EConf igurator Database
Oracle 8.1.6

Figure 2: Architecture des ClipackSRM composants
Je présenterais ici les composants d’Acces Commerce et développements de Clipack.
Les composants Access Commerce
L’application Clipack est bâtie autour de l’intégration des composants d’Access Commerce, en
particulier du composant eConfigurator.
Le composant eConfigurator est une applet qui communique avec des pages JSP hébergées par le
serveur d’application. Ces pages JSP font des appels, via IIOP, au CorbaCAS qui implémente la
logique du configurateur.
MAI Thuy Nga


11/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

En complément de ces composants standard, Access Commerce a développé un composant
spécifique qui offre les fonctionnalités suivantes:
• Génération d’articles standard à partir des configurations créées par l’applet eConfigurator
• Génération d’un flux XML représentant la différence entre deux configurations
• Copie d’une configuration
• Upload de fichiers joints
Les composants Access Commerce utilisent deux bases de données différentes:
• CameleonVE contient toutes les données relatives à l’application Visual Expert: description
des modèles configuration, description des critères, classes de critères et des articles
standards, ainsi que les tables utilisées par les développements spécifiques.
• EConfigurator contient les données utilisées par les développement spécifiques: stockages des
configurations au format XML, etc.…
Les développement spécifiques: l’application Clipack
Pour les développements spécifiques de l’application Clipack, nous utilisons un certain nombre de
librairies Java externes dont: Log4J, Xalan, Ant, Toplink, Junit …
Log4J est une librairie permettant d’ajouter des informations de debug dans le code. Log4J définit
cinq niveaux de gravité pour le debug qui sont: DEBUG, INFO, WARNING, ERROR, FATAL.
Log4J peut être paramétré (via un fichier de configuration) pour n’afficher les erreurs qu’à partir
d’un certain niveau de gravité. De plus, les informations émises par Log4J peuvent être dirigées vers
de multiples destinations: fichier, console, mail, base de donnée. Ainsi, sur un environnement en
production, on peut décider d’envoyer toutes les information d’un niveau de gravité ERROR ou

FATAL par mail à un compte administrateur, tandis que les informations de niveau WARNING,
ERROR et FATAL sont inscrites dans un fichier et que les informations de niveau DEBUG ne sont
pas affichées du tout.
Xalan effectue les transformations XSL sur des documents XML. Nous l’utilisons dans
l’implémentation de la couche de présentation. Cette utilisation est décrite en détail dans la suite du
document.
Toplink est un outil de mapping objets/relationnel, et facilitent le développement de la couche
d’accès aux données.
Akazi-Flowmind
Le composant Flowmind d'Akazi doit servir à mettre en oeuvre les Processus métiers de PackSRM.
Il se compose d'un éditeur graphique de processus et d'un moteur d'exécution de ces workflows.
L'avantage de ce type de système est de permettre à des experts métiers non informaticiens de
définir les workflows sans connaissances informatiques avancées. Cela permet aussi de modifier ces
processus métiers de manière dynamique car ils ne sont pas codés en dur dans l'application.

MAI Thuy Nga

12/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

3. Couche de Persistance
3.1. Persistance avec Object Relational Mapping (ORM)
La plupart des applications entreprises ne peuvent évidemment pas fonctionner sans une couche de
persistance. Elle contient un ensemble de classes, dédiées aux interactions avec une base de

données, telles que le passage d’un article en un objet Java, et vice-versa.
Avec JDBC, les développeurs doivent « hardcoder » les commandes SQL. C’est-à-dire ils doivent
gérer eux mêmes les champs et les tables en utilisant le langage SQL. Cela ne s’accorde pas aux
applications courantes d'entreprise.
Aujourd’hui, les entreprises maîtrisent bien le modèle relationnel et doivent adopter des modèles
objet pour répondre aux contraintes de flexibilité. 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.
ORM rend la couche persistante transparente (en utilisant l’API) et indépendante du type de base
des données. Le transparence simplifie considérablement des applications et améliore la capacité de
maintient en se cachant les détails de l’implémentation des de bases des données

3.2. Architecture ORM
ORM est utilise pour mapper les objets des Programmation Orientée Objet (object-oriented
programming - OOP) et la base de données relationnel. Beaucoup de produits utilisant ORM sont
conçus pour travailler bien avec les langages OOP comme OracleToplink, Hibernate, SimpleORM,
Castor...
On peut illustrer le workflow de l’architecture ORM comme suit:
Java Application
(PState layer)
Java
Objects

ORM Persistance Manager
ORM
Instance

A Query
Queries


ORM
Instance

Java
Objects

Transation
Transations

JDBC

Database

Descriptors

Figure 3: Architecture ORM
Dans cette architecture, il y a une partie de données qui est appelé « Descriptors » (sous forme les
fichiers XML). Le ORM Persistance Manager a besoin de cette information pour mapper ces objets
Java avec les données de la base. Une interface graphique est utilisée pour créer ces descripteurs, il
lit les méta-données (tables, champs, relations,..) et permet aux utilisateurs de définir des règles de
mapping entre objets Java et tables dans la base de données. Ces règles sont stockées dans les
fichiers de descripteurs pour être utilisé après par le ORM Persistance Manager. On doit créer les
descripteurs avant de l’exécution du système et ils sont donnés au système exactement grâce aux
fichiers de configuration.

MAI Thuy Nga

13/60



DEPA

Rapport de Projet de Fin d’Etudes

Clipack

Dans l’exécution du système, ORM Persistence Manager convertit les objets Java en une forme
plus appropriée (ORM instance). Ensuite, ORM Manager va lire les descripteurs correspondants
pour transformer les instances en les requêtes SQL.
Les requêtes sont combinées pour créer une transaction, le système va exécuter cette transaction
pour échanger les données de la base de données. En effet, ce processus comme on utilise les
commandes SQL et JDBC pour travailler avec la base de données
Utilisant cette technologie, les entités de la base de données sont utilises comme les objets du
langage, ORM sont appliques dans les cas que les développeurs veulent prendre les avantages de
persistance transparent.

3.3. Oracle9iAS Toplink
Oracle9iAS Toplink est une des librairies qui conforme au workflow ORM ci-dessus, elle est
appliquée dans l’application Clipack comme couche de persistance dans son architecture.
Oracle a un outil « Toplink Mapping Workbench” qui fournit l’interface graphique pour aider aux
développeurs de configurer et mapper des objets. Cette interface fournit plusieurs avantages
caractéristiques pour :
•

Accéder à la base de données pour créer un schéma

•

Configurer ORM


•

Générer les descripteurs

4. Couche Métier
Cette couche est toujours responsable principale de tous processus du projet. Il y a généralement
deux grandes activités:
-

Obtenir les données de la couche de présentation, les analyser et traiter et ensuite envoyer les
résultats spécifiques à la couche de persistance

-

Stocker les données de la couche de persistance, les traiter et les transformer pour les
retourner à la couche de présentation (plus en détail dans la partie suivante)

Avec le rôle d’une couche intermédiaire, la couche métier est conçue pour gérer et deviser les
données en deux types différents : Les objets Persistance (PState) et les objets Business (BO)
-

Les objets PState: Ce sont des objets que la couche de business utilise pour travailler
directement avec la couche de la base de données en adoptant ORM. C’est le type d’objet
que ORM (Toplink) utilise pour mapper 1-1 entre les objets Java et la base de données

-

Les objets BO: Cependant, cette couche et la couche de présentation ont besoin des
informations qui sont complètement différents les objets PState, par exemple ils sont
l’intégration de quelques objets PState. Les PState ne sont pas encore approprie quand la

couche métier travaille avec la couche de présentation, on crée donc les objets BO. Ces
objets contiennent des informations complètes que la couche de business et de présentation
peuvent utiliser. Ici, on utilise le pattern de Fabrique (Factory) pour gérer et transférer ces
deux formes objets.

Considérant à la technologie, Clipack applique la technologie J2EE et les objets simples Java pour
maintenir son propre état. En utilisant les objets PState et BO, un mécanisme de transaction entre la
couche de présentation et la couche de persistance a été mis en place.
MAI Thuy Nga

14/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

Par exemple, le diagramme de classes ci-dessous avec l’utilisation du pattern de Fabrique maintient
des objets dans la couche de persistance
Toplink/Oracle
transaction library

Some create methods
depending on concrete
requirement as Factory patterns

BOFactory
(from bo)

create()

ConcreteBO
(from bo)
getPState()
getRelationBOs()
addRelationBO()

BOManager
(from bo)
getById()
getByXXX()
convertPStateToBO()
getFactory()

UnitOfWork
(from uow)
createTransation()
register()
commit()

PersistenceFactory
(from persistence)
create()

ConcretePState
(from persistence)
getRelationPState()
getRelationPStates()
addRelationPState()


ToplinkDAO
(from persistence)
getDatabaseSession()
getById()
getByXXX()

Figure 4: Un exemple d’utilisation pattern Factory avec les objets BO et PState
-

ToplinkDAO : Librairie pour mapper les données de la base de données en des objets PState
et vice-versa

-

UnitOfWork : Représente la transaction avec une base de données : Un enregistrement en
base ne sera effectif qu’après un commit (Toplink/Oracle)

-

ConcretePState, ConcreteBO: Un des objet concret de plusieurs objets dans le système

-

BOManager: ConcreteBO n’est considère que comme un objet, BOManager est donc crée
pour le but de fournir toutes les activités sur cet objet et permettre le système à utiliser
facilement.

-


Factory: Utiliser pattern Factory pattern pour créer les objets PState et BO

MAI Thuy Nga

15/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

5. Couche de Présentation
Dans les applications Web, le code du côté Serveur qui est responsable de créer l’interface
graphique utilisateur est abordé comme la couche de présentation. Il est différent de ce qui sont
affichés sur le navigateur du client (utiliser HTML, CSS et JavaScript). En d’autres termes, la
couche de présentation est la couche qui crée et construit l'interface utilisateur réside au niveau
serveur.
Un projet assez complexe comme Clipack avec plusieurs types de requêtes à partir du client, il est
nécessaire d’avoir une architecture correcte et un design pattern pour cette couche afin de contrôler
le workflow des données entre le navigateur du client et l’application Clipack.
Dans ce but, l’application Clipack construit la couche de Présentation en utilisant le design pattern
MVC (Model-View-Control). Avec cette solution, elle peut gérer tous les types de requêtes et de
plus, elle supporte facilement des nouveaux types.

5.1. Le modèle MVC
Le modèle MVC décompose une application en trois parties: le modèle, la vue et le Contrôleur
MVC Model
2. Process


1. Request

Controller

2.1. Load models
2.2. Update models

3. Inform

Model

User
4. Response

4.1. Load models
View

Figure 5: Modèle MVC
Le Modèle: C’est la partie métier, le cœur de l’application. Il contient l’état de l’application. Il est
complètement dégagé du couple Vue/Contrôleur. Son développement est ainsi effectué
indépendamment de la Vue et du Contrôleur. Le Modèle peut être alors réutilisé avec d’autres
modules.
La Vue: Elle réalise le rendu graphique de l’application. Elle ne connaît pas le contrôleur, et doit
être avertie de toute modification du Modèle
Le Contrôleur: Il réagit aux entrées de l’utilisateur, et gère les interactions entre le Modèle et la Vue

MAI Thuy Nga

16/60



DEPA

Rapport de Projet de Fin d’Etudes

Clipack

5.2. Appliquer le modèle MVC dans l’application Clipack
Clipack crée les packages en utilisant MVC pour la couche de Présentation comme suit:

persistence
(from portal)

bo
(from portal)

statemachine
(from presentation)

create/update

update

modelview
(from presentation)

retrieve data

ViewLayerJSP


Figure 6: Design Pattern MVC dans ClipackSRM
Ce diagramme ne décrit que l’utilisation du modèle MVC pour la couche de Présentation,
l’échange de données entre cette couche et la base de données est réalisé grâce aux 2 paquets BO et
Persistence (on a déjà l’abordé dans la partie précédant)
-

ViewLayerJSP: Composant de la Vue, se contient des fichiers JSP

-

ModelView: Composant du Modèle, se contient les objets Java qui «encapsuler» des
données d’une entité

-

StateMachine : Composant du Contrôleur, se contient les classes qui sont responsables de
toutes les activités métier sur les objets Modèle et Vue

ClipackSRM applique la technologie XML pour la couche de Présentation, néanmoins les objets
BO ne supporte pas des données XML. Donc, dans ce pattern, le composant ModelView est crée
pour supporter des données XML. Un état prend des données de la couche Business et convertit les
objets BO en un Modèle. Les objets Modèles supportent non seulement des données XML, ils
peuvent mais encore être modifiés sans changer les objets BO.

MAI Thuy Nga

17/60



DEPA

Rapport de Projet de Fin d’Etudes

Clipack

6. Technologies XML
6.1. Généralités XML
XML (eXtensible Markup Language) est une recommandation du W3C. C’est est un langage à
balise définissant un format universel de représentation des données.
Un document XML contient à la fois des données et les indications sur le rôle que jouent ces
données. Ces indications permettent de déterminer la structure du document : ce sont des balises.
XML est une sous partie de SGML (Standard Generalized Markup Langage) définit par l’ISO (ISO
8879). SGML est un langage international de documentation normalisée, standard de fait dans le
milieu de la gestion documentaire.
Voici un exemple simple de document XML. Il décrit une librairie qui contient une liste de
catégories, chaque catégorie se compose des livres.
<?xml version="1.0" encoding="UTF-8"?>
<library>
<category name="XML">
<book id="bbbbbb">
<title>XML specification</title>
<author name="Mr. D" fullname="Nguyen Van D"/>
56</price>
</book>
<book id="cccc">
<title>Oracle - Building XML application</title>
<author name="Mr. A" fullname="Nguyen Van A"/>
57</price>
</book>

</category>
<category name="Java">
<book id="11111">
<title>Java Server Programming</title>
<description>This is a book for java server programming</description>
<author name="Mr. A" fullname="Nguyen Van A"/>
<author name="Mr. B" fullname="Nguyen Van B"/>
50</price>
</book>
</category>
</library>

6.2. Valider Document XML avec DTD
DTD signifie Document Type Definition (ou définition de type de document), c'est la grammaire
historique des documents XML.
On utilise DTD afin de vérifier qu’un document XML est conforme à une syntaxe donnée.
Voici une DTD qui est utilise pour le document XML ci-dessus
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT library (category+)>
<!ELEMENT category (book*)>
name CDATA #REQUIRED
>
<!ELEMENT book (#PCDATA | title | description | author | price)*>
id CDATA #REQUIRED
>
<!ELEMENT title (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT author EMPTY>

name CDATA #REQUIRED
fullname CDATA #REQUIRED
>
<!ELEMENT price (#PCDATA)>

MAI Thuy Nga

18/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

6.3. Parseur XML (DOM et SAX)
Parseur XML, c’est l’analyseur syntaxique de documents XML qui permet de parcourir un
document XML et d’en extraire des données.
On distingue deux types des parseurs XML par leurs approches qu’ils utilisent pour accéder à un
document XML :
•

Les parseurs type «callback»: se basent sur un modèle d’envoi d’événements. Un parseur
parcourt le document XML et renvoie un événement à chaque élément rencontré. Le
programmeur définit le traitement à effectuer pour chaque événement, et peut ainsi
construire sa propre structure de données. Cette approche n’est cependant pas adaptée
lorsqu’on désire modifier le document XML. SAX (Simple API For XML) est l’API la plus
connue se basant sur cette technique. Elle est indépendante du langage de programmation

•

Les parseurs type «arbre»: utilisent la structure arborescente d’un document XML. Le
parseur charge le document XML en mémoire, sous la forme d’un arbre. DOM (Document
Objet Model) est l’API la plus connue répondant à cette approche. L’utilisateur parcourt et
modifie l’arbre à l’aide des interfaces définies par le W3C. Cette API est aussi indépendante
du langage de programmation

6.4. Généralités XSL
XSL (eXtensible StyleSheet Language) est un langage recommande par le W3C pour effectuer la
représentation des données de documents XML.
XSL est un langage permettant de définir des feuilles de style pour les documents XML comme les
CSS (Cascading StyleSheets) pour le langage HTML.
De plus, XSL permet de retraiter un document XML afin d’en modifier totalement sa structure, ce
qui permet a partir d’un document XML de générer d’autres types de documents (HTML, EXcel,
PDF, RTF...) ou bien un fichier XML de structure différente.
XSL est une spécification composée de deux parties:
•

XSLT: qui permet de réorganiser des documents XML

•

XSL-FO: qui permet de gérer la présentation d’un document XML

On va décrire l’architecture XSLT et XSL-FO dans les chapitres suivants.

MAI Thuy Nga

19/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

CHAPITRE 3 :
IMPLEMENTATION DE LA COUCHE DE PRESENTATION
Le chapitre précédent décrit l'architecture de l’application Clipack avec les conceptions et les
solutions pour chaque couche. L’architecture posée, Clipack s'assure que l'implémentation et la
maintenance pour une couche n’influenceront pas des autres couches. Dans ce chapitre, je vais
présenter les implémentations détaillées de la couche de Présentation de l’application Clipack.

1. Vue du client avec XML/XSL
Comme vous le savez, la couche de Présentation de l’application Clipack utilise le pattern MVC,
avec cette architecture, il y a 3 parties principales: Modèle (Model), Vue (View) et Contrôleur
(Controller). Pour les applications Web, la vue du client est ce qui est affiché sur le navigateur, ce
sont les pages contenant le code de HTML, JavaScript et CSS
Toutes les requêtes du client avec l’événement correspondant sont envoyés au Contrôleur d’état
(State), Ce dernier va traiter et mettre à jour les données au Modèle, ensuite il choisit un espace pour
rendre le résultat au client. Le problème est comment peut-on fusionner des données dans le Modèle
avec les « Template » prédéfini dans la vue pour plusieurs types de requêtes.
JSP est un bon choix pour la couche de Présentation de l’application Clipack. De plus, Clipack
applique une autre solution afin de séparer la Présentation et logique, c’est la technologie XML et
XSLT (Extensible Stylesheet Language Transformations)
Si la couche de Présentation est séparée de la couche de métier, les désavantages de JSP sont
éliminés. Cela est complété par l’intégration XML et XSLT dans l’architecture MVC. Les

composants dans la couche de métier génère des packages de données XML, y compris des données
de business et de localisations. . Les composants dans la couche de présentation transforment ces
données de XML avec un processeur XSLT aux modèles désirés de rendement, tels que le PDF,
HTML, ou XML. Ces modèles seront traités par les scripts XSL
Le workflow de la technologie XML/XSLT comme suit:
DTD
Document
XML
Documents
XSLT Processor
(Xalan)

Output Documents
(XML, Excel,
HTML, Text...)

XSL
Document

Figure 7: Workflow de transformation XSL
Cette approche fournit beaucoup d'avantages, donc Clipack applique cette technologie dans
plusieurs parties de son implémentation:

MAI Thuy Nga

20/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

•

La structure de l’application est claire, compréhensible et se coordonne bien avec
l’architecture MVC.

•

Il sépare tous les développeurs en 2 parties, une responsable de la conception Web et l'autre
responsable de la logique métier, c’est à dire on fait de découplage entre la présentation et le
modèle métier. Chaque partie peut commencer en même temps sans influencer à l'autre

•

Le serveur peut utiliser la même donnée pour générer des différentes formes des données
sorties comme HTML, PDF, EXcel …en utilisant les différentes feuilles XSL

•

Les changements dans la couche de Présentation peuvent être fait par ajout de nouvelles
feuilles XSL dans l’application, sans aucune influence sur les composants métier.

•

La maintenance de l’application est simplifiée

2. Implémentations

2.1. Diagramme de état/activité
L’application ClipackSRM utilise le mécanisme « event-driven » pour la couche de Présentation. Le
Contrôleur Web reçoit une requête HTTP du client, cette requête est conçue pour contenir un
paramètre appelé "event" avec quelques autres paramètres conditionnels qui dépendent de chaque
requête. Ces paramètres sont connus comme des "informations déterministes"
Le contrôleur évalue la requête sur cette information et l'état actuel puis décide comment répondre
au client. Ce processus d'évaluation implique l'interaction de la couche Métier pour envoyer ou
stoker des données entre le client et l’application. Une étape également importante est que le
contrôleur doit changer l'état actuel en un nouvel état quand il envoie la réponse au client.
Voici le diagramme d’état/Activité dans l’application Clipack:

7. Put State
for a new event

User

0. Init with a main Event/State
(one time only)

States
Mapping

Pairs of Event/State
2. Get State
(event)

1. Web Request
(event + paramters)

3. Process

(State found)
States
Controller
0. Init
(one time only)

Current State

4. Process (connect with BO layer)
(web paramters)

5. Create a new State
(step 4's result)
6. Register
New State

Figure 8: Diagramme de état/activité

MAI Thuy Nga

21/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

2.2. L’interface du client dans ClipackSRM

Figure 9: L’interface du client dans ClipackSRM
Ainsi, quand l’application est affichée, il y a quatre états actifs:
-

ControlPanel: frame en haut, se contient des commandes de contrôle utilisant le système des
menus

-

MailBox: frame à gauche, se contient des courriels de l’utilisateur connecté

-

ContentBody: frame centrale où affiche les résultats des commandes

-

DisplayMessage: frame en bas où affiche le contenu d’un courriel

MAI Thuy Nga

22/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

2.3. Les diagrammes de séquences et de classes
Voici le diagramme de séquence que Clipack a conçue pour la couche Présentation en utilisant
XML/XSL et l’architecture multi-couches décrites dans les parties ci-dessus. Cela est un simple
diagramme pour un état spécifique, les autres états utilisent les diagrammes similaires (on peut voir
la partie de diagramme de classes pour trouver la façon de créer un nouvelle état et l’enregistrer
dans le système)

WebController :
FrameControllerJSP

: User

login( )

StateController :
UserSessionMachine

Concrete State
: State

Concrete BOManager :
BOManager

Concrete Model
: XMLable

: DisplayInfo

Util class that wraps

data for web page

create( )
init( )

request( )
createUserInfo( )

handle( )

Get a State using web
parameter fromFrame from
the State Mapping table
getState( )
handle( )
Return a new
State

getById( )

setState( )

Put the State into the
State Mapping table
getModel( )

buildModel( )

getById( )

Connect to
BOManager for
getting data
create( )

create( )

getXml( )
getXsl( )
transformXSL( )
writeHT ML( )
User XSL Processor

Figure 10: Diagramme de séquences pour la couche de présentation

MAI Thuy Nga

23/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

UserSessionContext
(from statemachine)

State

(from statemachine)
handle()
buildModel()
getModel()
getXsl()
getContext()
getMachine()
setMachine()

UserSessionMachine
(from statemachine)
init()
setState()
getState()
handle()
UserInfo
(from statemachine)

ConcreteState
XMLable
(from modelview)
toXML()
create()

ConcreteModel

FrameControllerJSP
(from ViewLayerJSP)

DisplayInfo

(from statemachine)

login()
request()
createUserInfo()
transformXSL()

DisplayInfo()
getXml()
getXsl()
create()

Figure 11: Diagramme de classes pour la couche de présentation
-

BOManager: Ce diagramme aborde seulement la couche de Présentation, il n’y a pas donc
d’information de la base de données. Comme la section precedante, BOManager travaille
comme un composant principal pour échanger des données entre la couche de Présentation
et la base de données. Il permet de s'abstraire de la couche de persistance. En clair chaque
couche à ces responsabilités qui lui sont propres.

-

UserSessionMachine : le contrôleur de l’application.

-

UserSessionContext : il mémorise le contexte d’exécution pour un utilisateur comme une
table mapping des états et les autres informations de l’utilisateur courrant

-

State:
la
super
classe
de
tous
les
«
états
»
ConcreteState est un exemple d’état qui « extends» classe State,
ControlPanel, ChoiceWorkspace..., qui correspondent à deux de ces
l’utilisateur peut respectivement choisir une option dans les menus
choisir un espace de travail à afficher.

-

XMLable (Interface pour tous les objets Modèle): ClipackSRM appliqué la technologie
XML/XSL dans cette couche pour afficher plus efficace les pages Web. XMLable est conçu

MAI Thuy Nga

de
l’application.
il peut êtres l’état
états dans lesquels
de l’application ou

24/60


DEPA

Rapport de Projet de Fin d’Etudes

Clipack

pour convertir l’ensemble objets “pure” Java sous forme le document XML que le parser
XML et Processor XSL peuvent traiter
-

ConcreteModel: C’est un exemple Modèle dans le système. Il peut être ControlPanel_Model
ou ChoiceWorkspace_Model qui correspondent respectivement aux classes de présentation
des états ControlPanel et ChoiceWorkspace.

-

DisplayInfo: C’est une classe utility qui contient les informations nécessaire pour le page, ils
sont le document XML (le contenu du page Web) et le feuille XSL

-

FrameControllerJSP: Le page Web principal travaille comme un Contrôleur Web pour
toutes les requêtes à partir client. Le résultat de traitement des requêtes est un Modèle,
FrameControlleurJSP prend les données XML du Modèle correspondant puis utilise avec
une feuille de style XSL pour les transformer en une page HTML puis la renvoie au
navigateur de l’utilisateur.

Le diagramme ci-dessus est divisé en 2 étapes:
Etape initiale
Cette étape a lieu lorsqu’un utilisateur se connecte à l’application (login) :
-

La page WebControllerJSP crée une instance de UserSessionMachine, la « state machine »,
qui est stockée dans la session HTTP et sera utilisée pour répondre à toutes les requêtes de
l’utilisateur.

-

La state machine est ensuite initialisée. Elle crée alors les états de base nécessaires au
fonctionnement de l’application: ControlPanel, MailBox et DisplayMessage.

Etape d’exécution
Cette étape a lieu lorsqu’un utilisateur travailler le système (déjà connecte):
-

La page WebControllerJSP reçoit une requête HTTP de l’utilisateur. Elle initialise un objet
UserInfo avec cette requête, puis invoque la méthode handle de la « state machine ».

-

La requête HTTP doit contenir certains paramètres obligatoires comme la frame depuis
laquelle a été initiée la requête, la frame de destination du résultat de l’action, et l’événement
envoyé par l’utilisateur.

-

La State Machine recherche l’état courant de la frame qui a généré la requête, puis invoque

la méthode « handle » de cet état avec les informations envoyées par l’utilisateur.

-

Chaque état doit être en mesure de traiter toutes les requêtes qui émanent de cet état.

-

La méthode « handle » de l'état retourne un nouvel état après avoir fait les traitements
nécessaires, et après avoir initialisé ce nouvel état. La state machine mémorise ce nouvel état
comme étant l'état courant de la frame de destination de la requête.

-

Ensuite, la state machine invoque buildModel de ce nouvel état pour créer le modèle-vue
associé. C'est l'état qui crée le modèle-vue, qui l'initialise, et qui invoque la méthode toXml
pour créer la vue XML correspondant à l'état. L'état renseigne aussi un objet DisplayInfo, le
nom de la feuille XSL à utiliser pour afficher le document XML.

-

Finalement, WebControllerJSP effectue la transformation XML
code HTML généré en réponse à la requête utilisateur.

MAI Thuy Nga

HTML et retourne le

25/60