Intégration des approches SOA et orientée objet pour modéliser une orchestration cohérente de services

Dimension: px
Commencer à balayer dès la page:

Download "Intégration des approches SOA et orientée objet pour modéliser une orchestration cohérente de services"

Transcription

1 Numéro d'ordre : 2010-ISAL-0060 Année 2010 InfoMath : École Doctorale Informatique et Mathématiques Intégration des approches SOA et orientée objet pour modéliser une orchestration cohérente de services Thèse de Doctorat (Spécialité informatique) Par Soutenue publiquement le 1 septembre 2010 devant la commission d'examen composée de : Dominique RIEU Professeur, Laboratoire LSR IMAG, Saint Martin d Hères présidente de jury Hervé PINGAUD Professeur, École des Mines d Albi-Carmaux Rapporteur Samir TATA Professeur, TELECOM & Management SudParis Rapporteur Frédérique BIENNIER Professeur, LIESP INSA de Lyon Directeur de thèse Youakim BADR Maître de Conférences, LIESP INSA de Lyon Co-Directeur de thèse Laboratoire d informatique pour l entreprise et les systèmes de production

2

3 Aux plus chers à mon cœur : mes parents, mes sœurs mes frères

4 REMERCIMENT Je tiens à remercier, Mme Dominique RIEU de me faire l honneur de présider mon jury de thèse. M. Hervé PINGAUD et M. Samir TATA pour avoir accepté de lire et d évaluer mon travail de thèse. Mme. Frédérique BIENNIER pour ses conseils et son aide pendant la rédaction de ma thèse. Mr. Youakim BADR pour son apport tant au niveau des connaissances, mais également pour ses encouragements, ainsi que son soutien tout au long de la thèse. Mes amis pour me supporter à avancer toujours. Toute ma famille en Syrie, et plus particulièrement mes parents, mes sœurs et mes frères qui m ont toujours encouragé. Un grand merci à mes parents à qui je dois ce que je suis devenue.

5

6 Résumé Pour faire face aux contraintes économiques, le développement de stratégies «au plus juste» (lean manufacturing) impose à la fois un recentrage métier, la mise en place de logistique de production «agile» et l organisation de collaborations inter-entreprises. Ces collaborations conduisent à l émergence d entreprises virtuelles et font largement appel aux technologies de l information et de la communication. Or les réponses technologiques apportées peuvent constituer un frein, les Systèmes d Information (SI) d entreprise ne sont que peu agiles. Et manquent de capacité d interopérabilité. En effet, l infrastructure informatique (matérielle et logicielle, i.e. ERP, CRM, CAD, SCM, MES ) présente une forte complexité technologique, manque d interopérabilité et limite donc les possibilités «d interconnexion» entre les processus d entreprise et l échange d information entre partenaires. Pour surmonter ces limites, l implémentation du système d information selon une architecture orientée services (SOA) définit une nouvelle approche pour organiser les applications d'entreprise et optimiser les processus métier. Néanmoins, ces infrastructures sont essentiellement destinées à soutenir l'interopérabilité intra-entreprise car elles reposent sur une définition monocontexte du processus d'affaires. Or un écosystème de services inclut un environnement multi-contextuel d exécution de services. Pour surmonter ces limites dans notre travail de recherche, nous proposons d intégrer une architecture supportant différents contextes d exécution pour favoriser le déploiement de systèmes d information interopérables au sein de l entreprise et donc faciliter la collaboration des processus interentreprises. Pour cela, nous proposons d utiliser une architecture de collaboration à base d hypergraphe. Afin de propager efficacement le contexte, nous proposons de définir des règles de propagation des mécanismes d héritage issus de l approche objet pour assurer une contextualisation des services à la demande. Pour cela, notre modèle est basé sur trois concepts : le service, le répertoire et le processus de collaboration (processus commun) qui est défini par différents vues (gestion, sécurité et médiation). Ces différentes vues permettent de composer simplement le service contextualisé. Mots clés : Collaboration interentreprises, Architecture Orientée Services (SOA), Service Web, composition de service, Approche Orienté Objet.

7 ABSTRACT To face the economic constraints, the development of just in time strategies (lean manufacturing) requires the organization of collaborations between enterprises. These collaborations lead to the emergence of virtual enterprise and needs the communication and information technologies. However the technological answers can constitute a brake as the enterprise Information systems (IS) lack of agility. Indeed, the infrastructure (hardware and software, ie ERP (Enterprise Resource Planning), CRM(Customer Relationship Management), MES (Manufacturing Execution System)...) has a high technological complexity, lack of interoperability and therefore limits the potential interconnection between business processes and exchange of information between partners. To overcome these limits, the implementation of the information system according to an orientated architecture services (SOA) defines a new approach to organize the applications of enterprise and to optimize the business processes. Nevertheless, these infrastructures are primarily proposed to support the interoperability inter-enterprise because they rely on a mono-context definition of the business process. However an ecosystem of services includes a multicontextual environment of execution of services. To overcome these limits, we propose to integrate an architecture supporting various contexts of execution to support the deployment of information systems interoperable within the enterprise and improving interenterprise collaborative processes enactment. Based on an hypergraph organisation, our architecture includes context propagation rules and extends the inheritance mechanisms from the object oriented approach to allow a simple service contextualisation. Our model is based on three concepts: service, repository and collaborative process (associated to the common process). Different views (management, mediation, security) are used to support a simple contextual service composition. Key-words: Enterprise collaboration, Service Oriented Architecture (SOA), Web service, service composition, and Approach objet oriented. vii

8 Table de matières Chapitre 1 Introduction Problématique... 1 Chapitre 2 Etat de l art Introduction Méthodes de modélisation CIMOSA GRAI PERA GERAM Méthodes orientées «système d information» Conclusion Approche basée processus Eléments caractéristiques d un modèle de processus Typologie des processus Gestion de processus métier ARIS : une méthode de modélisation orientée processus Stratégies d interconnexion de processus Conclusion Architecture orientée service : une réponse à l interopérabilité technologique Description de service Communication entre service Publication de service Description de la partie opérative des services Composition et orchestration de services Conclusion Démarches orientées objet Concepts de base de l approche objet Définition des Objets métier (Business objects) Méthodes de modélisation orientée objet IEM UML Conclusion Des modèles au logiciel Conclusion Chapitre 3 La collaboration des processus de l entreprise Introduction Architecture globale Spécification des différentes vues La vue de gestion La vue de médiation viii

9 3.3.3 Vue de sécurité Conclusion Exploitation du modèle : Conclusion Chapitre 4 Modélisation d'entreprises collaboratives par des graphes de d héritages de services Introduction Mécanismes d héritage Héritage entre services (objets) Héritage avec les propriétés fonctionnelles Les propriétés non fonctionnelles et le mécanisme d héritage La construction de l hypergraphe Construire l arborescence des instances Collaboration entre les entreprises à base d hypergraphe Orchestration contextualisée de type de service Les contraints de transition entre les types de service L enchaînement des types de services Les relations de dépendances entre les Services La relation d agrégation (A) Les cardinalités La spécification de contraintes globales La propagation des contraintes dans une composition La relation de recommandation (R) La relation de similarité (S) La relation de collaboration (C) Intégration des relations de dépendances dans les processus métiers Conclusion Chapitre 5 Conclusion générale et perspectives Conclusion général et perspective ix

10 Table de figures Figure 1 : Cube CIMOSA [16] page Figure 2 : les outils GRAI Figure 3 : éléments méthodologiques de GERAM [20], page Figure 4 : Cycle de vie de GERAM [21] page Figure 5 : La modélisation d une activité Figure 6 : Les éléments principaux pour la modélisation d un processus métier [10] page Figure 7 : l'architecture d'aris [41] page Figure 8 : Aris les niveaux de modélisation pour le processus de l entreprise [41] page Figure 9 : modèle de Service Web [51] page Figure 10 : La description d un service web grâce à WSDL [53] p Figure 11 : Ontologie OWL-S Figure 12 : Mécanismes d accès aux services fournis par un UDDI Registry [51] page Figure 13 : Modèle structurel des données de UDDI Registry [51] page Figure 14 : La connexion entre un processus BPEL et des services [59] page Figure 15 : Le document XLANG [59] page Figure 16 : Le model de coordination [53] page Figure 17 : exemple d'association Figure 18 : Exemple d'agrégation Figure 19 : exemple de généralisation Figure 20 : Schéma d un objet encapsulé Figure 21 : le modèle général d'activité d'iem Figure 22 : Représentation des relations entre classes [34] page Figure 23 : Exemple d'agrégation et de composition [34] page Figure 24 : Exemple d'une collaboration dans un diagramme de structure composite [34] page Figure 25 : Représentation d'un design pattern dans un diagramme de structure composite [34] page Figure 26 : Les niveaux de modélisation Figure 27 : Les catégories de modèles dans MDA Figure 28 : Exemple de PIM [40] page Figure 29 : Relation entre PIM et PSM en modélisation EJBexpanded [40] page Figure 30 : Etapes du processus MDA [40] page Figure 31 : Exemple d utilisation des modèles pour réaliser une application [38] page Figure 32 : Transformations des modèles [38] page Figure 33 : Comparaison entre processus collaboratifs traditionnels et multi-contextuels Figure 34 : Les concepts de base d une collaboration contextualisée Figure 35 : Description du contexte permettant une sélection et exécution multi-contextuelles de services Figure 36 : Génération du processus concret en choisissant les services concrets convenables.. 76 Figure 37 : Vue d agrégation du processus permettant la propagation des informations x

11 Figure 38 : Architecture globale Figure 39 : Relations entre le participant, le rôle, et le service abstrait Figure 40 : les relations entre les concepts dans le processus de collaboration Figure 41 : les éléments de modèle de collaboration (génération le service) Figure 42 : Exemple montrant la sélection du service abstrait à partir du rôle Figure 43 : Exemple montrant la règle de sélection des services concrets à partir des services abstraits Figure 44 : Définition d un service Figure 45 : Mécanisme de propagation de contraintes de sécurités via le médiateur Figure 46 : Les droits d accès et l héritage entre les objets Figure 47 : Construction du processus de collaboration par une série de transformation de modèles (MDA) Figure 48 : Modélisation des processus en termes d hypergraphe Figure 49 : Le modèle de service vu comme un objet qui encapsule les propriétés et les méthodes Figure 50 : L héritage entre les services Figure 51 : héritage avec les propriétés non fonctionnelles Figure 52 : Exemple d arborescence Figure 53 : Les attributs de la classe Figure 54 : L ensemble des attributs de l objet Figure 55 : L arborescence de l objet Figure 56 : Les liens entre les classes et les objets Figure 57 : Les liens avec des objets appartenant à différentes classes Figure 58 : Principe de présenter les services Figure 59 : Arbre d'héritage de service <achat> Figure 60 : rôle le médiateur Figure 61 : Le rôle de médiateur pour sélectionner le service contextuel Figure 62 : L Orchestration de type de service Figure 63 : Les différents états de transition Figure 64 : Service composé l acheter de produits informatiques Figure 65 : Vue statique du processus métier composite en relations d agrégation Figure 66 : Relation de recommendation < RoomBookingWS, R, SightSeeingWS > Figure 67 : Relation de similarité < RoomBookingWS, S, RoomReservationWS > Figure 68 : Relation de collaboration < AirTicketPurchaseWS, C, 0,5, RoomBookingWS> Figure 69 : Un processus métier et les différentes types de relations de dépendances entre les services xi

12 Chapitre 1 Introduction 1.1 Problématique L évolution de la demande pour des associations produits/services nécessite l organisation de collaborations «à la demande» entre entreprises pour répondre aux besoins des clients. Ce changement structurel au niveau du marché laisse donc prévoir une croissance exponentielle des écosystèmes de services dans les prochaines années et le développement de nouvelles structures organisationnelles permettant de pouvoir organiser des collaborations «à la demande» entre les entreprises. Ce changement de contexte impose d accroître non seulement l agilité de l entreprise (définie comme the ability of an organization to sense environmental change and respond efficiently and effectively to that change [1] page1 ") qui constitue un élément clef de succès [2] pour les entreprises mais aussi de résoudre les problèmes d interopérabilité tant au niveau organisationnel qu en ce qui concerne le niveau technologique. Pour ce qui concerne le niveau organisationnel, la mise en place de stratégie de collaborations et de partenariat entre entreprises impose de formaliser les différents processus afin de pouvoir ensuite construire un processus commun interconnectant les processus propres des différents partenaires. Pour cela, il faut modéliser à la fois les processus (définis comme des séquences de tâches) et les échanges d information entre ces tâches, ce qui nécessite la prise en compte de différents points de vue : 1. La vue fonctionnelle permet de décrire les différentes fonctions (en termes de processus, activités et opérations) et les contraintes de cohérence liées à l enchaînement de différentes fonctions. 1

13 2. La vue informationnelle est utilisée pour décrire les objets de l entreprise et leur gestion mais aussi l échange d information en entrée et sortie des fonctions et activités décrites précédemment 3. La vue des ressources est utilisée pour montrer les rôles des ressources et leur mode de gestion (qui fait quoi et avec quoi). 4. La vue organisationnelle sert à la description des responsabilités intervenant dans les prises de décision (qui est responsable de quoi). Cette phase de modélisation, si elle donne une vision globale et précise du fonctionnement de l entreprise, est relativement lourde à mettre en place. Or les règles de gestion des entreprises sont assez souvent similaires aussi les différentes méthodes de modélisation proposent elles une architecture intégrant des modèles génériques (représentant des «bonnes pratiques») à instancier et particulariser. Toutefois, cette logique top-down ne permet pas de s adapter dynamiquement aux différents contextes de collaboration puisque le processus de modélisation, instanciation, particularisation doit être repris depuis le début. De manière à atteindre le nécessaire niveau d agilité, il faut donc réorganiser l entreprise pour permettre une construction «incrémentale» des activités dans une logique plutôt «bottom-up». Au niveau technologique, les Systèmes d Information (SI) d entreprise ne sont que peu agiles et ne permettent pas d adapter les processus internes de l entreprises pour répondre «à la demande» aux changements structurels imposés par le marché. Or, l infrastructure informatique (matérielle et logicielle) repose sur une large variété de composants spécialisés ERP (Enterprise Ressource Planning), CRM(Customer Relationship Management), SCM(Supply Chain Management), ) et présente donc à la fois une forte complexité technologique et un manque d interopérabilité. Or la formalisation d une collaboration pour répondre à un objectif commun induit la création d un processus collaboratif liant et coordonnant l ensemble des processus mis en œuvre par les différents partenaires. Ceci impose donc de fortes contraintes d agilité et d interopérabilité sur les différents systèmes support pour permettre la combinaison et la bonne synchronisation de ces différents éléments. Ceci explique que le développement important des technologies de l information et de la 2

14 communication, au lieu de devenir un élément moteur de la collaboration inter entreprise soit vu comme des freins puisqu elles limitent les possibilités «d interconnexion» entre les processus d entreprise et l échange d information entre partenaires. Pour remédier aux problèmes d interopérabilité technologiques, le développement de l'architecture orientée services (SOA) [3] permet aux entreprises d organiser leur système d'information et les applications qui le composent en termes de services assemblés les uns avec les autres. L utilisation de standards d interface et de middleware (les Entreprise Service Bus ou ESB) permettent d apporter une réponse technologique au besoin d interopérabilité. Néanmoins, ces architectures à base de services ne permettent pas de contextualiser les services et leur assemblage dans une chaîne de service supportant un processus est dicté par l organisation du processus lui-même, spécification issue des activités de modélisation Pour surmonter ces limites, nous proposons d intégrer une architecture orientée service allant du niveau technologique au niveau d affaire. Pour cela, nous proposons de redéfinir les processus de manière abstraite au niveau de la logique d affaire en exprimant les différents rôles à jouer. Ceci permet de contourner la vision «topdown» de la modélisation traditionnelle en apportant une vision de composition incrémentale par composition de services abstraits en fonction des besoins. De manière à fournir le support technologique indispensable, ces processus abstraits sont utilisés pour sélectionner et interconnecter les services technologiques. De manière à faciliter la contextualisation, il importe de définir une logique d assemblage permettant d intégrer différentes logiques de médiation, de sécurité en composant des services technologiques adaptés au contexte. Pour cela, nous proposons une nouvelle logique d instanciation : il ne s agit plus seulement de dériver un modèle générique pour le particulariser puis transformer ce modèle particulier en un code exécutable, mais d adopter une logique de composition de services exécutables à partir de modèles abstraits ou d informations contextuelle. Pour cela, nous proposons une vision en hypergraphe qui nous permet de tirer partie à la fois des avantages de l approche objet (héritage, agrégation, ), de l ingénierie des modèles (logique de transformation) et de la composition de service. En effet, cette 3

15 architecture nous permet non seulement de relier étroitement services abstraits et concrets mais aussi d intégrer un «tissage» de modèles de sécurité, de médiation, des relations de similarité qui permettront d organiser au mieux le processus «concret» support de la collaboration en guidant les différentes opérations de composition. La suite de ce mémoire de thèse est organisée en 3 chapitres principaux : dans chapitre 2 consacré à l'état de l'art, nous concentrons d'abord sur la modélisation d'entreprise et présenterons différentes méthodes généralistes avant de nous intéresser plus spécifiquement aux méthodes de modélisation orientées système d information. Nous nous intéresserons ensuite aux approches orientées processus et aux apports des architectures orientées services avant de détailler les approches orientées objets et l ingénierie dirigée par les modèles. En effet, la plupart des méthodes de modélisation propose une démarche de type instanciation à partir de modèles générique pour créer des modèles spécifiques. Ce processus pourrait donc être amélioré en intégrant les apports de ces deux technologies. Le chapitre 3 présente globalement notre architecture permettant de générer des services contextuels «au vol» en combinant différents points de vue. L organisation des différents modèles associés est définie dans une structure à base d hypergraphe présenté de manière plus détaillée dans le chapitre 4. Enfin, le chapitre 5 rappelle nos principales contributions et présente les perspectives ouvertes par ce travail. 4

16 Chapitre 2 Etat de l art 2.1 Introduction Les évolutions rapides du contexte économique (notamment la prise en compte de stratégies de personnalisation «de masse», le développement de stratégies au plus juste, la recherche d une rentabilité maximale ) conduisent les entreprises à se recentrer sur leur cœur de métier tout en développant une stratégie d ouverture conduisant à des organisations collaboratives. Ce nouveau contexte impose aux entreprises de formaliser leur organisation (contraintes contractuelles) mais aussi d adapter leur organisation et leur système d information de manière à pouvoir construire de manière efficaces des processus collaboratifs interopérables permettant à l ensemble des partenaires d atteindre un but commun. Aussi, dans un premier temps, nous nous intéresserons aux méthodes générales de modélisation de l entreprise avant de nous focaliser sur les approches centrées processus. Dans un deuxième temps, nous prendrons en compte les contraintes d interopérabilité technologique et présenterons comment les approches orientées services et les standard associés peuvent apporter une réponse consistante au nécessaire besoin d ouverture des systèmes d information. Enfin, de manière à faciliter la conception des processus collaboratifs et de pallier les lourdeurs et difficultés inhérentes aux méthodes de modélisation classique, nous étudierons plus précisément les applications possibles des approches objets et de l ingénierie dirigée par les modèles pour permettre la génération de processus informatique «support». Ce tour d horizon nous permettra, en en identifiant les limites de ces différentes approches dans la conclusion de ce chapitre, d esquisser les pistes de recherche qui serviront de base à notre contribution.

17 2.2 Méthodes de modélisation Avant de présenter différentes approches de modélisation, il convient d en préciser l objectif et le périmètre. La modélisation d entreprise est l ensemble des activités et des processus utilisés pour développer les différentes parties d un modèle d entreprise dans le but de [13]: Construire une vision et une culture communes communiquées lors de l utilisation de modèles. Offrir une meilleure représentation et une meilleure compréhension du fonctionnement d une entreprise. Capitaliser la connaissance et le savoir-faire de l entreprise pour une utilisation ultérieure. Rationaliser et structurer les échanges d information. Concevoir et spécifier une partie de l entreprise (aspects structurels, organisationnels, informationnels, fonctionnels ou comportementaux). Analyser certains aspects d une partie de l entreprise (analyse économique, organisationnelle, quantitative, qualitative, etc.). Simuler le comportement d une partie de l entreprise. Offrir des éléments pour l aide à la décision pour le contrôle et l évolution de l entreprise (des processus, par exemple). Les approches de modélisation d entreprise sont nombreuses et intègrent différents points de vue permettant d appréhender globalement l organisation et le fonctionnement de l entreprise. Parmi elles, nous présenterons d abord la vision «intégratrice» de CIMOSA avant de nous intéresser à d autres méthodes se focalisant sur des points de vue plus spécifiques comme GRAI (pour la modélisation des décisions), PERA avant de terminer par le cadre fédérateur de GERAM. Nous nous intéresserons ensuite plus précisément aux approches de modélisation orientées système d information puisque le fonctionnement de l entreprise fait largement appel au système d information qui agit luimême comme un élément structurant de l organisation. Nous dresserons ensuite un bilan de ces méthodes dans le contexte particulier de la modélisation d organisations collaboratives. 6

18 2.2.1 CIMOSA La méthode CIMOSA (Computer-Integrated Manufacturing Open Systems Architecture) est issue d un projet européen Esprit. L objectif était de fournir un cadre de modélisation et un ensemble de modèles favorisant la mise en place du «Computer Integrated Manufacturing» [14] [15]. CIMOSA prend en compte à la fois un cadre de modélisation multi points de vue, une infrastructure facilitant la communication entre les différents éléments et une démarche méthodologique de modélisation. L infrastructure est chargée d apporter un ensemble de services : Les services de gestion assurent la gestion, le contrôle de l exécution des tâches ou activité du système. Les services de communication garantissent l accès aux données. Les services d interface supportent une représentation cohérente des différentes entités du domaine considéré. Le cadre de modélisation de CIMOSA, connu sous le nom du cube CIMOSA qui est montré dans la (figure 1) organise la modélisation de l entreprise selon trois axes [16]: Figure 1 : Cube CIMOSA [16] page 138 7

19 L axe de génération ou axe des vues est associé aux différents points de vue : a. La vue fonctionnelle permet de décrire les «fonctionnalités», la structure de contrôle et le comportement de l entreprise en termes d opération, activité et de processus. b. La vue information permet la spécification du système informatique de l entreprise, la création d une structure adaptée afin de stocker / mettre à jour / traiter Les informations (données et connaissances) pour les besoins des utilisateurs et des Applications (mémoire de l entreprise). c. La vue ressources est associée à la spécification et la description des composants requis et/ou implantés dans le système de production servant de réalisation des tâches de l entreprise. Il s agit aussi bien des composants de la technologie manufacturière que de ceux de la technologie informatique (qui fait quoi, quand et comment). d. La vue organisation sert à la description de l organisation et des responsabilités intervenant dans les prises de décision (qui est responsable de quoi). L organisation de l entreprise est exprimée en termes de cellules, d unités et de niveaux de prise de décision. L axe de dérivation permet d intégrer les différentes phases d un projet de modélisation selon trois phases : e. Expression des besoins : c est la construction d un modèle utilisateur qui définit ce qui doit être réalisé dans l entreprise (le QUOI). f. Spécification de conception : c est la construction d un modèle de l entreprise non ambigüe et cohérent. Différents modèles peuvent être développés pour étudier diverses alternatives par le biais de la simulation. g. Description de l implantation : c est la construction d un modèle exécutable de l entreprise (le COMMENT). L axe d instanciation permet à partir d un modèle générique global de construire différents modèles partiels avant de les particulariser pour définir des modèles spécifiques de l entreprise. Les différents points de vue proposés par cette méthode offrent un cadre riche permettant de définir les différentes représentations abstraites de l entreprise. La possibilité de générer des modèles particuliers pour l entreprise à partir de modèles génériques peut représenter un gain de temps appréciable et permettre de réutiliser des «8

20 best practices». Mais CIMOSA ne permet pas de se focaliser sur le processus de décision, capital en cas de développement d une stratégie de collaboration. Pour cela, on peut recourir à la méthode GRAI GRAI L objectif de la méthode GRAI [17] (Graphe de Résultats et Activités Inter-reliés) est de faciliter l identification de toutes les activités de décision d un système lors de l analyse et de la conception de son système pilotage. Pour cela, la méthode GRAI propose deux outils principaux : la grille GRAI et les réseaux GRAI [18] qui sont présentés dans la figure 2. La grille GRAI permet d identifier les activités des centres de décision suivant les dimensions fonctionnelles et temporelles. Les colonnes représentent les fonctions d un processus de décision. Les lignes correspondent à des niveaux de décision. Chaque niveau de décision est défini par un couple (horizon/période). Chaque centre de décision est défini par une activité de gestion. Les réseaux GRAI représentent le fonctionnement de tout ou partie d un centre de décision. Ils permettent de modéliser les activités d exécution et de décision. 9

21 Figure 2 : les outils GRAI La démarche GRAI comporte deux phases : L initialisation inclut la prise de contact avec l entreprise (pour définir les conditions de la collaboration et les objectifs à atteindre). L analyse de l existant débute par l établissement des grilles GRAI associées au système étudié. L étape suivante est l analyse ascendante qui permet la création des réseaux décrivant les processus utilisé dans le centre de décision identifié. Enfin, cette phase se termine par la rédaction du rapport d analyse. La conception du futur système : la grille GRAI permet de décrire l architecture du futur système de gestion de l entreprise. Cette modélisation des mécanismes de prise de décision (qui décide de quoi et sur quel horizon) nous semble bien correspondre aux problèmes soulevés par l organisation d organisations collaboratives car cela permet de définir clairement les limites de responsabilité. En outre, 10

22 la collaboration interentreprises fait largement appel aux technologies de l information et de la communication. Ce point est également pris en compte par GRAI dans la mesure où cette méthode a fait l'objet de plusieurs extensions en intégrant les méthodes orientées «système d information» comme IDEF0 et MERISE au processus de modélisation GRAI pour former la méthodologie GIM (GRAI Integrated Methodology ou GRAI-IDEF0-MERISE) vers les années 90. GIM apporte une réponse à la question de prise de décision, cependant, il n'apporte pas une réponse complète de gestion de ressource humaine et il ne prend pas en considération le cycle de vie d'un modèle. Pour surmonter cette limite, la méthode PERA peut être envisagée de manière complémentaire PERA PERA (Purdue Enterpris Reference Architecture) est une architecture pour la modélisation d entreprise développée à l université de Purdue aux Etats-Unis [19]. La méthodologie est basée sur les étapes associées au cycle de vie d un système : - Identification de l entité modélisée : cette étape concerne la caractérisation du domaine couvert par l étude : entreprise dans son ensemble, partie d une usine, - Conceptualisation : il s agit ici d exprimer les objectifs et politiques que l entreprise souhaite atteindre ou mettre en œuvre. - Définition : c est l étape d analyse fonctionnelle qui permet d identifier les besoins, les tâches à mettre en œuvre pour permettre la «réalisation» de ses besoins et les liens entre ces tâches. - Conception : cette étape débute par une phase de conception fonctionnelle destinée à définir les choix initiaux ou concevoir globalement les architectures organisationnelles, humaines, de production et informatique. Ces architectures sont ensuite précisées dans la phase de conception détaillée pour aboutir à des architectures d implémentation. - Installation et construction : il s agit ici de transformer les spécifications détaillées en une implantation effective des moyens nécessaires à la réalisation de la mission du système. C est lors de cette 11

23 étape que les ressources humaines sont formées et que les machines et équipements sont testés. - Mise en œuvre et maintenance : c est l exploitation effective de l installation en y intégrant les tâches de maintenance. PERA répond aux inconvénients observés dans GIM, néanmoins, cette méthode ne couvre pas plus que GIM tous les aspects nécessaires dans l organisation de collaboration. Elle doit donc être utilisée de manière complémentaire. Ceci pose donc le problème de mise en œuvre d un cadre fédérateur permettant «d articuler» différentes méthodes de modélisation pour tirer le meilleur partie de chacune d elle a obtenir un modèle le plus complet possible. C est l objectif du développement de GERAM GERAM Comme nous venons de le voir, les différentes méthodes de modélisation d entreprise utilisent une démarche méthodologique similaire tout en permettant d appréhender des points de vue différents (décision pour GRAI, fédération des architectures informatique, organisationnelles et de production pour PERA alors que CIMOSA juxtapose les différents composants du système). GERAM (Generic Enterprise Reference Architecture and Methodology) [20][21] est une initiative issue du groupe de travail (IFAC/IFIP Task Force) sur les architectures pour l intégration d entreprises et repose sur une analyse critique de ces différentes architecture pour fournir un cadre de modélisation générique permettant de fédérer différentes méthodes et outils de modélisation. Le cadre de travail de GERAM est composé de plusieurs entités [20] (voir figure 3). Une architecture générique de référence pour l entreprise (GERA : Generic Enterprise Reference Architecture) définit le cycle de vie de l entreprise. Une méthodologie générique d ingénierie de l entreprise (GEEM : Generic Enterprise Engineering Methodology) 12

24 permet de présenter les différents éléments à développer pour réaliser l intégration d une entreprise. Des outils et langages de modélisation génériques pour la modélisation de l entreprise (GEML : Generic Enterprise Modelling Tools and Languages) offrent le support nécessaire pour l activité de modélisaiton Des modèles génériques d entreprise (GEMS pour Generic Enterprise Models) : ils sont formés de méta-modèles, ontologies et de modèles d entreprise réutilisables. Ils constituent une base de «bonnes pratiques» qui peuvent être utilisées pour faciliter la modélisation d une entreprise. Des modules génériques d entreprise (GM pour Generic Enterprise Modules). Ce sont des implémentations standards d éléments qui peuvent être utilisé dans la phase d intégration pour une entreprise. Les EEMs (Enterprise Engineering Methodology) décrivent le processus de l'ingénierie d'entreprise. Pour chaque type d'activité du changement, elles décrivent des chemins d'évolution, identifient les tâches ainsi que les outils permettant ce changement. Les EMLs (Enterprise Modelling Languages) définissent des concepts (constructs) capables de modéliser à la fois la partie humaine de l'activité de l'entreprise, les processus métier et leurs technologies de support associées. Les constructs définissent les objets qui seront utilisés dans les vues définies dans GERA. Les méthodologies et les langues utilisées pour la modélisation d'entreprise sont supportés par les outils de modélisation d'entreprise (Enterprise Engineering Tools, EETs). Ces derniers permettent de gérer la création, l'utilisation et la gestion des modèles d'entreprise. La sémantique des langages de modélisation est assurée grâce à Generic Enterprise Modelling Concepts (GEMCs). Les modèles d'entreprise (Enterprise Models, EMs) qui représentent l'ensemble ou une partie des opérations d'entreprise, y compris son organisation et sa gestion ainsi que ses systèmes de pilotage et d'information. Ces modèles 13

25 sont utilisés pour guider l'implémentation du système opérationnel de l'entreprise (Particular Enterprise Operational Systems, EOS). Ces modèles particuliers peuvent être construits par «instanciation» puis adaptation de modèles génériques En fin Les modèles partiels (Partial Entreprise Model, PEMs) représentent les modèles réutilisables pour les rôles humaines, les processus ou les technologies. Figure 3 : éléments méthodologiques de GERAM [20], page 5. Outre ce cadre de référence, GERAM intègre aussi une démarche de modélisation basée sur un cycle de vie en sept phases [21] présenté dans la figure 4 : Phase d identification du contenu : pour une entité particulière, il s agit d identifier ses différentes activités, les limites de responsabilité et les relations avec l environnement. 14

26 Phase de définition des concepts de l'entité : C est l'ensemble d'activités qui sont nécessaires pour développer les concepts de l'entité fondamentale. Ces concepts incluent la définition de la mission de l'entité, vision, ses objectifs, ses concepts opérationnels, ses politiques, etc. Phase de définition des besoins : Ce sont les activités nécessaires pour définir les exigences opérationnelles de l'entité de l'entreprise, ses processus et tous besoins fonctionnels, comportementaux, informationnels. Phase de conception : Ce sont les activités qui définissent la spécification de l'entité avec l'ensemble de ses éléments qui satisfont aux exigences de l'entité. Ces activités incluent la conception de toutes les tâches humaines (tâches des individus et des entités d'organisation), et toutes les tâches automatisées. Phase de démantèlement : Ce sont les activités qui définissent toutes les tâches qui doivent être effectuées pour déconstruire l'entité. Phase de fonctionnement de l'entité : Ce sont les activités de l'entité qui sont nécessaires au cours de son fonctionnement pour fabriquer le produit demandé par les clients et réaliser au bon fonctionnement de l entité. Phase de recyclage de l'entité : ce sont les activités nécessaires pour recycler, réaffecter ou dissoudre un composant ou une entité toute entière en fin de sa vie. Figure 4 : Cycle de vie de GERAM [21] page 10 15

27 Le cadre fédérateur de GERAM présente l avantage principale de reposer sur une analyse critique des différentes architectures de modélisation d entreprise pour fournir un cadre de modélisation générique permettant de fédérer ces différentes méthodes et outils de modélisation. En effet GERAM est fondé sur les concepts de trois architectures (CIMOSA, GRAI-GIM et PERA) et a été définit dans un but de généricité. GERAM devrait donc être applicable à n importe quel type d entreprise [20]. D autres avantages sont également présentés par GERAM (par rapport aux autres méthodes) : GERAM permet de présenter et fédérer les différents éléments à développer pour réaliser l intégration d une entreprise. le cadre méthodologique de GERAM couvre l ensemble du cycle de vie non seulement d un projet de modélisation mais surtout GERAM couvre la totalité du cycle de vie d une organisation Méthodes orientées «système d information» Les entreprises créent de la valeur en gérant leurs Systèmes d'information (noté SI) qui représentent l'ensemble de tous les éléments participant à la gestion, au traitement, au transport et à la diffusion de l'information au sein de leurs organisations structurelles. La mise en place d un système d information se révèle une démarche très difficile et coûteuse. Il s agit dans un premier temps d étudier les différents secteurs fonctionnels d'une entreprise (achat, production, administration, ventes, maintenance, etc.) afin d aboutir à une structuration de ces activités et à une capitalisation de l'ensemble de ces informations échangées permettant ainsi d'en améliorer ses performances et son évolutivité. Il existe plusieurs méthodes d'analyse et de conception comme MERISE, SADT, OSSAD ou UML. Les trois premières méthodes représentatives de la conception du système d information dans une logique séparant données et traitements ont été utilisées dans des projets de grande ampleur de refonte d'un existant complexe ou le développement d un 16

28 nouveau système. La méthode UML en revanche respecte une logique orientée objet et encapsule données et traitement dans des composants. La méthode SADT (Structured Analysis and Design Technique) [22] est une méthode graphique établie par Douglas T.Ross (Softech) vers SADT distingue deux types de modèles : les actigrames qui représentent les activités ou traitements du système modélisé et les datagrames, représentant les données du système modélisé. SADT est basée sur le principe de décomposition hiérarchique et structurée des fonctions de l entreprise qui sont définies en termes d activité. Une activité peut être considérée comme une fonction de transformation d entrées (information ou matière) en sorties (informations ou matières) voir la figure 5. Cette vision permet donc d agréger ces différentes vues. Figure 5 : La modélisation d une activité L exécution de l activité est déclenchée par un (ou plusieurs) contrôle(s). La figure 6 représente une activité, les relations d une activité avec les autres activités au moyen de flèches. Les flèches entrant par le côté gauche du rectangle présentent les entrées de l activité, les flèches sortant par le côté droit du rectangle représentent les sorties de l activité. Les flèches entrant par la base du rectangle présent les mécanismes utilisés par l activité (les ressources nécessaires au déroulement de l activité. Enfin, les flèches entrant par le haut de rectangle présent les contrôles de l activité. En revanche, la méthode MERISE [23] [24,25] qui a été conçue pour réaliser la conception et la mise en œuvre des systèmes d information s appuie d une part sur la séparation des données et des traitements et d autres parts sur l organisation de différents points de vue (conceptuel, 17

29 logique et physique). Basée sur la proposition du modèle entité/association, la méthode MERISE, est très employée en France. Cette approche entité / association a largement été diffusée à l échelle mondiale par Peter CHEN. La méthode MERISE propose une démarche d ingénierie des systèmes d information couplant approches bottom-up et top-down : l étude de l existant doit permettre de remonter du niveau physique (implémentation) jusqu à la construction d une vision conceptuelle qui est ensuite améliorée. Une fois défini conceptuellement les modèles de données et traitement, ceux-ci sont ensuite transformés pour aboutir aux modèles physiques d implémentation. Le niveau conceptuel permet la description de l entreprise (objectifs généraux et contraintes). Il apporte la réponse à la question quoi (aspect fonctionnel) et représente le niveau le plus stable du système-entreprise. Le niveau organisationnel répond aux questions qui, où et quand?. il décrit la structure à mettre en place pour satisfaire les objectifs décrits au niveau précédent et représente un deuxième niveau de variabilité du système. Le niveau physique définit les moyens techniques à mettre en œuvre pour réaliser le système d information. Il répond à la question comment?. Cette méthode initialement définie pour les grands systèmes a ensuite été étendue pour y intégrer différentes évolutions technologiques. La méthode OSSAD (Office Support System Analysis and Design) [26] est une méthode de modélisation du système d information née dans le contexte d un projet Européen ESPRIT (European Strategic Programme for Research in Information Technology). Elle fonctionne suivant deux niveaux : Le modèle abstrait (MA) a comme objectif de formaliser les caractéristiques stables et durables du système. Dans ce modèle, on trouve des concepts qui sont liés à l activité. Il s agit des concepts de Fonction (nom donnés aux processus), de l organisation (exemple : marketing, production), de Sousfonction (sous processus) et d Activité. Notons que les fonctions ou sous-fonctions échangent des messages qui sont associés au concept de paquet d informations. 18

30 Le modèle descriptif (MD) décrit la façon pratique dont le travail est (ou sera) fait. Il propose les Rôles qui sont l ensemble des Tâches/responsabilités confiées à une personne : c est la fonction professionnelle de l individu. Les Acteurs sont des personnes remplissant un ou plusieurs Rôles. Les unités sont des regroupements de rôles sur la base de responsabilités identiques ou partagées. Ces trois méthodes représentatives d'analyse et de conception s articulent principalement autour de deux axes séparés à savoir les modèles de données et les modèles de traitements (ou les activités). Cette distinction entre les données et les activités nécessitent une gestion particulière pour maintenir la cohérence entre les activités et les données manipulées par ces activités. Cette gestion est fastidieuse lorsque le métier d une entreprise évolue face aux changements organisationnels, économiques ou technologiques. De manière orthogonale, la méthode UML propose une stratégie de modélisation orientée objet. L avantage de cette approche est d encapsuler les données et les opérations qui les traitent sous forme de classes. Ces classes représentent des objets métiers ayant un sens pour des acteurs de l entreprise. Le modèle des objets métier, qui est constitué d'un ou plusieurs classes (diagrammes de classe en UML), est de très haut niveau par rapport au système d'information et permet de donner une vision plus synthétique. Enfin, la large variété des modèles proposés par UML permet d appréhender à la fois une description statique portant sur les diagrammes de classes, de composants associés à l organisation effective de la solution et une vision dynamique intégrant des cas d usage (les «use case»), l organisation temporelle des échanges entre composants, une vision à base d automates à états finis En outre, les possibilités d instanciation et d héritage entre classes permettent de synthétiser les descriptions et améliorer la réutilisabilité. 19

31 2.2.6 Conclusion Comme nous venons de le voir, différentes méthodes de modélisation d entreprise ont été proposées depuis les années 80. L organisation d une entreprise regroupant différentes facettes, plusieurs méthodes peuvent être nécessaires pour couvrir l ensemble des besoins. Ainsi, le cadre de modélisation GERAM permet de les fédérer pour aboutir à une vision la plus exhaustive possible tout en préservant la cohérence globale. L ensemble de ces méthodes repose sur une conduite de projet dans une logique «top-down» de construction de modèle et de déploiement de la solution. Pour pallier les problèmes de complexité et de lourdeur de la démarche de modélisation, ces méthodes reposent toutes sur deux éléments invariants : l instanciation de modèles générique et la transformation de modèles pour permettre d aboutir à une solution déployable. Si la modélisation d entreprise reste fondamentale pour décrire globalement l entreprise et son organisation, la construction du système d information (conditionnant fortement la structuration de l entreprise) fait appel à d autres stratégies de modélisation se focalisant sur les processus à mettre en œuvre et sur l organisation des données. Toutefois ces méthodes spécialisées restent également complexes et lourdes à mettre en œuvre. Or l organisation collaborative repose sur la mise en place (rapide si possible) d un processus commun permettant d aboutir au résultat global souhaité objet de la collaboration et sur l organisation du support technologique à la collaboration (i.e. modélisation du système d information et organisation des interconnexions entre processus différents). Pour cela, nous présenterons les caractéristiques principales des approches basées processus dans la section suivante. 2.3 Approche basée processus Le processus métier est au cœur de la collaboration entre les entreprises : en effet, on peut le considérer comme un moyen pour atteindre l objectif commun (à savoir répondre aux besoins du client). 20

32 Nous nous intéresserons d abord aux définitions usuelles d un processus afin d en extraire les éléments de modélisation. Ensuite, nous présenterons les différents types de processus. Une introduction sur les technologies de workflow, qui permettent une mise en œuvre rapide des modèles de processus sera ensuite présentée. Enfin, nous conclurons cette section en repositionnant le processus dans un cadre plus large de modélisation Eléments caractéristiques d un modèle de processus Différentes définitions du processus sont proposées dans la littérature. Par exemple, [7] (p 9) définit le processus métier comme «un ensemble de plusieurs activités reliées les unes aux autres pour atteindre un objectif». Cette définition, basée uniquement sur le but à atteindre, peut être précisée par celle proposée par [8] en intégrant les moyens nécessaires pour atteindre ce but : un processus est défini comme un ensemble d activités ordonnées selon un ensemble de règles procédurales pour réaliser un objectif précis au sein d une organisation et réalisé par un groupe de personnes (par exemple, dans une entreprise). Une vision plus «systémique» conduit à appréhender la notion de processus comme un système composé d ensemble d éléments (activités, rôles, acteurs, ressources, entrées, résultats ) qu il faudra prendre en compte dans la modélisation du processus métier. On notera que ces définitions sont essentiellement «descriptive» [9]. Or un processus peut aussi être considéré comme un système dynamique orienté vers la réalisation d un objectif [10]. Dans la figure 6 ci-après nous présentons une synthèse de ces visions, intégrant à la fois les éléments statique (acteur, rôle, ressource, activité ), la partie dynamique du système (événement, transition ) et leur relations. 21

33 [10] page 16. Figure 6 : Les éléments principaux pour la modélisation d un processus métier Le concept d activité peut être défini comme unité de décomposition fonctionnelle du processus [10]. Les activités décrivent comment l objectif d un processus (décrit de manière détaillée) pourra être atteint. Les concepts de rôle et d acteur sont fortement liés. On notera d ailleurs que certains langages de modélisation n ont qu un seul concept pour ces deux notions. Un acteur est un élément actif chargé d une ou plusieurs activités dans le processus ([10] page 3). Un «élément actif» peut être une personne physique, une entité organisationnelle ou une machine. Ce sont les acteurs qui assurent l exécution des travaux d un processus. Le concept d acteur permet de faire apparaître les choix d automatisation (automate et / ou être humains) et d organisation à plusieurs niveaux (individu, service, département, etc.). Pour pouvoir être chargé d une ou plusieurs activités, 22

34 l acteur doit être capable d exécuter les travaux associés ou d en porter la responsabilité. Un rôle est un regroupement d activités (regroupement parfois limité à une seule activité ou bien intégrant différentes activités associées à des processus différents) données à un acteur unique. Le rôle représente le comportement attendu de l élément actif à qui on a attribué les activités associées à ce rôle. Une transition exprime une contrainte d enchaînement entre deux activités. On peut la considérer comme un lien orienté entre ces activités. L ensemble des transitions d un processus représente l ordonnancement de ses activités. Le concept de transition est utilisé lorsque l on veut représenter un enchaînement de plusieurs activités. Si la transition n est pas soumise à une condition, l enchaînement est mécanique : la fin d une activité déclenche la suivante. Une transition peut être soumise à condition. Elle peut être utilisée simultanément avec ou à la place de concepts d événement, d entrée et de résultat. Une condition peut être associée à une transition et dans ce cas l la transition n est réalisée que lorsque la condition est remplie. Cela signifie que la dernière tâche de l activité située au début de la transition analyse l expression associée à la condition pour déterminer si le passage à l activité suivante va s effectuer. Les conditions sur les transitions permettent de représenter des chemins alternatifs dans le déroulement du processus, ainsi que des boucles d une activité ou un ensemble d activités tant qu une condition est réalisée. Une tâche est le plus petit élément de décomposition d une activité. Lorsque l activité est décomposée, une activité peut être définie comme un ensemble de tâches. La tâche n a pas d autonomie par rapport à l activité dont elle dépend. Elle peut toutefois être soumise à une condition d activation. Une activité est activée par un événement. Cet événement n implique aucun acteur de l activité et ne consomme aucune de ses ressources. L événement métier déclencheur qui est à l origine de l exécution du processus peut être un échange avec le monde extérieur (par exemple : l événement envoi d une lettre au client réclamant des informations complémentaires pour traiter la demande est un événement en sortie d une activité de l entreprise et sera «déclencheur» pour une 23

35 activité du client alors que l événement réception de la réponse du client est un événement déclencheur pour une activité de l entreprise considérée). Un événement est toujours associé à au moins une activité sur laquelle il agit. Un même événement peut agir sur plusieurs activités : cela permet d activer des activités pouvant se dérouler en parallèle. A l inverse, plusieurs événements peuvent être associés à la même activité : celle-ci est alors dotée d une règle de synchronisation qui indique si les événements doivent être ou non synchronisés. On notera qu une condition peut être associée à un événement. Cela signifie que certaines tâches sont implicites dans la description de l activité. Ces tâches filtres analysent l expression conditionnelle attachée à l événement pour décider de la prise en compte ou non de cet événement. S il est interrupteur, cela signifie qu une tâche de surveillance des événements peut arrêter le déroulement de l activité, après réalisation éventuelle d une tâche spécifique d interruption, soumise à une même condition. Si l événement est modificateur, il agit sur le déroulement de l activité ; la condition se retrouve alors sur une ou plusieurs tâches qui ne seront exécutées que si la condition est remplie (ou à l inverse n est pas remplie). Le résultat est un produit issu de l exécution d une activité. Il est associé à l achèvement de l activité. Une activité peut produire plusieurs résultats. Un résultat peut être de différentes natures : matériel, documentaire, informationnel. Il peut également correspondre à un changement d état d un élément du système. Une ressource est un élément (matériel, documentaire, informationnel, logiciel ) utilisé pour l exécution d une activité. Selon la nature de l activité, plusieurs types de processus peuvent être organisés. Le niveau de description a priori des activités va dépendre directement du niveau de «répétitivité» de ces activités. Ceci conduit donc à différents niveaux de modélisation. Dans le paragraphe suivant nous présentons une synthèse sur les différents types de processus métier Typologie des processus D'après [9][11] les processus peuvent être classés selon quatre catégories complémentaires : 24

36 1. Le processus d administration : Il gère des processus administratifs dont les règles de déroulement sont bien établies et connues par chacun au sein de l organisation. Il est caractérisé par la circulation de documents/formulaires à travers l organisation (par exemple, demande de remboursement de frais de missions, demande d inscription à une formation, etc.). De ce fait, il aide à transformer la circulation de documents papiers en circulation de documents électroniques. Les processus d administration ne sont pas d une très grande valeur ajoutée pour une organisation d une part, et d autre part, ils sont assez statiques si l on considère leur degré de répétition élevé. 2. Le processus de production : Il gère les processus de production dans les entreprises. Il constitue généralement le cœur de métier de l entreprise et la valeur ajoutée de l entreprise dépend énormément de la qualité de ce processus. C est l efficacité de ce type de processus qui assure à l entreprise des avantages compétitifs (par exemple, processus de livraison pour une entreprise de vente en ligne, processus de gestion des prêts dans une banque, processus de gestion des demandes des dommages et intérêts au sein d une compagnie d assurance, processus de gestion de la chaîne de production chez un constructeur automobile, etc.). 3. Le processus de collaboration: Il gère la coordination au sein du groupe lors d un projet commun (par exemple, conception logicielle, réalisation d un plan de bâtiment, montage d un projet, réalisation d une œuvre artistique, etc.). Il est caractérisé par une forte valeur ajoutée au sein de l organisation, mais par un faible degré de répétition. Il se distingue des autres processus par le grand nombre de participants qui interagissent en permanence pour la réalisation du projet en commun. La complexité de ce type de processus réside dans la difficulté de modélisation de la méthodologie de travail à suivre surtout qu il faut prévoir, pendant le déroulement du processus, l arrivée de nouveaux participants, la création de nouvelles tâches à intégrer et à gérer, etc. Il s agit par exemple, d un processus de coordination apprenant-apprenant et apprenant-enseignant dans un environnement d apprentissage coopératif (Computer Supported Cooperative Learning ou CSCL), etc. 4. Le processus ad-hoc : Il représente une classe de processus destinés à des situations spécifiques où la logique de déroulement à 25

37 suivre est définie durant l exécution. Il forme une solution hybride rassemblant des caractéristiques d administration, de production et de collaboration. Ce type de processus gère des situations uniques ou causées par des exceptions. Généralement, ce type de processus ne possède pas de structure prédéfinie, l étape ultérieure à suivre est déterminée essentiellement par les participants du processus. Par exemple, si un coordinateur envoie une note d information aux membres de son équipe, ces derniers ont le choix de faire ce qu ils veulent avec cette note. Ils peuvent éventuellement la renvoyer à d autres personnes qu elle peut intéresser (par exemple, par messagerie électronique, dans les newsgroups, au sein d outils groupware, etc.). Comme on peut le constater, ces différents types de processus vont nécessiter des descriptions et modèles plus ou moins complexes. Ils impliquent des stratégies de gestion adaptées mais aussi le recours à des outils supports différents. Dans la suite, nous présentons rapidement les stratégies de gestion de processus métier Gestion de processus métier Le concept de processus métier est souvent associé au concept de Gestion des processus métier (ou BPM: Business Process Management). Le BPM consiste à modéliser des processus métier pour donner une vision globale sur ces processus et de leurs interactions afin de pouvoir les optimiser dans la mesure possible [12][35]. Dans le cadre du BPM, la gestion de processus métier comporte essentiellement trois étapes: l identification des processus; la description (modélisation) des processus en vue de leur mise en œuvre; le pilotage du processus en vue de son amélioration. - L identification des processus consiste à répertorier les processus de l entreprise en distinguant les processus liés au cœur de métier et les processus de support. Cette identification porte aussi sur la nature du processus (processus manuels ou informatisables). - La description (modélisation) des processus permet de formaliser le processus avec des outils spécifiques de modélisation ou de BPM. Deux approches complémentaires peuvent être appliquées : approches descendante ou ascendante. L approche descendante part du 26

38 général vers le plus détaillé par raffinements successifs. Le processus est d abord découpé en sous-processus et qui eux-mêmes sont découpés progressivement en activités, tâches et actions. Une approche ascendante part des parties de processus déjà modélisées, isolées comme des composants pour reconstruire un processus global par assemblage de composants de processus. - Le pilotage des processus est le passage obligé de leur amélioration. Il passe par la recherche de données pertinentes d exécution des processus, leur enregistrement dans une base de données et le calcul d indicateurs d analyse et de performance permettant d apprécier leur pertinence. - L orchestration des échanges interentreprises est une gestion des flux de messages qui gère le protocole de la transaction électronique entre les systèmes d information des entreprises impliquées. - La gestion de processus métier permet d orchestrer les interventions de personnes de l organisation et de logiciels du système d information dans la réalisation d un processus métier complet de l entreprise. Ainsi, les activités de BPM concernent l ensemble du cycle de vie d un processus métier, depuis son identification jusqu à son exécution en passant par les activités de modélisation. Pour ce dernier point, on peut recourir à une méthode «spécialisée processus» comme ARIS que nous présentons dans la section suivante ARIS : une méthode de modélisation orientée processus La méthode ARIS (Architecture of integrated Information Systems) [16][41] est un framework pour le développement et l optimisation des systèmes d information intégrés et permet de servir de cadre pour la création, l analyse et l évaluation des processus de gestion. ARIS permet la description des processus métier et permet de réduire leur complexité en les décomposant selon différentes vues (fonction, données, organisation et contrôle voir figure 7) et trois niveaux de modélisation (modèle conceptuel, modèle technique et implémentation voir figure 8). 27

39 Figure 7 : l'architecture d'aris [41] page 40 Figure 8 : Aris les niveaux de modélisation pour le processus de l entreprise [41] page 3 28

40 Les différents niveaux peuvent être décrits comme suit : - Niveau 1 : ingénierie du processus : Le processus métier est modélisé selon le modèle organisationnel. ARIS offre un cadre pour représenter tous les aspects du processus métier, y Compris l amélioration continue. - Niveau 2 : planification et contrôle de processus. Le processus métier est planifié et contrôlé selon les méthodes d ordonnancements en prenant en compte les contraintes de capacité et l analyse de coût. - Niveau 3 : contrôle du Workflow. Les objets à traiter sont transférés d un poste de travail au suivant. Dans le cas où ces objets sont des documents électroniques, les systèmes de gestion de Workflow s occupent de ces transferts. - Niveau 4 : systèmes d application. Les fonctions impliquées dans un processus métier sont exécutées via les systèmes d application, depuis les systèmes d édition simples jusqu aux logiciels complexes orientés objets de business. Dans le cadre plus particulier des processus inter-entreprises, le workflow représentant le processus commun est utilisé pour interconnecter des processus propres à chaque entreprise associés à des tâches à réaliser par l un ou l autre des partenaires. Cette interconnexion pose un évident problème d organisation des communications et échanges entre processus. Ce point est détaillé dans la section suivante Stratégies d interconnexion de processus L interconnexion des processus est un problème qui a été déjà étudié depuis plusieurs années. L EDI (Electronic Data Interchange): est défini comme un moyen d échange les données informatisées et les documents commerciaux structurés entre différentes organisation [42]. L échange de données informatisées peut être utilisé pour transmettre de manière dématérialisée des documents tels que des demandes d achat, des avis d expédition et d autres types de correspondance commerciale standardisée entre partenaire commerciaux. Il permet aussi de 29

41 transmettre des informations financières et des paiements sous forme électronique. Le standard principalement mis en œuvre dans le cadre de l EDI est EDIFACT [43][44]. C est une norme de l UN/CEFACT (Nations Unies) définissant les messages échangés dans les domaines du commerce international, des achats, des transports, de la santé, etc. Malgré les avantages liés à la dématérialisation, les technologies traditionnelles d EDI sont considérées comme coûteux non seulement dans le déroulement des échanges mais aussi pour ce qui concerne les aspects de communication car ils recouraient fréquemment à des Réseaux à Valeur Ajoutée (RVA Value-Added Network VAN ). Ceci a donc limité l adoption de cette solution, notamment par les petites et moyennes entreprises. Une stratégie plus légère consiste à construire de manière ad hoc des modèles électroniques de collaboration permettant à différents partenaires d interconnecter leurs processus. Pour cela, on peut utiliser le langage XML (extensible Markup Language) [46] [47] pour définir des échanges de documents structurés. Une solution basée sur XML est moins difficile et moins coûteuse qu une solution EDI classique. XML supporte, la structuration de données complexes en s appuyant sur des principes simples et clairs qui sont : La lisibilité à la fois par les machines et par les utilisateurs, la définition sans ambiguïté du contenu et la structure d un document, la séparation entre structure du document et présentation du document constituent les principaux avantages de cette approche. Compte tenu de son ouverture et des possibilités d extension de modèles, ce langage est le standard le mieux standard adapté aux besoins actuels d interopérabilité entre les processus d entreprise. Toutefois, si deux processus utilisent XML, ils peuvent analyser les messages transmis, mais cela n assure pas que le processus récepteur analyse correctement les messages. Ceci impose donc de revoir l organisation des processus et de leur communication pour intégrer les contraintes de traitement sur les données échangées dès la conception de ces processus. Ceci conduit de facto à une multiplication des canaux de communication et introduit un couplage fort entre les processus. 30

42 De manière à permettre la communication entre applications et offrir un couplage lâche, on peut utiliser un middleware (intergiciel) gérant différentes interfaces. Les systèmes de type EAI (Entreprise Application Integation) [45] offrent un ensemble de connecteurs permettant d éviter l établissement de relations point à point spécifiques entre applications et ainsi éviter le syndrome «spaghetti». D autres middleware sont orientés messages (Message Oriented Middleware MOM). Le message représente un contrat entre le serveur qui gère le processus et le client invoquant les services du processus. Ainsi, les interfaces des processus de l entreprise sont définies par ces messages. L application cliente ne communique plus avec le serveur mais directement avec le middleware. Ceci transforme donc le problème d interconnexion entre processus en interconnexion du serveur et du client avec le MOM. Ainsi, le client n a plus à gérer les informations du module serveur (par exemple localisation, configuration, interface). Il existe plusieurs plates-formes qui supportent cette stratégie comme par exemple Microsoft MSMQ (Microsoft Message Queue Server) ou le service d événement de CORBA (CORBA Event Service). Une autre stratégie consiste à réorganiser le système d information de l entreprise pour mettre en œuvre une architecture orientée service. Outre un couplage lâche par échange de messages, ce type d architecture présente également l avantage de séparer l interface de l implémentation et offre plusieurs interfaces standardisées. Nous détaillons cette approche dans la section

43 2.3.6 Conclusion Comme nous l avons vu section 2.3, l organisation de collaboration repose largement sur l organisation d un processus commun. Ce processus collaboratif est organisé comme l interconnexion des différents processus des entreprises partenaires. Cette stratégie d analyse nous a conduit d abord à présenter la méthode ARIS, méthode largement orientée processus avant d introduire les besoins de communication entre processus. Si cette vision semble plus légère que celle introduite par les stratégies de modélisation traditionnelles et permet d aboutir plus rapidement à la génération d un système de workflow support, le problème d interconnexion impose d utiliser une stratégie de mise en œuvre recourant à des standards pour garantir l interopérabilité technologique. Pour cela, les architectures orientées services peuvent apporter une réponse. 2.4 Architecture orientée service : une réponse à l interopérabilité technologique D après [48], un service peut être défini de la manière suivante: Services are autonomous platform-independent computational entities that can be defined, published, discovered, selected, composed, managed and programmed using XML artefacts for the purpose of developing distributed interoperable applications Un service est un composant logiciel qui est représenté par deux éléments séparés : son interface qui permet de définir les modalités d accès au service (nom et paramètres des opérations publiques définissant les signatures des opérations) et son implémentation. Les éléments de l interface de chaque service sont : le nom du service, les données d entrée et de sortie et les opérations. Les services sont interconnectés via l échange de messages. L ensemble des opérations associées à un service présente la vue dynamique de ce service. Ces opération sont publié pour que être retrouvée, composée puis invoquée. 32

44 Chaque service peut être composé avec un autre service selon une stratégie de composition séquentielle ou parallèle [49]. Dans une logique de composition séquentielle, les services sont ordonnés et présentés de manière séquentielle. Dans une logique de composition parallèle, les services sont exécutés en parallèle De manière plus spécifique, un Service Web est un système logiciel identifié par une adresse URL, dont les interfaces publiques sont définies et décrites à l'aide de XML. Sa définition peut être découverte par d'autres systèmes logiciels. Ces systèmes peuvent alors interagir avec le Service Web d une manière prescrite par sa définition, utilisant les messages basé sur XML et transmis par les protocoles d'internet [50] page 7. Le modèle d architecture à base de service Web se compose de trois entités, le fournisseur de services, l annuaire de services et le demandeur de services. La figure 9 représente une modèle de service Web : Figure 9 : modèle de Service Web [51] page 5 Le fournisseur de services crée ou offre simplement le service Web. Le fournisseur de services doit décrire le Service Web dans un format standard, qui est XML et publie cette description dans un annuaire de services. L annuaire de service contient des informations supplémentaires sur le fournisseur de services, telles que l'adresse et des détails techniques sur le service. Le demandeur de service recherche l'information de l annuaire et utilise la description de service obtenue pour se «lier» au service ( Bind ) à et à invoquer le service Web. 33

45 Les opérations de publication, recherche et liaison de services permettent ainsi de supporter les communications entre applications fonctionnant sur différentes plates-formes et écrites en différents langages de programmation, Le langage de description de service Web WSDL (Web Services Description Language) utilise le format de XML pour décrire les méthodes fournies par un Service Web. Cette description inclut aussi les paramètres d'entrée et de sortie, les types de données et le protocole de transport, qui est généralement HTTP. Le standard UDDI (Universal Description Discovery and Integration ) permet de publier les services et les informations concernant le fournisseur de service. Cet annuaire représente une opportunité pour le demandeur de service pour trouver le fournisseur de service et obtenir les détails sur le service Web. Le protocole SOAP est utilisé pour l'échange de l'information au format XML parmi les entités impliquées dans le modèle de service Web. Dans la suite de cette section nous présenterons les différents standards permettant d atteindre un bon niveau d interopérabilité pour les services Description de service Afin de pouvoir interconnecter des services plusieurs formats existent afin de décrire l interface de service (comme WSDL (Web Service Definition Language)) ou de découvrir automatiquement un service (comme OWL-S). WSDL [52] est un format de description de l interface des services Web basée sur XML. Le document WSDL définit les services comme des collections de point finaux (points d entrée endpoints ) de réseaux aussi appelés ports. Via ces ports les services communiquent par échange de message. Chaque port est associé à une liaison (binding) spécifique. C est la liaison (binding) qui détermine comment on peut naccéder à l opération en utilisant un protocole de communication particulier (SOAP, http, ). Chaque opération est constituée d un ensemble de messages d entrée et de sortie. Chaque message contient une ou plusieurs données définies 34

46 par des types. Une liaison (binding) établit une correspondance entre le protocole utilisé pour communiquer, le port et l opération. La description d un service web grâce à WSDL est montrée dans la figure 10. Figure 10 : La description d un service web grâce à WSDL [53] p86 Du fait du développement du web sémantique, un annuaire de type UDDI ne suffit plus pour faire une sélection pertinente des services. Pour cela, OWL-S (Web Ontology Language for Services) [54] définit une ontologie de décrire les services en s appuyant sur le framework OWL. Ce langage, standardisé par W3C est issu du programme DAML-S du DARPA. L initiative OWL-S issue du projet américain DARPA / DAML vise à fournir une ontologie de service web basé sur OWL. Cette description doit permettre d améliorer la découverte automatique de services Web, leur invocation, composition ainsi que la surveillance de leur exécution. Cette ontologie permet de fournir des informations sur l objet du service et sur son fonctionnement. Pour ce qui concerne le premier point, l accent est mis sur ce que fournit le service et ce qu il requière. Il s agit majoritairement de son interface. Le deuxième point concerne le 35

47 comportement du service. Il se focalise sur la description des opérations et des chemins possibles lors de l exécution. Pour cela un service est défini selon 3 facette complémentaire (service profile, service model et service grounding voir figure 11) que nous détaillerons ci-après. Figure 11 : Ontologie OWL-S Le ServiceProfile fournit des informations sur un service qui peut être utilisé par un agent pour déterminer si le service répond à ses besoins, et s'il satisfait des contraintes telles que la sécurité, la localité, l'accessibilité, etc. Le profil d un service serviceprofiles se compose de trois types d'information : une description du service et le fournisseur de services ; le comportement fonctionnel du service; et plusieurs attributs fonctionnels conçus pour l'automatisation de sélection. Le profil inclut une description de haut niveau sur le service et son fournisseur, qui typiquement serait présentée aux utilisateurs lors de la navigation le registre de service. Le ServiceModel permet à un agent : (1) d effectuer une analyse plus détaillée pour savoir si le service répond à ses besoins ; (2) de composer des descriptions de service pour exécuter une tâche spécifique ; (3) de coordonner les activités des différents agents ; et (4) contrôler l'exécution du service. Les services sont accessibles au Web par des programmes ou des périphériques. Leur opération est décrite en termes de modèle de processus. Les deux composants principaux du modèle de processus sont Process Ontology qui décrit un service en termes de ses entrées, sorties, conditions antérieurs, effets, et Process Control Ontology qui 36

48 décrit chaque processus en termes de son état, y compris l'activation, l'exécution, et l'achèvement. Le ServiceGrounding spécifie comment accéder aux détails de service avec des formats de protocole et de message. Le Servicegrounding présente comment invoquer le service. Dans DAML- S, le ServiceProfile et le ServiceModel sont conçus comme des représentations abstraites ; seulement le ServiceGrounding traite le niveau concret de la spécification. Dans la suite nous présenterons comment les services échangent de messages grâce le protocole SOAP Communication entre service SOAP (Simple Object Access Control) [53] [55] est un protocole de communication et d échange de messages entre les Services Web fondé sur XML. Le protocole SOAP permet d invoquer un objet distance en communiquant les informations nécessaire à l appel (Nom de la méthode et sa signature dans un message au format XML communiqué via http). La réponse à la requête est aussi renvoyée encapsulée au format XML. Un message SOAP est une structure très simple qui comporte une enveloppe (envelop) qui est la partie obligatoire du message et contient le nom du message, l entête (header) est une partie optionnelle utilisée lorsque le message doit être traité par plusieurs intermédiaires et le corps du message. Le corps du message est une partie obligatoire et peut contenir un ou plusieurs autres corps contenu dans le même message. Il contient les données spécifiques à l application. Il permet d échanger l information avec le destinataire final du message Publication de service Universal Description Discovery and Integration (UDDI) est un protocole qui permet non seulement la publication et l interrogation des services Web mais aussi de découvrir des informations sur une entreprise et ses services web. Le composant principal d UDDI est son registre (figure 12. Il contient des documents XML où figurent des informations sur les entreprises et les services publiés. L annuaire UDDI 37

49 facilite la localisation d un service web et l agrégation des services web émanant d entreprises différentes. Figure 12 : Mécanismes d accès aux services fournis par un UDDI Registry [51] page 117. UDDI encode de trois types d'informations sur les services Web : 1. Les pages blanches : elles comportent les informations sur les entreprises et contiennent des informations sur le fournisseur de service telles que le nom, les coordonnées (adresses), etc. 2. Les pages jaunes sont composées d informations permettant de classifier l entreprise. Ces informations s appuient sur des standards de classification industrielle normalisée. 3. Les pages vertes fournissent des informations techniques concernant les services publiés. Ces pages contiennent des informations sur les processus métier, des descriptions de service, et des informations de liaison sur les services. L UDDI comporte quatre structures de données définies sous forme de schéma XML : BusinessEntity, businessservice, bindingtemplate et tmodel : La structure BusinessEntity représente les informations sur l entreprise qui offre les services dans l annuaire UDDI. Le businessservice inclut les informations relatives aux services offerts par l entreprise. BindingTemplate définit les informations concernant le lieu du service, le point d entrées du service (URL) et comment accéder au service (protocole d accès). tmodel : comprend l information concernant le mode d accès au service. 38

50 La figure 13 représente les principaux éléments et relations entre entités du modèle d information UDDI sous forme de diagramme de classes UML. Figure 13 : Modèle structurel des données de UDDI Registry [51] page 119 Nous avons définit dans les sections précédentes que les services communiquent en utilisant différent standards pour décrire leurs interfaces et encoder leurs messages comme les protocoles SOAP, UDDI, et WSDL pour réaliser l interconnexion. Ces standards utilisent XML. Mais pour réaliser une interconnexion cohérente entre l ensemble de services il faut bien définir l enchaînement des services selon un canevas prédéfini afin de les composer dans un processus métier pour répondre à des demandes qu un seul service ne peut pas la réaliser Description de la partie opérative des services La prise en œuvre d un processus via des services web suppose non seulement de pouvoir retrouver les services répondant aux besoins, les composer dans une chaîne cohérente mais aussi de pouvoir définir précisément le comportement de ces services. Comme nous l avons vu précédemment, ces services interagissent en échangeant des messages 39

51 [Plusieurs standards proposent des langages permettant de décrire la partie opérative des processus et des services [56]. Au niveau du processus, BPML (Business Process Markup language) [57], il est destiné à la modélisation des processus métier. Il définit un modèle formel pour l expression de processus exécutables ou abstraits supports du processus métier. BPEL (Buiness Process Execution Language) [58] est un standard à permettre la description de l enchainement des actions pour réaliser un processus en invoquant des entités comme des services. BPEL fournit une sémantique riche qui permet d exprimer le comportement de processus métier. Ce langage fait suite à des langages comme XLANG ou WSFL développés par Microsoft ou IBM. WS-BPEL ou BPEL4WS utilise donc un ensemble de balises pour définir l exécution de services. Dans un scénario typique, le processus BPEL reçoit une requête puis il invoque alors les services web impliqués et envoie la réponse au demandeur. Les processus BPEL communiquent avec d autres services web s appuient fortement sur la description WSDL. BPEL introduit des extensions à WSDL qui permettent de spécifier précisément dans le processus les relations entre plusieurs services web. Ces relations sont appelées les liens vers des partenaires. La figure 14 montre ces connexions entre un processus BPEL et des services web (liens vers des partenaires). Figure 14 : La connexion entre un processus BPEL et des services [59] page 74. Tout processus BPEL précise l ordre exact dans lequel les services web participants doivent être invoqués. Cette invocation peut être séquentielle ou parallèle ou conditionnelle. L appel d un service peut 40

52 par exemple dépendre d une valeur provenant d une invocation précédente. Un processus BPEL est constitué d étapes. Chacune d elle est appelée une activité. BPEL prend en charge les activités élémentaires et les activités structurées. Les activités élémentaires sont utilisées pour interagir avec une entité externe pour réaliser des tâches communes. Les activités structurées gèrent le flot global du processus. Elles indiquent quelle activité doit être exécutée et dans quel ordre. XLANG est un langage qui a été créé par Microsoft pour l orchestration de service Web [60]. XLANG est déjà implémenté dans le serveur BizTalk. XLANG définit un langage de description du comportement individuel d un service web qui participe à un processus métier. Il décrit également comment combiner de tels services web pour produire un processus métier multi participant Il s appuie sur la spécification WSDL (figure 15) Etendant la description WSDL, XLANG s attache à prendre en compte les fonctionnalités suivantes [60]: La construction de flux de contrôle séquentiels et parallèles, Les transactions longues avec compensation, La corrélation de messages, La gestion des exceptions de traitement internes et externes, La référence de service dynamique, WSFL est un langage également basé sur XML permettant de décrire des orchestrations des services web. Proposé par IBM, WSFL définit deux formes d orchestration de services web [59][61]. Le premier décrit les processus d entreprise comme des chorégraphies des services web comme XLANG, le second type définit les processus métier en explicitant les relations producteur/consommateur de message entre les différents services web constituant le processus global. Pour illustrer le premier style de composition (processus métier ou modèle de flux), nous proposons de prendre le cas d une entreprise souhaitant mettre en place une application web pour le traitement de bon de commande à l aide de services web externes et internes déjà développés. Il s agit d identifier : 41

53 Les processus élémentaires (par exemple, la vérification du crédit du donneur d ordre, le rejet d un bon de commande, le traitement de la commande, l envoi des marchandises, etc.). Les conditions d enchaînement des processus élémentaires, qualifiées de règles métier dans la terminologie WSFL (tout d abord, vérifier le crédit de l acheteur puis, suivant le résultat, rejeter ou traiter la commande, puis envoyer les marchandises). Le flot de données à chaque étape (prendre le bon de commande comme paramètre d entrée et le passer à la procédure de rejet ou de traitement, etc.). Dans WSFL les étapes du processus sont appelées activités et sont reliées par des liens de contrôle (passage explicite du contrôle d un processus élémentaire à un autre) et des liens d information (passage de données, avec transformation éventuelle, d un processus élémentaire à un autre). On indique pour chaque activité l identité du service web responsable de son exécution et les opérations à appeler grâce aux éléments <Export> et <PlugLink>. Les activités sont exécutées sous la responsabilité d un rôle qui les déroule dans un espace de travail spécifique, appelé lane. Figure 15 : Le document XLANG [59] page Composition et orchestration de services Lorsqu un service associé à un processus implique l interaction avec des autre services (pour appeler leurs fonctionnalités), on parlera de service composé ou composite. La composition de services permet de combiner 42

54 les fonctionnalités de plusieurs services dans un même processus métier afin de répondre à des demandes complexes qu un seul service ne peut pas réaliser. La composition nécessite les étapes suivantes : Tout d abord il faut découvrir les services qui peuvent répondre aux besoins de la composition. Cette opération de découverte se fait via les annuaires. Il faut ensuite définir l ordre d invocation des différents services et organiser l interaction entre les services qu on veut composer : il s agit alors d orchestration et de chorégraphie [66]. L orchestration organise a priori les interactions entre plusieurs services et organise à l avance la gestion des échanges de messages, condition d activation La chorégraphie quant à elle est réalisée «au fil de l eau» et ne concerne donc qu un seul service. Si on s intéresse maintenant au contrôle de l exécution, il faut prendre en compte à la faut la spécification des conditions de coordination et de gestion de transactions. La coordination de séquences d'opérations est nécessaire pour assurer l'exactitude et la cohérence. Pour cela, de nouveaux protocoles et abstractions sont nécessaires. Afin de fournir des abstractions de modélisation et de simplifier le développement de services Web, différents efforts de standardisation ont été menés aboutissant par exemple à la proposition de WS-Coordination [62] par IBM. WS-Coordination décrivent un framework pour coordination de service qui se compose de(figure 16): Un service d'activation comportant une opération qui permet à une application de créer un contexte de coordination. Un service d'enregistrement comportant une opération qui permet à une application d enregistre aux protocoles de coordination. un ensemble de protocoles de coordination. 43

55 Figure 16 : Le model de coordination [53] page 4 Les applications utilisent le service d'activation pour créer le contexte de coordination pour une activité. Une fois qu'un contexte de coordination est défni par une application, il peut alors envoyé par tout moyen à une autre application. Le contexte contient l'information nécessaire pour s'enregistrer dans l'activité et spécifier le comportement de coordination que l'application suivra. Une application qui reçoit un contexte de coordination peut utiliser le service d'enregistrement de l'application originale ou peut en utiliser un qui est spécifié par un intermédiaire. De cette manière une collection arbitraire de services Web peut coordonner leurs opérations conjointement. Outre les problèmes de coordination, l exécution d un service composite peut nécessiter un temps long et des échecs peuvent survenir lors de l exécution de certains services. Ceci conduit donc à devoir annuler tout le processus. Pour cela, on peut s intéresser aux travaux menés dans le domaine de la gestion de transaction. Une transaction est un groupe d'opérations logiques qui doivent toutes réussir ou échouer [63]. On peut dire qu une transaction est une séquence d opérations qui permet de passer d un état stable à un autre état stable. Les spécifications de Transaction de service se séparent en deux parties les transactions atomiques (Atomic Transaction (AT)) et les Activités métier (Business Activity (BA)). Une transaction atomique est une transaction qui remplit les propriétés ACID [64] [65] (Atomicité, Cohérence, Isolation, Durabilité) qui sont utilisées pour coordonner les activités de courte durée. La transaction atomique aussi garantit que tous les participants confirment ou annulent la transaction dans une logique de type "tout ou rien". Une transaction atomique est terminée soit dans l état "commit" (transaction 44

56 validée) soit dans l état "avort" (transaction annulée). Dans le cas d une transaction validée, toutes les modifications liées à son exécution deviennent durables. En revanche quand la transaction est avortée, toutes les modifications amenées par son exécution doivent être annulées. Une activité métier est utilisée pour coordonner les activités de longue durée. Des transactions de compensation sont utilisées dans cette activité pour garantir la cohérence et remettre le système dans l état stable initial si un utilisateur décide a posteriori d annuler une transaction (par exemple un utilisateur commande un bien par internet puis annule ultérieurement sa commande : il faut alors faire un mécanisme de rollback pour annuler le payement). Cette nouvelle transaction appelée transaction de compensation «compense» les effets de la transaction originale. Il faut donc en prévoir la spécification lors de la conception d un processus métier Conclusion L approche orientée service présente plusieurs avantages dans le cadre de l organisation d un processus collaboratif : - La possibilité de publication de services permet de diffuser largement une interface des processus privés de l entreprise qui pourront ensuite être «composés» dans une chaîne de services correspondant au processus commun - Le processus de sélection / composition permet quant à lui d organiser rapidement une chaîne de services répondant aux besoins exprimés - L utilisation de standards permet d obtenir des systèmes interopérables nativement Toutefois, ces services ne peuvent être contextualisés ce qui conduit à une multiplication des services correspondant aux différents contextes d exécution et donc à des risques d incohérence puisqu aucune relation ne peut être définie entre services ni entre services et modèles de processus. 45

57 2.5 Démarches orientées objet La programmation orientée objet a été introduite dans les années 70. Il s agissait alors d identifier des objets du monde réel et leur associer des briques logicielles. L objet encapsule données et traitement associé et permet de modéliser plus simplement le monde réel en identifiant des objets et les relations entre eux. Dans le contexte de travail collaboratif inter-entreprises, cette approche qui embarque simultanément les données et processus dans des objets et ne doit présenter qu une interface pour rendre l objet utilisable pourrait permettre de garantir une relative indépendance entre les parties publiques et privées. En effet, puisque tous les accès transitent par une interface publique, il devient donc possible de «masquer» les éléments internes (et donc de garantir le respect de contraintes de confidentialité dans le cas d un processus inter-entreprise interconnectant plusieurs objets privés propres aux différentes entreprises). Outre ce premier avantage, l approche objet présente aussi une certaine similarité avec les méthodes de modélisation d entreprise. En effet, il est possible de construire de nouveaux objets en utilisant les mécanismes d héritage de manière similaire à la génération de modèles particulier par instanciation de modèles génériques. La définition des instances lors de la création est donc largement facilitée puisque une grande partie des informations et méthodes pourront être héritées des classes de niveau supérieur. Ce sont ces éléments qui motivent notre recours à l approche orientée objet. Dans une première sous-section nous présenterons d abord les points clef de cette démarche avant d introduire quelques méthodes de modélisation basée sur cette approche Concepts de base de l approche objet L approche objet propose de modéliser un ensemble d entités du monde réel sous forme objets, c.à.d. sous formes d unités atomiques unissant un état, un comportement et une identité [27][28]. L état d un objet est représenté par l ensemble de ses attributs (ou propriétés), c'est- 46

58 à-dire l ensemble des informations qui caractérisent l objet. Le comportement d un objet est défini via des méthodes (ou opérations). Ce sont ces opérations qui permettent à l objet de communiquer avec l extérieur (par exemple avec d autres objets. A ce titre, l opération (décrite par son nom de méthode) est l un des paramètres des messages échangé lorsque deux objets communiquent. L identité permet de distinguer cet objet des les autres objets (exemple : l identité d un objet voiture peut être donné par son numéro d immatriculation). Un objet comporte donc à la fois une partie statique (associée à son état) et une partie dynamique décrivant son comportement (via les opérations). Plusieurs objets peuvent posséder une structure et un comportement communs. Il est alors possible de regrouper ces objet dans un modèle générale (la classe ). On dit alors que l objet est une instance de la classe. Chaque classe est définie par un ensemble d attributs (appelés variable d objet) qui décrivent la structure des objets associés à cette classe, et des opérations, appelées méthodes. Les liens qui relient les objets correspondent à une relation entre leur classe. On distingue trois familles de relations ayant des sémantiques différentes : - l association et l agrégation, - la généralisation et spécialisation, - l héritage. L association est utilisée pour lier les classes appartenant à des environnements similaires (exemple : lier un étudiant et son université, la relation entre l étudiant et l université est une association) voir la figure 17. Figure 17 : exemple d'association La relation d agrégation permet de rassembler les propriétés et de construire des objets complexes à partir d autres objets, appelé objets composants. L agrégation exprime un assemblage fort entre les objets. L agrégation est une relation de type partie de ou composé de (c.à.d. une relation composant/composé) voir la figure

59 Figure 18 : Exemple d'agrégation La généralisation et la spécialisation sont exprimées sur les hiérarchies de classes. La généralisation permet de regrouper des classes qui ont les mêmes caractéristiques dans une classe plus générale [28] (voir la figure 19). Inversement, la spécialisation permet de créer des classes plus spécialisées à partir d une classe existante. Figure 19 : exemple de généralisation La relation d héritage permet la réutilisation de propriétés par spécialisation de classes. La classe spécialisée est appelée sous-classe et la classe qu on spécialisé est appelée superclasse [28]. Ces liens d héritage permettent de transférer des propriétés (attributs et méthodes) de la class mère (superclasse) vers sous-classes. Ce dernier point nous intéresse particulièrement dans notre travail dans la mesure où il permet de générer des objets plus «précis». Enfin, l encapsulation permet de masquer les détails de l objet pour n en présenter qu une interface. Ceci permet de préserver l intégrité de l objet en différenciant l interface (publique) et l implémentation (invisible) [29]. Ainsi un objet et les données qui lui sont associées ne peuvent être manipulées que par les méthodes explicitement définies (et donc dont les noms et paramètres de ces méthodes figurent dans la spécification d interface) lors de la création de cet objet (voir figure 20). L encapsulation définit donc deux représentations de l objet : niveau externe (publique) et le niveau interne (partie privée). La spécification d interface (niveau externe) regroupe la partie visible de l objet c.à.d. les données communes et les méthodes publiques (noms et paramètres) c'est-à-dire les méthodes qui peuvent 48

60 être invoquées depuis l extérieur. En revanche, les données et méthodes figurant dans la partie privée ne peuvent être accédées que par des méthodes de ce même objet. Dans notre cas de processus collaboratif, la démarche objet permet de protéger efficacement les informations, savoir et savoir faire organisationnels privés d une entreprise en ne les rendant invocable qu au travers d une interface publique. Ceci justifie donc de privilégier des méthodes de modélisation orientée objet dans notre cas. Figure 20 : Schéma d un objet encapsulé Définition des Objets métier (Business objects) L objet métier est un concept utilisé pour représenter des ensembles d'information du Système d'information de l entreprise. Un objet métier est définit selon [30] page 4 A business object captures information about a real world (business) concept, operations on that concept, constraints on those operations, and relationships between that concept and other business concepts. The business concept can then be transformed into a software design and implementation. A business application can be specified in terms of interactions among a configuration of implemented business objects. Ce concept de business object permet donc de modéliser des entités (les «choses» qui existent dans l entreprise, ce sera par exemple la notion d employé) et les activités qui y sont associées [31]. Comme pour un objet traditionnel, l état d un objet métier est défini par les attributs de cet objet et son comportement est défini par les actions que cet objet métier peut exécuter pour atteindre un but [32]. Enfin, la prise en compte de relations de composition permet aussi définir récursivement les objets métier à partir d un objet pivot (représentant le 49

61 concept principal) et des éléments complémentaires (objets métier de plus bas niveau). L organisation de relations entre les objets permet de modéliser un système par agrégation de plusieurs objets. Les opérations représentent la vue dynamique de l objet métier [31][36] Méthodes de modélisation orientée objet Notre contexte d étude étant lié à l organisation de processus collaboratifs inter-entreprises et à la possibilité de générer les composants associés, nous limiterons notre présentation à deux méthodes, l une IEM orientée modélisation d entreprise et l autre UML orientée informatique IEM IEM (Integrated Enterprise Modelling) utilise la modélisation orientée objet pour modéliser des processus d entreprise [33][37]. Les concepts principaux utilisés par IEM sont l encapsulation des fonctions et des données dans un objet, le concept de classe et le principe d héritage. IEM représente les différents aspects d une entreprise manufacturière au travers d un modèle unique composé de 8 vues. Les vues fonctionnelle et informationnelle sont axées sur la représentation des processus de l entreprise indépendamment des aspects technologiques induits. Les aspects technologiques sont détaillés dans quatre vues : applicatifs, stockage de données, réseaux et matériel. Enfin deux vues, personnel et qualifications d une part et unité d organisation d autre part sont affectées à la gestion des ressources humaines. La vue informationnelle regroupe les objets de l entreprise. Les objets sont structurés en trois classes de base, selon leur usage dans les processus modélisés : les produits, les commandes et les ressources. La vue fonctionnelle représente les traitements effectués sur les objets dans le cadre du processus de production. Le concept de base utilisé pour la modélisation des traitements est l activité. Une activité transforme des objets au moyen de ressources sous l action de contrôles. IEM définit un modèle générique d activité, représenté en figure

62 Figure 21 : le modèle général d'activité d'iem Une activité avec toutes ses entrées et sorties définies est appelée activité complète. Si seules les entrées et sorties d objets sont définies, on parle de fonction. Enfin, en l absence d entrées et de sorties, on dit qu on a affaire à une action. En dehors des vues fonctionnelle et informationnelle, à chaque vue additionnelle est associés une classe qui est la racine de tous les objets compris dans ces vues. La modélisation des processus est réalisée selon les cinq étapes traditionnelles : L identification des objets. L identification des fonctions manipulant ces objets. L organisation des fonctions. Leur enchaînement est défini au moyen d opérateurs de connexion qui sont la séquence, l exécution en parallèle, l alternative, la jointure et la boucle. La description de chaque fonction au moyen des objets affectés, c'est-à-dire la définition des entrées et des sorties de chaque fonction. La décomposition des fonctions en sous-fonctions si le niveau de détail du modèle le requiert UML The Unified Modeling Language (UML) [34] propose un ensemble de diagrammes permettant de représenter un système informatique et son utilisation prévue dans l entreprise. UML couvre les différentes étapes du développement d un objet en offrant différent types de diagramme. 51

63 Le diagramme de structure définit les concepts statiques (ex : classe, attribut, opération, composants, package) qui sont nécessaires pour les diagrammes de classes, de composants et de déploiement. Cette partie comporte trois packages (Class, Composite Structure, Components). Le diagramme de classe représente la structure d une application orientée objet en montrant les classes et les relations qui s établissent entre elles. La représentation d une classe comporte trois parties, à savoir (1) le nom de la classe et ses propriétés, (2) les attributs et (3) les opérations. Plusieurs types de relations permettent de relier les classes : la généralisation, l association et la dépendance comme indique dans la figure 22. Ce diagramme permet de définir toute la structure conceptuelle d une application et toutes les contraintes ou règles de gestion. Dans ce diagramme l agrégation et la composition sont deux précisions supplémentaires de l association (relation qui peut s établir entre instances de classes) qui introduisent la notion de composition comme le montre par exemple la figure 23. Figure 22 : Représentation des relations entre classes [34] page 20. Figure 23 : Exemple d'agrégation et de composition [34] page

64 Dans cet exemple on présente une relation d agrégation une zone inclut plusieurs stations c-à-d qu elle est implicitement composée de plusieurs stations. La relation de composition est une relation de type agrégation mais comporte en plus une règle sur la gestion du modèle. Dans l exemple présenté, un client possède obligatoirement un compte et la suppression d un client entraîne implicitement la suppression de son compte. Le package de type «Composite Structure» contient plusieurs sous-packages qui permettent de spécifier la structure interne d une classe. Il décrit deux types de composition possibles : la collaboration et la classe structurée. La figure 24 représente la collaboration dans un diagramme de structure composite. Figure 24 : Exemple d'une collaboration dans un diagramme de structure composite [34] page 29 Ce diagramme montre comment est réalisée la collaboration en définissant les rôles et les classes qui y participent. Les rôles sont reliés entre eux par un connecteur qui représente tous les moyens qui permet à deux objets de se connaître afin de s échanger de l information : passage d une référence, communication par opération, définition d une variable commune, etc. Les collaborations servent à exprimer les rôles des classes dans la réalisation d un patron de conception (design pattern) voir la figure

65 Figure 25 : Représentation d'un design pattern dans un diagramme de structure composite [34] page 29 Le package «Components» inclut plusieurs modèles : Le diagramme de cas d utilisation (Use-Cases) définit les concepts qui permettent de spécifier les cas d utilisation d une application. Un cas d utilisation représente une séquence d interactions entre l application et ses utilisateurs. Le diagramme d état consiste à décrire l évolution d un système. Cette évolution est définie par les états(les états sont des conditions ou situation durant la vie d un objet qui satisfont certaines conditions, réalisent certaines activités et attendent certains événements.) Le diagramme d activité est destiné à modéliser les processus et les fonctions sans nécessairement recourir au concept d état. Les diagrammes d interaction décrivent principalement des objets échangeant des messages. Il y a deux types de diagrammes d interaction. Le diagramme de séquence décrit les échanges de message entre les objets. Le diagramme de communication permet de spécifier l ordre de séquencement, les messages sont numérotés suivant une logique hiérarchique. UML présente plusieurs avantages pour modéliser un processus collaboratif : - Le diagramme des cas d utilisation permet de décrire précisément l organisation du processus 54

66 collaboratif et les interactions entre les différents partenaires - Le diagramme de composants permet de présenter plusieurs niveaux de description permettant de séparer l interface (associée à un processus public publié par l entreprise) de l implémentation réelle (processus privé de l entreprise) - Le diagramme de classe permet quant à lui de spécialiser progressivement les différents éléments. Cette approche hiérarchique peut permettre de regrouper des services «contextualisés» dans une même classe afin de bénéficier des mécanismes d héritage et une meilleure réutilisation. 55

67 2.5.4 Conclusion L approche objet offre un ensemble de concepts et méthodes de modélisation pouvant apporter une réponse pour modéliser des processus collaboratifs entre entreprises. En effet, l encapsulation permet de protéger raisonnablement le patrimoine propre de chaque entreprise (données et processus traduisant son savoir-faire) tout en offrant la nécessaire ouverture sur le système (via la spécification des interfaces). Les nombreuses facettes permettant de décrire un objet proposé par la méthode UML permet également de bien couvrir la spécification d un processus collaboratif. Le cas d usage permet aux partenaires de décrire effectivement ce qu ils prévoient de faire de manière «ponctuelle». Les autres diagrammes permettent ensuite de préciser le «comment» et le «qui fait quoi et quand». Toutefois, modéliser ne peut suffire à mettre en œuvre un processus de collaboration. Il importe d une part de pouvoir transformer les modèles en logiciel support de ce processus. 2.6 Des modèles au logiciel L ingénierie dirigée par les modèles propose un environnement permettant d organiser les différentes étapes de modélisation pour aboutir à un logiciel de qualité. Cette démarche permet de bénéficier des possibilités d abstraction des modèles et d augmenter les possibilités de réutilisation. Parmi les initiatives mettant en œuvre cette démarche, l OMG, a proposé l approche MDA pour permettre d accroître l interopérabilité des applications en séparant clairement les spécifications fonctionnelles d un système des spécifications de son implémentation sur une plate-forme donnée [38][39]. Plusieurs niveaux de modélisation sont définis dans la figure 26 : Le niveau M0 (ou instance) : il définit les informations correspondant aux objets du monde réel. 56

68 Le niveaum1(ou modèle): il décrit les informations de M0. Les modèles UML appartiennent au niveau M1. Les modèles M1 sont des instances de M2. Figure 26 : Les niveaux de modélisation Le niveau M2 (ou méta modèle) est composé de langages de spécification de modèles, tels que UML, profil UML qui permet d étendre le méta modèle UML. Le niveau M3 (ou méta-méta-modèle) : est le plus haut niveau d abstraction pour une architecture de méta modélisation. Il comporte une entité unique qui s appelle MOF et qui permet de décrire la structure des méta-modèles. La démarche proposée par MDA est la construction d un ou plusieurs modèles indépendants des plates-formes (Platform Independent Model, PIM) suivie de la transformation de ces modèles en modèles dépendants des plates-formes (Platform Specific Model, PSM). Les différents niveaux de modélisation permettent de gérer les connaissances nécessaires à ces transformations. L approche MDA comporte différents modèles qui sont présentés dans la figure 27 ci-après. 57

69 Figure 27 : Les catégories de modèles dans MDA. Le modèle d exigences CIM (Computation Independent Model ou modèle indépendant de la programmation) est aussi appelé modèle de domaine. Il modélise les exigences du système. Un modèle d exigences ne contient pas d information sur la réalisation de l application ni sur les traitements ce qui justifie son appellation CIM. Il montre simplement le système dans l environnement organisationnel dans lequel il va être exécuté. La première étape à faire pendant la construction d une nouvelle application est de spécifier les besoins du client. L objectif de ce modèle est d aider à comprendre le problème et permet de représenter ce que doit être fait par le système. Les exigences qui sont exprimées dans le CIM doivent être transmises dans le PIM et le PSM [38] [39][40]. Le modèle de description de plateforme PDM (Plateform Description Model) contient les informations nécessaires sur la plateforme afin de transformer des modèles PIM en modèles PSM puis en code adapté pour une plateforme spécifique [39]. La construction du modèle d analyse et de conception abstraite PIM (Platform Independent Model) est la première étape de la démarche MDA. Un exemple de PIM est présenté dans la figure 28. Cette famille de modèles décrit le système sans montrer les détails des plateformes. Un modèle de cette famille (représenté par un diagramme UML) représente par exemple les différentes entités fonctionnelles du système ainsi que les connexions entre celles-ci. Ce type de modèle peut aussi être décrit avec un langage de contrainte comme OCL (Object Contraint Language) [40]. Cette indépendance de la plateforme permet d assurer une interopérabilité fonctionnelle. 58

70 Figure 28 : Exemple de PIM [40] page 8. Le modèle de code ou de conception concrète PSM (plateforme Specific model) est quant à lui dépendant des plates-formes techniques. Les modèles de cette famille servent de base à la génération de code exécutable vers les plates-formes techniques. Il existe plusieurs niveaux de PSM. Le premier est obtenu directement à partir de modèle PIM. Il est représenté par un schéma UML. Les autre niveaux de PSM sont obtenus via la transformation jusqu'à l obtention du système exécutable (obtention du code dans un langage spécifique (Java,C++, etc) comme c est montré dans la figure 29 [40]. Figure 29 : Relation entre PIM et PSM en modélisation EJBexpanded [40] page 9 Les transformations de modèles (voir figure 30) concernent à la fois les transformations de modèles d exigences (CIM) en modèles fonctionnels (PIM) puis de modèles fonctionnels en modèles «technologiques» liés à la plateforme (PSM) puis en code [40]. Ces transformations sont essentielles à la pérennité des modèles : elles garantissent les liens de traçabilité entre les modèles et les besoins exprimé par le client. 59

71 La transformation de CIM vers PIM permet de construire des modèles de type PIM partiels à partir des informations contenues dans les modèles d exigences (CIM). L objectif est de s assurer que les besoins exprimés dans les modèles d exigence (CIM) sont retranscrits dans les PIM. Les transformations de modèles PIM à PIM sont généralement appliquées pour ajouter (ou enlever) des informations à des modèles. Par exemple quand on passe de la phase d analyse à la phase de conception, cette transformation permet de raffiner les modèles pour améliorer la précision des informations qu ils contiennent. Ces transformations qui comportent une grande part de connaissances ne sont pas généralement automatisable. Figure 30 : Etapes du processus MDA [40] page 6. Les transformations de modèles fonctionnels (PIM) vers des modèles spécifiques des plateformes utilisées (PSM) sont les plus importantes de la démarche MDA car elles garantissent la pérennité des modèles. Pour réaliser ces transformations vers des modèles intégrant les spécificités des plateformes il faut enrichir le modèle initial (de type PIM) pour le spécialiser vers une plate forme donnée. Cette opération consiste à ajouter des informations liées à une plateforme technique pour pouvoir enfin générer le code. Les principales plates formes PSM possible sont 60

72 J2EE, CORBA, XML/SOAP, ces plates formes sont montré dans la figure 31[38]. Figure 31 : Exemple d utilisation des modèles pour réaliser une application [38] page 5. Des transformations de type PSM vers PSM s appliquent sur un modèle spécifique afin d obtenir un autre modèle spécifique à la même plate-forme. Ces transformations sont utilisées lors des phases de déploiement, d optimisation, de raffinement ou de configuration (figure 32). Figure 32 : Transformations des modèles [38] page 6. Enfin, une démarche de rétro-ingénierie peut utiliser une transformation de type PSM à PIM afin de revenir à un modèle 61

73 indépendant de plate forme(pim) à partir d un modèle spécifique de plate forme (PSM). Ce type de transformation complexe à réaliser et plus difficile à automatiser. Cette démarche dirigée par les modèles est très riche dans la mesure où elle permet de prendre en compte les différents points de vue de modélisation. Sa richesse constitue à la fois son principal atout et son principal handicap pour le domaine qui nous concerne, à savoir la collaboration entre entreprises. Nous identifions trois limites pour ce contexte particulier. D une part la modélisation de collaboration entre entreprise s appuie principalement sur une vision «processus» et ne doit pas remettre en cause la totalité du système d information. D autre part la complétude de ces démarches imposent une durée d ingénierie d autant plus élevée que nombre de transformations ne sont pas automatisables. Cette durée peut s avérer incompatible avec la durée de vie du «projet de collaboration» (en d autres termes, il ne faudrait pas que la mise à disposition de l environnement de collaboration soit plus long que la collaboration elle-même). Enfin, sir la démarche de transformation permet d organiser une certaine interopérabilité applicative au niveau fonctionnelle, elle ne permet pas de définir une réelle interopérabilité au niveau technologique. 2.7 Conclusion L organisation de collaborations inter-entreprises (voire de coindustrie) conduit à l émergence d entreprises virtuelles et fait largement appel aux technologies de l information et de la communication. Ces pratiques collaboratives sont limitées à la fois en raison de la nécessaire modélisation et structuration des processus et des contraintes technologiques liées aux systèmes d information d entreprise, organisés en silo fonctionnels, et limitant la mise en place des collaborations du fait de leur rigidité (ils ne répondent donc pas au besoin d agilité) et de leur manque d ouverture (ce qui pose un problème d interopérabilité). La première limite, liée à la formalisation les processus de collaboration et les informations échangées suppose que chaque partenaire dispose de modèles permettant de décrire son activité et son 62

74 SI. Or les méthodes de modélisation traditionnelles sont souvent lourdes et nécessitent une durée de projet incompatible avec l horizon court ou moyen terme impliqué par une collaboration. Pour faciliter cette activité d ingénierie, la plupart des méthodes proposent des architectures permettant d utiliser un modèle générique puis de le particulariser. Cette approche, assez similaire au processus d instanciation de l approche objet, permet effectivement de simplifier l ingénierie en définissant des «bonnes pratiques» mais ne permet pas de s adapter à l organisation de l entreprise et aux changements de contexte : les modèles sont particularisés dans une approche top-down et tout changement impose de recommencer l activité d ingénierie. En outre, les méthodes de modélisation d entreprise n interfèrent que peu avec les méthodes de modélisation permettant la génération de code, introduisant ainsi une dichotomie entre espace de business et espace technologique. De la même manière, les processus de générations proposés dans la démarche MDA sont aussi organisés de manière hiérarchisée dans une logique topdown et ne permettent pas de «tisser» dynamiquement différents modèles contextuels. La deuxième limite que nous avons identifié concerne la réponse technologique : outre les coûts liés à l infrastructure informatique (matérielle et logicielle), les Systèmes d Information (SI) d entreprise ne sont que peu agiles et ne prennent pas réellement en compte les logiques de production. Les démarches d urbanisation et l organisation d architectures orientées services, visant à rendre les SI agiles, sont basées sur une organisation «métier» de l entreprise, reflétant plus l organigramme (achat, production, relation client ), que l organisation industrielle ce qui ne permet ni de pouvoir construire à la demande des organisations de co-production efficientes ni de rendre le système d information réellement adaptable (pour suivre de manière continuelle les stratégies industrielles) et pervasif (pour s adapter aux différents modes de suivi et de traçabilité de la production).. Si les architectures à base de services assurent une interopérabilité «syntaxique» et technologique, elles n apportent pas de réponse au niveau organisationnel. En outre, elles ne permettent pas de gérer des services contextualisés. Pour pallier les limites, il faudrait pouvoir apporter la flexibilité et l agilité des opérations de composition de service aux 63

75 stratégies de modélisation. Pour cela, nous proposons d étendre les travaux de thèse de Sodki Chaari [69] réalisés dans notre équipe. Il s agit de transformer l organisation traditionnelle de l entreprise en une organisation «d entreprise orientée service». Ainsi, une entreprise pourrait publier ses offres de services comme base pour établir des collaborations. L organisation d un processus collaboratif entre entreprises reviendrait ainsi à sélectionner et «composer» les services d entreprises pour former une chaîne répondant aux besoins du client puis générer le support informatique correspondant à ce contexte de collaboration. Pour offrir le meilleur niveau d interopérabilité possible, nous proposons de coupler plus étroitement les niveaux d affaire et technologique : l expression des besoins du client permet de définir les rôles et services qui devront être combinés pour former le processus collaboratif correspondant. Une fois identifiés ces services d affaire, ils sont composés dans une logique de processus et en fournissent donc un modèle abstrait. Pour aboutir au modèle «concret» du système support, il faut pouvoir transformer ces services abstraits en services technologiques composés en prenant en compte les contraintes de contexte. Pour cela, nous proposons de dépasser le simple cadre «topdown» de l ingénierie dirigée par les modèles pour passer à une logique de composition issue de l architecture orientée services d une part et de l héritage purement hiérarchique de l approche objet d autre part pour permettre de composer (ou «tisser») des modèles selon le contexte et être capable de propager ces contraintes contextuelles le long de la chaîne de services. Pour ce faire, il importe de définir une organisation non plus hiérarchique mais mixte en hypergraphe permettant d une part d améliorer la génération de services particuliers en utilisant pleinement les mécanismes d héritage et d autres part d utiliser les relations «latérales» pour propager les contraintes de contextes et améliorer les possibilité de substitution de services. Notons également que les possibilités d encapsulation apportées par la structure d hypergraphe peut permettre de masquer la complexité et le savoir-faire des processus propres de l entreprise en n en publiant que la vision «publique», c'està-dire le service de haut niveau. 64

76 Dans le chapitre 3, nous présenterons globalement le principe et l architecture retenue avant de détailler les différentes relations et mécanismes de construction de l hypergraphe dans le chapitre 4. 65

77 Chapitre 3 La collaboration des processus de l entreprise 3.1 Introduction L organisation d un système de collaborations entre entreprise suppose d abord une analyse de cette stratégie de collaboration : si dans le passé les entreprises pouvaient opérer seules dans des environnements relativement stables, les évolutions du marché (prise en compte de la dimension produit service, customisation de masse, recherche de réduction des coûts, globalisation, ) les conduisent à se recentrer sur leur cœur de métier et à construire de plus en plus de relations de collaborations plus ou moins durables avec des partenaires industriels. Les défis principaux de cette stratégie de collaboration sont (1) la sélection de partenaires industriels et / ou commerciaux appropriés, (2) l organisation et la mise en œuvre de processus appropriés en réponse aux besoins exprimés par les clients et ce avec des coûts de production acceptables et (3) disposer des moyens informatique nécessaires pour supporter ces fonctions de sélection et disposer rapidement des outils supports nécessaires pour l exécution de ce processus commun. Le premier défi suppose de pouvoir identifier les «services» proposés par les partenaires potentiels de manière à pouvoir les sélectionner. Le deuxième défi quant à lui impose une réorganisation des processus de l entreprise à la fois pour améliorer la productivité mais aussi pour avoir plus de souplesse et d agilité afin de répondre rapidement aux 66

78 changements de contextes liés au marché. Le troisième défi est quant à lui lié au développement des TIC induisant une nouvelle stratégie économique (économie numérique) et facilitant les échanges dématérialisés d information. Cette possibilité de recourir à une distribution des informations à large échelle a permis de faire émerger des entreprises virtuelles, c est à dire des entreprises regroupant dans une organisation collaboratives plusieurs partenaires partageant des ressources et travaillant ensemble pour atteindre un objectif commun. Le développement de ces stratégies de collaboration implique souplesse et agilité des entreprises tant en ce qui concerne leur organisation qu en ce qui concerne leur système d information. Ce développement bénéficie largement du développement des TIC et des technologies basées sur l Internet. En effet, le développement des services et des technologies de services web permet aux entreprises de pouvoir développer de manière plus rapide les supports informatiques nécessaires au développement de leurs processus en combinant des services mais cela pose d évidents problèmes d interopérabilité. Ainsi, un processus collaboratif peut être développé en construisant une chaîne de services intégrant des services offerts par différents fournisseurs à condition de pouvoir sélectionner puis «interconnecter» ces services, c'est-à-dire à condition que les entreprises publient ces services et développent des interfaces standardisées (ce qui est le cas lorsqu on utilise des technologies à base de services web). L enjeu principal est alors la capacité de s organiser pour collaborer et de partager de l'information entre les entreprises. Ceci pose alors le problème de l interopérabilité, tant en ce qui concerne l organisation (ce qui impacte l organisation et les conditions de travail) qu en ce qui concerne les technologies utilisées dans le système d information support. Pour répondre à ces exigences, nous nous focaliserons sur deux dimensions importantes : l agilité du système d information d une part et la construction de processus de collaboration d autre part. En effet, les systèmes d information d entreprises étant constitués de nombreux outils dédiés à des espaces métier particuliers (ERP, SCM, CRM ), il existe une forte complexité technologique et chaque système est relativement «figé» ce qui ne permet pas des (re)configurations rapides. En outre, ces systèmes étant relativement «fermés» et les formats d interfaces étant définis de manière spécifique (et souvent 67

79 incompatible), les échanges d informations (compréhensibles) entre partenaires sont donc limités. Dépasser cette limite impose d obtenir un niveau d interopérabilité suffisant. L interopérabilité dans l entreprise est définie comme la capacité des systèmes d information et des processus à supporter l échange des données et de permettre le partage d information et des connaissances [67]. Depuis quelques années, de nombreux travaux ont porté sur l interopérabilité, principalement pour ce qui concerne les applications. De nombreuses approches dans ce domaine ont pour but l adaptation des types et structures des paramètres d'appel quand un processus d entreprise doit invoquer un autre processus. Ceci a par exemple conduit au développement des architectures orientées services (SOA) [1] en réponse aux problématiques d'interopérabilité entre les différents systèmes qui implémentent les systèmes d'information des entreprises. Si cette approche apporte une solution adaptée au problème d interopérabilité dans l entreprise (donc interopérabilité entre les différents systèmes «métier»), elle reste limitée par une vision «monocontexte» du service, ce qui ne correspond pas réellement aux besoins d une collaboration inter-entreprises. En effet, un écosystème de services inclut un environnement multi-contextuel d exécution de services. Ainsi, l approche SOA impose de multiplier les services : chaque entreprise doit fournir plusieurs services, chacun relié à un contexte particulier, pour pouvoir intégrer convenablement les fonctions selon des besoins propres à chaque contexte. Ceci augmente donc la complexité du système et les risques d incohérence. Pour s adapter au contexte de collaboration inter-entreprises, il faut réorganiser l entreprise pour présenter une structure interopérable à tous les niveaux, i.e. niveaux organisation, d affaires (métier) et, technologiques : o L interopérabilité du niveau organisation impose d adapter les structures et les moyens d'organisation pour pouvoir construire des organisations dynamiques capables de fournir des réponses appropriées aux différents scénarios de collaboration. o L interopérabilité du niveau d affaire doit permettre la construction de processus de collaboration (pour la fabrication de produits ou de services) à partir des différents processus 68

80 appartenant aux différents partenaires. Les éléments industriels doivent être décrits, publiés et rendus accessibles par des plates-formes adaptées. o Enfin, l interopérabilité du niveau technique concerne les choix et moyens technologiques. Les entreprises doivent alors analyser leur système d'information afin de les adapter aux stratégies dynamiques de collaboration et faciliter l interopérabilité. Nos propositions pour améliorer l interopérabilité reposent sur un modèle multi-vues (gestion, médiation et sécurité) pour réaliser une bonne interconnexion entre les différents processus d entreprise. Comme dans la thèse de Mlle Rajsiri (voir [76]), nous proposons que le processus collaboratif soit conçu comme une chaîne de services. Ceci impose donc que chaque entreprise publie les services, pouvant intervenir dans un processus de collaboration, dans un répertoire propre. Ainsi, le processus de conception du processus collaboratif repose donc sur une sélection / composition. Comme dans [76], cet espace de conception s apparente à un modèle de type CIM : les services sont alors définis de manière abstraite et associé à des rôles. La transformation de ce modèle CIM en PIM puis PSM impose de transformer ces services abstraits en services concrets puis en services exécutables. Toutefois, à la différence de [76], notre modèle vise d une part une génération contextuelle des services et d autre part à faciliter la réutilisation, les processus de sélection/composition en ajoutant différentes relations entre les services d autres part. Tout d abord, nous lions la transformation du service abstrait en service concret au contexte (qui invoque le service, à partir de quel mode d accès, quand, avec quels besoins en qualité de service et sous quelles politiques de sécurité). Par exemple, un service abstrait d achat en ligne peut être réutilisé par plusieurs processus avec un rôle «Achat». Selon le contexte d accès au service (accès par un client final, un professionnel partenaire, un personnel de l entreprise) et l infrastructure d accès utilisé (PC et réseau privé, accès via internet, accès par téléphone portable ) différentes politiques de sécurité et différents services concrets (gérant des interface utilisateur spécialisées) pourront être déployés. 69

81 Ensuite, de manière à assurer la cohérence des services générés (modèles d interface, règles opératoires communes ) selon le contexte, nous avons choisi d encapsuler des services dans des objets pour utiliser pleinement le mécanisme d héritage (ce qui assure la cohérence entre les objets et facilite les opérations de mise à jour). Enfin, la structure du registre est enrichie par différents types de relations : - La relation d agrégation permet de définir des services comme englobant un chaîne de services élémentaire ce qui permet de gérer simplment plusieurs niveaux de détail dans la spécification des services et augmente les possibilités de réutilisation - La relation de similarité permet de définir des équivalences entre les services ce qui accélère notablement la sélection d un service adapté au moment de l exécution (sous réserve de disposer d un système de «late binding» adapté) ce qui est très important dans une logique de passage à l échelle (problème de scalabilité) - La relation de collaboration permet de disposer d informations objectives sur les collaborations précédentes pour sélection le(s) bon(s) partenaire(s) - La relation de recommandation permet enfin d assister l utilisateur dans la conception de la chaîne de service en indiquant quels autres services ont pu être utilisés conjointement. Ces relations et différentes descriptions permettent de sélectionner les services en fonction des besoins et de construire le processus commun comme une chaîne de services abstraits comme illustré dans la Figure33. 70

82 VS Contexte F i g Processus à base de services concrets u Vue Gestion Vue Médiation Vue Médiation Processus à base de services abstraits multi-contextuels re 33 : Comparaison entre processus collaboratifs traditionnels et multicontextuels L intégration des différentes vues permet de «superposer» différents éléments de contexte et, grâce à un «arbre d héritage», de contexualiser le service abstrait et donc aboutir à un service et un processus concrets. Pour cela, on intègre les contraintes de médiation entre les services (issues de la vue médiation) et les éléments de sécurité (déduit des politiques de sécurité exprimées dans la vue sécurité). Pour répondre à la contrainte de dynamicité, nous proposons que ces politiques soient exprimées dans une logique ECA (Event, Condition, Action) : l action est effectuée quand un événement donné se produit et que la condition est satisfaite. Pour prendre en compte ces différentes dimensions et permettre des héritages multiples, notre modèle est basé sur un hypergraphe permettant d introduire différentes stratégies d héritage et de multiples niveaux de description. Dans ce chapitre, nous présentons d abord l architecture globale avant de détailler les différentes vues et le processus de transformation avant de présenter le principe de construction d un 71

83 processus collaboratif. Le fonctionnement de l hypergraphe et son utilisation pour une orchestration cohérente seront quant à eux détaillés dans le chapitre suivant. 3.2 Architecture globale Notre architecture propose un modèle destiné à supporter la collaboration en sélectionnant les services nécessaires pour construire le processus collaboratif. Ce modèle repose sur les concepts suivants comme illustrés en Figure 34. Service Abstrait Services concrets Répertoire local Répertoire public Répertoire partagé de processus collaboratifs communs Figure 34 : Les concepts de base d une collaboration contextualisée 1. Le service abstrait : ce service fournit une description abstraite d une activité métier sans une description technique de son implémentation et son invocation. Il manipule les objets métiers passés comme des entrées et aide les partenaires à se concentrer sur la conception de processus de collaboration sans maitrise technique des services concrets. 2. Le service concret : est un service informatique qui implémente un service abstrait en respectant un modèle architectural (Service Web, DCOM, composant CORBA, etc.) et un langage de programmation (Java, C#, etc.). Dans notre approche les services concrets respectent la propriété du couplage lâche pour faciliter la réutilisation mais ils sont reliés par des relations sémantiques qui permettent de contextualiser l exécution (relation d héritage), faciliter la propagation des contraintes (relation d agrégation) et enrichir la robustesse et disponibilité (relation de similarité et relation de substitution). 72

84 3. Le répertoire local de services concrets : ce répertoire contient les services concrets et maintient les relations entre services. Il est interne à l entreprise et n est pas partagé avec les partenaires. 4. Le répertoire public de services abstraits : ce répertoire contient les services abstraits qu une entreprise souhaite partager avec ses partenaires. Les services abstraits pointent sur des services concrets interconnectés par les relations entre services (graphes de services). Il contient également les objets métiers manipulés par ces services abstraits. C est au moment de l exécution, 5. Le répertoire de processus collaboratifs communs : le processus collaboratif est conçu conjointement par les partenaires à partir de leurs services abstraits. Ce processus est vu comme une chaîne de services dont les informations contextuelles se propagent. Il est similaire à un patron (template) qui représente d'une manière abstraite les descriptions des services à sélectionner au moment de l exécution en tenant de compte des informations contextuelles et en s appuyant sur les différentes vues (gestion, médiation et sécurité). En général, nous considérons le service comme un objet représenté par son interface qui permet de donner accès au service abstrait. Les éléments associés à l interface d un service sont le nom du service, les paramètres en entrée et sorties et les opérations. Seules les noms, paramètres et opérations publiques sont présentées dans le répertoire destiné à la collaboration (ce qui permet de préserver les visions processus public et processus privé). Le service abstrait représente l interface publique publiée par l entreprise : ceci permet de masquer les implantations réelles et donc respecte la séparation publique / privée. Chaque service abstrait est ensuite lié aux services concrets qui représentent des instances de services «concrets» qui seront effectivement exécutés. La sélection du service concret est faite au moment de l exécution. L interconnexion entre les services offre une possibilité de couplage lâche qui repose sur l échange de messages. Le répertoire public, propre à chaque entreprise, permet de lister les services qu elle désire exposer. Ce répertoire permet de 73

85 présenter les services abstraits et leur interface. Notons que la description des échanges entre les services est prise en compte en associant les messages à la description des services (messages en entrée et en sortie). Lorsque plusieurs entreprises veulent collaborer, elles créent un répertoire commun intégrant les différents services proposés par les partenaires. Au cours du temps, d autres entreprises peuvent rejoindre ce groupe et publier également leurs services dans ce répertoire commun. Ceci permet d organiser des communautés de collaboration (breeding virtual organisation) [68]). Ensuite on peut créer un processus de collaboration (associé à un répertoire commun) qui comporte les services qui venant de différents partenaires. Dans ce répertoire au lieu de présenter les services comme une liste, des relations d agrégation, de similarité détaillées dans le chapitre suivant permettent de compléter une stratégie d héritage et de composition pour créer le processus commun. Ceci représente le concept clef de notre architecture. Ce processus commun permet de matérialiser les «opérations» nécessaires pour la réalisation de la collaboration et atteindre l objectif fixé. Le processus de collaboration est un concept clef de notre architecture. Ce processus est construit pour répondre à une demande spécifique et suppose que les entreprises partenaires soient d accord pour collaborer et donc créer le processus abstrait. Ce processus est constitué par assemblage de services abstraits qui viennent de différents partenaires. Ces services sont associés à des rôles ce qui permet de préciser la responsabilité de chaque partenaire dans l organisation du processus commun. Ce processus est défini par un ensemble de vues : gestion, médiation et sécurité, qui permettent de définir son contexte, dit contexte global. De la même manière, nous proposons d associer ces vues aux services abstraits constituant le processus ce qui permet de décrire leur contexte propre. Par composition, ces différents contextes permettent de construire le contexte global du processus commun. La Figure 35 présente le contexte du processus collaboratif en citant succinctement quelques éléments associés à ces vues. 74

86 La vue de gestion permet de gérer le service abstrait. Un ensemble de règles logiques est défini pour gérer les communications entre services et la collaboration entre participants en permettant ensuite de contextualiser le service. Processus collaboratif Vue Gestion Qualité de service - quantitatifs - qualitatif Préférences Objets métiers Règles métiers Vue Sécurité Authentification Autorisation Chiffrement Certificat Rôles. Vue Médiation Appariement - entrées - sorties Adaptation - messages - objets métiers Information Contextuelle Figure 35 : Description du contexte permettant une sélection et exécution multi-contextuelles de services Comme nous l avons déjà dit, ces services abstraits ne sont pas associés à une implantation effective mais définissent l interface publique d un service concret (entrées, sorties ), ce qui permet de préserver la confidentialité sur les processus privés des entreprises. De la sorte, un service abstrait peut être implémenté de manière «variable» selon le contexte en masquant le processus «concret» effectivement réalisé par chaque partenaire. 75

87 contexte Les services concrets candidats Médiation Processus abstrait Processus concret Figure 36 : Génération du processus concret en choisissant les services concrets convenables La vue de médiation permet transformer de le processus abstrait en processus concret (ou d affaire). Pour chaque service abstrait il faut trouver au moins un service concret en tenant en compte les informations contextuelles au moment du déploiement. Au fur et à mesure que le processus s exécute, le choix de chaque service concret est révisé si les informations contextuelles sont changées. La sélection est réalisé à partir du répertoire local de chaque entreprise : une requête où figure les entrées et sorties nécessaires pour chaque service abstrait est construite ce qui permet d extraire les services concrets correspondants. Par ce biais, on peut composer dynamiquement une chaîne de services concrets associés au processus de collaboration. La Figure 36 illustre brièvement la génération du processus concret. Chaque service abstrait dans le répertoire public est associé aux services concrets qui les implémentent. C est la médiation qui trouve le service convenable parmi les services concrets «candidats» en tenant compte du contexte. Figure 37 : Vue d agrégation du processus permettant la propagation des informations 76

88 Enfin, la vue de sécurité permet d intégrer les contraintes de sécurité dans la chaîne de services. Pour cela, chaque service concret hérite d une politique de sécurité correspondant au contexte (rôle joué par ce service, qui invoque ce service). Ceci permet d améliorer la gestion des droits d accès en définissant globalement des politiques cohérentes sélectionnées en fonction du contexte. La Figure 37 illustre comment un processus collaboratif peut être représenté par la relation d agrégation (top-down) qui relie ses services abstraits. Cette vue hiérarchisée permet également de définir les informations contextuelles qui doivent se propager moment de l exécution dans la chaine de services. A ce niveau, il est possible de vérifier si les contraintes de sécurité, par exemple, peuvent être s appliquées de bout en bout et si le médiateur devrait intervenir pour assurer les transitions/transformations entre les contraintes à respecter par chaque service. Dans la Figure 37 le rôle associé au processus est salesman tandis que le rôle associé au service S22 est online salesman. La médiation vérifie si le rôle online salesman peut avoir les mêmes droits que le rôle salesman et elle assure ensuite la transition au cours de l exécution. Ces vues, qui seront détaillées dans la section suivante, sont assemblées dans un Méta-Modèle d'entreprise (EMMA Enterprise Meta-Model Architecture ) pour permettre de générer des services «contextualisés». L architecture globale de notre approche est présentée par la Figure 38. Elle présente deux répertoires publics de deux entreprises (E1 et E2) qui contiennent respectivement leurs services abstraits. Le répertoire partagé contient les processus collaboratifs communs sous forme d hypergraphe conjointement conçus par E1 et E2, et qui sont reliés aux services abstraits. Le médiateur qui génère les objets contextes en tenant compte des trois vues, les rôles, et les services abstraits. 77

89 Figure 38 : Architecture globale 78

90 3.3 Spécification des différentes vues La vue de gestion Cette vue est destinée à supporter la première étape de sélection des services pour construire un processus de collaboration puis d intégrer leur spécification d interface pour composer une chaîne de services cohérents, comme nous l avons vu dans la modélisation d entreprise, nous proposons un logique d héritage pour permettre la définition de services particuliers instanciés à partir de modèles générique. Il faudra définir d autres relations et règles de propagation car le seul mécanisme d héritage seulement ne peut pas permettre la propagation des éléments liés au contexte sur la chaîne de service qui représente le processus. Dans la suite de cette section, nous présentons notre modèle de service abstrait construit à partir d un modèle de collaboration défini ci-après. Notre modèle de collaboration regroupe plusieurs participants (donc plusieurs entreprises) désirant atteindre un objectif commun via la collaboration. Un rôle définit la responsabilité d'un participant dans l organisation du processus commun (par exemple dans l organisation d une collaboration supportant une chaîne logistique, on trouvera des rôles de vente, achat, production). Pour chaque rôle, on associe des services abstraits qui permettent de remplir le cahier des charges fixé. Un service abstrait est donc associé aux compétences liées au rôle. Ce service peut aussi être associé à plusieurs services concrets qui décrivent comment ce service abstrait sera mis en œuvre. Par exemple pour un service de production (d un bien ou service), on pourra associer la gestion de l approvisionnement, la production et la gestion des expéditions). Cette modélisation réutilise pleinement les travaux de Mlle Rajsiri [76] qui propose une ontologie CNO (collaborative network ontology) qui couvre à la fois la collaboration d'interentreprises et les domaines de collaboration des processus. Cette ontologie se compose des concepts, relations et des règles de déduction propres au domaine de l entreprise. Elle permet de représenter les comportements collaboratifs entre les partenaires. Cette ontologie fédère plusieurs sous-ontologies, à savoir : - l'ontologie de collaboration (CO) est organisée en deux parties principales : le participant et la collaboration. 79

91 I) Le participant comprend trois concepts : le participant qui peut être un acteur physique ou une entreprise qui utilise le réseau pour atteindre un objectif commun avec d'autres participants, le rôle qui définit le rôle d'un participant dans le réseau. Par exemple : vendeur, acheteur et le service abstrait qui est un service qui décrit les compétences du participant. 2) La partie de collaboration concerne les critères de caractérisation de la collaboration : un objectif commun, participant, relation. - L'Ontologie de processus de collaboration CPO se réfère à la conceptualisation d'un processus de collaboration. Comme dans ce travail, le processus de transformation du modèle CIM en modèle PIM puis PSM passe par un remplacement des services abstraits par des services concrets (dits services de Business dans les travaux de Mlle Rajsiri). Comme nous l avons dit dans la présentation de notre architecture, nous enrichissons l approche de Mlle Rajsiri en intégrant le contexte (cad qui invoque quel service, dans quelles conditions en utilisant quels moyens d accès et avec quelles exigences de qualité de service) dans le processus de recherche des services concrets substituables aux services abstraits. Ceci nous conduit donc à coupler la notion de contexte aux services abstraits. La Figure 39 illustre les relations entre ces concepts. Figure 39 : Relations entre le participant, le rôle, et le service abstrait Un processus de collaboration est associé à un groupe d au moins deux participants qui voudraient travailler ensemble en réponse à un ou plusieurs objectifs communs. Une relation définit l'interaction entre les participants comme par exemple une relation client/fournisseur, une relation de type donneur d ordre / sous-traitance. Ces relations 80

92 permettent d intégrer le type de collaboration dans la spécification du contexte global (Figure 40). La juxtaposition de ce contexte de collaboration à la définition du service abstrait permet de construire le modèle global (Figure 41). Figure 40 : les relations entre les concepts dans le processus de collaboration. Figure 41 : les éléments de modèle de collaboration (génération le service) A partir de ce modèle, nous avons défini des règles logiques destinées à représenter le service : une première permet de sélectionner les services abstraits associés à des rôles alors qu une autre règle permet de retrouver les services d affaire (donc les services concrets) correspondant au contexte. 1) Sélection des services abstraits à partir du rôle : Cette première règle de sélection des services abstraits repose d abord sur l identification des rôles associés au participant pour ensuite extraire les services abstraits pouvant être invoqué avec ces rôles. Si la liste de services sélectionnés en fonction du rôle et du contexte n est pas vide, 81

93 la règle retourne le premier service de la liste. Ceci nous conduit à la formalisation suivante : Partner(x) HasRole(x, y) ListOfAbstractServicesByRole (y, z) Context(v) SelectContextuelAbstractService(x, y, z, v). La partie B de la Figure 42 montre comment la règle ci-dessus fonctionne à partir d un exemple. 82

94 Figure 42 : Exemple montrant la sélection du service abstrait à partir du rôle Le participant A peut jouer un rôle de vendeur. A ce rôle, on associe plusieurs services abstraits comme vendre un produit ou vendre un service. Ces services abstraits sont différenciés car ils correspondent à des processus différents dans l entreprise, même si leur rôle dans une chaîne de service est identique 2) Règle de sélection des services concrets (appelé aussi services d affaire) à partir des services abstraits : Soit un participant x dans un processus collaboratif qui fournit un service abstrait, y, dans un contexte bien défini, v. Il important de choisir le service concret approprié. Cette règle commence par rechercher les services concrets qui correspondent aux services abstraits fournis par le participant avant de renvoyer la liste de services d affaire que le participant devrait utiliser pour implémenter le service abstrait contextualisé. Partner(x) HasContextuelAbstractService(x, z) ListOfConcretServices(y, z) SelectConcretService(x, y, v). 83

95 La partie B de la Figure 43 montre comment la règle ci-dessus fonctionne à partir d un exemple. Figure 43 : Exemple montrant la règle de sélection des services concrets à partir des services abstraits Le participant A joue un rôle de vendeu. A ce rôle on associe plusieurs service abstrait (vendre prouduit). A chaque service abstrait on peutr associer un ou plusieurs services concrets élémentaires ou composites. La recherche du service concret est réalisée en fonction du contexte et peut nécessiter la composition de plusieurs services élementaires pour supporter le processus effectif (depuis la gestion de la commande, jusqu à la préparation de la livraison et la facturation). Une fois sélectionné, une règle contrôle l exécution du service. Soit deux partenaires P 1 et P 2, fournissant des services abstraits x et y. Il faut s assurer de la compatibilité des entrées et sorties pour permettre une bonne composition : Soient deux Participant P 1, et P 1, et respectivement leur service concret s 1 et s 2. L exécution de s 2 dépend de la compatibilité entre les propriétés fonctionnelles et non fonctionnelles de deux services, du contexte actuel et en particulier du rôle de chaque partenaire au moment de l exécution. La règle de médiation est la suivante PartnerConcreteService(P 1, s1) PartnerConcreteService(P 2, s2) MediateFunctionalPropertiesBetween(Output(s1), Input(s2)) MediateNonFunctionalPropertiesBetween(Role(s1), Role(s2)) PropagateContext(s1, s2) InvokeService(s2) Cette formalisation logique permet de raisonner sur les services, d automatiser la sélection des services abstraits, concrets 84

96 contextualisés et la médiation avant l invocation. Ceci nécessite un ensemble d ontologies décrivant, les propriétés fonctionelles et non fonctionelles, le contexte et les rôles, et un ensemble de règles pour implémenter les prédicats utilisés dans ces règles logiques. En conclusion, nous avons vu comment la vue de gestion permet de gérer la communication entre les services. Dans la section suivante, nous nous focaliserons sur la vue de médiation avant de prendre en compte les politiques de sécurité La vue de médiation Dans cette vue nous considérons le service comme une boîte noire. Il consomme un message et produit un autre message. Un message se compose de plusieurs propriétés ou attributs. Chaque attribut est associé à un type de données. Nous schématisons un service en fonction de ses entrées et sorties comme montrer dans la Figure 44. Nous avons vu dans la section précédente comment sélectionner un service concret à partir d une liste de services concrets qui implémentent réellement un service abstrait contextuel. Dans la suite, nous expliquons comment construire cette liste de services concrets qui correspond à un service abstrait identifié par les partenaires pendant dans la construction du processus collaboratif commun. Dans un premier temps, la construction de cette liste est basée sur les propriétés fonctionnelles du service abstrait-- notamment les attributs d entrée et de sortie --, la notions de sous-typage et la transformation des ces attributs pour qu elles correspondent respectivement aux attributs d entrée/sortie des services concrets. Figure 44 : Définition d un service 85

97 Nous définissons le service concret noté S de la manière suivante en prenant en compte ses entrée/sortie: S= {D entrée, D sortie }, où D entrée = {d i /d i est l attribut de la donnée d entrée de type t i } D sorties = {d i /d i est l attribut du donné de sortie de type t i } De la même manière, nous définissons un service abstrait, noté R par ses attributs d entrée/sortie R={R entrée, R sortie } où R entrée = {d i/d i est l attribut d entrée du service abstrait de type t i } R sortie = {d i /d i est l attribut de sortie du service abstrait de type t i } Pour trouver le service concret (ou les services concrets) qui correspond (correspondent) à un service abstrait R, nous proposons un mécanisme de médiation entre les attributs d entrée et sortie du service abstrait et les attributs d entrée et sortie de tous les services concrets du répertoire local. Cette médiation s appuie sur la similarité sémantique (noté ) et la similarité de typage (noté ): La similarité sémantique estime le degré de proximité entre la signification de deux attributs et évalue la relation sémantique qui les relie [73]. Le typage consiste à associer à un attribut le type de sa valeur. Le type définit les valeurs que peut prendre une donnée, ainsi que les opérateurs qui peuvent lui être appliqués. Un type pourrait être un booléen (valeurs vrai ou faux), un entier (signé ou non signé), un réel en virgule flottante et une chaîne de caractères. Certains types correspondent à d'autres structures de données plus complexes. Par exemple, le type composé adresse postale est composé de numéro de rue, nom de la rue, et code postale. Le typage signifie en plus que tout attribut a un type et que les attributs ne peuvent se combiner qu'en respectant des règles de "typage". Par exemple, concaténer une adresse (chaîne de caractères) et un numéro de téléphone (entier positive). La similarité de typage entre deux attributs s assure que leur types sont identiques ou bien qu il est possible de détecter une conversion de type implicite (par exemple, un entier est un réel, un réel est transformable en une chaîne de caractères, etc..). Nous nous appuyons sur les travaux développés dans le cadre de la thèse de Patrick Hoffmann [74] pour renforcer notre mécanisme de médiation et implémenter la similarité sémantique et la similarité de typage en utilisant des ontologies basées sur le contexte. Etant donnée un service abstrait, il faut découvrir les services concrets dont les attributs d entrée et sortie sont similaires. Ceci nous conduit à la formulation suivante : 86

98 D entrée de service d affaire (concret ) R entrée de service abstrait D sortie de service d affaire R sortie de service abstrait D entrée de service d affaire (concret ) R entrée de service abstrait D sortie de service d affaire R sortie de service abstrait A partir d une chaîne de services abstraits, on peut alors utiliser cette règle de médiation pour découvrir les services concrets candidats qui peuvent implémenter le service abstrait. Puisque les services concrets peuvent être implicitement interconnectés par des relations d héritage pour exprimer une variation dans leur contexte d utilisation (généralisation ou spécialisation), il s avère important de sélectionner parmi les services concrets candidats le service correspondant au contexte courant d exécution. Ceci se traduit par le parcours de l arbre d héritage de ces services et la comparaison entre le contexte du service abstrait et le contexte associé à chacun de ces services concrets. On répète cette procédure pour chaque service abstrait. Ceci permet donc transformer étape par étape la chaîne de services abstraits en chaîne de services concrets. Il ne reste alors plus qu à intégrer les contraintes de sécurité. 87

99 3.3.3 Vue de sécurité Pour sécuriser l interconnexion entre les différents services abstraits et par conséquences entre les différents services concrets nous traiterons les exigences de sécurité par le moniteur. Pour améliorer la gestion des droits d accès et répondre aux exigences de sécurité de manière cohérente entre les chaînes de service, nous définissons deux classes de droits d accès liés à deux rôles différents : propriétaire et membre. Chaque service a un propriétaire unique à un moment donné. Le propriétaire définit le niveau de sécurité du service, les niveaux d authentification et les droits d'accès affectés aux utilisateurs ou services. Les membres sont considérés comme des utilisateurs ou autres services qui ont l autorisation de manipuler le service en question via son interface et via les méthodes d'accès. Pour gérer les différents contextes, nous proposons d utiliser un ensemble de services interconnectés par une relation d agrégation afin de composer le processus collaboratif commun (i.e. la chaîne de service). Chacun d eux est associé à un contexte particulier. En plus, le processus collaboratif est associé à son tour à un contexte globale. contexte global Processus métier contraintes sécurités globales S2 S3 S5 contexte local S2 S3 S4 S5 S4 Processus métier S21 S22 contraintes sécurités locales Figure 45 : Mécanisme de propagation de contraintes de sécurités via le médiateur 88

100 Dans le contexte de la sécurité, la relation d héritage définit une relation de référentiel entre les services dérivés pour traiter la propagation de contraintes de sécurité d une façon similaire à l approche orientée objet. A titre d exemple, nous considérons deux hiérarchies de services (classes) C et D, et une relation d agrégation entre D et C. Chaque service dans chacune de ces deux hiérarchies encapsule les méthodes d accès aux données et les méthodes spécifiques utilisées pour manipuler ses attributs. Comme illustré dans la figure, les deux services, S1 et S2, font respectivement partie de C et D. S1 hérite les propriétés, en particulier la sécurité des composants et des méthodes, de son service de base (superclasse) dans l hiérarchie d héritage de C. Il en va de même pour D. Comme il existe une relation d agrégation entre C et D, (c-à-d C est un service composite ayant parmi ses constituants, un service de la hiérarchie d héritage de D), la médiation (et par la suite le médiateur) assure la comptabilité de sécurité et la propagation de ses contraintes (par exemple, rôle, token, etc) du service composite au service composant comme illustré dans la Figure 46. Figure 46 : Les droits d accès et l héritage entre les objets Les droits d'accès tels que l invocation d une méthode de lecture ou d une méthode de modification de valeurs d attributs sont principalement gérés par le propriétaire du service. Il accorde ses droits aux membres identifiés par leurs rôles. Les droits sont présentés par un triplet de règles d'accès définies par la relation suivante < R, S, m, o > qui définit que le membre ayant le rôle R, sont autorisés à manipuler l hiérarchie d héritage de services S (qui pourrait être un singleton), via 89

101 la méthode m selon les modes o de lecture (r), écriture (w), ou rien (x). Ci-dessous un exemple de droits d'accès qui peuvent être modifiés et ajustés, y compris en ajoutant de nouveaux droits d'accès et où en en révoquant par le propriétaire du service AchatEnligne et le service GestionVente. < Salesman, AchatEnligne, validercommande, r > < Client, GestionVente, annulercommande, x > < Anonyme, AchatEnLigne, PasserCommande,w > Les listes des droits d'accès sont continuellement ajustées : quand une classe est modifiée, les sous-classes et les droits d'accès à l objet sont également adaptés (ajout ou révocation dans la liste d'accès), sauf si le propriétaire de l objet a manuellement changé cette liste. La mise en place de cette vue permet donc d adapter dynamiquement le contrôle d accès au contexte d invocation du service et de simplifier la spécification de ces droits d accès Conclusion Dans cette section, nous avons présenté les différentes vues de notre modèle qui permettront de faciliter la contextualisation des services. Ainsi, nous avons défini une vue de gestion associée à des services abstraits, eux-mêmes associés à des rôles. La notion de contexte (qui accède à quoi avec quelles exigences de qualité et via quels moyens d accès) a été utilisée pour permettre de «tisser» les différentes politiques et sélectionner les services concrets adaptés. Ceci est réalisé grâce à la vue de médiation qui permet de définir des relations vers des services concrets. Enfin, la vue de sécurité permet de définir les éléments liés à la politique de sécurité. Cette organisation multi-vues enrichie la démarche de Mlle Rajsiri [76] en permettant une contextualisation des services lors de la transformation CIM vers PIM puis PSM et prolonge la séparation multi-niveaux introduite par [69]: en spécifiant des relations de rôles entre service, il devient plus «simple» de sélectionner les services abstraits répondant à un besoin puis d exploiter les relations existants avec les services concrets et éléments de sécurité pour permettre de construire un processus concret 90

102 contextualisé. Ces différents principes sont présentés dans la section suivante. 3.4 Exploitation du modèle : Pour montrer comment les différentes vues de ce modèle sont exploitées pour former un processus collaboratif, nous allons nous intéresser à la phase de conception de ce type de processus. En effet, lorsque des partenaires veulent collaborer, ils décrivent un processus abstrait qui servira de base aux contrats de collaboration. Pour cela, la notation graphique BPMN est fréquemment utilisée. Plusieurs travaux de recherche ont porté sur la transformation d un modèle décrit en BPMN (donc de manière abstraite) en processus concret BPEL. Figure 47 : Construction du processus de collaboration par une série de transformation de modèles (MDA) 91

103 Notre démarche est différente comme l indique la Figure 47: dans un premier temps, la chaîne de services abstraits est conçue en utilisant la notation BPMN. A la différence des autres travaux, la Processus collaboratif commun (BPMN) Transformation Processus à base de services abstraits multi-contextuels (BPEL abstrait) Transformation Processus à base de services concrets multi-contextuels (BPEL Concret) Contexte Exécution Vue Gestion Vue Sécurité Vue Médiation Moteur BPEL étendu transformation en BPEL n est pas réalisée en interprétant le processus défini en BPMN mais en procédant par substitution. Ensuite, nous allons rechercher dans les répertoires les services abstraits correspondant au besoin en nous intéressant aux opérations qui doivent être réalisées par le participant en fonction du rôle qu il doit jouer dans le processus 92

104 collaboratif : on procède d abord à une extraction du rôle du participant puis on extrait les services abstraits utilisables avec ce rôle : on utilise alors la vue de gestion. Ensuite, pour chaque service abstrait, on va rechercher les services d affaire qui peuvent le mettre en œuvre : il s agit alors d exploiter la vue de médiation. Pour chaque service abstrait, on recherche alors les services d affaire substituable dans le répertoire du partenaire concerné. De cette manière, les interfaces sont respectées. Ceci nous conduit à formaliser la règle suivante : Soit un processus de collaboration PC composé de services abstraits y i et Soit un partenaire P i pouvant fournir un service concret x i permettant de mettre en œuvre les fonctionnalités du service abstrait y i. On dira que si le service x i concret correspond au service y i abstrait alors le service concret x i peut être substitué au service abstrait y i. Pour établir une collaboration, les partenaires sélectionnent les services abstraits et construisent ensemble le processus collaboratif commun. On établit des relations entre services abstraits qu on répercute ensuite entre les services concrets. Nous notons P i un partenaire offrant un ensemble de services (abstraits et concrets) s (s P i ) noté p i (x). Ces services sont répartis en services abstraits y i et services concrets x i associés aux services abstraits. Si y 1 est un service abstrait de partenaire P 1, y 2 est un service abstrait du partenaire P 2 et que y 1 et y 2 sont liés par une relation R, alors cette relation R est répercutée entre les services concrets associés aux services abstraits : une relation R est créée entre les services concrets x 1 et x 2 associés respectivement aux services abstraits y 1 et y 2. Cette logique de transformation par substitution de services permet à la fois de respecter la séparation entre processus publics (publiés comme des services abstraits) et privés (services qui seront effectivement exécuté et intègre des connaissances sur le fonctionnement exact de l entreprise) et de composer et orchestrer le processus de collaboration «au vol» et donc de choisir le service concret qui sera invoqué en fonction du contexte exact. Une fois réalisée la sélection du service concret convenable, la dernière étape consiste à intégrer les services «techniques» de sécurité. En effet, si la séparation entre services publics et privés offre un premier niveau de protection aux entreprises, il importe également de prendre en compte les politiques de sécurité (gestion des droits d accès en 93

105 particulier). Pour cela, nous définissons deux services «techniques» d authentification et d autorisation qui peuvent être ajoutés lors de l opération de composition avant d invoquer un service concret : 1) Le service d authentification : Ce service vise à établir de manière certaine l identité de celui qui invoque un service soit pour conserver la trace «nominative» de l invocation soit en préalable d une demande d autorisation. Lors de la récupération des informations nécessaires à l authentification, ce service prend en charge la protection de ces informations (chiffrement des échanges, signature du message ) afin de garantir qu aucune capture d information conduisant à une usurpation d identité ultérieure ne puisse être faite. De même, les bases contenant ces informations seront protégées. 2) Le service d autorisation définit les droits d'un service et les autorisations sur un système. Une fois l identité prouvé (donc après l invocation du service d authentification), le service d autorisation détermine ce que l utilisateur du service invoqué (humain ou service appelant) peut effectuer sur le service invoqué (utilisation d une opération particulière par exemple). Par exemple dans le cadre d un processus d achat en ligne de pièces détachées, on aura une chaîne de différents services : présentation et sélection des produits, gestion de la commande, gestion du paiement. Dans le cadre du service de paiement, on devra échanger de manière sécurisée des informations financières (numéro de carte de crédit, gestion de l authentification du client). Pour cela, il faudra donc composer les services d authentification et de gestion des autorisations auprès de la banque pour poursuivre la transaction. En revanche, lorsque le processus d achat est mené par une entité de l entreprise (par exemple commande interne de pièces détachées par le SAV), le processus de facturation interne n impose que l authentification de l utilisateur qui invoque le service et non une quelconque demande d autorisation bancaire. 94

106 3.5 Conclusion Pour faciliter la collaboration entre entreprise, nous avons proposé de recourir à une stratégie «orientée service» permettant de composer un processus commun. En dotant chaque entreprise d un répertoire, des services abstraits (représentant son offre de collaboration) peuvent être exposés. L organisation en hypergraphe permet de définir différentes vues pour permettre, grâce à la spécification de relations typées, de faciliter la définition de services concrets contextualisés. L organisation précise de ces mécanismes est présentée dans le chapitre suivant. 95

107 Chapitre 4 Modélisation d'entreprises collaboratives par des graphes de d héritages de services 4.1 Introduction Afin d assurer la collaboration et l interconnexion de processus inter entreprises, nous avons introduit une approche originale qui s appuie sur une collaboration à base de services multi-contextuels. Les services métiers qui sont partagés par les partenaires sont modélisés selon trois vues différentes et complémentaires à savoir la vue de gestion, la vue de médiation et la vue de sécurité. En plus, nous ne considérons pas ces services comme des composants fonctionnels indépendants facilitant ainsi la composition de processus collaboratifs mais nous introduisons plusieurs types de relations implicites et non intrusives entre les services. Ces relations, qui sont maintenues par des répertoires, facilitent la découverte des services, enrichissent la composition et permettent l exécution en tenant compte du contexte. Dans ce chapitre nous définissons le concept d hypergraphe d un service. En effet, les hypergraphes sont des grappes de graphes qui permettent de spécialiser des relations sémantiques entre les services et les processus offerts par les partenaires. Les relations visent à faciliter la mise en place des processus collaboratifs et mieux gérer leurs interactions. En particulier, nous considérons les relations de type héritage qui sont vues comme un procédé de partage et d échange 96

108 d information dans une structure hiérarchique regroupant des sous ensembles d entités (services ou processus métiers). Dans ce contexte, les services sont décrits par des caractéristiques ou propriétés fonctionnelles et non fonctionnelles. La structuration hiérarchique nous permet de factoriser les propriétés communes à plusieurs entités afin de faciliter leur définition et la maintenance de l ensemble (meilleure cohérence). Ainsi, une propriété qui caractérise une entité est héritée par toutes ses sous entités inférieures. Chaque sous entité se définit par ses propres propriétés ainsi que par les propriétés héritées des entités supérieures. Dans cette organisation, il est possible d associer un mécanisme capable de restituer la définition complète d une entité à partir de ses propriétés propres et héritées. De façon plus abstraite, nous regroupons les entités en graphes : un arc représentent une relation d ordre partiel appelée relation d héritage et les nœuds représentent les sommets du graphe annotés par des propriétés fonctionnelles et non fonctionnelles. La relation d héritage est unidirectionnelle et orientée du plus spécifique au plus générique. Elle exige en plus que chaque nœud hérite des propriétés des nœuds les plus génériques. Dans notre contexte, la collaboration entre les entreprises s appuie sur un répertoire commun comprenant des structures d hypergraphes permettant la réalisation des objectifs métiers et des scénarios de collaboration. Une entreprise pourrait aussi être représentée par des hypergraphes représentant ses activités en termes de processus ou services à partager. Les relations d héritage permettent d offrir une variété d utilisation de ces processus ou services dans des différents scénarios d utilisation. Figure 48, illustre un hypergraphe contenant les processus ou services métiers composites (nœuds) et des liens génériques d interconnexion entre eux. 97

109 Figure 48 : Modélisation des processus en termes d hypergraphe Dans les sections suivantes, nous présentons la collaboration entre les entreprises en utilisation les hypergraphes afin de construire les chaînes de collaboration globale à base de services. Nous également discutons l enchainement des services et les contraintes de transaction entre eux. Enfin, nous enrichissons la construction d hypergraphe en utilisant différents types de relations entre les services à savoir les relations d héritage, d agrégation, etc 98

110 4.2 Mécanismes d héritage Dans notre contribution nous proposons d adopter le mécanisme d héritage développé dans l approche orientée-objet et l appliquer aux développements de services métiers et aux collaborations contextuelles. En effet, dans la vie pratique de l entreprise, nous avons constaté que la plupart de services métiers qui sont mis à disposition des partenaires ont subi des modifications successives selon la variété d utilisation dans des contextes différents. Cette tendance est bien connue dans le secteur de l innovation qui favorise la différenciation de produits existants en ajoutant quelques fonctionnalités afin de fournir de nouveaux produits et conquérir de nouveaux marchés. La relation d héritage permet ainsi d établir un lien indiquant qu un service est une spécialisation d un service plus générique (super-service). La spécialisation d un service existant décrit un contexte plus restreint pour son utilisation tout en gardant le sémantique métier hérité de son super-service. Ce recours à l approche et le sémantique objet est issu du constat que le concept service ressemble au concept classe de l approche orienté-objet, qui s avère être utile dans le domaine de génie logiciel. Nous expliquons dans cette section le mécanisme d héritage pour innover et développer de services contextuels. Il s agit d une approche incrémentale pour différencier les services à fournir aux partenaires ainsi que leurs intégrations dans des processus collaboratifs. A l exécution, les informations contextuelles pourraient guider le moteur d exécution d un processus collaboratif à bien choisir un service convenable sans mettre en cause la construction entière du processus. Avant d introduire le mécanisme d héritage entre services et en particulier l héritage de propriétés fonctionnelles et non fonctionnelles, nous rappelons que le concept classe ou objet est définit par identifiant, type et méthodes : L objet est défini par son nom et les propriétés associées à lui. Par exemple : O1 : [nom : Jaque, numéro compte : 1993] et O2 : [nom : Eric, numéro compte : 2404] 99

111 Type d objet : La structure d un objet comporte des propriétés (attributs) simples (entier, réel, chaîne, etc..) ou complexes et les méthodes (opérations). Un objet est dit de type complexe s il est une structure qui regroupe plusieurs types simples ou complexes (récursives). Les méthodes (ou opérations) : chaque objet est spécifié par un ensemble de méthodes. Exemple d un attribut pour réserver un avion [numéro : intègre, nom : string, date allé : date, prix de billet : real] et une méthode pour payer le prix d un ticket, payer(montant : real). 4.3 Héritage entre services (objets) Afin de détailler le mécanisme d héritage, nous nous intéressons aux propriétés des objets qui représentent les services dans notre contexte. Dans chaque service il existe des propriétés fonctionnelles (messages d entrée, messages de sortie, conditions, etc.) et des propriétés non fonctionnelles (sécurité, QoS, etc.). La Figure 49 illustre une vue abstraite du modèle service. Figure 49 : Le modèle de service vu comme un objet qui encapsule les propriétés et les méthodes Héritage avec les propriétés fonctionnelles Le mécanisme d héritage entre les services permet d hériter les propriétés et les opérations. Notons que les propriétés héritées 100

112 peuvent être redéfinies ou renommées. Ce mécanisme permet la transmission de propriétés, attributs et méthodes des services/objets qui sont dans les super-classes (services) vers les services/objets qui sont dans les sous-classes (services). En conclusion, les sous-services pourraient redéfinir, renommer les attributs ou modifier le comportement de certaines opérations. Dans notre cas quand le service S 2 hérite du service S 1, S2 peut garder les mêmes paramètres mais on peut aussi ajouter de nouveaux paramètres. Par exemple l héritage entre les deux servies S 1 (consulter compte en France) et S 2 (consulter compte depuis l étranger), nécessite de prendre en compte un nouveau paramètre (pays) comme illustré dans la Figure 50. Figure 50 : L héritage entre les services 4.4 Les propriétés non fonctionnelles et le mécanisme d héritage Les propriétés non-fonctionnelles de services fournissent des informations supplémentaires pour que les services s exécutent dans les meilleures conditions possibles et dans différents contextes. Ces propriétés incluent à titre d exemple les paramètres de qualité de service QoS tels que la fiabilité, la sécurité, la performance, le temps de réponse etc. 101

113 Selon [70] la qualité de service est définie comme quality is expressed referring to observable parameters, relating to nonfunctional property. La qualité de service peut être divisée en deux catégories comprenant la qualité d'exécution et la qualité métier. 1) La qualité d'exécution représente la mesure de propriétés qui sont liées à l'exécution d'une opération, Nous distinguons cinq catégories de qualité d exécution à savoir: le temps de réponse, la fiabilité, la disponibilité, l'accessibilité et l'intégrité [71][72][56]. Temps de réponse : mesure le délai prévu entre le moment où une opération envoie une requête et le moment où les résultats sont reçus. Fiabilité : concerne les échanges des messages entre les différents services. Elle assure les messages envoyés et reçus par les demandeurs de service et les fournisseurs de services ne sont ni perdus ni erronés. La disponibilité : elle concerne la capacité du système à offrir les fonctionnalités pour lesquels il a été conçu. Il s agit de s assurer que le service est opérationnel au moment où il est sollicité [56].. L'accessibilité : elle mesure le degré selon lequel une opération d un service est capable de répondre à une requête venant d un service web. L accessibilité peut être exprimée comme une probabilité mesurant le pourcentage de succès ou la chance de succès d instanciation du service à un instant donnée. (on différencie le cas où le service Web est fonctionnellement disponible mais ne peut être effectivvement instancié (manque de ressources locales ) [56]. L'intégrité : mesure la capacité d une opération de service à assurer correctement l'interaction. L exactitude : est définie comme le taux d'erreur produit (généré) par le service dans un intervalle de temps. Cette variable doit être minimisée. La performance : est mesurée en termes de débit (throughput) et de latence (latency). Le débit représente le nombre de demandes de service Web servis dans une 102

114 période donnée. La latence : est le temps qui s écoule entre l'envoi d'une requête et la réception de la réponse ([75] page 44). La qualité métier permet l'évaluation d'une opération de service d un point de vue métier. Par exemple : le coût mesure le prix qu'un demandeur de service doit payer pour invoquer l'opération de service. Dans l héritage de propriétés non fonctionnelles, les besoins sont hérités de la super-classe. Par exemple, quand le service S 2 hérite du service S 1 il prend les valeurs des attributs de sécurité de S1 mais aussi les valeurs associées aux exigences non fonctionnelles en ce qui concerne le contexte d exécution (temps de réponse, coût, ), voir la Figure 51. Figure 51 : héritage avec les propriétés non fonctionnelles 4.5 La construction de l hypergraphe Afin de réaliser les interconnexions entres les différents services, nous nous sommes basés sur le mécanisme d héritage. Par la suite, nous généralisons ce concept pour construire un hypergraphe de service contenant tous les services métier de l entreprise. L hypergraphe est composé par les services interconnectés par différents types de relations à savoir : la relation d agrégation, la relation de recommandation, et la relation de collaboration. 103

115 Nous définissons l hypergraphe hc comme un ensemble de services concrets qui forment les nœuds et qui sont reliés par des arcs. Les arcs désignent les relations d interdépendance entre les services (nœuds). Soient deux services c i et c j de l hypergraphe, l arc qui relie ces deux services est noté par a ci cj =( c i, c j ). Pour permettre de contextualiser les services concrets, nous organisons le répertoire locale de chaque entreprise dans un hypergraphe. Nous définissons l hypergraphe h comme un tuple (C, A) ; c-à-d h =(C, C A) sachant que C désigne l ensemble de tous les services concrets de l hypergraphe h tel que C = {c i} et A l ensemble de tous les arcs entre les C services de l ensemble C tel que A = { a ci cj }. La Figure 52 présent graphiquement un exemple d arborescence d un hypergraphe h C et montre que la relation ci a cj relie sémantiquement les deux services c i et c j. Par analogie à l approche orienté objet, les services sont similaires aux classes, les arcs sont similaires aux relations d interdépendance (par exemple héritage). Chaque service peut être exécuté en parallèle plusieurs fois dans un contexte de montée en charge ou en gestion transactionnelle ce qui ressemble aux objets instanciés d une classe donnée. Les services sont présentés par des rectangles et les instances sont présentées par des cercles. Par exemple, le service c i a deux instances qui s exécutent en concurrence. C Figure 52 : Exemple d arborescence 104

116 Nous notons par M i l ensemble de tous les attributs d un service c i. M i,p désigne l attribut p du service c i Dans notre contexte, les attributs représentent les messages d entrée et de sortie et les propriétés non fonctionnelles d un service. Par exemple dans la Figure 53, le service c i possède implicitement par le mécanisme d héritage l ensemble des attributs des tous ses services supérieures, notamment les attributs m o,1 et m o,2 du service c o, m h,1 du service c h et m i, 1, m i,2 et m i,3 du service c i. Figure 53 : Les attributs de la classe A l exécution, un service peut être exécuté en plusieurs instances. Pour cela, nous proposons de différentier les instances de services dans un hypergraphe afin d apporter un traitement individuel à chaque instance et établir de relations inter-instances de services qui reflètent la situation réelle de l exécution à un moment donné. Dans la section suivante nous construisons l hypergraphe des instances et nous montrons son utilité. Dans le paragraphe suivant nous expliquons comme noter les instances d un service de l hypergraphe. Nous notons par o m i l instance appelée m du service c i. L ensemble de tous les instances du service c i est noté par oi tel que o i = { o m m i } et o i o i. La notion d instance est importante dans le contexte d une gestion transactionnelle et d exécution répartie de service. En effet, certains fournisseurs de services exécutent en parallèle plusieurs instances d un service pour monter en charge et 105

117 répondre aux requêtes avec un temps de réponse acceptable, même en cas d'affluence massive. L'équilibrage de charges consiste à distribuer un service sur un pool de machines afin de s'assurer de la disponibilité d un service, en n'envoyant des requêtes qu'aux instances en mesure de répondre. En conséquence, les attributs d une instance o m i d un service c i est noté a m ip pour p=1,..,n Toute instance o m i possède implicitement, de plus de ses attributs, les attributs de l ensemble de toutes ses superinstances. Elles constituent l ensemble a m ip des attributs de l instance o m i (voir Figure 54) Figure 54 : L ensemble des attributs de l objet Une instance possède autant d attributs que son service et hérite aussi les attributs a i m de toutes les instances qui la précédent dans la hiérarchie d héritage. 4.6 Construire l arborescence des instances Après la construction de l hypergraphe nous présentons la construction de l arborescence des instances. L arborescence des instances constitue une vue réelle d un ensemble de services au cours de l exécution à un moment précis. Cette vue est utile pour décrire les cycles de vies des services en termes d états de transition (activé, annulé, échoué, compensé, terminé, etc..) et expliquer comment les contraintes sont propagés au cours de l exécution. Le mécanisme de transition et la propagation seront introduits plus tard dans ce chapitre. 106

118 Soient l arborescence h c et deux sommets c i et c j tels que c j est le successeur direct de c i, tout sommet o i m plusieurs sommets o j n par un arc m n o o i a j ci cj peut être relié à un ou à condition que les attributs a i n de l instance o j n soient identiques à l ensemble des attributs a i m de l instance o i m m o n m oi O={ o j i }, a m n i ci cj =( o i, o j ), a= oci a 2 o, m n j o cj h =<o, a>, voir la Figure 55. o Figure 55 : L arborescence de l objet Le service c i peut joindre un ou plusieurs services par l intermédiaire des relations. Une relation joignant c i à c j est noté : L k c i c j c, c ). Si deux services c i et c j possèdent une relation k L c i c j ( i j, les instances respectives de ces deux classes peuvent être reliées par un arc noté o m n i o j cicj L et qui désigne un lien entre ces instances. La Figure 56 montre que le service c i est interconnecté au service c j par la relation L, et inversement le service c j est relié au service c i par la relation L cij cji, les instances o i m du service c i o m n i o j cicj peut être reliée aux instances o n j du service c j par la relation L. Figure 56 : Les liens entre les classes et les objets 107

119 Une instance d un service peut avoir des liens avec des instances appartenant à différents services à condition qu il existe des liens entre ce service et les services correspondants aux instances considérées (voir Figure 57). En effet, l instance o m i possède des liens avec plusieurs instances d un même service. Figure 57 : Les liens avec des objets appartenant à différentes classes Une instance o m i peut être lié à des instances o n j et o p k appartenant à différents services, s il existe des liens respectivement entre les services c i, c j et c k. 4.7 Collaboration entre les entreprises à base d hypergraphe Pour établir une collaboration entre deux entreprises, nous avons proposé dans le chapitre précédent que chaque entreprise gère son répertoire local de services concrets et publie ses services abstraits dans un répertoire global. Le répertoire global contient les informations génériques sur ses activités, l ensemble de services abstraits et de processus à partager ainsi que leurs interfaces afin de faciliter leur découverte et déploiement. Il est important de noter que ce répertoire local ne contient pas la liste de services indépendamment les uns des autres mais prend aussi en compte des relations d héritage et d autres types de relations sous forme d hypergraphes. L architecture globale est illustrée en Figure 58 et montre que les hypergraphes de services dans les répertoires locaux sont utilisés pour établir des chaînes de services de collaboration enregistrées dans un répertoire commun. Les chaînes de services sont également représentées en tant que hypergraphes grâce à des relations comme la relation d héritage. Ainsi, la relation d héritage dans un hypergraphe permet la réutilisation des propriétés de services 108

120 par une relation de généralisation/spécialisation similaire à l approche orientée-objets : la classe spécialisée, c.à.d. la sous-classe, hérite les propriétés et les méthodes de la classe que l on spécialise, c.à.d. superclasse. L héritage entre les classes permet la transmission de propriétés (attributs et méthodes) de la super-classe vers les sous-classes. Figure 58 : Principe de présenter les services Supposons que les entreprises E 1 et E 2 souhaitent collaborer. Pour cela, elles négocient et établissent une chaîne de services à partir de leurs services abstraits. Elles déposent dans le répertoire commun la chaîne de service globale en tant que hypergraphe de services. D autre part, nous désignons par le terme type de service un arbre d héritage d un service particulier comprenant l ensemble de ses services hérités. Le type de service pointe sur le service racine et tous ses sous-services hérités. Le schéma dans la Figure 59 montre l arbre d héritage du service d achat, noté <achat> et qui inclut plusieurs sous-services tels que achat en ligne, achat par portable ou bien achat sur web : <achat> = achat online achat portable achat web. 109

121 Figure 59 : Arbre d'héritage de service <achat> Au moment de la génération du processus de collaboratif correspondant à le chaîne de services concrets à partir de la spécification ne com :portant que les services abstraits, le médiateur cherche le type de services qui correspond au service abstrait en tenant compte du contexte (par exemple, le contexte d exécution, les périphériques d accès, le profil de l utilisateur etc.). Le médiateur permet de choisir le service contextualisé en s appuyant sur son type de service (voir Figure 60). Figure 60 : rôle le médiateur Par exemple, lorsqu un utilisateur décide d acheter un ticket de train en utilisation son portable, le médiateur choisit de l arbre d héritage du service Achat (type de service <Achat>), le service Achat Portable». Sachant que la chaîne de service globale désigne un processus de collaboration générique qui décrit le flux d information et le sens d exécution de services, la prise ne compte du contexte permet de développer des services contextuels qui nécessitent un mode 110

122 d orchestration ou de composition particulière. Le médiateur devient un élément essentiel pour une orchestration proactive qui s appuie sur les relations entre les services. L architecture présentée Figure 61 montre une vue globale d un processus générique à base de type de services et le rôle du médiateur qui consiste à choisir tardivement et en fonction du contexte le service à exécuter. Dans la section suivante, nous détaillons le mécanisme d orchestration de service. Figure 61 : Le rôle de médiateur pour sélectionner le service contextuel 4.8 Orchestration contextualisée de type de service L orchestration de services permet explicitement de décrire l enchaînement de l exécution des services. Elle permet également de spécifier les messages échangés et les interactions qui se produisent au niveau de ces messages [63]. 111

123 Pour réaliser une orchestration contextualisée en se basant sur le concept type de service, nous définissons formellement un type de service par un triplet de trois nœuds(n e (s), n rc (s), n s (s)) tels que : n e (s): désigne l ensemble des attributs d entrée, n e1,n e2,..n en du service S. n s : désigne l ensemble des attributs de sortie, ns1, n s2, n sm du service S. n rc : désigne l ensemble de règles de contrôle qui s appliquent sur les attributs d entrée et sortie. Les règles n rc1, n rc2, n rcn contraignent l exécution du service S en posant des conditions sur les attributs, conditions à satisfaire avant l exécution et après l exécution. A titre d exemple, les règles de contrôle pour une réservation d un billet d avion sont définies en termes de ses ressources et leurs propriétés sont listées dans le Tableau 1. Tableau 1 : Règles de contrôle pour une réservation de billet d avion Dans ce cas, les règles de contrôle sont définies comme suit : a. le service «Acheter un billet d avion» est exécuté si les conditions prix<500 euro et le jour de départ est dimanche sont valides. b. le service «AutoriserRéservation» est exécuté si la condition «passeport du client n est pas expiré» est valide. En cours d exécution, un service est prêt à être exécuté si et seulement si toutes les valeurs des attributs d entrée sont fournies et que toutes les conditions définies par les règles de contrôle (nrc) sont accomplies ou réalisées. Dans le cas contraire, le service est considéré non disponible. Les règles de contrôle sont considérées comme une condition préalable (pré-condition) sur la disponibilité d un service. Nous définissons le mécanisme d orchestration comme une extension à l orchestration BPEL en redéfinissant les activités (invoke) 112

Conception, architecture et urbanisation des systèmes d information

Conception, architecture et urbanisation des systèmes d information Conception, architecture et urbanisation des systèmes d information S. Servigne Maître de Conférences, LIRIS, INSA-Lyon, F-69621 Villeurbanne Cedex e-mail: sylvie.servigne@insa-lyon.fr 1. Introduction

Plus en détail

OpenPaaS Le réseau social d entreprise. Tâche 3.2.2 : Métamodèle support à la caractérisation des utilisateurs et des collaborations

OpenPaaS Le réseau social d entreprise. Tâche 3.2.2 : Métamodèle support à la caractérisation des utilisateurs et des collaborations OpenPaaS Le réseau social d entreprise Tâche 3.2.2 : Métamodèle support à la caractérisation des utilisateurs et des collaborations Propriétés du Document Source du Document Titre du Document FSN OpenPaaS

Plus en détail

Aide à la conception de Système d Information Collaboratif, support de l interopérabilité des entreprises

Aide à la conception de Système d Information Collaboratif, support de l interopérabilité des entreprises Aide à la conception de Système d Information Collaboratif, support de l interopérabilité des entreprises Jihed Touzi, Frédérick Bénaben, Hervé Pingaud Thèse soutenue au Centre de Génie Industriel - 9

Plus en détail

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Architecture d'entreprise : Guide Pratique de l'architecture Logique Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam

Plus en détail

Modélisation Principe Autre principe

Modélisation Principe Autre principe Modélisation Principe : un modèle est une abstraction permettant de mieux comprendre un objet complexe (bâtiment, économie, atmosphère, cellule, logiciel, ). Autre principe : un petit dessin vaut mieux

Plus en détail

Positionnement de UP

Positionnement de UP UNIFIED PROCESS Positionnement de UP Unified Process Langage Méthode Outil logiciel UML UP RUP 6 BONNES PRATIQUES développement itératif gestion des exigences architecture basée sur des composants modélisation

Plus en détail

Conventions communes aux profils UML

Conventions communes aux profils UML Conventions communes aux profils UML Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* Référence : Livrable 2.1 Date : Juin 2002 * : Les partenaires du

Plus en détail

IFT2255 : Génie logiciel

IFT2255 : Génie logiciel IFT2255 : Génie logiciel Chapitre 6 - Analyse orientée objets Section 1. Introduction à UML Julie Vachon et Houari Sahraoui 6.1. Introduction à UML 1. Vers une approche orientée objet 2. Introduction ti

Plus en détail

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes FICHE JANVIER 2009 THÉMATIQUE Direction de projets et programmes La représentation par les processus pour les projets Système d Information (SI) La modélisation de l'entreprise par les processus devient

Plus en détail

Ingénierie d entreprise et de système d information dirigée par les modèles : quels usages?

Ingénierie d entreprise et de système d information dirigée par les modèles : quels usages? Ingénierie d entreprise et de système d information dirigée par les modèles : quels usages? Hervé Panetto, Xavier Boucher, Pierre-Alain Millet To cite this version: Hervé Panetto, Xavier Boucher, Pierre-Alain

Plus en détail

SDL: 20 ans de programmation basée modèle

SDL: 20 ans de programmation basée modèle SDL: 20 ans de programmation basée modèle Emmanuel Gaudin emmanuel.gaudin @ pragmadev.com Principes MDE, MDA et MDD: Approche orienté modèle PIM: Platform Independant Model PDM: Platform Definition Model

Plus en détail

Business Process Design Max Pauron

Business Process Design Max Pauron Business Process Design Max Pauron 2005 Max Pauron - Reproduction and communication, even partial, are strictly prohibited without written permission. Unauthorized photocopying is a crime. Contexte Les

Plus en détail

Sujet de thèse CIFRE RESULIS / LGI2P

Sujet de thèse CIFRE RESULIS / LGI2P Ecole des Mines d Alès Laboratoire de Génie Informatique et d Ingénierie de Production LGI2P Nîmes Sujet de thèse CIFRE RESULIS / LGI2P Titre Domaine De l ingénierie des besoins à l ingénierie des exigences

Plus en détail

L SIO I N O 3 & & PE P R E S R PE P C E TIV I ES E

L SIO I N O 3 & & PE P R E S R PE P C E TIV I ES E INTRODUCTION SOMMAIRE 1 Modélisation de processus et Workflows 2 - Méthodes et outils pour la Modélisation de processus Workflows 3 Notions de flexibilité et d adaptabilité dans les WorkFlow CONCLUSION

Plus en détail

Processus de développement UP

Processus de développement UP Chapitre 1 Processus de développement UP I. Pourquoi UP? II. Définition III. Activités et phases IV. Modèles mis en place 1. Pourquoi UP? Les notions de base acquises dans le module ACOO1, notamment la

Plus en détail

Mongi TRIKI Docteur en Informatique Université Paris Dauphine

Mongi TRIKI Docteur en Informatique Université Paris Dauphine Université Méditerranéenne Libre de Tunis Faculté Méditerranéenne Privée des Sciences Informatiques, Economiques et de Gestion de Tunis Département d Informatique LICENCE INFORMATIQUE Guide du Stagiaire

Plus en détail

Université de Bangui. Modélisons en UML

Université de Bangui. Modélisons en UML Université de Bangui CRM Modélisons en UML Ce cours a été possible grâce à l initiative d Apollinaire MOLAYE qui m a contacté pour vous faire bénéficier de mes connaissances en nouvelles technologies et

Plus en détail

OFFRE DE FORMATION L.M.D.

OFFRE DE FORMATION L.M.D. REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE MINISTERE DE L ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE OFFRE DE FORMATION L.M.D. MASTER PROFESSIONNEL ET ACADEMIQUE Systèmes d Information

Plus en détail

IFT2251 : Génie logiciel

IFT2251 : Génie logiciel 4.1. Introduction à UML IFT2251 : Génie logiciel 1. Approches de développement 2. Introduction à UML (une méthodologie basée sur l approche orientée aspect) 3. Rappel de quelques concepts objets Chapitre

Plus en détail

Intégration d'applications d'entreprise (INTA)

Intégration d'applications d'entreprise (INTA) Master 2 SITW - Recherche Intégration d'applications d'entreprise (INTA) Dr. Djamel Benmerzoug Email : djamel.benmerzoug@univ-constantine2.dz Maitre de Conférences A Département TLSI Faculté des NTIC Université

Plus en détail

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base SOA et Services Web 23 octobre 2011 1 SOA: Concepts de base 2 Du client serveur à la SOA N est Nest pas une démarche entièrement nouvelle: années 1990 avec les solutions C/S Besoins d ouverture et d interopérabilité

Plus en détail

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation Un peu d'organisation Conception et Programmation par Objets HLIN406 Marianne Huchard, Clémentine Nebut LIRMM / Université de Montpellier 2 Premières semaines Contrôle des connaissances Supports 2015 Sommaire

Plus en détail

LE SUPPLY CHAIN MANAGEMENT

LE SUPPLY CHAIN MANAGEMENT LE SUPPLY CHAIN MANAGEMENT DEFINITION DE LA LOGISTIQUE La logistique est une fonction «dont la finalité est la satisfaction des besoins exprimés ou latents, aux meilleures conditions économiques pour l'entreprise

Plus en détail

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013 UML Mise en œuvre dans un projet 2013 Introduction Rôles et activités dans un projet Définir la méthode de votre projet Adapter la modélisation à la méthode de votre projet Conseils de mise en œuvre de

Plus en détail

Cycle de vie du logiciel. Unified Modeling Language UML. UML: définition. Développement Logiciel. Salima Hassas. Unified Modeling Language

Cycle de vie du logiciel. Unified Modeling Language UML. UML: définition. Développement Logiciel. Salima Hassas. Unified Modeling Language Unified Modeling Language UML Salima Hassas Version Cycle de vie du logiciel Client Besoins Déploiement Analyse Test Conception Cours sur la base des transparents de : Gioavanna Di Marzo Serugendo et Frédéric

Plus en détail

Sujet de thèse CIFRE RESULIS / LGI2P

Sujet de thèse CIFRE RESULIS / LGI2P Ecole des Mines d Alès Laboratoire de Génie Informatique et d Ingénierie de Production LGI2P Nîmes Sujet de thèse CIFRE RESULIS / LGI2P Titre Domaine De l ingénierie des besoins à l ingénierie des exigences

Plus en détail

Modélisation objet Le langage UML

Modélisation objet Le langage UML Modélisation objet Le langage UML Brahim HAMID La base de contrôle Robot Zone à explorer brahim.hamid@irit.fr brahim.hamid@univ-tlse2.fr http://mass-cara.univ-tlse2.fr/~brahimou/ens/uml 1 Les méthodes

Plus en détail

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009 GPA 789 : Analyse et Conception Orientées Objet ETS Mickaël Gardoni Bureau A 3588 tel 84 11 Mise en œuvre UML 1/ 25 Introduction Mise en œuvre d UML UML n est pas une méthode 2/ 25 1 UML n est qu un langage

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement: Environnements de Développement Mme BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

Comment initialiser une démarche SOA

Comment initialiser une démarche SOA Comment initialiser une démarche SOA Placer l approche l SOA au cœur c de la vie du Système d Informationd Olivier Dennery IT Architect IBM certified BCS Application Innovation Objectifs Objectifs - Rappeler

Plus en détail

Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform

Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform IBM Software Group Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform Thierry Bourrier, Techical Consultant thierry.bourrier@fr.ibm.com L Architecture

Plus en détail

URBANISME DES SYSTÈMES D INFORMATION

URBANISME DES SYSTÈMES D INFORMATION FAYCAL AYECH GL2. INSAT 2010/2011 INTRODUCTION AUX SYSTÈMES D INFORMATIONS URBANISME DES SYSTÈMES D INFORMATION De l Urbanisme à L Urbanisation des SI Urbanisme : Mise en œuvre des politiques urbaines

Plus en détail

Chapitre I : le langage UML et le processus unifié

Chapitre I : le langage UML et le processus unifié I. Introduction Les méthodes d analyse orientées objet sont initialement issues des milieux industriels. La préoccupation dominante de leurs auteurs est le génie logiciel, c est-àdire les principes et

Plus en détail

CEISAR Survey on IT education

CEISAR Survey on IT education CEISAR Survey on IT education Objectives In June 2007, the CEISAR conducted a survey to understand what company needs are in terms of training on Computer Science and Management of IS. Our objective was

Plus en détail

Le génie Logiciel (suite)

Le génie Logiciel (suite) Le génie Logiciel (suite) Lors du cours précédent, on a étudié différents cycles de vie, dont la cascade, ou la spirale. Analyse des besoins L analyse des besoins est une étape menant à l élaboration de

Plus en détail

Cours Gestion de projet

Cours Gestion de projet Cours Gestion de projet Méthodes de conduite de projet Version Date Auteur V1.8 Septembre 2007 Pascal HEYER 1 Méthodes de conduite de projet Ce document est publié sous la licence libre Creative Commons-BY-NC-SA

Plus en détail

BACHELOR OF SCIENCE INFORMATICIEN-NE DE GESTION

BACHELOR OF SCIENCE INFORMATICIEN-NE DE GESTION Informatique de gestion BACHELOR OF SCIENCE HES-SO BACHELOR OF SCIENCE INFORMATICIEN-NE DE GESTION Plans d études et descriptifs des modules Filière à plein temps et à temps partiel Table des matières

Plus en détail

UML Diagramme de classes (class diagram) pour le recueil et l analyse des besoins. Emmanuel Pichon 2013 V1.1

UML Diagramme de classes (class diagram) pour le recueil et l analyse des besoins. Emmanuel Pichon 2013 V1.1 UML Diagramme de classes (class diagram) pour le recueil et l analyse des besoins 2013 V1.1 Objectif Diagramme de classes (class diagram) pour le recueil des besoins et l analyse Présenter un ensemble

Plus en détail

ADELFE : Atelier de développement de logiciels à fonctionnalité émergente

ADELFE : Atelier de développement de logiciels à fonctionnalité émergente ADELFE : Atelier de développement de logiciels à fonctionnalité émergente Gauthier Picard*, Carole Bernon*, Valérie Camps**, Marie- Pierre Gleizes* * Institut de Recherche en Informatique de Toulouse Université

Plus en détail

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

GÉNIE LOGICIEL (SOFTWARE ENGINEERING) GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 5ÈME PARTIE UML (UNIFIED MODELING LANGUAGE) Faculté des Sciences et Techniques http://labh-curien.univ-st-etienne.fr/~fj/gl Francois.Jacquenet@univ-st-etienne.fr Plan

Plus en détail

Système de Gestion de Contenus d entreprises

Système de Gestion de Contenus d entreprises Système de Gestion de Contenus d entreprises OUDJOUDI Idir, H.HOCINI Hatem. Centre de développement des technologies avancées Cité 20 Août Baba Hassan Alger Algérie Tél. 0(213)351040, Fax : 0(213)351039

Plus en détail

Analyse abstraite de missions sous PILOT

Analyse abstraite de missions sous PILOT Analyse abstraite de missions sous PILOT Damien Massé EA 3883, Université de Bretagne Occidentale, Brest damien.masse@univ-brest.fr Résumé Nous étudions la possibilité de réaliser un analyseur par interprétation

Plus en détail

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 MDA : Un Tutoriel Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 1 Sommaire Table des matières 1 Sommaire 1 2 Introduction 2 2.1 A qui s adresse ce tutoriel......................

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

Mineure Architectures Orientées Services SOA Business Process Modeling (BPM) Mineure SOA. Business Process Modeling (BPM)

Mineure Architectures Orientées Services SOA Business Process Modeling (BPM) Mineure SOA. Business Process Modeling (BPM) Mineure SOA Business Process Modeling (BPM) Idir AIT SADOUNE idir.aitsadoune@supelec.fr Idir AIT SADOUNE - Plan 1 Notion de processus? 2 Modélisation des processus? 3 Langages

Plus en détail

Programmation orientée objet et événementielle en JavaScript. Département SRC Pôle Universitaire de Vichy Bruno Bachelet

Programmation orientée objet et événementielle en JavaScript. Département SRC Pôle Universitaire de Vichy Bruno Bachelet Programmation orientée objet et événementielle en JavaScript Département SRC Pôle Universitaire de Vichy Bruno Bachelet «PARTIE IV Introduction au paradigme objet Programmation objet et événementielle

Plus en détail

Introduction à l'analyse et à la modélisation des processus. Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001

Introduction à l'analyse et à la modélisation des processus. Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001 Introduction à l'analyse et à la modélisation des processus Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001 Les composants d'une méthode d'analyse La conception d'un

Plus en détail

Comparaison de trois techniques de modélisation de processus: ADONIS, OSSAD et UML

Comparaison de trois techniques de modélisation de processus: ADONIS, OSSAD et UML Olivier Glassey Jean-Loup Chappelet Comparaison de trois techniques de modélisation de processus: ADONIS, OSSAD et UML Working paper de l'idheap 14/2002 UER: Management public / Systèmes d'information

Plus en détail

PTSI PT ÉTUDE DES SYSTEMES

PTSI PT ÉTUDE DES SYSTEMES PTSI PT ÉTUDE DES SYSTEMES Table des matières 1 - PRESENTATION GENERALE... 1 1.1 - Définition d'un système... 1 1.2 - Exemples... 1 1.3 - Cycle de vie d'un système... 1 1.4 Langage de description SysML...

Plus en détail

Les principaux domaines de l informatique

Les principaux domaines de l informatique Les principaux domaines de l informatique... abordés dans le cadre de ce cours: La Programmation Les Systèmes d Exploitation Les Systèmes d Information La Conception d Interfaces Le Calcul Scientifique

Plus en détail

Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise.

Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise. Solutions PME VIPDev Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise. Cette offre est basée sur la mise à disposition de l ensemble de nos compétences techniques et créatives au service

Plus en détail

Méthodologie de conceptualisation BI

Méthodologie de conceptualisation BI Méthodologie de conceptualisation BI Business Intelligence (BI) La Business intelligence est un outil décisionnel incontournable à la gestion stratégique et quotidienne des entités. Il fournit de l information

Plus en détail

Description et illustration du processus unifié

Description et illustration du processus unifié USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins

Plus en détail

Gestionnaire contextualisé de sécurité pour des «Process 2.0»

Gestionnaire contextualisé de sécurité pour des «Process 2.0» N d ordre : 2013 ISAL 0 132 Année 2013 Thèse Gestionnaire contextualisé de sécurité pour des «Process 2.0» Présentée devant L institut national des sciences appliquées de Lyon Pour obtenir Le grade de

Plus en détail

Le Guide Pratique des Processus Métiers

Le Guide Pratique des Processus Métiers Guides Pratiques Objecteering Le Guide Pratique des Processus Métiers Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam 21 avenue Victor Hugo 75016

Plus en détail

Business Process Modeling (BPM)

Business Process Modeling (BPM) Business Process Modeling (BPM) Mineure SOA Cécile Hardebolle cecile.hardebolle@supelec.fr Programme 8 nov. 15 nov. Introduction. Enjeux, rôle de l'architecte SI Partie n 1 du cas d'étude Architecture

Plus en détail

SYSTEMES D INFORMATION & CONCEPTION de BdD

SYSTEMES D INFORMATION & CONCEPTION de BdD SYSTEMES D INFORMATION & CONCEPTION de BdD PLAN CONCEPT DE SYSTEME D INFORMATION MODELISATION D UN SYSTEME D INFORMATION MODELISATION CONCEPTUELLE : les METHODES METHODE SYSTEMIQUE METHODE OBJET L3 Informatique

Plus en détail

Concepts et langages du cadre RM-ODP de l'iso pour analyser et articuler les pratiques de projets libres de système de formation

Concepts et langages du cadre RM-ODP de l'iso pour analyser et articuler les pratiques de projets libres de système de formation Concepts et langages du cadre RM-ODP de l'iso pour analyser et articuler les pratiques de projets libres de système de formation Système de formation fédérant trois projets du logiciel libre (Moodle, OpenGLM

Plus en détail

Pour une entreprise plus performante

Pour une entreprise plus performante Pour une entreprise plus performante Smart Technology Services Raison Sociale - Smart Technology Services llc Pôle d activités - Service et conseil dans la technologie de l information Pôle d activités

Plus en détail

Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009

Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009 Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009 Notion de méthode de conception de SI Méthodes OO de conception Généralités sur les méthodes

Plus en détail

Le "tout fichier" Le besoin de centraliser les traitements des fichiers. Maitriser les bases de données. Historique

Le tout fichier Le besoin de centraliser les traitements des fichiers. Maitriser les bases de données. Historique Introduction à l informatique : Information automatisée Le premier ordinateur Définition disque dure, mémoire, carte mémoire, carte mère etc Architecture d un ordinateur Les constructeurs leader du marché

Plus en détail

Séminaires Système D Information. Formation Conduite du Changement. Préambule

Séminaires Système D Information. Formation Conduite du Changement. Préambule Séminaires Système D Information Formation Conduite du Changement Préambule Sommaire Préambule L entreprise : système complexe en mouvement permanent Mickael Porter Harvard Business School - L avantage

Plus en détail

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes

Plus en détail

Les FONDEMENTS de l ARCHITECTURE d ENTREPRISE Ingénierie de l organisation

Les FONDEMENTS de l ARCHITECTURE d ENTREPRISE Ingénierie de l organisation Les FONDEMENTS de l ARCHITECTURE d ENTREPRISE Ingénierie de l organisation Patrice Briol Ingénierie de l organisation 1 ère édition http://www.ingenieriedesprocessus.net La notation UML et le logo UML

Plus en détail

MASTER II ECONOMIE ET GESTION Spécialité Management des Organisations de la Neteconomie

MASTER II ECONOMIE ET GESTION Spécialité Management des Organisations de la Neteconomie MASTER II ECONOMIE ET GESTION Spécialité Management des Organisations de la Neteconomie MODULE C03 - Séquence 1 INTRODUCTION I. UN PEU D'HISTOIRE II. LES RESSOURCES D'UN SI III. LA DÉFINITION D UN SI À

Plus en détail

SGBDR et conception d'un système d'information avec MERISE

SGBDR et conception d'un système d'information avec MERISE 1 SGBDR et conception d'un système d'information avec MERISE Séminaires Codes & Travaux @ IRISA 26 Avril 2007 Anthony ASSI Ingénieur Expert R&D Plateforme Bio Informatique / Equipe Symbiose 2 SGBDR : Système

Plus en détail

ARIS : Des Processus de gestion au Système Intégré d Applications

ARIS : Des Processus de gestion au Système Intégré d Applications ARIS : Des Processus de gestion au Système Intégré d Applications Présentation de IDS Scheer IDS Scheer propose des solutions dédiées au management de l'entreprise par les processus. Avec la solution ARIS,

Plus en détail

Accélérer la transformation de vos nouveaux modèles assurances

Accélérer la transformation de vos nouveaux modèles assurances Accélérer la transformation de vos nouveaux modèles assurances Enjeux critiques des systèmes de distribution Assurance Etude Accenture Assurances 2020 4 axes d amélioration : Articuler le SI Assurance

Plus en détail

PROJET MES COMMUNIQUE DE PRESSE. L intelligence collaborative au service du pilotage d atelier

PROJET MES COMMUNIQUE DE PRESSE. L intelligence collaborative au service du pilotage d atelier PROJET MES L intelligence collaborative au service du pilotage d atelier COMMUNIQUE DE PRESSE Annecy 28 septembre 2009 Après 1 an de travail et de collaboration, les 7 éditeurs de logiciels et les 2 laboratoires

Plus en détail

1. Introduction. 2. Diagramme des exigences

1. Introduction. 2. Diagramme des exigences 1. Introduction La complexité des systèmes techniques est telle que, sans outils de représentations abstraites et progressivement enrichies, les intervenants d un projet auraient de nombreuses difficultés

Plus en détail

UML (Diagramme de classes) Unified Modeling Language

UML (Diagramme de classes) Unified Modeling Language UML (Diagramme de classes) Unified Modeling Language Sommaire Introduction Objectifs Diagramme de classes Classe (Nom, attribut, opération) Visibilité et portée des constituants d une classe Association

Plus en détail

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES Aristote ----- Cloud Interopérabilité Retour d'expérience L A F O R C E D E L I N N O V A T I O N Résumé Les systèmes d'information logistique (SIL) sont des outils qui amènent des gains de productivité

Plus en détail

Projet de recherche doctoral

Projet de recherche doctoral Projet de recherche doctoral Formalisation des règles métier et organisation des indicateurs de performance pour le développement de la méthode publique d Architecture d Entreprise Praxeme. 1 Contexte

Plus en détail

MODÉLISATION ET MANIPULATION DES DOCUMENTS STRUCTURÉS: UNE APPROCHE MODULAIRE, FLEXIBLE ET ÉVOLUTIVE

MODÉLISATION ET MANIPULATION DES DOCUMENTS STRUCTURÉS: UNE APPROCHE MODULAIRE, FLEXIBLE ET ÉVOLUTIVE MODÉLISATION ET MANIPULATION DES DOCUMENTS STRUCTURÉS: UNE APPROCHE MODULAIRE, FLEXIBLE ET ÉVOLUTIVE ÉCOLE POLmECHNlQUE FÉDÉRALE DE LAUSANNE POUR L'OBTENTION DU GRADE DE DOCTEUR ÈS SCIENCES PAR Yassin

Plus en détail

Découvrez la gestion collaborative multi-projet grâce à la. solution Project EPM

Découvrez la gestion collaborative multi-projet grâce à la. solution Project EPM Découvrez la gestion collaborative multi-projet grâce à la solution Project EPM Project EPM 2007 est la solution de gestion de projets collaborative de Microsoft. Issue d une longue expérience dans le

Plus en détail

Chapitre 2 Modélisation de bases de données

Chapitre 2 Modélisation de bases de données Pourquoi une modélisation préalable? Chapitre 2 Modélisation de bases de données 1. Première étape : le modèle conceptuel Eemple : le modèle Entités-Associations (E/A) 2. Deuième étape : le modèle Traduction

Plus en détail

GT IS3C Muriel LOMBARD

GT IS3C Muriel LOMBARD Interopérabilité de Systèmes Intégrés : à la plateforme PICS-PPO et au Advitium pour la gestion de l information dans les projets de conception produit-process GT IS3C Muriel LOMBARD Ingénierie des Systèmes

Plus en détail

1 sur 12 25/08/2014 16:37

1 sur 12 25/08/2014 16:37 Nous contacter 01 53 63 37 87 ok qui sommes nous consulting agile formations gestion de projet certifications PMI CONSULTING & ACCOMPAGNEMENT Conduite de projets CENTRE DE FORMATION DEPUIS 1986 Formations

Plus en détail

L approche Bases de données

L approche Bases de données L approche Bases de données Cours: BD. Avancées Année: 2005/2006 Par: Dr B. Belattar (Univ. Batna Algérie) I- : Mise à niveau 1 Cours: BDD. Année: 2013/2014 Ens. S. MEDILEH (Univ. El-Oued) L approche Base

Plus en détail

Urbanisation des Systèmes d Information Architecture d Entreprise. 04 Architecture du SI : identifier et décrire les services, structurer le SI

Urbanisation des Systèmes d Information Architecture d Entreprise. 04 Architecture du SI : identifier et décrire les services, structurer le SI Plan du chapitre Master Informatique et Systèmes Urbanisation des Systèmes d Information Architecture d Entreprise 04 Architecture du SI : identifier et décrire les services, structurer le SI 1 2 3 1.1

Plus en détail

Design patterns par la pratique

Design patterns par la pratique Alan SHALLOWAY James TROTT Design patterns par la pratique Groupe Eyrolles, 2002 ISBN : 2-212-11139 Table des matières Préface.................................................... XV SECTION I Introduction

Plus en détail

Système d Information

Système d Information 1 sur 9 Brandicourt sylvain formateur Unix,apache,Algorithme,C,Html,Css,Php,Gestion de projet,méthode Agile... sylvainbrandicourt@gmail.com Système d Information Architecture Technique Architecture Logiciel

Plus en détail

Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.»

Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.» Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.» Projet de fin d études 2 Sommaire OBJET DU DOCUMENT... 3 LES ETAPES DU PROJET... 4 ETUDE PREALABLE...5 1 L étude d opportunité...

Plus en détail

Architecture Logicielle

Architecture Logicielle Architecture Logicielle Chapitre 3: UML pour la description et la documentation d une architecture logicielle Année universitaire 2013/2014 Semestre 1 Rappel L architecture d un programme ou d un système

Plus en détail

Product Life-Cycle Management

Product Life-Cycle Management Offre de prestations en Product Life-Cycle Management Contact : Pascal MORENTON CentraleSupélec 1, campus de Chatenay-Malabry 06 13 71 18 51 pascal.morenton@centralesupelec.fr http://plm.ecp.fr Nos formations

Plus en détail

Management des Systèmes d Information

Management des Systèmes d Information Spécialité Réseaux (RES) UE: Management des systèmes d'information [mnsi, NI303] M2IRT 2012 1 ère année Management des Systèmes d Information Unité 2 - Les principaux types de SI dans l entreprise Gilles

Plus en détail

OMGL UE Modélisation de données 2 / 41

OMGL UE Modélisation de données 2 / 41 Module OMGL UE Modélisation de données Analyse et Conception des Systèmes d Information Modélisation des données J. Christian Attiogbé Septembre 2008, maj 11/2009, 08/2010 OMGL UE Modélisation de données

Plus en détail

Cas d étude appliqué à l ingénierie logicielle

Cas d étude appliqué à l ingénierie logicielle ypbl : une méthodologie pédagogique pour la professionnalisation d une formation Cas d étude appliqué à l ingénierie logicielle Ernesto Exposito 1,2, Anne Hernandez 2 1 CNRS ; LAAS ; 7 av. du Colonel Roche,

Plus en détail

Module Business Process Management & Service Oriented Architecture

Module Business Process Management & Service Oriented Architecture - 1 - Module Business Process Management & Service Oriented Architecture SI5/Master IFI Audrey Occello occello@polytech.unice.fr http://moodle.i3s.unice.fr/course/view.php?id=55 Pour ceux qui ne sont pas

Plus en détail

Le pilotage des collaborations et l interopérabilité des systèmes d information Vers une démarche intégrée

Le pilotage des collaborations et l interopérabilité des systèmes d information Vers une démarche intégrée Colloque : Systèmes Complexes d Information et Gestion des Risques pour l Aide à la Décision Le pilotage des collaborations et l interopérabilité des systèmes d information Vers une démarche intégrée BELKADI

Plus en détail

Chapitre 2 : Conception de base de données relationnelle

Chapitre 2 : Conception de base de données relationnelle Chapitre 2 : Conception de base de données relationnelle Le modèle entité-association 1. Les concepts de base 1.1 Introduction Avant que la base de données ne prenne une forme utilisable par le SGBD il

Plus en détail

Business & High Technology

Business & High Technology UNIVERSITE DE TUNIS INSTITUT SUPERIEUR DE GESTION DE TUNIS Département : Informatique Business & High Technology Chapitre 3 : Le web dans l entreprise Sommaire Introduction... 1 Intranet... 1 Extranet...

Plus en détail

Nom de l application

Nom de l application Ministère de l Enseignement Supérieur et de la Recherche Scientifique Direction Générale des Etudes Technologiques Institut Supérieur des Etudes Technologiques de Gafsa Département Technologies de l Informatique

Plus en détail

Modélisation pour l étude de l interopérabilité d entreprise en conception de produits

Modélisation pour l étude de l interopérabilité d entreprise en conception de produits Modélisation pour l étude de l interopérabilité d entreprise en conception de produits GUILLAUME VICIEN 1,2, CHRISTOPHE MERLO 1,2 1 ESTIA Technopole Izarbel, 64210 Bidart, France g.vicien@estia.fr c.merlo@estia.fr

Plus en détail

WEB15 IBM Software for Business Process Management. un offre complète et modulaire. Alain DARMON consultant avant-vente BPM alain.darmon@fr.ibm.

WEB15 IBM Software for Business Process Management. un offre complète et modulaire. Alain DARMON consultant avant-vente BPM alain.darmon@fr.ibm. WEB15 IBM Software for Business Process Management un offre complète et modulaire Alain DARMON consultant avant-vente BPM alain.darmon@fr.ibm.com Claude Perrin ECM Client Technical Professional Manager

Plus en détail

Intégration de produits mécatroniques au sein d un système PLM

Intégration de produits mécatroniques au sein d un système PLM Intégration de produits mécatroniques au sein d un système PLM HOUSSEM ABID 1, MADY GUILLEMOT 1, DIDIER NOTERMAN 1, PHILIPPE PERNELLE 2 1 Laboratoire DISP, INSA Lyon 69100, France {houssem.abid,mady.guillmot,didier.noterman}@insa-lyon.fr

Plus en détail

Approche organisationnelle basée sur le paradigme agent pour la synthèse & la réutilisation des connaissances en ingénierie collaborative

Approche organisationnelle basée sur le paradigme agent pour la synthèse & la réutilisation des connaissances en ingénierie collaborative Approche organisationnelle basée sur le paradigme agent pour la synthèse & la réutilisation des connaissances en ingénierie collaborative Hind Darwich, doctorante en thèse CIFRE au sein de la société TDC

Plus en détail

Ingénierie Dirigée par les Modèles IDM

Ingénierie Dirigée par les Modèles IDM Ingénierie Dirigée par les Modèles Pierre Laforcade Master EIAH 2007 Présentation personnelle Statut Enseignements Lieu : IUT de Laval Matières : modélisation objet en UML, programmation objet, JavaEE/EJB,...

Plus en détail

Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech

Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech INF380-2013! Sylvie.Vignes@telecomParistech.fr Département INFRES, groupe S3 Cadre du processus 2! q Basé sur un processus incrémental:

Plus en détail