Spécification et transformation de langages de points de vue des systèmes répartis ouverts

Texte intégral

(1)UNIVERSITE MOHAMMED V–AGDAL FACULTE DES SCIENCES Service des affaires estudiantines RABAT. N° d’ordre : 2479. THÈSE DE DOCTORAT Présentée par Youssef BALOUKI Discipline : Informatique Spécialité : Systèmes répartis et réseaux. Titre de thèse :. Spécification et transformation de langages de points de vue des systèmes répartis ouverts. Soutenue le 10 février 2010 devant le jury composé de : Président : S. EL HAJJI. Professeur (PES) à la Faculté des Sciences Rabat. Examinateurs : M. ERRADI. Professeur (PES) à l’Ecole Nationale Supérieure d’Informatique et d’analyse des Systèmes Rabat. E.M. SOUIDI. Professeur (PES) à la Faculté des Sciences Rabat. N. ZAHID. Professeur (PES) à la Faculté des Sciences Rabat. M. BOUHDADI. Professeurs (PH) à la Faculté des Sciences Rabat Faculté des Sciences, 4 Avenue Ibn Battouta B.P. 1014 RP, Rabat-Maroc. Tel : + 212 (0) 37 77 18 34/35/38, Fax : + 212 (0) 37 77 42 61, http://www.fsr.ac.ma..

(2) à ma fille Lina.

(3) REMERCIEMENT Les travaux présentés dans cette thèse ont été effectués au sein de l’unité de formation et de recherche Mathématiques, Informatique et Applications à la faculté des sciences de Rabat. Je tiens à remercier très vivement Monsieur Mohammed BOUHDADI, Professeur Habilité à la faculté des sciences de Rabat, pour son soutien, sa disponibilité, sa patience, la collaboration étroite dans laquelle nous avons travaillé et son aide qui m’ont permis de mener à bien cette thèse. Merci également pour ses relectures minutieuses de ce mémoire. J’exprime ma profonde gratitude à Saîd ELHAJJI, professeur à l’Université de Rabat, pour l’honneur qu’il me fait de présider mon jury de thèse. Qu’il trouve ici l’expression de ma profonde gratitude. Je souhaite remercier M.ERRADI, professeur à l’école nationale supérieure d’informatique et d’analyse des systèmes Rabat, et M.SOUIDI, professeur à l’Université de Rabat, pour avoir accepté la lourde charge d’être Rapporteur et pour leurs précieuses remarques qui m’ont permis d’améliorer ce manuscrit. Je tiens à remercier N.ZAHID , professeur à l’Université de Rabat, pour l’intérêt qu’il a tout porté à ce travail. Merci infiniment à tous les membres du Département de Mathématiques et Informatique à la faculté des sciences de Rabat. Mes remerciements vont naturellement à l’ensemble des gens que j’ai côtoyé durant ces cinq années et qui m’ont aidé ou tout simplement rendu le déroulement de cette thèse agréable. En particulier je voudrais remercier mes parents pour leur amour et leur soutien dans les moments difficiles. Je tiens à remercier très chaleureusement ma femme, Bouchra Farah, qui m’a beaucoup aidé tout au long de ces cinq années. Je remercie mes frères pour leur amitié et leurs encouragements. Enfin, je tiens à remercier tous ceux qui m’ont soutenu, et plus particulièrement ma famille et mes amis.. i.

(4) RESUME Dans un système réparti ouvert, les applications sont capables d'interagir même lorsqu'elles ont été développées dans des environnements différents. Cette capacité ne peut être obtenue que si ces environnements sont conformes à un même modèle conceptuel. Ces besoins constituent le point de départ du travail de la normalisation du modèle de référence pour le traitement réparti ouvert RM-ODP. Cependant, RM-ODP n’est pas une méthode, mais bien un ensemble de concepts de spécification et de modélisation. Ses langages de point de vue possèdent une sémantique informelle qui n’est décrite qu’en langage naturel. Ceci peut provoquer des problèmes d'interprétation et d'ambiguïté. C'est en partant du constat du manque de formalisme des langages ODP et du manque de convivialité des méthodes formelles, que nous avons travaillé autour de l'intégration de ces deux types de méthodes. Afin de contribuer à résoudre cette problématique, nous nous intéressons à la sémantique formelle du modèle de référence ODP pour la rendre plus précise. Nous avons adopté l’approche méta-modélisation basé UML/OCL et l’approche dénotationnelle pour la spécification précise de la sémantique des langages de point de vue ODP en particulier du langage d’entreprise et de traitement. Nous proposons le méta-modèle de la syntaxe abstraite qui se compose des diagrammes de classe et des contraintes OCL, le méta-modèle des instances des modèles en UML/OCL et la relation entre les modèles et leurs instances. Nous avons définit une sémantique formelle pour un sous ensemble de concepts de comportement ODP dans le langage d'entreprise (temps, comportement, action, rôle et processus) en utilisant UML couplé avec le langage de contraintes OCL. Puis, nous avons proposé une méthodologie de modélisation de comportement du langage d'entreprise ODP par la création d’un profil UML spécifique. Ce profil sera transformé au langage BPEL. Cette transformation, orientée MDA, va être assurée par l’utilisation de l’outil Rational rose.. Mots clés : RM-ODP, Langages de point de vue, Sémantique dénotationnelle, Comportement, UML/OCL, BPEL. ii.

(5) TABLES DES MATIERES Remerciement .......................................................................... i Résumé .................................................................................... ii Tables des matières ...............................................................iii Liste des figures ..................................................................... vi Liste des tableaux .................................................................. vi Liste des abréviations ........................................................... vii Glossaire ................................................................................ vii Introduction générale............................................................. 1 I. Pourquoi un modèle de référence pour le traitement réparti ouvert ?................................. 1 II. Méthodologie de conception pour les systèmes répartis ................................................... 4 III. Thème de recherche ......................................................................................................... 5 IV. Description des travaux réalisés ....................................................................................... 6 V. Plan de mémoire ................................................................................................................ 8. Chapitre I : État de l’art ...................................................... 10 I.1. Introduction .................................................................................................................... 10 I.2. Le modèle RM-ODP ...................................................................................................... 11 I.2.1. Présentation générale de RM-ODP ......................................................................... 12 I.2.2. Le modèle objet....................................................................................................... 13 I.2.3. Le modèle architectural........................................................................................... 14 I.2.3.1. Les points de vue ............................................................................................. 14 I.2.3.1.1. Point de vue Entreprise ............................................................................. 14 I.2.3.1.2. Point de vue Information .......................................................................... 16 I.2.3.1.3. Point de vue Traitement ............................................................................ 17 I.2.3.1.4. Point de vue Ingénierie ............................................................................. 17 I.2.3.1.5. Point de vue Technique ............................................................................. 20 I.2.3.2. Les langages de points de vue .......................................................................... 20 I.2.3.2.1. Le langage d’entreprise ............................................................................. 21 I.2.3.2.2. Le langage d’information .......................................................................... 21 I.2.3.2.3. Le langage de traitement ........................................................................... 21 I.2.3.2.4. Le langage d’ingénierie............................................................................. 26 I.2.3.3. Les fonctions ODP ........................................................................................... 26 I.2.3.4. Les transparence ODP...................................................................................... 27 I.3. La sémantique formelle.................................................................................................. 28 I.3.1. La syntaxe ............................................................................................................... 28 I.3.1.1. La syntaxe concrète.......................................................................................... 29 I.3.1.2. La syntaxe abstraite.......................................................................................... 29 I.3.2. Les principales méthodes de description de la sémantique .................................... 30 I.3.2.1. Sémantique opérationnelle ............................................................................... 31 I.3.2.2 Sémantique axiomatique(ou predicate transformer) ......................................... 33 I.3.3. Sémantique dénotationnelle .................................................................................... 35 I.3.3.1. la composition .................................................................................................. 35 I.3.3.2. Sémantique statique et dynamique................................................................... 36 iii.

(6) I.3.3.3. L’approche dénotationnelle ............................................................................. 37 I.3.3.3.1. Syntaxe abstraite ....................................................................................... 37 I.3.3.3.2. L’algèbre sémantique ................................................................................ 38 I.3.3.3.3. La relation entre la syntaxe et la sémantique ............................................ 39 I.3.3.4. Exemple : Application sur un langage de spécification QML ......................... 39 I.3.3.4.1. La syntaxe abstraite de QML .................................................................... 40 I.3.3.4.2. Algèbre sémantique de QML .................................................................... 41 I.3.3.4.3. Fonctions sémantiques pour QML. ........................................................... 42 I.3.4. La cohérence des définitions sémantiques .............................................................. 44 I.4. Méta-modélisation et transformation de modèles .......................................................... 45 I.4.1. Techniques de méta-modélisation........................................................................... 45 I.4.1.1. Modèles et méta-modèles ................................................................................ 45 I.4.1.2. Le besoin de méta-modélisation ...................................................................... 46 I.4.1.3. Une architecture de méta-modélisation à quatre niveaux ................................ 47 I.4.1.4. Le MOF : Un langage de définition de méta-modèles ..................................... 48 I.4.2. Transformation des modèles ................................................................................... 50 I.4.3. Les standards pour la manipulation des modèles .................................................... 51 I.4.3.1. Le MOF ............................................................................................................ 51 I.4.3.2. Les langages UML et OCL .............................................................................. 52 I.4.3.3. Les profils UML .............................................................................................. 53 I.4.3.4. Le format d’échange normalisé : XMI............................................................. 54 I.5. Conclusion ..................................................................................................................... 54. Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL .............. 56 II.1. Introduction .................................................................................................................. 56 II.2. Travaux connexes ......................................................................................................... 57 II.3. Stratégie de formalisation ............................................................................................. 59 II.3.1. La convenance du méta-modèle ............................................................................ 61 II.3.2. L’utilisation du standard ........................................................................................ 62 II.3.3. La précision de la sémantique de base................................................................... 62 II.4. RM-ODP ....................................................................................................................... 64 II.4.1. Le modèle objet ODP ............................................................................................ 64 II.4.2. Utilisation des langages de point de vue ............................................................... 66 II.4.3. Le langage d'entreprise RM-ODP.......................................................................... 67 II.4.4. Le langage de point de vue traitement RM-ODP ................................................. 69 II.5. Sémantique dénotationnelle pour le langage de point de vue entreprise ...................... 72 II.5.1. Domaine Syntaxique.............................................................................................. 72 II.5.2. Domaine sémantique ............................................................................................. 75 II.5.3. La fonction de signification ................................................................................... 77 II.6. Sémantique dénotationnelle pour le langage de point de vue traitement ..................... 80 II.6.1. Domaine Syntaxique.............................................................................................. 80 II.6.2. Domaine sémantique ............................................................................................. 82 II.6.3. La fonction de signification ................................................................................... 84 II.7. Conclusion .................................................................................................................... 87. Chapitre III : Une sémantique dénotationnelle pour un sous-ensemble de concepts de comportement du langage d’entreprise ........................................................................... 89 III.1. Introduction ................................................................................................................. 89 iv.

(7) III.2. Concepts de modélisation de base du comportement ODP...................................... 91 III.3. Meta-modélisation du temps et des contraintes comportementales ............................ 94 III.3.1. Temps ................................................................................................................... 94 III.3.2. contraintes Comportementales ............................................................................. 96 III.3.2.1. Contraintes de séquencement ........................................................................ 97 III.3.2.2. Contraintes de la concurrence ....................................................................... 97 III.3.2.3. Contraintes de non-déterminisme.................................................................. 98 III.4. Les politiques de comportement dans le Langage Entreprise RM-ODP .................... 99 III.4.1. Obligation ........................................................................................................... 100 III.4.2. Permission .......................................................................................................... 100 III.4.3. Interdiction ......................................................................................................... 101 III.5. Conclusion ................................................................................................................. 102. Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d’entreprise ODP ............ 103 IV.1. Introduction ............................................................................................................... 103 IV.2. Langage d’exécution des processus métiers ............................................................. 103 IV.2.1. Introduction au BPM : Business Process Management ..................................... 103 IV.2.2. Langage BPEL ................................................................................................... 106 IV.3. La fonction de courtage............................................................................................. 108 IV.4. Spécification de la fonction de courtage du point de vue entreprise......................... 109 IV.5. Profil UML pour des processus automatisés de comportement ................................ 110 IV.6. Transformation au BPEL ......................................................................................... 113 IV.6.1. D'UML à BPEL.................................................................................................. 113 IV.6.2. Exécution du processus de comportement ......................................................... 114 IV.6.3. Démarche de transformation d’UML au BPEL ................................................. 116 IV.6.4. Implémentation du processus de comportement ................................................ 117 IV.6.4.1. La construction et l’exportation du modèle ................................................ 117 IV.6.4.2. Génération du BPEL et WSDL ................................................................... 118 IV.7. Conclusion ................................................................................................................ 120. Conclusion générale et perspectives ................................. 122 Bibliographie ...................................................................... 124 Annexes ............................................................................... 128 Annexes A : Grammaire du langage OCL ......................................................................... 128. v.

(8) LISTE DES FIGURES Figure 1 : Modèle architectural de RM-ODP ........................................................................... 13 Figure 2 : La spécification au point de vue Ingénierie ............................................................. 18 Figure 3 : Les objets du point de vue Ingénierie ...................................................................... 19 Figure 4: La relation entre les points de vue ODP ................................................................... 20 Figure 5 : Types de liaisons...................................................................................................... 25 Figure 6 : Système de translation d’un langage de programmation ......................................... 32 Figure 7 : Interpréteur .............................................................................................................. 32 Figure 8 : Domaines syntaxiques du langage QML ................................................................. 41 Figure 9 : Domaines sémantiques du langage QML ................................................................ 42 Figure 10 : Fonctions de valuation pour les domaines syntaxiques de QML .......................... 43 Figure 11 : Relation entre les diverses sémantiques ................................................................ 44 Figure 12 : L’architecture à quatre niveaux ............................................................................. 47 Figure 13 : Le MOF version 1.3 ............................................................................................... 49 Figure 14 : Transformation de méta-modèle ............................................................................ 51 Figure 15 : Le processus de formalisation ............................................................................... 63 Figure 16 : RM-ODP Foundation Object Model ..................................................................... 64 Figure 17 : Méta-modèle de la syntaxe abstraite du langage d’entreprise ............................... 72 Figure 18 : Méta-modèle des domaines sémantiques du langage d’entreprise ........................ 75 Figure 19 : Méta-modèle de la syntaxe abstraite du langage de traitement ............................. 81 Figure 20 : Méta-modèle des domaines sémantiques du langage du traitement ...................... 83 Figure 21 : Relation entre domaines syntaxique et sémantique des différentes méthodes formelles ................................................................................................................................... 90 Figure 22 : Concepts de base de modélisation de comportement ............................................ 94 Figure 23 : (a) les contraintes déterministes séquentielles (b) les contraintes non déterministes séquentielles ............................................................................................................................. 96 Figure 24 : Diagramme RM-ODP - Contraintes de la concurrence ......................................... 97 Figure 25 : Diagramme RM-ODP - Exemple de contraintes de non-déterminisme ................ 98 Figure 26 : Un méta-modèle pour des concepts de comportement et de politique ................ 102 Figure 27 : Collaboration entre différents acteurs .................................................................. 104 Figure 28 : Méta-modèle du langage BPEL ........................................................................... 108 Figure 29 : La fonction de Trading dans ODP ....................................................................... 109 Figure 30 : Une classe UML modélise le processus du comportement BPEL ...................... 112 Figure 31 : Un diagramme d'activité du processus de comportement.................................... 113 Figure 32 : Développement d’un processus ........................................................................... 117 Figure 33 : Modélisation et Exportation avec XDE ............................................................... 118 Figure 34 : Transformation du fichier XMI ........................................................................... 119 Figure 35 : Déploiement du processus ................................................................................... 120 Figure 36 : Déploiement des services .................................................................................... 120. LISTE DES TABLEAUX Tableau 1 : Mapping entre concepts de comportement et constructions UML ..................... 111 Tableau 2 : Mapping entre constructions UML et concepts BPEL....................................... 114. vi.

(9) LISTE DES ABREVIATIONS API BPEL4WS CCM CIM CORBA CWM DCOM DTD EAI EDOC EJB IDM IDL MDA MOF OCL OMG ODP PDM PIM PSM QoS QVT SDL SPEM UML XMI XML. Application Program Interface (Business Process Execution Language for Web Services) : le langage de composition de services CORBA Component Model Computation Independent Model Common Object Request Broker Architecture Common Warehouse Metamodel Distributed Component Object Model Document Type Definition Enterprise Application Integration Enterprise Distributed Object Computing Entreprise Java Bean Ingénierie Dirigée par les Modèles Interface Definition Language Model Driven Architecture (Architecture basée sur les modèles ou Architecture dirigée par les modèles) Meta-Object Facility Object Constraint Language Object Management Group Open Distributed Processing Plateform Description Model Platform Independent Model Platform Specifique Model Quality of Service Query View Transformation Specification and Description Language Software Process Engineering Metamodel Unified Modeling Language XML Metadata Interchange eXtensible Markup Language. GLOSSAIRE Architecture Composant. Framework Middleware. Plate-forme Système. L’architecture d’un système est la spécification de ses différentes parties avec leurs interconnexions qui le constituent. Module logiciel autonome qui assure un service. Ce module peut être installé sur différentes plates-formes. En vue de son utilisation ou de sa réutilisation, il exporte différents attributs ou méthodes sous forme d'interfaces Infrastructure logicielle qui facilite la conception des applications par l'utilisation de bibliothèques de classes ou de générateurs de programmes Permet la communication entre des clients et des serveurs ayant des structures et une implémentation différentes. Il permet l'échange d’informations dans tous les cas et pour toutes les architectures. Enfin, le middleware doit fournir un moyen aux clients de trouver leurs serveurs, aux serveurs de trouver leurs clients et en général de trouver n'importe quel objet atteignable Ensemble ou sous-ensemble de systèmes et de technologies qui fournissent un ensemble cohérent de fonctionnalités au travers d’interfaces Pris au sens large, il peut s’agir d’un programme, d’un ensemble d’applications logicielles,… vii.

(10) INTRODUCTION GENERALE. L’évolution conjuguée de la technologie des télécommunications et de la structure des organisations conduit à l’émergence d’applications réparties de grande complexité. Ces applications sont ouvertes pour supporter l'intégration permanente de services sophistiqués et interagir dans de multiples environnements, eux-mêmes évolutifs en permanence. Leur construction, leur déploiement, leur fonctionnement, leur maintenance posent des problèmes difficiles pour lesquels les solutions actuelles sont jugées insuffisantes par les utilisateurs et coûteuses par les opérateurs de services. L’environnement d’exécution d’une application répartie est constitué des systèmes interconnectés généralement hétérogènes. L’hétérogénéité technique se caractérise par des machines d’architectures différentes, des systèmes d’exploitation distincts ou encore des réseaux de nature diverse. L’hétérogénéité organisationnelle apparaît lorsque l’environnement d’exécution relève de domaines d’organisation multiples, avec des objectifs, des politiques d’usage et de gestion et des contraintes différentes. L’interconnexion des systèmes soulève en plus, les problèmes plus classiques de la concurrence, de l’asynchronisme, ou de l’absence d’état global. Maîtriser cette complexité est nécessaire pour supporter des applications constituées de composants, développées par différents acteurs, interagissant et répartis sur des sites distants. L’assemblage de tels composants, dont les interactions réalisent les fonctionnalités attendues, donne naissance à des systèmes fortement hétérogènes. L’intégration provient de la nécessité de conserver et faire évoluer les applications existantes pour des raisons économiques évidentes et également pour offrir une certaine continuité vis-à-vis des utilisateurs. Cependant, les composants de ces applications ne sont pas toujours homogènes ni propriétaires. Leur réutilisation ou leur coopération pour offrir de nouvelles fonctionnalités reposent sur la capacité d’interactions cohérentes de tous leurs composants. L'interaction entre ces composants applicatifs constitue un des aspects du traitement réparti. Plus précisément, Le traitement réparti correspond aux différents aspects du traitement de l'information dans lequel des composants déterminés peuvent être localisés dans des lieux différents et au cours duquel les communications entre composants peuvent subir des délais ou des pannes. 1.

(11) Introduction générale. Lorsque ces composants ont une capacité d'ouverture, on peut alors parler de traitement réparti ouvert. Dans un système réparti ouvert idéal, les applications sont capables d'interagir même lorsqu'elles ont été développées dans des environnements différents (par exemple, ils sont écrits au moyen de langages différents ou développés par des organisations distinctes). Cette capacité ne peut être obtenue que si ces environnements sont conformes à un même modèle conceptuel. Ces besoins constituent le point de départ du travail de la normalisation du modèle de référence pour le traitement réparti ouvert RM-ODP. Les objectifs de RM-ODP sont la répartition, l'interfonctionnement et la portabilité. Il fournit un cadre de description des architectures selon plusieurs niveaux d’abstraction. Cependant, il ne vise pas à fournir une méthodologie concrète de conception ou de développement. En fait, il n'est qu'un fil banalisant l'ingénierie de systèmes répartis en environnements hétérogènes. C'est une norme qui guide le développement d'autres normes qui permettront à long terme de développer de tels systèmes.. I. Pourquoi un modèle de référence pour le traitement réparti ouvert ? Parallèlement aux efforts d’industriels au sein de l’OMG (Object Management Group), le monde de la recherche de son côté, est sollicité pour fournir de nouvelles théories et de nouveaux paradigmes liés à cette évolution. En effet, l’effort de normalisation est fourni, au sein de l’ISO et de l’ITU/T sur le modèle de référence pour le traitement réparti ouvert, pour suivre l’évolution et le développement des systèmes répartis. En fait, l’ISO et l’ITU-T ont d’abord activement étudié le problème d’interconnexion de systèmes hétérogènes et ont produit le modèle OSI. Ce modèle est structuré en sept couches. Cependant avec la prolifération de nombreux standards applicatifs au niveau de la couche application, il a été constaté que les six premières couches ne fournissent qu’un support de communication, et par conséquent un modèle de référence plus général était nécessaire pour traiter tous les aspects relatifs à la répartition d’applications : interfaces normalisées entre les composants d’applications, plate-forme de répartition et conception de ces applications. En outre, l’ensemble des caractéristiques d’un système réparti ne couvre pas que des aspects techniques mais recouvre également des aspects organisationnels, puisqu’ un système peut être réparti en plusieurs organisations. Différentes autorités participent alors à sa réalisation sans control central, d’où l’hétérogénéité technique s’ajoute à l’hétérogénéité d’entreprise qui s’exprime en termes de domaines et d’objectifs distincts, de politique d’usage et de gestion de contrainte. Dans ce contexte l’objectif de la normalisation ODP est de développer une architecture de 1.

(12) Introduction générale. référence pour les systèmes répartis ouverts. Cette architecture serait générique, c'est-à-dire, définie indépendamment de tout domaine d’application. Elle prendrait en compte l’interfonctionnement, la répartition, la portabilité, la modularité, la sécurité, la transparence et le contrôle de la qualité de service. L’ISO a défini la norme RM-ODP. De ce fait, en contraste avec le modèle OSI, le modèle RM-ODP n’est pas restreint aux aspects de communication entre systèmes hétérogènes mais traite les problèmes d’interaction et d’interfonctionnement d’applications. RM-ODP permet d’assurer l’interfonctionnement et la portabilité des applications de façon transparente aux applications elles mêmes. Le modèle identifie en fait les fonctionnalités de la plate-forme de traitement réparti (l’environnement d’exécution support d’ODP) requises pour les interactions de composants d’applications ; ces interactions étant ouvertes et transparentes à la répartition. Le principe étant qu’un jour, il sera possible d’automatiser ce processus de traitement distribué. La construction du modèle RM-ODP est basée sur le principe de la séparation de points de vue. Ce modèle définit une architecture permettant de définir un système selon cinq points de vue qui sont : 1) Le point de vue entreprise (enterprise viewpoint) décrit un système ODP en spécifiant les besoins d’un domaine donné. Il porte essentiellement sur l'objectif et la portée du système ainsi que sur les politiques qui lui sont applicables. Elle comprend les objets d'entreprise et les actions de ces objets. 2) Le point de vue information (information viewpoint) spécifie l’information gérée et manipulée ainsi que les traitements effectués sur cette information. 3) Le point de vue traitement (computational viewpoint) exprime une décomposition fonctionnelle d’un système en termes d’objets interagissant via leurs interfaces et ce, en faisant abstraction de la répartition. 4) Le point de vue ingénierie (engineering viewpoint) décrit l’infrastructure requise pour mettre en œuvre une spécification de traitement. Il est axé sur les mécanismes et les fonctions qui prennent en charge l’interaction répartie des objets du système. 5) Le point de vue technologie (technology viewpoint) est axé sur les choix technologiques de réalisation et d’implantation du système.. 2.

(13) Introduction générale. Afin de représenter un système ODP selon un point de vue donné, il est nécessaire de définir un ensemble structuré de concepts qui permettent d’exprimer la partie de spécification relative à ce point de vue. Cet ensemble forme un langage de point de vue. Les termes de chaque langage et les règles de structuration de ces termes sont définis en utilisant les concepts du modèle objet. Le langage d’entreprise : définit les objectifs, le domaine d’application et les politiques d’un système ODP. Le système ODP et l’environnement dans lequel il opère sont représentés par un ou plusieurs objets d’entreprise regroupés en une communauté d’entreprise liés par un contrat et par les rôles joués par ces objets. Le langage d’information : définit la sémantique de l’information et la sémantique de traitement de l’information dans un système ODP. Celui-ci est exprimé en termes d’une configuration d’objets d’information. Les relations entre les objets d’information sont modélisées comme des objets d’information ou comme parties des objets d’information. Le langage de traitement : est un modèle de programmation réparti abstrait, basé objet pour décrire la structure et l’exécution d’application répartie dans un environnement ODP. Il constitue une spécialisation du modèle objet en considérant l’objet de traitement comme unité de répartition. Une application répartie est alors structurée en un ensemble d’objets interagissant à travers leurs interfaces. Le langage de traitement définit un modèle d’interaction, des interfaces de traitement et un modèle de liaison. Le langage d’ingénierie : permet d'exprimer une spécification d'ingénierie qui définit les fonctions et les mécanismes requis pour prendre en charge l'exécution et l'interaction répartie entre les objets d'un système ODP. Le langage de technologie : décrit la réalisation du système ODP en termes de configuration d'objets techniques qui en représentent les composants matériels et logiciels. Le point de vue technologie fournit ainsi un lien entre l'ensemble des spécifications de points de vue et la réalisation effective en donnant la liste des normes utilisées pour fournir les opérations de base que requièrent les autres spécifications de points de vue. De plus, le modèle contient un ensemble de fonctions s’appelant les fonctions ODP. Elles sont au nombre de 24, organisées en 4 catégories qui participent à la simplification de la description du modèle d’architecture : 3.

(14) Introduction générale. 1) les fonctions de gestion système qui incluent la gestion des nœuds, d’objets, de grappes et de capsules ; 2) les fonctions de référentiel qui incluent les fonctions de stockage, de gestion de base d’informations, de conteneurs de types et de courtage ; 3) les fonctions de coordination qui incluent la fonction de notification d’événement, de sauvegarde et de reprise, de désactivation,. et réactivation, de groupage, de. duplication, de migration, de ramasse miettes pour les références d’interfaces d’ingénierie et de transaction ; 4) les fonctions de sécurité qui incluent les fonctions de contrôle d’accès, d’audit, d’authentification, d’intégrité, de confidentialité, de non répudiation et de gestion de clé.. II. Méthodologie de conception pour les systèmes répartis Le développement des applications ouvertes dans un environnement réparti (CORBA, OMA) a atteint aujourd'hui un premier niveau de maturité industrielle qui reste cependant limité : l'apparition de chaînes de développement logiciel permettant la fabrique de lignes de produit, à l'instar d'autres industries, n'est pas encore à l'ordre du jour. Cependant des disciplines émergentes y concourent comme l'ingénierie des modèles, confirmée entre autres par l'OMG (Object Management Group) et son initiative MDA (Model Driven Architecture). L'Architecture Dirigée par les Modèles est un thème en pleine expansion aussi bien dans le monde académique que dans le monde industriel. Elle apporte un changement important dans la conception des applications, la pérennité des savoir-faire, des gains de productivité et bénéficie des avantages des plates formes existantes. C’est une approche qui préconise de construire des applications réparties interopérables via les modèles. L’idée est d’automatiser la transformation des modèles métier d’une application pour en arriver à une solution technique sur une plate-forme de notre choix. Ainsi, en cas de changement d’architecture technique, il suffirait de regénérer un autre code du même modèle métier. Pour cela, MDA envisage de construire une chaîne automatisée de production de logiciels. Celle-ci doit être suffisamment outillée pour supporter tout le cycle de vie des applications à réaliser et garantir l’industrialisation de leur fabrication. Elle devrait être modulable et générique. De nombreuses techniques manipulant les modèles permettent la mise en œuvre de cette approche (méta-modélisation, transformation de modèles, …). Toutefois, il n’existe pas de 4.

(15) Introduction générale. consensus sur une méthodologie pour les appliquer. Parmi celles les plus répandues, la méthodologie ODAC (Open Distributed Applications Construction), orientée MDA, dont l’objectif est d’assurer une industrialisation de la production logicielle. Généralement ces méthodes permettent le développement de système avec la notation UML selon une sémantique ODP. Cependant, cette sémantique est ambigüe, et pour l’essentiel informelle.. III. Thème de recherche RM-ODP définit une architecture permettant de construire des systèmes répartis et ouverts. Il est cependant très difficile à appréhender non pas à cause de sa longueur et de ses détails mais parce qu’il est très abstrait. Il constitue une méta-norme donc non applicable directement. En effet il n’a défini ni quand ni comment produire les spécifications des différents points de vue. Il faut utiliser une méthode de génie logiciel adéquate qui servira d’outils permettant de structurer le développement de systèmes ODP. Cela consiste entre autres à situer (à correspondre) les points de vue ODP avec le processus de développement de la méthode. Un objectif majeur est de construire correctement les systèmes ODP, c'est-à-dire que les systèmes ODP doivent être par construction correctes malgré leur complexité. Les différentes spécifications de point de vue correctes et conformes entre elles (techniques de raffinement). Il faut alors que la méthode de génie logiciel utilisée aboutira à des spécifications qu’on peut prouver qu’elles sont correctes et qu’elles sont conformes entre elles. Cependant, RM-ODP n’a défini ni de relations de conformité entre les différentes spécifications, ni les moyens de validation et de vérification. Il a néanmoins, défini les concepts de modélisation et de formalisation en utilisant des langages formels standards. Or les langages préconisés ont été conçus pour l’ingénierie des protocoles et la conception de systèmes matériels. Il est donc nécessaire de disposer d’un formalisme conforme à ODP. Ce formalisme doit être intégré à la méthode de génie logiciel conforme à ODP. Ce que nous avons constaté comme insuffisance ou ce qui manque pour le développement des systèmes ODP ne constitue guère des oublis dans RM-ODP. En fait ce modèle fournit un cadre architectural et une base minimale pour coordonner et guider le développement de nouveaux standards pour le traitement réparti ouvert. Selon le modèle, le traitement réparti correspond aux différents aspects du traitement de l’information. RM-ODP est indépendant de tout domaine d’application et de toute technologie particulière. Il définit le traitement réparti 5.

(16) Introduction générale. ouvert en se basant sur lui-même. Un traitement réparti ouvert est un traitement conçu conformément aux standards ODP, qui sont RM-ODP et les standards qui lui sont conformes de façons directes ou indirectes. Ces standards incluent : -. les standards pour les composants de systèmes ODP ;. -. les standards pour la composition des systèmes ODP ;. -. les standards pour la modélisation et la spécification des systèmes ODP ;. -. les standards pour les langages de programmation ;. -. les standards pour les tests de systèmes de système ODP ;. -. la fonction de conteneur de type ;. -. les références d’interfaces ;. -. le raffinement du langage d’entreprise ;. -. la qualité de service.. L’objectif de notre thème de recherche est d’apporter une solution qui répond à certaines insuffisances précitées. Un deuxième objectif, qui est aussi important, est la transformation de modèles orientée MDA. Nous avons proposé un méta-modèle de la sémantique du langage de point de vue entreprise et un autre pour le langage de traitement fondée sur la description en UML et OCL de sémantiques dénotationnelles. Aussi, avons-nous défini avec précision les concepts de base du comportement dans le langage d’entreprise. Puis, nous avons définit un profil UML pour ces concepts de comportement. Ce profil a été mappé avec les concepts du langage BPEL.. IV. Description des travaux réalisés Pour aborder ce thème, nous avons eu à étudier les méthodes de génie logiciel, et les techniques de spécification formelle actuelles. Nous en avons déduit que les orientations actuelles sont d'une part l'unification et l'intégration, aussi bien des méthodes de génie logiciel, que des techniques de spécification et de description formelle; d'autre part, leur intégration ensemble. Ces orientations rappellent les tendances du traitement réparti. Le langage UML constitue un modèle de référence pour les langages de modélisation objet. Ses propriétés de généricité et d'extensibilité entre autres, laissent à penser qu’UML est 6.

(17) Introduction générale. adéquat pour la modélisation de systèmes ODP. Quant à la spécification formelle de systèmes ODP, les langages préconisés par RM-ODP (Z, SDL, LOTOS, ESTEREL) ne permettent pas de décrire tous les concepts du traitement réparti ouvert. Vu la complexité de problèmes à résoudre, nous avons choisi de traiter un certain nombre de problèmes représentatifs liés aux points de vue ODP. Chaque point de vue présente un nombre de problèmes en plus des problèmes communs. Nous avons choisi l’approche de méta modélisation de la syntaxe dans la définition d’UML. Nous supposons que cette syntaxe est indépendante du contexte [1,2]. Nous avons traité plusieurs problèmes : -. L’utilisation du langage OCL dans le processus de développement de systèmes ODP (plus particulièrement le point de vue entreprise et traitement) ;. -. La sémantique formelle des langages de point de vue (le point de vue entreprise et traitement) ;. -. La définition précise des concepts de base du comportement de point de vue entreprise ;. -. La transformation de modèles (le point de vue entreprise).. Nous avons traité dans un premier point l’utilisation d’OCL dans l’ingénierie des systèmes ODP. En effet, l’intégration et l’unification aussi bien des méthodes de génie logiciel que des méthodes formelles laissent penser que le langage OCL peut être utilisé dans l’ingénierie des systèmes ODP plus particulièrement pour la spécification formelle de la sémantique ODP. En deuxième lieu, nous avons définit la spécification formelle des langages de point de vue en utilisant l’approche dénotationnelle. Nous avons séparé entre la syntaxe et la sémantique. D’abord, nous avons supposé que la syntaxe est indépendante du contexte et nous avons traité le problème de la syntaxe contextuelle pour les différents concepts de structure des langages d’entreprise et de traitement. En troisième lieu, nous avons défini avec précision les concepts de base du comportement de point de vue entreprise d’ODP en ajoutant des contraintes de séquencement, de nondéterminisme et de la concurrence utilisant le langage OCL et en définissant des politiques sous forme de contraintes OCL sur le comportement du système ODP. 7.

(18) Introduction générale. En dernier lieu, la spécification du comportement établie a été transformée en spécification opérationnelle dans un environnement d’exécution cible en utilisant le langage BPEL. La transformation utilisée est de type transformation méta-modèle.. V. Plan de mémoire Dans le premier chapitre constituant l’état de l’art des travaux relatifs à notre sujet, nous présentons seulement les concepts et principes nécessaires à la compréhension de notre propos et nous donnons des pointeurs vers les sources permettant au lecteur d’approfondir ses connaissances sur le sujet. Dans un premier temps, nous exposons le modèle de référence pour le traitement réparti ouvert RM-ODP. Nous introduisons ensuite la sémantique formelle mettant l’accent essentiellement sur l’approche dénotationnelle. Enfin, nous donnons un résumé sur les récentes avancées qui ont eu lieu dans le domaine de méta-modélisation et de transformation de modèles. Dans le chapitre 2, nous traitons la nécessité de la notation formelle des langages de point de vue ODP. Ces langages sont des langages abstraits dans la mesure où ils définissent les concepts qui devraient être employés, mais pas comment devraient-ils être représentés. Une définition formelle des langages de point de vue ODP permet de tester la conformité des spécifications de différents points de vue, d'analyser et vérifier formellement les spécifications produites, et de dériver des implémentations possibles à partir des spécifications de système. Nous avons adopté l’approche dénotationnelle pour la spécification précise de la sémantique d’un sous ensemble de concepts de structure dans les deux points de vue entreprise et traitement. Nous proposons le méta-modèle de la syntaxe abstraite qui se compose des diagrammes de classe et des contraintes OCL, le méta-modèle de la sémantique en UML/OCL et nous définissons la fonction sens entre les modèles et leurs instances en utilisant OCL. Le chapitre 3 propose de définir une sémantique formelle pour un sous ensemble de concepts de comportement ODP cités dans la partie fondements RM-ODP[1,2,3,4] en particulier dans le langage d'entreprise en utilisant le langage de modélisation unifié UML, couplé avec le langage de contraintes OCL. Nous commençons par une analyse des concepts comportementaux RM-DOP centrés sur la représentation et la spécification de comportement, de temps, d’action, de rôle et de processus, nous donnons par la suite des définitions précises pour les contraintes de séquencement, de non-déterminisme et de la concurrence et nous 8.

(19) Introduction générale. terminons par la définition des politiques qui peuvent être utilisées pour identifier la spécification des contraintes sur le comportement du système ODP. Dans le chapitre 4, nous allons décrire la méthodologie de modélisation de comportement du langage d'entreprise ODP par la création d’un profil UML. Nous allons présenter le profil UML spécifique au comportement. Ce profil sera transformé au langage BPEL en faisant un mapping entre les concepts du comportement du langage d'entreprise et les concepts du langage BPEL, cette transformation, orientée MDA, va être assurée par l’utilisation de l’outil Rational rose. Finalement, Nous concluons ce travail en récapitulant les résultats obtenus et en évoquant différentes possibilités de continuation et d’extension de travail déjà réalisé.. 9.

(20) CHAPITRE I : ÉTAT DE L’ART. I.1. Introduction La croissance rapide des applications réparties a fait naître le besoin d'un cadre pour coordonner la normalisation du traitement réparti ouvert (ODP, open distributed processing). Le modèle de référence ODP fournit ce cadre et il établit une architecture qui permet la prise en compte de la répartition, de l'interfonctionnement et de la portabilité. Le modèle de référence pour le traitement réparti ouvert (RM-ODP, reference model of open distributed processing) repose sur des concepts précis issus des développements récents dans le domaine des traitements répartis et s'appuie, dans la mesure du possible, sur l'utilisation des techniques de descriptions formelles pour la spécification de l'architecture. Les méthodes formelles existent depuis plusieurs décennies et ont pour finalité la description de systèmes logiciels de façon plus mathématique. L’utilité des descriptions formelles est de faciliter la compréhension des langages, la conception et la spécification d’un système, la vérification et la validation des spécifications. En contrepartie, leur difficulté d’apprentissage et d’utilisation leur a souvent été reprochée. La sémantique a une importance décisive sur la spécification d’un système. La théorie des sémantiques doit contribuer à une spécification et vérification de systèmes de manière systématique. Les sémantiques formelles peuvent être classées selon trois catégories complémentaires: Opérationnelles, Axiomatiques, Algébriques ou Dénotationnelles. Chacune d'elles s'apprête mieux à un certain type de tâches. La méta-modélisation est une technique de définition des concepts à utiliser pour modéliser des systèmes. Elle apporte donc la flexibilité nécessaire à la fourniture de moyens adaptés aux besoins d’un processus logiciel, pour concevoir des applications.. 10.

(21) Chapitre I : État de l’art. La transformation de modèles constitue un aspect clé dans la démarche de développement des logiciels basés sur l’ingénierie dirigée par les modèles. Le succès de cette technologie repose en grande partie sur les transformations de modèles. Leur application (ou utilisation) couvre plusieurs aspects. Ce chapitre est organisé de la manière suivante : dans la première section nous présentons principalement les parties de traitement réparti ouvert RM-ODP, puis dans la section suivante nous allons traiter l’approche dénotationnelle que nous avons adopté dans cette thèse. Dans la troisième partie nous introduisons les techniques de méta-modélisations en mettant l’accent sur les transformations de modèles.. I.2. Le modèle RM-ODP Le modèle de référence ODP (ISO/CEI 10746) se compose de : -. la Rec. UIT-T X.901 | ISO/CEI 10746-1 [1], aperçu général : elle contient un aperçu général du modèle de référence ODP, en précise les motivations, le domaine d'application et la justification, et propose une explication des concepts clés, ainsi qu'une présentation de l'architecture ODP. Elle explique la façon d'interpréter le modèle de référence ODP et la manière dont il peut être utilisé, en particulier, par les auteurs de normes et les architectes de systèmes ODP. Elle contient également une classification des domaines de normalisation en matière de systèmes répartis; cette classification s'appuie sur des points de référence de conformité identifiés dans la Rec. UIT-T X.903 | ISO/CEI 10746-3. Ces textes communs ne sont pas normatifs ;. -. la Rec. UIT-T X.902 | ISO/CEI 10746-2 [2], fondements : elle contient la définition des concepts et le cadre analytique à utiliser pour la description normalisée de systèmes de traitement répartis (arbitraires). Elle s'en tient à un niveau de détail suffisant pour étayer la Rec. UIT-T X.903 | ISO/CEI 10746-3 et établir les exigences de nouvelles techniques de spécification. Ces textes communs sont normatifs ;. -. la Rec. UIT-T X.903 | ISO/CEI 10746-3 [3], architecture : elle contient la spécification des caractéristiques d'un système réparti ouvert. Ce sont les contraintes auxquelles les normes ODP doivent se soumettre. Elle utilise les techniques descriptives de la Rec. UIT-T X.902 | ISO/CEI 10746-2. Ces textes communs sont normatifs ;. 11.

(22) Chapitre I : État de l’art. -. la Rec. UIT-T X.904 | ISO/CEI 10746-4 [4], sémantique d'architecture : elle contient une formalisation des concepts de modélisation ODP définis dans la Rec. UIT-T X.902 | ISO/CEI 10746-2, articles 8 et 9. La formalisation s'obtient en interprétant chaque concept à partir d'éléments des différentes techniques normalisées de descriptions formelles. Ces textes communs sont normatifs.. I.2.1. Présentation générale de RM-ODP La norme de traitement réparti ouvert (ODP), développée conjointement par l'ISO et l'ITU-T, fournit un modèle de référence qui définit un cadre architectural pour la construction de systèmes et applications réparties ayant un ensemble de caractéristiques importantes telles que l’ouverture, la facilité d’intégration, la flexibilité, la modularité, la sécurité, la transparence, le contrôle de la qualité de service. Ce modèle de référence ne vise pas à fournir une méthodologie concrète de conception ou de développement. Pourtant, il fournit un cadre de description des architectures selon plusieurs niveaux d’abstraction. Le modèle de référence ODP (RM-ODP) définit deux modèles : un modèle objet et un modèle architectural que nous présentons ci-après. La vue générale du modèle RM-ODP est présentée dans la figure suivante :. 12.

(23) Chapitre I : État de l’art. Figure 1 : Modèle architectural de RM-ODP [6]. I.2.2. Le modèle objet Le modèle de référence ODP a pour but d’offrir un cadre conceptuel qui permet de spécifier rigoureusement l’architecture de systèmes répartis dans un environnement de communication et d’exécution hétérogène. Il définit pour cela un modèle générique d’architecture, et normalise des points de vue, qui décrivent chacun un aspect différent du système. ODP repose sur un modèle orienté objet. Un objet est l’entité qui résulte de l’encapsulation d’un ensemble de données et des opérations (ou méthodes) qui peuvent être réalisées sur ces données. Le service offert par un objet, représenté par son interface, est dissocié de son implantation. L’interface d’un objet est son point d’accès pour les autres objets. Elle caractérise les interactions que celui-ci peut avoir avec son environnement. Un objet ne possède habituellement qu’une seule interface, composée d’un ensemble de méthodes rendues ainsi accessibles aux autres objets. Dans le cadre du modèle RM-ODP, un objet peut avoir. 13.

(24) Chapitre I : État de l’art. plusieurs interfaces. Par exemple, il peut disposer d’une interface de service, qui permet de l’invoquer et d’une interface de contrôle, destinée à son administration. ODP autorise également la construction d’objets composites, par l’agrégation de plusieurs objets coopérants. La composition permet de décrire une relation hiérarchique entre objets. Ainsi composer deux objets permet d'en générer un nouveau, appelé objet composite. Réciproquement, la décomposition est un procédé de raffinement permettant de passer d'une application répartie complexe à un ensemble d'objets plus simples qui pourront à leur tour être décomposés. Composition et décomposition sont des termes et des activités de spécification duales, qui s'appliquent non seulement aux objets mais également aux comportements. Le modèle de référence ODP ne fait pas d’hypothèse sur l’application de ce modèle. Un objet peut être aussi élémentaire qu’un simple entier ou être d’une complexité arbitraire . Un objet peut également afficher n’importe quel comportement interne. Il peut en particulier mettre en oeuvre des formes quelconques de parallélisme. Enfin, les interactions entre objets ne sont pas contraintes : elles peuvent être asynchrones, synchrones ou isochrones, sous une forme discrète ou continue.. I.2.3. Le modèle architectural Le modèle architectural ODP est construit sur la notion de point de vue. Un point de vue est une subdivision d'une spécification d'un système complexe. Il permet pendant la phase de conception de considérer le système sous un angle particulier en ne s'intéressant qu'à la partie de spécification relative à celui-ci. Chaque point de vue représente une abstraction différente du même système. Les points de vue ne forment pas une séquence fixe et ne doivent donc pas être assimilés à une structuration en couches. De même, ils ne sont pas créés dans un ordre fixe selon une méthodologie de conception. Notons d'ailleurs que le modèle de référence ODP ne constitue pas en soi une méthodologie de spécification de systèmes répartis, même si beaucoup l'utilisent comme tel. Il définit une architecture qui utilise pour les besoins de sa spécification une séparation en cinq points de vue ci-après.. I.2.3.1. Les points de vue I.2.3.1.1. Point de vue Entreprise Le point de vue Entreprise définit une vision conceptuelle de l’architecture étudiée. Il décrit les entités de l’entreprise, c’est-à-dire les communautés et les rôles, les comportements et les. 14.

(25) Chapitre I : État de l’art. interactions entre ces derniers, les acteurs, les processus, les règles de gestion, les droits et les obligations, ce que l’on appelle de façon générale la politique de l’entreprise. Il fournit une spécification du système dans l’environnement avec lequel il interagit. Cette spécification s’intéresse plus spécialement aux objectifs et à la politique du système. Généralement, ce point de vue exprime les besoins et les exigences définies par l’organisation. Un concept de structuration majeur d'une spécification d'entreprise est celui de communauté. Une communauté est une configuration d’objets d’entreprise formée pour remplir un objectif dit métier. Elle modélise une collection d’entités (êtres humains, système de traitement d'information, ressources variées, etc) sujets à un contrat implicite ou explicite gouvernant leur comportement collectif. Au sein d'une communauté, les objectifs des membres sont contraints pour être conforme à l'objectif de la communauté. Une spécification d’entreprise inclut au moins la description d’une communauté dans laquelle le système ODP est vu comme un objet unique d'entreprise interagissant avec son environnement. Cette communauté est désignée sous le terme (<S>community). Une spécification d’entreprise peut inclure la description de plus d'une communauté. Elle peut ainsi être structurée en un ensemble de communautés qui interagissent, chacune de ces communautés étant alors vue comme un objet composite (appelé le c-objet). Une spécification d'entreprise est ainsi composée des spécifications de différents éléments tels que communautés, rôles, objets d'entreprise etc. Selon le choix du modélisateur et le niveau de détail souhaité, chacun de ces éléments peut être spécifié par les caractéristiques de l'élément, ou par le type de l'élément ou par un gabarit de l'élément. La norme ne fait aucune prescription sur le processus de spécification ou sur le niveau d’abstraction utilisée dans une spécification d'entreprise. L'objectif de la communauté est donc ce qui motive son existence. Au sein d'une communauté, chaque objet d'entreprise joue un rôle. Un objet peut jouer plusieurs rôles, dans la même communauté ou dans des communautés distinctes. Il peut participer à différents processus. Réciproquement, un rôle peut être rempli par différents objets, mais de façon successive dans le temps et non simultanée. Autrement dit, à un instant donné, un rôle est rempli par un et un seul objet. Le rôle d'acteur dans une communauté est distinct de celui. 15.

(26) Chapitre I : État de l’art. d'artefact. Vis-à-vis d'une action, l'acteur est l'objet qui participe à l'action et l'artefact est l'objet qui est référencé dans l'action. Jouer un rôle d'acteur dans une communauté signifie alors que l'objet est acteur pour au moins une action de ce rôle tandis que jouer un rôle d'aterfact dans une communauté signifie que l'objet est artefact pour toutes les actions de ce rôle. Assigner des objets aux rôles de la communauté permet de peupler la communauté. Le comportement d'un objet auquel on assigne un rôle doit alors être cohérent avec le comportement identifié par ce rôle. Cette assignation peut varier dynamiquement pendant la durée de vie de la communauté. De même, la création et la destruction de rôles sont envisageables. Une spécification d'entreprise doit établir les circonstances de tels changements. L'inclusion de ces changements dans la spécification relève d'un choix de modélisation, i.e., les comportements associés à ces changements peuvent être explicites ou non. La terminaison d'une communauté est également un choix de modélisation. Elle peut se produire car l'objectif a été atteint, ou qu'il y a eu échec dans la recherche de l'objectif. Le comportement de terminaison peut être inclus explicitement ou non dans la spécification. Les politiques, quant à elles, expriment les contraintes sur le comportement des objets jouant un rôle d’acteurs. Une politique s’applique à la communauté, à un ou plusieurs rôles ou à un type d’actions. Elle peut être exprimée comme une obligation, une autorisation, une permission ou une interdiction, les définitions suivantes devant s'appliquer à ces termes : -. Obligation : prescription stipulant la nécessité d'un comportement particulier ;. -. Autorisation : prescription stipulant qu'un comportement particulier ne doit pas être empêché ;. -. Permission : prescription autorisant un comportement particulier ;. -. Interdiction : prescription stipulant qu'un comportement particulier ne doit pas se manifester.. Un type particulier de communauté est la fédération, qui est une communauté de domaines établie à des fins de coopération. Le concept de fédération permet d'établir les principes généraux d'interfonctionnement entre domaines et de décrire les politiques gouvernant cet inter-fonctionnement.. I.2.3.1.2. Point de vue Information. 16.

(27) Chapitre I : État de l’art. Le point de vue Information est employé pour définir la sémantique de l'information et la sémantique du traitement de l'information nécessaires à une application définie selon le modèle ODP. Cette définition est faite en utilisant trois schémas : statique, invariant et dynamique, qui décrivent l'état et la structure d'un objet. -. le schéma statique capture l'état et la structure d'un objet à un certain moment particulier (par exemple, un état d'initialisation ou un état d'exception) ;. -. Le schéma invariant définit la limite de l'état et la structure d'un objet à tout moment ;. -. Le schéma dynamique spécifie le changement autorisé de l'état et de la structure d'un objet.. Les schémas peuvent également être employés pour décrire des relations ou des associations entre les objets. Un schéma peut se composer d'autres schémas pour décrire les objets complexes ou composés. Les schémas statique et dynamique doivent respecter les contraintes de tout schéma d'invariant. Comme RM-ODP n’impose pas une méthode pour décrire les points de vue, les spécifications du point de vue Information d'une application d'ODP peuvent être exprimées par de nombreuses méthodes, par exemple, par les modèles entités-relations, les schémas conceptuels, la méthode formelle Z, ou le langage UML [7].. I.2.3.1.3. Point de vue Traitement Le point de vue Traitement s’intéresse à la décomposition fonctionnelle d’un système en objets qui interagissent grâce à leurs interfaces et ce, en faisant abstraction de la répartition. La spécification de ce point de vue contient une configuration des objets de traitement, les spécifications des actions de ces objets, la spécification des interactions entre objets, les spécifications des interfaces qui supportent les interactions, la spécification des liaisons pour supporter les interfaces, les contraintes qui s’appliquent sur les interactions entre les objets de traitement, et les contrats d’environnements pour assurer le traitement correct des contraintes pour les objets et leurs environnements [5-6].. I.2.3.1.4. Point de vue Ingénierie Une spécification d'ingénierie définit les fonctions et les mécanismes requis pour prendre en charge l'exécution et l'interaction répartie entre les objets d'un système ODP. Contrairement. 17.