Intégration et Généricité: Modèle ADROIT

SOMMAIRE Pages

Introduction 2

I. Intégration 4

1. Etat de l'art 4

2. Intégration par le modèle ADROIT 44

3. Critiques sur l'intégration 52

4. Propositions d'amélioration du modèle d'intégration de ADROIT 53

II. Généricité du modèle application 58

1. Etat de l'art 59

1. Généricité par les modèles 59

2. Généricité par les composants 63

2. ADROIT ( Acte - Document - Rubrique - Objet - Information - Tiers) 65

3. Critiques sur la généricité du modèle application 75

4. Propositions et amélioration du modèle application de ADROIT 76

III. Plateforme ADROIT : Comment gérer un hôtel 78

1. Vue d'ensemble des fonctionnalités d'une gestion d'hôtel 78

2. Les cas d'utilisation 79

3. Diagramme de classe 81

4. Intégration de gestion d'hôtel dans ADROIT 82

IV. Conclusion 85

INTRODUCTION

Depuis des années, les systèmes d'information deviennent de plus en plus complexes. On parle désormais de système obéissant à la généricité des données et des fonctionnalités.

Un système générique doit fournir :

Ø un modèle de données générique utilisable par un utilisateur final autorisé et contenant les données les plus souvent présentes dans la majorité des services.

Ø Une interface utilisateur documentée entièrement paramétrable par le même utilisateur.

Dans les grandes entreprises et organisations, les besoins de l'utilisateur peuvent être complètement différents d'un site à l'autre et d'une fonction d'entreprise à une autre. L'un des défis majeurs pour aboutir à l'informatisation de tels systèmes est de fournir des outils génériques et pratiques qui conviennent à de multiples cas de figures et aux acteurs impliqués dans les fonctions d'entreprise correspondantes.

Les entreprises et organisations tous secteurs confondus, doivent s'attacher à :

· Tirer profit des infrastructures existantes pour faire des économies.

· Prolonger la durée de vie de leurs systèmes.

· Moderniser tout en maintenant une activité normale.

Conscients de ces enjeux et de leur incidence majeure sur l'activité de l'entreprise, les acteurs du génie logiciel se penchent de plus en plus sur l'intégration et la généricité des systèmes qui permettront de concevoir, déployer et exploiter des solutions pratiques.

Notre travail consiste à analyser l'intégration de systèmes déjà existants tels que ERP5, OFBIZ, COMPIERE et TINYERP, à étudier la généricité du système ADROIT et à faire une mise en oeuvre en intégrant la gestion d'hôtel dans ADROIT.

A cause de la nécessité pour les entreprises de mettre en place des systèmes d'informations paramétrables, le système que nous allons concevoir doit remplir toutes les conditions pour être utilisé dans n'importe quelle structure ou domaine.

Ce mémoire comporte un ensemble de recherches qui s'inscrivent dans le cadre d'une problématique portant sur l'intégration des systèmes et la généricité des modèles. D'une part, il établit les fondements théoriques d'une intégration et d'une généricité. D'autre part, il rassemble les meilleures pratiques et démarches pour faire une bonne intégration par généricité.

Ce document permet, en effet, de bien définir les objectifs que nous voulons atteindre, la démarche que nous adoptons et les moyens dont nous disposons pour les atteindre.

Dans un premier temps, nous chercherons à comprendre comment intégrer ou faire intégrer notre système à d'autres. Pour cela, nous verrons d'abord les PGI ( Progiciels de Gestion Intégré) avant de mettre en évidence les différents outils d'intégration tels que les EAI (Entreprise Application Intégration) et les EII (Entreprise Information Intégration). Pour illustrer l'utilisation de ces outils, nous exposerons des exemples de réalisations de PGI, d'EAI et d'EII.

Dans ce chapitre, nous étudierons le modèle ADROIT ( Acte, Document, Rubrique, Objet, Information, Tiers) en passant en revue ses aspects génériques. ADROIT est un modèle générique conçu par InformatiS pour apporter une solution à l'épineux problème de l'intégration et de la généricité. Ce modèle sera comparé à d'autres modèles tels que ERP5, OFBIZ, COMPIERE etc.. A l'issue de cette étude comparative, nous ferons des critiques sur les différents modèles étudiés et apporterons des propositions sur le modèle ADROIT.

Dans un deuxième temps, nous étudierons la généricité dans son ensemble en se basant sur deux aspects qui sont : la généricité par les modèles et la généricité par les composants.

Nous verrons aussi le modèle d'application de ADROIT qui nous permettra de comprendre son degré de généricité.

Nous ferons des critiques sur la généricité du modèle d'application de ADROIT et y apporterons des propositions d'amélioration.

Dans un troisième temps, pour mettre en oeuvre notre travail de recherche, nous ferons l'intégration de la gestion d'hôtel dans le modèle ADROIT. Pour cela, nous donnerons une vue d'ensemble sur la gestion d'un hôtel, les cas d'utilisations permettant de structurer les besoins des utilisateurs et les objectifs correspondants, le diagramme de classe qui donnera structure du modèle à intégrer et l'intégration de la gestion d'hôtel proprement dite.

Nous finirons enfin par la conclusion dans laquelle nous ferons un aperçu global de notre travail.

I. Intégration

I.1 Etat de l'art

De nos jours, de larges volumes de données sont disponibles publiquement, les types de données sont divers, et les ressources très nombreuses. Souvent les données provenant de différentes sources se complètent mais se recoupent également

Un système intégré est un système qui organise les interactions avec les utilisateurs humains en privilégiant la saisie et l'utilisation en temps réel des informations, qui minimise les saisies multiples et facilite la réutilisation des données au profit des différentes activités de l'entreprise (délivrance des soins, gestion administrative et financière, pilotage, autoévaluation et audit, recherche, enseignement). Un système intégré est capable de faire abstraction d'un découpage en sous-systèmes dédiés aux différentes unités fonctionnelles ( fichier central des patients, facturation des soins, etc...).

Il convient tout d'abord de distinguer le concept d'intégration en tant que propriété d'un système (on parle de système intégré), du concept d'intégration au sens d'un processus tendant à transformer un système pour en faire un système intégré.

L'intégration des applications consiste en la combinaison de plusieurs applications métiers, créant ainsi une valeur ajoutée pour les entreprises car cela permet l'échange et le partage des données.

L'expansion du nombre de sources d'informations disponibles sur le Web a fait de l'intégration de données un domaine de recherche de plus en plus important. Les sources d'informations sont autonomes, réparties et hétérogènes. Pour optimiser l'exploitation des informations, les systèmes d'intégration de données offrent à l'utilisateur une vue uniforme et une interrogation transparente des contenus de ces différentes sources.

Selon Mathieu Lafourcade [I.1], l'intégrabilité d'un système est sa faculté à pouvoir accepter un nouveau composant. Un composant est d'autant plus intégrable qu'il est facile de le rajouter comme nouvel élément d'un système.

On peut définir un ERP comme un système d'informations unique (englobe toutes les autres applications). Dans ce cas, l'ERP contient des fonctions ; une fonction manipule des objets métiers; les objets métiers sont décrits par une base de données unique.

L'ERP est un sous ensemble d'informations capable de prendre en charge la gestion intégrale de l'entreprise, incluant la gestion comptable et financière, la production et la logistique, la gestion des ressources humaines, la gestion administrative ainsi que la gestion des ventes et des achats.

On peut définir l'organisation d'un ERP comme suit :

Base de Données

Marketing

Gestion de la Production

Logistique

Finances

R & D

Achats/Appro

Commercial

Ressources Humaines

Organisation d'un ERP

PGI dont l'acronyme est Progiciel de Gestion Intégré, est l'équivalent des ERP, c'est à dire Enterprise Ressource Planning, en anglais. Ce sont des logiciels centralisant toutes les informations concernant certaines fonctions d'une entreprise. Ils s'articulent autour d'une base de données unique, un jeu de code et une interface utilisateur intégrée. 

En effet, les ERP se proposent de gérer les ressources de l'entreprise, mais encore faut-il les faire fonctionner correctement avec les systèmes déjà en place. Les progiciels de gestion intégrés (ERP) sont des applications qui, fonctionnant à travers une organisation et grâce à leur intégration, automatisent les processus d'affaires de l'organisation. 

Philippe Louchet et Frédérique Brossillon expliquent que [I.2] « La caractéristique première du PGI est son organisation autour d'une unique base de données et son rôle d'unification des systèmes d'informations.

  L'EAI est un logiciel qui permet la compatibilité et l'interopérabilité entre des applications déjà existantes, non compatibles à l'origine. Elle  permet de synchroniser et de faire communiquer

des applications hétérogènes qui n'avaient pas été conçues pour dialoguer entre elles par échange

d'informations indépendamment des plates-formes et du format des données.

Il permet de fédérer des applications mais aussi il limite le nombre des interfaces et facilite l'évolution du système. 

L'EAI à trois fonctionnalités qui sont :

Ø la connexion aux applications,

Ø la conversion des informations dans un langage commun,

le transport et le routage des informations, de l'application émettrice à l'application réceptrice. 

Les web services sont considérés comme des outils de connectivité au sein des EAI. C'est une application qui permet à client de se connecter à d'autres applications

Le web service étant donc une fonctionnalité de l'EAI, F. Casati et M-C Shan le définissent comme [I.3] une application mise à disposition sur Internet par un fournisseur de service, et accessible par les clients à travers des protocoles Internet standards.

Les web services sont des protocoles qui font communiquer des programmes écrits dans des langages de programmation différents. C'est ainsi que Patrick Kellert et Farouk Toumani ont définit techniquement un service web [I.4] comme étant une interface décrivant une collection d'opérations accessibles via le réseau à travers des messages XML standardisés.

Le MOM signifiant « Message Oriented Middleware », est également appelé Middleware asynchrone. En fait, c'est une technologie qui permet de transporter et de transformer les messages d'un point à un autre et facilite la communication entre applications.

Le concept de Middleware désigne des services destinés à faciliter l'intégration des applications au sein des systèmes d'informations. La démarche d'intégration fondée sur l'utilisation d'un Middleware consiste donc à modifier les produits existants pour permettre leur inter

fonctionnement via une plateforme d'intégration.

Moisdon J-C et Seli-Arslan définissent le Middleware à messages ou MOM ( Message-Oriented Middleware ) [I.5] comme une infrastructure logicielle de communication asynchrone qui prend à sa charge les problèmes transitoires de réseau, de connexion de machine, voire de disponibilité de machines. Ils sont utilisés pour interconnecter des applications d'entreprise

L'EDI est un concept d'échange de données informatisé visant à transférer d'application à application, à l'aide d'ordinateurs, connectés sur un ou plusieurs réseaux des données structurées selon un langage normalisé via un mode de communication électronique.

L'EII (Enterprise Information Integration) permet de coordonner des transactions impliquant différentes sources de données. Elle permet aussi à une application métier d'accéder à un ensemble de bases de données par le biais d'une vue logique unique et une interface de programmation unique.

  XML est un langage à balises permettant de décrire des documents à destination du Web, qui contiennent à la fois des données ( des mots, des images ...) et les indications sur leur rôle.

Un datawarehouse est une plateforme avec des données de très bonne qualité qui supportent des applications de type informationnel, comme les applications d'aide à la décision, ainsi que les processus dans l'entreprise.

W.H. Inmon [I.6] définit le datawarehouse comme étant une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour le processus d'aide à la décision. En 2003, Jeff Konnen [I.7] précise que la motivation des datawarehouses, ou entrepôts de données, est de transformer des données stockées dans des systèmes d'information opérationnels en informations.

L'intégration ad hoc consiste à modifier les sous-systèmes existants pour permettre la communication des données entre les sous-systèmes à intégrer. Cette approche n'est pas antinomique de l'utilisation de standards.

On peut distinguer trois approches de l'ERP :

L'adoption complète « Comprehensive » : Dans cette approche, un ERP quasiment au complet est adopté à travers une organisation multi nationale, qui comporte plusieurs sites.

L'adoption moyenne « Middle road » : Dans cette catégorie, l'organisation qui adopte l'ERP peut y avoir un site principal ou plusieurs sites.

L'adoption vanille « Vanilla » : Cette catégorie est plutôt peu ambitieuse et peu risquée. On déploie le système dans un seul site et avec un nombre d'usagers. On n'adopte qu'un nombre restreint de modules clés. C'est l'organisation qui s'adapte à l'ERP et non l'inverse.

Philippe Louchet et Frédérique Brossillon explique comment le terme « processus » revient fréquemment quant il est question de PGI. [I.2] et pour cause : [...] `approche processuelle de l'organisation de l'entreprise est basée sur l'analyse en termes de « facteurs clés de succès » et de « chaîne de la valeur » développée notamment par Michael Porter [I.8].

Dans son livre « La mise en place des systèmes d'informations », Rigaud Louis [I.9] montre que l'approche systémique et modulaire de l'entreprise qui présente celle-ci comme la réunion de trois sous-systèmes (systèmes opérant, d'information, de décision) peut également être mobilisée pour penser l'intégration à laquelle prétend le PGI.

L'essence même de l'EAI est de décorréler les applications entre elles. Chaque application communique directement avec l'EAI, qui se charge d'acheminer les informations qu'il reçoit vers les applications destinatrices. L'EAI peut être vu comme un bus à travers lequel différentes entités vont communiquer. Ce bus va assurer diverses fonctions (transport, transformation, routage et workflow) ainsi que les services de sécurité. 

L'EAI répond à un besoin de mise en oeuvre d'une solution d'intégration rapide. Il ne nécessite pas de modifier l'architecture du SI ni les applications qu'il intègre.

 Pour fonctionner, l'EAI intègre les éléments suivants :

Ø un référentiel des objets métier de l'entreprise, un moteur de gestion de règles,

Ø des connecteurs applicatifs permettant l'interface avec les applications et les données de l'entreprise,

Ø un système de transport des informations.

Pour le transport des informations, on parle de :

Ø hub : le point central ou convergent les informations du système,

Ø Middleware : d'une manière générale, la couche logicielle qui s'intercale entre des applications et un système,

Ø MOM (Middleware orienté messages) : il s'agit d'une organisation où une application A n'attend pas la réponse de l'application B, avec laquelle elle communique, pour continuer à travailler. Dans ce cas, les communications sont gérées à l'aide de files d'attente, la communication est asynchrone.

Ø message broker : le système qui traduit les données échangées, gère les adresses et les files d'attentes des messages porteurs d'informations entre les applications. 

Les approches des web services sont des approches de connectivité des EAI.

Ardissono L. Goy A. et Petron G. dans le livre intitulé « Enabling Conversations with web services » [I.10] définissent l'approche web services comme une  approche basée sur les modèles théoriques de la gestion du dialogue.

L'approche web services a un objectif qui est définit dans le livre « Semantic Web Enabled Web Services. » de D. fensel C. Bussler et A. Maedche [I.11] comme étant de transformer le Web en un dispositif distribué de calcul où les programmes (services) peuvent interagir de manière intelligente en étant capables de se découvrir automatiquement, de négocier entre eux et de se composer en des services plus complexes.

Les approches des MOM sont des approches de transport des EAI.

Dans un article intitulé « Approche coopérative de l'adaptabilité des applications mobiles basées sur MobileJMS » de Mejdi Kaddour et Laurent Pautet [I.12] montrent que le faible couplage entre les entités communicantes dans un MOM, en terme de disponibilité et de logique fonctionnelle, permet d'incorporer à un système d'information global les applications et les données patrimoniales de l'entreprise, et ouvre la voie à de nouveaux types d'accès comme le Web.

EII a trois dispositifs principaux :

Ø C'est une infrastructure de logiciel, pas une application. EII soutient la création des applications comme portails d'entreprise qui montrent et analysent des données combinées à travers des sources de données.

Ø L'EII est un logiciel simple qui donne une large étendue des applications sur la deuxième rangée d'une architecture e-business qui accède à des bases de données et des systèmes de fichiers fonctionnant sur la troisième rangée sans données de réplique.

Ø Elle fournit une approche intégrée. EII fournit une infrastructure commune sur ce que tous les liens peuvent être construits.

L' EDI a trois approches qui sont défini par Denis Gerard et J-R Caron [I.13]  

Ø L'EDI en mode autonome est la forme la plus simple à mettre en place. Les applications d'EDI fonctionnent sans liens avec les autres applications de l'entreprise. L'EDI en mode autonome se concrétise de façon plus courante sous trois formes : le formulaire électronique, la télécopie à EDI et le bureau de service. 

Ø Le mode intégré suggère une harmonisation entre les applications existantes et le logiciel d'EDI. L'EDI, en mode intégré, entraîne une automatisation de certaines tâches. L'application d'EDI peut converser avec les applications de l'utilisateur.

Ø L'EDI en mode intégré et transformation se distingue du mode intégré non pas sur le plan du matériel ou du logiciel, mais plutôt par le fait que l'EDI est intégré aux processus d'affaires de l'entreprise.

Olivier Grenet dans « la connectivité des logiciels doit s'appuyer sur des standards afin d'assurer l'interopérabilité des systèmes » montre le caractère presque indispensable de XML au sein des SGBDR [I.14] en ces termes : « Le développement croissant des contenus XML a incité les SGBDR de dernière génération à intégrer au moins des fonctions d'importation/exportation d'XML et au mieux à stocker et gérer nativement les données XML.

Le datawarehouse ou entrepôts de données a trois principales approches : OLAP, MOLAP et ROLAP.

Ø Le concept OLAP (On Line Analytical Processing) repose sur une base de données multidimensionnelle, destinée à exploiter rapidement les dimensions d'une population de données. La plupart des solutions OLAP reposent sur un même principe : restructurer et stocker dans un format multidimensionnel les données issues de fichiers plats ou de bases relationnelles.

Ø Les outils MOLAP sont conçus exclusivement pour l'analyse multidimensionnelle, avec un mode de stockage optimisé par rapport aux chemins d'accès prédéfinis.. MOLAP agrège tout par défaut.  

Ø Les outils ROLAP superposent au dessus des SGBD/R bidimensionnels un modèle qui représente les données dans un format multidimensionnel.

Dans l'article « Une démarche de conception générique », Michel Chokron et M. Des Rochers [I.15] ont précisé que la technique de conception des ERP nécessite l'existence d'une architecture de base à partir de laquelle l'ERP et ses différentes options sont établis. Cette architecture de base devrait être le commun dénominateur de l'architecture des systèmes des entreprises clientes car ainsi on minimiserait l'effort de paramétrage.

Dans leur recherche, Losavio et al. [I.16], étendent un modèle conceptuel d'intégration d'outils CASE pour avoir une conception unique et cohérente au niveau des processus et des services dans une organisation. 

	Intégration montante	Intégration arrière			Intégration frontale
	"Upward"	Backward			"Forward"
Processus
Exemple :	Planification de l'approvisionnement	Approvisionnement			Approvisionnement avec les
Gestion de	de la haute direction	Pour les producteurs			fournisseurs, et vendeurs
l'approvisionnement
Services	. Systèmes d'aide à la décision	Outils CASE			. Systèmes de gestion
	. Systèmes à base de	Systèmes			des données clients
	connaissances	Patrimoniaux ERP			. Systèmes de gestion
	. Systèmes d'audit ou				des données fournisseurs
	d'assurance qualité				. Systèmes de e-commerce
					entre entreprise
					. Systèmes de e-commerce
					entre vendeur et client
Technologie	Matériel
	Logiciel
	BD
	Technologie de communication

D'un autre côté, dans l'article de Toussaint P.J. [I.17], l'intégration centrée sur les applications utilise deux groupes de technologies. L'approche Middleware applicatif qui est une démarche d'intégration fondée sur l'utilisation d'un Middleware consistant à modifier les produits existants pour permettre leur inter fonctionnement via une plateforme d'intégration.

Ainsi l'EAI assure trois fonctionnalités, en effet c'est à la fois : un service de connectivité des applications Middleware, un gestionnaire de processus workflow, un transformateur de données. 

Pour interconnecter plusieurs applications à travers les EAI, les web services ont des technologies telles que : SOAP, WSDL, UDDI, WSFL, WSCL, ebXML.

P. kellert et F. Toumani [I.4] ont montré que du point de vue technique, la description d'un web service inclut tous les détails nécessaires à l'interaction avec le service comme, par exemples, le format des messages, les signatures des opérations, le protocole de transport et la localisation du service. Les web services s'appuient sur des mécanismes et des protocoles standards et sont donc indépendants des langages de programmation (Java, J#, C++, Perl, C#, etc.), du modèle objet (COM, EJB, etc.) ainsi que des plates-formes d'implémentation (J2EE, .NET, etc.). 

Dans sa thèse sur « la conception d'une plate-forme électronique basée sur les rapports commerciaux de vente de produits de luxe », Nikia Filipovic [I.18] montrent les principaux protocoles, technologies et standards dans les web services

Ø The simple Object access Protocol (SOAP) combine XML et Multipart Internet Mail Extensions (MIME) pour créer un "extensible packaging format". Message SOAP peut être transporté par beaucoup de mécanismes de transport, comprenant http, SMTP et le transport traditionnel des messages.

Ø The Web Services Description Language(WSDL) est un vocabulaire XML utilisé pour décrire les Web Services. Il définit les opérations, les types de données et "binding information". Artefact.

Ø Universal Description, Discovery, and Integration (UDDI) fournit le modèle pour organiser, régistrer et accéder l'information sur les web services.

Ø The Web service Flow Language (WSFL) et le Web Service Collaboration Language (WSCL) sont concernés par la description du workflow entre les services, ainsi leurs rapports peuvent être encapsulés faisant la partie de l'application.

Ø Electronic Business XML(ebXML) fournit le framework pour e -commerce qui inclut le "inter-application workflow" et la description et la découverte des services. Il utilise le SOAP comme le mécanisme du transport mais n'utilise pas directement WSDL, UDDI ou WSFL.

Pour transporter les messages entre applications les MOM utilisent des technologies telles

que [I.19] :

Ø Le modèle de programmation des invocations distantes : l'entité appelante (client), avant de demander un service à une autre entité (serveur), doit connaître l'existence d'un tel serveur capable de satisfaire/exécuter sa requête et doit obtenir sa référence.

Ø Le modèle d'une architecture basée sur des événements : les composants coopèrent par l'envoi et la réception d'événements, un type spécial de messages. L'émetteur du message (la source) transmet un message à un aiguilleur de message qui se charge de le distribuer à tous les composants ayant déclaré leur intérêt dans la réception de ce message. Ce type d'infrastructure s'appelle souvent MOM (Message Oriented Middleware).

Modèles de programmation 

  Les solutions d'EII s'adossent à différents modes d'interfaçage pour s'affranchir de l'hétérogénéité technologique des serveurs de données de l'entreprise. Il peut s'agir de connecteurs (JDBC, ODBC ou encore JCA) ou encore de web services (interfaces SOAP/WSDL).

La transmission à l'application de données structurées selon un format normalisé peut se faire de diverses façons selon Lucy Bottomley [I.20] et les méthodes les plus couramment utilisées sont les suivantes :

Ø EDI direct ou point à point : L'EDI direct assure une liaison directe entre deux ordinateurs.

Ø Réseau à valeur ajoutée (RVA) : Le RVA met à la disposition de l'abonné une boîte aux lettres électronique permettant l'enregistrement et la retransmission des messages, et un certain nombres de services supplémentaires.

Ø Internet : Le réseau Internet constitue une méthode rapide et peu coûteuse à laquelle on pourrait éventuellement faire appel pour la livraison des messages par courrier électronique ou par transfert de fichiers.

Selon mounir Fegas [I.21], les documents XML sont représentés par un ensemble de leurs paths et sous-paths, qui sont classées par longueur. Cette représentation nous permet d'aplatir ces documents, tout en conservant leurs structures.

 Sur le plan conceptuel, un document XML a deux parties:

Ø le document proprement dit, obligatoirement présent,

Ø une description formelle optionnelle, appelée Document Type Definition (DTD).

Cette description contient les règles syntaxiques que doit respecter le document. Tout se passe comme pour un programme que l'on écrit dans un langage de programmation: le langage a une grammaire qui décrit les structures syntaxiques permises pour un programme et les mots réservés que l'on emploiera.

Les outils APL de Veys [I.22] utilisent une mesure de ratio d'interaction qui crée des domaines selon le degré d'échanges d'information de part et d'autre des fonctions. Elle comprend une étape d'analyse de l'organisation et de sondage auprès des utilisateurs sur les processus d'affaires, les classes de données et les unités organisationnelles. Cette méthode de conception d'architecture ne cherchait pas à créer un modèle générique. »

Le logiciel d'EAI offre par ailleurs [I.23] un ensemble de composants architecturaux qui facilite grandement les échanges entre les bases de données. Parmi ces composants figurent les services de transformation de données, la sécurisation et la fiabilisation des échanges, l'utilisation de connecteurs standard d'accès aux sources de données.

Dans leur recherche, Losavio et al. étendent [I.16] un modèle conceptuel d'intégration d'outils CASE pour avoir une conception unique et cohérente au niveau des mécanismes dans une organisation. 

Mécanismes
Architecture	Styles architecturaux	Patrons
	. Invocation par évènements	. Courtier
	. Niveaux en couche	. Réflexion
	. Dépôts d'archives	. Façade d'encapsulation
		. Intercepteur

L. Avignon et T. Brethes dans « Le livre blanc de l'EAI- Intégration des applications d'entreprise » [I.24] citent trois principales architectures EAI, par ordre d'importance décroissant dans les systèmes actuels qui sont :  

Ø Le transfert de fichier représente l'immense majorité des flux d'information. Quand deux applications communiquent, le premier mécanisme mis en oeuvre consiste à extraire une partie de l'information contenue dans l'application, puis, pour chaque destinataire, la formater et la transmettre.

Ø Les systèmes d'extraction orientés datawarehouse ( Extract -Transform-Load : ETL) constituent une avancée dans le domaine puisqu'ils prennent en charge la gestion d'un dictionnaire mettant en relation les données sources (qui peuvent être sous différentes formes : fichiers, bases relationnelles, etc.) et les données cibles du datawarehouse.

Ø Les systèmes de réplication SGBDR sont optimisés pour répliquer en mode fil de l'eau ou en mode batch des données issues de SGBDR.  »

L'architecture de référence des web services s'articule autour des trois rôles suivants [I.4]:

Ø Le fournisseur de service : correspond au propriétaire du service. D'un point de vue technique, il est constitué par la plate-forme d'accueil du service.

Ø Le client : correspond au demandeur de service. D'un point de vue technique, il est constitué par l'application qui va rechercher et invoquer un service. L'application cliente peut être elle-même un web service.

Ø L'annuaire des services : correspond à un registre de descriptions de services offrant des facilités de publication de services à l'intention des fournisseurs ainsi que des facilités de recherche de services à l'intention des clients. »

Client

Recherche/localisation

Lier ( bind)/connecter

Invovation

service/méthodes

Fournisseurs de services

Implémentation

Déploiement

Description et

publication

Annuaire de

Service

(e.g. UDDI)

2 - Rechercher WSDL

4 - Invoquer (SOAP)

1 - Publier (WSDL)

3 - Lier/

connecter

Architecture des services web

Philippe Laumay dans « Déploiement d'un bus à message sur un réseau à grande échelle » [I.25] montre qu'il existe trois types d'architectures qui assurent une modularité de déploiement des MOM sur n'importe quel type de topologie réseau et applicative :

Ø La topologie hub and spoke est une architecture centralisée représentée par un seul serveur représentant le MOM.

Ø La topologie snow flake est une architecture distribuée représentée par un ensemble de serveurs interconnectés (mais pas complètement maillés).

Ø La topologie en Bus est une architecture distribuée représentée par un ensemble de serveurs interconnectés à la manière d'un LAN (c'est à dire un graphe de serveurs complètement maillés). »

On peut citer trois types d'architecture MOM : Hub and spoke, Snow flake, Bus.

L'architecture hub and spoke est appelée ainsi car elle se présente comme une roue de vélo, où tous les rayons (spoke) sont reliés au même moyeu central (hub). Cette architecture est constituée d'un serveur principal unique qui centralise tous les messages .

L'envoi de message est très simple à réaliser, l'émetteur lance son message au serveur central (broker) puis celui-ci le transmet dans la boîte aux lettres du destinataire. 

Le deuxième type d'architecture est appelée snow flake à cause de sa topologie en flocon de neige (voir Figure ). Contrairement à l'architecture précédente, ici le gestionnaire de messages est distribué sur plusieurs sites. Le MOM est donc représenté par un ensemble de serveurs qui constitue le gestionnaire global, chaque serveur étant une partie (un sous-module, une subdivision, etc.) de l'ensemble. Lorsqu'un client (une application) s'adresse au gestionnaire de messages il s'adresse en fait à l'un des "serveurs de messages". L'émetteur envoi un message au gestionnaire de messages via un serveur appelé point d'accès, puis le message est transmis par le serveur soit directement au destinataire si celui-ci est associé au même serveur, soit à un autre serveur auquel est associé le destinataire. 

Dans le livre « MTS & MSMQ » de Alex Hormer et D. Sussman [I.26] et dans l'article « A case for Message Oriented Middleware » de G. Banavar [I.27], les auteurs disent que la topologie de l'architecture « Snow flake » permet de réaliser plus facilement une application à grande échelle. Dans l'architecture précédente, le passage à l'échelle était limité à cause du nombre restreint de clients associés à l'unique serveur gestionnaire de messages. Dans cette configuration, il est aisé de relier un grand nombre de serveur et de déployer les clients sur ces différents sites. Ainsi tous les clients ne s'adresseront pas toujours au même serveur.

P. Reiss a dans son article « Connecting Tools Using Message Passing in the Field Environment » [I.28] dit que l'architecture en Bus est la plus récente des architectures répartie, elle est employée dans les MOM les plus récents. Le modèle de bus à messages n'est pas forcément une architecture définie au niveau physique. Le bus logiciel est en fait une vision logique d'une architecture distribuée dont le but est d'acheminer les messages à leurs destinataires. La vision réelle de l'architecture d'un bus est une architecture snow flake qui serait complètement maillée.

L'architecture d'une solution EDI est constituée de 3 composants [I.29] :

Ø Le système d'information. Celui-ci représente l'ensemble des applications amenées à échanger des messages.

Ø Les logiciels EDI, ou traducteurs. Leur principal rôle est d'assurer la transformation des

données d'un format applicatif, propre à l'entreprise, à un format d'échange standard, reconnu

par le partenaire.

Ø Les interfaces de communication. Ceux-ci permettent l'envoi et la réception de messages EDI sous différents protocoles et sur différents réseaux.

XML (eXtensible Markup Language) est similaire à HTML (HyperText Markup Language), dans le sens où il utilise un système de balises ouvrantes/fermantes. Cependant, XML va beaucoup plus loin dans la définition des règles syntaxiques associées au langage, et constitue un langage stricte et standardisé pouvant être réutilisé et adapté aux besoins spécifiques d'applications.

XSL

WSDL

SOAP

UDDI

Web services

EAI

Quelques langages de l'univers XML

XQUERY

BPML

Les constituants de base d'un document XML sont les « éléments », et les « attributs » [I.30] .

Un document XML est dit `bien-formé' s'il respecte le formalisme XML (éléments-attributs) et les règles associées (encodage ...)

 Le Model Driven Architecture (MDA) [I.31] est une démarche de développement proposée par l'OMG. Elle permet de séparer les spécifications fonctionnelles d'un système des spécifications de son implémentation sur une plate-forme donnée.

Cécile Bourreau dans son mémoire « Développement sur l'ERP libre OfbizNéogia » explique que [I.32] l'utilisation de l'ERP est très marquée dans le monde industriel avec la gestion de stocks et de fabrication, mais également dans les activités tertiaires avec la gestion de commandes et les sites E-commerces. Actuellement le marché des ERP est dominé par des applications de type propriétaires tel que SAP, BAAN, ORACLE, etc. Cependant il immerge de nouvelles technologies basées sur les logiciels Libres comme les projets GNU Enterprise, Ofbiz ou bien Compiere.

L'intégration au niveau des processus métier, également appelée BPI ( Business Process

Integration), permet de concevoir des processus métier et de les relier aisément aux applications sous-jacentes.

L'intégration au niveau des applications est un bon départ en vue d'une exposition des API métier des applications en tant que web services.

L'intégration de la couche métier n'est cependant pas toujours une tâche aisée. En effet, toutes les applications ne fournissent pas des API métiers. La notion de couche n'existe pas et les seules interfaces qu'elles exposent sont constituées par des grilles d'écran.

  Pour mettre en évidence l'utilisation des web services, Mathieu Nicolescu [I.33] dit qu'une entreprise qui veut mettre en place un système de messagerie au sein de son intranet, voire par la suite Internet pourra donc opter pour la technologie des web services en développant le serveur de messagerie en web service .NET. L'avantage est que l'application cliente pourra être développée sous n'importe quel langage.

IBM a conçu une plateforme nommée  WebSphere Everyplace qui permet l'accès des utilisateurs mobiles aux données de l'entreprise. Cette plate-forme est conçue comme une extension du serveur d'application WebSphere qui intègre la spécification JMS. Parmi les points intéressants de cette technologie est sa capacité à fournir l'accès à des utilisateurs utilisant des protocoles de communications différentes ( GPRS, SMS, WAP, Wifi, Bluetooth ...). Everyplace utilise pour cela des services pour l'adaptation du contenu suivant les capacités et les formats de données pris en charges par les terminaux mobiles.

Pierre-Yves Fourmond [I.34] montre comment  les Middleware Orientés Message sont très utilisés dans le domaine de l'EAI (Enterprise Application Integration).

Les autres secteurs utilisateurs de MOM incluent, par exemple, le datawarehouse, les messageries inter-bancaires ainsi que la diffusion d'informations. 

L'EII est utilisé dans des projets impliquant la consolidation de données ( dans le cas de la relation clientèle ou plus généralement lors de la mise en oeuvre d'un portail d'entreprise. Il est encore utilisé dans le champ de la Business Intelligence (BI) - qui effectue des traitements divers (prédictifs, multidimensionnels, etc.) sur des données issues en général de systèmes internes variés - en vue de proposer des rapports de suivi de l'activité de l'entreprise. 

 Le développement des EDI est présenté comme devant apporter l'ouverture contrôlée des systèmes d'information internes aux communautés des professionnels du droit et aux grands partenaires de l'institution judiciaire, l'accès sécurisé en consultation et mise à jour aux bases de données (casier judiciaire, fichier national des détenus, statistiques), l'enrichissement des fonctions d'accueil et de renseignement, les moyens d'une mise en place d'un accueil de proximité, de juridictions spécialisées, de travail déporté, en accompagnement des décisions qui interviendraient au titre de la réforme de la carte judiciaire, et ceux d'une alimentation automatique du fichier de jurisprudence. 

Mounir FEGAS [I.21] illustre l'utilisation de l'intégration à travers Oracle qui proposera en 1999, avec Oracle 8i, une offre d'interopérabilité XML intéressante. On pourra stocker des documents XML dans la base de données, accéder à ses éléments, effectuer des conversions entre modèles XML et relationnel.

Dans son mémoire intitulé « Mise en place d'un système d'information décisionnel dans un environnement médical », A.S.T Sané comment l'intégration peut être utilisé dans le domaine médical en ces termes [I.35] « les besoins du corps médical en terme de reporting - requêtes, statistiques, analyse de données peuvent être vus selon deux grands métiers : la gestion., la recherche.

L'intégration en général pourrait être représentée sur le schéma ci-dessous

ERP5

Dans le site de ERP5, on peut trouver la définition suivante [I.36] « ERP5 est un progiciel orienté production (utilisé en industrie de production : automobile par exemple), il est édité par la société NEXEDI et est développé en langage PYTHON avec comme serveur d'application ZOPE.

ERP5 comporte 3 problématiques :

Ø Un modèle d'unification des flux informationnels de l'entreprise

Ø Un système de base de données d'objets actifs

Ø Un mécanisme de distribution des données fondé sur la synchronisation

La première problèmatique qui consiste en un modèle d'unification des flux informationnels (modèle théorique) comporte cinq concepts (classes) qui sont : Ressource (resource), noeud (node), mouvement (movement), élément (item), chemin (path).

Path (Chemin)

Planification

Approvisionnement

Resource (Ressource)

Argent

Matériaux

Service

Compétence

Item (Elément)

Logistique

Traçabilité

Node (Noeud )

Machine

Personne

Organisation

Movement (Mouvement)

Commande

Livraison

Transaction

Ordre de production

Modèle d'unification des flux informationnels

( modèle de gestion intégré ).

Une ressource (Resource) décrit une ressource abstraite dans le processus de gestion. Elle est un descripteur d'objets tangibles (matière première, papier, eau, électricité.) ou intangibles

( argent, compétence, temps ).

Un noeud (Node) définit l'identité d'un acteur d'un processus de gestion. Il peut aussi définir un lieu ou un emplacement qui peut recevoir une quantité de ressources et en recevoir. Il peut représenter une personne, une organisation, un stock, un compte, un atelier etc.... Il peut stocker ou transformer des ressources, exemple : dans un atelier de métallurgie, une matière première peut être transformer en un produit fini. Le stock est un type de noeud. Un compte bancaire peut recevoir de l'argent mais il peut aussi en donner.

La classe Node (Noeud) est l'une des plus importantes classes de ERP5.

Chaque noeud à une capacité et une capacité consiste en :

Ø Définir la quantité maximale de ressources qu'un noeud peut garder. Il est définit par un ensemble d'inéquations qui doivent être satisfaites par le stock. Chaque équation prend une quantité d'une ressource donnée comme variable et la capacité du noeud comme paramètre.

Ø Définir la quantité maximale ou minimale de ressource qu'un noeud peut produire. Il est aussi définit à travers un ensemble d'inéquations.

Exemple : Pour l'organisation au niveau noeud, il faut prendre en considération les mouvements qui viennent ou partent du noeud.

Ø un mouvement qui arrive au noeud augmente le niveau du stock.

Ø un mouvement qui part du noeud diminue le niveau du stock.

Ø un mouvement qui part du noeud et ne va nulle part est une consommation de ressource.

Ø un mouvement qui part de nulle part et arrive au noeud est une production de ressource.

Pour calculer le niveau du stock, il faut voire l'historique, ajouter les quantités sorties et soustraire les entrées.

Il existe la notion de méta noeud qui représente une collection d'autres noeuds. Par exemple une compagnie est un noeud, un projet est en même temps un noeud et une ressource.

Un méta noeud peut recevoir des mouvements en entrées et envoyer des mouvements en sorties comme un noeud le fait.

Le méta noeud est principalement pratique si l'on veut implémenter une organisation au niveau méta sans affecter les détails de l'organisation au niveau noeud. L'organisation de la compagnie devrait alors requérir un changement de source et de destination de mouvements à partir du niveau méta noeud à chaque fois qu'une organisation plus détaillée est requise.

Les méta noeuds sont une agrégation de règles pour des mouvements à côté du comportement habituel d'un noeud.

Une agrégation de mouvements de méta noeud consiste en un ensemble de mouvements qui sont reliés dans un noeud ou à un noeud qui ne sont pas contenus dans un méta noeud.

Le mouvement (Movement) décrit le mouvement de ressources entre deux noeuds en un moment donné et à une heure donnée. Par exemple, on peut avoir un envoi de matière première du stock vers le magasin; un mouvement autre mouvement peut représenter le transfert de l'argent d'un compte vers un autre.

Les mouvements peuvent inclure des sous mouvements générés par des règles de gestion (le coût pour l'obtention d'un mouvement entre noeud source et un noeud stock).

Les mouvements peuvent aussi être associé à d'autres mouvements à travers des causalités. La collection complète de mouvements avec des dates passées et des dates futures représente l'organisation complète de l'entreprise parce que les mouvements ont un commencement et une fin.

Toutefois, les mouvements sont des objets ERP5 de bas niveau. Par conséquent, les mouvements sont rassemblés ensemble dans des livraisons. Les livraisons sont des documents qui sont utilisés en pratique pour gérer l'organisation d'une compagnie.

La classe Movement permet d'implémenter un modèle ERP5 de comptabilité universel. Les instances de la classe Movement sont utilisées dans différentes situations.

Ø orders : ces instances utilisées comme objet documentaire pour définir des quantités dans des orders.

Ø deliveries : les mouvements suivent la trace de l`actuel transfert de ressources dans le passé (comptabilité) ou dans le futur (planning/ budgétisation)

Par exemple : Les objets suivants sont des orders:

Ø Bon de commande (document envoyé à un fournisseur quand il a besoin de marchandises).

Ø Ordre de vente (document envoyé à un client pour lui signifier la confirmation d'une vente).

Ø Ordre de production document envoyé à un magasin pour confirmer que nous avons besoin d'une opération ou d'un service).

Les orders permettent de décrire une cible, mais peuvent être utilisée pour compter la réalité d'un actuel transfert de quantité.

Les cas suivant ne sont pas des délivrances : une délivrance de monnaie entre deux comptes abstraits, une délivrance de marchandises expédiées, une délivrance de marchandises reçues, une délivrance de service, une délivrance de monnaie entre deux comptes réels

Le chemin (Path) correspond au chemin pour un noeud d'accéder à la ressource dont il a besoin éventuellement. Le prix et les profiles commerciaux peuvent être attachés à un noeud afin de définir le prix par défaut d'une ressource achetée à un fabricant donné.

Il peut aussi définir le chemin pour un atelier d'obtenir des ressources d'un stock. Un path a toujours une date de début et une date de fin. Le chemin peut aussi représenter la tâche attribuée à une personne dans un projet temporaire.

Dans certaines entreprises, en particulier dans les compagnies de services, les personnes sont attribuées à des projets pour une certaine période (consultation) ou les personnes sont envoyées à des clients pour une certaine période donnée (exemple : un centre de réparation d'ordinateur). Ces situations peuvent être représentées dans ERP5 par l'utilisation de Path temporaire avec une date de début et une date de fin données.

L'élément (Item) est une instance physique d'une ressource. Les mouvements de ressources sont décomposés en éléments ayant chacun un numéro de série.

Un mouvement peut être étendu en une série de mouvements traçables à travers des items. Les items permettent aussi de définir comment une quantité de ressources donnée est actuellement expédiée ou transportée (traçabilité d'une ressource). Exemple : colis, numéros de série d'items dans chaque conteneur.

La deuxième problématique consiste en un système de base de données d'objets actifs, au lieu de stocker des données dans une base de données relationnelle, ERP5 utilise la base de données Zope. On peut donc interroger la base d'objets ERP5 au moyen de requêtes SQL.

La troisième problématique est le mécanisme de distribution des données fondé sur la synchronisation, on trouve que le fonctionnement de ERP5 est distribué et permet la répartition des données sur plusieurs sites.

Ainsi la combinaison des trois innovations décrit en haut et le caractère libre de ERP5 forment son caractère générique.

Dans ERP5, le modèle abstrait inclut les notions de variations et de transformations qui permettent la mise en oeuvre de modifications complexes.

Les  variations  sont utilisées par ERP5 pour représenter les possibles modifications d'une ressource donnée : par exemple : couleur, la taille, la vitesse etc...

ERP5 a la possibilité de gérer plusieurs variations pour une ressource donnée. Par exemple : un ordinateur peut être construit avec 128 Mo ou 256 Mo. La notion de variations permet avec une simple description de ressources et une collection de paramètres optionnels pour définir des millions de variations d'un produit sans créer des millions d'enregistrements dans la base de donnée et sans avoir à créer un numéro de produit pour chaque produit.

Le variantage permet de parer à toute complication induite par la législation de chaque pays.

Les variations sont très pratiquées dans les industries telles que : les ordinateurs (taille mémoire, taille disque dur, vitesse processeur), costumes (couleur et taille), bus (couleur, moteur, options)

Les variations sont particulièrement utilisées pour définir des ressources complexes résultant de

transformations successives. Chaque transformation est représentée comme une collection de transformations.

Une transformation est utilisée pour représenter une ressource complexe fabriquée à partir de la transformation de plusieurs ressources. Plutôt que de suivre un modèle hiérarchique, ERP5 utilise un modèle de diffusion.

Ainsi, afin de d'implémenter le choix d'une ressource, l'équivalence de ressources permet de définir une ressource parmi un groupe de ressources. L'équivalence de ressources est très utilisée pour implémenter l'équivalence de classes de ressources obtenues à partir de plusieurs sources.

Les transformations dans le modèle ERP5 sont instanciées par les causalités de mouvements réels entre noeuds. La seule causalité qui existe dans un processus de fabrication complexe est la causalité résultante de la définition d'une transformation. En particulier, le stock qui est un type de noeud n'a pas de causalité.

Le contenu du modèle ERP5

Le système ERP est une base de données de documents qui contient une collection de dossiers dont chacun implémente un module de gestion.

Chaque dossier contient une documentation autonome et éventuellement des sous- dossiers.

L'expérience de ERP5 est basée sur la métaphore d'un gros fichier avec beaucoup de feuilles dont chacune contient toutes les infos nécessaires pour décrire le type de transaction ou de gestion d'un document. Les documents sont comme des objets simples avec peu d'attributs. Des objets pourraient agir comme des conteneurs afin de tenir d'autres objets simples.

Il existe une relation entre la gestion du contenu du modèle ERP5 et le modèle abstrait de ERP5.

ERP5 fonctionne avec un serveur d'application ZOPE, donc il est nécessaire de connaître le fonctionnement de ce serveur.

Nous donnons ci-dessous le tableau de correspondance des documents ERP5 et les objets instanciés à partir des 5 classes.

Classes		Objets
NODE	N	Node	Amount	Profile	MetaNode
MOVEMENT	M	Movement	Delivery	Order	Transformations
RESOURCE	R	Resource	MetaRessource
PATH	P	Path
ITEM	I	Item	Container	Tracking

Avantages

L'ERP5 a l'avantage de n'utiliser que cinq classes qui représentent le modèle de classe. Avec ce modèle, ERP5 représente toute l'entreprise sauf le coté gestion de la clientèle ( CRM).

OFBIZ

Le projet Ofbiz a été lancé en 2001, suite à une demande client, pour offrir une solution eCommerce. Le modèle de données est basé sur une référence, the Data Model Resource Book. Lui même issu de très nombreuses expériences clients. Dés le départ, les composants catalogue, acteur et commande ont été conçus pour être extensibles et s'adapter à des environnements complexes. Au fur et à mesure que les besoins augmentent, l'apparition d'autres composants devient une nécessité : Stock, GPAO (Production Service et Projet ), comptabilité.

Ofbiz est écrit en java et utilise une approche entité-relation par soucis de simplicité et de généricité au niveau de la couche de données Entity Engine. Aux liaisons qui existent entre les différentes tables.

L'entité dans Ofbiz correspond aux tables d'une base de données. Les entités sont représentées par des classes dont le stéréotype est « entity ».

L'attribut dans Ofbiz correspond aux champs de la table. L'association correspond aux relations entre tables.

Ce modèle a l'inconvénient de s'attacher plus aux données qu'à la dynamique du système. Pour pallier à cet inconvénient, un projet nommé Néogia dont l'objectif est de fournir des outils de génération permettant de développer des applications Ofbiz à l'aide d'une modélisation UML dont l'avantage est d'avoir une vision globale de l'architecture du composant à créer.

Ofbiz intègre les modules de gestion suivants : Supply Resource Management (SCM), Customer Relationship Management (CRM),  Manufacturing Resource Planning (MRP), Content Management System (CMS), eCommerce .

OfBiz (Open for Business) est un progiciel métier de gestion d'entreprise. Il est orienté

e-commerce et est organisé suivant un modèle client/serveur. Son interface graphique est séparée de la partie métier et utilise une interface de type web dynamique.

Son architecture est de type modulaire. Ces composants sont réutilisables et un composant est le plus petit élément de l'architecture OfBiz. Un composant peut fournir un ensemble de ressources permettant de construire une application OfBiz. Les ressources peuvent être un jeu de données, un modèle de données, des services, une application web ou du code java. L'architecture de OfBiz est composée de plusieurs composants. Ces composants regroupés entre eux forment un progiciel de gestion intégré et sont classés en trois niveaux d'abstraction (le framework, les applications de base, et les applications de haut niveau).

Cette approche composant a permis une meilleure réutilisation des composants logiciels, un développement modulaire plus rapide. Ce type d'architecture permet aussi de remplacer un composant par un autre dans le cas où il existe plusieurs implémentations différentes.

Ofbiz se décompose en deux parties : le serveur et les composants.

Ø Le serveur, ou base, propose un environnement d'exécution homogène et performant pour les applications qu'il fait tourner. Il fournit tout un ensemble de mécanismes de gestion de cache et de pools de connexions qui permettent une meilleure montée en charge et une meilleure réactivité du système.

Ø Les composants, quant à eux, représentent les plus petites briques logicielles gérées par le serveur. Ils fournissent un ensemble de ressources permettant de construire tout ou une partie d'une application Ofbiz. Ces ressources peuvent être : un jeu de données, un modèle de données, des services, une application web. Un composant est en général spécialisé pour une fonctionnalité donnée.

Le composant composant Entity Engine se charge de la gestion des données de tous les autres composants Ofbiz. Les données sont représentées selon un modèle entité-relation compatible avec des bases de données relationnelles. Le principal objectif de ce composant est d'éliminer tout code spécifique à la persistance des données dans un système transactionnel. Les deux principales caractéristiques de ce composant sont :

L'accès aux données via une interface unique, le « GenericDelegator ». supporte l'accès transparent à plusieurs bases de données.

Le « GenericDelegator » est le coeur de l'Entity Engine. Il est considéré comme une interface qui permet d'effectuer des opérations de création, d'enregistrement, de suppression, de recherche et de mise en cache des données. Les définitions des entités sont lues au démarrage du serveur et ce dernier vérifie leur validité et leur cohérence par rapport aux bases de données sous-jacentes. Si des différences existent, l'Entity Engine peut créer automatiquement les tables, les champs et les relations manquantes.

Le Service Engine est l'équivalent de l'Entity Engine pour les traitements des composants Ofbiz. Il permet de lancer des services sans avoir besoin de connaître leur localisation et leur implémentation.

Le ControlServelet est l'élément clé de la communication entre les utilisateurs et les applications web Ofbiz. Il est implémenté selon le modèle MVC ( Modèle-Vue-Controleur).

L'architecture de OfBiz en composants est représentée ci-dessous.

Comptabilité Générale

Comptabilité Analytique

Comptabilité Tiers

Trésorerie

Gestion Commerciale

Gestion Maintenance

Employé-Ressource

Humaine

Gestion Projet

Relation Client

Relation Fournisseur

Gestion du Service

E-Commerce

Catalogue produit

Gestion d'Achat

Gestion de Production

Article

Acteur

Ordre

Stock

Tâche

Comptabilité

Commun

Contenu

Services

Entity

ECA

Workflow

J2EE Container

SGBD

Java OS

Sécurité

Composants applicatifs de base

Composants applicatifs techniques

Composants techniques de base

Architecture de OfBiz détaillée

Les principales entités de OfBiz qui permettent la modélisation pour chaque composant sont :

Ø Content ou Contenu gèrent les documents. Cette entité est utilisée pour enregistrer et manipuler les contenus généraux et les bases de connaissances. Cette entité inclut la séparation de l'information et l'organisation des données utilisées dans les structures comme les arbres, les listes ou les maps d'objets.

Ø Security ou Sécurité : Cette entité sert à contrôler l'accès aux données. Elle inclut les mots de passe, les logins et les permissions. La gestion plus complète de la sécurité est réalisée par l'entité « Party » permettant à un groupe d'utilisateurs de voir et modifier certaines données, à un autre d'interdire tout accès ou encore de ne lui autoriser qu'un accès en lecture.

Ø Party ou Acteur : Cette entité peut représenter une personne, un groupe (entreprise, fournisseur, client ...). Un acteur a un rôle (client, fournisseur, employé etc...).

Type d'acteur

Groupe d'acteurs

Personne

Nom de la société

Raison sociale

NINIEA

------

Nom, Prénom

Adresse

Profession

--------------

Rôle d'acteur

Client

Fournisseur

Fournisseur

Organisation des acteurs

Un type de données en relation avec « Party » est le mécanisme des numéros de téléphone, adresses de courriels ou les URL.

Ø Product ou Produit : Cette entité contient les informations sur les produits (biens et services) commercialisés ou utilisés dans l'entreprise. Les biens peuvent être des matériaux bruts, des produits semi-finis ou finis. Product définit un produit et non l'instance d'un produit.

Pour cela il y a les éléments d'inventaire ou éléments du stock. Ceux-ci indiquent où un produit est entreposé, le statut du produit et un numéro de série ou une quantité disponible et une quantité dans le stock.

La figure suivante montre les relations entre les produits.

Types d'articles

Produits finis

Produits immatériels

Services

Matière première

Sous-ensemble

Mots-clef

Catégories

Références

Contenu

Emplacements

Stock

Magasins de stock

Caractéristiques

Attributs

Articles associés

Fig : Organisation des produits

Un produit peut être organisé en catégories ou en nomenclatures. Il peut appartenir à une catégorie et une catégorie peut être membre d'une catégorie mère. Un produit peut aussi être associé avec un autre pour donner des packages ou des variantes.

Les catégories de produits peuvent être associées à différents catalogues. Un catalogue de produit est un point de départ pour toutes les informations sur un ensemble de produits à commercialiser.

Plusieurs produits peuvent être associés à un produit comme peuvent l'être les coûts. Différents prix peuvent être définis pour différentes monnaies, différents stocks ou magasins et pour différentes périodes de l'année (période normale et période des fêtes de Noël pour les jouets par exemple).

Ø Order ou Commande : Cette entité permet de gérer les ventes et les achats et toutes les

informations relatives à une commande. Elle permet aussi la gestion des retours de marchandises.

Une demande pour un produit peut être suivie et être éventuellement transformée en nécessité qui peut être utilisé pour créer un « Work Effort » défini ci-dessous, qui va satisfaire le besoin. La demande faite, une demande de confirmation peut être établie qui, une fois acceptée par le client, peut être utilisée pour créer une commande. Une fois la requête satisfaite, une facture peut être créée à partir de la commande. Les factures font partie de la comptabilité (entité Accounting).

Une commande consiste en un entête et des lignes qui décrivent les détails et les ajustements (taxes, frais de ports, réductions et autres).

Type d'ordre

Vente/atcat

Suivi statut avec

le workflow

Paiement

- Compte client

- mode paiement

Lignes d'ordre

- Statut

- Calcul du prix

- Promotions

- Quantité

- .......

Acteur

- coordonnées

- destinataires

Expéditions

- Dates

- Transporteur

- conditions

Gestions des ordres

Réf. ordre n° xxx

Statut

date

Facturation-Paiement

Mode de paiement xxx

Acteurs

Coordonnées livraison

Données d'ordre commercial

Expédition

Transporteur

Condition

Date

Lignes d'ordres

Article Statut Quantité Prix Solde total

xxx xxxx 1 99

Total ligne

Frais d'expédition

999

99

TVA

99

Gestion des Ordres

Facility ou contact : peut être un bâtiment ou un emplacement physique ( stocks, magasins, docks, bureaux, pièces de bâtiments ). Un facility aura un contact associé comme une adresse et un numéro de téléphone.

Ce composant gère aussi la gestion dynamique des stock tel que l'inventaire, les mouvements de stock. L'inventaire du stock est réalisé par un ajustement des quantités réelles pour chaque ligne de stock.

Ø Shipment ou Expédition : Cette entité gère les réceptions et les expéditions ainsi que les entrées et sorties de stock. Un Shipment est composé de ShipmentItem, chacun représentant une certaine quantité d'un produit à expédier. Shipment fait aussi le lien avec les services des transporteurs pour le suivi des colis et des livraisons.

Ø Accounting ou comptabilité : Cette entité est organisée par date et sur les principes sur la comptabilité analytique et le plan comptable.

Clients

Compte client

Commande

Expédition

Acteurs

Rôle :

- Facture

-

Facture

Paiement

Limite de crédit

Terme de paiement

Coordonnées

Gestion de la Comptabilité

Ø Marketing : Permet de suivre les campagnes de marketing et les informations reliées tels les contacts (courriels, listes de diffusions ou téléphoniques).

Ø Work Effort ou Tâche : Elle est une tâche, une phase d'un projet, quelque chose à faire et même, une gamme (un processus semi-automatique qui implique des activités automatiques réalisées par la machine et manuelles réalisées par une personne ou par un dispositif externe contrôlé par une personne) ou une activité d'une gamme.

Une gamme est un type particulier de « Work Effort ».

Stock Stock

OF : ordre de fabrication

Découpe

Perçage

Assemblage

Sortie de composant entrée de l'article fabriqué Nomenclature

Lancement

o manuel

o proposition du MRP

(organisation des ressources industrielles )

GAMME DE FABRICATION

calendrier

Gestion de gamme

Ø Human Ressources ou Ressources humaines : Cette entité permet de gérer et de suivre les responsabilités, les compétences, salaires et autres informations en relation avec la gestion du personnel.

Avantages

L'avantage de OfBiz réside dans sa flexibilité. La disponibilité des sources et la possibilité de les modifier permet de l'adapter dans n'importe quelle entreprise. Son approche entité-relation permet la simplicité et la généricité au niveau de son entité Entity Engine.

Inconvénients

Les inconvénients de OfBiz résident sur sa lenteur, sa consommation mémoire astronomique (à cause de sa programmation en java/J2EE), et au nombre de tables. Son approche entité-relation s'attache plus aux données qu'à la dynamique du système. Il faut savoir que chaque composant utilise son modèle qui peut générer plusieurs tables qui seront reliées aux autres tables. Il y a beaucoup de tables ou des attributs qui sont inutiles.

COMPIERE

Compiere est un progiciel de gestion intégré ( PGI) et est fournie sous licence CPL ( Compiére Public License) une variante de la MPL ( Mozilla Public License). Il est entièrement basé sur le concept d'Active Data Dictionnary ( ADD) ou dictionnaire actif de donnée. Le dictionnaire de données de compiere contient les définitions des entités de données de base (type, validation, etc...), la manière dont elles sont visualisées ( étiquettes sur les écrans, rapports, aide, ordre d'affichage et position relative par rapport aux autres champs), de même que les règles d'affichage. Il contient aussi les règles de sécurité et d'accès.

Compiere est développé à l'aide de Java J2EE et peut être utilisée sur des bases de données telles que Oracle, MySQL, PostgreSQL et Sybase. Il utilise JBOSS comme serveur d'application.

Compiere est plus qu'un logiciel mais intégre un outil de développement qui permet de développer pour faire des changements, des personnalisations et de créer de nouveaux modules.

Compiere comporte plusieurs modules : gestion des ventes ( tarification, facturation, CRM) , portail de ventes ( gestion des catalogues gestion des tarifs et suivi des commandes), fonctions achats ( fournisseurs...), de stock et de logistique ( gestion par lots), comptabilité, finances, production, CRM, Gestion de projets, Gestion de la logistique.

Il gère plusieurs langues ( 15 à l'an 2004), plusieurs devises plusieurs plans comptables simultanément.

TINYERP

Tiny Erp est un progiciel de gestion intégré qui fournit une solution qui automatise les processus de l`entreprise suivants : Finance, gestion de caisse, achats et ventes, production, logistique, relation client et fournisseur. Il est spécialisé salles de vente.

Base

Marketing

Account

Contrats

Network

CRM

Product

Stock

HR

MRP

Purchasse

Sale

MRPII

Project

Cartes des modules de TinyErp

TinyErp est multi langue, multi compagnie, multi département, multi utilisateur. Il est flexible et fonctionne sur les plates fores GNU/Lunix et Windows.

Il est écrit avec le langage python et utilise postgreSsql comme gestionnaire de base de données.

TinyErp intégre un moteur de requêtes qui est utilisé pour le suivi de tous types de requêtes.

Comparaison des ERP

Ce tableau montre que pratiquement tous les ERP libres ont été développé avec des langages libres tels que python, XML, java/J2EE et Php. Ils sont implémentés sur des serveurs d'applications libres tels que Zope, Tomcat, Jboss, Apache et utilisent des bases de données libres comme ZODB, Mysql, Postgresql.

Parmi les ERP étudiés ici, il n y a que Compière qui utilise Oracle comme serveur

d'application et comme SGBD. Ce cas a été critiqué parce que Oracle est propriétaire et donc si on utilisait Compière, on était obligé de acquérir Oracle. Cette situation est maintenant gérée avec l'utilisation de Jboss et de Postgresql.

Compiere s'adresse davantage aux secteurs financiers et de la distribution (un module orienté manufacturing devrait cependant voir le jour).

ERP5 s'adresse par contre davantage à l'industrie manufacturière, avec une réelle capacité à gérer des nomenclatures complexes de produits.

Tiny ERP s'adresse aux salles de vente tandis qu'Ofbiz s'adresse au secteur du commerce avec son orientation e-Commerce.

Pour ce qui est des fonctionnalités, on voit que chaque ERP a une spécialité avant de s'étendre dans les autres secteurs de l'entreprise.

ERP			ERP5		OFBIZ		TINYERP		COMPIERE	ADROIT
Principale fonctionnalité			Production		Commerce éléctronique		Salle de ventes		Financiers et Distribution	Financiers et Dossiers
Editeur	ERP/PGI	Langage		Exemple Serveur d'applications		Exemple BDD utilisée		Fonctionalités
Nexedi/ Coramy	ERP5	Python		Zope		ZODB ( Zope Object Database)		Gestion production, Gestion financière, CRM, Chaîne logistique, E-business, Groupeware
Nereide	Ofbiz	XML		J2EE(Tomcat)		MySql		Gestion clients, Gestion fournisseurs Gestion employés, Gestion des articles, Gestion des stocks, Gestion des commandes Gestion de projet, E-commerce
Audaxis	Compiere	Java/J2EE		Jboss, Oracle etc...		Oracle/PostgreSql MySql		Gestion des ventes, Gestion des catalogues, des tarifs, Suivi des commandes, Gestion des achats, des stocks, Gestion de la logistique Gestion de la comptabilité, des finances
Tiny	TinyErp	Python		Jboss		Postgresql		CRM, Gestion Stocks, Gestion de la comptabilité Gestion de projet, Gestion des ventes, des achats. Gestion de la production, Gestion Ressources humaines, Marketing

Tableau de comparaison des ERP

ERP

Caractéristiques

	ERP5	COMPIERE	OFBIZ	TINYERP	ADROIT
Couverture fonctionnelle	X	X	X	X	X
Base de données unique	X	X	X	X	X
Adaptation et paramétrage	X	X	X	X	X
Architecture informatique ouverte	X	X	X	X	X
Présence d'outils d'aide à la décision	X	X	X	X

Tableaux de comparaison sur les caractéristiques des ERP étudiés.

MQ Series Integrator (Middleware asynchrone en mode message) : transforme, augmente, applique les règles de " message based data". Il transfert et distribue les données entre les différents systèmes.

C'est un outil qui permet l'intégration de nouvelles applications aux applications déjà existantes et cela même avec du contenu dynamique. Il permet de visualiser les flux des applications grâce au développement d'un environnement graphique.

E-biz Integrator : transforme automatiquement les bases de données dans n'importe quel format requis par le système informatique de l'entreprise. La technologie utilisée par e-biz Integrator assure le transfert des données critiques même si les programmes, réseaux ou SI sont en panne. E biz integrator permet l'intégration de n'importe quel environnement informatique quelque soit le matériel, l'OS, les logiciels, les bases de données et les protocoles de communications, utilisés. 

Agha G.A. [I.37] définit ScalAgent comme un exemple de réalisation d'un Middleware qui fournit un modèle de programmation de composants applicatifs adapté à la communication asynchrone et inspiré du modèle d'acteurs.

Dans l'article « Configuration de Middleware dirigé par les applications  - INRIA» Vivien Quema et Luc Bellissard [I.38] montrent que chaque composant applicatif de ScalAgent est créé et s'exécute au sein d'un représentant local du Middleware appelé serveur de composants. Celui-ci assure la création des composants, leur exécution et leurs communications. Il héberge une fabrique de composants et un bus local qui est composé de deux composants principaux. Chaque composant Middleware responsable d'une propriété non fonctionnelle possède un ensemble d'attributs qui lui permettent de fournir cette propriété.

L'environnement Calife permet la création de deux types d'automates [I.39]. Les automates simples, représentables sous la forme d'un graphe ; les automates composés par produit synchronisé d'automates. Par la suite, le terme automate désignera un automate simple et le terme block désignera un produit synchronisé d'automates (simples ou eux-mêmes crées par produit synchronisé). Le terme composant désignera indifféremment un block ou un automate simple.

L'entrepôt de données , baptisé Gedaw (Gene Expression DAta Warehouse), [I.40] intègre à ce jour les données expérimentales du groupe fer de l'Unité 522 (par l'intermédiaire de la création d'une base de données relationnelle Transcriptome) et intégrera à terme des données expérimentales d'autres équipes, des données pertinentes provenant de grandes banques publiques. Une fois intégrées, ces données vont être analysées à l'aide de requêtes et d'outils dédiés, développés localement et/ou importés des sites Web.

L'entrepôt de données Gedaw (Gene Expression Data Ware house)

Les objectifs de la réalisation de cet entrepôt sont doubles :

Ø Fournir aux chercheurs un outil complet et intégré facilitant ainsi l'accès aux données sur le transcriptome (analyse simple). Ceci correspond à une simple interrogation de la base de données.

Ø Permettre par le biais de ce même outil, de fournir une aide à la décision, permettant d'orienter les recherches biologiques.

Dans les travaux sur « La modélisation d'un entrepôt de données dédié à l'analyse du transcriptome hépatique », Guérin, Moussani et autres [I.41] ont montré que le GEDAW (Gene Expression Data Warehouse) est un entrepôt de données orienté objet qui permet l'intégration de ces données et d'autre part fournit des outils pour leur analyse, afin de mettre en évidence des corrélations entre gènes étudiés.

Les apports d'une intégration des données sont une garantie de la cohérence des données dans les deux systèmes, l'évitement des redondances inutiles et la possibilité de manipuler les données de manière transparente à partir des différents systèmes. 

La base de données unique d'un ERP permet les avantages immédiats suivants :

Ø une donnée est saisie une seule fois au moment adéquat et par le personnel adéquat ; on évite les redondances.

Ø une donnée peut être utilisée par n'importe quelle personne avec autorisation. Les données sont donc disponibles pour les différents modules applicatifs.

Ø optimisation des processus de gestion (flux économiques et financiers) ;

Ø cohérence et homogénéité des informations, intégrité et unicité du système d'information ;

Ø partage du même système d'informations facilitant la communication interne et externe ;

Ø maîtrise des coûts et des délais de mise en oeuvre et de déploiement.  

La valeur de l'EAI se situe à trois niveaux :

Ø l'EAI permet un accès universel et un partage de toutes les données et composants d'un système d'information, qu'ils soient normalisés, propriétaires ou incompatibles.

Ø l'EAI nécessite peu ou pas de modifications des applications ou structures de données qu'il intègre.

Ø une architecture EAI n'est pas figée. Elle constitue un socle évolutif, réutilisable et dynamique suivant en cela l'évolution des besoins métier spécifiques comme les évolutions structurelles de l'entreprise.

L'un des plus gros avantages des web services est qu'ils reposent sur des protocoles standardisés. Cela permet que cette technologie soit exploitable par de nombreux langages.

En effet, les web services se reposent sur les protocoles tels que XML et disposent en effet de fonctions pour lire un fichier XML ( Parseur XML). Donc un web service développé sous une plate forme .NET peut être utilisé via le langage Perl, PHP, Python, Delphi, Cobol .

Les web services sont la base de l'EAI. [I.42] contrairement à ce qu'on peut voir aujourd'hui, ils ne se limitent pas à la création de petits composants à destination du Web. C'est un véritable système de communication qui peut être utilisé pour l'intégration des applications. 

Le principe fondamental de fonctionnement des web services [I.43] est de morceler les applications et les processus d'affaires en morceaux réutilisables appelés « Service » de sorte que chacun de ces segments effectue une tâche distincte. Ces services peuvent alors servir à l'intérieur et à l'extérieur de l'entreprise, facilitant l'interopérabilité entre tous ces services.

D'après Pierre Yves Fourmond [I.34] , les Middleware Orientés Message, outre les services d'acheminement (envoi, réception), de stockage, et de recherche des messages etc ..., offrent des services plus évolués tels que :

Ø Rendre certains messages plus prioritaires que d'autres

Ø Compresser les données utiles du messsage

Ø Faire expirer un message à une date donnée et ne rendre un message disponible qu'à partir d'une certaine date (sur certains MOM uniquement).

Ø Des services de routage des messages d'un noeud à l'autre (un peu à la manière des serveurs de mails).

Ø Des fonctionnalités de triggering: lancement d'applications lorsque des messages sont disponibles pour elle.

Un autre avantage des MOM est qu'ils sont insensibles (au moins temporairement) à l'indisponibilité des applications, en ce sens que dès qu'un message est envoyé au MOM ou reçu par l'applicatif, cet applicatif peut s'arrêter, puisque la connexion entre l'application et le MOM n'est requise que pendant l'échange du message.

L'EII présente pour principal avantage de simplifier le travail de développement et de maintenance des applicatifs nécessitant l'intervention de bases de données hétérogènes. Il facilite le déploiement d'applications nécessitant l'accès à diverses bases de données, notamment en rendant plus simple le travail d'élaboration et de maintenance des requêtes.

Dans les travaux sur la classification des documents XML, Mounir Fegas [I.21] donne quelques apports de XML qui sont : la possibilité de structurer des documents quelque soit leur complexité - l'extensibilité, en définissant toutes les balises dont on a besoin - la validation, permettant de vérifier la conformité de la syntaxe d'un document par rapport à la grammaire générale du langage XML.

Dans son article « La connectivité des logiciels doit s'appuyer sur des standard afin d'assurer l'interopérabilité des systèmes, Olivier Grenet [I.14] explique que XML présente certains avantages. Il est auto-descriptif car les balises décrivent la structure et le type des noms des données ; il est portable puisque codé en Unicode, et il peut décrire les données sous la forme d'un arbre ou d'un graphe.

L'EDI comporte des avantages déterminants:

Ø il accélère les flux d'informations

Ø il supprime les erreurs de ressaisie et de recopie

Ø il permet l'intégration directe des données dans l'informatique du destinataire

Ø il préserve la confidentialité des informations

Ø il donne à l'expéditeur l'assurance que le destinataire a bien reçu le message. 

La conception d'un datawarehouse débouche naturellement vers une approche multidimensionnelle, donc sur la mise en place de cube qui va plus loin, encore, dans l'analyse des données. Cela permet que les données restituées soient : normalisées, de meilleure qualité, homogènes.

C'est des systèmes très lourds, lents et coûteux à la mise en oeuvre. Il y a aussi une sensation de perte d'autonomie et de pouvoir due au partage des informations, au décloisonnement des fonctions de l'entreprise et aux réorganisations.

Dans le livre « Making ERP a success, communications of the ACM - vol. 43» Scheer August-Wilhelm et Habermann F. [I.44] disent que les ERP requièrent beaucoup de ressources notamment en espace mémoire, les besoins de réseautique, et en coûts de formation. 

Les ERP / PGI ne sont pas exempts d'inconvénients :

Ø coût élevé ;

Ø lourdeur et rigidité de mise en oeuvre ;

Ø difficultés d'appropriation par le personnel de l'entreprise ;

Ø nécessité d'une bonne connaissance des processus de l'entreprise (par exemple, une commande d'achat et une commande de vente nécessitent deux processus différents;

Ø nécessité d'adapter parfois certains processus de l'organisation ou de l'entreprise au progiciel ;

Ø nécessité d'une maintenance continue 

Pour la plupart, les outils de EAI ne possèdent pas de fonctionnalités de workflow qui permettent de prendre en compte les interactions avec les utilisateurs.

Un inconvénient majeur des web services aujourd'hui est l'absence de vraie sécurité dans les normes officielles.

Dans son article, Pierre-Yves Fourmond [I.34] explique que l'inconvénient que l'on peut trouver aux MOM est précisément de devoir installer et configurer un composant logiciel supplémentaire pour faire communiquer plusieurs applications. On critique ensuite les MOM pour leur manque de standards. Cette critique n'est pas recevable dans la mesure où la plupart des MOM actuels implémentent tous l'interface JMS, qui est le standard pour la communication en mode message en Java.

. Dans le cas de l'EII, les requêtes multi-sources consomment beaucoup de ressources et les temps de réponse s'en ressentent.  En outre, l'EIIl ne dispose pas de fonctions pour transformer les données, il n'y a pas de fonctions de transformation et il y a peu de performances sur les requêtes complexes. 

Malgré le fait que la solution EDI Edifact permette de structurer les segments et les messages qui couvrent les besoins des entreprises dans leur échanges, il n'est que peu utilisé cela principalement pour les raisons suivantes :

Ø Les coûts d'une solution EDI. Dans la majeur partie des cas, les solutions EDI sont délivrés à travers un réseau à valeur ajoutée. Or les coûts d'installation, de transaction et de maintenance de ces réseaux sont trop importants pour les PME.

Ø Rigidité d'une solution EDI. Alors que les partenaires demandent de la flexibilité, l'EDI demande de leur part une formalisation très importante et un fonctionnement quasi-statique car les applications sont personnalisées et spécifiques.

Ø Absence d'interopérabilité. les solutions EDI sont souvent construites sur une base vierge et ne sont pas à même de partager les ressources avec des applications autres que celles initialement prévues. 

Dans l'article de Steven Song et Bellant [I.45], on peut voir la mise en évidence de l'une des faiblesses contre laquelle le langage XML ne fait rien au vocabulaire.

Olivier Grenet [I.14] cite Ronald Bourret qui énumère les faiblesses de XML: un stockage inefficace, les index, la sécurité, les transactions et l'intégrité des données, l'accès multi-utilisateur, les déclencheurs (triggers), les requêtes sur plusieurs documents, etc.

Les mises à jour globales d'un datawarehouse demandent un temps considérable. 

Les changements technologiques incluent le déploiement de tous les modules d'un ERP, et l'intégration de l'ERP avec les applications de l'entreprise. Cette approche pose des inconvénients : si les changements technologiques sont réalisés en même temps, il devient difficile de déterminer l'origine d'une panne technique qui entraîne des interruptions du travail des employés, enquêtes du coté des administrateurs système. 

L'EAI permettra à terme de créer des liens de plus en plus étroits entre les différents partenaires. Pour bientôt les applications EAI permettront la connexion avec des terminaux mobiles tels que les téléphones portables WAP, les assistants personnels, les ordinateurs portables et autres applications Peer to Peer et Wireless.

La notion d'EAI voisine donc avec d'autres concepts :

Ø avec les ETL : bien que différent dans son objectif, il assure comme un ETL, la connexion aux systèmes d'information et la conversion des informations,

Ø avec les workflows : puisqu'il assure le suivi des processus sur des systèmes pré-existants,

Ø avec le BPM à qui il peut fournir, comme l'ERP, une plate-forme opérationnelle idéale,

Ø enfin, avec les applications sectorielles (CRM, SCM...) qui exigent un minimum d'intégration des processus. 

Gilbert B.F. et Cirano M.L. [I.43] comparent les web services aux Middlewares en expliquant que fonctionnellement, les web services n'apportent rien de neuf par rapport aux Middlewares, conçus pour appeler des services distants, ou par rapport à l'EDI, qui décrit comment échanger des documents d'affaires. Cependant, la façon avec laquelle les web services réalisent ces fonctions est entièrement novatrice, découplant le service lui-même de son implantation. 

  En bref, la mise en place d'une solution EDI implique un haut niveau de technicité et exige une préparation soigneuse ; elle représente un certain investissement, et induit ensuite des coûts de fonctionnement qui, tout en étant très compétitifs par rapport aux transmissions par courrier, téléphone, télex ou fax, ne sont tout de même pas nuls. 

L'utilisation des composants XML, document XML et feuilles de style XSL est relativement facile grâce à des éditeurs XML. Toutefois, l'utilisation unique de ces composants limite l'application du langage à la création de pages HTML statiques. Pour avoir une solution dynamique, il faut employer un langage de programmation. 

Mohand-Saîd Hacid et Chantal Reynaud [I.46] dans leurs travaux sur « l'intégration de sources de données » expliquent qu'un datawarehouse répond aux problèmes de données surabondantes et localisées sur de multiples systèmes hétérogènes.

I. 2 Intégration par le modèle ADROIT

La bonne définition d'un modèle de données générique a été capitale pour ADROIT.

En effet, si une information de l'entreprise ne peut être gérée par le système, son efficacité est remise en question.

Il s'agit alors d'imaginer tous les cas de figure qui risquent de se présenter d'un domaine à un autre pour déterminer le niveau de généricité à mettre en place. C'est ainsi qu'une fois qu'il ait atteint un certain niveau de généralisation, la base de données résultante du modèle, sera utilisée pour l'intégration de ADROIT dans d'autres systèmes.

Le modèle de données de ADROIT est défini sur six (6) principales classes pour gérer toutes les informations de l'entreprise. Elles sont : Acte, Document, Rubrique, Objet, Informations, Tiers

Pour gérer les informations concernant le paramétrage et la gestion des accès du système on a définit trois autres classes, qui sont : Reference, Paramètre, User

Chacune de ses classes joue un rôle dans le dispositif conceptuel.

Ø La classe Acte

Cette classe est l'une des plus importantes de notre modèle. Elle regroupe les informations concernant un acte du système ; c'est-à-dire une FACTURE, un AVOIR, une CONSULTATION ou une HOSPITALISATION. Elle est identifiée par le « NumeroActe » qui est unique et surtout caractérisée par le « Type » de l'Acte. Il y a donc certains attributs qui sont spécifiques à certaines instances d'acte, ce qui prouve la prise en compte de tous les cas de figure.

Ø La classe Tiers

Cette classe renseigne sur les informations des Tiers concernés par un Acte. Elle est identifiée par le « NumeroTiers » et le « NumeroActe » auquel le Tiers se réfère et caractérisée par le « Type » du Tiers. Le Tiers peut être de type CLIENT, PATIENT, MEDECIN, etc.

Tiers

NumeroTiers : BigInteger

NumeroActe : BigInteger

Nom : Character

Type : Character

Adresse : Character

Pays : Character

Ville : Character

Telephone : Character

Boite Postale : Character

Email : Character

Rang : Integer

Supprimer()

Modifier()

Nouveau()

Ø La classe Objet

Dans cette classe, on définit les produits ou services gérés par l'entreprise. Elle est liée à la classe Acte et sert en même temps pour la gestion de stock. Les instances de cette classe sont surtout caractérisées par leur attribut « Type » qui peut être soit PRODUIT ou SERVICE.

Objet

NumeroObjet : BigInteger

NumeroActe : BigInteger

CodeSecurite : Character

Nom : Character

Type : Character

PrixUnitaireVente : Integer

Unite : Character

Supprimer()

Modifier()

Nouveau()

Ø La classe Rubrique

Cette classe fait plutôt référence au détail d'une instance Acte de Actes de nature FINANCE. Elle est aussi liée à la classe Objet.

Rubrique

NumeroRubrique : BigInteger

NumeroActe : BigInteger

CodeSecurite : Character

Type : Character

Nombre : Integer

PrixUnitaire : Integer

Base : Integer

TVA : Integer

Remise : Integer

Supprimer()

Modifier()

Nouveau()

Ø La classe Informations

Dans cette classe on regroupe toutes les autres informations concernant l'Acte ou le Tiers. Elle est identifiée par le « NumeroInfos » et le « NumeroActe » et caractérisée par le « Type » d'Information.

Informations

NumeroInfos : BigInteger

NumeroActe : BigInteger

Nom : Character

Type : Character

Valeur : Character

Rang : Integer

Supprimer()

Modifier()

Nouveau()

Ø La classe User

Cette classe contient les informations concernant les utilisateurs du système. Elle est utilisée principalement pour la gestion des utilisateurs.

User

NumeroUser : BigInteger

Type : Character

Code : Character

Nom : Character

Adresse : Character

MotDePasse : Character

CodeTypeUser : Character

DateMaj : Date

Telephone : Character

Email : Character

CodePostal : Character

Question : Character

Reponse : Character

Actif : Character

Nouveau()

Supprimer()

Modifier()

Rechercher()

Ø La classe Document

Dans cette classe on stock les informations concernant les documents joints à une instance Acte de la classe Actes. Elle est identifiée par le « NumeroDoc » et le « NumeroActe ».

Document

NumeroDoc

NumeroActe : BigInteger

Type : Character

Nom : Character

Nature : Character

NomComplet : Character

Supprimer()

Modifier()

Nouveau()

Ø La classe Parametre

Cette classe regroupe les informations de base du progiciel. Elle est indispensable pour le paramétrage et le bon fonctionnement du progiciel.

Parametre

NomProprio : Character

AdresseProprio : Character

Telephone1Proprio : Character

Telephone2Proprio : Character

FaxProprio : Character

PaysProprio : Character

VilleProprio : Character

NomIntegrateur : Character

NomApplication : Character

NomSociete : Character

AdresseSociete : Character

PaysSociete : Character

VilleSociete : Character

TelephoneSociete : Character

FaxSociete : Character

MessageBienvenue : Character

HoteBaseCons : Character

LoginBaseCons : Character

MotDePasseBaseCons : Character

HoteBaseServ : Character

LoginBaseServ : Character

MotDePasseBaseServ : Character

CodePostaleProprio : Character

CodePostaleSociete : Character

Modifier()

Consulter()

Ø La classe Reference

Reference

NumeroOrdre : BigInteger

Code : Character

Type : Character

Nom : Character

Nature : Character

Nouveau()

Supprimer()

Modifier()

Rechercher()

La classe Reference, regroupe toutes les informations concernant les Type d'Acte, Tiers, Infos, Document et les autres paramètres permettant de faciliter la saisie et les traitements des informations du système.

Diagramme de classe global indépendant

Informations

NumeroInfos : BigInteger

NumeroActe : BigInteger

Nom : Character

Type : Character

Valeur : Character

Rang : Integer

Supprimer()

Modifier()

Nouveau()

Rubrique

NumeroLigne : BigInteger

NumeroActe : BigInteger

CodeSecurite : Character

Type : Character

Nombre : Integer

PrixUnitaire : Integer

Base : Integer

TVA : Integer

Remise : Integer

Supprimer()

Modifier()

Nouveau()

Tiers

NumeroTiers : BigInteger

NumeroActe : BigInteger

Nom : Character

Type : Character

Adresse : Character

Pays : Character

Ville : Character

Telephone : Character

Boite Postale : Character

Email : Character

Rang : Integer

Supprimer()

Modifier()

Nouveau()

1..n

1..n

concerner1

Objet

NumeroProduit : BigInteger

NumeroActe : BigInteger

CodeSecurite : Character

Nom : Character

Type : Character

PrixUnitaireVente : Integer

Unite : Character

Supprimer()

Modifier()

Nouveau()

1..n

0..n

contenir

Document

NumeroDoc

NumeroActe : BigInteger

Type : Character

Nom : Character

Nature : Character

NomComplet : Character

Supprimer()

Modifier()

Nouveau()

Actes

NumeroActe : BigInteger

Code : Character

Type : Character

Nom : Character

Date Acte : Date

Description : Character

InfoSupp : Character

Nouveau()

Valider()

Supprimer()

Imprimer()

Créer()

1..n

1

concerner

0..n

1

concerner3

1..n

1

concerner2

0..n

1

concerner4

0..n

1

concerner5

concerner par

1

0..n

Ce diagramme représente les six (6) principales classes et les relations existant entre elles.

Modèle ADROIT

ADROIT est un logiciel créé par la société InformatiS. Auparavant conçu pour être un ERP, les concepteurs ont pensé le doter d'un système intégrateur pour en faire un système intégré.

Actuellement, [I .78] le modèle ADROIT est basé sur une approche d'intégration centrée sur les modèles. Cette approche a l'avantage de gérer l'interdépendance des plateformes, de permettre un accès temps réel et une interaction bidirectionnelle entre systèmes.

Par contre l'intégration centrée sur les modèles a des inconvénients comme la nécessité de modéliser tous les aspects (sources de données, utilisation des données, agrégation et insertion des données, le problème de maintenance), la problématique des cas où plusieurs structures doivent partager les modèles.

Etant un outil de gestion intégrée du système d'informations de l'entreprise, ADROIT vise des objectifs fonctionnels pouvant améliorer ces performances.

Pour modéliser les processus de traitement et de gestion des informations de processus, les événements, les relations de causalité et les informations elles-mêmes (entités, relations, états, etc...), on peut envisager les approches suivantes [I .78] :

- Intégration poste à poste

Cette approche permet l'accès aux informations détenues par les sous-systèmes au niveau des postes de travail. L'utilisateur réalise lui même son intégration.

L'intégration poste à poste peut se faire aussi en dotant les différents sous-systèmes de serveurs Web et permettre une consultation facile des informations à partir d'un navigateur. Dans ce cas, l'utilisateur décide de se connecter au serveur Web.

Les avantages sont :

o peu coûteuse malgré des développements supplémentaires

o facile à mettre en oeuvre

o la notion de portail d'accès donne une vision intégrée des services offerts

Les inconvénients sont :

o aucune interopérabilité entre les sous-systèmes

o pas d'automatisation des processus de traitement d'informations

o traitement d'informations par l'utilisateur

o pas de contrôle de cohérence de la part du système

- Intégrations au niveau données

Les systèmes orientés datawarehouse tels que EII, les ERP non modélisé, les EDI et les systèmes de réplication permettent de faire une intégration centrée sur les données.

Cette approche offre aux utilisateurs un entrepôt de données virtuel sans déplacement de données capables de fonctionner en mode événementiel

- Intégration au niveau application

Cette approche pourra être mise en oeuvre à travers les EAI, les Middleware applicatifs, par workflow ou par BPM (Business Process Management - gestion des processus métiers).

Cette intégration permet de réduire la redondance, améliore la cohérence des informations entre les différents systèmes. Elle est extensible et grâce au workflow et au BPM, on peut respecter l'architecture et les développements déjà réalisés.

Son coût s'avère élevé (modification des sous systèmes existants, développement d'adaptateurs pour les applications à intégrer. Sa véritable traduction syntaxique et sémantique des informations entre les dialectes locaux et le langage commun le rend complexe.

- Intégration par les web services

Les web services permettent à un système d'offrir à d'autres systèmes d'intégrer ses informations à leur processus. Ils s'appuient sur un langage ouvert (XML et dérivés) et fonctionnent avec les EAI qui en sont un élément de base.

Les avantages sont :

o simplifie le partage d'informations

o diminue le coût de l'activité et augmente la souplesse

o offre une meilleure visibilité des activités internes et externes

o permet de coordonner plus efficacement les processus répartis entre

plusieurs systèmes, services et entités.

Les inconvénients sont :

o Solution pas complète d'intégration des flux métier

o adaptation pour des interactions et des volumes de transactions faible

o sécurité limitée s'agissant d'ouverture se session à des tiers à travers

internet.

o pas d'architecture événementielle pour de nombreuses interactions entre les web service

o problème de gestion de la cinématique d'appel des différents web

services.

L'analyse de certains outils d'intégration nous a permis de choisir ETL et EAI en tenant compte des avantages et des inconvénients de chacun.

L'utilisation de ces deux outils nous permettra de répondre immédiatement aux demandes des clients.

L'EAI a des mécanismes d'acheminement des données en temps réel mais ne sait pas transformer les données.

L'ETL est une technologie capable apporter de la cohérence aux données, de transformer et de les consolider dans un datawarehouse.

I.3 Critiques

En générale, l'intégration des systèmes d'informations pose un problème de choix technique vue la limite des techniques à répondre à toutes les questions du décideur

Depuis leur détermination à vouloir mettre en place un système capable de subvenir aux besoins de l'entreprise industrielle, les concepteurs de ERP5 ont introduit les notions de transformation et de variantage dans leur système. Cette initiative a beaucoup joué dans l'espérance de performance souhaitée de ERP5.

Selon Eric Darras, ERP5 est plutôt un progiciel sectoriel qu'un PGI générique en considérant qu'un ERP est sectoriel lorsqu'il est dédié à un secteur spécifique

Les inconvénients de OfBiz résident sur sa lenteur, sa consommation mémoire astronomique (à cause de sa programmation en java/J2EE), et au nombre de tables. Le modèle Entité-Relation de Ofbiz a l'inconvénient de s'attacher plus aux données qu'à la dynamique du système.

Le modèle de données de ADROIT comparé à ERP5 gère la transformation (un produit peut être transformé ou être obtenu à partir de la transformation de plusieurs autres produits) et le variantage (un produit peut avoir plusieurs variantes, par exemple : chaussure taille 12, chaussure taille 20, chaussure taille 23) par le principe du clonage (faire une copie d'un objet et y apporter des modifications).

La classe Acte (contient les actes) peut représenter la classe Movement (définit les mouvements de ressources) dans ERP5. Dans la classe Acte, on retrouve un montant qui peut être un prix, une taxe, un montant d'une rubrique de salaire etc...Mais un problème se pose si un fournisseur (type de tiers) a un profil qui lui permet de vendre à un prix préférentiel ou un client qui doit acheter à un prix préférentiel.

La classe Tiers correspond à la classe correspond à la classe Node de ERP5. Les deux classes ont le même contenu à la différence que dans ERP5, le Stock est un type de Node.

La classe Rubrique correspond à la classe Resource de ERP5. L'ERP ADROIT intégre le prix du produit ou du service alors que dans ERP5, il est prévu la possibilité d'avoir plusieurs prix ou des variations pour une ressource. La classe Ressource du modèle ERP5 contient des objets Profile et Catégorie qui permettent de gérer les prix, les conditions d'achats et de ventes et le variantage. Un produit peut être transformé ou être obtenu à partir de la transformation de plusieurs autres produits donc il y a la notion de transformation qui n'est pas gérée dans l'ERP ADROIT.

L'historique est une fonctionnalité qui a des limites dans ADROIT car l'historique des prix des articles en stock n'est pas pris en compte (dés que le prix d'un article change, il est remplacé et n'est stocké nulle part).

Au niveau des classes, on voit que la classe Informations ne prend en compte que les informations de l'Acte et du Tiers alors que l'Objet peut avoir des informations.

Dans la classe Acte, on retrouve un montant qui peut être un prix, une taxe, un montant d'une rubrique de salaire etc...Mais un problème se pose si un fournisseur (type de tiers) a un profil qui lui permet de vendre à un prix préférentiel ou un client qui doit acheter à un prix préférentiel.

La classe Objet ne permet pas effectivement de prendre en charge les différents prix et les conditions de ventes ou d'achats qui peuvent lui être affectés suivant des profils Tiers bien définis.

I.4. Propositions d'amélioration du modèle d'intégration de ADROIT

L'objectif d'un logiciel, en général, est l'automatisation des tâches auparavant manuelles. Une application informatique est appelée à évoluer au rythme de la technologie et de l'importance des informations gérées.

Pour faire de ADROIT un système intégré capable de prendre en compte les autres logiciels ou de pouvoir intégrer d'autres systèmes, nous avons pensé à proposer trois approches intégratives.

Intégration au niveau des données : Les données sont transmises avec des transformations éventuelles.

Intégration au niveau application : Utilisation d'API métier (web services) pour transférer ou intégrer les flux de données).

Intégration au niveau processus : Orchestration d'un ensemble de tâches à effectuer par différentes applications

Pour atteindre cet objectif visant à assurer l'intégration des données, nous avons proposé les outils EAI et ETL ( Extract Transform, Load ).

L'EAI est un bus inter-applicatif qui fonctionne en mode synchrone et traite des charges importantes de données mais n'a pas de fonctions de transformations.

EAI

NT

NT

NT

NT

NT

NT

Intégration avec un EAI

Extract

Extract

Extract

Transform

Load

Datawarehouse de ADROIT

L'ETL extrait, transforme les données et les charge dans une nouvelle base de données. Une seule base de données est interrogée par l'outil de restitution. Il fonctionne en mode asynchrone et n'est pas flexible aux modifications. On peut considérer l'ETL qui permet d'alimenter un datawarehouse peut être considéré comme un sous ensemble d'EAI.

Fonctionnement d'un ETL

Le but de l'extracteur est de prélever le flux de données. L'extraction peut se faire de deux manières (totale ou incrémentielle).

La fonction de transformation permet de supprimer des données de mauvaises qualité (incomplètes, aberrants, doublons, obsolètes etc ...).

Une fois un ensemble homogène obtenu, le chargement (Load) consiste à injecter de manière correcte les données dans le datawarehouse et les rendre disponible.

L'intégration au niveau des données 

Pour atteindre cet objectif visant à assurer l'intégration des données, nous avons proposé les outils EAI et ETL (Extract Transform, Load).

La transformation de l'information est assurée par les services de transformations. Avec ces deux outils, la sécurité et la fiabilité des informations et des échanges sont traitées. L'utilisation de XML et/ou des web services par l'intermédiaire de l'EAI permettra aux applications concernées par l'intégration de se connecter.

L'échange direct entre bases de données par l'intermédiaire de l'EAI court circuit la couche métier (les règles de gestion implémentées ne sont pas vérifiées). On pourra parer à ce

problème en dupliquant les règles de gestion dans l'outil EAI mais on aura un autre problème de maintenance dû à l'évolution du logiciel.

Pour faire une intégration efficace au niveau des données, il faut une connaissance parfaite et détaillée des schémas internes de bases de données mis en jeu.

Nous proposerons de faire un datawarehouse (entrepôt de données) pour permettre à l'ETL de charger les données extraites de diverses sources. L'utilisation de l'ETL est limitée par le fait qu'il ne donne pas la photographie en temps réel des données.

L'intégration au niveau application

L'application ADROIT ne contenant pas d'API (points d'entrées d'intégration applicative), donc il faut faire d'abord une structuration. La modification de l'application ne doit pas nécessiter la modification de l'API métier. Le mode asynchrone court sera utiliser pour permettre à l'EAI d'appeler l'API en mode synchrone.

Les couches de l'EAI seront :

- Transport (transporter les infos ou les messages entre les applications connectées. Elle s'appuie sur la couche transport du modèle OSI.,

- Connecteurs (responsable de la connectivité entre applications)

- Transformation (fournit les services de conversion pour permettre le dialogue

- Routage (assure la gestion des flux entre applications),

- Processus métier (gère la logique de l'enchaînement des tâches)

Il y aura d'autres couches dont les fonctionnalités sont transverses :

- Paramétrage (adapte les principales couches)

- Développement (permet d'ajout des fonctionnalités)

- Administration (gère l'ensemble de la solution technique et fonctionnelle)

- Reporting (fournit les infos décisionnelles)

- Sécurité (règles les problèmes d'authentification, d'intégrité, de confidentialité)

Pour ADROIT, nous proposons l'architecture du système centralisé (Hub and Spoke). Aucun flux d'informations ou de données ne pourra se faire sans l'entremise du hub.

L'intégration au niveau processus

Cette intégration est fonctionnelle au niveau de l'application. Le BPI (Business Process Integration ou processus d'intégration d'affaires) se charge de gérer automatiquement le code nécessaire aux interactions entre les actions élémentaires et les instructions permettant au moteur d'exécuter les processus.

Pour permettre une bonne intégration, nous avons proposons ce modèle ci-dessus. Il diffère de l'ancien modèle par la liaison entre les classes Objets et Informations. Nous considérons qu'à l'instar des classes Actes et Tiers, la classe Objets peut avoir des informations.

Par exemple : Une CHAISE a plusieurs caractéristiques telles que la taille, la couleur, poids etc...

Nouveau modèle ADROIT proposé

II. Généricité

II.1 Etat de l'art

Le mot générique est à la mode, il sous entend réutilisation possible, simplicité d'utilisation et unification.

L'introduction de la notion de système générique a permis une adaptation des logiciels aux besoins de l'utilisateur.

Un système générique doit fournir :

Ø un modèle de données

Ø une interface utilisateur entièrement paramétrable.

Pour avoir une application générique, il faut certains principes sui sont :

Ø paramétrage sur les types

Ø paramétrage sur les structures, méta modèles ( c'est à dire en dehors du modèle)

Les PGI sont caractérisés par la généricité des fonctionnalités qu'ils proposent et disposent. Ils utilisent une seule base de données pour l'ensemble des données relatives aux fonctions de l'entreprise

Plutôt que d'ignorer le contexte d'exécution ou de tenter de le masquer par des couches d'abstraction (intergiciel), nous pensons que les applications doivent avoir un caractère générique.

Du point de vue de la technologie, la généricité est une promesse d'économie de moyens, et de réutilisabilité.

Pour montrer l'impact du paramétrage dans la généricité, Pierre Crescenzo dit que [I.52] la généricité regroupe traditionnellement les problèmes de variabilité et ceux d'adaptation à un domaine ou un rôle spécifique. La spécification de modèles, notamment métiers, implique la prévision de différentes variantes d'une même entité pour définir des lignes de produits. En d'autres termes, certaines entités d'un modèle métier sont génériques et cette généricité doit permettre une variation aussi bien structurelle que comportementale des entités.

II.1-1 La généricité par les modèles

Selon Mathieu Lafourcade [I.1], la conception et la programmation orientée objet sont imposées comme des modèles de programmation générique mais on peut voir derrière ce terme de programmation générique l'utilisation des patrons de classes.

Les patrons de classes permettent d'atteindre des niveaux de paramétrage et de factorisation des modèles orientés et du code qui restent hors de portée des seuls concepts de l'objet.

L'utilisation des patrons de classes ne se limite pas à la réalisation de conteneurs génériques. La spécialisation est l'opération qui consiste à utiliser un patron en renseignant ses paramètres de généricité. Les classes ainsi construites peuvent être utilisées par du code exécutable.

L'avantage d'un logiciel générique réside dans la réduction des coûts et des risques par contre on trouve ses inconvénients dans la nécessité de réorganisation des processus métiers, la diminution de son avantage concurrentiel et la perte de contrôle total.

Philippe Dosch [I.47] écrit dans son document « Introduction à la conception objet et à C++ » que la généricité permet de définir des modules paramétrés par le type qu'ils manipulent. Un module générique n'est alors pas directement utilisable : c'est plutôt un patron de modèle qui sera « instancié » par les types paramètres qu'il accepte. Cette notion est très intéressante, car elle va permettre la définition de méthodes (façon de travailler) plus que de fonctions (plus formelles). Elle permet de définir des modules paramétrés par le type qu'ils manipulent.

Si la généricité est le moyen de réaliser l'interopérabilité de façon efficace et évite l'explosion combinatoire liée au support de multiples personnalités, la variabilité est définie comme la capacité d'un système à être changé, personnalisé et configuré en fonction d'un contexte spécifique [I.50]

La généricité n'existe pas dans le code compilée, au niveau de la JVM. Cela entraîne quelques restrictions dans son usage.

La généricité a pour seul effet de changer des types pour les variables et méthodes d'une classe. Ces types sont connus une fois la substitution des paramètres effectuée, c'est `a dire dans le code qui utilise la classe paramétrée.

Dans une démarche de conception d'un modèle générique, Michel Chokron, Mireille Des Rochers [I.15] dit que le concept de modèle générique est apparenté à celui d'architecture des systèmes d'information de l'entreprise ou de cadre («framework») de développement des systèmes. Une architecture des systèmes est le regroupement, à l'aide d'un critère donné, des entités et des activités en domaines et des liens entre ces derniers. En général, chaque domaine est sujet au développement d'un système d'information. Un modèle générique est une architecture des systèmes qui peut s'appliquer à un ensemble donné d'entreprises.

Au niveau des systèmes multi-agents, Maher EL'ARBI, Ahmed HADJ KACEM, Mohamed JMAIEL [I.64] montrent que la généricité des modèles et des outils doit donc s'imposer afin d'évoluer vers la réutilisation.

Selon Eric SARDET [I.56], l'approche orientée objets propose une solution pour permettre un accès à des propriétés à un niveau intermédiaire d'une hiérarchie de classes au moyen du mécanisme de factorisation/héritage. Cette approche consiste à redéfinir une propriété ne pouvant être factorisée au niveau d'une famille générique, car ne participant pas à la description de toutes les sous-classes de cette classe générique, dans toutes les classes où elle est effectivement utilisée.

Pour Philippe Dosch [I.47], le concept de généricité permet encore d'accroître cette

abstraction, en proposant des classes qui sont paramétrées par des types de données ;

- extensibilité : les classes sont définies en terme de services. Dès lors, un changement de représentation interne de données ou une modification de celles-ci n'altère pas la façon dont les autres classes les utilisent.

- lisibilité : l'interface (documentée) permet d'avoir un mode d'emploi clair et précis de l'utilisation d'une classe, qui est d'autant plus clair que l'implantation des classes est cachée.

La notion de généricité permet de paramétrer les fonctions et les classes par un type de données.

Pour Frédéric Gava [I.58], avec le polymorphisme objet, on pouvait notamment mettre dans un conteneur différents objets de type différents s'il avait un type père (commun). Mais il était difficile d'exprimer le fait que l'implantation du conteneur ne dépendait pas des objets contenus. Pour cela, il fallait passer soit par un »objet abstrait» (avec les méthodes qui sont utilisées) soit directement par le type Object. La généricité va remédier à ce défaut afin d'exprimer plus concisément ce genre de problèmes (on parle d'expressivité).

Pour Hyacinthe Choury [I.57] la généricité d'un service doit permettre sa réutilisation sans excès. L'approche orientée objets propose une solution pour permettre un accès à des propriétés à un niveau intermédiaire d'une hiérarchie de classes au moyen du mécanisme de factorisation / héritage. Cette approche consiste à redéfinir une propriété ne pouvant être factorisée au niveau d'une une famille générique, car ne participant pas à la description de toutes les sous-classes de cette classe générique, dans toutes les classes où elle est effectivement utilisée.

Selon Mathieu Lafourcade [I.1] dans sa thèse « Génie Logiciel pour le Génie Linguiciel », la généricité est obtenue d'une part au niveau du modèle en permettant l'ajout de nouveaux types et opérateurs. Cette généricité est obtenue d'autre part au niveau des représentations symboliques: elles ne sont pas fixées et il est donc possible d'en ajouter autant que nécessaire tant que les interfaces sont respectées.

Dans la thèse intitulée «Vers un environnement générique d'aide au développement d'applications interactives de simulations de métamorphoses », Fabrice DEPAULIS [I.59] dit qu'à partir d'une application générique, l'utilisateur peut construire de nouvelles fonctions en se basant sur celles existant et les inclure dans la présentation de sa nouvelle application ...Une classe générique est chargée de représenter le « support de programme ». Il s'agit d'identifier, dans la structure de données, le point de départ du parcours de la structure.

Mathieu Barcikowski [I.51] dit que l'un de nos objectifs d' une démarche générique pour l'adaptation des interfaces dans les applications Web est de fournir un système générique. Cette généricité commence par le langage de description des modèles qui permet de représenter selon un même formalisme le modèle usager, de groupe et de contexte. [...] Le modèle usager [...] qui permet de stocker, de modifier et de fournir des informations sur l'environnement dans lequel se déroulent les interactions, sont des services disjoints avec le service d'adaptation fourni par notre système.

Dans son mémoire de DEA intitulé «Une démarche générique pour l'adaptation des interfaces dans les applications Web», Mathieu Barcikowski explique que [I.51] le modèle de contexte est un modèle adaptatif. [...] Le langage de description de modèle est composé de quatre éléments, qui sont les modèles, les sections, les objets et les attributs. [...]

Les modèles permettent de séparer les informations selon l'utilisation auxquelles elles

sont destinées.[...] Les sections permettent d'organiser de manière arborescente les informations

contenues dans les modèles [...] Les objets représentent les différentes catégories d'informations qu'il est possible d'utiliser lors de l'adaptation. Les objets sont décrits par un ensemble d'attributs qui les qualifient. [...] Les attributs fournissent les valeurs qui seront demandées et utilisées lors du processus d'adaptation, et modifiées lors de l'interprétation des actions de l'utilisateur.

Une interface, quelle soit adaptée ou non, a pour but de présenter des informations à l'utilisateur.

Le problème de la représentation des données à afficher se pose alors. L'approche systèmes adaptatifs [...] permet surtout d'adapter la navigation et rend l'adaptation du contenu et de la présentation plutôt difficile à réaliser. [... ] Les systèmes plus récents utilisent une approche par fragments qui permet de bénéficier, en plus d'une adaptation de la navigation, d'une adaptation beaucoup plus fine qui peut porter à la fois sur le contenu et la présentation.

Georges-Louis Baron et Éric Bruillard [I.60] ont expliqué que la relation étroite entre connaissance et représentation soulève la question de la généricité des modèles que l'on peut construire. [...] du point de vue de la technologie, la généricité est une promesse d'économie de moyens, et de réutilisabilité. Le rapport entre spécificité et généricité des modèles est en fait une question fondamentale que nous devons aborder comme telle, c'est-à-dire avec méthode et en cherchant un encadrement théorique du débat qui permette de rendre plus objectif son issue.

Bertrand Marquet et Laurent Ballester [I.53] ont montré que l'approche générique mise en place consiste à appréhender de manière globale le domaine par un modèle générique s'appliquant à la fois sur les exigences du domaine et sur le système proprement dit. La méthode fait apparaître deux grandes étapes : La première consiste à décrire une solution générique sur la base des besoins des utilisateurs des systèmes , des technologies à supporter (bien que, en toute théorie, le modèle devrait être indépendant des technologies) et enfin des normes en vigueur ; la seconde étape consiste à appliquer cette solution générique d'une part à un cadre spécifique en considérant le domaine applicatif.

Pierre Crescenzo, Philippe Lahire, Emanuel Tundrea [I.52] parlent de la généricité paramétrée en expliquant que le concepteur d'un modèle métier doit tout d'abord identifier les différentes entités du domaine modélisé et établir le degré de généricité de chaque entité. Il commence par décrire les entités qui ne sont pas génériques.[...] Pour les entités génériques, le concepteur définit une métaclasse générique et y décrit des paramètres et des caractéristiques qui vont permettre de faire varier la structure et le comportement de ces entités. Ils sont respectivement définis comme des instances des classes .

Selon Mathieu Barcikowski [I.51], le processus d'adaptation [...] consiste à générer une description abstraite d'une interface au moyen d'un langage de description de l'interface. Cette génération s'effectue en fonction du modèle usager, de groupe et de contexte, des fragments et en fonction des templates, mais aussi consiste à traduire l'interface décrite de manière abstraite vers une description concrète utilisant le langage utilisé par le terminal de l'utilisateur. »

Pour avoir un haut degré de généricité, [I.54] les approches orientées modèles, telles que MDA (Model Driven Architecture), prônée par l'OMG , deviennent intéressantes. Ces approches de développement sont souvent appelées "prototypage par raffinements" (evolutionary prototyping) [I.12]. Le principe est de concevoir le système en utilisant un modèle exprimé dans un langage dédié au domaine d'application visé (ici, les systèmes répartis).

II.1-2 La généricité par les composants

Un système générique est décrit par Chouki Tibermacine [I.48] comme un certain nombre de composants. Le mode de communication et de coordination entre ces composants est encapsulé par des connecteurs. La configuration du système est représentée par un assemblage de composants par le biais de connecteurs.

Pour mieux appréhender l'importance des composants dans la généricité, Tarak Chaari et Frédérique Laforest disent que [I.55] pour la généricité, un composant doit fournir des services utiles, conformes à l'usage courant de l'entité qu'il modélise ; l'adaptation d' un composant générique aux besoins spécifiques d' une application doit coûter moins cher que le développement d' un composant spécifique.

Cauvet C., SemmakF. [I.61] ont dit que le développement à base de composants repose sur deux mécanismes : la production de composants pour la réutilisation et la production de composants par réutilisation [[I.61], [I.62]].

La qualité principale attendue d'un composant est d'être réutilisable. Cette qualité est directement liée à sa généricité : la définition d'un composant doit être exempte de tout élément contextuel, lié à une utilisation particulière du composant, qui restreint sa capacité à être réutilisé pour d'autres utilisations. [...] La réutilisabilité d'un composant dépend de la généricité de son contexte de définition. Cette généricité dépend à son tour de la capacité du langage de modélisation à isoler la définition d'un composant de tout contexte d'utilisation.

Sylvain Vauttier, Christelle Urtado et Eric Mendizabal [I.63] ont montré que pour être utile au processus de réutilisation, le contexte de définition d'un composant doit comporter :

- la définition des classes qui constituent le composant,

- les relations structurelles (relations de composition) qu'entretiennent les classes d'objets du composant entre-elles,

- les relations fonctionnelles (collaborations définies par des relations d'association) qu'entretiennent les classes d'objets du composant entre-elles.

Dans sa thèse,Thomas Quinot [I.49] montre comment le polymorphisme et l'héritage facilitent la réutilisation de composants, l'un en permettant la manipulation générique d'ensembles d'entités partageant un ensemble minimal de propriétés, l'autre en autorisant l'ajout de fonctionnalités à des objets existants, sans modification directe de ceux-ci.

Mamadou Niang , Mohamed Sidi Farssi, Sissoko Gregoire, A. Cissé et A.S.T. Sané  [I.65] ont dit que le modèle ADROIT vise la mise en oeuvre des composants d'un SI grâce à une application générique paramétrable dotée d'outils décisionnels et de management de la connaissance.

II.2 ADROIT (Acte - Document - Rubrique - Objet - Information - Tiers )

ADROIT est développé pour répondre aux besoins des entreprises Sénégalaises en générale et surtout pour les centres médicaux dans le domaine de la Télé médecine, de l'Hôtelerie, de l'Enseignement et du Commerce en général. Il peut gérer toute l'activité d'un hôtel ou d'un centre médical.

ADROIT est développé en PHP. Le système est basé sur 6 principales fonctionnalités :

- La gestion du site

- La gestion du paramétrage

- La gestion de l'administration

- La gestion de domaine

- La gestion des outils

- La gestion du décisionnel

ADROIT permet de faire des saisies, des modifications, des suppressions, des consultations et des éditions.

L'architecture graphique de ADROIT peut être représentée comme suit :

L'ordonnancement des tâches suit le niveau d'informations de la base de données.

Par exemple: on ne peut pas faire une entrée en stock d'un nouveau article sans pour autant au préalable créer l'article.

Saisie d'un nouveau article

Mise à jour du stock

Chacune de ses fonctionnalités est le résultat d'une instanciation d'un formulaire qui aura des caractéristiques liées au profil de l'utilisateur.

Par exemple : le secrétaire comptable pourra saisir dans des comptes mais ne pourra pas saisir les infos liées à la masse salariale.

La généricité de ADROIT est fonction de sa capacité de paramétrage. Par cette caractéristique, les modules de ADROIT peuvent être instanciés avec des méthodes, des fonctions et des propriétés spécifiques.

Cette procédure permet à ADROIT d'avoir une généricité simple.

Tiers

Clients

Patients

Employés

Etc...

INSTANCES

Etc...

Acte

Dossier médicale

Facture

Bulletin de paie

I

N

S

TANCE

S

Exemple d'Acte Exemple de Tiers

Les éditions dans ADROIT sont paramétrées de la même manière qu'au niveau formulaire.

On tient compte des profils des utilisateurs; ceci permet d'instancier le module d'impression pour avoir un état ( une facture, un bulletin de salaire etc...).

Connexion

L'accès au menu principal passe par un formulaire d'authentification lié à la table stockant les informations concernant les utilisateurs autorisés du système. Les règles de contrôle sont définies de sorte que, tout utilisateur du système dispose d'un profil permettant de déterminer quels sont les droits qui lui sont octroyés, et quelles sont les informations auxquelles il a accès. Ce qui fait que n'importe qui ne peut faire n'importe quoi sur le système. Aussi, pour éviter des attaques externes comme internes, la technologie de cryptage md5 a été utilisée pour la transmission des informations sensibles, telles que les mots de passe, sur le réseau.

Ainsi tout mot de passe fourni sur le réseau est crypté de façon irréversible de sorte que même si une personne mal intentionnée récupère l'information, elle ne puisse pas régénérer le mot de passe en clair.

Paramétrage

Le paramétrage de ADROIT est relativement simple avec l'interface qu'il offre pour le faire.

L'accès au menu d'administration n'est permis qu'à l'administrateur ou l'intégrateur du site et pour le faire il faut s'identifier à l'accueil.

On accède à toutes les autres fonctionnalités de paramétrage et d'administration du progiciel.

Le paramétrage permet :

- de gérer les profils des domaines ( c'est le degré d'accessibilité à un domaine particulier),

- de gérer les domaines ( création des domaines d'activités ou des fonctions), Exemple : Comptabilité, Stock, Finance, Production etc...

- de gérer les listes ( permet de créer les données de base des tiers, des objets et des produits),

- de gérer les champs (à chaque classe, on peut attribuer des champs suivant le domaine ; les libellés des champs sont susceptibles d'être modifiés)

Gestion des profils (Paramétrage)

Dans la gestion des Profils, on détermine le niveau d'accès à un domaine fonctionnel du système. Par exemple si on attribue « Publique » au domaine Stock, cela veut dire que Stock est accessible à tout le monde.

Gestion des Outils (Paramétrage)

Dans la gestion des Outils, l'intégrateur peut stocker ses outils de travail ( outils de développement, de conception et d'intégration etc ...).

Gestion des Domaines (Paramétrage)

Dans la gestion des Domaines, on crée les domaines ou les fonctions d'une entreprise. Ceci permet de faire une gestion verticale d'une fonction d'entreprise. Par exemple : La comptabilité existe dans toutes les entreprises et par conséquent ce domaine pourra être utilisé par toute entité quelque soit son activité (médicale, commerciale, production etc...).

Pour chaque domaine, on peut lui attribuer des classes du modèle. Cette fonctionnalité est un des résultats de la généricité du modèle ADROIT.

Gestion des SMS (Paramétrage)

Permet de choisir les actes qui peuvent être envoyés par SMS, par mail ou par serveur vocal. Dans ce cas chaque acte est associé à un ou plusieurs types de média. Par exemple : une facture peut être envoyée par SMS, par mail ou son montant communiqué par boîte vocal

Gestion des Champs ( Paramétrage)

Pour chaque Acte, on associe les champs qui sont concernés (les champs d'une facture ne seront pas les mêmes que ceux d'un acte médical). Il n'a que les champs choisis qui seront affichés au moment de l'instanciation de la classe. La généricité réside dans le degré de paramétrage qui permet l'association d'un acte à des champs sans limite aucune.

Gestion des Listes ( Paramétrage)

Les listes font parti d'une série de concepts qui ont donné à ADROIT sa généricité car il y a le principe de la réutilisation des classes telles que TIERS ou OBJETS ou PRODUITS dans toutes les fonctions d'une entreprise. Les listes sont des instances des classes qui participent aux éléments de bases d'une classe principale (Acte). Par exemple : Création de la liste des clients d'une entreprise commerciale ; pour facturer un client, il faut aller récupérer le client dans la liste des clients ou la créer dans la liste.

Gestion des Utilisateurs

Dans la gestion des utilisateurs, on peut associer à chaque utilisateur les domaines et les menus où il a accès. Cette fonctionnalité permet de gérer la sécurité du système au niveau accès.

Gestion des types d'Actes

Dans la gestion des types d'Actes, on peut créer des types d'actes qui seront associés à des domaines, des classes (Tiers, Objets ou Produits, Infos ou Documents). Chaque zone contenant l'instance d'une classe peut être affichée ou non suivant la définition et la fonctionnalité du type d'acte considéré.

Ce paramétrage de la gestion des Actes donne un caractère générique au modèle ADROIT.

Gestion des type de Tiers

Dans la gestion des types de Tiers, on peut créer des créer des types de tiers ( par exemple : CLIENTS, FOURNISSEURS, EMPLOYES etc..). L'instanciation de la classe tiers associée au type de tiers permet de créer une liste ( par exemple : Clients : Mamour Ndiaye, Moustapha Diouf etc...)

Gestion des Objets

Dans la gestion des objets, on crée les objets et les produits. Chaque objet ou produit est lié à un type d'Acte. Les produits représentent les articles commercialisables et les objets représentent les immobilisations. Ceci permet par exemple de gérer séparément la gestion des immobilisations à la gestion commerciale. Cette fonctionnalité est possible à cause la généricité du modèle qui à permis de prendre en compte les objets et les produits dans une même entité.

Gestion des Informations

La gestion des informations permet de définir le paramétrage des éléments divers ne figurant pas dans les classes prédéfinies. Ces éléments divers peuvent être des listes qui pourront servir à alimenter le choix des rubriques informations. Par exemple : les pays de naissance ou les pays des adresses clients ou fournisseurs.

Gestion des Documents

La gestion des documents prend en compte les types de documents tels que les documents scannés, les photos, les textes attachés etc. Chaque type de documents peut être lié à un domaine. Par exemple : Le type de document Photo peut être lié au domaine Ressources Humaines.

Le MENU PRINCIPAL

Dans ce menu, on peut voir tout ce qui a été défini au niveau des modules Administration et Paramétrage : Les domaines, les Actes et leur contenu, les autres fonctionnalités ( listes, réglement, transfert, décisionnel, Webmail, Optimisation, archivage, Outils).

Par cette technologie de généricité, le modèle applicatif de ADROIT permet d'avoir une vue d'ensemble de la gestion globale ( horizontale et verticale ) dans tous les domaines. On voit ici qu'on peut créer n'importe quel domaine et l'associé aux classes du modèle ADROIT par le paramétrage.

II.3 Critiques sur la généricité

Malgré sa fonction de généricité, ADROIT traîne certains problèmes :

- Limites de certaines fonctionnalités

- Inexistence d'autres fonctionnalités

- Inadaptation d'une interface graphique pour certains cas.

ï Limites de certaines fonctionnalités

Le clonage qui permet de gérer les notions de variations et de transformations est insuffisant pour prendre en compte un groupe d'articles ou de services. Ceci augmente la quantité d'informations à stocker et par conséquent agit sur la performance du système.

La notion de variations permet avec une simple description d'une rubrique et une collection de paramètres optionnels pour définir des millions de variations d'un produit sans créer des millions d'enregistrements dans la base de donnée et sans avoir à créer un numéro de produit pour chaque produit.

ï Inexistence de certaines fonctionnalités

L'internationalisation du système (multi langue) n'est pas pris en compte.

Toujours au niveau fonctionnalités, ADROIT ne gère pas les aspects marketing, le CRM, la gestion de projet, production et le e-commerce. Il se limite à gérer les Stocks, les Finances, la comptabilité, les ventes et les achats.

La gestion de planning est aussi une fonctionnalité non prises en compte par ADROIT.

ï Inadaptation d'une interface graphique pour certains cas

L'interface graphique n'intègre pas l'option de reporting qui pourrait permettre la création d'états paramétrés à partir de conteners.

Une interface web adaptée au paiement en ligne serait un point important pour la gestion commerciale e-commerce.

II.4 Propositions et amélioration du modèle d'application de ADROIT

Nous proposons un système composé de couches que nous présentons ci-dessous :

- la couche présentation (GUI) avec une sous couche logique de présentation (fonction du matériel, des profils utilisateurs, de la version du logiciel)...

- la couche business qui effectue le job de l'application

- la couche persistance, avec une logique de persistance qui peut choisir le mode d'enregistrement ou s'adapter.

- la couche de communication qui prend en charge les problèmes réseaux

- la couche d'interopérabilité

Une telle vision architecturale d'une application (en terme de service en faite) permet de mieux organiser son code, mieux le packagé.

Dans le module gestion des outils de ADROIT, nous proposons la mise en place d'outils qui permettront de faire une intégration complète du système. Ces outils d'intégration pourront être des Middlewares ( intergiciels ) , des web services ou de XML.

III. Plateforme ADROIT : Comment gérer un hôtel

Pour illustrer ce travail de recherche, nous allons intégrer un modèle de gestion d'un hôtel au modèle ADROIT. Ce logiciel permettra de gérer les réservations, la facturation et le suivi des clients dés leur arrivée jusqu'à leur sortie de l'hôtel. Pour ce faire, nous présentons d'abord le modèle de la gestion d'hôtel. Ce modèle a été conçu sous l'AGL Windev version 8.0 de PCSOFT.

III. 1 Vue d'ensemble des fonctionnalités d'une gestion d'hôtel

- Création et mise à jour :

1 - Enregistrement des chambres, des bars et des restaurants

2 - Enregistrement des réservations

3 - Validation des réservations ( cette validation pourra se faire par SMS ou par mail, par

fax ou par téléphone)

4 - Enregistrement des services ( les consommations sont enregistrées au jour le jour)

5 - Validation facture ( Cette validation de la facture se fait à la fin du séjour du client)

6 - Sécurité avec code d'accès

- Consultation :

1- Consultation et édition des clients arrivées

2 - Consultation et édition des clients départs

3 - Consultation et édition de la configuration des chambres

4 - Consultation et édition de la main courante

5 - Consultation et édition du planning d'occupation des chambres

6 - Consultation et édition du planning de réservation

7- Consultation et édition du relevé du bac( factures impayées)

8 - Consultation et édition de la situation caisse utilisateur

9 - Consultation et édition de la situation journalière caisse

10 - Consultation et édition de la situation journalière des statistiques 

11 - Consultation et édition de la situation journalière des consommations diverses

12 - Consultation et édition de la situation journalière des consommations restaurant

13 - Consultation et édition de la situation journalière de l'hébergement

14 - Consultation et édition de la situation journalière par segmentation

15 - Consultation et édition de la situation journalière des consommations du bar par période

16 - Consultation et édition de la situation journalière des consommations du restaurant par période

III.2 Les cas d'utilisations

Les cas d'utilisations permettent de structurer les besoins des utilisateurs et les objectifs correspondants d'un système. Ils centrent l'expression des exigences du système sur ses utilisateurs. Ils se limitent aux préoccupations réelles des utilisateurs ; ils ne présentent pas de solutions d'implémentation et ne forment pas un inventaire fonctionnel du système. Ils identifient les utilisateurs du système et leur interaction avec le système.

Titre	Auteur	Description
Enregistrement des chambres, des bars et des restaurants	Commercial, Gestionnaire bar, Gestionnaire restaurant	Permet de saisir les chambres à réserver, les restaurants et les bars qui existent dans l'hôtel
Enregistrement des réservations	Commercial, Organisme payeur, Client	Permet de faire des réservations sur les chambres susceptibles d'être libérées avant la date d'arrivée du client
Enregistrement des services	Comptable, Gestionnaire bar, Gestionnaire restaurant, Caissier principal	Permet d'enregistrer les consommations faites dans les bars et les restaurants mais aussi les services de chambre
Facturation	Comptable, Gestionnaire bar, Gestionnaire restaurant, Caissier principal	Permet de valider les consommations faites dans les bars et les restaurants mais aussi les services de chambre
Sécurité avec code d'accès	Administrateur	les utilisateurs sont paramétrés par l'administrateur. Il leur attribut un code d'accès pour se connecter au système
Consultation et édition des clients arrivées	Commercial	A une date donnée, le commercial doit savoir le nombre de clients arrivés
Consultation et édition des clients départs	Commercial	A une date donnée, le commercial doit savoir le nombre de clients partis
Consultation et édition de la configuration des chambres	Commercial	A une date donnée, le commercial doit connaître la configuration des chambres
Consultation et édition de la main courante	Comptable, Gestionnaire restaurant, Caissier principal	A une date donnée, on doit pouvoir connaître la main courante du restaurant
Consultation et édition du planning d'occupation des chambres	Commercial	Le commercial doit connaître à une date donnée le planning d'occupation des chambres
Consultation et édition du planning de réservation	Commercial	Le commercial doit connaître à une date donnée le planning de réservation des chambres
Consultation et édition du relevé du bac( factures impayées)	Comptable, Caissier principal	Le caissier principal doit connaître les factures impayées à une date donnée
Consultation et édition de la situation caisse utilisateur	Gestionnaire de bar, gestionnaire restaurant	Chaque caissier ( bar ou restaurant ) doit pouvoir connaître la situation journalière de sa caisse
Consultation et édition de la situation journalière caisse	Comptable, Caissier principal	On doit pouvoir connaître la situation général des caisse à une date donnée
Consultation et édition de la situation journalière des statistiques	Comptable, Caissier principal, Commercial	Connaître le nombre de chambres ( disponibles, occupées, bloquées) et le taux d'occupation
Consultation et édition de la situation journalière des consommations diverses	Comptable, Caissier principal, Gestionnaire bar, Gestionnaire restaurant	A une date donnée, connaître la situation journalière des consommations diverses
Consultation et édition de la situation journalière des consommations restaurant	Comptable, Caissier principal, Gestionnaire restaurant	A une date donnée, connaître la situation journalière des consommations au restaurant
Consultation et édition de la situation journalière de l'hébergement	Comptable, Caissier principal	A une date donnée, connaître la situation journalière de l'hébergement ( téléphone, blanchisserie etc...)
Consultation et édition de la situation journalière par segmentation	Commercial, Comptable, Caissier principal	Connaître la situation journalière des consommations par segmentation
Consultation et édition de la situation des consommations du bar par période	Comptable, Caissier principal, Gestionnaire bar	Connaître la situation période des consommations faites au bar
Consultation et édition de la situation des consommations du restaurant par période	Comptable, Caissier principal, Gestionnaire restaurant	Connaître la situation période des consommations faites au restaurant

III.3 Diagramme de classe

Un diagramme de classes est une collection d'éléments de modélisation statiques qui montre la structure d'un modèle.

III.4 Intégration de gestion d'hôtel dans ADROIT

Nous avons utilisé les cinq classes du modèle ADROIT :

Les tables du modèle UML de l'application gestion d'hôtel sont intégrées dans ADROIT comme suit :

- TIERS (Clients, Bar_Resto)

- OBJET (Chambre, Segmentation)

- ACTES (Réservation, Facture)

- INFORMATIONS (Position, Situation, Nationalité, Mode de paiement, Type règlement, date règlement)

- RUBRIQUES ou FINANCES (Ligne_Facture, Ligne_Reservation)

Par exemple :

- Pour un Acte de type Réservation, on aura un Tiers de type Client, un Objet de type Segmentation ( pour la tarification à appliquer) et une Rubrique de type Finances qui contiendra la chambre et le prix.

Pour obtenir une facture provenant d'une réservation, il faut faire un clonage. Pour cela, les informations de la réservation doivent être les mêmes que celles de la facture. Dés que la clonage est fait, on aura un Acte Facture.

Par exemple :

- Pour un Acte de type Réservation, on aura un Tiers de type Client, un Objet de type Segmentation ( pour la tarification à appliquer) et une Rubrique de type Finances qui contiendra la (chambre, les services consommés et leur prix respectifs).

Pour le paramétrage des éditions, nous avons adopté l'option d'utiliser la classe objet qui nous permettra de créer des états. Chaque champ de la classe objet devra contenir un champ de l'état dont sa mise à jour se fera à partir de requêtes.

Pour y parvenir, les requêtes seront stockées dans des champs spécifiques à ce besoin. Ils pourront être modifier à chaque fois que les règles de gestion et de calcul changent.

De cette manière, le modèle ADROIT a pu intégré le modèle d gestion d'hôtel grâce à son caractère fortement générique.

IV. Conclusion

Ce travail de mémoire a permis de comprendre l'intégration et la généricité. Nous avons durant ce travail fait des recherches sur des systèmes d'intégration tels que les ERP, les EAI, les EII, les datawarehouses, les web services, les ETL etc...et ensuite sur la généricité des applications.

A l'issue de la recherche que nous avons mené sur l'intégration des systèmes, nous pu voir que :

ï Les notions d'EAI et de web services ne sont donc pas concurrentes mais bien complémentaires, l'EAI pouvant servir de plateforme de déploiement de web services (exposition des ressources du SI en tant que web services de manière rapide et simple ou consommation de web services). De plus, les web services sont encore très loin de répondre à l'ensemble des enjeux de l'intégration. Ils ne peuvent prétendre remplacer intégralement l'ensemble des fonctions offertes par un EAI.

ï A la différence de l'EII qui se contente d'orchestrer et d'organiser des requêtes adressées à différents systèmes cibles sans agrégation de contenu préalable, un entrepôt commence par regrouper les données nécessaires avant de les exposer aux applications clientes. Pour ce faire, il s'appuie généralement sur des mécanismes d'intégration assez complexes, tels l'EAI (intégration d'applications d'entreprise) ou l'ETL (extraction, transfert et chargement de données).

ï Les systèmes orientés datawarehouse tels que EII, les ERP non modélisé, les EDI et les systèmes de réplication permettent de faire une intégration centrée sur les données.

Concernant les recherches faites sur la généricité, nous avons pu trouver qu'un modèle générique permet d'élaborer un modèle indépendant de tout domaine d'application et que cette généricité permet de modéliser les concepts et les cas d'utilisation.

On a vu aussi que pour résoudre le problème de génération automatique des interfaces graphiques, on pouvait concevoir et la réaliser un outil de génération d'interfaces graphiques basé sur un modèle XML générique.

Nous avons pu voir la différence entre la généricité par les composants et la généricité par les modèles. Le premier permet d'adapter un composant suivant le contexte dans lequel il sera utilisé et le second permet de mettre générer un modèle entier en s'appuyant sur des classes génériques.

L'objectif de généricité est atteint en proposant des règles générales qui interprètent les structures représentant les connaissances du domaine.

La relation étroite entre connaissance et représentation soulève la question de la généricité des modèles que l'on peut construire. Il s'agit là d'une question centrale dans la mesure où, du point de vue de la technologie, la généricité est une promesse d'économie de moyens, et de réutilisabilité. Mais, par ailleurs, la spécificité est un gage d'efficacité des systèmes et de leur pertinence dans un procès d'apprentissage. Le rapport entre spécificité et généricité des modèles est en fait une question fondamentale qui doit être abordée comme telle.

L'utilisation de ces outils a permis à l'industrie du génie logiciel à participer activement à la globalisation et à la mondialisation. L'interopérabilité des outils de modélisation passe également par ces technologies.

Avec les outils d'intégration et de généricité, nous sommes moins liés aux spécificités des

besoins qu'à la généralisation et l'inter connectivité. Donc la conception serait l'étape essentielle dans un travail d'intégration.

De nouveaux standards restent à définir si l'on ne veut pas être constamment lié à une solution propriétaire.

La généricité et la réutilisation des formalismes et des traitements ont donc constamment orienté les différents choix.

Avec le modèle ADROIT, nous avons pu apporter des propositions au niveau intégration et généricité. Ces propositions tant au plan modèles de données que modèle d'application pourront améliorer les fonctionnalités de ADROIT applicatif.

Au niveau données, nous avons pu mettre en ouvre un modèle de gestion d'hôtel qui s'est adapté dans les meilleures conditions à cause de la généricité du modèle ADROIT. Cette intégration nous a permis de générer un modèle d'application de gestion d'hôtel.

La principale perspective est de pouvoir adapter ADROIT à toutes les situations de l'entreprise, tant au niveau horizontale que verticale.

Comme perspectives, nous pensons à la résolution de certains problèmes auxquels sont confrontés les modèles génériques :

A court terme :

- Comment intégrer la comptabilité des matières dans ADROIT ?

A long terme :

- Comment prendre en compte l'évolution du modèle ADROIT ?

- Comment tenir compte des relations entre ADROIT et d'autres modèles ?

Bibliographie

[I.1] Mathieu Lafourcade «Génie Logiciel pour le Génie Linguiciel » 1er décembre 1994

[I.2] Philippe Louchet, Frédérique Brossillon . « PGI: A la recherche de l'intégration »

[I.3] F. Casati & M-C. Shan (2001). «Models and Languages for Describing and Discovering E-Services.» In ACM SIGMOD, Santa Barbara, USA.

[I.4] Patrick Kellert et Farouk Toumani. « Les Web services sémantiques ». Laboratoire LIMOS - UMR (6158) du CNRS ISIMA - Campus des Cezeaux - B.P. 125 63173 AUBIERE Cedex . pages 5

[I.5] Moisdon J-C. , Seli-Arslan (1997) : « Du mode d'existence des outils de gestion ».

[I.6] W. H. Inmon (Wiley 2002) . « Building the Data Warehouse »

[I.7] Jeff Konnen. « Couplage d'un ERP et d'un datawarehouse avec un SIG. Le mariage d'un monde multidimensionnel avec la cartographie. ». 2003-2004

[I.8] Porter Michael, « L'Avantage concurrentiel », Paris, InterEditions, 1986.

[I.9] Rigaud Louis, « La Mise en place des systèmes d'information », Paris, Dunod, 1979.

[I.10] ARDISSONO L., GOY A., PETRON G., « Enabling Conversations with Web Services », Proc AAMAS03 : The Second International Joint Conference on Autonomous Agents and Multi-Agent Systems, Melbourne, Australia, July 2003, ACM, p. 819-826.

[I.11] D. Fensel, C. Bussler, & A. Maedche (2002). «Semantic Web Enabled Web Services. In International Semantic Web Conference », Sardinia, Italy, pages 1-2.

[I.12] Mejdi Kaddour, Laurent Pautet. « Une Approche Coopérative de l'Adaptabilité des applications Mobiles basées sur MobileJMS ». Ecole Nationale Supérieure des Télécommunications

[I.13] Denis Gerard, Jean-Rene Caron. « Cet outil de gestion est une initiative conjointe de la Direction du commerce et de la Direction du développement des entreprises et des affaires d'entreprises, du MDER, réalisée dans le contexte du projet Comment vendre aux grandes chaînes ». ( 2000- 2003)

[I.14] Olivier Grenet, directeur technique de Datox: «La connectivité des logiciels doit s'appuyer sur des standards (Web Services SOAP par exple) afin d'assurer l'interopérabilité des systèmes. »

[I.15] Michel Chokron, Mireille Des Rochers « Une démarche de conception d'un modèle générique ». - HEC, Montréal - Cahier du GReSI no 00-03 Avril 2000

[I.16] Losavio, Francisca, Ortega, Dinarle; and Perez, Maria. «Modeling EAI [I.Enterprise Application Integration], Proceedings. 12th International Conference of the Chilean Computer Science Society », 2002, 6-8 November (2002) pp: 195-203, ISSN: 1522-4902

[I.17] Toussaint P.J., Bakker A.R.,and Groenewegen L.P.J. : «Integrating information systems in medicine: a reference model for Middleware, Informatics Medical», Vol. 22, n°3, 227-235, 1997.

[I.18] Nikica FILIPOVIC (2001-2002) « Conception d'une plate-forme électronique basée sur les rapports commerciaux de vente de produits de luxe: étude de cas. »

[I.19] B. Gibaud - « HDR - Document de synthèse »

[I.20] Lucy Bottomley. « Introduction à l'EDI (Échange de données informatisé). » Flash Réseau Numéro 6 ISSN 1200-5304 Fév. 1995

[I.21] Mounir FEGAS.  « Classification de documents XML. Application au corpus d'INEX et aux rapports d'activité INRIA »

[I.22] [I.Veys 1981] Veys, M., «Information System Study Am APL-Tool for BSP», IBM Belgium, 1981;

[I.23] David ROUSSE (DSI/BEST) . « Panorama d'une infrastructure EAI ».

[I.24] L. Avignon, T. Brethes, C. Devaux, P. Pezziardi. « Le livre blanc de l'EAI - Intégration des applications d ' Entreprise ». 1999 OCTO Technology

[I.25] Philippe Laumay. « Déploiement d'un bus à messages sur un réseau à grande échelle ». Thése de DEA. Juin 2000. Page 12.

[I.26] Alex Hormer and David Sussman. In book : « MTS & MSMQ », Chapitre 5, Eyrolles, Paris, France, février 1999. ISBN 1-8610046-0.

[I.27] G. Banavar, T. Chandra, R Strom and D. Sturman. « A case for Message Oriented Middleware ». Distributed Computing 13th International Symposium, Bratislava, Slovak Republic, September 27-29, 1999, Proceedings. Lecture Notes in Computer Science, Vol. 1693 : 1-18, Springer, 1999, ISBN 3-540-66531-5

[I.28] P. Reiss. « Connecting Tools Using Message Passing in the Field Environment ». IEEE Software, pages 57-66, juil 90.

[I.29] Nathalie Ndjependa. « Utilisation d'XML dans les entreprises Le cas d'un cabinet d'architecture du paysage ».

[I.30] Daniel Weck - Peter Hewat . « Player SMIL 2.0 pour PocketPC `PocketSMIL2.0. » Version : 2.0. 25 Août 2002

[I.31] John D. Poole. "Model-Driven Architecture : Vision, Standards And Emerging Technologies".ECOOP 2001, Workshop on Metamodeling and Adaptive Object Models, April 2001.

[I.32] Cécile Bourreau.  « Développements sur l'ERP libre OfbizNéogia ».

[I.33] Mathieu Nicolescu. « Webservices ». version 1.1 - 3 novembre

[I.34] Pierre-Yves Fourmond  « Les Middleware Orientés Messages.Une introduction aux Message Oriented Middleware (MOM) ». Copyright 2005 - 2006

[I.35] Ahmed Sékou Touré SANE. « Mise en place d'un Système d'Information Décisionnel dans un Environnement Médical ».

[I.36] http://www.erp5.org

[I.37] Agha G. A., « Actors : A Model of Concurrent Computation in Distributed Systems », The MIT Press, ISBN 0-262-01092-5, Cambridge, MA, 1986.

[I.38] Vivien Quema, Luc Bellissard. « Configuration de Middleware dirigée par les applications ». INRIA Rhône-Alpes ; Sardes Project2ScalAgent Distributed Technologies

[I.39] B. Tavernier, A. Croixmarie. « Architecture, intégration. Représentation XML au sein de l'envirinnement Calife ». AVERRROES Ver. 1.0

[I.40] Guérin, E., Marquet, G., Moussouni, F., Burgun, A., Mougin, F. and Loréal, O. «Deployment of heterogeneous resources of genomic, biological and medical knowledge on the liver to build a datawarehouse.» ECCB, European Conference on Computational Biology, Paris, France, 2003.

[I.41] Guérin, E., Moussouni, F., Courselaud, B. and Loréal, O. « Modélisation d'un entrepôt de données dédié à l'analyse du transcriptome hépatique. » JOBIM, Journées Biologie, Informatique et Mathématique, Saint Malo, France, 2002.

[I.42] Georges-Louis Baron et Éric Bruillard, « Les technologies en éducation, Perspectives de recherche et questions vives.» Actes du Symposium international francophone, Paris, 31 janvier 2001 - février 2002, Éditions Fondation MSH, INRP, IUFM de Basse-Normandie.

[I.43] Gilbert Babin Fellow, CIRANO Michel Leblanc « M.Sc. commerce électronique Associé », Adviso Conseil Inc. (Août 2003) 2003RB-07

[I.44] Scheer August-Wilhelm , and Habermann Frank, «Making ERP a success,Communications of the ACM», Vol. 43, No. 4, April (2000) 57 - 61, ISSN:0001-0782

[I.45] Steven Song, Bellant, CIEA . «Outils techniques et organisationnels servant à la gestion des connaissances et à leurs réseaux ». 2002

[I.46] Mohand-Saïd Hacid* et Chantal Reynaud, « L'intégration de sources de données ».*LIRIS, UFR Informatique Université Claude Bernard Lyon 1 43, Blvd du 11 novembre 1918

69622 Villeurbanne . LRI, Bâtiment 490 Université Paris-Sud 91405 Orsay cedex

[I.47] Philippe Dosch . " INTRODUCTION À LA CONCEPTION OBJET ET À C++ " UNIVERSITÉ NANCY 2 INSTITUT UNIVERSITAIRE DE TECHNOLOGIE 2 ter boulevard Charlemagne CS 5227 54052
· NANCY cedex . Janvier 2001

[I.48] Chouki Tibermacine. " Un méta-modèle pour la description de contraintes architecturales sur l'évolution des composants ". Laboratoire VALORIA. Centre de recherche Yves Coppens Université de Bretagne Sud F-56000 Vannes Cedex

[I.49] Thomas Quinot. " Conception et réalisation d'un intergiciel schizophrène pour la mise en oeuvre de systèmes répartis interopérables ". pour obtenir le grade de Docteur de l'Université Paris VI - Pierre-et-Marie-Curie. le 24 mars 2003

[I.50] Nicolas Arnaud - Agnès Front - Dominique Rieu. " Expression et usage de la variabilité dans les patrons de conception ". LSR-IMAG, équipe SIGMA 681 rue de la passerelle BP 72 38402 Saint Martin d'Hères Cedex

[I.51] Mathieu Barcikowski «Une démarche générique pour l'adaptation des interfaces

dans les applications Web». DEA JUILLET 2003

[I.52] Pierre Crescenzo* -- Philippe Lahire* -- Emanuel Tundrea** « SmartModels : la généricité paramétrée au service des modèles métiers »

[I.53] Bertrand Marquet, Laurent Ballester, " Vers une nouvelle architecture des services de sécurité ". Alcatel Corporate Research Center Route de Nozay, F-91461 Marcoussis Cedex

[I.54] D. Regep,Y. Thierry-Mieg, F. Gilliers, F. Kordon†, " Modélisation et vérification de systèmes répartis : une approche intégrée avec LfP "

[I.55] Christelle Urtado / Sylvain Vauttier « Programmation par composants » - Année 06-07

[I.56] Eric SARDET . " Une approche pour la représentation des catalogues de composants industriels : le modèle P-Lib ". Rapport de recherche N° 00 003. ECOLE NATIONALE SUPERIEURE DE MECANIQUE ET D'AEROTECHNIQUE Site du Futuroscope - BP 40109 - 86961 FUTUROSCOPE Cedex - France Tél : [phone] - Fax : [phone]

[I.57] Hyacinthe Choury. " Architecture Orientée Services : gagner en rapidité, flexibilité et

Réactivité Architect Leader ". Capgemini France

[I.58] Frédéric Gava. " Introduction à la Programmation Java : généricité, le polymorphisme paramétrique " L.A.C.L Laboratoire d'Algorithmique, Complexité et Logique

[I.59] Fabrice DEPAULIS «Vers un environnement générique d'aide au développement d'applications interactives de simulations de métamorphoses ». Thèse 29 Novembre 2002

[I.60] Georges-Louis Baron et Éric Bruillard, « Les technologies en éducation, Perspectives de recherche et questions vives.» Actes du Symposium international francophone, Paris, 31 janvier 2001 - février 2002, Éditions Fondation MSH, INRP, IUFM de Basse-Normandie.

[I.61] CAUVET C., SEMMAK F., "La réutilisation dans l'ingénierie des systèmes d'information", Génie Objet - Analyse et Conception de l'Evolution, C. OUSSALAH et alii, Hermès, 1999.

[I.62] FRONT-CONTE A., GIRAUDIN J.P., RIEU D., SAINT-MARCEL C., " Réutilisation et patrons d'ingénierie" , GénieObjet - Analyse et Conception de l'Evolution, C. OUSSALAH et alii, Hermès, 1999.

[I.63] Sylvain Vauttier, Christelle Urtado, Eric Mendizabal. " La relation d'association dans les approches dirigées par les modèles : besoins et usages pratiques ". LGI2P / Ecole des Mines d'Alès, Site EERIE - Parc Scientifique G. Besse - F30035 Nîmes - France

[I.64] Maher EL'ARBI, Ahmed HADJ KACEM, Mohamed JMAIEL. " Une plate-forme de conception et de mise en oeuvre de systèmes multi-agents à base de modèles d'interaction ". Université de Sfax Laboratoire LARIS B.P. 1088, 3018 Sfax, Tunisie

[I.65] Mamadou Niang , Mohamed Sidi Farssi, Sissoko Gregoire * , A. Cissé, A.S.T. Sané : « ADROIT Modèle d'intégration et de Management de la Connaissance. » ESP, *UCAD -FASET.