Université de Maroua The University of Maroua

**** ****
Institut Supérieur du Sahel The Higher Institute of the Sahel
**** ****
Département d’Informatique et des Department of Computer Science
Télécommunications and Telecommunications
**** ****

INFORMATIQUE ET TELECOMMUNICATIONS

Mémoire présenté et soutenu en vue de l’obtention du Diplôme d’INGENIEUR DE

CONCEPTION EN : INFORMATIQUE OPTION GENIE LOGICIEL

Présenté par

TSAGUE KENNE LANDRY

Licence en: Informatique
Matricule: 12X193S

Sous la Direction de

Pr. DANWE RAÏDANDI

Maître de Conférences
Devant le jury composé de :

Président : Pr. NSANGOU MAMA

Rapporteur : Pr. DANWE RAÏDANDI
Examinateur: Pr. EMVUDU WONO Yves
Invité: Ing. Baké Jc. BAKENEGHE (Software Coordinator de KOOSSERY)

Année Académique 2013 / 2014

 Université de Maroua The University of Maroua
**** ****
Institut Supérieur du Sahel The Higher Institute of the Sahel
**** ****
Département d’Informatique et des Department of Computer Science
Télécommunications and Telecommunications
**** ****

INFORMATIQUE ET TELECOMMUNICATIONS

Mémoire présenté et soutenu en vue de l’obtention du Diplôme d’INGENIEUR DE

CONCEPTION EN : INFORMATIQUE OPTION GENIE LOGICIEL

Présenté par

TSAGUE KENNE LANDRY

Licence en: Informatique
Matricule: 12X193S

Sous la Direction de

Pr. DANWE RAÏDANDI

Maître de conférences
Devant le jury composé de :

Président : Pr. Pr. NSANGOU MAMA

Rapporteur : Pr. DANWE RAÏDANDI
Examinateur: Pr. EMVUDU WONO Yves
Invité: Ing. Baké Jc. BAKENEGHE (Software Coordinator de KOOSSERY)

Année Académique 2013/2014

DEDICACE

À mes Parents

ii
REMERCIEMENTS

Je remercie l’Éternel Dieu Tout Puissant pour son amour inconditionnel envers
moi et pour toutes les grâces dont il ne cesse de m’innonder.
Mes remerciements vont particulièrement :
 Au Pr. NSANGOU MAMA pour l’honneur qu’il me fait de présider ce jury.
 Au Pr. EMVUDU WONO Yves pour le privilège qu’il m’offre en examinant
ce mémoire
 À mon encadreur académique Pr. DANWE RAÏDANDI pour sa disponibilité
et l’encadrement apporté tout au long de la rédaction de ce mémoire.
 À tous les enseignants de l’ISS Université de Maroua, en particulier ceux du
Département d’INFOTEL, plus précisément le chef du département d’INFOTEL
Dr. Olivier VIDEME BOSSOU et M. DOUWE HALLAM Vincent pour leur
dévouement et leurs sacrifices tout au long de ma formation.
 À tous les Ingénieurs coéquipiers du plateau technique de KOOSSERY pour
leur coopération et leur disponibilité.

Je tiens également à exprimer ma profonde gratitude à :

 Mon père, KENNE Thomas pour son amour et pour tous les sacrifices qu’il a
consentis à mon égard. Tu as fait de moi ce que je suis aujourd’hui.
 Ma mère, LONTSI Jacqueline pour son amour profond pour moi.
 Ma grand-mère, FOMENA qui n’a jamais cessé de croire en ma réussite. Grand-
mère, je te dis merci.
 Mes frères et sœurs qui m’ont toujours encouragé et soutenu dans les chemins
que j’ai eu à emprunter chaque fois.
 Ma fiancée BOUHOM TCHEMEULE Vanissa qui m’a apporté tout son amour
et son soutien pour concourir à ma réussite.
 Mes amis qui m’ont toujours accompagné que ce soit pour les conseils ou les
encouragements, particulièrement à M. ILOGA Sylvain, M. PAMBE Junior,
BADANG NGUEYEP Fabrice. Merci vous êtes plus que des amis.
 Ma famille de Maroua maman MENEYEOU Pauline J., TEWE FOKA
Philippe, CHESSEU Vanessa Claude et Ing. NGONGANG Herve. Merci
 À tous ceux qui de près ou de loin ont contribué à ma réussite. Merci, que la grâce
de Dieu soit avec vous.

iii
RÉSUMÉ

Pour mettre en place le travail collaboratif, les entreprises intègrent souvent

plusieurs logiciels différents développés en des technologies différentes. La société
KOOSSERY propose sa plate-forme intégrée koosseryDesk qui est un logiciel unique
contenant l’ensemble des modules nécessaires pour le travail collaboratif en entreprise.
Le fait d’être un logiciel unique procure des avantages techniques parmi lesquels :

- la facilité de déploiement : on déploie koosseryDesk en un seul tenant et on

n’a pas de problèmes d’intégration, plutôt que de devoir déployer plusieurs
logiciels aux technologies disparates

- réduire le coût de formation utilisateur : avec koosseryDesk on a une interface

utilisateur uniforme, plutôt que de devoir s’adapter à autant d’interfaces que
de logiciels disparates

- administration : avec koosseryDesk, on administre un seul logiciel plutôt que

de devoir administrer plusieurs logiciels disparates

- réduire le coût de maintenance : avec koosseryDesk, on maintient un seul

logiciel plutôt que de devoir maintenir plusieurs logiciels disparates

La plate-forme koosseryDesk pour être au complet propose un module

d’archivage qui se situe à la fin de la chaine du traitement de l’information. Le travail
présenté dans ce mémoire traite du développement des composants de services dans la
plate-forme koosseryDesk et de sa mise en œuvre dans le cadre du module 'archiving'
de koosseryDesk. Pour développer les composants de service du module archiving, il a
été réalisé une étude des spectres SEDA 1.0 (Système d’Échange de Données pour
Archivage) et de l’open source as@lae 1.3 puis la réalisation du projet UML, ensuite
l’implémentation du projet UML enfin une étude du moteur de validation de règles
métiers ‘Drools’ pour une intégration future à la plate-forme.

Mots-clés : Travail collaboratif, Archivage Électronique, Architecture orientée service (SOA),

Framework, Open source, Service.

iv
ABSTRACT

To implement collaborative work, firms often integrate several different software

developed in different technologies. The KOOSSERY Company offer its koosseryDesk
integrated platform which is unique software containing all the necessary modules for
collaborative work in business. The fact of being a single software provides technical
advantages including:

- Ease of deployment: koosseryDesk is deployed as a single piece and there are no

problems of integration, rather than having to deploy multiple disparate software
technologies

- Reduce the cost of user training: koosseryDesk provides a uniform user interface,
rather than of have to adapt to as many interfaces as disparate software

- Administration: with koosseryDesk there is administered a single software rather

than having to manage multiple disparate software

- Reduce the maintenance cost: with koosseryDesk there is maintained a single

software rather than having to maintain multiple disparate software

The platform koosseryDesk to be complete proposes an archiving module that is

situated at the end of the string of information processing. The work presented in this
thesis treats of services components development in the platform koosseryDesk and its
implementation under the 'archiving' module of koosseryDesk. To develop the service
components of archiving module, studies was made of sepectra SEDA 1.0 and open
source as@lae 1.3 and then realization of the UML project, after it there was an
implementation of the UML project, finally a study of business rules validation engine
‘Drools’.

Keywords: Collaborative work, Electronic Archiving, Service Oriented Architecture

(SOA), Framework, Open source, Service.

v
LISTE DES TABLEAUX

Tableau 1 : Cahier des charges des composants de service du module ‘archiving’ .............................. 37

Tableau 2 : Taux de réalisation des Fonctionnalités ............................................................................. 77

vi
LISTE DES FIGURES ET ILLUSTRATIONS

Figure 1 : Image d’illustration du travail collaboratif [google image] .................................................... 7

Figure 2 : Cycle de vie d’une archive [11] ............................................................................................ 13

Figure 3 : SOA à la Convergence des solutions [17] ............................................................................ 23

Figure 4 Architecture orientée application vs architecture orientée service [17] .................................. 24

Figure 5 – Structure du composant de service [17] ............................................................................... 26

Figure 6 - Représentation schématique du système [17] ....................................................................... 27

Figure 7- Données d'échange et données persistantes [17] ................................................................... 28

Figure 8 : Fonctionnement SOA [17] .................................................................................................... 28

Figure 9 : Schéma SEA selon SEDA [13] ............................................................................................. 30

Figure 10 Séquence système entre acteurs SEDA ................................................................................. 31

Figure 11: Structure d’une archive ........................................................................................................ 33

Figure 12 : Use Case View .................................................................................................................... 38

Figure 13 : Cas d’utilisation – Gérer transfert d’une archive ................................................................ 40

Figure 14 : Séquence système du use case – Transfer archives ............................................................ 40

Figure 15: Logical view ........................................................................................................................ 43

Figure 16 : Cartographie des services rendus par le Back-end.............................................................. 44

Figure 17 : Liste de Composant métier pour le module archiving ....................................................... 45

Figure 18 : Composant métier-« composant» Archive.......................................................................... 45

Figure 19-Diagramme de classe des DTO du composant métier archive ............................................. 46

Figure 20 : Diagramme de classe des dao du composant archive ......................................................... 47

Figure 21 : Diagramme de classe du ArchiveSISV ............................................................................... 48

Figure 22 : Illustration des DTO du «composant » Transfer................................................................ 49

Figure 23 : Illustration des DAO «composant » Transfer ..................................................................... 49

Figure 24 : Réalisation des cas d’utilisations ........................................................................................ 50

Figure 25 : Réalisation de cas d’utilisation ‘Transférer une archive’ .................................................... 54

Figure 26 : Architecture globale du module archiving .......................................................................... 55

vii
Figure 27 Relation de dépendance entre les couches [9] ..................................................................... 56

Figure 28: Principe d'isolation et de localisation des composants [9] .................................................. 58

Figure 29: Mise en œuvre du principe d'isolation des composants [9] ................................................. 58

Figure 30 : modèle 3-tiers détaillé du socle technique Java de Koossery Technology [9] ................... 59

Figure 31 : Communication des couches via spring .............................................................................. 60

Figure 32 : illustration de la mise en œuvre de Drools (google image) ................................................ 62

Figure 33 Intégration Contunie (google image) .................................................................................... 64

Figure 34 : Structure de koosseryDesk vue d’Eclipse ........................................................................... 65

Figure 35: représentation des éléments du module contract.................................................................. 66

Figure 36- Configuration des ressources pour la couche SISV ............................................................. 66

Figure 37 : ressources pour les services composés ............................................................................... 68

Figure 38: drools-koosseryhumanRules.drl........................................................................................... 69

Figure 39 : Configuration de l’AOP Pour la validation des règles ........................................................ 70

Figure 40 drools-config.xml .................................................................................................................. 70

Figure 41 : Résultat des tests pour TransfertServiceImpl...................................................................... 72

Figure 42 : Résultat des tests pour ArchiveServiceImpl ....................................................................... 73

Figure 43 : Résultat des tests pour DeliveryServiceImpl ...................................................................... 73

Figure 44 : Résultat des tests pour RestitutionServiceImpl ................................................................... 74

Figure 45 : Résultat des tests pour ReferentielServiveImpl .................................................................. 74

Figure 46 : Résultat des tests pour OrganizationServiceImpl ............................................................... 75

Figure 47 : Résultat des tests pour UserServiceImpl ............................................................................. 75

Figure 48 Résultat des tests pour RoleServiceImpl ............................................................................... 75

Figure 49 : Résultat des tests pour ArchivalAgreementServiceImpl .................................................... 76

Figure 50 : Résultat des tests pour ArchiveSISVImpl........................................................................... 76

viii
LISTE DES SIGLES ET ABRÉVIATIONS

Terme Signification

CMR Cameroun

SEDA Système d’échange de données pour Archivage

SEA Système d’Archivage Électronique

CRUD Create Read Update and Delete

IOC Inversion Of Control

AOP Aspect Oriented Programming

POO Programmation Orientée Objet

IDE Integrated Development Environment

UML Unified Modeling Language

SI System d’informations

SOA Service Oriented Architecture ou Architecture Orientée Service

DRL Drools Rule Language

XML eXtensible Markup Language.

DAO Data Access Object

DTO Data Transfer Object

SISV Service simple ou service interne

Service Service composé

SISV Service simple ou service interne

SIVCO Service à valeur ajouté ou service composé

SVN Subversion (système de gestion de version)

ix
TABLES DE MATIÈRES

INTRODUCTION ................................................................................................................................... 1

CHAPITRE I : CONTEXTE ET PROBLEMATIQUE .......................................................................... 2

I.1. Présentation de l’entreprise KOOSSERY ..................................................................................... 2

I.1.1 La Société KOOSSERY......................................................................................................... 2

I.1.2 Présentation de la plate-forme koosseryDesk ......................................................................... 2

I.1.2.1 Les fonctionnalités de la plate-forme kosseryDesk.............................................................. 3

I.1.2.2 Socle technique de kosseryDesk .......................................................................................... 5

I.1.2.3 Intégration de koosseryDesk en entreprise........................................................................... 5

I.2 Contexte ......................................................................................................................................... 6

I.3 Problématique ................................................................................................................................ 8

I.4 Méthodologie ................................................................................................................................. 8

I.5 Objectifs ....................................................................................................................................... 10

I.5.1 Objectifs généraux ................................................................................................................ 10

I.5.2 Objectifs spécifiques ............................................................................................................. 10

CHAPITRE II : GENERALITE SUR L’ARCHIVAGE ET LES ARCHITECTURES SYSTÈMES .. 11

II.1 Généralité sur l’archivage ........................................................................................................... 11

II.1.1 Définition des concepts ........................................................................................................ 11

II.1.2 Cycle de vie des archives ...................................................................................................... 12

II.1.3 Archivage électronique ........................................................................................................ 14

II.1.4 Les enjeux du module d'archive en entreprise ...................................................................... 15

II.2 Programmation orientée Objet (POO) ........................................................................................ 17

II.2.1 Introduction ................................................................................................................... 17

II.2.2 Concept de base de la POO [10].................................................................................... 17

II.2.3 Limites de la Programmation Orienté Objet (POO) ............................................................ 19

II.3 Les Design Patterns .................................................................................................................... 20

x
 II.3.1 Définition ............................................................................................................................. 20

II.3.2 Cartographie ........................................................................................................................ 20

II.3.3 Conséquences des Design Patterns ...................................................................................... 21

II.4 Les Architectures n-tiers ou en couches ..................................................................................... 22

II.4.1 Communication entre Objet ................................................................................................. 22

II.4.2 Problème ............................................................................................................................ 23

II.5 Les Architectures Orientées Services (SOA).............................................................................. 23

II.5.1 Introduction.......................................................................................................................... 23

II.5.2 Les principes et motivation .................................................................................................. 24

II.5.3 Les Éléments de base de l'architecture SOA ....................................................................... 25

II.5.4 Fonctionnement des SOA .................................................................................................... 28

CHAPITRE III ANALYSE ET CONCEPTION DES COMPOSANTS DU MODULE ARCHIVING

............................................................................................................................................................... 30

III.1 Présentation de la norme SEDA [13] ........................................................................................ 30

III.2. Cahier de Charge ...................................................................................................................... 34

III.3 Analyse et conception des composants du module Archiving .................................................. 38

III.3.1 Use Case View ................................................................................................................... 38

III.3.2 Logical View ...................................................................................................................... 43

III-Architecture logique du module archiving de koosseryDesk................................................... 55

CHAPITRE IV REALISATION DES COMPOSANTS DU MODULE ARCHINVING ................... 56

VI.1 Framework utilisés .................................................................................................................... 56

VI.1.2 Framework koosseryServer ................................................................................................ 56

VI.1.3 Framework Spring (IOC et AOP) ...................................................................................... 60

VI.1.4 Framework Drools ............................................................................................................. 61

VI.2 Environnement de développement ............................................................................................ 62

VI.2.1 Outil de modélisation UML (Enterprise Architect) ........................................................... 62

VI.2.2 IDE (Eclipse) ...................................................................................................................... 62

VI.2.3 Système de gestion de version (SVN) ................................................................................ 63

xi
 VI.2.4 Outil du build et de gestion du cycle de vie du projet (Maven) ......................................... 63

VI.2.5 Plate-forme de test (Junit) .................................................................................................. 63

VI.2.6 Plate-forme d'intégration continue ..................................................................................... 64

IV.3 Implémentation du module Archiving de koosseryDesk .......................................................... 65

IV.3.1 kooseryDesk.server.contract ............................................................................................. 66

IV.3.2 Service Simple .................................................................................................................. 66

IV.3.3 Service composés et exposition du serveur ....................................................................... 67

IV.3.4 Processus de test et d'intégration ....................................................................................... 68

VI.3.5 Mise en œuvre du moteur Drools dans un projet test ......................................................... 69

CHAPITRE V : RESULTATS ET COMMENTAIRES ....................................................................... 71

V.1 Le projet UML............................................................................................................................ 71

V.2 Projet Maven .............................................................................................................................. 71

V.2.1 Implémentation des cas d’utilisations.................................................................................. 71

V.2.2 Résultats des tests unitaires ................................................................................................. 72

V.3 Évaluation des composants de service du module ‘archiving’ ............................................... 77

CONCLUSION ET PERSPECTIVES .................................................................................................. 78

BIBLIOGRAPHIE ................................................................................................................................ 79

ANNEXE .............................................................................................................................................. 81

xii
INTRODUCTION
De nos jours les entreprises pour subvenir à leurs besoins informatiques, pour le
travail collaboratif déploient plusieurs logiciels spécifiques qu’elles intègrent par la
suite. L’intégration n’est en général pas évidente car d’une part il faut faire
communiquer des modules aux technologies disparates, d’autre part les coûts de
formation utilisateur, d’administration et de maintenance sont élevés car il faut
maintenir des briques hétérogènes…

La plateforme koosseryDesk est une réponse appropriée en ce sens qu’elle est une
plateforme qui se présente sous la forme d’une seule application disposant l’ensemble
des modules nécessaires au travail collaboratif.

Avec l’informatisation des entreprises la production des documents numériques est très
croissante et il se pose le problème de conservation car l’entreprise doit préserver sa
mémoire, fournir des éléments de preuves au tiers (clients, associés, etc.). C’est dans ce
sens que la plate-forme koosseryDesk propose son module ‘archiving’ (qui se place à la
fin de la chaine du traitement de l’information) pour l’archivage électronique.

Dans le cadre de notre stage d’ingénieur de conception au sein de la société

KOOSSERY il nous a été demandé d’une part de concevoir et réaliser les composants
de ‘service’ de la plate-forme koosseryDesk dans le cadre du module archiving et
d’autre part d’étudier le moteur de validation des règles métiers ‘Drools’ pour une
intégration future à la plate-forme.

Ce document est constitué de cinq chapitres. Le premier présente la société

KOOSSERY, le contexte du travail collaboratif, et la méthodologie pour la mise en
place des composants de service du module archiving. Le deuxième présente de façon
sommaire l’archivage électronique, les enjeux de l’archivage en entreprise et en fin les
concepts technique (POO, Design pattern, Architectures n-tiers et SOA) qui ont guidé
notre choie architectural. Le troisième présente l’étude de la norme SEDA 1.0, le cahier
des charges, puis la réalisation du projet UML du back-end (serveur) du module
archiving. Le quatrième chapitre présente l’implémentation du projet UML. Le
cinquième chapitre présente nos résultats obtenus et les commentaires.

1
CHAPITRE I : CONTEXTE ET PROBLEMATIQUE

I.1. Présentation de l’entreprise KOOSSERY

I.1.1 La Société KOOSSERY

KOOSSERY est une entreprise informatique de logiciels, fournisseur de la
plateforme intégrée de travail collaboratif koosseryDesk ainsi que des services autour
de ladite plateforme.
Outre d'être intégrée, la plateforme koosseryDesk est aussi modulaire et extensible. Elle
est développée à partir de diverses briques techniques et applicatives open source dont
certaines couvrent une partie des cas d’utilisation du travail collaboratif d’entreprise.
KOOSSERY dispose d'un plateau technique en Europe (FR) en charge des
activités d'intégration de la plateforme koosseryDesk auprès de ses clients européens
ainsi que d'un plateau technique en Afrique (CMR) pour divers développements back-
office.

I.1.2 Présentation de la plate-forme koosseryDesk

koosseryDesk est une plateforme intégrée, modulaire, extensible, complète,
omni-canal, pour le travail collaboratif. Elle a pour socle les meilleures briques
techniques et applicatives open source éprouvées réalisant une partie des cas
d’utilisation du travail collaboratif d’entreprise :

- Travail Collaboratif:

koosseryDesk permet de mettre à disposition de toutes les parties prenantes

(collaborateurs, fournisseurs, clients, partenaires, agences règlementaires, organismes,
administration, etc.) les contenus (documents électroniques, modèles, documents
papiers dématérialisés, audio, vidéo, etc.), les données (bases de données, flux
d’applications métiers tierces) pour une exécution efficiente des processus (Workflow)
de l’entreprise ou de l’organisation.

- Plateforme intégrée:

2
koosseryDesk fournit directement aux utilisateurs et aux développeurs une plateforme
intégrante parfaite.

I.1.2.1 Les fonctionnalités de la plate-forme kosseryDesk

koosseryDesk est composé des modules suivant :

- koosseryDesk .scanchain&analysing ;

- koosseryDesk.ecm&workflow ;

- koosseryDesk.signaturebook ;

- koosseryDesk.archiving ;

- koosseryDesk.dashbord ;

- koosseryDesk.report ;

- koosseryDesk.administration.

 koosseryDesk.scanchain&analysing:

L’information en input passe par ce module afin d’être analysée. L'information injectée
dans koosseryDesk peut provenir de divers systèmes : mail, documents papiers,
systèmes tiers (ERP, CRM, applications bancaires, applications assurances etc.), saisie
directe. Ce module est entièrement basé sur les API de Ephesoft et offre en standard
toutes les fonctionnalités d’Ephesoft. A ces fonctionnalités s’ajoutent des
fonctionnalités non couvertes par Ephesoft (exemple: envoi d’un document dans un
espace de travail et de workflow du composant koosseryDesk.ecm&workflow, envoi du
document vers un circuit de signature du composant koosseryDesk.signaturebook.

 koosseryDesk.ecm&workflow :

C’est le module des espaces de travail et de workflow. Il est entièrement basé sur les
API de Alfresco repository et offre en standard toutes les fonctionnalités de la GED
Alfresco. A ces fonctionnalités s’ajoutent des fonctionnalités non couvertes par Alfresco
(exemple= création de document à partir d’un modèle de document, configuration de

3
plan de classement par défaut pour les espaces de travail, publication vers d’autres
espaces de travail, envoie du document vers un circuit de signature du composant
koosseryDesk.signaturebook, envoi du document vers un circuit d’archivage du
composant koosseryDesk.archiving, envoi du document vers un circuit de
télétransmission.

 koosseryDesk.signaturebook :

Ce module offre des circuits de signature pour les documents. Ces circuits peuvent être
configurables et on peut également définir de nouveaux circuits.

 koosseryDesk.archiving :

Ce module assure la pérennité des documents dans le temps. Exemples d'archivage :

factures, relevés d’opération financière CIB.

 koosseryDesk.dahsbord :

Ce module permet à chaque utilisateur de disposer de son propre tableau de bord. Il

aide l'utilisateur à suivre les applications, les tâches et les évènements qui lui sont
assignés. Il fournit nativement un grand nombre de gadgets et on peut également en
intégrer d'autres. Les éléments de koosseryDesk.dashboard sont également disponibles
via les applications mobiles.

 koosseryDesk.report :

Ce module est basé sur les API Jasper report et permet d’avoir des indicateurs de suivi
sur un certain nombre de points et de processus de la plateforme.

 koosseryDesk.Administration :

La plateforme koosseryDesk offre une interface d’administration intégrée et unifiée:

– Users, role, membership management ;

– Business activity managment ;

– Functional log management.

4
I.1.2.2 Socle technique de kosseryDesk
La plate-forme koosseryDesk est une application java EE composée de :

 un front-end (le client):

Il est développé en utilisant Spring-MVC, Spring SURF, Freemaker templates et

Sencha. Le front-end présente au travers d'un seul point d'entrée, tous les composants
qui interviennent de bout en bout dans le processus de travail collaboratif. Le front-end
accède au serveur via une couche de services exposés.

 un back-end (le serveur):

Il est développé en mode SOA. Par exemple :

- le module “ecm&workflow” est basé sur Alfresco repository API, jBPM et

Lucene ;

- le module “ scanchain&analysing ” est base sur Ephesoft API ;

- le module “ reporting ” est base sur Jasper report API.

I.1.2.3 Intégration de koosseryDesk en entreprise

 Portail d'entreprise : la plate-forme koosseryDesk s'intègre dans tout portail
d'entreprise (exemple : Liferay) au travers de portlet.

 Annuaire d'entreprise : pour la gestion des comptes utilisateurs, la plateforme

koosseryDesk s'intègre avec des annuaires d'entreprise respectant la norme
LDAP.

 Authentification unique: la plateforme koosseryDesk fonctionne avec des

systèmes d'authentification SSO (openSSO).

 Standards: La plateforme koosseryDesk est développée à base de java EE en

utilisant des API standards et selon l’Architecture Orientée Services(SOA), ce
qui lui permet d'être interopérable avec des applications déjà présentes au sein
du système d'information. La plateforme koosseryDesk offre également des
connecteurs (exemple : connecteur CRM, …).

5
  Multilingue: La plateforme koosseryDesk est traduite en Anglais et en Français.

I.2 Contexte
De nos jours le travail collaboratif désigne un travail qui n'est plus fondé sur
l'organisation hiérarchisée traditionnelle, et plus spécifiquement un nouveau mode de
travail (éventuellement intégré dans un modèle économique de production) où
collaborent de nombreuses personnes grâce aux technologies de l’information et de la
communication. Le travail collaboratif (collaboratif Web) passe par la mise en œuvre
d'un intranet composé de fonctions dites collaboratives, permettant de dématérialiser les
processus, flux de communication et tâches de collaboration entre plusieurs
intervenants.

Les outils collaboratifs Web intègrent en général quatre grands types de

composants:

- Des services de communication (messagerie, messagerie instantanée,

mailing lists, chat, web meeting, visio-conférence, etc.) ;

- Des services de coordination des tâches (gestion de formulaires, workflow,

etc.) ;

- Des services de partage de ressources et d'applications (agenda, gestion de

tâches, plate-forme de fichiers, tableau blancs virtuels, etc.) ;

- Des services de partage de connaissances et de réseau social d'entreprise

(échange d'informations, gestion de contenu, recherche, etc.) ;

6
 Figure 1 : Image d’illustration du travail collaboratif [google image]

Jusqu’à présent, pour la mise en œuvre du travail collaboratif, les entreprises

déploient des logiciels spécifiques qu’elles intègrent ensuite. Elles déploient par
exemple un logiciel d’injection et d’analyse de l’information en entrée, un logiciel
d’archivage déployé à part, un logiciel d’ECM&workflow, etc…Chacune de ces
briques est déployée à part et ensuite les entreprises procèdent à un travail
d’intégration de tous ces modules. Départ son constat la société KOOSSERY réalise
que la mise sur place du travail collaboratif pose les problèmes suivants aux
entreprises:

- L’intégration car il faut bien que des logiciels aux technologies disparates
communiques ;
- Le coût élevé de la formation utilisateur et d’administration ;
- Le coût élevé de la maintenance ;

7
I.3 Problématique
Vue les problèmes rencontrés en entreprise par la mise sur place du travail
collaboratif l’on se pose les questions suivantes :

- comment rendre évident la communication entre des modules aux technologies

disparates ?

- comment réduire les coûts de formation utilisateur et d’administration ?

- comment réduire les coûts de maintenance des briques hétérogène ?

La plateforme koosseryDesk est une réponse appropriée en ce sens qu’elle est une
plateforme qui se présente sous la forme d’une seule application disposant de l’ensemble
des modules nécessaire pour le traitement de l’information en entreprise.

koosseryDesk est en cours de développement et il nous a été demandé de développer

les composants de service pour le module archiving de koosseryDesk.

I.4 Méthodologie
Il existe dans le domaine du génie logiciel plusieurs méthodes de développement
(en cascade, V, Z, agile...etc.) des systèmes informatiques. La société KOOSSERY
utilise le processus ‘Scrum’ (il est un processus agile) car la plate-forme koosseryDesk
est complexe et se fait développer par des ingénieurs se trouvant au Cameroun et en
France.

‘Scrum’ est défini par ses créateurs comme un « cadre de travail permettant de
répondre à des problèmes complexes et changeants tout en livrant de manière productive
et créative des produits de la plus grande valeur possible » [Ken Schwaber and Jeff
Sutherland, Le Guide de Scrum, 1991-2013]. La méthode s'appuie sur le découpage d'un
projet en boites de temps, nommés « sprints ». Les sprints peuvent durer de quelques
heures à un mois (avec une préférence pour deux semaines). Chaque sprint commence
par une vérification de la planification opérationnelle. Le sprint se termine par une
démonstration de ce qui a été achevé et contribue à augmenter la valeur d'affaire du
produit. Avant de démarrer un nouveau sprint, l'équipe réalise une rétrospective : elle

8
analyse ce qui s'est passé durant ce sprint, afin de s'améliorer pour le prochain.
L'adaptation et la réactivité de l'équipe de développement sont facilitées par son auto-
organisation.

Afin de développer les composants de service du module archiving de

koosseryDesk nous sommes passés par les phases (en respectant le processus ‘Scrum’)
suivantes :

- Formation au sein du Training Center (Centre de formation) ;

- Analyse de la norme d’archivage SEDA 1.0 ;

- Réalisation du Projet UML ;

- Implémentation du module archiving ;

- Test unitaire et intégration ;

- Étude du moteur Drools.

 Training (formation) ;
Cette phase nous a permi de nous familiariser avec les outils et l’environnement
technique de KOOSSERY. Le training consiste à travailler sur des parcours qui
aboutissent à des travaux pratiques.
 Analyse de la norme SEDA Version 1.0;
Cette phase a été consacrée à l’étude de la norme SEDA 1.0 et à l’étude de l’open
source as@lae Version 1.3 qui est une implémentation de SEDA Version 0.2
 Réalisation du projet UML ;
Cette phase a consisté à analyser puis concevoir les composants de services du
module archiving
 Implémentation ;
Cette phase est simplement le développement en Java des services composés et
service simples du module archiving sur la base du projet UML élaboré à l’étape
précédente
 test unitaire ;

9
 Cette phase consiste en l’élaboration des tests unitaires de nos développements
avec la plate-forme de test jUnit.

 Étude du moteur Drools ;

Cette phase consiste à réaliser un mini projet intégrant le moteur Drools pour la
validation des règles métiers.

I.5 Objectifs

I.5.1 Objectifs généraux

Participer au développement de la plate-forme koosseryDesk.

I.5.2 Objectifs spécifiques

Notre travail consiste précisément à fournir une implémentation des composants
de services du module archiving. Les tâches sont les suivantes :

 Analyser et concevoir des composants de services du module archiving de

kosseryDesk

Nous allons analyser et concevoir les composants de service du module archiving

de koosseryDesk selon le principe d’une SOA (Architecture Orientée Service).

 Implémenter et tester les composants module archiving de koosseryDesk

Nous allons implémenter et exposer les composants de service, c’est-à-dire

implémenter les services simples (SISV), tester et recomposer ces service simples pour
avoir les service composés qui doivent aussi être testés puis exposés au front-end à l’aide
des interfaces.

 Étudier le moteur Drools

Nous allons étudier le moteur de validation des règles métiers ‘Drools’

pour une intégration future à la plate-forme koosseryDesk.

10
CHAPITRE II : GENERALITE SUR L’ARCHIVAGE ET
LES ARCHITECTURES SYSTÈMES

II.1 Généralité sur l’archivage

Nous présenterons de fond en comble dans cette partie, la notion d’archivage, qui
est encore définie de multiples façons. Nous verrons que depuis plusieurs années,
notamment avec l'arrivée de l'internet et des nouvelles technologies, l'archivage a pris
de l'importance et est maintenant perçu d'une toute autre façon par les entreprises. Cette
nouvelle aire est également caractérisée par l'expansion de l'archivage électronique, dont
nous parlerons ensuite plus en détail.

II.1.1 Définition des concepts

L'Archivage est un terme, à la fois récent dans la langue française, puisqu'il n'est
utilisé que depuis quelques décennies seulement, et complexe par le fait qu'il n’existe
pas de définition légale du terme « archivage », alors qu’il en existe une du mot «
archives », dans le Code du Patrimoine de 2008, et figurant dans la loi du 3 janvier
1979, qui définit ce terme comme «l’ensemble des documents, quels que soient leur
date, leur forme et leur support matériel, produits ou reçus par toute personne physique
ou morale et par tout service ou organisme public ou privé dans l’exercice de leur
activité. »

Plusieurs auteurs ont prêté à ce terme des définitions différentes. Dans les
dictionnaires de l'information, l'archivage est défini comme « l'ensemble des méthodes,
processus et outils mis en œuvre pour gérer et conserver les documents qui ont cessé
d'être d'utilité courante. » Cette définition, aujourd'hui, est obsolète car l'archivage
touche l'ensemble des documents, les trois âges. Marie-Anne Chabin, archiviste
française, présente l'archivage comme étant « la démarche d’organisation qui a pour
objectif d’identifier, de mettre en sécurité et de maintenir disponibles l’ensemble des
documents qui engagent une entreprise ou un organisme vis-à-vis de tiers ou de son
activité future et dont le défaut représenterait un risque ».

11
 L'unité de base de l'archivage tourne autour de ce qu'on appelle un document, qui
est considéré comme une entité physique constituée par un support individualisé sur
lequel sont fixées des informations. Ces deux définitions montrent que l’archivage
n'englobe pas tous les documents, toutes les données ou toutes les informations, mais
seulement les documents qui engagent leur détenteur. Ces documents, originaux ou
copies, constitués ou non en dossiers, sont fixés sur des supports, qui peuvent être
physiques ou électroniques.

II.1.2 Cycle de vie des archives

A la base, le cycle de vie est un concept assez général. Il s'applique à toutes les
professions liées au documentaire. Il correspond à l'âge des archives, qui n'est exprimé
ni en mois ni en années mais qui désigne la période de vie qu'elles sont en train de
traverser.

Il existe une théorie fondée sur le cycle de vie des archives. Il s'agit de la théorie
dite « des trois âges ». Ce concept est né dans la seconde moitié du XX° siècle aux États-
Unis (Théodore Schellenberg est le père fondateur de cette théorie). Cette théorie doit
son apparition en France à Yves Pérotin, en 1961, dans un article où il parle des «
archives courantes », des « archives intermédiaires » et des « archives archivées ». Il
souhaitait ainsi intéresser les archivistes à la production des archives avant leur
versement afin d'en contrôler l'évaluation.

Les archives naissent dans les bureaux en vue d'une action plus précise, puis
conservent un intérêt plus ou moins à long terme. Des bureaux aux Archives, les
documents connaissent trois étapes d'utilisation :

Les archives courantes sont ce que l'on appelle les dossiers vivants, qui servent
à la gestion quotidienne des affaires. Ils sont utilisés fréquemment, et sont généralement
conservés à proximité des utilisateurs, dans les bureaux.

Les archives intermédiaires sont les dossiers clos, qui ne sont plus d’usage
courant mais qui sont néanmoins conservés pour des impératifs de gestion et/ou des
impératifs juridiques. Ils sont conservés à proximité des bureaux, souvent dans un local
dédié dit de pré archivage.
12
 Les archives définitives sont les dossiers dont l’utilité administrative ou de
gestion est éteinte, mais qui présentent un intérêt historique et qui seront versés dans le
service d’archives compétent pour être conservés indéfiniment.

Figure 2 : Cycle de vie d’une archive [11]

Le schéma ci-dessus, représente le cycle de vie du document, selon les principes

du Records Management. L’identification du cycle de vie des documents a pour objectif
d’organiser la gestion des archives dans le temps (définition des délais de conservation)
et dans l’espace (gestion des espaces d’archivage, des éliminations et des versements).
Durant l'archivage courant et intermédiaire, les documents sont conservés selon une
durée bien précise : la durée d'utilité administrative (DUA). Cette durée établit un délai
durant lequel un document est conservé et accessible au service producteur. Arrivé au
terme de cette durée de conservation, on applique le sort ou traitement final (qui désigne
le devenir physique des documents archivés à échéance de leur durée de conservation),
proposé dans le tableau de gestion : tri, élimination, et conservation.

13
II.1.3 Archivage électronique
Avec l'introduction des nouvelles technologies dans les collectivités et dans les
administrations, beaucoup de documents autrefois tenus sous forme papier sont
aujourd'hui gérés sous forme électronique. A l’instar de l’archive papier, l’archivage
électronique est l’ensemble des procédures définies par une collectivité pour assurer la
conservation de son patrimoine documentaire conformément à un référentiel défini par
l’autorité chargée du stockage et de la mise à disposition future des documents
effectivement versés. Il représente, au sens général, « l'ensemble des actions, outils et
méthodes visant à identifier, recueillir, classer et conserver des informations
électroniques, qui sont mis en œuvre pour conserver à moyen et long terme ces
informations dans le but de les exploiter [16] ». En comparaison avec l'archivage papier,
l'archivage électronique gère les documents numériques, qui sont des « ensembles
composés d’un contenu, d’une structure logique, d’attributs de présentation permettant
leur représentation, dotés d’une signification intelligible par l’homme ou lisible par une
machine [17] ». Il peut être crée à l'état natif ou obtenu par un processus de
transformation d'un document physique, par exemple par numérisation. Les documents
bureautiques, les bases de données, les messages électroniques, les dossiers numérisés
sont considérés comme des documents numériques.

L’archivage électronique doit répondre aux exigences suivantes :

- l’intégrité des documents ;

L'intégrité d'un document prouve que celui-ci n’a subi aucun ajout, ni aucune
modification qui pourrait provoquer l'altération ou la destruction des données.

- la pérennité des données ;

La pérennité consiste à maintenir dans le temps l'intégrité des données.

- la sécurité des documents ;

Il s'agit d'assurer la sécurité physique des locaux et des données.

- l'authenticité des documents ;

14
 Le manuel de spécizfications Moreq2 explique qu'il s'agit de prouver qu'un
document est bien original.

Ces exigences permettent ainsi :

- de faciliter l’accès à l’information ;

- de répondre aux exigences légales de conservation et de communication ;

- de relever le défi de l’obsolescence technologique récurrente ;

II.1.4 Les enjeux du module d'archive en entreprise

L'archivage correspond à l'organisation raisonnée d'une conservation sécurisée
de l'information créée aujourd'hui afin de pouvoir la réutiliser demain ou après-demain.
De nécessité, l'archivage est devenu une obligation pour les entreprises. Avant de mettre
en place une politique d'archivage, l'entreprise doit au préalable analyser ses besoins.
L'archivage répond à deux besoins distincts [11].

 le premier, le plus important, est le besoin pour l'entreprise de prouver ce qu'elle

a fait ou ce qu'elle n'a pas fait. Elle doit justifier de son activité vis-à-vis des
autorités de tutelle, vis-à-vis de l'État, vis-à-vis d'un audit interne. Elle doit en
outre, lors d'un contentieux, produire les pièces nécessaires à la défense de ses
droits et de ses intérêts;

 le deuxième besoin est pour l'entreprise l'intérêt de préserver sa mémoire, tant

pour constituer une culture d'entreprise, que pour communiquer envers ses
clients, ses partenaires, ses salariés, voire la société.

Les enjeux de l'archivage ou de l'absence d'un archivage raisonné et efficace

correspondent à la nécessité de maîtriser les risques suivants :

 juridique.

Le principal risque est de ne pas pouvoir produire les données requises par un audit
ou un juge dans la forme requise. Non seulement les données doivent avoir été archivées,

15
mais elles doivent présenter des caractéristiques d'authenticité, d'intégrité et de non-
répudiation leur permettant d'être retenues comme élément de preuve valide ;

 logistique.

Les données ont été bien archivées techniquement, mais il est pratiquement
impossible d'y accéder car elles n'ont pas été caractérisées pour pouvoir effectuer des
recherches et les moteurs de recherche ne produisent que du « brut » inexploitable ; ou
encore, les données existent, mais ne sont pas intelligibles (on a perdu le moyen de les
décoder et de les interpréter) ;

 sécuritaire.

Des données confidentielles (données stratégiques, personnelles) risquent d'être

divulguées parce qu'elles ne sont pas ou insuffisamment protégées, ou encore parce
qu'elles auraient dû être détruites ;

 technique.

L'enjeu technique est double, à la fois dans l'espace, avec les problèmes
d'interopérabilité entre systèmes, et dans le temps, avec le défi de pérennité des données
sur le long terme, face à l'obsolescence récurrente des formats, supports et outils de
restitution ;

 financier.

L'enjeu financier est double également : coût d'une amende, d'un redressement
fiscal ou d'une condamnation judiciaire et, dans une moindre mesure mais à ne pas
négliger tout de même, temps perdu à la recherche d'informations ou investissement
perdu dans des outils non maintenus dans le temps.

Les enjeux de l'archivage peuvent se résumer aux conséquences, pour l'entreprise, de ne

pas pouvoir retrouver les informations qu'elle a produites à un moment de son activité,
alors qu'elle a besoin de les communiquer ou de les réutiliser.

16
II.2 Programmation orientée Objet (POO)
L’objectif de cette section est d’explorer la programmation orientées objets
(POO) et leurs concepts fondamentaux. Ensuite, montrer leurs limites pour une bonne
conception.

II.2.1 Introduction
Le but de la programmation Objet est de se rapprocher le plus possible d'une
représentation de la réalité en programmation, en considérant que tout objet peut être
classé dans une catégorie qui a ses caractéristiques et ses possibilités propres. En effet,
tout objet qui nous entoure peut être "classé" dans une catégorie qui fait elle-même partie
d'autres catégories. Considérons par exemple : votre mobile fait partie de la catégorie
"Téléphone portable", qui elle-même fait partie de la catégorie "Téléphone", faisant
partie de la catégorie "Outil de communication téléphonique", etc…

II.2.2 Concept de base de la POO [10]

II.2.2.1 Objet
Un objet est une entité cohérente rassemblant des données et du code travaillant
sur ses données. Une classe peut être considérée comme un moule à partir duquel on
peut créer des objets. Une classe décrit la structure interne d'un objet : les données qu'il
regroupe, les actions qu'il est capable d'assurer sur ses données. En fait, on considère
plus souvent que les classes sont les descriptions des objets, lesquels sont des instances
de leur classe.

II.2.2.2 Encapsulation
L'encapsulation correspond à appliquer le principe de la "boîte noire" aux objets
que l'on crée. Il se traduire par l’abstraction de données et l'abstraction procédurale.

- Abstraction de données : la structure d'un objet n'est pas visible de l'extérieur,

son interface est constituée de messages invocables par un utilisateur. La réception d'un
message déclenche l'exécution de méthodes.

17
 - Abstraction procédurale : Du point de vue de l'extérieur (c’est-à-dire en fait du
client de l’objet), l'invocation d'un message est une opération atomique.

L'utilisateur n'a aucun élément d'information sur la mécanique interne mise en

œuvre. Par exemple, il ne sait pas si le traitement requis a demandé l’intervention de
plusieurs méthodes ou même la création d’objets temporaires etc.

Il est très important de cacher les détails d'implémentation des objets à

l'utilisateur. En effet, cela permet de modifier, par exemple la structure de données
interne d'une classe (remplacer un tableau par une liste chaînée) sans pour autant
entraîner de modifications dans le code de l’utilisateur, l’interface n’étant pas atteinte.

II.2.2.3 Héritage
L'héritage est le second des trois principes fondamentaux du paradigme orienté
objet. Il est chargé de traduire le principe naturel de Généralisation / Spécialisation.

En effet, la plupart des systèmes réels se prêtent à merveille à une classification

hiérarchique des éléments qui les composent. La première idée à ce sujet est liée à
l'entomologie et aux techniques de classification des insectes en fonction de divers
critères. Expliquons nous d'abord sur le terme d'héritage. Il est basé sur l'idée qu'un objet
spécialisé bénéficie ou hérite des caractéristiques de l'objet le plus général auquel il
rajoute ses éléments propres.

En termes de concepts objets cela se traduit de la manière suivante :

On associe une classe au concept le plus général, nous l'appellerons classe de

base ou classe mère ou super - classe.

Pour chaque concept spécialisé, on dérive une classe du concept de base. La

nouvelle classe est dite classe dérivée ou classe fille ou sous-classe

L'héritage dénotant une relation de généralisation / spécialisation, on peut

traduire toute relation d'héritage par la phrase:« La classe dérivée est une version
spécialisée de sa classe de base » On parle également de relation est-un pour traduire
le principe de généralisation / spécialisation.

18
II.2.2.4 Le polymorphisme
Le polymorphisme est le troisième des trois grands principes sur lequel repose le
paradigme objet. C'est assurément son aspect à la fois le plus puissant et le plus
troublant. Comme son nom l'indique le polymorphisme permet à une méthode d'adopter
plusieurs formes sur des classes différentes. Selon les langages, le polymorphisme
pourra s'exprimer sur l'ensemble des classes d'un système alors que d'autres le confinent
aux classes appartenant à une même hiérarchie. On distingue plusieurs formes de
polymorphisme, à savoir :

- Le Polymorphisme de surcharge : La surcharge permet d’associer au

même nom de méthode / fonction / procédure différentes signatures.

- Le Polymorphisme d’héritage: La redéfinition consiste à faire hériter

plusieurs classes d'une même classe 'mère', et de redéfinir une méthode
pour chaque classe.

II.2.3 Limites de la Programmation Orienté Objet (POO)

Lorsqu’on parle de la POO, on voit de manière instantanée les principes
d’encapsulation, d’héritage et de polymorphisme. Avec ces principes seuls [6],

- L’ajout des nouveaux comportements passe obligatoirement par la

déclaration de sous-classes et la surcharge des méthodes existantes. Ce qui
peut créer une explosion du nombre de classe et qui résulte à une
maintenance très complexe.

- Couplage fort entre les classes : les classes sont liées entre elles
indirectement. Ceci se manifeste par le fait que pour un système existant,
l’ajout des nouvelles fonctionnalités passe par la modification de la
solution existante.

- Cohésion faible : Ceci se matérialise par le fait que les méthodes sont
distribuées entre les différentes classes de notre système.

Toutes ces limites ne nous permettent pas de concevoir un système évolutif, facile
à maintenir et prenant en compte le fait que les besoins évoluent toujours, sont très
19
souvent mal définis et surtout sont incomplets. Les principes de la POO masquent le
fait que la clé d’une bonne conception ne se trouve pas dans l’héritage, mais plutôt dans
l’encapsulation des variations dans un système.

II.3 Les Design Patterns

Certains précurseurs ont poussé la réflexion sur l’objet en particulier sur la
Conception Orienté Objet(COO). De cette réflexion sont nées les bonnes pratiques de
conception via la capitalisation de l’expérience des développeurs. Ces bonnes pratiques
sont mieux connues sous le nom des Design Patterns. Dans cette partie nous ferons le
rappel sur les Design Patterns et l’évolution qu’ils apportent vis-à-vis des limitations de
la COO.

II.3.1 Définition
Ce concept a été formalisé dans le livre [7] On y décrit un Design Pattern conne
étant un concept qui permet de définir une interaction entre les Objets et fournit une
manière élégante de réutiliser des solutions aux problèmes fréquents rencontrés dans le
challenge de la programmation. On peut aussi considérer un Design Pattern comme une
solution classique et éprouvée aux problèmes de conception récurrents dans le monde
du développement.

II.3.2 Cartographie
Les Design Patterns, publié dans le livre [7], sont au nombre de 23 et repartis en
trois catégories.

- Les Patterns de Création pour délégué à d’autres classes la construction

des objets.

- Les Patterns de structure pour tenter de concevoir des agglomérations de

classes avec des macro-composants, c’est-à-dire de composer des classes
pour bâtir de nouvelles structures. Ces structures servent avant tout à ne
pas gérer différemment des groupes d’objets et des objets uniques.

20
 - Les Patterns de comportement qui tente de répartir les responsabilités
entre chaque classe (l’usage est plutôt dynamique).

A ces modèles de conceptions, on peut ajouter d’autre tels que : Le « Data Access
Object » lié à l’accès aux données et le « Service Locator » lié aux systèmes
distribués [15].

II.3.3 Conséquences des Design Patterns

Les Design Patterns ont introduit d’autres principes de conception. Cette
approche se base sur la manière dont les systèmes changent, ce qui permet d’anticiper
ces changements et de chercher où ils vont survenir. Cette approche se base sur les
principes décris dans le livre [7] :

- Concevoir et programmer via des interfaces et non des implémentations

concrètes.

- Favoriser la composition par rapport à l’héritage.

- Considérer ce qui varie et l’encapsuler.

Ainsi les Design Patterns introduisent des concepts qui concourent à

l’augmentation de la qualité d’un logiciel en proposant l’implémentation du
principe de l’ouvert fermé (ouvert pour le développeur et fermé pour le client).

Disposants des abstractions de la conception, il faut les associer à des

moyens techniques disponibles pour la réalisation : c’est le rôle des architectures.
En particulier, disposée d’une architecture qui prend en compte les différents
aspects fonctionnels d’une application. C’est le cas de l’architecture n-tiers qui
fera l’objet du paragraphe suivant.

21
II.4 Les Architectures n-tiers ou en couches
Il s’agit d’une architecture logicielle inhérente aux différents aspects fonctionnels
d’une application d’entreprise, à savoir : l’aspect Présentation, l’aspect Traitements et
l’aspect Données. Ce type d’architecture permet la distribution d’application entre
multiples services et non la multiplication des niveaux de service (présentation, logique
métier et accès aux données). D’où le terme n-tiers [16]

Cette distribution introduit une problématique de la communication entre les

différents composants de l’application. Pour ce faire, elle met en œuvre une approche
objet pour offrir une plus grande souplesse d’implémentation et faciliter la réutilisation
des développements.

II.4.1 Communication entre Objet

Pour permettre la répartition d’objets entre machines et l’intégration des systèmes
non objets, il doit être possibles d’instaurer une communication entre tous ces éléments.
Ainsi est né le concept de middleware objet qui a donné naissance à plusieurs
spécifications, dont l’architecture CORBRA préconisée par L’OMG, DCOM
développée par Microsoft et JAVA RMI développée par SUN Microsystems [10].

Ces middlewares sont constitués d’une série de mécanismes permettant à un

ensemble de programmes d’inter opérer de façon transparente. Les services offerts par
les applications serveurs sont présentés aux clients sous la forme d’objets. La
localisation et les mécanismes mis en œuvre pour cette interaction sont cachés par le
middleware. Ce qui gomme la différence entre les appels locaux et les appels distants,
du point de vue du code.

Avec les architectures n-tiers, on dispose enfin d’une vision cohérente du système
d’information. Tous les composants sont représentés sous la forme d’objets
interchangeables qu’il est possible d’implanter librement, en fonction des besoins. Le
potentiel de ce type d’application est très important et permettrait enfin l’utilisation
d’objets métiers réutilisables.

22
II.4.2 Problème
Nous avons vu que les logiciels basés sur les composants offrent une bonne
solution à la réutilisation et la maintenabilité fonctionnelle. Toutefois les développeurs
font face de jours à des complexités grandissantes (avec la POO, les Design Patterns et
les architecture distribuées) et la naissance de nouveaux besoins tels les intégrations
d’applications, les indépendances de plateformes, les indépendances de protocoles.
C’est à ces problèmes que les architectures orientées services(SOA) tentent d’apporter
une solution.

II.5 Les Architectures Orientées Services (SOA)

SOA est un style d’architecture logicielle pour lequel les processus métier de
l’entreprise sont des composants logiciels paramétrables, orchestrant des tâches avec les
acteurs de l’entreprise et des appels à des composants de services pour s’exécuter
[VALTECH. Urbanisation & Intégration de Systèmes « THINK SERVICE ». 2007].

Cette partie traite de l’architecture orientée service; c’est-à-dire les motivations,

les principes, les éléments de base et le fonctionnement de l’architecture.

II.5.1 Introduction
L’architecture orientée service (SOA) s’est imposée aujourd’hui comme un
thème majeur pour les systèmes d’informations (SI) d’entreprise. Plus qu’une nouvelle
technologie ou méthode, c’est la convergence de plusieurs approches existantes, et
l’émergence d’un style d’architecture et de gouvernance de SI.

Figure 3 : SOA à la Convergence

23 des solutions [17]
II.5.2 Les principes et motivation

II.5.2.1 Motivation de la SOA

La motivation fondamentale vient du constat suivant: le cloisonnement en silos
applicatifs indépendants (blocs monolithiques) est une des sources majeures des
difficultés rencontrées pour le traitement des évolutions et la maintenance des systèmes.

Figure 4 Architecture orientée application vs architecture orientée service [17]

Une autre motivation est la recherche de l’agilité. Cette notion n’est pas nouvelle:
Les Systèmes d’Information sont en constante évolution. Les organisations sont
confrontées à des demandes de changement toujours plus étendues et plus fréquentes.
Ces changements sont liés à la fois aux réorganisations (fusion, acquisitions), à
l’ouverture des processus et à la multiplication des évolutions des marchés. Les
applications construites et structurées pour répondre à des besoins particuliers dans un
contexte donné ne sont plus adaptées aux réalités présentes. Les changements
technologiques ajoutent encore des contraintes supplémentaires. Aux delà d’un certain
stade, les coûts induits par les modifications deviennent prohibitifs, et les délais
incompatibles avec les demandes métiers. Le système devient trop rigide, prisonnier de
son architecture antérieure. Les évolutions réalisées dans ce cadre détériorent la qualité
du système et renforce encore ces difficultés.

24
II.5.2.2 Principes de la SOA
 Diviser pour régner: Substituer la découpe strictement applicative par une
structuration en composants plus réduits et potentiellement plus simples à faire
évoluer.

 Alignement métier: Construire et organiser le système à partir des réalités

métiers, qui doivent se retrouver dans ses constituants.

 Neutralité technologique: Assurer une indépendance totale entre les interfaces et

les implémentations. L’élément qui utilise un service ne doit pas être contraint ni
par la technologie d’implémentation, ni par sa localisation (potentiellement
distribué).

 Mutualisation: Favoriser la réutilisation de services métiers par plusieurs lignes

métiers ou applications. Permettre la construction de services de haut niveau par
combinaison de services existants.

 Automatisation des processus métier. Isoler la logique des processus métiers sur
des composants dédiés qui prennent en charge les enchaînements de tâches et les
échanges de flux d’information.

 Échanges orientés Document. Les informations échangées par les services

possèdent une structure propre, guidée par les besoins métiers. On privilégie la
transmission de contenus complets et utilisables (exemples XML) au profit
d’accès direct aux structures de type objet ou relationnel.

II.5.3 Les Éléments de base de l'architecture SOA

Les éléments de base de l’architecture SOA sont :

- Composant de service

- Contrat de service

- Les données d’échange et données de persistances

25
II.5.3.1 Le composant de service
Le composant de service est la brique de base de l’architecture [Figure 5]. Il se
décompose en deux parties : la vue externe (ou spécification de service) qui expose la
facette service proprement dite, et la vue interne qui décrit le contenu du composant

La vue externe est constituée par un ensemble d’opérations de service regroupées

en interfaces (au sens UML) et de l’appareillage pour les utiliser (types des données
échangées, contrat de service, propriétés, etc.…).

La vue interne contient des informations relatives à la logique interne comme le

détail des traitements ou les bases de données manipulées. On y trouve également les
références vers les services utilisés par le composant. Cette vue est masquée aux
consommateurs du composant de service. Elle est employée notamment par les
architectes SI, qui travaillent sur la vision globale du système.

Figure 5 – Structure du composant de service [17]

Schématiquement, l’articulation des composants de service avec leurs liens de

dépendance constitue la structure du système [Figure 4]. Chaque composant de service
peut invoquer les opérations de service d’autres composants dans la mesure où les règles
de visibilité sont respectées.

26
 Figure 6 - Représentation schématique du système [17]

II.5.3.2 Les contrats de services

Le concept contrat de service fait ressortir ce qui relie d’un côté des
consommateurs de service et de l’autre côté des fournisseurs ou pourvoyeurs
capables de proposer des services. Il est donc nécessaire de formaliser ce lien entre
consommateur et fournisseur afin que la réutilisation soit facilitée et, s’il y a lieu, son
interopérabilité garantie. Le contrat de service joue un rôle majeur : il détaille les
conditions d’utilisation du service sous forme de pré et post conditions, protocoles, et
contraintes (QoS : qualité de service). Les contraintes non fonctionnelles permettent de
fixer les termes du contrat opérationnel entre consommateur et fournisseur de service.

II.5.3.3 Données d'échange et données persistantes

La distinction entre les données d’échange et les données persistantes est
inhérente aux architectures SOA, qui isolent les bases de données à l’aide de services
d’accès [Figure 7]. Les données d’échanges ont les informations véhiculées entre les
participants (consommateurs ou fournisseurs de service) à travers l’invocation des
opérations de service. Les données persistantes sont les informations contenues et gérées
dans les bases de données. Ces informations sont structurées de façon habituelle (par
exemple SGBD en mode relationnel), dans le cadre de référentiels ou de bases
applicatives.

27
 Les types de donnée d’échange (TDE) établissent la sémantique, la structure et
le format de ces données. Ils peuvent être définis à l’aide de schémas XML et
éventuellement de classes UML (DTO acronyme de Data Transfert Object). Chaque
opération de service précise les types de donnée d’échange en entrée et en sortie.

Figure 7- Données d'échange et données persistantes [17]

II.5.4 Fonctionnement des SOA

Figure 8 : Fonctionnement SOA [17]

28
 Le service est le composant clé de l’architecture et il fournit une fonctionnalité
bien définie. C’est aussi un composant autonome qui ne dépend d’aucun contexte ou
service externe. Les services sont enregistrés par des composants dits fournisseurs dans
un annuaire fourni par l’architecture. Les services référencés sont alors mis à la
disposition de consommateurs ou clients. La figure ci-dessous montre qu’un composant
souhaitant mettre à disposition un service (étiquette 1) l’enregistre dans l’annuaire
(étiquette 2). Puis les composants clients souhaitant utiliser ce service (étiquette 3)
émettent une requête pour rechercher le service désiré dans l’annuaire (étiquette 4). Si
la réponse est positive, une liaison (appelée aussi binding) est mise en place pour
l’utilisation du service (étiquette 5)

29
CHAPITRE III ANALYSE ET CONCEPTION DES
COMPOSANTS DU MODULE ARCHIVING

III.1 Présentation de la norme SEDA [13]

Le standard d’échange de données pour archivage vise à faciliter
l’interopérabilité entre le système d’information d’un service d’archives et les systèmes
d’informations de ses partenaires (producteurs, utilisateurs…). Il fournit un modèle pour
les différentes transactions qui peuvent intervenir : transfert, communication,
élimination…

Figure 9 : Schéma SEA selon SEDA [13]

Le standard SEDA modélise les transactions entre acteurs dans le cadre de

l'archivage de données.

30
III.1.1 Acteurs SEDA

Service Producteur Service de contrôle

Demande autorisation
Produire Restituer archives
document
Éliminer archive
Service d’archives

Modifier archive
Transfert
d’archive
Communiquer
archive

Service Versant Service Demandeur

Figure 10 Séquence système entre acteurs SEDA

La norme SEDA récence pour le SAE les acteurs suivants :

- Service Producteur ;

- Service Versant ;

- Service d’archives ;

- Service de contrôle ;

- Service demandeur.

III.1.1.1 Service producteur (Originating Agency)

Le Service producteur désigne l’entité qui a produit les archives, c’est-à-dire qui
les a créées ou reçues dans le cadre de son activité.

31
III.1.1.2 Service versant (Transferring Agency)

Le Service versant désigne l’entité qui transfère un ensemble de données à un

service d’archives.

III.1.1.3 Service d’archives (Archival Agency)

Le Service d’archives est l’entité destinataire du transfert et assurant la gestion

des Archives transférées par les Services versants.

III.1.1.4 Service de contrôle (Control Authority)

Certains messages ne sont émis qu’après validation par un service de contrôle.

Le service de contrôle exerce le contrôle scientifique et technique sur les archives.

III.1.1.5 Demandeur d'archives (Requester)

Le terme Demandeur d'archives désigne toute personne physique ou morale qui

souhaite consulter les archives conservées par le service d’archive dans le respect de la
législation applicable en matière de communication des Archives.

III.1.2 Les transactions (échanges de données) SEDA

- Transfert d'archives (Archive Transfer)

Transmission d'archives par un Service versant à un Service d’archives en vue de

lui en confier la conservation. Le transfert peut être précédé d'une demande de transfert
(Archive Transfer Request).

- La Communication d'archives (Archive Delivery)

Transmission d'archives par un service d'archives à un demandeur d'archives,

avec l'autorisation, le cas échéant, du service producteur et du service de contrôle
compétent.

- Élimination d’archives

32
 Destruction de l’archive par le service d’archive dans le SAE. Cette destruction
consiste à la suppression des documents d’archive et conservation des métadonnées
d’archives afin de garder leur traçabilité dans le système.

- Modification d’archives

Modification par le service d’archive des données archivées (la conversion de

formats en cas d'obsolescence du format des données dans lequel les données ont été
transférées), ou sur les métadonnées.

- Restitution d'archives (Archive Restitution)

Transmission d'archives par un Service d'archives à un Service producteur en vue

de lui en restituer la garde.

III.1.3 Les données (objets échangés)

Archive : elle est composée de métadonnées (informations de représentation et de

pérennisation) ainsi que d'objets d'archives et de documents.

- Objet d'archives : Il s'agit d'une subdivision intellectuelle de l'Archive qui

possède des caractéristiques propre de conservation. Les objets peuvent
eux-mêmes être subdivisés en sous-objets.

- Document : Sert à transporter des contenus de données (fichiers) associés

à leurs métadonnées.

Figure 11: Structure d’une archive

33
III.1.3 Exemple d’implémentation de la spécification SEDA (as@lae 1.3)
Asal@e 1.3 est un open source écrit en Php 5 implémentant la norme SEDA 0.2.
Le déploiement et l’analyse de son code nous a permis de proposer des algorithmes
efficaces pour l’implémentation du module archiving de koosseryDesk.

III.2. Cahier des Charges

Le cahier des charges est un outil important du domaine du génie logiciel, il
permet à tous les acteurs du projet (concepteur, développeur et client) d’avoir une vue
d’ensemble sur ce qui doit être fait. Le client peut grâce à ce dernier savoir si le produit
final répondra à ses exigences, de même le développeur est assuré qu’il ne produira pas
des fonctionnalités inutilisables par le client. Ce cahier des charges a été élaboré en
collaboration avec l’équipe du front-end (équipe en charge du développement
l’application cliente de koosseryDesk). Le tableau ci-dessous regroupe les éléments du
cahier des charges des composants de services du module archiving de koosseryDesk
que nous allons développer.

Composants de services Fonctionnalités rendus par le back-end

Gestion des Transfert d’archives F1 : Transférer archives vers le service d’archive

F2 : Modifier un transfert d’archives

F3 : Supprimer un transfert d’archives

F4 : Verrouiller un transfert d’archive

F5: Déverrouiller un transfert d’archives

F6 : Analyser un transfert d’archives

F7 : Traiter un transfert d’archives

F8 : Rechercher un transfert d’archive

Gestion des archives F9 : Supprimer archives du système

34
 F10 : Éliminer archive à la demande du producteur

F11 : Modifier archive

F12 : Créer demande d’élimination d’archives

F13 : Modifier demande d’élimination d’archives

F14 : Supprimer demande d’élimination d’archives

F15 : Rechercher demande d’élimination d’archives

F16 : Verrouiller demande d’élimination d’archives

F17 : Rechercher archives

Gestion des Communications d’archives F18 : Créer une demande de communication

F19 : Modifier une demande de communication

F20 : Supprimer une demande de communication

F21 : Rechercher demande de communication

F22 : Verrouiller une demande de communication

F23 : Communiquer archive à un demandeur

Gestion des restitutions d’archives F24 : Restituer des archive au producteur

F25 : Créer une demande de restitution

F26 : Verrouiller une demande de restitution

F27 : Modifier une demande de restitution

F28 : Supprimer une demande de restitution

F29 : Rechercher demande de restitution

Gestion des profils d'archive F30 : Créer un profil d’archive

F31 : Supprimer un profil d’archive

35
 F32 : Modifier profil d’archives

F33 : Rechercher un profil d'archive

Gestion des accords de versement F34 : Créer un accord de versement

d’archives
F35 : Modifier un accord de versement

F36 : Supprimer un accord de versement

F37 : Rechercher un accord de versement

Gestion des référentiels SEDA F38 : Rechercher tous les Code de Restriction d’accès

F39 : Rechercher tous les codes du sort final

F40 : Rechercher tous les niveaux de description

F41 : Rechercher tous les types de documents

F42 : Rechercher tous les types de fichier

F43 : Rechercher tous les types de mot clés

F44 : Rechercher tous les codes de langues

F45: Rechercher tous les codes Mime

F46 : Rechercher tous les codes de réponse

Gestion des Acteurs SEDA F47 : Créer un acteur SEDA

F48 : modifier un acteur SEDA

F49 : supprimer un acteur SEDA

F50 : Rechercher acteur SEDA

36
Gestion des utilisateurs F51 : Créer un utilisateur

F52 : Modifier un utilisateur

F53 : Supprimer Utilisateur

F54 : Rechercher Utilisateur

Gestion des rôles F55 : Créer un Rôle

F56 : Modifier un Rôle

F57 : Supprimer un Rôle

F58 : Rechercher Rôle

Gestion des workflows F59 : Créer un workflow

F60 : Modifier un workflow

F61 : Supprimer un workflow

F62 : Rechercher un workflow

Gestion du service de control F63 : Traiter une demande d’autorisation

Tableau 1 : Cahier des charges des composants de service du module ‘archiving’

37
III.3 Analyse et conception des composants du module Archiving
Le projet UML est une organisation structuré (propre à KOOSSERY ayant fait
l’objet d’une publication scientifique) permettant de consigner la conception technique
d’un Projet afin de favoriser son implémentation par les développeurs. Le projet UML
sert d'outil de communication entre les différents intervenants techniques du projet. Il
repose sur la méthodologie décrite dans le document suivant : « framework-pour-
modelisation-projet-langage-uml » [14]. Cette Structure fondamentale s’exprime à
travers plusieurs parties parmi lesquelles nous utilisons le Use Case View et le Logical
View.

III.3.1 Use Case View

Figure 12 : Use Case View

Le Use Case View est constitué de plusieurs parties (Business Model, User
Interface et le Use Case Model) et celle qui nous intéresse ici est le Use Case Model.

38
III.3.2.1 L’acteur du système et le contexte

Acteur : du point de vue du back-end le seul acteur est le front-end

Contexte : le système lui-même (back-end) et la source de données (SGBD)

III.3.2.2 Use cases

Un cas d'utilisation représente généralement un objectif complet que remplit le

système de manière à répondre au besoin d'un acteur appelé initiateur pour ce cas
d'utilisation. Tous les cas d’utilisations ici ont un seul acteur le front-end. Certains cas
d’utilisation que nous allons citer par la suite sont génériques c’est-dire une abstraction
de plusieurs cas d’utilisations élémentaires qui seront illustrés par les diagrammes de
cas d’utilisation.

Cas d’utilisation 1 : Gérer transfert d’archives

Ce cas d’utilisation est une abstraction du cas d’utilisation gérer transfert

d’informations vers le système d’archive. Pour la gestion d’un transfert le front-end
pourra transférer les informations vers le système d’archives, modifier un transfert
d’archives, supprimer un transfert d’archives, verrouiller un transfert d’archive,
déverrouiller un transfert d’archives, rechercher un transfert d’archive.

39
uc Main

«Abstract use case» Analyser un transfert

Gérer transfert d'une archiv e

kooosseryDesk.archiv ing.FrontEnd (from UC-TRANFERT-007- Analyser un transfert)

(from Actors) (from UC-TRANSFERT-000- gérer transfert information vers système d'archive)

Transfer archiv es
Find transfert d'archiv es

(from UC-TRANSFERT-001-Transférer information vers système d'archive)

(from UC-TRANSFERT-006-Find transfert d'archives)

Modifier un transfert
Verrouiller un
d'archiv es
transfert d'archiv es

(from UC-TRANSFERT-002-Modifier un transfert d'archives)

(from UC-TRANSFERT-004-Verrouiller un transfert d'archives)

traiter un transfert
Supprimer un Dev errouiller un transfert
transfert d'archiv es d'archiv es
(from UC-TRANSFERT-008-Traiter un transfert)

(from UC-TRANSFERT-003-Supprimer un transfert d'archives)

(from UC-TRANSFERT-005-Déverrouiler transfert d'archives)

Figure 13 : Cas d’utilisation – Gérer transfert d’une archive

«actor,External Sys...

Séquence système du cas d’utilisation : Transfer archives

sd SC10-Nominal-SC10-Nominal-Archiv er une archiv e

«system»
Context::koosseryDesk.archiving.Server
kooosseryDesk.archiving.FrontEnd

Transfer d'archives

réponse au transfer d'archives

(from Actors)

Figure 14 : Séquence système du use case – Transfer archives

40
Cas d’utilisation 2 : Gestion des archives

Ce cas d’utilisation est l’abstraction des cas d’utilisation supprimer archives du

système, éliminer archive à la demande du producteur, modifier archive, rechercher
archive, Créer demande d’élimination d’archives, Modifier demande d’élimination
d’archives, Supprimer demande d’élimination d’archives, Rechercher demande
d’élimination d’archives, Verrouiller demande d’élimination d’archives.

Cas d’utilisation 3 : Gestion des Communications d’archives

Le cas d’utilisation Gestion des Communication est une abstraction des cas
d’utilisations créer une demande de communication, modifier une demande de
communication, supprimer une demande de communication, rechercher demande de
communication, verrouiller une demande de communication, communiquer archive à
un demandeur.

Cas d’utilisation 4 : Gestion des restitutions d’archives

Le cas d’utilisation Gestion des restitutions est une abstraction des cas
d’utilisation restituer des archive au producteur, créer une demande de restitution,
verrouiller une demande de restitution, modifier une demande de restitution, supprimer
une demande de restitution, supprimer une demande de restitution.

Cas d’utilisation 5 : Gestion des profils d’archives

Le cas d’utilisation Gestion des profils d’archives est une abstraction des cas
d’utilisation créer un profil d’archive, modifier un profil d’archive, supprimer un profil
d’archive, rechercher profil d’archive.

Cas d’utilisation 6 : Gestion des accords de versements d’archives

Le cas d’utilisation Gestion des accords de versements d’archives est une

abstraction des cas d’utilisation créer un accord de versement, modifier un accord de
versement, supprimer un accord de versement, rechercher accord de versement.

41
Cas d’utilisation 7 : Gestion des Référentiels SEDA

Le cas d’utilisation Gestion des Référentiels SEDA est une abstraction des cas
d’utilisation rechercher tous les Code de Restriction d’accès, rechercher tous les codes
du sort final, rechercher tous les niveaux de description, rechercher tous les types de
documents, rechercher tous les types de fichier, rechercher tous les types de mot clés,
rechercher tous les codes de langues, rechercher tous les codes Mime, rechercher tous
les codes de réponse.

Cas d’utilisation 8 : Gestion des acteurs SEDA

Le cas d’utilisation Gestion des acteurs SEDA est une abstraction des cas
d’utilisation créer un acteur SEDA, modifier un acteur SEDA, rechercher acteur SEDA.

Cas d’utilisation 9 : Gestion des utilisateurs

Le cas d’utilisation Gestion des utilisateurs est une abstraction des cas
d’utilisation créer un utilisateur, modifier utilisateur, supprimer un utilisateur,
rechercher tous les utilisateurs.

Cas d’utilisation 10 : Gestion des rôles

Le cas d’utilisation Gestion des rôles est une abstraction des cas d’utilisation
créer un rôle, modifier rôle, supprimer un rôle, rechercher tous les rôles.

Cas d’utilisation 11 : Gestion des Workflows

Le cas d’utilisation Gestion des rôles est une abstraction des cas d’utilisation
créer un workflow, modifier workflow, supprimer un workflow.

Cas d’utilisation 12 : Gestion du service de contrôle

Le cas d’utilisation Gestion des rôles est une abstraction de traiter une demande
d’autorisation.

42
III.3.2 Logical View

Figure 15: Logical view

Le « logical View » est compose de deux grandes parties Data Model qui
représente le schéma de la base de données et le Analysis Model qui est une réalisation
des use case. Le « Data model » étant réalisé par l’équipe qui s’occupe de la couche des
accès aux données, nous allons présenter juste le « analysis Model ». Le « Analysis
Model » est composé de 3 parties à savoir : « service», « Business Component » et le
« Use Case Realizations ».

III.3.2.1 Service (service composé)

Ce Package est dédié au regroupement des composants de service du système.

Les services rendus par un composant « service » sont exprimés à travers des interfaces.
Chaque composant de « service » est en charge d'orchestrer un ensemble de service
proposé par la couche de composants « métiers » afin de répondre à un besoin du front-
end. À la différence des composants métiers, les composants « service » modélisent la
partie la plus instable du système d’information, celle susceptible d’évoluer le plus dans
le temps.

43
class Cartographie des serv ices

«interface»
Transfert::ITransfertService «interface»
Restitution::IRestitutionService
+ delete(ArchiveTransferDTO) : void
+ find(ArchiveTransferDTO) : List<ArchiveTransferDTO> + restitute(archiveRestitutionRequestDTO) : ArchiveRestitutionDTO
+ lock(ArchiveTransferDTO) : void + create(ArchiveDeliveryRequestDTO) : long
+ transfer(ArchiveTransferDTO) : ArchiverTansferRequestReplyDTO + delete(ArchiveDeliveryRequestDTO) : void
+ unLock(ArchiveTransferDTO) : void + lock(ArchiveDeliveryRequestDTO) : void
+ update(ArchiveTransferDTO) : void + find(ArchiveDeliveryRequestDTO) : List< ArchiveDeliveryRequestDTO>
+ analyse(ArchiveTransferDTO) : void + update(ArchiveDeliveryRequestDTO) : void
+ process(TraitementStepDTO, long, long) : void
«interface»
Communication::IDeliveryService
«interface»
Archive::IArchiveService + deliver(archiveDeliveryRequestDTO) : ArchiveDeliveryRequestReplyDTO
+ create(rchiveDeliveryRequestDTO) : long
+ eliminate(ArchiveDTO) : void + update(ArchiveDeliveryRequestDTO) : void
+ find(ArchiveDTO) : List<ArchiveDTO> + delete(ArchiveDeliveryRequestDTO) : void
+ removeDefinitivelyFromTheSystem(ArchiveDTO) : void + find(ArchiveDeliveryRequestDTO) : List<ArchiveDeliveryRequestDTO>
+ update(ArchiveDTO) : ArchiveModificationNotificationDTO + lock(ArchiveDeliveryRequestDTO) : void
+ create(ArchiveEliminationRequestDTO) : long
+ update(ArchiveEliminationRequestDTO) : long
+ delete(ArchiveEliminationRequestDTO) : long
+ find(ArchiveEliminationRequestDTO) : list<ArchiveEliminationRequestDTO>
«interface»
+ lock (ArchiveEliminationRequestDTO) : void
ArchivalAgreement::IArchivalAgreementService
+ create(ArchivalAgreementDTO) : long
«interface»
+ delete(ArchivalAgreementDTO) : void
Referentiel::IReferentielService + update(ArchivalAgreementDTO) : void
«interface»
+ findAll() : List<AccessRestrictionCodeDTO> + find(ArchivalAgreementDTO) : List<ArchivalAgreementDTO>
User::IUserService
+ findAll() : List<AppraisalCodeDTO>
+ findAll() : List<DescriptionLevelCodeDTO> + create(UserDTO) : long
+ update(UserDTO) : void «interface»
+ findAll() : List<DocumentTypeCodeDTO>
+ delete(UserDTO) : void ArchiveProfil::IArchiveProfilService
+ findAll() : List<FileTypeCodeDTO>
+ findAll() : List<KeywordTypeCodeDTO> + findAll() : List<UserDTO> + create(ArchiveProfilDTO) : long
+ findAll() : List<LanguageCodeDTO> + delete(ArchiveProfilDTO) : void
+ findAll() : List<MimeCodeDTO> + find(ArchiveProfilDTO) : List< ArchiveProfilDTO>
+ findAll() : List<ReplyCodeDTO> «interface» + update(ArchiveProfilDTO) : void
Role::IRoleService
«interface» + create(RoleDTO) : long «interface»
Organization::IOrganizationService + update(RoleDTO) : void WorkFlow::IWorkFlowService
+ create(OrganizationDTO) : long + delete(RoleDTO) : void + create(WorkFlowDTO) : long
+ find(OrganizationDTO) : List<OrganizationDTO> + findAll() : List<RoleDTO> + update(WorkFlowDTO) : void
+ update(OrganizationDTO) : void + find(WorkFlowDTO) : List<WorkFlowDTO>
+ findOne(long) : OrganizationDTO 44 + delete(WorkFlowDTO) : void

Figure 16 : Cartographie des services rendus par le Back-end

La figure ci-dessus présente les interfaces de services rendus par le back-end.

III.3.2.2 Business Component

C'est dans ce package qu'on regroupe tous les composants métiers du système.

Figure 17 : Liste de Composant métier pour le module archiving

Chaque composant métier est constitué de 3 parties (DTO, DAO, SISV).

Ici nous présentons juste les composants métier : « composant » Archive et

« composant » Transfert, qui entre dans la mise en œuvre du cas d’utilisation
‘Transfer d’archives’

III.3.2.2.1 « composant » Archive

Figure 18 : Composant métier-« composant» Archive

III.3.2.2.1.1 DTO du « composant» Archive

Le package dto : encapsule des données d'une archive

45
class Structure

«domain»
«domain» «domain» «domain»
Archiv eDTO
AttachementDTO ContentDescriptionDTO DocumentDTO
- accessRestrictionRule: AccessRestrictionRuleDTO - accessRestrictionRule: AccessRestrictionRuleDTO
- date: date - archivalAgencyDocumentIdentifier: string
- appraisalRule: AppraisalRuleDTO - custodialHistory: CustodialHistoryDTO
- fileTypeCode: string - attachement: Attachement
- archivalAgencyArchiveIdentifier: string
- id: int - description: string - control: bool
- contentDescription: ContentDescriptionDTO
- mineCode: string - filePlanPosition: string - copy: bool
- languageCode: LanguageCodeDTO
- path: string - latestDate: Date - creationDate: Date
- listOfArchiveObject: List<ArchiveObject> - listOfKeyword: List<Keyword>
- taille: byte - description: string
- listOfDocument: List<Document> - listOfOtherMetatData: List<OtherMetaData>
- version: string - documentTypeCode: DocumentTypeCodeDTO
- name: string - listOfRelatedObjectReference: List<RelatedObjectReference> - integrity: byte
- originatingAgencyArchiveIdentifier: string - OldestDate: Date - issue: Date
- transferingAgencyArchiveIdentifier: string
- originatingAgencyId: int - languageCode: LanguageCodeDTO
«domain» «FK» - otherDescriptiveData: string - listOfOtherMetaData: List<OtherMetaData>
OtherMetaDataDTO - archivalAgreementId: int - size: float - listOfRelatedData: List<RelatedData>
- archivalProfileId: int - OriginatingAgencyDocumentIdentifier: string
- path: string «FK»
- archiveDeliveryRequestReplyId: int - purpose: string
- descriptionLevelCode: DescriptionLevelCodeDTO
«FK» - archiveRestitutionId: int - languageCode: LanguageCodeDTO - receiptDate: Date
- documentId: int - archiveRestitutionRequestId: int - reprositoryId: int - responseDate: Date
- contentDescriptionId: int - archiveTransferReplyId: int - size: int
- archiveTransferRequestId: int «PK»
«PK» - status: string
- archiveTransferRequestReplyId: int - id: int
- id: int - submissionDate: Date
- archiveTransfertId: int - transferingAgencyDocumentIdentifier: string
- authorizationControlAuthorityRequest: int
«domain» «FK»
- authorizationOriginatingAgencyRequestId: int Archiv eObj ectDTO
«domain» - archiveId: int
- authorizationOriginatingAgencyRequestReplyId: int
CustodialHistoryDTO - archiveObjectId: int
- serviceLevelCode: string - accessRestrictionRule: AccessRestrictionRuleDTO
- appraisalRule: AppraisalRuleDTO «PK»
- costodialHistoryItem: string «PK»
- archivalAgencyObjectIdentifier: string - id: int
«PK» - id: int
- contentDescription: ContentDescriptionDTO
- id: int - listOfArchiveObject: List<ArchiveObject>
- listOfDocument: List<Document> «domain»
«domain»
- name: string keyw ordDTO
«domain» RelatedDataDTO
RelatedObj ectReferenceDTO - originatingAgencyObjectIdentifier: string - accessRestrictionRule: AccessRestrictionRuleDTO
- data: byte - transferingAgencyObjectIdentifier: string - keywordContent: string
- RelatedObjectIdentifier: int - listOfRelatedData: List<RelatedData> «FK» - keywordReference: string
- relation: string - relation: string - archiveId: int - keywordTypeCode: KeywordTypeCodeDTO
«PK» «PK» - parentId: int «PK»
- id: int - id: int «PK» - id: int
«FK» «FK» - id: int «FK»
- contentDescriptionId: int - documentId: int - contentDescriptionId: int

Figure 19-Diagramme de classe des DTO du composant métier archive

46
 III.3.2.2.1.2 dao du « composant» Archive

Le package dao représente la couche d'accès à la base de données

class Structure

DocumentDAO Achiv alAgreementDAO AttachementDAO

+ findIdArchiveByAttachementPath(string) : long + findClassifyingPlan(long) : string + insert(AttachementDTO) : long
+ insert(DocumentDTO) : long + findArchivalAgencyId(long) : Long + delete(long) : void
+ delete(long) : void
+ update(DocumentDTO) : void

Archiv eDAO
RelatedObj ectReferenceDAO
+ find(ArchiveDeliveryRequestDTO) : List<ArchiveDTO>
+ findOne(long) : ArchiveDTO + insert(RelatedObjectReferenceDTO) : long
+ insert(archiveDTO) : long + delete(long) : void
+ delete(long) : void + update(RelatedObjectReferenceDTO) : void
+ update(ArchiveDTO) : void
+ find(ArchiveDTO) : List<ArchiveDTO>

IndexLuceneDAO Keyw ordDAO ContentDescriptionDAO

+ indexDocument(File) : void + insert(keywordDTO) : void + insert(ContentDescriptionDTO) : long

+ searchDocument(string) : List<Document> + delete(long) : void + delete(long) : void
+ delete(string) : void + update(KeywordDTO) : void + update(ContentDescriptionDTO) : void

ReletedDataDAO
+ insert(RelatedDataDTO) : long
+ delete(long) : void
+ update(RelatedDataDTO) : void
OtherMetaDataDAO CustodialHistoryDAO
+ insert(OtherMetaDataDTO) : void + insert(CustodialHistoryDTO) : long
+ delete(long) : void + delete(long) : void
+ update(OtherMetaDataDTO) : void + update(CustodialHistoryDTO) : void

Figure 20 : Diagramme de classe des dao du composant archive

47
III.3.2.2.1.3 Service simple (sisv) du « composant» Archive

Le package sisv (service interne): service simple implémentant la logique métier.

class Structure

Archiv eSISV

+ concreteEliminate(ArchiveDTO) : void
+ create(ArchiveTransferRequestDTO) : ArchiveTransferRequestReplyDTO
+ delete(ArchiveTransferDTO) : void
+ deliteTransfer(Long) : void
+ deliver(ArchiveDeliveryRequestDTO) : ArchiveDeliveryRequestReplyDTO
+ eliminate() : void
+ eliminate(ArchiveDTO) : void
- find(ArchiveDeliveryRequestDTO) : List<ArchiveDTO>
+ find(ArchiveDTO) : List<ArchiveDTO>
+ find(ArchiveTransferDTO) : List<ArchiveTransferDTO>
+ lock(ArchiveTransferDTO) : void
+ remove(long) : void
+ remove(ArchiveDTO) : void
+ restitute(ArchiveRestitutionRequestDTO) : ArchiveRestitutionDTO
+ transfer(ArchiveTransferDTO) : ArchiveTransferReplyDTO
+ unlock(ArchiveTransferDTO) : void
+ update(ArchiveDTO) : ArchiveModificationNotificationDTO
+ update(ArchiveTransferDTO) : void
- validate(ArchiveTransferRequestDTO) : bool
- validate(archiveTransferDTO) : bool
- validate(ArchiveDeliveryRequestDTO) : bool
- validate(ArchiveRestitutionRequestDTO) : bool

Figure 21 : Diagramme de classe du ArchiveSISV

48
III.3.2.2.2 « composant » Transfert

class Structure

«domain» «domain»
Archiv eTransferDTO Archiv eTransferRequestDTO
- comment: string - comment: string
- date: Date - date: Date
- listOfArchive: List<ArchiveDTO> - listOfArchive: List<ArchiveDTO>
- signature: SignatureDTO - signature: SignatureDTO
- transferringAgencyId: int - transfertDate: Date
«FK» «FK»
- archivalAgencyId: int - archivalAgencyId: int
- relatedTransferReferenceId: int - RelatedTransferReference: int
- transfertRequestReplyId: int
«PK»
«PK» - id: int
- id: int - transferringAgencyId: int

«domain»
«domain»
Archiv eTransferReplyDTO
Archiv erTansferRequestReplyDTO
- comment: string
- comment: string
- date: Date
- date: Date
- grandDate: Date
- listOfArchive: List<ArchiveDTO>
- listOfArchive: List<ArchiveDTO> - replyCode: string
- replyCode: string - transferDate: Date
- signature: SignatureDTO
«FK»
«FK»
- archivalAgencyId: int
- archivalAgencyId: int
- signature: SignatureDTO
- transferId: int - transferRequestId: int
- transferringAgencyId: int - transferringAgencyId: int
«PK»
«PK»
- id : int
- id: int

Figure 22 : Illustration des DTO du «composant » Transfer

class Structure

Archiv eTranferDAO
Archiv eTransferRequestDAO
+ delete(Long) : void
+ insert(ArchiveTransferRequestDTO) : long
+ find(ArchiveTransferDTO) : List<ArchiveTransferDTO>
+ findOne(Long) : ArchiveTransferDTO
+ insert(ArchiveTransferDTO) : long
+ update(ArchiveTransferDTO) : void

Archiv eTransferRequestReplyDAO Archiv eTransferReplyDAO

+ insert(ArchiveTransferRequestReplyDTO) : long + insert(ArchiveTransferReplyDTO) : long

Figure 23 : Illustration des DAO «composant » Transfer

49
III.3.2.3 Use Case Realizations

Figure 24 : Réalisation des cas d’utilisations

La réalisation d’un cas d’utilisation dans ce contexte désigne l’agencement des

différents composants afin de rendre le service. Il est illustré par un diagramme de
séquence. Voici en exemple le diagramme de séquence illustrant la réalisation du cas
d’utilisation ‘Transférer une archive’. Nous allons procéder par une décomposition,
puis une recomposition des fragments afin d’avoir le cas d’utilisation d’origine (car
celui-ci est très complexe).
sd other

seq create accessRestrictionRule

sisv::ArchiveSISV dao::AccessRestrictionRuleDAO

create(accessrestrictionRuleDTO) :long

id technique accessRestrictionRule

50
sd other

seq create appraisalRule

sisv::ArchiveSISV dao::AppraisalRuleDAO

create(appraisalRuleDTO) :long

id technique appraisalRule

sd other

seq create ContentDescription

sisv::ArchiveSISV dao::CustodialHistoryDAO dao::ContentDescriptionDAO dao::KeywordDAO dao::RelatedObjectReferenceDAO

seq

ref create AccessRestrictionRule

create(custodialHistoryDTO) :long

id technique custodialHistory

create(contentDescriptionDTO) :long

id technique contentDescription

loop create keyw ord

seq

Ref create AccessRestrictionRule

create(keywordDTO)

id technique keyword

loop create relatedObj ectReference

create(relatdObjectReferenceDTO) :long

id technique relatedObjectReference

loop create otherMetaData

seq

Ref create otherMetaData

51
sd document

seq create document

sisv::ArchiveSISV dao::AttachementDAO dao::DocumentDAO dao::ReletedDataDAO

create(attachementDTO) :long

id technique attachement

create(documentDTO) :long

id technique document

loop create relatedData

create(relatedDataDTO) :long

id technique relatedData

loop create otherMetaData

Ref SD create otherMetaData

sd archiv eObj ect

seq create archiv eObj ect

sisv::ArchiveSISV dao::ArchiveObjectDAO

seq

Ref SD: create accessRestrictionRule

seq

Ref SD: create appraisalRule

seq

Ref SD: create contentDescription

create(archiveObjectDTO) :long

id technique archiveObject

loop create document

seq
Ref SD: create document

52
sd archiv e

seq Create archiv e

sisv::ArchiveSISV dao::ArchiveDAO

seq
Ref SD : create accessrestrictionRule

seq
Ref SD: create appraisalRule

seq
Ref SD: create ContentDescription

create(ArchiveDTO) :long

id technique archive

loop create document

seq
Ref SD: create document

loop create archiv eObj ect

seq

Ref: create archiveObject

53
 «actor,Extern...

sd Transfer Archiv e

Transfert::TransfertServiceImpl sisv::ArchiveSISV dao::ArchiveTransferRequestDAO dao::ArchiveTransferRequestReplyDAO dao::ArchiveTranferDAO dao::ArchiveTransferReplyDAO

kooosseryDesk.archiving.FrontEnd

transfer(archiveTransferDTO) :ArchiverTansferRequestReplyDTO

validate(ArchiveTransferRequestDTO) :bool

boolValue

[boolValue]:

create(archiveTransferRequestDTO) :ArchiveTransferRequestReplyDTO

create(ArchiveTransferRequestDTO) :long

id archiveTransferRequest

create(archiveTransferRequestReplyDTO) :long

id archiveTransferRequestReply
archiveTransferRequestReply

validate(ArchiveTransferDTO) :bool

boolValue

[boolValue]:

Begin
Transaction
create(archiveTransferDTO) :ArchiveTransferReplyDTO create(archiveTransferDTO) :long

id archiveTransfer

loop create archiv e

seq

Ref SD: create archive

create(archiveTransferReplyDTO) :long
id archiveTransferReply

archiveTransferReply
end
archiveTransferReply Transaction

(from Actors)
Figure 25 : Réalisation de cas d’utilisation ‘Transférer une archive’

54
III-Architecture logique du module archiving de koosseryDesk
Service Composants métiers
s ITransfertService

SISV (Service Simple ou service

Service de gestion
des transferts

IArchiveService
Service de gestion
des archives

interne)
IDeliveryService
Service de gestion des
communications
IRestitutionService
Service de gestion
des restitutions
IArchivalProfilService
Service de gestion des
profils d’archives

SISVFinder
IArchivalAgreementService
Service de gestion des DAOControleur
accords de versement
IReferentielService
Service de gestion des
référentiels SEDA
IOrganizationService DAO (Data Access Object)
Service de gestion des
Acteurs SEDA
IDUserService
Service de gestion
des utilisateurs

Storage
SGBD File System

55
Figure 26 : Architecture globale du module archiving
CHAPITRE IV REALISATION DES COMPOSANTS DU
MODULE ARCHIVING

VI.1 Framework utilisés

VI.1.2 Framework koosseryServer

Le Framework koosseryServer incarne toute la logique métier et la logique
d’accès aux données. Elle est organisée en trois couches : la couche Service composé
(SVCO), la couche service simple (SISV) et la couche d’accès aux données (DAO).
Ainsi elle part de l’accès aux données jusqu'à l’exposition des services à valeurs
ajoutées. La figure 27 montre les relations entre les différentes couches : DAO, SISV et
SVCO.

SVCO

SISV

DAO

Figure 27 Relation de dépendance entre les couches [9]

La couche DAO

C’est la couche d’accès aux données. Les données peuvent être stockées dans une
base de données (MySQL, Oracle, SQL Server….) ou sur tout autre support (fichier
Excel, XML, ….). Pour accéder aux données, la couche DAO va s’appuyer sur un
Framework de mapping O/R. iBatis et Hybernate sont les Framework de mapping Objet
relationnel (O/R) les plus utilisés à KOOSSERY. Il arrive aussi souvent de s’appuyer
directement sur JDBC mais cela se fait en respectant une architecture similaire à
l’utilisation d’un mapping O/R.

56
La couche SISV

C’est la couche des services simples. Cette couche manipule directement la

couche DAO. Il s’agit d’une couche en général très stable car elle est constituée de
petites fonctionnalités qui sont obtenues en effectuant des combinaisons d’appels sur la
couche DAO. Elle incarne la couche des composants métiers.

La couche SVCO

C’est la couche des services composés. Elle suit le design pattern des « Service
Composer ». Son but est de composer des services simples autant que nécessaire afin de
réaliser une demande cliente. Cette couche est constituée de services à haute valeur
ajoutée.

VI.1.2.1 Principes de développement lors de l’utilisation du socle Java

koosseryServer
Le développement avec le socle technique koosseryServer s’appuie sur des
principes dont nous avons recensé quelques-uns des plus importants à savoir l’inversion
de contrôle (IOC) et le principe d’isolation des composants

L’inversion de contrôle (IoC) grâce au framework Spring

L'inversion de contrôle est un modèle de conception (pattern IOC) ancien et

largement utilisé. Celui-ci peut être mis à profit pour diminuer le couplage entre
composants sous la forme d'injection de dépendance. L'inversion de contrôle est un
terme global désignant le fait qu'un programme principal n'appelle pas lui-même un
autre programme ou une librairie, mais que ce soit celui-ci, ou cette dernière qui contrôle
l'appel.
Isolation des composants dans le Framework

Afin de bien isoler les couches les unes des autres et aussi de permettre la
réutilisation des services d’une couche par de nouveaux appelants, KOOSSERY a choisi
comme principe directeur de toujours séparer l’interface d’un composant de son
implémentation. Il est important de comprendre que le granule du Framework est le
composant et non chaque classe devant être codée pour l’application. Les services
57
rendus par le composant sont publiés via une façade. Un consommateur du service
accède au composant via cette façade. Afin de localiser la façade ou le service adéquat,
le consommateur se sert d’un utilitaire : le Finder.
Cette pratique facilite énormément par exemple le changement d’implémentation
ou le changement de localisation d’une implémentation. La figure 28 illustre bien le
principe d’isolation de services et de localisation de ceux-ci via le Finder.

Figure 28: Principe d'isolation et de localisation des composants [9]

La figure 29 montre comment est mise en œuvre isolation Interface/Implémentation :

Figure 29: Mise en œuvre du principe d'isolation des composants [9]

58
VI.1.2.2 Architectures logicielles et mise en œuvre avec le socle koosseryServer
Le socle technique de KOOSSERY pour les applications Java s’intègre aussi bien
dans les architectures SOA que dans les architectures n-tiers. Il utilise pour cela la
technologie Spring pour mettre en œuvre ces différents concepts. Nous allons ici
présenter comment le Framework arrive à se glisser dans les architectures SOA et n-
tiers et aussi la mise en œuvre avec Spring et iBatis.

Mapping du Framework à une application n-tiers

L’architecture du Framework fait ressortir l’aspect multicouche. Plus

précisément la couche présentation, la couche métier et la couche d’accès aux données.
On peut établir une bijection entre l’architecture du Framework et les trois niveaux
d’abstraction d’une application. La figure 30 illustre ces différentes couches du
Framework

Presentation Layer Business Layer Data Access Layer

«utility» Service Common

Implémentation

Controleur Service
DAO (Data Acces
«interface» Object)
SVCO Finder
DAO

«interface»
SVCO
DATA SOURCE
DAO Factory
Usage
Web Appli / Win Form
SISV Finder Usage «interface»
SISV Données

Implémentation

Implémentation

VO «utility» «utility»
Exceptions Utilitaires
SVCO SISV

Figure 30 : modèle 3-tiers détaillé du socle technique Java de Koossery Technology

[9]

59
VI.1.3 Framework Spring (IOC et AOP)
Le Framework spring est une infrastructure similaire à un serveur
d'applications J2EE . Il prend en charge la création d’objets et la mise en relation
d’objets par l’intermédiaire d’un fichier de configuration qui décrit les objets à fabriquer
et les relations de dépendances entre ces objets. Le gros avantage par rapport aux
serveurs d’application est qu’avec spring, les classes n’ont pas besoin d’implémenter
une quelconque interface pour être prises en charge par le Framework (au contraire
des serveur d'applications J2EE et des EJBs). C’est en ce sens que spring est qualifié de
conteneur “ léger ”. Le framework spring est basé sur trois concepts clés (Inversion of
Control, Aspect Oriented Programming et Abstraction) [3]. Dans le cadre de notre
travail nous avons utilisé les concepts suivants de spring :

- Inservion Of Control (injection de dépendances)

- Aspect Oriented Programming (AOP)

VI.1.3.1 Inversion Of Control avec spring

L’injection de dépendance peut être effectuée de trois manières possibles :

- L’injection de dépendance via le constructeur.

- L’injection de dépendance via les modificateurs (setters).
- L’injection de dépendance via une interface

Couche interface utilisateur Couche métier Couche d’accès aux données(DAO)

SPRING

Figure 31 : Communication des couches via spring

Toutes les couches de l’application sont indépendantes, la communication entre

elles se fait essentiellement par découverte de service.

60
VI.1.3.2 Aspect Oriented Programming (AOP) avec spring
L’AOP est un paradigme qui permet de séparer les aspects transversaux (sécurité,
journalisation et gestion des transactions) afin que le développeur soit mieux concentrer
sur la logique métier. spring nous offre son côté AOP pour la gestion des transactions.

VI.1.4 Framework Drools

Drools est un framework de gestion des règles métiers (SGRM ou BRMS) [5].
Un BRMS a pour objectif principal de fournir un environnement d’édition des règles
utilisable simplement et directement par des experts « métier » sans compétences
informatiques particulières. Cela permet de faciliter la maintenance évolutive, grâce à
la lisibilité des règles, et induit donc une meilleure réactivité et adaptation aux
changements. En effet, le codage et la validation des nouvelles règles sont plus rapides
à effecteur et plus aisées à mettre en œuvre, les utilisateurs n’ayant plus besoin de faire
appel aux services informatiques. Ceci est possible, car les BRMS sont conçus pour
séparer la logique « métier » (la formalisation des règles, en utilisant directement les
concepts « métier ») de la logique système (la mise en œuvre technique). Drools repose
essentiellement sur les concepts de l’intelligence artificielle suivants :

- La base de règles (règles métier définir par l’utilisateur)

- La base des faits (données manipulées par l’application)

- Le moteur d’inférence est un programme chargé d’exploiter la base de

connaissance (base de règles et la base des faits) pour mener un
raisonnement sur le problème posé en fonction du contenu de la base de
faits.

61
 Figure 32 : illustration de la mise en œuvre de Drools (google image)

La figure ci-dessus montre comment Drools s’intègre de façon transversale au

système applicatif. Il prend en entrée les règles métiers et les data objects et produire en
sortie les data objects après l’application des règles.

VI.2 Environnement de développement

VI.2.1 Outil de modélisation UML (Enterprise Architect)

Pour faciliter la phase de modélisation, l’équipe devrait disposer d’un outil
permettant de réaliser facilement les différents artefacts à produire. De nos jours un tel
outil devrait être un environnement de modélisation visuel d’une grande performance,
permettant une productivité accrue tout en respectant les standards liés au langage
UML. De par sa stabilité Entreprise Architect est l’outil de modélisation UML utilisé
par la société KOOSSERY

VI.2.2 IDE (Eclipse)

Après la modélisation, on passe à l’écriture du code. Il faut alors se doté d’un
environnement de développement intégré lié au langage orienté objet (java). Une des
qualités première d’un tel outil doit être sa flexibilité. En effet celui-ci devrait par
exemple permettre une greffe d’autres outils externes, ce qui permet aux développeurs
de faire appel à ces outils sans sortir de son environnement de développement. Eclipse
de par sa popularité et le fait qu’il soit open source est l’IDE utilisé par la société
KOOSSERY.

62
VI.2.3 Système de gestion de version (SVN)
Dans un projet de développement logiciel les membres de l’équipe n’étant pas
forcement sur place et chacun s’occupant d’une portion du code, il se pose alors le
problème d’accès concurrentiel au code et de l’évolution de celui-ci (le versionning).
Pour pallier à ce problème la société KOOSSERY dispose d’un serveur de gestion de
version SVN qui garde le code source de référence et dispose sur les différents postes
développeurs un client SVN pour l’accès au code stocké sur le serveur.

VI.2.4 Outil du build et de gestion du cycle de vie du projet (Maven)

La gestion manuelle du build et du cycle de vie du projet est fastidieuse d’où la
nécessité de se doté d’un outil de build et de gestion du cycle de vie du projet très
performant. Maven est l’outil choisi par KOOSSERY à cette effet, car en plus d’être
simple d’utilisation il permet de gérer les dépendances du projet, générer la
documentation et le site du projet.

VI.2.5 Plate-forme de test (Junit)

Le test unitaire est d’une importance capitale car ce n’est qu’après un test qu’on
peut qualifier une portion du code correct. La réalisation des tests unitaires consiste à
associer à chaque classe une classe de test qui se charge d’évaluer toute les méthodes de
la classe à tester. Il est nécessaire de se doté d’une plate-forme de test à fin d’être plus
productif et d’automatiser le processus de test. Junit est le framework de test unitaire
utilisé par la société KOOSSERY car son langage est très maniable et elle s’intègre
facilement à éclipse.

Junit propose deux types de classe de test :

- testCase : classe en charge d’évaluer les méthodes d’une classe

- testSuite : classe en charge d’exécuter plusieurs testCase.

63
VI.2.6 Plate-forme d'intégration continue

Figure 33 Intégration Contunie (google image)

L’intégration continue est une technique puissante qui permet de garder en phase
les équipes de développement et de limiter les risques et la complexité liée à la création
par plusieurs développeurs d’un logiciel unique. A intervalles réguliers, on construit
(build) et teste la dernière version du logiciel. Parallèlement, chaque développeur teste
et valide (commit) son travail en ajoutant son code dans un lieu de stockage commun à
tous les développeurs. Après le commit vers le serveur de sauvegarde il est nécessaire
de se rassurer que les dernières modifications n’ont pas créé des bugs puis par la suite
de générer le rapport et créer une version déployable du projet en cas de validation de
test. La société KOOSSERY a choisi la plate-forme CRUISE CONTROL en raison
de sa popularité et son ancienneté.

64
IV.3 Implémentation du module Archiving de koosseryDesk

Figure 34 : Structure de koosseryDesk vue d’Eclipse

koosseryDesk est un projet Maven constitué des sous module suivant :

- Le sous module ‘koosseryDesk.server.contract’ :

Ce module représente le contrat entre le front-end et le back-end, il contient les

DTO, les exceptions, et les interfaces pour l’exposition du back-end.

- Le sous module ‘koosseryDesk.server.impl’ :

Ce module représente l’implémentation du serveur. Il est organisé en trois

package suivant :

o dao : pour les accès aux données

o sisv : pour l’implémentation des composants ‘metier’

o service : pour l’implémentation des composants de ‘service’

- Le sous module ‘koosseryDesk.webapp’ :

Ce module représente le front-end en charge d’invoquer les services exposés par

le back-end.

65
Nous avons travaillé spécifiquement sur le back-end (partie serveur) du module
archiving de koosseryDesk.

IV.3.1 kooseryDesk.server.contract
L’implémentation du module ‘contract’ consiste à implémenter toutes les
données de transferts (DTO), l’exception serveur et les interfaces des services à exposés
au front-end.

Figure 35: représentation des éléments du module contract

IV.3.2 Service Simple

L’implémentation d’un service simple consiste à :

- Implémenter les fichiers de configuration des ressources

- Coder les composants ‘métier’

IV.3.2.1 Configuration des ressources pour services simples

Figure 36- Configuration des ressources pour la couche SISV

66
 La figure ci-dessus présente les configurations nécessaires pour le bon
fonctionnement des services simples. Les contenus des fichiers ci-dessous sont
représentés en annexe.

Le fichier koosseryDeskSISVMessage.xml est la configuration des messages

d’erreur pour les composants de ‘métier’ de koosseryDesk.

Le fichier spring-koosseryDeskSISV.xml est la configuration spring des

composants ‘métier ’pour l’injection des dépendances et la gestion des transactions.

Le fichier koosseryDeskSISV.properties représente la configuration des

propriétés systèmes pour les services simples.

Le fichier env.properties contient les propriétés système pour l’environnement de

travail.

Le fichier log4j.properties permet de configurer les logs c’est-à-dire le niveau des

log et la localisation du fichier contenant les logs, il permet une traçabilité du système
afin de favoriser la correction des Bugs.

Une fois la configuration des ressources terminée on peut alors commencer le code.

IV.3.2.2 Implémentation des services simples

L’implémentation d’un service simple consiste à manipuler les données au

travers des DAO qui reposent sur le principe CRUD (Create, Read, Update and Delete).
Ces DAO nous sont fournis par l’équipe des accès aux données.

IV.3.3 Service composés et exposition du serveur

L’implémentation des Composants de service consiste à :

- Implémenter les fichiers de configuration de ressources

- Combiner les composants ‘métier’ afin de répondre à un cas d’utilisation

67
IV3.3.1 Configuration des ressources pour les services composées

Figure 37 : ressources pour les services composés

La figure 37 présente les configurations nécessaires pour le bon fonctionnement

des services composés. Le contenu des fichiers ci-dessous sont représentés en annexe.

Le fichier koosseryDeskServiceMessage.xml représente la configuration des

messages d’erreur pour la couche service composés de koosseryDesk.

Le fichier spring-koosseryDeskService.xml est la configuration spring pour la

couche service de koosseryDesk.

Le fichier koosseryDeskService.properties contient les propriétés système pour

les composants de service de koosseryDesk.

IV3.3.2 l’implémentation des services composés

Implémenter un service consiste à orchestrer un ensemble de service simple

pour implémenter une interface du module contract.

IV.3.4 Processus de test et d'intégration

Après chaque implémentation d’une méthode d’une classe donnée nous
réalisons une méthode correspondante de sa classe de test, on exécute tous les cas de
tests pour éviter le problème de non-régression. Chaque matin avant de toucher au code,
nous effectuons un update du projet à partir de Subversion (client de SVN) pour
synchroniser le projet local avec celui se trouvant sur le serveur SVN. Après la mise à
jour on passe si nécessaire à la résolution des conflits puis l’exécution des cas de test
pour éviter la non-régression.

68
Après chaque implémentation et tests unitaires en local, nous effectuons les opérations
suivantes :

- update pour avoir les contributions des autres développeurs

- exécuter les cas de tests

- commit pour reporter nos modifications sur le repository SVN

VI.3.5 Mise en œuvre du moteur Drools dans un projet test

Le projet koosseryhuman est un mini projet de gestion du personnel de
l’entreprise KOOSSERY développé à l’échelle du laboratoire afin d’effectuer des
travaux de recherche dessus pour des intégrations future à la plate-forme koosseryDesk.
Le but de ce travaux est d’intégré le moteur « Drools » afin qu’un expert métier puisse
gérer les règles métier sans plus faire appel au développeur. L’objectif principal ici est
d’utiliser l’AOP (Aspect Oriented Programming) pour gérer de façon transversale la
validation des DTO.

Configuration des ressources pour la mise en œuvre de « Drools » dans le projet

koosseryhuman.

Figure 38: drools-koosseryhumanRules.drl

69
Figure 39 : Configuration de l’AOP Pour la validation des règles

Figure 40 drools-config.xml

70
CHAPITRE V : RESULTATS ET COMMENTAIRES

Dans cette partie nous présentons et commentons les résultats obtenus de nos
travaux. Au terme de nos travaux nous avons réalisé 10 sur 12 cases d’utilisation
abstraits présentés dans le cahier des charges. Cette réalisation est constituée des deux
projets suivants :

- Un projet UML;

- Un projet Maven;

V.1 Le projet UML

Le projet UML obtenu représente la conception des composants de service du
module archiving de la plate-forme koosseryDesk, pour plus de détaille voir chapitre
III paragraphe ‘ III.3 analyse et conception des composants du module archiving’

V.2 Projet Maven

Le projet Maven représente la plate-forme koosseryDesk en sa totalité, mais le
résultat présenté ici portera seulement sur le module archiving de la dite plate-forme.
Au sein du module archiving de koosseryDesk nous avons obtenu les résultats suivants :

- implémentation des cas d’utilisations

- implémentation des cas de test unitaires

V.2.1 Implémentation des cas d’utilisations

L’implémentation des composants de ‘service’ et des composants métier du
module archive est consigné dans les sous modules suivants du projet Maven:

- com.koosseryDesk.server.impl.service.arching : service composé

- com.koosseryDesk.server.impl.sisv.archiving : service simple

71
V.2.2 Résultats des tests unitaires
Cette partie consiste à la présentation des résultats de test unitaire de nos
implémentations. La plate-forme de test JUnit 4 nous permet de réaliser les tests
unitaires, elle nous donne également le temps de réponse de chaque fonctionnalité afin
que nous puissions optimiser nos algorithmes pour réduire le temps de réponse du
serveur.

V .2.2.1 Résultats des tests du composant de service «TransfertServiceImpl »

La figure 41 représente les résultats d’exécution du composant gestion des
transferts d’archives issu de la plate-forme JUnit. Ici nous avons réalisé 6 sur 8
fonctionnalités. Les fonctionnalités analyser un transfert et ‘traiter un transfert’ n’ont
pas été réalisé, en ce qui concerne ‘ traiter un transfert’ sa réalisation dépend du
composant gestion des workflows qui est en cours de conception. Les Fonctionnalités
de ce composant sont exposées au front-end à travers l’interface ‘ITransferService’.

Figure 41 : Résultat des tests pour TransfertServiceImpl

72
V .2.2.2 Résultats des tests du composant de service «ArchiveServiceImpl »
La figure 42 représente les résultats d’exécution du composant gestion des
archives issu de la plate-forme JUnit. Ici toutes les fonctionnalités ont été réalisées et
sont exposées au front-end à travers l’interface ‘IArchiveService’

Figure 42 : Résultat des tests pour ArchiveServiceImpl

V .2.2.3 Résultats des tests du composant de service «DeliveryServiceImpl »

La figure 43 représente les résultats d’exécution du composant gestion des
communications d’archives issu de la plate-forme JUnit. Ici toutes les fonctionnalités
ont été réalisées et sont exposées au front-end à travers l’interface ‘IDeliveryService’

Figure 43 : Résultat des tests pour DeliveryServiceImpl

73
V .2.2.4 Résultats des tests du composant de service «RestitutionServiceImpl »
La figure 42 représente les résultats d’exécution du composant gestion des
Restitutions d’archives issu de la plate-forme JUnit. Ici toutes les fonctionnalités ont
été réalisées et sont exposées au front-end à travers l’interface ‘IRestitutionService’

Figure 44 : Résultat des tests pour RestitutionServiceImpl

V .2.2.5 Résultats des tests du composant de service «ReferentielServiceImpl »

La figure 45 représente les résultats d’exécution du composant gestion des
référentiels SEDA issu de la plate-forme JUnit. Ici toutes les fonctionnalités ont été
réalisées et sont exposées au front-end à travers l’interface ‘IReferentielService’

Figure 45 : Résultat des tests pour ReferentielServiveImpl

74
V .2.2.6 Résultats des tests du composant de service «OrganizationServiceImpl »
La figure 46 représente les résultats d’exécution du composant gestion des
acteurs SEDA issu de la plate-forme JUnit. Ici toutes les fonctionnalités ont été
réalisées et sont exposées au front-end à travers l’interface ‘IOrganisationService’

Figure 46 : Résultat des tests pour OrganizationServiceImpl

V .2.2.7 Résultats des tests du composant de service «UserServiceImpl »

La figure 47 représente les résultats d’exécution du composant gestion des
Utilisateurs issu de la plate-forme JUnit. Ici toutes les fonctionnalités ont été réalisées
et sont exposées au front-end à travers l’interface ‘IUserService’.

Figure 47 : Résultat des tests pour UserServiceImpl

V .2.2.8 Résultats des tests du composant de service RoleServiceImpl »

La figure 48 représente les résultats d’exécution du composant gestion des Role
des Utilisateurs issu de la plate-forme JUnit. Ici toutes les fonctionnalités ont été
réalisées et sont exposées au front-end à travers l’interface ‘IRoleService’

Figure 48 Résultat des tests pour RoleServiceImpl

75
V .2.2.9 Résultats des tests du composant «ArchivalAgreementServiceImpl »
La figure 49 représente les résultats d’exécution du composant gestion des
accords de versement issu de la plate-forme JUnit. Ici toutes les fonctionnalités ont été
réalisées et sont exposées au front-end à travers l’interface
‘IArchivalAgreementService’

Figure 49 : Résultat des tests pour ArchivalAgreementServiceImpl

Figure 50 : Résultat des tests pour ArchiveSISVImpl

76
 V.3 Évaluation des composants de service du module ‘archiving’

Composants de service Taux de Réalisation des fonctionnalités

Nbre fonctionnalités Nbre Réalisations Pourcentage

Gestion des transferts d’archives 8 6 75%

Gestion des archives 9 9 100%

Gestion des communications d’archives 6 6 100%

Gestion des Restitutions d’archives 6 6 100%

Gestion des Référentiels SEDA 9 9 100%

Gestion des acteurs SEADA 4 4 100%

Gestion des Utilisateurs 4 4 100%

Gestion des Rôles 4 4 100%

Gestion des accords de versement 4 4 100%

Gestion des profils d’archives 4 4 100%

Gestion des worflows 4 0 0%

Gestion du service de contrôle 1 0 0%

Total 63 56 88,9%

Tableau 2 : Taux de réalisation des Fonctionnalités

La tâche qui nous est allouée durant notre stage ingénieur consistait à participer
au développement de la plate-forme koosseryDesk en développant les composants de
service du module archiving. Comme vous pouvez le constater à travers le taux de
réalisation qui est de 88,9% que le développement des composants de services du
module d’archive n’est pas achevé. Vue la charge du travail à réaliser sur le module
archiving 4 mois n’ont pas été suffisant, d’où la nécessité d’un temps supplémentaire
pour clos totalement le module archiving de koosseryDesk.
77
CONCLUSION ET PERSPECTIVES

L’objectif de notre stage ingénieur au sein de la société KOOSSERY était de

participer au développement de sa plate-forme koosseryDesk (plate-forme intégrante
de traitement d’information de bout en bout), en développant les composants de service
de la partie back-end de koosseryDesk dans le cadre du module archiving.

Nous avons dans ce travail intégré l’environnement de travail de KOOSSERY,

ensuite une étude de la norme SEDA 1.0 et l’open source as@lae a été effectué, puis un
projet UML pour le back-end du module archiving a été réalisé et enfin une
implémentation a été réalisé. 10 composants sur 12 présenté dans le cahier des charges
ont été implémenté (9 totalement et 1 partiellement voir le tableau « Taux de réalisation
des Fonctionnalités » pour plus de détaille) et livré, L’étude et la mise en œuvre du
moteur Drools dans un projet test a été un succès. Ce stage s’achève avec un taux de
réalisation de 88,9%, d’où la nécessité d’un temps supplémentaire pour clos totalement
le module archiving de koosseryDesk.

Perspectives

Le travail présenté dans ce document est réalisé à hauteur de 88,9%. Nous

proposons que les composants gestion des workflows, gestion du service de contrôle et
la fonctionnalité ‘traiter un transfert’ du composant gestion des transferts soient
développés, afin que le module archiving de koosseryDesk puisse jouer son rôle.

L’intégration du moteur de validation des règles ‘Drools’ peut faire l’objet d’une version
future de la plate-forme kosseryDesk.

78
BIBLIOGRAPHIE

Ouvrages et Articles

[1] Gilbert Raymond, SOA: Architecture Logique, version 2.1, Softeam, Paris, 2011.

[2] Eric A Marks, Michael Bell, Service-Oriented Architecture: a planning and

implementation guide for business and technology, Hoboken, John Wiley & Sons, USA,
2006.

[3] Gary Mak, Hervé Soulard (traducteur), Spring Recipes,a problem-solution approach
( Spring par l’exemple), Pearson Education, Spring Source, Paris, 2009.

[4] Petar Tahchiev, Felipe Leme, Vincent Massol, Gary Gregory, JUnit in action, second
edition, Manning Publications Co, Stamford, USA, 2011.

[5] Michal Bali, Drools JBoss Rules 5.0 Developer's Guide, Packt Publishing, 2009.

[6] Alan Shalloway, James R. Trott, Deseign Patterns Explained A New Perspective on
Object-Oriented Deseign, second edition, Ed Addison Wesley Professional, 2004

[7] Erich Gamma,Richard Helm,Ralph Johnson,John Vlissides, Design Patterns :

Elements Of Reusable Object-Oriented Software, 1994

[8] Vincent Legendre, Gérald Petitjean, Thierry Lepatre, Gestion des règles « métier »,
No 92, 2010.

[9] KOOSSERY, Socle Technique Java de Koossery Technology

[10] ISIMA École Doctorale Sciences Fondamentales, Introduction aux objets. 1999

79
Thèses et mémoires

[11] Ludivine Magrez, Comment choisir une solution de gestion d'archives : le cas de
la Communauté d’Agglomération de la Porte du Hainaut, Université Charles de Gaulle
Lille 3,UFR IDIST, 2010.

[12] Djomga Touka Peter Charles, Développement industrialisé d’application N/tiers

partie back-end, Mémoire d’Ingénieur de Conception, Université de Yaoundé I, ENSP,
2007.

Articles du web (webographie)

[13]http://www.archivesdefrance.culture.gouv.fr/seda/documentation/SEDA_descripti
on_standard_v1_0.pdf, consulté le 26/03/2014 à 9h00 CMR

[14]http://koossery-tech.developpez.com/tutoriels/uml/framework-pour-modelisation-
projet-langage-uml, consulté le 01/04/2014 CMR

[15] http://corej2eepatterns.com/Patterns2ndED/index.html, consulté le 02/07/2014,

10h00 CMR

[16] http://www.dotnetguru.org/downloads/pag.pdf, consulté le 03/07/2014, 06h00

CMR

[17]http://www.softeam.fr/pdf/fr/SAO_Architecture_Logique.pdf, consulté le
04/05/2014, 10h30 CMR

[18] http://www.archivesdefrance.culture.gouv.fr/static/2997,consulté le 04/05/2014,

12h30

80
ANNEXE

koosseryDeskSISVMessage.xml

81
spring-koosseryDeskSISV.xml

koosseryDeskSISV.properties

82
 koosseryDeskSISV.properties

env.properties

koosseryDeskServiceMessage.xml

83
log4j.properties

84
spring-koosseryDeskService.xml

85