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

Transcription

1 UNIVERSITE MOHAMMED V AGDAL FACULTE DES SCIENCES Service des affaires estudiantines RABAT N d ordre : 2479 Discipline : Informatique Spécialité : Systèmes répartis et réseaux THÈSE DE DOCTORAT Présentée par Youssef BALOUKI 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 RP, Rabat-Maroc. Tel : (0) /35/38, Fax : (0) ,

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 I.1. Introduction I.2. Le modèle RM-ODP I.2.1. Présentation générale de RM-ODP I.2.2. Le modèle objet I.2.3. Le modèle architectural I Les points de vue I Point de vue Entreprise I Point de vue Information I Point de vue Traitement I Point de vue Ingénierie I Point de vue Technique I Les langages de points de vue I Le langage d entreprise I Le langage d information I Le langage de traitement I Le langage d ingénierie I Les fonctions ODP I Les transparence ODP I.3. La sémantique formelle I.3.1. La syntaxe I La syntaxe concrète I La syntaxe abstraite I.3.2. Les principales méthodes de description de la sémantique I Sémantique opérationnelle I Sémantique axiomatique(ou predicate transformer) I.3.3. Sémantique dénotationnelle I la composition I Sémantique statique et dynamique iii

6 I L approche dénotationnelle I Syntaxe abstraite I L algèbre sémantique I La relation entre la syntaxe et la sémantique I Exemple : Application sur un langage de spécification QML I La syntaxe abstraite de QML I Algèbre sémantique de QML I Fonctions sémantiques pour QML I.3.4. La cohérence des définitions sémantiques I.4. Méta-modélisation et transformation de modèles I.4.1. Techniques de méta-modélisation I Modèles et méta-modèles I Le besoin de méta-modélisation I Une architecture de méta-modélisation à quatre niveaux I Le MOF : Un langage de définition de méta-modèles I.4.2. Transformation des modèles I.4.3. Les standards pour la manipulation des modèles I Le MOF I Les langages UML et OCL I Les profils UML I Le format d échange normalisé : XMI I.5. Conclusion Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL II.1. Introduction II.2. Travaux connexes II.3. Stratégie de formalisation II.3.1. La convenance du méta-modèle II.3.2. L utilisation du standard II.3.3. La précision de la sémantique de base II.4. RM-ODP II.4.1. Le modèle objet ODP II.4.2. Utilisation des langages de point de vue II.4.3. Le langage d'entreprise RM-ODP II.4.4. Le langage de point de vue traitement RM-ODP II.5. Sémantique dénotationnelle pour le langage de point de vue entreprise II.5.1. Domaine Syntaxique II.5.2. Domaine sémantique II.5.3. La fonction de signification II.6. Sémantique dénotationnelle pour le langage de point de vue traitement II.6.1. Domaine Syntaxique II.6.2. Domaine sémantique II.6.3. La fonction de signification II.7. Conclusion Chapitre III : Une sémantique dénotationnelle pour un sous-ensemble de concepts de comportement du langage d entreprise III.1. Introduction iv

7 III.2. Concepts de modélisation de base du comportement ODP III.3. Meta-modélisation du temps et des contraintes comportementales III.3.1. Temps III.3.2. contraintes Comportementales III Contraintes de séquencement III Contraintes de la concurrence III Contraintes de non-déterminisme III.4. Les politiques de comportement dans le Langage Entreprise RM-ODP III.4.1. Obligation III.4.2. Permission III.4.3. Interdiction III.5. Conclusion Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP IV.1. Introduction IV.2. Langage d exécution des processus métiers IV.2.1. Introduction au BPM : Business Process Management IV.2.2. Langage BPEL IV.3. La fonction de courtage IV.4. Spécification de la fonction de courtage du point de vue entreprise IV.5. Profil UML pour des processus automatisés de comportement IV.6. Transformation au BPEL IV.6.1. D'UML à BPEL IV.6.2. Exécution du processus de comportement IV.6.3. Démarche de transformation d UML au BPEL IV.6.4. Implémentation du processus de comportement IV La construction et l exportation du modèle IV Génération du BPEL et WSDL IV.7. Conclusion Conclusion générale et perspectives Bibliographie Annexes Annexes A : Grammaire du langage OCL v

8 LISTE DES FIGURES Figure 1 : Modèle architectural de RM-ODP Figure 2 : La spécification au point de vue Ingénierie Figure 3 : Les objets du point de vue Ingénierie Figure 4: La relation entre les points de vue ODP Figure 5 : Types de liaisons Figure 6 : Système de translation d un langage de programmation Figure 7 : Interpréteur Figure 8 : Domaines syntaxiques du langage QML Figure 9 : Domaines sémantiques du langage QML Figure 10 : Fonctions de valuation pour les domaines syntaxiques de QML Figure 11 : Relation entre les diverses sémantiques Figure 12 : L architecture à quatre niveaux Figure 13 : Le MOF version Figure 14 : Transformation de méta-modèle Figure 15 : Le processus de formalisation Figure 16 : RM-ODP Foundation Object Model Figure 17 : Méta-modèle de la syntaxe abstraite du langage d entreprise Figure 18 : Méta-modèle des domaines sémantiques du langage d entreprise Figure 19 : Méta-modèle de la syntaxe abstraite du langage de traitement Figure 20 : Méta-modèle des domaines sémantiques du langage du traitement Figure 21 : Relation entre domaines syntaxique et sémantique des différentes méthodes formelles Figure 22 : Concepts de base de modélisation de comportement Figure 23 : (a) les contraintes déterministes séquentielles (b) les contraintes non déterministes séquentielles Figure 24 : Diagramme RM-ODP - Contraintes de la concurrence Figure 25 : Diagramme RM-ODP - Exemple de contraintes de non-déterminisme Figure 26 : Un méta-modèle pour des concepts de comportement et de politique Figure 27 : Collaboration entre différents acteurs Figure 28 : Méta-modèle du langage BPEL Figure 29 : La fonction de Trading dans ODP Figure 30 : Une classe UML modélise le processus du comportement BPEL Figure 31 : Un diagramme d'activité du processus de comportement Figure 32 : Développement d un processus Figure 33 : Modélisation et Exportation avec XDE Figure 34 : Transformation du fichier XMI Figure 35 : Déploiement du processus Figure 36 : Déploiement des services LISTE DES TABLEAUX Tableau 1 : Mapping entre concepts de comportement et constructions UML Tableau 2 : Mapping entre constructions UML et concepts BPEL 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'inter- fonctionnement 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 [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 Ces textes communs ne sont pas normatifs ; - la Rec. UIT-T X.902 ISO/CEI [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 et établir les exigences de nouvelles techniques de spécification. Ces textes communs sont normatifs ; - la Rec. UIT-T X.903 ISO/CEI [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 Ces textes communs sont normatifs ; 11

22 Chapitre I : État de l art - la Rec. UIT-T X.904 ISO/CEI [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 , 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 Les points de vue I 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 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 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 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

28 Chapitre I : État de l art au point de vue traitement qui permet de considérer quand et pourquoi les objets interagissent, le point de vue ingénierie s'intéresse à la façon dont ils interagissent (le "comment"). Le point de vue Ingénierie est employé pour décrire des aspects répartition d'un système d'odp. Il définit un modèle pour l'infrastructure distribuée du système. Le point de vue Ingénierie n'est pas concerné par la sémantique de l'application d'odp, excepté pour déterminer les conditions et la transparence de la répartition. Par ailleurs, il s intéresse d une part aux moyens pour prendre en charge l interaction répartie des objets, et d autre part aux mécanismes de placement des objets sur les ressources d exécution. Les entités fondamentales décrites dans le point de vue Ingénierie sont des objets et des canaux. Des objets peuvent être divisés en deux catégories : les objets dits basiques (correspondant aux objets définis dans les spécifications du point de vue Traitement) et les objets d'infrastructure (par exemple, un objet de protocole) qui sont déterminés dans le point de vue Ingénierie. Un canal correspond à une liaison (binding) ou à un objet de liaison (binding) dans les spécifications Traitement. Le canal Un canal fournit le mécanisme de communication et contient les fonctions de transparence exigées par les objets basiques de niveau Ingénierie, comme indiqués dans les contrats d'environnement dans les spécifications Traitement. Le schéma ci-dessous illustre le canal entre un objet de client et l'objet de branche de banque. Le secteur ombragé est le canal, composé des talons, des lieurs, et des objets de protocole. Des talons et des lieurs sont employés pour fournir les diverses transparences de distribution. Figure 2 : La spécification au point de vue Ingénierie [6] 18

29 Chapitre I : État de l art Les structures Ingénierie Le point de vue Ingénierie de RM-ODP préscrit la structure d'un système d'odp sans définir les composants techniques. Cependant, les objets suivants constituent la base de description des ressources d exécutions des objets basiques du point de vue Ingénierie (voir Figure 3). Cluster : une configuration d objets basiques d ingénierie formant une unité pour les traitements de type activation, désactivation, réactivation, restauration, migration. Gérant de cluster : un objet gérant les objets dans un cluster. Capsule : une configuration d objets d ingénierie formant une unité pour l encapsulation des traitements et du stockage, par exemple une machine virtuelle ou un processus. Une capsule contient un ensemble de clusters. Gérant de Capsule : un objet gérant les objets dans une capsule. Nœud : un objet qui regroupe un ensemble de fonctions de type traitement, stockage et communication, par exemple un ordinateur. Noyau : un objet qui coordonne les traitements, le stockage et la communication pour les objets au sein du nœud auquel il appartient, par exemple un système d exploitation. Figure 3 : Les objets du point de vue Ingénierie [6] Étant donné ces définitions, les règles structurantes suivantes sont définies : 19

30 Chapitre I : État de l art - chaque nœud a un objet de noyau ; - chaque objet de noyau peut soutenir plusieurs capsules ; - chaque capsule peut contenir plusieurs clusters ; - chaque cluster peut contenir des objets basiques Ingénierie ; - chaque objet de base Ingénierie peut contenir plusieurs activités. Toute la communication inter-clusters se fait par l'intermédiaire des canaux. I Point de vue Technique Des spécifications du point de vue Technique d'un système d'odp décrivent l'exécution de ce système et l'information exigée pour le test. Il s intéresse aux choix matériels et logiciels effectués pour implanter les spécifications résultant des autres points de vue. Ces aspects sortent du champ de normalisation. La Figure 4 montre les relations existantes entre les parties regroupant les concepts ODP. Le fait qu'il y ait des relations entre les points de vue ne consiste pas à créer un système en couches. Chaque point de vue est une abstraction du système spécifié et peut ensuite être présent dans les couches basses ou hautes des réseaux. Les fonctions de transparence et de gestion sont surtout présentes dans le point de vue ingénierie, ces fonctions traitant en fait de la répartition du système ODP. Figure 4: La relation entre les points de vue ODP I Les langages de points de vue 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 20

31 Chapitre I : État de l art à 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. I Le langage d entreprise Il s utilise pour définir 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. La finalité d une spécification d entreprise est d identifier les actions requises par les politiques gouvernant la communauté spécifiée. Ces politiques fixent le cadre de l application du contrat de la communauté en définissant les actions permises, obligatoires ou interdites à un objet. I Le langage d information 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. Une spécification consiste en un ensemble de gabarit d objet d information. Un gabarit est décrit en termes de trois schémas qui sont le schéma d invariant, le schéma statique et le schéma dynamique. Le schéma d invariant est un ensemble de prédicats sur un ou plusieurs objets d information qui doivent toujours être vrais. Le schéma statique spécifie l état d un ou plusieurs objets à un instant donné. Le schéma dynamique spécifie les changements d états autorisés par un ou plusieurs objets d information. Ces changements peuvent inclure la création ou la suppression d objets d information. Les schémas statique et dynamique doivent respecter les contraintes de tout schéma d invariant. I Le langage de traitement 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. 21

32 Chapitre I : État de l art A. Le modèle d'interaction Dans le point de vue traitement, les interactions entre objets sont essentiellement asynchrones, reflétant en cela les hypothèses sur la nature des environnements répartis (absence d'horloge globale, d'état global, délais arbitraires des communications, possibilité de défaillance, etc.). Une interaction peut prendre la forme suivante : - Une opération est similaire à une procédure et est invoquée à une interface désignée. L'opération reflète le paradigme client-serveur. C'est une interaction entre un objet client et un objet serveur par laquelle l'objet client demande l'exécution d'une fonction par l'objet serveur. Il y a deux types d'opérations : o L'interrogation est une fonction qui retourne un résultat. Une interrogation peut être synchrone (bloquante) au sens où le client est suspendu en attente du résultat ou asynchrone (non bloquante). Elle est composée de l'invocation, initiée par l'objet client vers l'objet serveur, qui correspond à la demande de l'exécution d'une fonction par cet objet serveur. Elle est suivie de la terminaison qui constitue la réponse de l'objet serveur à l'invocation. Invocation et terminaison vont toujours de paire. Cette notion de terminaison généralise les notions de résultat et d'exception existant dans la plupart des langages de programmation basés objet ou non ; o L'annonce est une invocation d'opération sans retour de résultat. Elle est initialisée par un objet client aboutissant à l'acheminement d'informations d'un objet client vers un objet serveur, et demandant l'exécution d'une fonction par cet objet serveur. - Un flux est une abstraction de séquences d'interactions aboutissant à l'acheminement d'informations d'un objet producteur (source des informations) vers un objet consommateur (collecteur des informations). Par exemple, un flux peut être utilisé pour modéliser le débit d'information audio ou vidéo d'une application multimédia ou d'un service de télécommunication. Ce peut être également un transfert de fichiers. Sous Unix, on pourrait assimiler un flux à un socket. Un flux est caractérisé par son nom et son type, qui spécifie la nature et le format des données échangées. - Un signal est une interaction atomique élémentaire aboutissant à une communication unilatérale d'un objet initiateur vers un objet répondeur (c'est-à-dire acceptant la 22

33 Chapitre I : État de l art communication). Il correspond par exemple à un événement ou une interruption. Sous Unix, on pourrait assimiler le signal à un signal Unix. Une opération ou un flux peut être exprimé par une combinaison de signaux. Par exemple une interaction peut être comprise comme une séquence de quatre signaux qui sont l'émission d'invocation par l'objet client, la réception d'invocation par l'objet serveur, l'émission de terminaison par l'objet serveur et la réception de terminaison par l'objet client. En ce qui concerne les flux le langage de traitement ne définissant pas leur sémantique exacte, leur correspondance en une combinaison de signaux n'est pas définie. B. Les interfaces de traitement Une interface de traitement se caractérise par une signature, un comportement et un contrat d'environnement. La signature dépend du type d'interface, qui peut être opération, flux ou signal : - Une interface opération à une signature qui définit quel jeu d'opérations cette interface met en œuvre et si l'interface joue le rôle de client ou de serveur pour ce jeu d'opérations ; - Une interface flux à une signature qui définit quel jeu de flux cette interface met en œuvre et, pour chaque flux, si l'interface joue le rôle de producteur ou de consommateur ; - Une interface signal à une signature qui définit quel jeu de signaux cette interface met en œuvre et, pour chaque signal, si l'interface joue le rôle d'initiateur ou de répondeur. Les signatures d'interface opération sont décrites par un langage de définition d'interface IDL (Interface Definition Language) qui est celui de CORBA [7]. Le comportement est décrit par les séquences d'actions permises aux objets de traitement qui sont associés à l'interface. Le comportement peut comprendre des actions internes à l'objet. Il est soumis aux contraintes d'environnement de l'objet résultant, en particulier, d'interactions intervenant sur d'autres interfaces. Un objet peut avoir plusieurs interfaces de différentes catégories. Il peut donc jouer plusieurs rôles. Par exemple, un objet peut être client ou serveur. Dans ce cas, il a obligatoirement au minimum deux interfaces opération, une interface client et une interface serveur, puisque le 23

34 Chapitre I : État de l art rôle client ou serveur s'applique à l'interface opération dans son ensemble et non à une opération dans une interface opération. Il peut bien sûr en avoir plus de deux. Par contre le rôle d'un objet consommateur ou producteur s'appliquant à un flux d'une interface flot, un objet peut être producteur et consommateur tout en ayant une seule interface flot. Le nombre d'interfaces de l'objet peut varier. Une spécification de traitement définit un ensemble initial d'objets de traitement et leur comportement. La configuration change selon que les objets de traitement instancient d'autres objets de traitement ou d'autres interfaces de traitement, exécutent des actions de liaisons, remplissent des fonctions de contrôle sur des objets de liaison et suppriment des interfaces de traitement ou des objets de traitement. Il est important de noter que toute spécification d'interface comporte aussi un contrat d'environnement qui spécifie un jeu de contraintes de qualité de service portant sur un objet de traitement et son environnement. Si l'environnement, qui est constitué d'autres objets de traitement et de l'infrastructure sous-jacente, tient le niveau demandé de qualité de service, alors il est garanti par construction que l'objet lui-même fournira un certain niveau de qualité de service. Les caractéristiques de qualité de service spécifiées à une interface expriment à la fois les exigences qu'elle porte sur son environnement et la qualité de service qu'exhibe l'objet s'il est placé dans un environnement qui répond aux exigences. Le langage de traitement ne normalise pas de notation particulière pour la spécification de la qualité de service. C. Le modèle de liaison Les interactions entre interfaces de traitement nécessitent préalablement l'établissement d'une liaison (binding) entre elles, c'est à dire un chemin de communication. On distingue les liaisons implicites des liaisons explicites : Les liaisons implicites sont spécifiées pour les interfaces opération. Lorsqu'un objet client invoque une opération d'une interface serveur à laquelle il n'est pas lié, une liaison implicite est établie par l'infrastructure qui crée l'interface opération client de type de signature complémentaire à l'interface serveur et qui lie les deux interfaces. La suppression de l'interface client, une fois que l'opération invoquée est terminée, est facultative (voir Figure 5). 24

35 Chapitre I : État de l art Figure 5 : Types de liaisons [6] Les liaisons explicites lient des interfaces flot ou des interfaces opération. Leur établissement résulte d'actions effectuées par un objet de traitement. Ces actions sont spécifiées par le langage de traitement. Deux types de liaison explicites sont identifiés : les actions de liaison primitive et les actions de liaison composite : - les actions de liaison primitive lient deux interfaces du même objet ou de deux objets de traitement différents. Une telle action est paramétrée par deux identificateurs, un pour chaque interface. Elle nécessite que les deux interfaces soient de même catégorie (signal, flot ou opération), et aient des types de signature et des rôles complémentaires (par exemple, si l'une est cliente, l'autre est serveur). Le langage de traitement ne définit pas explicitement d'action de suppression de liaison. Cependant, supprimer une interface, qu'une action de liaison primitive a liée à une autre, entraîne la suppression de la liaison ; - les actions de liaison composite lient un ensemble d'interfaces (deux ou plus) à l'aide d'un objet de liaison, qui est un objet de traitement prenant en charge la liaison. Une telle action est initiée indifféremment par un objet impliqué dans la liaison. Elle a pour conséquence l'instanciation de l'objet de liaison. Celui-ci instancie alors un ensemble d'interfaces correspondant à l'ensemble à lier et utilise les actions de liaison primitive pour effectivement relier les deux ensembles. Il instancie également un ensemble d'interfaces de contrôle en retournant les identificateurs de ces interfaces à l'objet initiateur de la liaison. Ces interfaces de contrôle permettent la supervision de fonctionnement et entre autres de la qualité de service qu'elle offre. A travers ces interfaces, il est par exemple possible de modifier l'appartenance de la liaison ou le modèle de communication activé par la liaison ou de supprimer la liaison dans son 25

36 Chapitre I : État de l art ensemble. La liaison composite est un moyen permettant de construire des interactions complexes entre objets, dépassant ainsi le mode d'interaction primitif du modèle qui est point à point. D'autre part, un objet de liaison peut lui-même être composé d'objets de traitement interagissant via de nouveaux objets de liaison. Le nombre de schémas de communications pouvant être ainsi élaborés est potentiellement infini et inclut par exemple la diffusion, les communications de groupe ou les conférences. I Le langage d ingénierie 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. D'un point de vue ingénierie, une application répartie est un ensemble d'objets d'ingénierie de base interagissant via un canal de communication. Les concepts de ce langage sont nœud (ordinateur), noyau (système d exploitation), capsule (espace d adressage) et grappe (modules liés pour former une exécutable) et objet d ingénierie (module d un programme). I Les fonctions ODP Le modèle de référence identifie un certain nombre de fonctions fondamentales pour la construction des systèmes ODP [8-9]. Celles-ci prennent en charge les exigences des points de vue traitement et ingénierie et sont suffisamment génériques pour être appliquées à un grand nombre d applications. Ces fonctions sont regroupées en quatre catégories : 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 conteneur 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 groupe, 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é. 26

37 Chapitre I : État de l art I Les transparence ODP La transparence à la répartition est une fonction qui permet de masquer à un utilisateur le comportement potentiel de certaines parties du système. Les utilisateurs sont aussi les utilisateurs finaux, les développeurs d applications que les réalisateurs de fonctions ODP. Le modèle définit un ensemble de transparences qui permettent la mise en œuvre de systèmes ODP transparents à la répartition du point de vue de leurs utilisateurs. Ce sont : 1) la transparence à l accès, qui masque les différences dans la représentation des données et les mécanismes d invocation pour permettre l inter-fonctionnement entre objets ; 2) la transparence à la défaillance, qui masque, au niveau d un objet, les défaillances et la possibilité de reprise d autres objets, pour garantir la tolérance aux fautes ; 3) la transparence à la localisation, qui masque l utilisation des informations de localisation dans l espace lors de l identification et de liaison à des interfaces ; 4) la transparence à la migration, qui masque au niveau d un objet, la capacité d un système à modifier la localisation d un objet. La migration est utilisée pour équilibrer la charge et réduire le temps de latence ; 5) la transparence à la relocalisation, qui masque la relocalisation d une interface vis-àvis des autres interfaces qui lui sont liées ; 6) la transparence à la duplication, qui masque l utilisation d un groupe d objets mutuellement compatibles dans leurs comportements pour prendre en charge une interface. La duplication est souvent utilisée pour augmenter les performances et la disponibilité ; 7) la transparence à la persistance, qui masque, au niveau d un objet, la désactivation et la réactivation d autres objets. La désactivation et la réactivation sont souvent utilisées pour maintenir la persistance lorsqu un objet ne peut pas lui assurer de manière continue les fonctions de traitement, de stockage et de communication ; 8) la transparence aux transactions, qui masque la coordination des activités participant à une configuration d objets pour en assurer la cohérence. Le modèle de référence n impose pas l utilisation d un ensemble défini de transparences à la répartition. Le langage d ingénierie fournit au contraire une structure flexible au sein de laquelle différentes transparences à la répartition peuvent être utilisées et combinés à la 27

38 Chapitre I : État de l art discrétisation du concepteur. Choisir des transparences est alors un choix de conception reflétant les compromis inhérents à la construction d un système réparti. I.3. La sémantique formelle Un langage de spécification a trois caractéristiques principales [12] : 1) Syntaxe : définit la structure ; 2) Sémantique : l'attribution d un sens aux différentes structures ; 3) Pragmatique : Inclut les domaines possibles d'application du langage, la facilité d'exécution et d'utilisation, et l efficacité dans la réalisation des objectifs fixés. La sémantique a une importance décisive sur le comportement d un système. Dans ce contexte, plusieurs questions se posent : - Qu elle est l utilité d un sens ou d une sémantique si elle est incohérente? - Conduit-elle à des contradictions? - Est-elle ambiguë «la même notation peut avoir plusieurs sens»? - Peut-elle conduire à des catastrophes «dans des domaines critiques»? D où la nécessité d utiliser des méthodes formelles afin de décrire les systèmes logiciels de façon plus mathématique. Les sémantiques formelles peuvent être classées selon trois catégories complémentaires : Opérationnelles, Axiomatiques, Dénotationnelles appelés aussi Algébriques, chacune d'elles s'apprête mieux à un certain type de tâches. Nous allons présenter ces trois sémantiques en se concentrant sur la sémantique dénotationnelle qui est l objet de notre travail. I.3.1. La syntaxe La syntaxe se rapporte aux manières de combiner les symboles pour créer des phrases bien formées dans le langage. Elle définit les relations formelles entre les constituants d'un langage, fournissant de ce fait une description structurale des diverses expressions qui composent les chaînes légales dans le langage. La syntaxe traite seulement la forme et la structure des symboles sans donner de l importance à leur signification. Cependant, La syntaxe doit être indiquée avant la sémantique puisque la signification peut être donnée seulement aux expressions correctement formées dans un langage. 28

39 Chapitre I : État de l art I La syntaxe concrète Les méthodes formelles ont eu plus de succès avec la description de la syntaxe des langages de programmation qu'avec explication de leur sémantique [11]. Définition : Une grammaire < Σ, N, P, S> se compose de quatre parties : 1) Un ensemble fini Σ des symboles terminaux, l'alphabet du langage, qui sont assemblés pour composer les phrases. 2) Un ensemble fini N de symboles non terminaux ou de catégories syntaxiques, qui représente une certaine collection de sous expressions des phrases. 3) Un ensemble fini P de productions ou règles qui décrivent comment chaque non terminal est défini en terme de symboles terminaux et non terminaux. 4) Un S non terminal distingué, le symbole racine, qui indique la catégorie principale. La forme de Backus-Naur (souvent abrégée en BNF, de l'anglais Backus-Naur Form) est une notation permettant de décrire les règles syntaxiques des langages de programmation. C est donc un métalangage. Elle est une notation pour des grammaires formelles de type horscontexte (car on définit les termes hors de leur contexte, pour remplacer ensuite la définition desdits termes dans ce contexte). En utilisant la BNF, on peut spécifier la syntaxe d un langage par une grammaire constituée d un ensemble de productions. Chaque production décrit la forme d une certaine classe d éléments du langage tels que les instructions, les expressions, les routines, etc. La BNF et ses variantes fournissent un mécanisme de description de la syntaxe raffiné. Mais elles ne sont pas les meilleures pour étudier en profondeur les langages de programmation. Plus précisément, une spécification en BFN décrit la vue extérieure des programmes, tels qu ils sont vus par les programmeurs, et non leur structure. Les productions BNF renferment plusieurs détails non pertinents tels que les mots-clé et autres conventions syntaxiques externes. I La syntaxe abstraite Dans la définition formelle des langages de programmation, la syntaxe abstraite s'oppose à la syntaxe concrète. Tandis que cette dernière décrit la forme extérieure, la syntaxe abstraite tend 29

40 Chapitre I : État de l art à donner simplement les composants de chaque construction du langage, sans préciser les détails de la représentation. Une description de la syntaxe abstraite d un langage nommée une «grammaire abstraite». Une telle grammaire est constituée d un ensemble fini des noms de constructions et d un ensemble fini de productions, chacune est associée à une construction. Chaque construction sert à décrire la structure d un ensemble d objets ayant une certaine forme. Une production peut être définie ainsi : T = partie-droite Où T est une construction ; qui ne peut être définit que par une production au plus. Si cette production existe, la construction est non terminale. Dans le cas échéant, c est une construction terminale. Généralement, la syntaxe abstraite des langages de programmation et son lien avec la syntaxe concrète sont donnés par une grammaire hors-contexte en forme de Backus-Naur. I.3.2. Les principales méthodes de description de la sémantique Tout langage de programmation peut être caractérisé par des propriétés syntaxiques et sémantiques. En effet, la définition d'un langage débute par une syntaxe abstraite. Cette syntaxe abstraite exprime toutes les phrases du langage sous la forme d'une séquence de caractères analysable selon des méthodes d'analyse lexicale et syntaxique connues. La sémantique vise, pour l'essentiel, à définir comment attribuer une signification à chacune des phrases du programme, en se basant sur la syntaxe abstraite du langage. Une sémantique formelle emploie comme éléments de signification des objets mathématiques formellement manipulables. Le choix des objets mathématiques utilisés distingue les nombreuses méthodes de description de la sémantique (opérationnelle, dénotationnelle, axiomatique, etc.) qui sont équivalentes ou sont approximatives les unes des autres. Ces méthodes forment une hiérarchie organisée selon la précision de la description des comportements des programmes à l exécution. 30

41 Chapitre I : État de l art I Sémantique opérationnelle La sémantique opérationnelle est l'une des approches qui servent à donner une signification aux programmes informatiques d'une manière rigoureuse, mathématiquement parlant. Contrairement à une sémantique qui décrit seulement ce qu'un programme fait, le but de la sémantique opérationnelle est de décrire comment un calcul est exécuté. Dans l approche opérationnelle informelle, on définit une machine abstraite qui est typiquement un ensemble d états ou configurations et une relation de transition entre les états. Sur cette machine, un programme avec ses entrées assume le rôle de l état initial et une suite de transitions jusqu `a un état final qui représente le résultat (si le programme termine). Cette suite est la signification du programme. Dans le cas d'un programme fonctionnel, l'état final d'une suite qui termine donne la valeur de retour du programme. Généralement, il peut y avoir plusieurs suites de calculs et plusieurs valeurs de retour pour un seul programme nondéterministe. La définition d une sémantique opérationnelle au travers d'un système de transition se fait fréquemment en donnant une définition inductive de l'ensemble des transitions possibles. Généralement, cela prend la forme d'un ensemble de règles d'inférence définissant les transitions valides du système. L idée de la sémantique opérationnelle est d exprimer la signification d'un langage de programmation par une collection de résultats obtenus en exécutant des programmes sur un interpréteur particulier ou comme programme traduit dans un langage d'assemblage par le compilateur du langage[11]. Cette approche de signification est la sémantique opérationnelle concrète. La sémantique de translation d'un compilateur peut être considérée comme définition d'un langage de programmation. Le diagramme ci-dessous montre la structure d'un système de translation pour un langage de programmation (voir Figure 6). 31

42 Chapitre I : État de l art Figure 6 : Système de compilation d un langage de programmation [10] L'approche de compilation présente deux inconvénients principaux si elle est considérée comme outil formel de spécification : 1) Le langage source du traducteur est défini aussi bien que son langage cible. l'exactitude et la perfection des spécifications se fondent sur un arrangement complet du langage cible. 2) Un traducteur peut soigneusement décrire la relation entre un programme source et sa traduction dans le langage cible, mais il peut en même temps fournir peu de perspicacité dans la nature essentielle du langage source. Généralement, la sémantique opérationnelle concrète se rapporte à une approche d'interprète dans laquelle un programme en langage source est simulé directement. Une définition interprétative d'un langage de programmation est généralement moins complexe qu une méthode de translation. La figure 7 montre la structure de base d'un système d'interprétation. Figure 7 : Interpréteur [10] Définir la signification d'un langage de programmation en termes de vrai interprète a également des imperfections comme mécanisme de spécifications : 32

43 Chapitre I : État de l art 1) Pour des langues complexes, il est difficile d écrire des interprètes corrects (aussi bien que des compilateurs). 2) Des interprètes sont écrits pour fournir les outils de mise au point de programmes pratiques, et ils ne fournissent pas la précision mathématique requise dans une définition formelle. La sémantique formelle exige une meilleure approche, en utilisant une machine abstraite définie avec précision dans un langage mathématique ou une logique formelle sans avoir des limitations sur la mémoire, la taille de mot et la précision de l'arithmétique. La sémantique opérationnelle peut être reliée à la sémantique dénotationnelle à travers le concept d'abstraction. I Sémantique axiomatique(ou predicate transformer) La méthode axiomatique exprime la sémantique d un langage de programmation en associant au langage une théorie mathématique permettant de spécifier et prouver les propriétés des programmes écrits dans ce langage. Tandis que la méthode denotationnelle donne un modèle du langage. Ce modèle est plus une implémentation abstraite qu une pure spécification. La description axiomatique d un langage est une théorie de ce langage. Une théorie sur un ensemble particulier d objets est un ensemble de règles qui permettent d exprimer des affirmations sur ces objets et de déterminer si celles-ci sont vraies ou fausses. Elle peut être considérée comme un métalangage (langage formel), défini par des règles syntaxiques et sémantiques. L ensemble des règles syntaxiques du métalangage, ou grammaire, définit les affirmations significatives de la théorie, appelées formules bien formées. Les règles sémantiques de la théorie (axiomes et règles d inférence), qui ne s appliquent qu aux formules bien formées, déterminent quelles formules sont des théorèmes et lesquelles n en sont pas. -Assertions 33

44 Chapitre I : État de l art Pour la catégorie la plus répandue des langages de programmation, les propriétés pertinentes des programmes sont commodément exprimées par les assertions. Une assertion est une propriété des objets du programme, qui peut être ou non satisfaite par un état du programme. -Préconditions et postconditions Dans l approche axiomatique, on s intéresse à savoir, étant donné des assertions logiques valides avant l exécution d une instruction, quelles autres assertions vont être valides après (la sémantique d un programme est ainsi un transformateur de prédicats, d òu la terminologie). Deux sortes d assertions doivent être considérées : - Préconditions, supposées satisfaites avant l exécution du fragment. - Postconditions, garanties satisfaites après l exécution du fragment. Une spécification pré-post est comparable à un contrat établi entre l environnement et le programme. La précondition impose une obligation à l environnement et la postcondition impose une obligation au programme. Si l environnement ne respect pas ses engagements, le programme lui aussi est libre de faire ce qu il veut. Mais si précondition est satisfaite et le programme ne garantit pas la postcondition, alors le programme est incorrect. Hoare introduit la notation : {P}Instr{Q} Pour indiquer que P est vrai juste avant d exécuter Instr, alors Q est vrai après son exécution. -Correction partielle et totale Un programme est partiellement correct par rapport à une condition préalable et à une postcondition. Si le programme commence par les valeurs qui rendent la condition préalable vraie, la postcondition devient vraie dans le cas ou le programme s arrête. Si on peut également montrer que le programme se termine une fois commencé par des valeurs satisfaisant la condition préalable, le programme est appelé (totalement) correct. Correction partielle = (condition préalable et arrêt Postcondition) Correction totale = (correction partielle et arrêt). 34

45 Chapitre I : État de l art La sémantique dénotationnelle (approche adoptée dans notre thèse) sera développée en détail dans la section suivante. I.3.3. Sémantique dénotationnelle La sémantique dénotationnelle doit son nom au fait qu'elle voit les phrases de la syntaxe comme «dénotant» l'objet mathématique explicitant leur signification. Elle considère les programmes et les objets qu'ils manipulent comme des réalisations symboliques des objets mathématiques abstraits. Par exemple, les chaînes des chiffres réalisent des nombres, et les sous-programmes de fonction réalisent des fonctions mathématiques. L'idée de la sémantique dénotationnelle est d'associer un objet mathématique approprié, tel qu'un nombre entier, une valeur de vérité, un tuplet, ou une fonction, à chaque expression du langage. On dit que l'expression dénote l'objet mathématique, et l'objet s'appelle : dénotation de l'expression. Pour cette raison, la sémantique dénotationnelle est à l'origine appelée la sémantique mathématique. Cette discipline a été introduite par Christopher Strachey et son groupe de recherche de programmation à Oxford au milieu des années 60 ; Dana Scott a fourni les bases mathématiques en 1969 [16]. Bien qu au début, elle a été prévue comme mécanisme pour l'analyse des langages de programmation, la sémantique dénotationnelle est devenue un outil puissant pour la conception et l'implémentation des langages informatiques. I La composition Le principe de composition a une longue histoire dans les mathématiques et les spécifications des langages. Dans son livre [14] sur la sémantique des langages de programmation, Tennent suggère trois raisons pour l'usage des définitions compositionnelles : 1) Dans une définition dénotationnelle, chaque expression d'un langage donne une signification qui décrit sa contribution à la signification d'un programme complet qui la contient. Ainsi, la signification de chaque expression est formulée en fonction des dénotations de ses sous expressions immédiates. Par conséquent, lorsque deux expressions ont la même dénotation, l une peut remplacer l'autre sans changer la signification du programme. Ainsi, une sémantique dénotationnelle soutient la substitution des expressions sémantiquement équivalentes. 2) La structure syntaxique des spécifications BNF d un langage, permet de vérifier par induction structurelle les propriétés de ses constructions. 35

46 Chapitre I : État de l art 3) La Composition prête une certaine élégance aux définitions dénotationnelle, puisque les équations sémantiques sont structurées par la syntaxe du langage. D'ailleurs, cette structure permet aux différentes constructions du langage d'être séparément analysées et évaluées. I Sémantique statique et dynamique La méthode dénotationnelle exprime la signification d un langage de programmation en associant à chaque construction T deux fonctions : - V T : T B - M T : T D T La fonction de validité V T définit la sémantique statique de la construction ; les fonctions de validité sont aussi appelées «contraintes». La fonction de signification M T donne la sémantique dynamique de la construction, ou dénotation. Les constructions T sont aussi nommées domaines syntaxiques, tandis que les dénotations D T sont appelées domaines sémantiques. Les fonctions V et M jouent différents rôles : - La fonction de validité (prédicats) complète les descriptions syntaxiques par des contraintes contextuelles, tels que les contraintes de typages, que l on ne peut pas prendre en charge dans les descriptions syntaxiques. - Les fonctions M décrivent l effet de chaque construction en spécifiant sa dénotation mathématique. L utilisation des deux fonctions différentes V et M englobe les sémantiques statique et dynamique en un seul mécanisme. La définition des fonctions de signification suppose que l argument de la fonction est valide du point de vue de la sémantique statique. Puisque les fonctions M ne s appliquent qu aux arguments statiques valides, elles sont spécifiées comme des fonctions partielles. 36

47 Chapitre I : État de l art I L approche dénotationnelle La sémantique dénotationnelle repose sur deux principes fondamentaux : la compositionalité et le calcul de points fixes. La compositionalité est la propriété d'une sémantique dont la dénotation d'une construction du langage est définie en termes de dénotations de ses sousexpressions : la signification d'une phrase ne dépend que de la signification de ses sousphrases. Plus techniquement, on pourrait dire que les objets mathématiques représentant la signification d'une phrase ne sont que le résultat de la composition des objets mathématiques représentant la signification de ses sous-phrases. Cette propriété importante permet de vérifier les propriétés sur les programmes par induction structurelle sur ses phrases, en utilisant des règles de déduction définies sur les différents types de phrases de la syntaxe abstraite. Dans le cas de la sémantique dénotationnelle, on cherchera à donner aux structures «autoréférentielles», comme les itérations, la récursivité ou encore le «self» des langages à objets, une signification sous la forme d'un objet mathématique. Cependant la contrainte de compositionalité a amené au choix d'obtenir la signification de ces structures autoréférentielles par un calcul de point fixe. Il y a principalement trois éléments de base pour une présentation structurée de la sémantique dénotationnelle : - La syntaxe abstraite, qui définit la structure de toutes les phrases sur lesquelles la sémantique doit travailler ; - L algèbre sémantique, qui définit l'ensemble des valeurs des objets mathématiques qui vont servir de dénotations pour les phrases de la syntaxe abstraite ; - Les fonctions sémantiques, qui vont définir, par des équations, quelle valeur du domaine sémantique dénote chacune des phrases abstraite d'un programme. I Syntaxe abstraite La syntaxe abstraite est un concept relativement bien connu pour les informaticiens. Une fois analysé, le programme peut révéler sa structure sous la forme d'une arborescence des phrases où n'apparaissent que les éléments porteurs de sens. Réduite à la définition d'arborescences, la syntaxe abstraite utilise généralement des grammaires. Dans ces grammaires, les nonterminaux définissent les types de phrases, généralement appelés domaines syntaxiques en référence aux domaines sémantiques, et correspondent à des types de nœuds pouvant 37

48 Chapitre I : État de l art apparaître dans l'arbre de syntaxe abstraite. Un type de nœud dans un arbre de syntaxe abstraite a généralement plusieurs formes. Dans un langage de programmation fonctionnelle, un type de nœud serait défini comme un type somme. Le domaine syntaxique Les catégories syntaxiques ou les domaines syntaxiques sont des collections d'objets syntaxiques qui peuvent se produire dans des expressions définies par la syntaxe du langage [11]. Par exemple : Chiffre, commande et expression. Généralement, chaque domaine syntaxique est associé à une méta-variable spéciale. A titre d exemple : - C : Commande ou instruction - E : Expression - N : Chiffre - I : Identificateur Les règles de production abstraites Elles décrivent la manière dont les objets des catégories syntaxiques peuvent être combinés selon la définition de BNF du langage. Elles fournissent les modèles possibles que les arbres de la syntaxe abstraite peuvent prendre. Ces règles de production abstraite peuvent être définies en utilisant les catégories syntaxiques ou en utilisant les méta-variables comme mécanisme d abréviation [11]. Exemple : Commande := while Expression do Commande+ E ::= N I E O E E Ces règles sont des productions abstraites qui présentent simplement les formes possibles de constructions syntaxiques qui ont été vérifiées comme correctes par d autres moyens. I L algèbre sémantique L'algèbre sémantique introduit tous les types d'objets mathématiques qui vont exprimer la signification des programmes. Ces valeurs font partie de structures mathématiques aptes à supporter le calcul de points fixes. Le plus souvent, ce sont des domaines au sens de Scott, c'est-à-dire des ensembles partiellement ordonnés [14]. 38

49 Chapitre I : État de l art Les domaines sémantiques sont des «ensembles structurés» d'objets mathématiques d'une forme particulière ayant le treillis comme structure. Ces objets servent de dénotations pour les phrases de la syntaxe abstraite. Ces domaines possèdent un élément spécial appelé bottom, qui dénote un élément non défini ou une absence d'information. Un calcul non terminé produit normalement le en tant que résultat. Par exemple : Booléen = {vrai, faux} est l'ensemble de valeurs de vérité. Entier = {, - 2, - 1, 0, 1, 2, 3, 4, } est l'ensemble de nombres entiers. Mémoire = (variable Entier) se compose des ensembles de relations (fonctions liant les noms variables aux valeurs). Nous employons la notation A B pour dénoter l'ensemble de fonctions avec le domaine A et codomaine B. I La relation entre la syntaxe et la sémantique Les fonctions sémantiques tracent les objets du monde syntaxique dans des objets du monde sémantique. Elles définissent, par des équations, quelle valeur du domaine sémantique dénote chacune des phrases abstraites d'un programme. Les équations sémantiques sont employées pour indiquer comment les fonctions agissent sur chaque modèle de la définition syntaxique des expressions du langage. Pour chaque domaine syntaxique, une fonction de signification différente est définie par une suite d'équations sémantiques. Il y a une équation pour chacune des alternatives apparaissant dans la production (composite) de la syntaxe abstraite. Pour ce domaine syntaxique, les fonctions de signification peuvent comporter un certain nombre d'arguments : environnement, mémoire, etc. Les équations définissent habituellement des fonctions ; la notation la plus utilisée pour définir ces fonctions est le λ-calcul car cette notation possède les propriétés mathématiques nécessaires pour définir les valeurs des domaines sémantiques de fonctions [10, 15,16]. I Exemple : Application sur un langage de spécification QML Nous présentons ci-dessous la sémantique dénotationnelle d'une partie du langage QML (QoS Modeling Language) de spécification de la qualité de service des composants logiciels, 39

50 Chapitre I : État de l art qui a été réalisé par Malenfant [12-13]. Un programme QML est essentiellement une série de déclarations de types de contrats, de contrats et de profils. Un type de contrats est constitué d'une séquence de déclarations de dimensions, lesquelles sont formées d'un identificateur de dimension et d'un type de dimension (i.e. une sorte de dimension suivie ou non d'une unité de mesure). QML prévoit cinq sortes de dimensions. Les énumérations, énumérations avec ordre, ensembles et ensembles avec ordre permettent de définir des niveaux de qualité de service à l'aide d'identificateurs (i.e. modélisation qualitative de la qualité de service). Ces identificateurs définissent des valeurs de qualité de service, éventuellement comparables par la relation d'ordre. Dans les dimensions ensemblistes, des ensembles de valeurs sont admis entre lesquels une relation d'ordre est établie (inclusion si les valeurs individuelles ne sont pas comparables, inclusion avec majorant sinon). La dernière sorte de dimension est la dimension numérique, servant bien entendu à la modélisation quantitative de la qualité de service. Une information importante donnée par une déclaration de dimension est la sémantique ou signification de la notion de valeur préférable ou meilleure valeur (increasing ou decreasing). I La syntaxe abstraite de QML La Figure 8 présente la syntaxe abstraite partielle du langage QML. Un programme p est une séquence de déclarations de types de contrats et de contrats, suivie d'une expression de test t. Cette expression de test, ajoutée pour la mise au point, vérifie si une valeur dv respecte la contrainte posée sur une dimension d'un contrat donné. Une déclaration de type de contrat ctd associe un identificateur i à un type de contrat ct, lequel est constitué d'une séquence de dimensions. Une dimension dim déclare une sorte de dimension ds qualifiée ou non par une unité de mesure. Les cinq sortes de dimension se retrouvent, avec une sémantique de relation rs s'il y a relation d'ordre, une séquence d'identificateurs jouant le rôle de valeurs, et une relation d'ordre o le cas échéant. Une relation d'ordre est constituée de relation rel entre valeurs deux à deux. Une déclaration de contrat associe un identificateur à une expression de contrat ce. L'expression de contrat peut être simple, et définir un nouveau contrat d'identificateur i et de contraintes co+ ou encore le rafinement d'un contrat existant d'identificateur i auquel sont ajoutées les contraintes co+. Une contrainte pose l'opérateur de contrainte cp et la valeur cible dv sur une dimension d'identificateur i. Les littéraux lit sont des identificateurs, des séquences d'identificateurs (ensembles de valeurs), et des réels pour les dimensions numériques. 40

51 Chapitre I : État de l art Figure 8 : Domaines syntaxiques du langage QML [12] I Algèbre sémantique de QML Les domaines sémantiques de QML sont présentés à la Figure 9. Le domaine caractéristique V des valeurs exprimables dans le langage est constitué d'identificateurs (dimensions énumération avec ou sans ordre), de nombres ou encore d'une liste d'identificateurs (dimensions ensembliste avec ou sans relation d'ordre). Une valeur de dimension est définie par le domaine DimensionValue qui est le produit d'une valeur exprimable et d'une unité de mesure. Les unités de mesure sont définies par une valeur de domaine fini indiquant l'absence d'unité (none), un pourcentage (percent) ou, si l'unité est nommée, une liste d'identificateurs représente les noms d'unités individuelles (la liste <m, sec> représentant l'unité composite m/sec) [12]. 41

52 Chapitre I : État de l art Un type de contrat ContractType est un environnement liant des identificateurs de dimension à des types de dimension DimensionType. Un type de dimension est représenté par une fonction qui accepte un opérateur de contrainte (ConstraintOperator) et qui retourne une fonction prenant une valeur cible du domaine DimensionValue et retournant une fonction du domaine ContractDimension. Cette fonction va réaliser le test sur les valeurs mesurées selon cette dimension du contrat. On lui passe une valeur mesurée du domaine DimensionValue et elle retourne vrai ou faux selon que cette valeur respecte la contrainte ou non. Pour ce faire, elle vérifie la conformité des unités de mesure, puis elle appelle une autre fonction du domaine Dimension-Test qu elle accepte une valeur exprimable V (sans unité) et retourne vrai si cette valeur respecte la contrainte sans égard à l'unité déjà vérifiée. Figure 9 : Domaines sémantiques du langage QML [12] I Fonctions sémantiques pour QML. La Figure 10 présente les principales fonctions de valuation pour QML, c'est-à-dire celles qui concernent les domaines syntaxiques assurant les grands aiguillages dans le programme : programme, déclarations, déclarations de types de contrats et de contrats, etc. La dénotation associée à un programme par la fonction de valuation P est la paire (, τ) où est l'environnement obtenu par l'évaluation des déclarations et τ est le résultat de l'évaluation de 42

53 Chapitre I : État de l art l'expression de test. Les séquences de déclarations mènent à la construction d'un environnement par la fonction DE*, en appliquant à chaque déclaration la fonction DE. Cette dernière appelle la fonction CT D s'il s'agit d'une déclaration de type de contrat et C D s'il s'agit plutôt d'une déclaration de contrat. La fonction T illustre l'utilisation des contrats. Avec l'identificateur de contrat i, on récupère le contrat dans l'environnement produit par DE*, puis avec l'identificateur de dimension i1, on récupère la fonction de vérification associée à la dimension par le contrat (vu comme un environnement), qui est appliquée à la valeur mesurée dv [13]. Figure 10 : Fonctions de valuation pour les domaines syntaxiques de QML[13] 43

54 Chapitre I : État de l art I.3.4. La cohérence des définitions sémantiques L approche dénotationnelle est une interprétation des constructions des langages en termes de fonctions mathématiques ; tandis que la sémantique axiomatique est un ensemble de règles servant à démontrer des théorèmes. Comme toute théorie, on peut l étudier et l appliquer indépendamment de toute interprétation particulière. L approche axiomatique est plus abstraite que son homologue dénotationnelle [17]. En conséquence, la relation entre ces deux techniques est non symétrique mais elle est cohérente et complémentaire : les règles de la sémantique axiomatique sont valides sous l interprétation dénotationnelle, cela revient à déduire que l interprétation dénotationnelle est un modèle de la théorie axiomatique. Un modèle est une interprétation qui associe une propriété vraie à chaque théorème. Les seules théories intéressantes sont celles qui possèdent au moins un modèle. Par rapport à la sémantique opérationnelle, qui donne l interprétation d un programme sur une machine abstraite, la sémantique dénotationnelle est plus abstraite (pas d interprétation pas à pas). La Figure 11 suivante de ( Wolfgang Schreiner) résume la relation de complémentarité entre les diverses sémantiques et leurs points d'action dans la chaîne de conception/implémentation des langages de programmation. Figure 11 : Relation entre les diverses sémantiques [72] 44

55 Chapitre I : État de l art I.4. Méta-modélisation et transformation de modèles La modélisation est une technique de spécification de systèmes utilisant un certain nombre de concepts prédéfinis. 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. La Model Driven Architecture (MDA, architecture dirigée par les modèles) est apparue après plusieurs années d existence de standards de modélisation et de méta-modélisation comme UML (Unified Modeling Language) ou le MOF (Meta Object Facility). La MDA propose une approche qui tend à organiser les modèles définissant un système. Les techniques utilisées sont principalement des techniques de modélisation et de transformation de modèles. 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 dont : - la génération de modèles de plus bas niveau et éventuellement du code à partir de modèles de plus haut niveau ; - la synchronisation de modèles ayant ou pas le même niveau d abstraction ; - la rétro-ingénierie de modèles de haut niveau à partir du code ou de modèles de plus bas niveau d abstraction. Au regard de l importance que revêtent les transformations de modèles, un intérêt particulier a été initié par l OMG pour un effort de standardisation. I.4.1. Techniques de méta-modélisation I Modèles et méta-modèles En vue de préciser les notions fondamentales de l approche méta-modélisation, nous commençons tout d abord par définir les notions de modèle et de méta-modèle. Nous retrouvons, dans la littérature, plusieurs définitions du mot modèle, nous donnons ici quelques unes des définitions les plus pertinentes : 45

56 Chapitre I : État de l art Définition 1. Un modèle est une abstraction de la réalité dans le sens où il permet de représenter certains aspects de cette réalité dans un contexte précis. Ceci permet l utilisation d une vision du monde plus simplifiée, en évitant la complexité et l irréversibilité des éléments du monde réel. La modélisation, au sens large, est donc l utilisation d une chose à la place d une autre pour simplifier et faire abstraction de certaines préoccupations (Rothenberg 1989). Définition 2. Un modèle est une représentation utile d un sujet ; il représente une abstraction (plus ou moins formelle) de la réalité (ou de l univers de discours) exprimé dans un formalisme (ou langage) défini par des concepts de modélisation adaptés au besoin de l utilisateur. Ces concepts de modélisation forment les éléments d un langage de modélisation défini par une syntaxe et une sémantique particulière (Vernadat 1996). La deuxième définition s avère la mieux appropriée pour le travail que nous exposons dans cette thèse, nous la considérons donc comme référence. Par ailleurs, dans le domaine de la modélisation la notion de méta-modèle est elle aussi souvent évoquée. Ci-dessous, quelques définitions du méta-modèle : Définition 3. Un méta-modèle est un modèle définissant le langage utilisé pour exprimer un modèle (Bézivin 2004). Définition 4. Un méta-modèle est le modèle d un langage de modélisation (Favre 2004). Définition 5. Un méta-modèle est le modèle d un modèle (Seidewitz 2003) La définition de Seidewitz (cf. Définition 5) paraît être la plus proche de notre compréhension du terme «méta-modèle» ainsi que de l utilisation que nous en ferons. I Le besoin de méta-modélisation Une méta-modélisation est nécessaire afin de comprendre le lien existant entre différents langages. La méta-modélisation permet la définition de la syntaxe dite «abstraite» d un langage. Le produit de l activité de méta-modélisation est habituellement appelé métamodèle. Les méta-modèles doivent être définis en utilisant une technique de méta- 46

57 Chapitre I : État de l art modélisation (c est à dire des langages pour créer des méta-modèles). Des standards telles que XML (DTDs ou Schémas), MOF peuvent être utilisées. Ces techniques sont indépendantes du contenu (génériques et applicables pour la définition de n importe quel langage). D autres techniques de méta-modélisation sont dépendantes du contenu (et parfois spécifiques à un domaine). Par exemple, XMI est un format d échange en XML basé sur le méta-modèle d UML (UML, 2003) conçu pour permettre l échange de modèles UML. Actuellement, plusieurs langages et outils de méta-modélisation existent, mais aucun ne cible spécifiquement le domaine de la définition des langages de points de vue ODP. La raison en est que ces langages de méta-modélisation ont la plupart du temps été développés pour concevoir et implémenter des Systèmes d Informations et des Bases de Connaissance. Un méta-modèle pourrait aussi être utilisé pour définir tout ou une partie de la sémantique du langage [18]. I Une architecture de méta-modélisation à quatre niveaux Cette architecture formelle se décompose en quatre niveaux représentés sur la figure suivante : Figure 12 : L architecture à quatre niveaux 47

58 Chapitre I : État de l art Le niveau le plus bas M0 représente les différents sujets de modélisation aussi appelés «univers du discours ou monde réel». Le niveau M1 contient les différents modèles de chaque univers de discours. Le modèle d un système est sa description ou sa spécification. Un modèle est souvent présenté comme une combinaison de dessins et de textes. Le texte peut être dans un langage de modélisation spécifique ou bien en langage naturel. Les modèles du niveau M1 appartiennent à différents domaines d intérêt relatifs aux univers du discours représentés par les modèles. Il est possible qu un domaine d intérêt recouvre plusieurs univers du discours. Le niveau M2 représente les meta-modèles spécifiques à chaque domaine: un meta-modèle pour chaque domaine d intérêt pertinent pour les modèles de niveau M1. Finalement, le niveau M3 présente le meta-meta-modèle et doit être conçu pour permettre la définition de tous les concepts nécessaires pour la modélisation de meta-modèles et pour leur unification sous un cadre commun. Un meta-meta-modèle est indépendant du domaine, il contient des métacaractéristiques pour des meta-modèles spécifiques. Cette architecture est donc utilisée par le MOF (Meta Object Facility), UML. Un problème récurrent en méta-modélisation consiste à identifier précisément le nombre et le contenu des différents niveaux d'abstraction. Les niveaux M3, M2 et M1 sont généralement bien acceptés. Le niveau M0 pourra quant à lui ne pas être représenté lorsque l'on ne s'intéresse qu'aux modèles et méta-modèles. Enfin, pour certains, il existe ensuite un nombre infini de niveaux permettant de représenter les informations. Mais il faut garder à l'esprit que le nombre de ces niveaux dépend directement de la relation d'instanciation qui les traverse et qui lie les entités d'un niveau aux entités du niveau directement supérieur [19]. I Le MOF : Un langage de définition de méta-modèles Un langage de méta-modélisation appelé MOF et issu du RFP Meta Object Facility a alors été standardisé par l'omg en novembre Le MOF a donc été défini dans le but de formaliser les langages de modélisation. Il est actuellement utilisé pour sa propre définition (le MOF est en effet réflexif), mais il est également utilisé pour définir le méta-modèle d UML. Le principal atout du MOF est son ouverture. Son but est de proposer un framework qui pourra supporter tout type de méta-modèles et qui permettra, au besoin, d enrichir ces méta-modèles avec de nouveaux concepts. Il s inscrit dans une architecture de métamodélisation à quatre niveaux. Le point clé d une telle architecture est que son méta-métamodèle va permettre la représentation, via un formalisme commun, de modèles et de métamodèles. 48

59 Chapitre I : État de l art Le modèle MOF correspond au méta-méta-modèle de l architecture à quatre niveaux déjà représentée (voir Figure 13). C est un langage de modélisation à "objets". Il est utilisé pour définir la structure et la sémantique de méta-modèles, qu ils soient généralistes ou liés à un domaine plus spécifique. Il est particulièrement bien adapté pour définir à la fois des métamodèles des formalismes à "objets", des méta-modèles plus traditionnels (relationnels, entitéassociation) ou tout autre méta-modèle encore plus élémentaire. La notation graphique UML semble être bien adaptée pour représenter les méta-modèles MOF. Cependant, les associations et les classes représentées via cette notation ne sont pas des associations et des classes UML, mais des associations et des classes MOF. Le MOF peut se représenter récursivement. Le MOF, sans être vraiment minimal, peut être présenté entièrement sur un modèle (c. f. Figure 13). Figure 13 : Le MOF version

60 Chapitre I : État de l art I.4.2. Transformation des modèles La complexité croissante des applications informatiques, leur nécessaire évolutivité et leur couplage de plus en plus fort sur les organisations dans lesquelles ils opèrent ont provoqué une réaction importante et rapide. Pour résoudre ce problème actuel de construction et d évolution de systèmes d information auxquels font face les industriels, l OMG (Object Management Group) a défini sa nouvelle orientation : MDA (Model Driven Architecure). Le principe de base du MDA est l élaboration de modèles indépendants des plates formes (PIM) et la transformation de ceux-ci en modèles dépendants des plates formes (PSM). Les techniques employées sont donc principalement des techniques de modélisation et des techniques de transformation de modèles. L OMG a d ailleurs déjà commencé à définir des standards dans ce domaine (ex : UML, XMI, MOF, profils EJB et CORBA ). Aujourd hui, la nouvelle stratégie MDA se démarque très nettement de l ancienne architecture OMA (Oject Management Architecure), en se positionnant clairement sur un niveau supérieur d abstraction et en se concentrant non plus sur les approches à objet mais sur les approches à modèles. Le but est de se concentrer sur l élaboration de modèles de plus haut niveau d abstraction et de favoriser les approches transformationnelles paramétriques vers les plates formes techniques. Ceci signifie que l on pourra, par exemple, définir des modèles métier totalement indépendants des plates formes techniques et générer du code soit pour corba, soit pour java/ejb, soit pour XML, soit encore pour des compositions de ces différentes plates formes. L OMG a proposé une formalisation et une standardisation des techniques de transformation de modèles pour garantir la compatibilité entre les différents outils. Dans cette optique, l OMG fournit le langage M0F23 (langage de méta-modélisation) comme langage d échange de constructions utilisées par les modèles. L intérêt de ce langage est de faire inter-opérer des méta-modèles différents, ce qui permet de manipuler les modèles à l aide d opérations génériques sans connaissance du domaine. Dans ce contexte 1 OMG propose de définir la transformation de modèles par des projections entre méta-modèles représentant des concepts de domaines variés. Cependant, l OMG ne fournit pas avec le MOF de mode d emploi. Il revient alors à chaque utilisateur de définir sa propre organisation de mise en œuvre du MOF en fonction de ses besoins (Marvie, 2002). Notamment, Lemesle introduit la transformation de modèles en établissant des règles de transformations entre méta-modèles. La Figure 14 [19], ci-dessous, présente le processus de transformation basée sur la projection de méta- 50

61 Chapitre I : État de l art modèles représentant le modèle source et le modèle cible. Cette transformation est basée sur des règles de correspondances structurelles entre méta-modèle source et méta-modèle cible. Figure 14 : Transformation de méta-modèle [19] Les règles sont écrites dans un langage de type condition/conclusion. Une condition peut aussi bien contenir des assertions sur le modèle source que sur le modèle cible. La conclusion permet de créer et de lier des éléments dans le modèle cible. De plus, il est possible de créer des relations temporaires de coréférence entre des éléments du modèle source et du modèle cible. Ces relations peuvent également être réutilisées dans les conditions. On appelle mapping, l ensemble des règles de transformation de modèles permettant de traduire les instances d un meta-modèle source en des instances d un méta-modèle cible (Levendovszky, et al., 2002). I.4.3. Les standards pour la manipulation des modèles Afin de décrire la manière de faire passer les modèles du stade contemplatifs au stade productif, nous allons citer quelques standards permettant la manipulation et la transformation des modèles par des outils informatiques. I Le MOF Nous avons vu dans le paragraphe I que le MOF était le standard de l OMG qui fournit un référentiel de modèle (un méta modèle) qui peut être utilisé pour la spécification et l élaboration des modèles, tout en gardant une consistance et une cohérence dans les 51

62 Chapitre I : État de l art manipulations de ceux-ci. Il spécifie aussi des mécanismes d interopérabilité entre ces métamodèles. Le MOF définit pour chaque méta-modèle : - Un modèle abstrait d objets MOF génériques et leurs associations ; - Un ensemble de règles sur le cycle de vie et la composition des éléments d un métamodèle MOF ; - Un ensemble de règles pour exprimer un méta-modèle MOF à l aide d interface IDL* (Interface Definition Language) ; - Une hiérarchie d interfaces réflexives permettant de découvrir et de manipuler des modèles basés sur des méta-modèles MOF. I Les langages UML et OCL Le langage UML (Unified Modeling Language) ou langage unifié de modélisation est un langage standardisé pour visualiser, spécifier et documenter les systèmes à base de logiciels. UML joue un rôle central dans l'approche MDA comme langage de modélisation de haut niveau. Associé à un langage formel de transformation et de contraintes comme OCL, il doit permettre d'automatiser entièrement la génération du code. La version 2 de ce langage intègre un ensemble plus complet et plus précis de concepts pour spécifier le comportement des objets au sein des logiciels. Le langage UML permet la modélisation de systèmes indépendamment de toute démarche ou de plateforme. C est pourquoi, dans la cadre du MDA, UML peut-être utilisé pour décrire des plates-formes (PDM), des modèles (PIM) ou la plupart des systèmes logiciels (PSM). L OMG veut intégrer l UML au sein même des applications de développement afin d éviter que le passage au code marque la fin de l'utilisation des modèles UML. Ce passage au code exécutable devra se faire de façon automatique, solutionnant ainsi un bon nombre de problèmes de maintenabilité et d évolutivité des logiciels. Ce langage peut être étendu par l intermédiaire de «profiles». Un profil permet de spécialiser UML à un domaine particulier en ajoutant de nouveaux types d éléments au langage ou en le restreignant. A titre d exemple le profil CORBA permet de représenter à l aide d UML le modèle de composants CORBA. Le langage OCL (Object Constraint Language) est un langage d expression de haut niveau d abstraction parfaitement intégré à UML qui permet de trouver des erreurs beaucoup plus tôt 52

63 Chapitre I : État de l art dans le cycle de vie de l application. Il permet de décrire des contraintes sur des modèles objet. Une contrainte est une restriction sur une ou plusieurs valeurs d un modèle non représentable en UML. Il donne des descriptions précises et non ambiguës du comportement du logiciel en complétant les diagrammes. Il définit aussi des pré-conditions, des postconditions ou des invariants pour une opération. Il définit aussi les expressions de navigation ou des expressions booléennes. OCL est interprété par des outils et par conséquent le passage vers différentes plates-formes technologiques est réalisable de façon semi-automatique ou automatique [22, 23]. I Les profils UML Un profil décrit une extension d UML spécifique à une technologie d implémentation. Il permet d adapter le langage UML à un domaine qu il ne pouvait couvrir correctement. Chaque profil est défini par un ensemble de stéréotypes qui permettent l ajout de nouveaux éléments au méta-modèle, d étiquettes (tags) agissant comme des attributs des méta-classes de UML pour attacher des informations à ses instances et de contraintes qui permettent l ajout ou la modification de règles comme la condition d héritage. Le profil est aussi composé d un ensemble de règles de présentation, de conception ou de transformation. Ce sont ces règles qui rendent le profil opérationnel [22, 24, 25]. Dans l approche MDA, les profils sont utilisés pour la génération de PIM ou de PSM mais aussi pour transformer des PIMs au PSMs. L OMG incite à créer des profils et en fournit plusieurs qui peuvent être utilisés dans le contexte du MDA en particulier dans les transformations : - Le profil CORBA, pour exprimer la sémantique de CORBA IDL en utilisant une notation UML et pour supporter CORBA IDL dans des outils UML. - Le profil Test permet la spécification de tests pour les aspects structurels (statiques) ainsi que pour les aspects comportementaux (dynamiques) des modèles UML. - Le profil QoS (Quality of Service) représente la qualité de service et de tolérance aux erreurs. - Le profil EDOC (Enterprise Distributed Object Computing) vise à faciliter les développements de modèles d entreprises, de systèmes ou d organisations. - Le profil CORBA Component Model (CCM) étend le profil CORBA et permet les transformations de PIM à PSM ou de PSM à PSM. 53

64 Chapitre I : État de l art - Le profil modélisation temps réel (Schedulability Performance and Time) pour modéliser des applications en temps réels. I Le format d échange normalisé : XMI XMI (XML Metadata Interchange) est le langage d échange entre le monde des modèles et le monde XML (extensible Markup Language). Ce standard a été créé pour faciliter la sérialisation et les échanges de données, dans le cadre de la modélisation, entre les différents outils compatibles MDA qui interviennent dans le cycle de vie d'une application informatique. XMI se focalise sur les échanges des méta-modèles MOF et des modèles basés sur ces métamodèles sous forme de fichiers XML. Il s'appuie sur les mécanismes de DTD (Document Type Definition) ou de schéma XML pour définir les structurations de balises nécessaires et suffisantes à la représentation des modèles MOF au format XML. Cette représentation facilite les échanges de données (ou méta-données) entre les différents outils ou plates-formes de modélisation. En effet, XMI décrit des règles de création des DTD* (Document Type Definition) et des schémas XML à partir de méta-modèle. Ainsi, il est possible de reconstruire des méta-modèles à partir de document XML. Généralement, les méta-modèles MOF et UML sont décrits par des DTD et les modèles traduits dans des documents XML correspondants à leur DTD. Parmi les avantages de ce standard le regroupement des métadonnées et leurs instances dans un même document ce qui facilite la compréhension des instances grâce à leurs métadonnées. [21,22, 25]. I.5. Conclusion RM-ODP fournit un modèle de référence pour la spécification architecturale. Il est basé sur la séparation des préoccupations des enjeux en utilisant les cinq points de vue ODP : Entreprise, Information, Traitement, Ingénierie, Technique. Ce modèle traite le problème de la répartition en tenant compte de l hétérogénéité des systèmes et des organismes. Cependant, il n existe pas de méthodologie concrète pour guider les architectes. Il est donc nécessaire de définir une méthodologie et des outils associés pour pouvoir mener des spécifications dans le cadre du modèle de référence RM-ODP. Généralement ces méthodes permettent le développement de système avec la notation UML selon une sémantique ODP. Pourtant, cette sémantique est ambigue, et pour l essentiel informelle. Nous proposons une méthodologie définissant la sémantique formelle des langages de points de vue pour pouvoir 54

65 Chapitre I : État de l art construire effectivement des systèmes répartis ouverts et aussi les standards et les applications ODP. Les méthodes d ingénierie ont recours à des opérations complexes d intégration et de transformation de modèles. Le méta-modèle présente une des composantes essentielles de la «garantie sémantique» qui permet de telles opérations sur les modèles. De même il est important de contrôler la «distance sémantique» entre un modèle obtenu par transformation et le méta-modèle de référence des modèles initiaux. Les opérations sur les méta-modèles constituent donc un complément nécessaire aux transformations de modèles. Une idée importante des techniques de transformation dirigées par les méta-modèles est que les transformations entre deux modèles peuvent être décrites en des termes définis au niveau de chacun de leurs méta-modèles. Partant du fait qu un méta-modèle définit une syntaxe abstraite à partir de laquelle on peut décrire la sémantique d un modèle, les règles de transformation qui surgissent de ces techniques sont souvent qualifiées de précises. Cependant, ces règles sont restrictives car elles passent par certains choix de transformation. L utilisation conjointe des langages de spécifications formelles et semi-formelles semble être un domaine prometteur avec pour objectif de profiter des avantages de ces deux types d approches. La définition d une sémantique formelle, écrite en termes mathématiques, a l'avantage de nous faire éviter toute confusion et ambigüité dans une spécification d un système. On distingue généralement deux classes de sémantique : la sémantique opérationnelle, qui manipule des phrases du langage, et la sémantique dénotationnelle, qui associe un objet mathématique à chaque phrase. La sémantique opérationnelle, en général plus facile à définir, est souvent plus proche de l implémentation qu on pourrait faire du langage. Souvent, elle garde un aspect concret, ce qui rend les preuves parfois très complexes. Au contraire, la sémantique dénotationnelle permet de spécifier formellement un système donnant accès à ses différentes propriétés, ce qui rend les preuves beaucoup plus simples puisqu elles sont faites dans un monde mathématique où il est facile de calculer. De ce fait, elle peut être très utile pour vérifier les propriétés d un système par rapport à une autre spécification qui peut être du même système ou d un autre système effectuant des tâches similaires. 55

66 CHAPITRE II : MODELISATION DE LA SEMANTIQUE FORMELLE DES LANGAGES DE POINTS DE VUE ODP EN UML ET OCL II.1. Introduction RM-ODP (Reference Model - Open Distributed Processing) est considéré comme le standard en matière de modélisation et de développement des systèmes d'information complexes et interopérables. Ce modèle repose sur le concept de la séparation de préoccupations proposant ainsi d'aider les architectes à modéliser un système selon cinq points de vue. A chaque point de vue est associé un langage de point de vue utilisé pour spécifier un système. Les concepts de modélisation par objets fournissent une base commune aux différents langages. Ils permettent l'identification des relations entre les différentes spécifications d une part et l'expression des correspondances entre les représentations du système sous les différents points de vue d autre part. Cependant, malgré le souhait original de ses auteurs, RM-ODP n est pas une méthode, mais bien un ensemble de concepts de spécification et de modélisation. Aucune démarche particulière n est imposée. En dépit de sa grande richesse, 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é. Pour développer un système de façon rigoureuse, il est reconnu depuis longtemps que l'utilisation des méthodes formelles est plus que recommandée. Mais ces méthodes sont souvent difficiles à utiliser et éloignées des habitudes industrielles de développement. C'est en partant de ce 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. 56

67 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL Dans ce chapitre nous traitons la nécessité de la notation formelle des langages de point de vue ODP. Bien que ce modèle de référence fournisse des langages abstraits pour les concepts appropriés, il ne prescrit pas des notations particulières à employer dans les différents points de vue. Ces langages définis dans le modèle de référence sont des langages abstraits dans la mesure où ils définissent quels concepts devraient être employés, mais pas comment devraient-ils être représentés. Il est important de noter que RM-ODP utilise le terme langage dans le sens large : «un ensemble de termes et des règles pour la construction des relations entre les termes ;». Ce manque de notations précises pour exprimer les différents modèles impliqués dans les spécifications de multiples points de vue d'un système, est commun pour la plupart des approches architecturales d'entreprise, y compris le cadre de Zachman, le modèle «4+1», ou le RM-ODP. 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. Le chapitre est organisé de la façon suivante : La section 2 décrit les travaux similaires. Dans la section 3 nous présentons les motivations qui nous ont amené au choix de l approche métamodélisation et dénotationnelle dans notre démarche de définition de la sémantique des langages de point de vue ODP. La section 4 présente le méta-modèle du modèle d'objet et les langages de point de vue entreprise et traitement sujet de nos travaux. La section 5 adopte l approche de la sémantique dénotationnelle pour la spécification précise d un système. Dans cette section, 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 nous établissons la relation entre les modèles et leurs instances en utilisant OCL. La section 6 traite, en utilisant la même approche dénotationnelle, les concepts principaux du langage de traitement. II.2. Travaux connexes Les langages Z [28], SDL [29], LOTOS [30] et Esterel [31] sont utilisées dans la partie sémantique architecturale de RM-ODP [4] pour la spécification des concepts d'odp. Cependant, aucune méthode formelle n'est susceptible de présenter tous les aspects d'un système ODP d une façon complète et non ambiguë. En fait, ces méthodes ont été développées pour l ingénierie des protocoles et la conception du hardware. Les 57

68 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL caractéristiques inhérentes des systèmes ODP impliquent la nécessité d'intégrer différents langages de spécification et différentes méthodes de vérification. Pendant ces dernières années, l intégration des méthodes formelles et des méthodes graphiques a été l un des challenges des industriels, et a ainsi suscité de nombreux travaux au sein d organisations scientifiques internationales de recherche (IFAC, IFIP) et de standardisation (IEC, ISO, OMG). L intégration de ces deux types de méthodes consiste à doter les notations graphiques d une sémantique formelle. En effet, le groupe PUML (Precise UML) a été créé pour permettre le dialogue entre toutes les personnes intéressées par la définition d'une sémantique précise pour UML [32]. L'idée est de décrire la sémantique d UML en utilisant un méta-modèle qui est présenté en termes de trois vues [33-35] : la syntaxe abstraite, les règles de bonne formation et la sémantique des éléments de modélisation. La syntaxe abstraite est exprimée en utilisant un sous-ensemble de notations structurelles statiques d'uml qui sont les diagrammes de classe et leurs relations [36-37]. Les règles de bonne formation sont exprimées en langage de contraintes objet OCL [38], qui restreignent l'utilisation des concepts du méta-modèle. La sémantique est décrite en langage naturel, explicitant l'usage et la signification des concepts du méta-modèle. Actuellement, RM-ODP accroit l'intérêt d'utiliser UML pour la modélisation des systèmes. Si les concepteurs d'uml utilisent les concepts et les mécanismes de RM-ODP pour structurer leurs larges spécifications des systèmes selon une proposition mûre et standard, les concepteurs des systèmes ODP utilisent la notation UML pour exprimer leurs spécifications de manière graphique standard tirant profit des outils d'uml dans les phases de validation et vérification. En résumé, l adoption de la notation UML facilitera la conception des logiciels et la spécification d'architecture d'entreprise de grands systèmes logiciels. Ces différents avantages des méthodes de génie logiciels et des techniques de description formelle, nous ont poussés à employer l'uml/ocl et se baser sur l approche de la sémantique dénotationelle [39] pour définir la sémantique des concepts de spécification du langage considéré. En outre, les méthodes de test courantes [40], [41] ne sont pas très adaptées pour tester les systèmes ODP [2-3], en particulier pour les langages de point de vue. Une nouvelle approche de test nommée la programmation agile [42], [43] ou l approche de test first [44] est devenue 58

69 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL de plus en plus adoptée. Le principe étant l'intégration du modèle du système et du modèle du test en utilisant la méta-modélisation d'uml [45, 46]. Cette approche est basée sur l'uml exécutable [47]. Dans ce contexte, l OCL est employé pour spécifier les invariants [19] et les propriétés à tester [43]. Les invariants OCL sont définis en utilisant la sémantique dénotationelle d'uml et d OCL lui-même. II.3. Stratégie de formalisation L'idée est de permettre d'utiliser les langages de points de vue ODP tout en ayant un moyen rigoureux d analyser les modèles produits. Pour cela il faut rendre la notation précise en la dotant d'une sémantique formelle. Une telle sémantique doit être complète, elle doit préserver le degré d'abstraction de la notation et être compréhensible par les développeurs. Bien que la sémantique formelle propose une approche de définition claire et non-ambigüe, elle souffre du manque de maitrise par la majorité des concepteurs. Un avantage potentiel de fournir une sémantique précise pour les langages de point de vue ODP est de bénéficier des avantages qu offre un langage formel tel que Z ou le spectre [48]. Certains de ces avantages sont indiqués ci-dessous : - Clarté : la sémantique formellement indiquée peut agir en tant que point de référence à la résolution de désaccords de l'interprétation prévue et éclaircir la confusion autour de la signification d'une construction. - Équivalence et uniformité : une sémantique précise fournit une base non ambiguë pour comparer et contraster le modèle RM-ODP avec d'autres techniques et notations, et pour assurer l'uniformité entre ses différents composants. - Extensibilité : la solidité des extensions à RM-ODP peut être vérifiée. - Raffinement : l'exactitude des étapes de conception des systèmes ODP peut être vérifiée et documentée avec précision. En particulier, une sémantique correctement développée supporte le développement des transformations de conception, dans lesquelles un modèle plus abstrait est schématiquement transformé en modèle d'exécution. - Preuve : les preuves justifiées et l'analyse rigoureuse des propriétés importantes d'un système ODP exigent une sémantique précise afin de déterminer leur exactitude. 59

70 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL Nous proposons une démarche systématique de modélisation de la sémantique des langages de point de vue ODP fondée sur la description en UML, OCL et de la sémantique dénotationnelle. L'emploi de techniques de méta-modélisation et de langages formels comme OCL (Object Constraint Langage) apportent des solutions pour mieux préciser les modèles. Cette approche se fonde sur la précision mathématique de la sémantique dénotationnelle de même que sur l'accessibilité et le rôle prépondérant des définitions en UML/OCL pour répondre à deux grandes questions : 1) Comment communiquer aux concepteurs une définition précise d'un langage? 2) Comment intégrer des modèles de la sémantique des langages à l architecture orientée modèle (MDA) d une manière cohérente et uniforme avec une démarche UML? Dans le contexte de l MDA, l'intégration de tels modèles de langages permettra d'appuyer le développement logiciel par une génération automatique de code vers de multiples langages cibles. L'alternative que nous proposons, consiste à définir la forme d'une instance de chaque élément du langage et d'un ensemble de règles qui déterminent quelles instances dénotées ou non par un élément du langage particulier. Généralement, les trois phases principales de l'approche dénotationnelle sont : 1) Définition du méta-modèle du langage des modèles (domaine syntaxique) ; 2) Définition du méta-modèle du langage des instances (domaine sémantique) ; 3) Définition du mapping entre ces deux langages (fonction de signification). Afin de mettre en application l approche de méta modélisation et de la sémantique dénotationelle, il est nécessaire de développer une démarche pour formaliser la sémantique. Ceci est prévu pour agir en tant que guide (étape par étape) du procédé de formalisation. En développant une stratégie de formalisation pour RM-ODP il a été nécessaire de considérer les questions suivantes : 1) L'approche méta modèle employée dans la sémantique courante de RM-ODP est-elle appropriée pour assigner une sémantique précise aux langages de point de vue? 2) La sémantique existante de RM-ODP devrait-elle être employée comme base pour développer une sémantique précise pour RM ODP? 3) Étant donné la grande portée de RM-ODP, quelle partie devrait être formalisée en priorité? 60

71 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL II.3.1. La convenance du méta-modèle Plusieurs approches sont utilisées pour assigner la sémantique à un langage. Une des plus connue est l'approche dénotationnelle. Dans cette approche, on associe à chaque représentation syntaxique certaines entités mathématiques, tels que les entiers, les fonctions, les ensembles et les relations appelées dénotations. Typiquement, des fonctions sont employées pour faire un mapping entre la syntaxe et les dénotations. La signification d un langage simple pour additionner et soustraire des nombres naturels pourrait être décrite en termes de deux fonctions : ajout et soustraction, et le résultat de chacune serait une valeur simple d un nombre entier. L'utilisation d'un langage pour donner une description de la metacircular` de sa propre sémantique dénotationnelle est bien connue dans l'informatique. Par exemple, le langage de spécifications Z a donné une sémantique metacircular en utilisant un sous-ensemble simple de Z. L'usage du méta-modèle dans ces contextes est justifié par la possibilité de donner une interprétation formelle à une méta-description en termes de langage plus fondamentale telle que la logique d'attribut. Cet argument peut également être appliqué à ODP, car il est probable qu'il peut donner une interprétation plus fondamentale en termes d'ensembles et de logiques de prédicats. En effet, plusieurs travaux significatifs ont été déjà réalisés pour décrire la sémantique des concepts de modélisation comme des expressions en Z [48]. Une autre raison importante et pragmatique de choisir ODP pour décrire sa propre sémantique dénotationelle, réside dans le fait qu elle est conçue pour fournir des moyens intuitifs pour construire des modèles. L'utilisation d'odp aide mieux à comprendre ODP et est susceptible d'être une manière utile de tester l'expressivité et la puissance des langages ODP comme langages de spécification et de modélisation. Étant donné qu'odp est sensé être utilisé pour décrire sa propre sémantique, comment cette sémantique devrait-elle être présentée afin de mettre l accent sur la sémantique dénotationnelle? bien que la sémantique courante d'odp fait déjà une distinction entre la syntaxe et la sémantique (comme dans l'approche dénotationelle), Cependant, le modèle de rerérence ODP emploi généralement le langage naturel pour décrire la partie sémantique. 61

72 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL Notre approche utilise des associations (et des contraintes sur des associations) pour mapper les éléments syntaxiques à leurs dénotations. II.3.2. L utilisation du standard Etant donné que l approche méta modèle ait été choisie, deux approches de développement de la sémantique précise des langages ODP peuvent être adoptées : - La première approche est d'ignorer la documentation existante de la sémantique et développer un nouveau modèle. Ceci a l'avantage que le modélisateur est complètement libre pour développer une sémantique appropriée à ses besoins. Par exemple, l accent pourrait être mis sur l obtention d un modèle sémantique simple, ou un modèle qui supportera aisément une technique particulière de preuve. - La deuxième approche est d'adopter la sémantique existante comme base à partir de laquelle une sémantique précise peut être obtenue. Ci-dessous, quelques raisons pratiques d'adopter cette approche : 1. En tenant compte du temps et d'effort considérables qui ont été investis dans le développement de la sémantique existante d'odp, on ne peut pas prévoir qu'une proposition sémantique radicalement différente sera incorporée dans les nouvelles versions. 2. En omettant les contraintes de la sémantique existante, il est facile de développer des modèles qui sont incompatibles avec la norme ou d'omettre ses aspects importants. Un aspect important de l'approche est de clarifier itérativement la sémantique existante des langages. II.3.3. La précision de la sémantique de base Pour faire face à la grande portée d RM-ODP, il est normal de se concentrer sur des concepts essentiels des langages pour établir une base claire et précise comme base pour la formalisation. Par conséquent, l'approche adoptée se concentre sur l identification et la formalisation d un modèle sémantique de base pour RM-ODP avant d'aborder ses autres dispositifs. Ceci a un certain nombre d'avantages : premièrement, il rend la tâche de formalisation plus maniable ; deuxièmement, un noyau plus précis agira en tant que base pour concevoir la sémantique du reste du langage, l utilité provient du fait que la sémantique de chaque langage de point de vue peut être définie comme «vue» particulière de la sémantique 62

73 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL du modèle de base [49]. Par exemple, la signification des concepts d'interaction devrait être interprétée en termes de sous-ensemble de la sémantique comportementale de base. Démarche de formalisation Pour concrétiser notre stratégie, nous proposons une démarche selon les étapes suivantes : 1) Choix d'une notation formelle. De part notre expérience et pour son caractère général, nous avons sélectionné le langage de contraints orienté-objet OCL ; 2) Identification des éléments de base des langages de points de vue ODP ; 3) Définition de la syntaxe abstraite de la notation graphique. Le méta-modèle peut poser des problèmes d'ambiguïtés, aussi avons nous choisi de la décrire en OCL ; 4) Caractérisation de la notion de système en termes de composants, d'interactions et de comportements. C'est le domaine sémantique auquel va correspondre la syntaxe abstraite ; 5) Définition des fonctions de signification qui permettent le lien entre syntaxe abstraite et sémantique [51]. La figure suivante exprimée par un diagramme d activité UML résume notre approche de formalisation : Modèle Informel Définir la syntaxe abstraite en OCL Décrire les invariants et pré/post conditions en OCL Domaine Syntaxique Domaine Sémantique Établir le lien entre domaines par la fonction de signification Modèle Formel Figure 15 : Le processus de formalisation [51] 63

74 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL II.4. RM-ODP RM-ODP est un cadre pour la construction des systèmes répartis ouverts. Il définit un modèle objet générique dans les parties fondement et architecture qui contiennent les spécifications des caractéristiques exigées qui qualifient le traitement réparti comme ouvert. II.4.1. Le modèle objet ODP Le modèle objet ODP est très général et introduit un ensemble minimal et générique de concepts de modélisation basée objet. Ces concepts de base concernent l'expression de l'existant (ce qui se passe) et de l'activité (où et sur quoi cela se passe). Les concepts principaux sont : objet, action, interface et interaction. Un système est alors composé d'objets interagissant. SuperType Type SubType Satisfies SuperClass Class SubClass Satisfies Satisfies Interaction Interface Provides 1..* Object Performs Action 1..* Has 1..* Substitutes 1..* 1..1 Identity Description Description Description Internal Interface Template Object Template Action Template Template Figure 16 : RM-ODP Foundation Object Model Un objet est une entité contenant de l'information et offrant des services [51]. Il est caractérisé par son identité, son état, son comportement et ses interfaces. L'identité d'un objet permet de le distinguer des autres objets. L'état d'un objet caractérise l'information qu'il détient à un instant donné. Son comportement caractérise l'ensemble des changements d'états possibles qui peuvent l'affecter et définit les actions potentielles auxquelles l'objet peut prendre part. Cet 64

75 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL ensemble d'actions associées à un objet est réparti en actions internes et externes (interactions). Une action interne se produit sans la participation de l'environnement de l'objet. Une interaction se produit avec la participation de l'environnement de l'objet. Le terme environnement d'un objet désigne tous les objets autres que celui considéré. Une interaction appartient à une unique interface d'un objet, qui correspond à un point d'accès à cet objet. Une interface définit un ensemble d'interactions possibles d'un objet, qui correspond à un comportement observable. En effet, seules les interactions sont observables, et non les actions internes, du fait de l'encapsulation. Un objet peut avoir plusieurs interfaces et leur nombre peut varier dans le temps. Ces interfaces constituent des vues abstraites des fonctions fournies par un objet, en masquant la façon dont celui-ci manipule l'information ou effectue les changements d'état. Les objets sont décrits par des gabarits (template) qui spécifient leurs caractéristiques communes à un niveau de détail suffisant pour permettre leur instanciation. Un gabarit caractérise donc l'ensemble des objets qu'il instancie. Ainsi des objets exhibant le même comportement peuvent être décrits par le même gabarit. A partir du comportement d'un objet, il est possible d'identifier des rôles de l'objet par extraction d'un sous-ensemble de fonctionnalités spécifiques. Un rôle correspond alors à un sous-ensemble du comportement total d'un objet. Considérer un objet en fonction de son rôle revient à s'intéresser à un sousensemble de ses actions en faisant abstraction de ses autres actions. Selon ses interactions, un objet peut avoir plusieurs rôles à un instant donné et peut avoir des rôles différents dans le temps. Le modèle objet définit le concept de type (d un <X>) comme étant un prédicat, c'est-à-dire une propriété, ou un ensemble de propriétés, portant sur une collection de choses (objets, interfaces, etc.). Par exemple, "est rouge" est un type. On dit que quelque chose satisfait un type, ou est du type, si le prédicat tient pour la chose. Les choses peuvent être très différentes, tout en satisfaisant le même type; il suffit qu'elles possèdent les propriétés que prescrit le type. Par exemple, une voiture de sport donnée et une maison de briques donnée peuvent toutes être rouges. Les types organisent implicitement les choses sous forme d'ensembles appelés classes. Une classe (de <X>) est la collection des objets <X> qui présentent les propriétés décrites par le type. La notion de type est très générale. Il est possible de la spécialiser de diverses manières. Elle est utile dans tout contexte où il est nécessaire de parler des propriétés des 65

76 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL choses, de raisonner à leur sujet et de les vérifier (aux fins, par exemple, de courtage, ou de liaison). Des concepts de type et de classe découlent des hiérarchies naturelles, de classe à sous-classe et de type à sous-type. La distinction entre classe et sous-classe correspond à la distinction intuitive que fait la théorie des ensembles entre ensemble et sous-ensemble. Une classe est sous-classe d'une autre si et seulement si la première est un sous-ensemble de la dernière. Un type est sous-type d'un autre si le prédicat du premier implique le prédicat du second. Les notions de sous-classes et de sous-types vont de pair. A chaque type correspond une classe associée, qui peut naturellement être vide. Si donc nous avons deux types, T1 et T2, il doit exister des classes C1 et C2 qui leur sont associées. T1 est sous-type de T2 précisément quand C1 est sous-classe de C2. Cette hiérarchie de type et de classe est à distinguer de la hiérarchie d'héritage qui s'exprime par les concepts de classe parente et classe dérivée. Ces deux concepts sont fondés sur la notion de modification incrémentale de gabarit, c'est à dire la dérivation d'un nouveau gabarit à partir de la modification d'un gabarit existant. Les concepts d'objet, d'action et d'interface sont décrits par les concepts de type, de gabarit et de classe. II.4.2. Utilisation des langages de point de vue Le présent Modèle de référence définit un ensemble de cinq langages (entreprise, information, traitement, ingénierie et technologie) Chaque langage correspondant à l'un des points de vue. Chacun décrit les concepts et les règles pour spécifier un système ODP dans le point de vue correspondant. Un langage de point de vue utilise des concepts provenant de la recommandation Rec. UIT-T X.902 ISO/CEI , affine ces concepts et introduit des règles prescriptives ainsi que des concepts additionnels spécifiques à ce point de vue. Ces concepts additionnels sont, à leur tour, définis en utilisant des concepts de la même norme. Une spécification du système comprend des spécifications correspondant à un ou plusieurs points de vue. Ces spécifications doivent être mutuellement cohérentes. Des règles visant à structurer de façon cohérente les spécifications de point de vue sont données à l'article 10 de la partie fondements. Le spécificateur doit démontrer par d'autres moyens que les termes sont utilisés de manière cohérente dans les spécifications. Une spécification d'une partie d'un système faisant appel à plusieurs points de vue contraindra plus les réalisations qu'une 66

77 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL spécification faisant appel à moins de points de vue. La spécification d'objets dans un point de vue donné utilise le langage de point de vue associé ou les langages associés à d'autres points de vue. Il n'est pas nécessaire de spécifier un objet complètement de chaque point de vue pour obtenir un ensemble cohérent de spécifications de cet objet. II.4.3. Le langage d'entreprise RM-ODP L'élaboration de spécifications s'inscrit souvent dans la catégorie désignée comme étant une spécification d'analyse ou d'exigences. Il existe de nombreuses méthodes utilisées pour comprendre, adopter et spécifier des systèmes dans le contexte des organisations auxquelles ils appartiennent. Ces méthodes peuvent fournir d'utiles ouvertures sur l'organisation considérée comme sur les exigences auxquelles les systèmes doivent satisfaire afin de prendre en charge ces méthodes. Cependant, celles-ci manquent généralement de la rigueur, de la cohérence et de la complétude nécessaires à une spécification approfondie. La spécification du système ODP permet de décrire tout ou une partie des points suivants : - un système existant dans son environnement ; - une future structure envisagée ou le comportement de ce système existant dans le même environnement ou dans un environnement futur envisagé ; - un système à créer dans un environnement donné. Les spécifications s'adressent également à différents lectorats. Pour parvenir à un accord entre les utilisateurs potentiels d'un système ODP et le fournisseur de ce système, il peut être nécessaire d'avoir des présentations différentes du même système, l'une en termes compris par le client et l'autre en termes directement liés à la réalisation du système. Une spécification d'entreprise définit les objectifs, le domaine d'application et les politiques d'un système de traitement ODP. L'utilisation des spécifications d'entreprise peut s'étendre au-delà des phases initiales du processus d'ingénierie logicielle. Une tendance actuelle est d'intégrer des systèmes existants en réseaux mondiaux dans lesquels la fonctionnalité considérée couvre de multiples organisations. Le langage d'entreprise permet de spécifier l'accord conclu au sujet du comportement commun des systèmes ODP à l'intérieur de ces organisations et interorganisations. La spécification d'entreprise peut aussi être utilisée lors d'autres phases du 67

78 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL cycle de vie du système. Elle peut par exemple être utilisée lors du fonctionnement du système afin de contrôler les accords passés entre le système et ses utilisateurs et de conclure de nouveaux accords selon la même structure contractuelle. Le langage d'entreprise comprend des concepts, des règles et des structures pour la spécification d'un système ODP du point de vue entreprise : Objets d'entreprise : Un objet d'entreprise est tout objet contenu dans une spécification d'entreprise. Les objets d'entreprise et les entités qu'ils modélisent sont ceux que l'on estime nécessaires afin de spécifier et comprendre le système du point de vue entreprise. Un objet d'entreprise peut représenter un être humain, une entité juridique, un système informatique, une ressource, ou une série ou partie de ces éléments. Communauté : c est un concept de structuration fondamental pour les spécifications d'entreprise. Ce concept est une configuration d'objets d'entreprise qui décrit un ensemble d'entités formé afin d'atteindre un objectif (par exemple, des êtres humains, des systèmes de traitement de l'information, des ressources de diverses sortes et des ensembles de telles ressources). Ces entités font l'objet d'un accord régissant leur comportement collectif. Comportement : Le comportement d'une communauté est un ensemble collectif composé des actions auxquelles les objets de la communauté participent afin de remplir ses rôles, ainsi qu'un ensemble de contraintes relatives à l'instant auquel ces actions peuvent intervenir. Rôles : Un rôle désigne une abstraction du comportement communautaire. Toutes les actions de ce rôle sont associées au même objet d'entreprise dans la communauté. Chaque action de la communauté fait partie d'un même comportement de rôle ou une interaction faisant partie de plusieurs comportements de rôle. Chacune des ces abstractions est étiquetée comme étant un rôle. Le comportement désigné par un rôle est soumis aux contraintes spécifiées dans le contrat et dans la structure de la communauté. Contrairement à la spécification d'actions et à leur ordonnancement en termes de processus, l'accent est mis sur les objets d'entreprise qui participent au comportement particulier. Les rôles servent alors à décomposer le comportement de la 68

79 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL communauté en éléments qui peuvent être chacun exécutés par un objet d'entreprise de la communauté. L'objet d'entreprise qui exécute le comportement d'un rôle est considéré comme remplissant ce rôle dans la communauté ou est considéré comme attribué à ce rôle dans la communauté. Politique : une politique identifie la spécification d'un comportement ou des contraintes sur un comportement. Celle-ci peut être modifiée au cours de la durée de vie du système ODP ou afin de permettre l'application d'une même spécification à un ensemble de systèmes ODP différents. Les modifications des politiques d'une communauté au cours de sa durée de vie ne peuvent intervenir que si une spécification d'entreprise contient le comportement qui peut provoquer de telles modifications. Les politiques peuvent s'appliquer à une communauté dans son ensemble, à des objets d'entreprise qui remplissent des rôles dans cette communauté (quels que soient ces rôles), à des rôles (c'est-à-dire à toutes les actions nommées par ces rôles) ou à des types d'action. Elles peuvent également s'appliquer au comportement collectif d'un ensemble d'objets d'entreprise. La spécification d'une politique comprend : - le nom de la politique ; - les règles, exprimées sous la forme d'obligations, de permissions, d'interdictions et d'autorisations ; - les éléments de la spécification d'entreprise affectés par la politique ; - le comportement de modification de la politique. La spécification d'une politique peut indiquer le degré suivant lequel ou les circonstances dans lesquelles il peut y avoir délégation à un objet d'entreprise de la part d'un autre objet. II.4.4. Le langage de point de vue traitement RM-ODP Le point de vue traitement s'intéresse directement à la répartition du traitement, mais pas aux mécanismes d'interaction grâce auxquels la répartition devient possible. La spécification de traitement décompose le système en objets qui remplissent des fonctions individuelles et qui interagissent mutuellement sur des interfaces bien définies. Elle fournit ainsi le fondement des décisions sur la manière de répartir les travaux à effectuer puisqu'il est possible de placer les interfaces en toute indépendance, supposition faite qu'il soit possible de définir dans la 69

80 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL spécification d'ingénierie les mécanismes de communication capables de prendre en charge le comportement à ces interfaces. Le cœur du langage de traitement est le modèle par objets qui définit : - la forme d'interface que peut présenter un objet ; - la manière dont les interfaces peuvent être liées et les formes d'interactions qui peuvent s'y dérouler ; - les actions qu'un objet peut exécuter dont, en particulier, la création de nouveaux objets et de nouvelles interfaces, ainsi que l'établissement de liaisons. Le modèle de traitement fournit la base qui permet d'assurer que les langages de spécification, les langages de programmation et les mécanismes de communication opéreront tous de manière cohérente, condition d'interfonctionnement ouvert et de portabilité des composants. Le langage de traitement utilise un ensemble de concepts de base et de règles de structuration définis par usage des concepts de modélisation par objets que définit la Rec. UIT-T X.902 ISO/CEI et plusieurs concepts spécifiques au point de vue traitement : Objets et interfaces. Les spécifications des systèmes ODP sont exprimées en termes d'objets. Un objet est une représentation d'une entité du monde réel. Il contient de l'information et offre des services. Un système se compose d'objets en interaction mutuelle. Dans le point de vue traitement nous parlons des objets de traitement, qui modélisent les entités définies dans les spécifications de traitement. Les objets de traitement sont des abstractions des entités qui se produisent dans le monde réel, dans les systèmes ODP, ou dans d'autres points de vue [2,3]. Les objets de traitement ne peuvent agir les uns sur les autres que par des interfaces. Une interface représente une partie du comportement de l'objet, relative à un sous-ensemble donné des interactions auxquelles il peut participer. Chaque interface est identifiable à un ensemble d'interactions auxquelles l'objet peut participer. Il est à noter que ces interactions ne prennent pas nécessairement place avec d'autres objets : un objet peut avoir des interactions avec luimême. Une importante caractéristique des objets du modèle de référence ODP est qu'un objet peut disposer de plusieurs interfaces. Gabarit de traitement. Les objets et les interfaces de traitement peuvent être spécifiés par des gabarits. Dans ODP, un gabarit de <X> est une spécification des caractéristiques 70

81 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL communes à une collection de <X>, suffisamment détaillée pour permettre, en l'utilisant, l'instanciation d'un <X>. <X> peut être tout élément qui a un type. Ainsi, une interface d'un objet de traitement est habituellement spécifiée par un gabarit d interface de traitement, qui est un gabarit d'interface pour une interface signal, une interface flux ou une interface opération. Un gabarit d'interface de traitement comprend une signature d'interface signal, une signature d'interface flux ou une signature d'interface opération, selon le cas, une spécification de comportement et une spécification de contrat d'environnement. Une signature d'interface se compose d'un nom, d'un rôle de causalité (producteur, consommateur, etc.), et de l'ensemble de signatures de signal, de signatures d'opération, ou de signatures de flux comme approprié. Chacune de ces signatures spécifie le nom de l'interaction et de ses paramètres (des noms et des types). Signature d interface signal: signature d'interface pour une interface signal comprenant un ensemble fini de gabarits d'action pour chacun des types de signal de l'interface. Chaque gabarit d'action comporte, pour l'objet qui l'instancie, le nom du signal, le nombre, les noms et les types de ses paramètres et une indication de causalité (initiateur ou répondeur, mais pas les deux à la fois). Interactions. Les interactions qui se produisent entre objets de traitement sont essentiellement asynchrones; elles peuvent prendre trois formes : signaux, opérations et flux. Un signal peut être considéré comme une interaction atomique élémentaire entre les objets de traitement. Les signaux constituent l'unité la plus fondamentale de l'interaction dans le point de vue traitement. Les opérations sont le reflet du paradigme client/serveur. Une opération est une interaction qui se produit entre un objet client et un objet serveur qui appelle (ou invoque) l'exécution d'une fonction quelconque par le serveur. Il y a deux types d'opérations: interrogations et annonces. Une interrogation est une interaction bidirectionnelle dans laquelle le serveur renvoie une réponse (ou terminaison) à la demande du client. une annonce est une interaction à sens unique où il n'y a pas de réponse à la demande du client. La notion de terminaison est une généralisation des concepts de résultat et d'exception que l'on trouve dans de nombreux langages de programmation. Les flux peuvent servir à modéliser le débit d information, c.-à-d., un flux représente une abstraction d'une séquence d'interactions aboutissant à l'acheminement d'informations d'un objet producteur vers un objet consommateur. Il se caractérise par son nom et par son type, qui spécifie la nature et le format 71

82 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL des données échangées. Le modèle de traitement ne spécifie pas la sémantique exacte des flux. Il peut en effet exister, selon le domaine d'application, de nombreuses sémantiques de flux. De point de vue traitement, les opérations et les flux peuvent être exprimés en termes de signaux [1-4]. II.5. Sémantique dénotationnelle pour le langage de point de vue entreprise II.5.1. Domaine Syntaxique La modélisation de la syntaxe abstraite est certainement la partie la mieux connue de l'approche dénotationnelle. En effet, la grammaire abstraite décrit des arborescences qui peuvent être représentées sous forme d'objets. L'idée est de définir une classe pour chaque domaine syntaxique. Lorsqu'un domaine syntaxique possède plusieurs alternatives, sa classe est définie comme abstraite et on définit autant de sous-classes concrètes qu'il y a d'alternatives dans la production. Nous définissons dans cette section le méta-modèle des concepts présentés dans la section précédente. La syntaxe abstraite des concepts d'objet de base est décrite par le méta-modèle représenté par la Figure 16. La Figure 17 ci-dessous définit le Méta-modèle de la syntaxe abstraite des concepts du langage d'entreprise (Balouki et al.2007) [51,52]. Figure 17 : Méta-modèle de la syntaxe abstraite du langage d entreprise 72

83 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL Nous allons utiliser des contraintes pour spécifier des restrictions sur les éléments des différents modèles ODP. Une contrainte peut être attachée à tout type d'élément du modèle. Un invariant de template, par exemple, peut être défini par une contrainte en spécifiant une expression booléenne qui doit être satisfaite pour toutes les instances de cette template. Une contrainte est définie comme une politique spécifiant des restrictions sur les rôles des objets d entreprise. Les expressions booléennes composent le corps d'une contrainte et correspondent juste à un type particulier d'expression. Les contraintes peuvent être des pré- et des post-conditions, des invariants ou des gardes. Le langage OCL est utilisé, lors des différentes phases de notre démarche, pour exprimer les contraintes, entre autres pour spécifier des invariants sur les templates en précisant par exemple le domaine de valeur d'un attribut et les types dans les modèles de templates. Il sert aussi pour l expression de pré- et post-conditions et, bien sûr, pour spécifier les contraintes de contexte entre les différentes constructions syntaxiques. Ces contraintes sémantiques peuvent être exprimées en OCL de la façon suivante : Context m: Model inv : Les templates source et cible des relations d association du modèle m sont des templates du m. m. Template->includesAll(m.Relation.Source ->union(m.relation.target) m.roles->includesall(m.objecttemplates.roles) // Les rôles incluent les rôles remplis par les objets d entreprise m.roles->includesall(m.communitytemplate.roles) // ainsi les rôles d une communauté. Le rôle d'interface est un rôle dans une communauté indiquant le comportement qui intervient avec la participation d'objets qui sont membres de cette communauté (Rec X.911, clause 6.3.4). m.roles->includesall(m.interfacetemplate.roles) m.types ->includesall(m.interactiontemplates.types) // Un type-gabarit est un prédicat défini dans un gabarit. m.interactiontemplates -> includes(m.objecttemplates.actions) // Les actions peuvent être des interactions entre //l'objet et son environnement. m. EnterepriseObjectTemplates ->includesall(m.interactiontemplates.source- >union(m.interactiontemplate.target) Context community inv : Le modèle, dont s est une instance, inclut tous les templates communauté dont les s.community sont instance. 73

84 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL s.of.communitytemplates->includesall(s.communitys.of) Context o: Object Template inv : eot (enterprise object template ) n'est pas un parent ou un fils de lui-même not (eot.parents ->includes(eot ) or eot.children->includes(eot)) Tous les objets d entreprise d une communauté ont bien cette communauté comme configuration et inversement. context Community inv : enterpriseobject->notempty() implies enterpriseobject ->forall( e : enterpriseobject e.configuration- >includes(self)) context Enterpriseobject inv : community ->notempty() implies community ->forall ( c : configuration c.enterpriseobject ->includes (self)) Context communityobject inv : Le type d objet de communauté correspond exactement au type d objet d entreprise self.ocliskindof(enterpriseobject) Un acteur (par rapport à une action) : rôle (par rapport à cette action) au travers duquel l'objet d'entreprise qui le remplit participe à l'action. Cet objet peut être appelé acteur. (Rec X.901, Clause 6.3.1) Actiontemplate.actor.oclIsType(enterpriseobject) Un artefact (par rapport à une action) : rôle (par rapport à cette action) au travers duquel l'objet d'entreprise qui le remplit est visé dans l'action. Cet objet peut être appelé artefact (Rec X.901, Clause 6.3.2) Actiontemplate.artefact.oclIsType(enterpriseobject) Une ressource (par rapport à une action) : rôle (par rapport à cette action) au travers duquel l'objet d'entreprise qui le remplit est essentiel à l'action: il nécessite une attribution ou peut devenir indisponible. Cet objet peut être appelé ressource (Rec X.901, Clause 6.3.3). Actiontemplate.ressource.oclIsTypeof(enterpriseobject) 74

85 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL II.5.2. Domaine sémantique Nous définissons le modèle de spécification de point de vue entreprise ODP. C'est un ensemble d'objets d'entreprise créée pour répondre à un objectif précis. L'objectif est exprimé sous forme de contrat qui précise comment l'objectif peut être atteint. Les objets sont des instances d'un ou plusieurs templates d objet; ils peuvent être d'un ou de plusieurs types. Le méta-modèle prend en charge les types dynamiques. La sémantique d'un modèle UML est définie en ajoutant des contraintes sur les instances possibles d un modèle. Celles-ci représentent le domaine sémantique qui peut être intégré avec le domaine syntaxique au sein d'un même méta-modèle. La Figure 18 présente le métamodèle proposé pour le domaine sémantique [52,53] : Figure 18 : Méta-modèle des domaines sémantiques du langage d entreprise Nous donnons ci-après des contraintes entre les instances du domaine sémantique (Balouki et al.2007) [52] : Context s: system inv : s.entrepriseobjects->includesall(s.links.source->union(s.links.target) Cette contrainte OCL exprime le fait que les objets d entreprise source et cible des liens du système s sont des objets dans s. 75

86 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL De même, la contrainte «Les liens entre deux objets entreprise sont uniques par relation» peut être exprimée par l expression OCL : s.links->forall(l s.links- >select(l' l'.source=l.source&l'.target=l.target&l'.of=l.of)=l) Un autre aspect du modèle à renforcer se rapporte à la signification des instances indirectes. Une instance d'un template est également une instance indirecte de ses templates de parent. Cette propriété de conformité d'instance peut être indiquée avec précision en ajoutant des contraintes additionnelles sur le rapport entre les instances d'un template et les instances appartiennent aux parents du template. On les spécifie comme suit : Context t: communitytemplate inv : t.parent -> forall (c: communitytemplate c.instance -> inclaudesall(t.instance)) Context t: entreprisetemplate inv : t.parent -> forall (e: entreprisetemplate e.instance -> inclaudesall(t.instance)) Context I: interfacerole inv : I.Role -> forall (R: Role R.instance -> inclaudesall(i.instance)) Ceci indique que les instances de tout template, t, est un sous-ensemble de ceux qui appartiennent aux instances de ses parents. Context community inv : Une communauté est une configuration d'objets constituée pour atteindre un objectif, cet objectif est exprimé dans un contrat qui spécifie la façon dont il peut être atteint. (RM-ODP, partie 3, clause 5.1.1). self.contrat->includeall(m.community.specifier) // Un contrat spécifie l objectif d une communauté Self.objective->notEmpty() // Une communauté a au moins un objectif Self. EnterepriseObject-> size() >= 1 // Une communauté contient au moins un objet d entreprise Un objet d entreprise est distinct de tout autre objet de la communauté par son identité. self.objectentereprise.allinstance->forall(o1,o2 :object Ò1 <> O2 implies O1.id <> Oé.id) Tous les objets d'entreprise contenus dans une spécification d'entreprise remplissent au moins un rôle dans au moins une communauté. Lorsqu'ils remplissent leurs rôles, les objets d'entreprise interagissent comme membres de la communauté (RM-ODP, partie 5, clause 7.4). Self.member_of ->includes (self.role.enterepriseobject) // Les rôles sont remplis par les objets membre de la //communauté. 76

87 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL Self.member_of ->Forall(o:EO self.o.role->notempty) // les objest d entreprise remplissent au moins un rôle dans // au moins une communauté. II.5.3. La fonction de signification La sémantique du langage basé UML est déterminée par la relation entre un modèle du système et ses éventuelles instances. Les domaines syntaxiques et sémantiques sont définis en utilisant UML/OCL. L'association entre ces deux domaines est définie en utilisant le même méta-modèle d'uml. La sémantique d'un modèle UML est définie en ajoutant des contraintes sur la relation entre le modèle et ses instances possibles. Ceci se traduit par des contraintes sur la relation entre les expressions de la syntaxe abstraite des modèles UML et celles des instances. Les contraintes OCL jouent le rôle de la fonction de signification lors de la définition de la sémantique dénotationnelle dans le contexte UML [20, 31]. Nous donnons ciaprès quelques contraintes qui montrent le principe global. Nous utilisons la sémantique des invariants telle qu elle définie dans [19]. Premièrement, nous donnons une contrainte concernant les objets d entreprise (Balouki et al.2007) [53]. Elle montre comment les relations d héritage forcent un objet pour être instance des classes de ses parents. Context o: object inv: Les templates de o doivent être l union d un template unique et de tous ses parents : o.of->exists(t o.of=t->union(t.parents)) Ensuite, nous définissons quatre contraintes qui assurent qu une instance du modèle est une instance valide du modèle dont elle devrait être une instance. Les deux premières contraintes expriment le fait que les objets d entreprise et les comportements sont associés par des templates et des rôles définis dans le modèle. La troisième contrainte, exprime le fait que les comportements sont associés par des rôles définis dans le modèle. Context s: system inv: Le modèle, dont s est une instance, comprend tous les templates dont les objets de s sont instances (RM-ODP, partie 1, clause 7.2.4) : 77

88 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL s.of.objecttemplates->includesall(s.objects.of) Le modèle, dont s est une instance, inclut tous les rôles dont les comportements de s sont instances : Context s: system inv : s.of.roletemplates->includesall(s.roles.of) La quatrième contrainte assure le respect des contraintes de cardinalité sur les communautés : Context s: system inv: s.community.of -> forall( r let community_in_s be r.instances ->intersect ( s.community ) in (r.upperbound -> notempty implies community_in_s ->size <= r.upperbound ) and coomunity_in_s->size >= r.upperbound) Les modifications à la structure ou au comportement d'une communauté ne peuvent être apportées que si une spécification d'entreprise inclut un comportement qui peut provoquer de telles modifications (Rec ISO/IEC 15414, clause 7.6.3). Les modifications à prendre ici en considération sont les suivantes(balouki et al.2009) [53]. : - ajout, modification ou suppression de politiques ou de règles ; - ajout, modification ou suppression de rôles ; - ajout ou suppression d'objets d'entreprise ; - ajout, modification ou suppression de processus ou d'étapes. Context Community:: add_in_community (o : Object) : id pre : not (community.member_of ->includes(o) ) post: result.oclisnew() and if o.oclistypeof(enterepriseobject ) then community.member_of ->including(result) else if o.oclistypeof(role) then community.specifing_in ->including(result) else community.policy ->including(result) end if end if Context Community:: change_in_community (o : Object) : id 78

89 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL pre : community.member_of ->includes(o) post: if o.oclistypeof(enterepriseobject ) then community.member_of ->including(result) else if o.oclistypeof(role) then community.specifing_in ->including(result) else community.policy ->including(result) end if end if Context Community:: remove_in_community (obj : Object) pre : community.member_of ->includes(obj) or community. specifing_in ->includes(obj) or community.policy ->includes(o) or post: if o.oclistypeof(enterepriseobject ) then community.member_of ->excluding(result) else if o.oclistypeof(role) then community.specifing_in ->excluding(result) else community.policy ->excluding(result) end if end if Context Community:: terminating_a_community (c : community) : boolean pre : community.achieved = true post: result =community. EnterepriseObject.allinstances ->Isempty and communityrole.allinstances ->Isempty and community. policy.allinstances ->Isempty Context Community:: Assignmentrole (o : Entrepriseobject) :role pre : not (community. Specified_in ->includes(r) ) post: result.oclisnew() and role = role@pre -> including(result) and o.role = o.role@pre -> including(result) 79

90 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL II.6. Sémantique dénotationnelle pour le langage de point de vue traitement II.6.1. Domaine Syntaxique La Figure 19 présente un diagramme de classes partiel de la syntaxe abstraite du langage de traitement (Balouki et al.2009) [54]. Certaines contraintes d un système ODP ne sont pas définissables par les éléments de modélisation décrits par UML. Elles sont souvent exprimées par des notes en langage naturel ce qui peut induire des ambiguïtés quant à leurs interprétations. OCL se veut un langage formel permettant de décrire ces contraintes de façon déterministe. De plus, il se veut simple à écrire ainsi qu à comprendre. Ces contraintes sémantiques peuvent être exprimées en OCL de la façon suivante : Un gabarit d objet de traitement est un gabarit d'objet qui comprend un ensemble de gabarits d'interface de traitement que l'objet peut instancier et une spécification de comportement (RM-ODP, partie 3, clause 7.1.9). Context m : Model inv : m.computationalobjecttemplate-> includesall(m.conputationalinterfacetemplate)-> union (m.conputationaltemplate.behavior) Un gabarit d interface de traitement est un gabarit d'interface pour une interface signal, une interface flux ou une interface opération. Un gabarit d'interface de traitement comprend une signature d'interface signal, une signature d'interface flux ou une signature d'interface opération. (RM-ODP, partie 3, clause ). Context m : Model inv : m.computationalinterfacetemplate.types ->includesall(m.computationalobject.signainterface) -> union (m.computationalobject.flowinterface) -> union (m.computationalobject.operationinterface) Context cit : ComputationalInterfaceTemplate inv : cit.signainterfacesignature.oclistypeof(interfacesignature) and cit.flowinterfacesignature.oclistypeof(interfacesignature) and cit.operationinterfacesignature.oclistypeof(interfacesignature) Context m: Model inv: 80

91 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL Les objets de traitement constituent les fonctions du système. Ils offrent un ensemble d interfaces relatives à des liaisons entre objets. Un objet peut avoir plusieurs interfaces de même signature (RM-ODP, partie 2, clause 9.12). m.interactiontemplates -> includesall(m.computationalobjecttemplates.interactiontemplates) m.types ->includesall(m.interactiontemplates.types) -> union(m.computationalinterfacetemplates.types) m.computationalinterfacetemplates ->includesall(m.computationalobjecttemplates.interface) Chaque interaction d'objet de traitement se produit à l'une de ses interfaces de traitement (RM-ODP, partie 3, clause 7.2.2). m.computationalobjecttemplates.interface->includesall(m. ComputationalObjectTemplates.InteractionTemplates) Les objets source et cible d une interaction sont des objets de traitement du modèle. m.computationalobjecttemplates- >includesall(m.interactiontemplates.source>union(m.interactiontemplate.target) Figure 19 : Méta-modèle de la syntaxe abstraite du langage de traitement context i : InteractionTemplate inv : i.binder.inverse->isempty or L inverse de l'inverse de binder b est b (i.b.inverse.inverse=b and L inverse de b renverse la source et la cible de b 81

92 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL i.b.inverse.source=i.b.target and i.b.inverse.target= i.b.source L inverse de b est dans le même gabarit d interaction que b and i.b. InteractionTemplate =i.b.inverse. InteractionTemplate) Context cot : Object Template inv : cot (computational object template) n'est pas un parent ou un enfant de lui-même not (cot.parents ->includes(cot ) or cot.children->includes(cot)) Nous considérons les concepts du subtype/supertype (RM-ODP, partie 2, clause 9.9) et du subclass/superclass (RM-ODP, partie 2, clause 9.10) comme relations entre les types et les classes respectivement. Un type A est un sous-type d un type B, et B est un super-type de A, si chaque <X> satisfaisant au type A satisfait également au type B. Les relations de soustypage et de super-typage sont réflexives, transitives et antisymétriques. Context o : ComputatinalObjectTemplate inv : o.types-> forall( t1: Type, t2: Type t2.subtype -> includes(t1) implies t1.valid_for.satisfies_type=t2) o.types-> forall( t1: Type, t2: Type t1.supertype ->includes(t2) implies t1.valid_for.satisfies_type=t2) Une classe A est une sous-classe d'une autre classe B, et B est une superclasse de A, si tous les <X> satisfaisant à A satisfont aussi à B. Une sous-classe est par définition un sousensemble de chacune de ses superclasses. Context o : ComputatinalObjectTemplate inv : o.class-> forall( c1: Class, c2: Class c2.subclass -> includes(c1) implies c2.associated_type.subtype ->includes(c1.associated_type)) o.class-> forall( c1: Class, c2: Class c1.superclass -> includes(c2) implies c2.associated_type.subtype ->includes(c1.associated_type)) II.6.2. Domaine sémantique La sémantique d'un modèle UML est définie en ajoutant des contraintes sur les instances possibles d un modèle. Celles-ci représentent le domaine sémantique qui peut être intégré avec le domaine syntaxique au sein d'un même méta-modèle. La figure 20 présente le métamodèle proposé pour le domaine sémantique [54] : 82

93 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL Figure 20 : Méta-modèle des domaines sémantiques du langage du traitement Nous donnons ci-après des contraintes entre les instances du domaine sémantique (Balouki et al.2009) [54], ces contraintes s'appliquent aux éléments du diagramme représentés sur la Figure 20 : Une interface de traitement se caractérise par une signature. une signature d'interface d opération comprenant un ensemble de signatures d'interrogation et d'annonce(rm-odp, partie1, clause 8.4.1). Context is : InterfaceSignature inv : is.operatiointerfacesignature -> inclaudesall(is.annoucementsignature) ->union(is.integrationsignature) 83

94 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL and is.signalinterfacesignature -> inclaudesall(is.signalsignature) and is.flowinterfacesignature -> inclaudesall(is.flowsignature) Toute interface associée à une signature d'interface de signal est une interface de signal, et toutes ses signatures constitutives d'interaction sont des signatures de signal [54]. Context Signal inv : self.interface->forall(oclistypeof(signalinterface)) and self.signature.specifier->forall(oclistypeof(signalsignature)) and self.interfacesignature.specifier->forall(oclistypeof(signalinterfacesignature)) Toute interface associée à une signature d'interface d'opération est une interface d'opération, et toutes ses signatures constitutives d'interaction sont des signatures d'annonce, d'interrogation, d'invocation ou de terminaison [54]. Context Announcement inv : self.interface->forall(oclistypeof(operationinterface)) Context Invocation inv : self.interface->forall(oclistypeof(operationinterface)) Context Termination inv : self.interface->forall(oclistypeof(operationinterface)) Context OperationInterface inv : self.specifier->forall(oclistypeof(operationinterfacesignature)) Toute interface associée à une signature d'interface de flux est une interface de flux. Context Flow inv : self.interface->forall(oclistypeof(streaminterface)) Context StreamInterface inv : self.specifier->forall(oclistypeof(streaminterfacesignature)) II.6.3. La fonction de signification Les domaines syntaxiques et sémantiques sont définis en utilisant UML/OCL. A l instar de ce qu on a fait pour définir la fonction de signification dans le langage d entreprise, nous donnons ci-après les contraintes OCL qui associent les deux domaines syntaxiques et 84

95 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL sémantiques du langage de traitement. Nous utilisons la sémantique des invariants telle qu elle définie dans [37]. Nous donnons deux contraintes concernant les objets de traitement et les objets de liaison (Balouki et al.2009) [54]. La première montre comment les relations d héritage forcent un objet pour être instance des classes de ses parents. La deuxième assure qu'un objet de liaison relie des objets des gabarits comme dictés par son rôle. Context o: object inv: Les templates de o doivent être l union d un template unique et de tous ses parents : o.of->exists(t o.of=t->union(t.parents)) Context b:binder inv: Les objets qui sont la source/cible d une liaison ont des gabarits qui sont la source/cible des rôles correspondants. (b.of.source)->intersection (b.source.of)->notempty and (b.of.target->intersection(b.target.of)->notempty Ensuite, nous définissons quatre contraintes qui assurent qu une instance du modèle est une instance valide du modèle dont elle devrait être une instance. Les deux premières contraintes expriment le fait que les objets de traitement et les interfaces sont associés par des gabarits définis dans le modèle. La troisième contrainte, exprime le fait que les objets de liaison sont associés par des rôles définis dans le modèle. Context s: system inv: Le modèle, dont s est une instance, comprend tous les gabarits dont les objets de s sont instances : s.of.computationalobjecttemplates->includesall(s.computationalobjects.of) Le modèle, dont s est une instance, inclut tous les gabarits d interface dont s.interfaces en sont instances : s.of.computationalinterfacetemplates->includesall(s.interfaces.of) Context s: system inv: 85

96 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL Le modèle dont s est une instance, comprend tous les rôles que les objets de liaison s.binder en sont instances : s.of.roles ->includesall(s.binders.of) La quatrième contrainte assure le respect des contraintes de cardinalité sur les objets de liaison : Context s: system inv: s.binder.of -> forall( r let binder_in_s be r.instances ->intersect ( s.binder ) in (r.upperbound -> notempty implies binder_in_s ->size <= r.upperbound ) and binder_in_s->size >= r.upperbound) Pour bien préciser la relation entre les interfaces de traitement, nous allons définir des contraintes OCL sur ces interfaces. En général, nous pouvons représenter les relations entre les gabarits d interfaces de traitements et les signatures correspondantes comme suit : La Signature d interface signal est une signature d'interface pour une interface signal comprenant un ensemble fini de gabarits d'action pour chacun des types de signal de l'interface. Chaque gabarit d'action comporte, pour l'objet qui l'instancie, le nom du signal, le nombre, les noms et les types de ses paramètres et une indication de causalité (initiateur ou répondeur, mais pas les deux à la fois) (RM-ODP, partie 3, clause ). Context: SignalInterface inv: self.type -> forall(t self.siganture->includes(set (t.actiontemplate)) ) and Forall( at : actiontemplate at.names ->includesall(self.signal.name)->union(self.parmeter.name) and at.types ->inclaudesall(self.parmeter.type)) and (self.causality =#Intiating xor self.causality =#Responding) La Signature d'interface opération est une signature d'interface pour une interface opération comprenant, pour l'objet qui l'instancie, un ensemble de signatures d'interrogation et d'annonce pour chacun des types d'opération de l'interface, ainsi qu'une indication de causalité (client ou serveur, mais pas les deux à la fois) pour l'interface dans son ensemble. Chaque signature d annonce correspond à un gabarit d'action comportant le nom de l'invocation et le nombre, les noms et les types de ses paramètres (RM-ODP, partie 3, clause ). Context OperationInterface inv: 86

97 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL self.signature -> includes (set(annoucementsignature)) -> union set (integrationsignature) self.annoucementsignature -> includes(set (actiontemplate)) and Forall( at : actiontemplate at.names ->includesall(self.invocation.name) ->union(self.parmeter.name) and at.types ->inclaudesall(self.parmeter.type)) Chaque signature d interrogation comprend un gabarit d'action avec les éléments suivants: - le nom de l'invocation ; - le nombre, les noms et les types de ses paramètres ; - un ensemble fini non vide de gabarits d'action, pour chacun des types de terminaison possibles de l'invocation et contenant le nom de la terminaison ainsi que le nombre, les noms et les types de ses paramètres. Context InterrogationInterface inv: self.signature -> includes (set(actiontemplate)) and Forall( at : actiontemplate at.names - >includesall(invocation.name) ->union(parmeter.name) and at.types ->inclaudesall(parmeter.type)) and forall (I:invoction exists( at :actiontemplate at.names ->includesall(i.termination.name)- >union(termination.parmeter.name) and at.types ->inclaudesall(termination.parmeter.type)) Context OperationInterface inv : Self.interogation -> includes(set(self.invocation)->union (self.termination) and Forall( I:invocation exists(t : termination self.i.possible_termination = T) La Signature d interface flux est une signature d'interface pour une interface flux comprenant un ensemble fini de gabarits d'action pour chacun des types de flux de l'interface flux. Chaque gabarit d'action d'un flux contient, en fonction de l'objet qui l'instancie, le nom du flux, le type d'informations du flux ainsi qu'une indication de causalité du flux (à savoir producteur ou consommateur, mais pas les deux à la fois) (RM-ODP, partie 3, clause ). Context FlowInterface inv : Self.type -> forall(t includes(self.signature -> set (t.actiontemplate)) ) and Forall( at : actiontemplate at.names ->includesall(self.flow.name) and at.types ->inclaudesall(self.inforamtion.type)) and (self.causality =#Producer xor self.causality =#Consumer) II.7. Conclusion Ce chapitre décrit notre travail pour développer les langages de points de vue ODP comme des langages de modélisation précis. En appliquant la connaissance et l expérience acquises 87

98 Chapitre II : Modélisation de la sémantique formelle des langages de points de vue ODP en UML et OCL dans les domaines de la conception orientée objet et les domaines sémantiques, nous avons montré comment rendre précises la sémantique des concepts de structure de base des langages entreprise et traitement. En adoptant l approche de méta-modélisation et celle de la sémantique dénotationnelle, nous avons défini des méta-modèles de la syntaxe abstraite et de la sémantique basés sur UML/OCL pour les concepts de base des langages de point de vue. Une stratégie de formalisation a été aussi développée dans l espoir d agir en tant que base pour le développement des sémantiques des autres aspects ODP et d intégrer de nouveaux systèmes de preuves pour ce standard. Les contraintes OCL qu on a défini peuvent être vérifiées afin qu elles soient toutes satisfaites et qu elles évitent l introduction d'incohérence dans les données. Nous visons à ce que ces contraintes puissent s'assurer que la génération du code en tienne compte, d où leur possible intégration à un outil de modélisation et de génération de code (outil CASE). Finalement, nous réitérons les facteurs qui ont motivé le travail présenté dans ce chapitre. Etant donné l intérêt d ODP en tant que cadre de spécification des systèmes répartis ouverts, il devient impératif qu il ait une sémantique précise. Ce n est que lorsqu on fournisse une telle sémantique qu on aura la certitude d aboutir à une technique de spécification rigoureuse. Ceci aura l effet de faciliter l utilisation et la compréhension d ODP aussi bien par les concepteurs que par les développeurs. 88

99 CHAPITRE III : UNE SEMANTIQUE DENOTATIONNELLE POUR UN SOUS- ENSEMBLE DE CONCEPTS DE COMPORTEMENT DU LANGAGE D ENTREPRISE III.1. Introduction Un système informatique est vu comme une collection d objets qui interagissent les uns avec les autres en échangeant des messages afin d accomplir un service. Une interaction est un comportement qui comprend un ensemble de messages échangés au sein d un groupe d objets pour atteindre un objectif. La sémantique d UML décrit parfaitement la structure d un système. Ce n est hélas pas le cas des aspects dynamiques (ou comportementaux) qui sont exprimés au moyen de différents diagrammes (séquence, collaboration, activité, états) sans que la cohérence entre eux puisse être assurée. Récemment, des groupes tels que puml [58] ont proposé une sémantique rigoureuse pour la version 2.0 d UML (à l aide du langage OCL) mais ces extensions n abordent toujours pas les aspects dynamiques. Dans le contexte d'un système ODP, le comportement est déterminé par l'ensemble de toutes les actions possibles auxquelles le système (agissant en tant qu'objet) ou l'un de ses objets constitutifs est susceptible de participer, ainsi que par l'ensemble des contraintes relatives aux conditions d'occurrence de ces actions. En langage d'entreprise, le comportement peut être exprimé en termes de rôles, de processus, de règles, de politiques ou de relations entre ces éléments. Les modèles de comportement jouent un rôle central dans la visualisation, la spécification, la construction et la documentation des aspects dynamiques d un système. Ces aspects comprennent le flot des messages dans le temps et le mouvement physique des composants à travers un réseau. Une spécification correcte d'un système permet d'éviter les problèmes potentiels qui pourraient être découverts au cours des essais coûteux et les phases de débogage. 89

100 Chapitre III : La représentation formelle du comportement d un système ODP L'un des moyens de spécifier le comportement d'un système est d'utiliser les méthodes formelles " Les méthodes formelles sont utilisées pour révéler l'ambiguïté, l'incomplétude, et l'incohérence dans un système "[59]. L utilisation des langages formels n est pas toujours une tache facile du moment qu elle exige une bonne connaissance de la notation formelle et une capacité de relier correctement les concepts de spécification formelle avec une exécution (ou domaine sémantique). C est la raison pour laquelle les développeurs utilisent souvent des langages semi formelles. Les spécifications formelles sont plus facilement implémentables. J. Wing dans [59] définit la spécification formelle des langues comme un triple <Syn, Sem, Sat>, où Syn est appelé le domaine syntaxique du langage, Sem est le domaine sémantique du langage et Sat est appelé "Satisfait la relation" qui définit la relation entre les termes syntaxiques et leurs significations sémantiques dans un domaine sémantique (voir Figure 21). Domaine Syntaxique Domaine Sémantique RM-ODP écrit en UML/OCL Contrainte Action Etat Temps t0 Automate à états finis a2 t1 Action t2 Etat Relation Satisfaite e2 a0 c2 UML- diagramme d activité Etat e1 c0 c1 Contrainte Action a1 Statecharts Action Garde Etat Figure 21 : Relation entre domaines syntaxique et sémantique des différentes méthodes formelles 90

101 Chapitre III : La représentation formelle du comportement d un système ODP Plusieurs domaines syntaxiques peuvent être utilisés pour décrire le même système. Par exemple, l UML peut être utilisé pour décrire les aspects structurels du système en utilisant les diagrammes de classe et les aspects comportementaux en utilisant les diagrammes d activités. En plus, ces diagrammes permettent de vérifier formellement certaines propriétés du système. Dans ce cas plusieurs domaines syntaxiques peuvent décrire le même élément d'une exécution du système. Ceci est illustré par la Figure 21, nous pouvons y voir que l'élément du système a1 (dans le domaine sémantique) est lié au concept d'action dans tous les domaines syntaxique. Le concepteur doit garantir une certaine forme de cohérence entre les domaines syntaxiques formels ou informels utilisés. Pour ce faire, la spécification d un système peut être décrite selon une certaine norme permettant de relier les différents concepts comportementaux de ces domaines. Le modèle RM-ODP est envisagé comme méta-modèle de spécification de comportement afin d assurer la cohérence et l uniformité des différentes spécifications des systèmes répartis ouverts. Cependant RM-ODP définit un domaine syntaxique générique, et ne donne pas de définitions précises de tous les concepts de modélisation. Dans ce cadre on 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-5] en particulier dans le langage d'entreprise en utilisant le langage de modélisation unifié UML couplé avec le langage de contraintes OCL. Dans la section 2, 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, dans la section 3, des définitions précises pour les contraintes de séquencement, de non-déterminisme et de la concurrence. Nous terminons, dans la section 4, 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. III.2. Concepts de modélisation de base du comportement ODP Nous allons considérer les concepts de modélisation de base nécessaires à la spécification du comportement. Pour spécifier le comportement des systèmes répartis, il existe différentes approches selon la stratégie utilisée et selon les aspects du comportement étudiés. Un système concurrent est représenté par le triplet : états, actions et l ensemble de comportements [66]. 91

102 Chapitre III : La représentation formelle du comportement d un système ODP Chaque comportement est modélisé comme une action et une séquence finie ou infinie des états interchangeables. Il y a généralement deux approches duales qui permettent de décrire cette séquence [60] : 1) «Modélisation des systèmes en décrivant leur ensemble d'actions et leurs comportements» ; 2) «Modélisation des systèmes en décrivant leur espace d état et leurs séquences possibles de changement d état». La dualité est due au fait qu'une action définit les changements d'état, et l'état qui se produit dans un changement des séquences d états, peut être interprété comme une représentation abstraite d actions [60]. Ces deux approches peuvent être vues comme une abstraction de l'approche générale basée sur RM-ODP. Dans ce qui suit, la dualité de ces deux approches peut être exprimée en proposant une sémantique précise, en UML/OCL, des concepts de base du comportement RM-ODP en l occurrence des concepts pris de la clause 8 «modélisation des concepts de base» de la partie 2 de RM-ODP. Ces concepts, appelés par Naumemko [61] propositions du premier ordre des éléments du modèle, sont : le comportement, l action, le temps, les contraintes et les états (voir Figure 22). Nous utilisons aussi les concepts (type, instance, pré-condition, post-condition) de la clause 9 "Spécification des concepts". Ces concepts de spécifications sont les propositions d ordre supérieur appliquées aux propositions de premier ordre des éléments du modèle. La définition du comportement fait appel à deux concepts de modélisation RM-ODP à savoir : action et contraintes. Les contraintes font partie du comportement du système et elles sont associées à l action [62]. Malheureusement, RM-ODP ne donne pas la définition précise aux contraintes de comportement. Il définit le comportement d un objet en tant que : "Une collection d'actions avec un ensemble de contraintes sur le moment où ils se produisent" (RM_ODP, partie 2, clause 8.6). Cette définition peut être formalisée en utilisant l OCL comme suit : Context m : modelbehavior inv: m.behavior->includesall(m.actions->union(m.constraints)) //Le comportement est un ensemble // d actions et de contraintes 92

103 Chapitre III : La représentation formelle du comportement d un système ODP Context c : constraint inv: c.constrained_act -> size > 0 //Une contrainte est définie pour une action Pour tout élément b du comportement, si b est une action et a au moins une contrainte, cette contrainte est un élément du comportement. De même quand b est une contrainte et a au moins une action, cette action est un élément du comportement. L expression OCL correspondant est la suivante : Context b :behavior inv : m.behavior->forall(b ((m.actions->includes(m.b) and b.constraints->notempty) implies m.behavior-> includes(b.constraints)) or ((m.constraints->includes(m.b) and b.actions->notempty) Implies m.behavior-> includes(b.actions)) Pour formaliser la définition de l action en UML/OCL, nous avons considéré deux autres concepts de modélisation : le temps et l'état. Nous pouvons voir comment ces concepts sont liés à la notion d'action en examinant leurs définitions. Le temps est présenté de la manière suivante (RM-ODP, partie 2, la clause 8.10) : Position dans le temps : Intervalle de temps de taille arbitraire pendant lequel une action peut se produire. instant_begin : chaque action a un point de temps quand elle commence instant_end : chaque action a un point de temps quand elle finit instant_bloc: chaque action peut avoir un point de temps quand elle se bloque. État : (d'un objet) (RM-ODP, partie 2, clause 8.7) : à un instant donné dans le temps, condition d'un objet qui détermine l'ensemble de toutes les séquences d'actions auxquelles l'objet peut prendre part. Par conséquent, la notion d'état est duelle au concept d'action. Ils ne peuvent pas être considérés séparément dans la modélisation. Cette définition montre que l'état dépend du temps et il est défini pour un objet pour lequel il est spécifié. L expression OCL correspondante est comme suit : Context t :time inv: b.actions->exists (t1,t2 t1 =action.instant_beging ->notempty and //pour chaque action, l instant de t2 =action.instant_end ->notempty and t1<> t2) and t1 < instant_bloc < t2 //début est différent de l instant de fin 93

104 Chapitre III : La représentation formelle du comportement d un système ODP Figure 22 : Concepts de base de modélisation de comportement III.3. Meta-modélisation du temps et des contraintes comportementales "Les contraintes de comportement peuvent par exemple comprendre des contraintes tempsréel, de séquencement, de non-déterminisme, ou de parallélisme " (RM-ODP, partie 2, clause 8.6). Dans ce travail, nous considérons les contraintes de séquencement, du non-déterminisme et de la concurrence. Le concept de contraintes de séquencement est lié à la notion de temps. III.3.1. Temps Le temps a deux rôles importants : - Il sert à des fins de synchronisation des actions inter et intra processus, de synchronisation d'un système avec ses utilisateurs et aussi pour la synchronisation des exigences de l utilisateur avec l exécution réelle d'un système ; - Il définit des séquences d'événements (séquences des actions). 94

105 Chapitre III : La représentation formelle du comportement d un système ODP Pour satisfaire le premier objectif, nous devons être capables de mesurer des intervalles de temps. Toutefois, une horloge précise pouvant être utilisée pour la mesure du temps n'existe qu en théorie [63]. Ainsi, la mesure du temps est toujours approximative. Dans ce cas, nous ne devons pas choisir des horloges précises, mais celles qui expliquent mieux les phénomènes à étudier. La simultanéité de deux événements ou de leur séquencement et l'égalité de deux durées devraient être définies de telle sorte que la formulation des lois physiques soit la plus simple possible [63]. Par exemple, pour la synchronisation des actions, des horloges internes de l ordinateur peuvent être utilisées et pour la synchronisation des besoins des utilisateurs, des horloges partagées qui mesurent le temps en secondes, minutes et heures peuvent être utilisées. Nous considérons le deuxième rôle du temps. Selon [63], nous pouvons construire une sorte d horloge qui peut être utilisé pour la spécification des séquences d'actions. RM-ODP confirme cette idée en disant que "une position dans le temps et dans l'espace est définie relativement à un système de coordonnées approprié" (RM_ODP, partie 2, la clause 8.10). Le système de coordonnées de temps définit une horloge utilisée pour la modélisation de systèmes. Nous définissons un système de coordonnées comme un ensemble d'événements en temps. Chaque événement peut être utilisé pour spécifier le début ou la fin d'une action. Un système de coordonnées de temps doit avoir les propriétés fondamentales suivantes : - Le temps est toujours croissant. Cela signifie que le temps ne peut pas avoir des cycles ; - Le temps est toujours relatif. Tout moment de temps est définie par rapport à d'autres moments de temps (suivant, précédent ou qui ne sont pas liées). Cela correspond à l'ordre partiel défini pour l'ensemble des événements temporels. Nous utilisons le langage de modélisation UML et OCL pour définir le temps : le temps est définie comme un ensemble d'événements en temps. Ces événements doivent être définis en relation avec d autres événements de temps (ordre partiel) : nte : définit les événements de temps les plus proches d un événement temporel donné [65]. 95

106 Chapitre III : La représentation formelle du comportement d un système ODP fte : définit l'ensemble des événements de temps qui suivent ou la fermeture transitive d un événement de temps t sur la relation nte de manière à garantir que les séquences d'événement de temps n'ont pas de boucles. bte : définit l ensemble des événements de temps qui précèdent un événement temporel donné ;pour gérer l historisation du comportement d un système. Ainsi, nous définissons l invariant suivant en OCL (Balouki et al.2009) [55] : Context t : time inv : Time->forAll(t:Time (t.nte->isempty implies t.fte->isempty) and (t.nte->notempty and t.fte->isempty implies t.fte =t.nte) and (t.nte->notempty and t.fte->notempty implies t.fte-> includes(t.nte.fte->union(t.nte)) and t. fte->exludes(t)). and ( t.nte->notempty implies t.bte->notempty) Cette définition du temps est utilisée dans la section suivante pour définir les contraintes de séquencement. III.3.2. contraintes Comportementales Nous définissons le comportement comme un automate à états finis (FSA). Par exemple, la Figure 23 montre la spécification des contraintes de séquencement et de non déterminisme. Le système est spécifié en utilisant les contraintes de non-déterminisme : l'état S1 a un choix non-déterministe entre les actions a. S1 a1 a2 S2 S3 S1 a a S2 S3 an Sn a Sn (a) (b) Figure 23 : (a) les contraintes déterministes séquentielles (b) les contraintes non déterministes séquentielles 96

107 Chapitre III : La représentation formelle du comportement d un système ODP Basé sur RM-ODP, la définition de comportement doit établir un lien entre un ensemble d'actions avec les contraintes correspondantes. Par la suite nous donnons une définition précise des contraintes de séquencement, de concurrence et de non-déterminisme. III Contraintes de séquencement Chaque contrainte de séquencement devrait avoir les propriétés suivantes [65] : - Elle est définie entre deux actions ou plus ; - Le séquencement doit garantir la terminaison d'une action avant le début de celle qui suit. Puisque RM-ODP emploie la notion des intervalles de temps cela signifie que nous devons garantir qu'un intervalle de temps suit l'autre : Context SC :constraintseq inv : //pour/chaque contrainte de séquencement sc Behavior.actions-> forall(a1,a2 a1<> a2 and //il existe deux actions différentes a1 et a2 a1.constraints->includes(sc) and a2.constraints->includes(sc) and //sc est défini entre a1 et a2 ((a1.instant_end.fte->includes(a2.instant_begin) or //a1 avant a2 ou (a2.instant_end.fte->includes(a1.instant_begin) ) //a2 avant a1 III Contraintes de la concurrence Deux actions sont dites exécutables en parallèle si et seulement si elles peuvent être exécutées simultanément dans n'importe quel ordre (l'intersection de leurs intervalles d'exécution peut être quelconque). Ces actions n'ont aucune influence entre elles. L'aspect temporel est ici lié de manière intrinsèque à la notion de parallélisme. La Figure 24 montre des spécifications qui ont des contraintes de la concurrence. Nous pouvons vérifier que le système est spécifié en utilisant des contraintes de la concurrence en regardant l'état a1 qui a un choix simultané entre deux actions a2 et a3. a1 cc a2 a3 Figure 24 : Diagramme RM-ODP - Contraintes de la concurrence 97

108 Chapitre III : La représentation formelle du comportement d un système ODP La contrainte de concurrence cc est définie entre une action a1, deux actions internes a2 et a3, «a1 est avant a2» et «a1 est avant a3» : Context cc : constraintconc inv : Behavior.actions-> forall(a1 :Action,a2,a3 : internalaction (a1 <> a2) and (a2 <> a3) and (a3 <> a1) and a1.constraints->includes(cc) and a2.constraints->includes(cc) and a3.constraints->includes(cc) and a1.instant_end.fte-> includes(a2.instant_begin) and a1.instant_end.fte-> includes(a3.instant_begin)) III Contraintes de non-déterminisme Afin de définir les contraintes de non-déterminisme, nous considérons la définition suivante donnée dans [60]: «Un système est appelé non-déterministe s il est susceptible de montrer certain nombre de comportement différent, où le choix du comportement ne peut pas être influencé par son environnement». Cela signifie que les contraintes de non-déterminisme devraient être définies entre trois actions au minimum. La première action devrait précéder les deux actions suivantes et ces actions doivent être internes (voir Figure 25). a2 a1 c a3 Figure 25 : Diagramme RM-ODP - Exemple de contraintes de non-déterminisme Context ndc: NonDetermConstraints inv : Behavior.actions-> forall(a1 :Action,a2,a3 : internalaction (a1 <> a2) and (a2 <> a3) and (a3 <> a1) and a1.constraints->includes(ndc) and a2.constraints->includes(ndc) and a3.constraints->includes(ndc) and a1.instant_end.fte-> includes( a2.instant_begin) or a1.instant_end.fte-> includes(a3.instant_begin)). 98

109 Chapitre III : La représentation formelle du comportement d un système ODP Nous notons que le choix du comportement ne devrait pas être influencé par l'environnement. Les actions a2 et a3 doivent être des actions internes (pas d'interactions). Sinon, le choix entre les actions serait le choix de l'environnement. III.4. Les politiques de comportement dans le Langage Entreprise RM-ODP Une spécification d'entreprise du système ODP est une description de ce système et des parties correspondantes de son environnement. La spécification d'entreprise est centrée sur la portée et sur l'objectif de ce système ainsi que sur les politiques qui s'y appliquent dans le contexte de son environnement. Elle comprend la communauté, les rôles joués par le système ODP et par d'autres objets d'entreprise dans cette communauté, ainsi que les processus auxquels participent le système ODP et les objets d'entreprise contenus dans son environnement. Une telle spécification peut indiquer le comportement collectif de soussystèmes du système ODP spécifiés séparément et en inter fonctionnement. Une politique est un ensemble de règles relatives à un objectif particulier. Une règle peut être exprimée sous la forme d une autorisation, d'une obligation, d'une permission ou d'une interdiction. Une politique peut être spécifiée parmi un ensemble de politiques laquelle doit être appliquée dans certaines circonstances. Une spécification d'entreprise peut comprendre un mécanisme permettant de déterminer ou modifier de temps à autre la politique à appliquer dans certaines circonstances, parmi un ensemble de politiques. Plusieurs auteurs ont proposé différents langages de spécification formelle pour exprimer les politiques ODP (par exemple Object-Z) mais qui n'ont pas une syntaxe graphique. Nous proposons la modélisation des concepts du comportement de point de vue entreprise à l'aide des diagrammes UML standards et des mécanismes de modélisation de comportement, puisque les politiques contraignent le comportement des rôles. Context s :System inv : //le comportement comprend les rôles ou les processus et les politiques s.behavior->(includesall(s.roles ) or includesall(s.process )) ->union(s.roles.policy)) Context o : object inv : s.behavior-> includes(o.behavior.roles)>-union(o.behavior.roles.policy) 99

110 Chapitre III : La représentation formelle du comportement d un système ODP Dans ce qui suit, nous proposons une formalisation des concepts de la politique d'un système de traitement ODP. La politique est définie comme une combinaison d actions d'établissement, de terminaison et d'exécution. La Figure 26 présente le méta-modèle d'uml 2.0, pour les concepts de comportement et de politiques. Les actions d établissement sont définies par des événements qui déclenchent la communication ou le processus : Establishing_act: ensemble d'actions qui initialisent un comportement Terminating_act: ensemble d'actions qui terminent certains processus Executing_act: ensemble d'actions qui exécutent un comportement ou un processus Context P : Policy inv : P.specified_by -> size > 0 //chaque politique est spécifiée par au moins une action //(établissement, terminaison ou exécution) III.4.1. Obligation Pour modéliser l obligation, nous avons besoin de préciser les actions que le système est forcé d'entreprendre dans le cadre de son comportement. En fait, une obligation est une prescription d'un comportement particulier et nécessaire (RM-ODP, partie 2, clause ). Le comportement contraint par la politique d obligation doit être établit par l action d établissement (Establishing_act), exécuté par l action Executing_act et terminé par l action de terminaison (Terminating_act) [55]. Context po :policyobligation inv: b.policy->includes(po) implies (Behavior.actions-> (includes(self.establishing_act) and (Behavior.actions-> includes(self.terminating_act ) and (Behavior.actions-> includes(self.executin_act ) III.4.2. Permission La permission est une prescription qui permet à un comportement particulier de se produire. Une permission équivaut au fait qu'il n'est pas obligatoire que le comportement ne se produise pas (RM-ODP, partie 2, clause ). Les permissions permettent les transitions d'état. Par conséquent, la permission est exprimée par une action Establishing_act qui détermine le 100

111 Chapitre III : La représentation formelle du comportement d un système ODP scénario de l'action(s) autorisée et de leur (s) participants, alors que les effets d une telle action sont décrits par une action Terminating_act. Context pp :policypermission inv : b.policy->includes(pp) implies (Behavior.actions-> (includes(self.establishing_act) or (Behavior.actions-> includes(self.terminating_act )) III.4.3. Interdiction Une interdiction est une prescription stipulant qu'un comportement particulier ne doit pas se manifester. Une interdiction équivaut au fait qu'il est obligatoire que le comportement ne se présente pas (RM-ODP, partie 2, clause ). Les interdictions peuvent être traitées de deux manières différentes selon leurs natures : - La première manière est de les exprimer en tant que déclarations conditionnelles, interdisant explicitement l'action Establishing_act. De cette façon, le système empêchera automatiquement l'action interdite pour se produire ; - La deuxième manière est de traiter les prohibitions en employant les règles de surveillance, qui détectent l'occurrence de l'action interdite et exécutent l'action Terminating_act, si possible. Context ppr :policy Prohibition inv : b.policy->includes(ppr) implies (Behavior.actions-> (excludes(self.establishing_act) and (Behavior.actions->excludes(self.Executing_act) and includes(self.terminating_act)) 101

112 Chapitre III : La représentation formelle du comportement d un système ODP Figure 26 : Un méta-modèle pour des concepts de comportement et de politique [54] III.5. Conclusion Dans ce chapitre, nous avons défini avec précision les concepts de comportement de base des systèmes ODP, en l occurrence le temps et l action, par l ajout des contraintes de séquencement, de non-déterminisme et de la concurrence. Nous avons aussi défini des politiques qui peuvent être utilisées pour identifier la spécification des contraintes sur le comportement du système ODP en se basant sur UML /OCL. Ainsi, nous envisageons, pour assurer l aspect vérification formelle, l utilisation de la théorie des automates d états comme les réseaux de Petri Objets/Hiérarchiques ou de Promela. Ces techniques ont prouvé qu il était possible d assembler de manière cohérente l information répartie dans les différents diagrammes de comportement d UML à des fins de vérification formelle, notamment par model checking, résultat qu on voit possible d étendre aux aspects comportementaux dans les différents langages de point de vue ODP. 102

113 CHAPITRE IV : UTILISATION DE BPEL POUR LES CONCEPTS COMPORTEMENTAUX DU LANGAGE D ENTREPRISE ODP IV.1. Introduction Dans le chapitre précédent, nous avons défini avec précision les concepts de comportement de base des systèmes ODP. L objectif de ce chapitre est de décrire la méthodologie de modélisation de comportement du langage d'entreprise ODP par la création d un profile UML spécifique. Par ailleurs le modèle de référence est un modèle indépendant de toute plate-forme, tel que décrit dans le MDA de l OMG [OMG 01], offrant ainsi une plus grande productivité, une meilleure qualité, et une transparence vis-à-vis des changements possibles de la technologie. Ce chapitre est structuré de la manière suivante : la section 2 présente, le langage BPEL. La section 3 décrit la modélisation du comportement du système par un profil UML spécifique. Dans la section 4, nous définissons un mapping entre les concepts du comportement du langage d'entreprise et les concepts de BPEL tout en présentant la structure et la syntaxe d'un processus du comportement BPEL. Ainsi, la transformation des modèles UML du comportement vers les BPEL correspondants va être assurée par l utilisation de l outil Rational rose. IV.2. Langage d exécution des processus métiers IV.2.1. Introduction au BPM : Business Process Management La conception et l exécution des processus métiers de l entreprise nécessitent la collaboration d utilisateurs ayant des profils différents et manipulent des concepts et des outils souvent hétérogènes (voir Figure 27) : - Les équipes méthodes précisent un formalisme pour la modélisation des processus métiers, et peuvent définir des processus normalisés soit d une manière verticale 103

114 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP (spécifique à un corps de métier), ou horizontale (indépendante du corps de métier de l entreprise) ; - Les décideurs et les analystes métiers définissent les processus métiers de haut niveau, les cas d utilisation et les scénarios détaillés, en s appuyant sur les recommandations des équipes méthode ; - Les équipes techniques traduisent ces processus en termes d applications, services et intégration de l existant, tout en capitalisant sur les applications du système d information [67]. Figure 27 : Collaboration entre différents acteurs Cette hétérogénéité rend la collaboration entre les différents acteurs assez difficile. Tout d abord, ces acteurs manipulent des concepts différents : un diagramme UML a par exemple peu de signification pour un analyste métier. De plus, leurs outils ne fournissent pas les moyens de cette collaboration : pour implémenter un processus métier modélisé avec Aris, il est nécessaire de le modéliser à nouveau sous Rational, pour pouvoir générer du code de manière plus ou moins efficace lors de la phase d implémentation. Actuellement, que ce soit dans les phases de modélisation métier et technique, ou d implémentation, des outils de conception sont rarement utilisés de bout en bout, de la modélisation à l exécution. On retrouve un fossé entre les phases de spécification et d implémentation, même dans la partie technique. De ce fait, il est difficile pour les décideurs d avoir une vue claire sur les besoins auxquels répondent les applications du système d information, et donc de justifier les nouveaux investissements IT. La maîtrise des processus est actuellement dans les mains des techniques, pas des personnes qui les définissent. 104

115 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP L objectif de BPM (Business Process Management) est de permettre aux décideurs, analystes métiers, équipes fonctionnelles et équipes techniques de collaborer pour la définition et la modélisation des processus métiers via un seul outil fédérateur. Un des objectifs clés du BPM est de capitaliser sur les applications du système d information : le mot d ordre est la réutilisabilité. La réutilisabilité est rendue effectivement possible, tant au niveau technique (connecteurs, règles techniques, transformation de données) que fonctionnel (réutilisation d un processus de facturation dans un processus de gestion de bons de commande par exemple). Un processus métier est défini généralement selon trois niveaux : - le niveau métier : le niveau haut de la vue métier du processus, définissant ses principales étapes et l impact sur l organisation de l entreprise. Ce niveau est défini par les décideurs, et les équipes méthodes ; - le niveau fonctionnel : formalisation des interactions entre les participants fonctionnels du processus où sont formalisées les règles métiers conditionnant son déroulement. Ce niveau est modélisé par les équipes fonctionnelles ; - le niveau technique : établit le lien entre les activités (modélisés dans le niveau fonctionnel) et les applications du SI. Ce niveau est réalisé par les architectes et les équipes techniques de l entreprise. Pour la prise en compte de l analyse et de la modélisation des processus métiers, l OMG a développé son approche qui s inscrit dans l architecture générale de modélisation sous le nom de MDA (Model Driven Architecture). La MDA est un cadre de définition et de transformation des méta-modèles, de spécification des notations associées ainsi que d échange des modèles et de leurs diagrammes sous un format normalisé (XMI). L OMG a lancé l initiative de spécification des processus métiers BPDM qui s appuie sur les modèles d activités d UML 2.0 en prenant en charge les différents niveaux d analyse des processus : implémentation, organisation et stratégie. Ainsi la BPMI a publié la spécification BPMN (Business Process Modeling Notation) 1.0, qui présente une avancée indéniable dans la formulation graphique des processus. Cependant, le véritable défi se situe dans la capacité des processus, dont la description a été formalisée par les acteurs métier, de déboucher directement sur la génération de langages 105

116 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP exécutables par des applicatifs informatiques et des services web. Le langage BPEL4WS 1 est une spécification de standards pour l orchestration des web services annoncée en août 2002 par BEA, IBM et Microsoft. IV.2.2. Langage BPEL Le BPEL est la représentation XML d un processus exécutable, qui peut être déployée sur n importe quel moteur de processus métier. Ce langage est construit en se basant sur le WSFL (Web Services Flow Language) d'ibm et le XLANG (Web Services for Business Process Design) de Microsoft. Il fournit un langage de spécification des processus métiers et des protocoles de leur interaction [68]. Il combine les dispositifs d'un langage de processus structuré par bloc (XLANG) avec ceux d'un langage de processus graphique (WSFL). BPEL est prévu pour décrire un processus de métiers de deux manières différentes [69] : - un processus abstrait est un protocole de métiers spécifiant le comportement d'échange de message entre différentes parties, sans préciser leur comportement interne ; - un processus exécutable spécifie l'ordre d'exécution entre un certain nombre d'activités, les partenaires impliqués, le message échangé entre ces partenaires et les mécanismes de gestion d erreur et d'exception. La composition d un service au niveau BPEL est décrite en termes de processus. Chaque élément du processus est appelé une activité. BPEL fournit deux genres d'activités [69] : - Les activités primitives effectuent des opérations simples comme réception (attendre un message d'un partenaire externe), réponse (répondre un message d un partenaire), appel (appeler un partenaire), assignation (copier une valeur d'un endroit à l'autre), rejet (générer une erreur), terminaison (arrêter l'instance de processus entier), attente (attendre un certain temps) et vide (ne fait rien) ; - les activités structurées sont employées pour définir l'ordre des activités primitives. Elles peuvent résider avec d'autres activités structurées. Ces activités prennent la forme de : séquence (collection d'activités à exécuter séquentiellement), flux 1 Business Process Execution Language for Web Services, qui remplace BPML Business Process Modeling Langage, devenu ensuite BPEL Business Process Execution Langage 106

117 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP (indiquant une ou plusieurs activités à exécuter concurremment), while (la boucle while), commutateur (choisit un chemin de contrôle à partir d'un ensemble de choix) et sélection (blocage et attente d un message approprié). La séquence, le flux, le commutateur, la sélection et la construction «while» fournissent les moyens d'exprimer des dépendances de flux structurées. En plus de ces constructions, BPEL en fournit une autre appelée «liens de contrôle» ainsi que les notions associées «join condition» et «transition condition», qui supportent la définition de la priorité, la synchronisation et les dépendances conditionnelles des activités structurées. Un lien de contrôle entre les activités A et B indique que B ne peut pas commencer avant que A ait terminé ou A ait sauté. D'ailleurs, B peut seulement être exécuté si ses associés «join condition» ont la valeur «True», sinon B sera sauté. Une activité X propage une valeur positive le long d'un lien sortant L si et seulement si X était exécutée et la 'transition condition' associé à L a la valeur «True». Les 'transition condition' sont des expressions booléennes au-dessus des variables de processus. Le processus par lequel des valeurs positives et négatives sont propagées le long des liens de contrôle, causant l exécution ou le saut des activités, est nommé DPE (dead path elimination). La Figure 28 ci-dessous est le méta modèle BPEL représenté par un diagramme de classe UML, qui décrit de manière précise tous les éléments de modélisation ( les concepts véhiculés et manipulés par le langage), leur définition et le sens de leur d utilisation. A partir de ce schéma, il devient possible de faire un mapping entre les concepts du comportement du langage d entreprise et ceux du BPEL. 107

118 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP Figure 28 : Méta-modèle du langage BPEL [56] IV.3. La fonction de courtage L'une des principales caractéristiques d'odp est la fonction de courtage (Trading) [1,2,4]. Son rôle est de permettre l'établissement de contact entre objets, la négociation de l'utilisation des interfaces des services offerts ainsi que l'invocation d'opérations. Cette fonction est assurée par des objets de type trader. Un trader est un objet système à travers lequel d'autres objets font connaître leurs services disponibles et satisfont à leurs besoins. Les services disponibles dans les réseaux sont les objets d'information pour le système de courtage. Donc les services sont les descriptions des interfaces des objets de traitement. Un service est décrit comme étant une interface d'un objet de traitement. On a ainsi deux services offerts par un trader : 1) exporter : il s'agit de rendre un service public. Pour cela on donne au trader une description de l'interface de ce service (type et contexte) ainsi qu'une référence où l'on trouvera l'interface. 2) importer : l'objectif est l'inverse du service précédent. On cherche à utiliser un service et donc à recevoir du trader une référence d'interface du service requis. Le schéma ci-dessous décrit ce mécanisme de trading. 108

119 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP T 2 1 C 3 S T : Trader 1 : Export C: Client 2 : Import S: Server 3 : Service Figure 29 : La fonction de Trading dans ODP Dans ce schéma, on voit que la fonction de trading modifie le schéma habituel du modèle Client-serveur. En effet, dans un premier temps, l'objet exportateur (serveur) délivre au trader une description du service offert ainsi que la localisation de l'interface à travers laquelle le service est disponible (étape 1). Ensuite, Un objet recherchant (client) un service interagit avec le trader en lui exprimant son besoin, c'est à dire en découvrant les caractéristiques du service désiré (étape 2), le serveur lui donne une référence où le client pourra trouver l'interface du serveur (étape 3). L'avantage de cette façon de procéder est d'offrir une méthode incrémentale, dynamique et ouverte pour introduire et découvrir des services dans un système distribué. De plus, elle offre un haut degré de transparence pour l'interaction entre objets. La fonction de trading obéit à des règles, notamment l obligation de décrire un service offert d'une manière spécifique. L'architecture ODP offre la possibilité à des traders de travailler ensemble. Ainsi, la fonction de courtage doit être développée suivant les points de vues d'odp pour pouvoir assurer l'interfonctionnement et la portabilité de traders. C'est pourquoi les standards pour les fonctions ODP et leur composition sont définis comme des standards ODP. IV.4. Spécification de la fonction de courtage du point de vue entreprise La spécification d'entreprise identifie les objectifs de la fonction de courtage et la politique qui gouverne ses activités. Elle définit le concept de communauté de courtage qui est composée d'objets ayant différents rôles, par exemple courtier, importateur et exportateur. Les activités d'une communauté sont l'exportation et l'importation de services. Elles sont gouvernées par la politique de courtage. Cette dernière est un ensemble de règles répondant à 109

120 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP un objectif particulier. Ces règles édictent un guide pour la prise de décisions devant satisfaire les objectifs de la communauté. Les membres de la communauté doivent s'y conformer, de même que le courtier pour qui ces règles contraignent le comportement, mais de façon cohérente avec l'objectif commun [70]. Les politiques de courtage incluent des politiques d'exportation (comme l'obligation pour une offre de service d'être décrite d'une manière spécifique), des politiques d'importation (comme la permission de propager l'importation de services à plusieurs courtiers en interfonctionnement); des politiques d'arbitrage pour résoudre les conflits apparaissant pendant les activités de courtage, ou encore des politiques de recherche pour guider la recherche d'offres de service dans le système de courtage. En fait à chaque cas d'utilisation est associé la politique de l'utilisation de l'objet. A chaque objectif est associée une politique. IV.5. Profil UML pour des processus automatisés de comportement L existence de modèles de composants technologiques dont les plus connus sont CCM (CORBA Component Model) de l OMG, EJB de Sun ainsi que COM/DCOM et.net de Microsoft a donné naissance à l extension du méta-modèle d UML 2.X. et à la création de profil. Pour l OMG, un profil est un ensemble de stéréotypes, de valeurs marquées (tagged-value) et de contraintes. Ces éléments permettant d adapter dynamiquement un méta-modèle à un domaine d'intérêt particulier. C est dans ce contexte que nous avons développé un nouveau profil UML pour la modélisation du comportement dans le langage d'entreprise des systèmes ODP. Le profil proposé est basé essentiellement sur la notion de stéréotype. En effet, le but ultime des stéréotypes est de combler les manques d UML par l extension de la notation à des points spécifiques. Le développeur peut créer des stéréotypes et les personnaliser en leur donnant un sens clair et précis à l aide du langage OCL[71]. Nous présentons ci-dessous un profil UML pratique, qui supporte la modélisation d un ensemble de constructions sémantiques du comportement dans le langage d'entreprise, tout en donnant leurs correspondants en langage d'exécution de processus des métiers BPEL (voir le Tableau 1, Balouki et al.2008) [56]. 110

121 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP Behavior Concepts Process_Ev Action Actor Policy Objective <<receive>>, <<reply>>, <<invoke>> actions Profile Construct << process>> class Activity graph on a <<process>> class <<partner>> class <<process>> class attributes Hierarchical structure and control flow <<receive>>, <<reply>>, <<invoke>> activities Tableau 1 : Mapping entre concepts de comportement et constructions UML Nous introduisons un sous-ensemble du profil UML à travers un exemple qui définit un processus simple de comportement. Il est résumé comme suit : «ODP vise à fournir la répartition et la transparence d exploitation de services sur des environnements hétérogènes. Afin d'utiliser les services, les utilisateurs doivent être au courant des fournisseurs de services potentiels et capables d'y accéder. Étant donné que les sites et les applications dans les systèmes répartis sont susceptibles de changer fréquemment, Il est avantageux de permettre une liaison entre les utilisateurs de services et les fournisseurs. Ce besoin a nécessité l implémentation d un composant qui doit être en mesure de trouver des fournisseurs de services dynamiquement. La fonction de courtage d ODP prévoit la négociation de cette dynamique de sélection de fournisseurs de services au moment de l'exécution». Les processus BPEL sont de type «stateful» et possèdent des instances, ainsi dans BPEL ce scénario est implémenté comme une instance du processus de comportement. Dans le profil UML, un processus est représenté comme classe avec le stéréotype <<Process>>. Les attributs de la classe correspondent à l'état du processus (variables dans BPEL 1.1). La classe UML représentant le processus de comportement est illustrée dans la Figure

122 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP Figure 30 : Une classe UML modélise le processus du comportement BPEL [56] Le comportement de la classe est décrit en utilisant un diagramme d'activité. La Figure 31 représente le diagramme d'activité du processus de comportement. Les activités, telle que invoke, sont présentées par des rectangles avec les coins arrondis. Les actions à exécuter sont illustrées sous forme de conditions d'entrée à l'activité. Par exemple, la contrainte d'action (une variable) est placée au résultat du service de contrôle. Les acteurs avec lesquels le processus communique sont représentés par les répartitions UML (également connues sous le nom swimlanes) : Trader, Client et Serveur. Les activités qui impliquent un message, envoient ou reçoivent l'opération à un acteur apparaissant dans la répartition correspondante. Les flèches indiquent l'ordre dans lequel le processus exécute les activités. L activité d affectation n'est pas dans un «swimlane»; elle n exige pas un service externe. Elle décrit seulement une action interne au processus. 112

123 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP Trader <<receive>> receive Entry/objective(request) ImportRequest/condition= True/False ImportReplies/condition= True/False Client <<invoke>> invoke Entry/serviceinvocation :=check(request) ServiceInvoke ExportRequest/condition= True/False ServiceReplay <<replay>> replay Entry/objective():=objectiveinfo Server <<replay>> replay Entry/servicereplies :=objectiveinfo Figure 31 : Un diagramme d'activité du processus de comportement [56] L exécution du processus se termine par l envoi d une réponse de l'activité replay au trader. Chaque activité a un nom descriptif et une action d'entrée détaillant la tâche effectuée par l'activité. IV.6. Transformation au BPEL IV.6.1. D'UML à BPEL Le profil UML pour les processus de comportement automatisés montre comment on peut générer des artéfacts BPEL exécutables à partir des modèles UML [71]. Le mapping entre profil UML développé et concepts BPEL est illustré dans le Tableau 2 : 113

124 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP Profile Construct BPEL Concept << process>> class BPEL process definition Activity graph on a <<process>> class <<process>> class attributes Hierarchical structure and control flow <<receive>>, <<reply>>, <<invoke>>activities BPEL activity hierarchy BPEL variables BPEL sequence and flow activities BPEL activities Tableau 2 : Mapping entre constructions UML et concepts BPEL [71] IV.6.2. Exécution du processus de comportement BPEL est une représentation XML d'un processus exécutable qui peut être déployé sur n'importe quel moteur de processus. L'élément atomique d'un processus BPEL est l «activité», qui peut être l'envoi d'un message, la réception d'un message, l'appel d'une opération (envoi d'un message, tentative d'une réponse), ou une transformation des données. Selon le BPEL, les activités réalisées dans le cadre de l'exécution du processus de comportement sont définies en XML. Nous présentons ci-dessous la structure et la syntaxe de processus de comportement proposé (Ev_behavior) : < Ev_behavior > < actors /> definition of the actors (roles) <containers/> definition of the containers of the data <transitioncondition> <policies /> A set of rules related to a behavior. </transitioncondition> <sequence/> <receive /> reception of a request of process <assign /> transformation of the data <invoke /> call of an process <assign /> transformation of the data <reply /> sending of an answer to the process </sequence> </Ev_behavior > <process > < partners /> definition of the partners (actions) <containers/> definition of the containers of the data 114

125 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP <sequence /> <receive /> reception of a request <assign /> transformation of the data <invoke /> call of an action <assign /> transformation of the data <reply /> sending of an answer </sequence> </process> <policies> name = "namepolicy" <process name ="process"/> < actors name = "actor"/> <choice > <policy type ="obligations"/> <policy type ="permissions"/> <policy type ="prohibitions"/> <policy type ="authorizations"/> </choice > </policies> Une version du document BPEL généré de l'exemple du processus de comportement est donnée dans le listing 1. Listing 1. Extrait du Listing BPEL <process name="behaviorprocess"...> <variables> <variable name="request" messagetype="objectivedef:actioninformationmessage"/> <variable name="action_constraint" messagetype="asns: action_constraintmessage"/>... </variables>... <flow> <receive name="receive1" partner="actor1" porttype="apns:behaviorprocesspt" operation="objective" variable="request" createinstance="yes"> <source linkname="receive-to-action2" transitioncondition= "bpws:getvariabledata('request', 'condition') = true"/> <source linkname="receive-to-action3" transitioncondition= 115

126 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP "bpws:getvariabledata('request', 'condition)=false"/> </receive> <invoke name="invokeactor2" partner="actor2" porttype="asns:actionconstraint" operation="check" inputvariable="request" outputvariable="action_constraint"> <target linkname="receive-to-action3"/> <source linkname="action3-to-setmessage" transitioncondition= "bpws:getvariabledata('action_constraint ', 'check')='true'"/> <source linkname="action3-to-action2" transitioncondition= "bpws:getvariabledata('action_constraint ', 'check')!='true'"/> </invoke> <assign name="assign"> <target linkname="action2-to-setmessage"/> <source linkname="setmessage-to-reply"/> <copy> <from expression="'yes'"/> <to variable="objectiveinfo" part="accept"/> </copy> </assign>... <reply name="reply" partner="actor1" porttype="apns:behaviorprocesspt" operation="approve" variable="objectiveinfo"> <target linkname="setmessage-to-reply"/> <target linkname="objective-to-reply"/> </reply> </flow> </process> IV.6.3. Démarche de transformation d UML au BPEL Nous présentons alors la démarche technique de transformation de modèles, entre les langages UML et BPEL, pour l automatisation du processus de comportement. Cette technique est basée sur l idée qu un modèle de processus, développé dans un outil UML tel que IBM Rational's XDE or Rose, peut être convertit en fichiers BPEL et WSDL nécessaires pour l implémentation de ce processus. La transformation est alors conduite selon les 116

127 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP éléments constituant le profil. Elle préconise l utilisation de deux types de fichiers qui sont les modèles UML qui peuvent être ouverts et modifiés avec les outils Rose ou XDE, et les fichiers XML contenant la version XMI des modèles UML, qui sont exportés par Rose ou XDE [71]. La Figure 32 fait appel à un diagramme d'activité UML pour présenter le processus global de transformation des fichiers; les rectangles représentent les artefacts (généralement des fichiers), tandis que les éllipses représentent une action ou une activité. Notre démarche repose sur les étapes suivantes : - la construction et l'exportation du modèle UML à XMI (à l aide de Rose ou XDE) ; - génération du BPEL, des fichiers comportement, et des fichiers XSD ; - déploiement et exécution de ces derniers sur le moteur BPEL. Requirements Analysis Functional specification Design Implementation Figure 32 : Développement d un processus IV.6.4. Implémentation du processus de comportement Nous présentons maintenant la mise en œuvre expérimentale du processus Ev_Behavior : IV La construction et l exportation du modèle Les fichiers UML (.Mdl ou.mdx) qui spécifient la fonction Trader d ODP peuvent être manipulés par les outils Rose ou XDE. 117

128 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP Figure 33 : Modélisation et Exportation avec XDE Le modèle UML développé peut être exporté vers XMI, à partir du menu Fichier -> Exporter, par la sélection de l option Exportation XMI, comme le montre la figure 33. IV Génération du BPEL et WSDL Nous avons utilisé WebSphere Application Developer pour créer un projet Java et importer le fichier XMI déjà crée dans la section précédente. Ensuite, nous avons choisi l option "Générer BPEL d UML" pour sélectionner le fichier XMI comme montré sur la Figure

129 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP Figure 34 : Transformation du fichier XMI Après avoir cliqué sur «Terminer», un certain nombre de fichiers apparaît dans le projet, y compris les principaux BPEL et des fichiers WSDL, en l occurrence les fichiers WSDL concernant les services du client et du serveur et les définitions de données. À ce stade, les fichiers générés devraient être prêts à se déployer en utilisant le serveur d Applications Web Sphère. Le panneau de déploiement BPEL4WS nous permet d entrer le fichier WSDL qui correspond aux principaux services (server.wsdl) et le fichier BPEL, (Ev_behavior.bpel) dans les champs respectifs, comme le montre la Figure 35 : 119

130 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP Figure 35 : Déploiement du processus Après avoir cliqué sur «Continuer le déploiement», on insère les fichiers requis par les différents rôles dans le processus. Dans cet exemple il y a deux rôles : serveur et client (figure 36). Figure 36 : Déploiement des services IV.7. Conclusion Nous avons vu qu en langage d'entreprise, le comportement peut être exprimé en termes de rôles, de processus, de règles, de politiques ou de relations entre ces éléments. Afin de spécifier le comportement d'un système et de le rendre exécutable, le modèle de référence ODP RM-ODP peut être employé comme méta-modèle pour l aspect comportemental. 120

131 Chapitre IV : Utilisation de BPEL pour les concepts comportementaux du langage d entreprise ODP Dans ce chapitre, nous avons présenté dans un premier lieu le langage BPEL puis décrit la modélisation du comportement du système ODP par un profil UML spécifique. Ce profil permet aux développeurs d utiliser la notation UML et les outils appropriés pour modéliser les processus de comportement en utilisant le langage BPEL. Nous avons ensuite fait un mapping entre les méta-modèles des deux langages d entreprise et BPEL tout en présentant la structure et la syntaxe d'un processus du comportement BPEL. Ce mapping nous a permis de transformer les modèles UML du comportement vers les BPEL correspondants. Cette transformation est de type transformation de méta-modèle décrit par l approche MDA. Le mapping d'uml à BPEL est une approche conduite par le modèle dans laquelle les processus exécutables BPEL peuvent être générés automatiquement à partir des modèles UML. Ceci montre que l approche MDA peut être appliquée dans plusieurs domaines et à différents niveaux d abstraction. 121

132 Conclusion générale et perspectives CONCLUSION GENERALE ET PERSPECTIVES Etant donné l intérêt d ODP en tant que cadre de spécification des systèmes répartis ouverts, il devient impératif qu il ait une sémantique précise. Ceci aura l effet de faciliter l utilisation et la compréhension d ODP aussi bien par les concepteurs que par les développeurs. Dans ce cadre, nous avons montré comment rendre précise la sémantique des concepts de base du système ODP. En adoptant l approche de méta-modélisation et celle de la sémantique dénotationnelle, nous avons défini des méta-modèles de la syntaxe abstraite et de la sémantique basés sur UML/OCL pour les concepts de base des langages de point de vue. La relation entre ces deux modèles est exprimée par des contraintes OCL. Ces contraintes peuvent être vérifiées afin qu elles soient toutes satisfaites et qu elles évitent l introduction d'incohérence dans les données. Nous visons à tenir compte de ces contraintes lors de la génération du code d une spécification ODP. Ce qui rendra possible leur intégration dans un outil de modélisation et de génération de code (outil CASE). Une stratégie de formalisation a ainsi été développée dans l espoir d agir en tant que base pour le développement des sémantiques des autres aspects ODP et d intégrer de nouveaux systèmes de preuves pour ce standard. Ensuite, nous avons défini avec précision les concepts de comportement de base des systèmes ODP, en l occurrence le temps et l action, par l ajout des contraintes de séquencement, de non-déterminisme et de la concurrence. Nous avons aussi défini des politiques qui peuvent être utilisées pour identifier la spécification des contraintes sur le comportement du système ODP en se basant sur UML /OCL. Nous envisageons, pour assurer la vérification formelle, l utilisation de la théorie des automates d états comme les réseaux de Petri Objets/Hiérarchiques ou de Promela. Ces techniques ont prouvé qu il était possible d assembler de manière cohérente l information répartie dans les différents diagrammes de comportement d UML à des fins de vérification formelle, notamment par model checking, résultat qu on voit possible d étendre aux aspects comportementaux dans les différents langages de point de vue ODP. 122

133 Conclusion générale et perspectives En dernier lieu, nous avons décrit la modélisation du comportement du système ODP par un profil UML spécifique. Nous avons ensuite fait un mapping entre les méta-modèles des deux langages d entreprise et BPEL. Ce mapping nous a permis de transformer les modèles UML du comportement vers les BPEL correspondants. Cette transformation est de type transformation de méta-modèle décrite par l approche MDA. Ce travail permet de modéliser le comportement du système de la spécification jusqu à l exécution proposant ainsi une démarche de modélisation qui ouvre le chantier pour de nouveaux travaux d extension aux autres langages de point de vue ODP. 123

134 Bibliographie BIBLIOGRAPHIE [1]. ISO/IEC, Basic Reference Model of Open Distributed Processing-Part1: Overview and Guide to Use, ISO/IEC CD , [2]. ISO/IEC, RM-ODP-Part2: Descriptive Model, ISO/IEC DIS , [3]. ISO/IEC, RM-ODP-Part3: Prescriptive Model, ISO/IEC DIS , [4]. ISO/IEC, RM-ODP-Part4: Architectural Semantics, ISO/IEC DIS , July [5]. ISO/IEC, Use of UML for ODP system specifications, ISO/IEC 19793, may [6]. J-R. Putman, Architecting with RM-ODP, Prentice-Hal, [7]. M.-P. Gervais, Méthodologie ODAC: Le guide de spécification comportemental, Rapport de recherche LIP [8]. ISO/IEC, ODP Type Repository Function, ISO/IEC JTC1/SC7 N2057, [9]. ISO/IEC, The ODP Trading Function, ISO/IEC JTC1/SC [10]. D.A. Schmidt. Denotational Semantics : a methodology for language development. Wm.C. Brown Publishers, [11]. K.Slonneger. Formal Syntax and Semantics of Programming Languages. Addison-Wesley Publishers, 1995 [12]. J.Malenfant. Modélisation de la sémantique formelle des langages de programmation en UML et OCL. Rapport technique, IRISA, [13]. J. Malenfant. Une étude sémantique du langage QML. Rapport technique, IRISA,2002. [14]. R. D. Tennent, Semantics of Programming Languages, Prentice Hall International, Hemel Hempstead, UK, [15]. P.D. Mosses. Denotational Semantics. In Handbook of Theoretical Computer Science, chap. 11, pages 575_631. Elsevier Science Publishers & MIT Press, [16]. Dana S. Scott. Domains for denotational semantics. In Proceedings International Colloquium on Automata, Languages, and Programming '82, 1982 [17]. B.Mayer, Introduction à la théorie des langages de programmation,intereditions Publishers,1992 [18]. Hervé PANETTO, Meta-modèles et modèles pour l intégration et l interopérabilité des applications d entreprises de production, rapport de thèse,2006. [19]. LEMESLE Richard, Techniques de Modélisation et de Méta-modélisation, rapport de Thèse, oct [20]. Henri Tudor, Rapport de veille sur MDA et UML, dec [21]. BEZIVIN J. et BLANC X, MDA vers un nouveau paradigme(1), Développeur Référence,juillet 2002, v2.16, pp [22]. BEZIVIN J. et BLANC X, Standards et travaux (3), Développeur Référence. [23]. SUNYE G., Conception par contrats avec UML OCL Object Constraint Language. 124

135 Bibliographie [24]. OMG, MDA Guide Versions 1.0.1, [en ligne], juin 2003, Disponible sur : [25]. BLANC X., Ingénierie des modèles, juillet [26]. JOAQUIN M., What's a Platform - An Overview of Model Driven Architecture, [27]. OMG, Magnet Communications, Inc., MDA Success Story. [28]. J.M. Spivey, The Z Reference manual, Prentice Hall, [29]. IUT, SDL: Specification and Description Language, IUT-T-Rec. Z.100, [30]. ISO/IUT, LOTOS: A Formal Description Technique Based on the Temporal Ordering of Observational Behavior, ISO/IEC 8807, [31]. H. Bowman et al. FDTs for ODP, Computer Standards & Interfaces Journal, Vol. 17, No.5-6, Elsevier, (1995) [32]. J. Rumbaugh et al., The Unified Modeling Language, Addison Wesley, [33]. B. Rumpe, A Note on Semantics with an Emphasis on UML, Second ECOOP Workshop on Precise Behavioral Semantics, LNCS 1543, Springer, (1998) [34]. A. Evans et al., Making UML precise, Object Oriented Programming, Systems languages and Applications, (OOPSLA'98), Vancouver, Canada, ACM Press (1998) [35]. A. Evans et al. The UML as a Formal Modeling Notation, UML, LNCS 1618, Springer, (1999) [36]. S. Kent, et al. A meta-model semantics for structural constraints in UML,, In H. Kilov, B. Rumpe, and I. Simmonds, editors, Behavioral specifications for businesses and systems, Kluwer, (1999). chapter 9 [37]. E. Evans et al., Meta-Modeling Semantics of UML, In H. Kilov, B. Rumpe, and I. Simmonds, editors, Behavioral specifications for businesses and systems, Kluwer, (1999). chapter 4. [38]. J. Warmer and A. Kleppe, The Object Constraint Language: Precise Modeling with UML, Addison Wesley, (1998). [39]. D.A. Schmidt, Denotational semantics: A Methodology for Language Development, Allyn and Bacon, Massachusetts, (1986) [40]. G. Myers, The art of Software Testing,, John Wiley &Sons, (1979) [41]. Binder, R. Testing Object Oriented Systems. Models. Patterns, and Tools, Addison- Wesley, (1999) [42]. A. Cockburn, Agile Software Development. Addison-Wesley, (2002). [43]. B. Rumpe, Agile Modeling with UML, LNCS vol. 2941, Springer, (2004) [44]. Beck K. Column on Test-First Approach. IEEE Software, Vol. 18, No. 5, (2001) [45]. L. Briand, A UML-based Approach to System testing, LNCS Vol Springer, (2001) , [46]. B. Rumpe, Model-Based Testing of Object-Oriented Systems; LNCS Vol , Springer; (2003)

136 Bibliographie [47]. B. Rumpe, Executable Modeling UML. A Vision or a Nightmare?, In: Issues and Trends of Information technology management in Contemporary Associations, Seattle, Idea Group, London, (2002) pp [48]. Bruel and R.B.France. Transforming UML models to formal specifications.in UML 98 Beyond the notation, LNCS SpringerVerlag,1998. [49]. Jean-Michel Bruel. Une sémantique formelle pour UML : pourquoi? comment?. SEE Systèmes Informatiques de Confiance Cercle "Objectif Zero-Defaut" sur le thème "UML et techniques formelles", 2 February Pp 11 [50]. R. France, S. Kent, A. Evans, R. France, What Does the Term Semantics Mean in the Context of UML, In Ana M. D. Moreira and S. Demeyer Editors, ECOOP Workshops 1999, ECOOP 99 Workshop Reader, LNCS vol. 1743, Springer, (1999), pp [51]. Mohamed Bouhdadi, Youssef Balouki and al A UML/OCL Meta-model Syntax for Structural Constraints in ODP Enterprise Language Journal WSEAS Transactions on Computers, Vol 6, Issue 1, WSEAS Press, pp:31-36, [52]. M. Bouhdadi, Y. Balouki, E. Chabbar Meta-modelling Syntax and Semantics for Structural Concepts for Open Networked Enterprises, ICCSA 2OO7, Kuala Lumpur Malaysia, August 2007, LNCS. [53]. M. Bouhdadi et Youssef Balouki, A Semantics of Community related Concepts in ODP Enterprise Language. Series: Lecture Notes in Electrical Engineering, Vol. 27. Mastorakis, Nikos; Mladenov, Valeri (Eds.) Springer, p [54]. Youssef Balouki et M. Bouhdadi. A Semantics of Core Computational Model for ODP Specifications. Series: Lecture Notes in Electrical Engineering, Vol. 28 Mastorakis, Nikos; Mladenov, Valeri (Eds.) Springer, pp [55]. Mohamed Bouhdadi, Youssef Balouki. Semantics of Behavioral Concepts for Open Virtual Enterprises. Series: Lecture Notes in Electrical Engineering, Vol. 27 Mastorakis, Nikos; Mladenov, Valeri (Eds.) Springer, P [56]. Youssef Balouki et M. Bouhdadi. Using BPEL for Behavioural Concepts in ODP Enterprise Language. Virtual Enterprises and Collaborative Networks 2008 Poznan Poland. IFIP TC 5 WG 5.5 Publications Ninth Working Conference on Virtual Enterprises, September 8-10, 2008 Poznan Poland.Series : IFIP main Series in Computer Science, Pervasive Collaborative Networks Vol. 283 Springer Boston, 2008 pp [57]. M. Bouhdadi et al., An UML-based Meta-language for the QoS-aware Enterprise Specification of Open Distributed Systems,, Collaborative Business Ecosystems and Virtual Enterprises, FIP Series, vol. 85, Springer, ( 2002) pp [58]. A. S. Evans and A.N.Clark. Foundations of the unified modeling language,in: 2nd Northern Formal Methods Workshop, Ilkley, electronic Workshops in Computing. Springer-Verlag, [59]. Wing, J.M., A Specifier's Introduction to Formal Methods. IEEE Computer, (9): p [60]. Broy, M., Formal treatment of concurrency and time, in Software Engineer's Reference Book,J. McDermid, Editor, Oxford: Butterworth-Heinemann, (1991). 126

137 Bibliographie [61]. Naumenko, A., et al. A Viewpoint on Formal Foundation of RM-ODP Conceptual Framework, Technical report No. DSC/2001/040, July 2001, EPFL-DSC ICA. [62]. Wegmann, A. et al. Conceptual Modeling of Complex Systems Using RMODP Based Ontology. in 5th IEEE International Enterprise Distributed Object Computing Conference - EDOC ( 2001). September 4-7 USA. IEEE Computer Society pp [63]. Henri Poincaré, The value of science, Moscow «Science», 1983 [64]. Harel, D. and E. Gery, Executable object modeling with statecharts, IEEE Computer.30(7) pp (1997) [65]. P. Balabko, A. Wegmann, From RM-ODP to the formal behavior representation Proceedings of Tenth OOPSLA Workshop on Behavioral Semantics Back to Basics, Tampa, Florida, USA, pp (2001). [66]. Lamport, L. and N.A. Lynch, Distributed Computing: Models and Methods, in Handbook of Theoretical Computer Science, Volume B: Formal Models and Semantics. 2000, Elsevier and MIT Press. [67]. Tanguy Crusson,Business Process Management, De la modélisation à l exécution Positionnement par rapport aux Architectures Orientées Services, Intalio, livre blanc, [68]. Jörg Nitzsche and al.defining the Behaviour of BPELlight Interaction Activities Using Message Exchange Patterns, ServiceWave,PP , [69]. Duhang Zhong et al. Reliability Prediction for BPEL-Based Composite Web Service, Proceedings of the first international conference On Research challenges in Information science, pages 265,270. Ouarzazate, Morocco, [70]. M. Bouhdadi et al., An Informational Object Model for ODP Applications, Malaysian Journal of Computer Science, Vol. 13, N 2, (2000) [71]. keith_mantell, From UML to BPEL Model Driven Architecture in a Web services world, Report IT Architect, IBM [72]. Wolfgang Schreiner, Structure of Programming Languages : Denotational Semantics, Rapport technique,

138 Annexes ANNEXES Annexes A : Grammaire du langage OCL Cette annexe décrit la grammaire du langage OCL. La description de cette grammaire utilise la syntaxe EBNF. La description de cette grammaire utilise la syntaxe EBNF, où " " signifie un choix, "? " Option et "*" zéro ou plusieurs fois. oclfile := ( "package" packagenameoclexpression "endpackage")+ packagename := pathname oclexpression := (constraint)* constraint := contextdeclaration (("def" name? ":" letexpression* ) ( stereaotype name? ":" oclexpression))+ contextdeclaration := "context" (operationcontext classifiercontext ) classifiercontext := ( name ":" name ) name operationcontext := name "::" operationname "(" formalparameterlist ")" (":" returntype)? stereotype := ( "pre" "post" "inv" ) operationname := name "=" " + " "-" "<" "<=" "=>" ">" "/" "*" "<>" "implies" "not" "or" "xor" "and" formalparameterlist := ( name ":" typespecifier ( "," name ":" typespecifier)*)? typespecifier := simpletypespecifier collectiontype collectiontype := collectionkind "(" simpletypespecifier ")" oclexpression := (letexpression* "in")? expression returntype := typespecifier expression := logicalexpression ifexpression := "if" expression "then" expression "else" expression "endif" logicalexpression := relationalexpression( logicaloperator relationalexpression )* relationalexpression := additiveexpression( relationaloperator additiveexpression )? additiveexpression := multiplicativeexpression( addoperator multiplicativeexpression )* multiplicativeexpression := unaryexpression( multiplyoperator unaryexpression )* unaryexpression := ( unaryoperator postfixexpression ) postfixexpression postfixexpression := primaryexpression ( ("." "->") featurecall )* primaryexpression := literalcollection literal pathname timeexpression? qualifier? featurecallparameters? "(" expression ")" ifexpression featurecallparameters := "(" ( declarator )? ( actualparameterlist )? ")" literal := <STRING> <number> "#" <name> enumerationtype := "enum" "{" "#" <name> ( "," "#" <name> )* "}" simpletypespecifier := pathtypename enumerationtype literalcollection := collectionkind "{" expressionlistorrange? "}" 128

139 Annexes expressionlistorrange := expression ( ( "," expression )+ ( ".." expression ))? featurecall := pathname timeexpression? qualifiers?featurecallparameters? qualifiers := "[" actualparameterlist "]" declarator := <name> ( "," <name> )*( ":" simpletypespecifier )? " " pathtypename := <typename> ( "::" <typename> )* pathname := ( <typename> <name> ) ( "::" ( <typename> <name> ) )* timeexpression := "@" <name> actualparameterlist := expression ( "," expression )* logicaloperator := "and" "or" "xor" "implies" collectionkind := "Set" "Bag" "Sequence" "Collection" relationaloperator := "=" ">" "<" ">=" "<=" "<>" addoperator := "+" "-" multiplyoperator := "*" "/" unaryoperator := "-" "not" typename := "A"-"Z" ( "a"-"z" "0"-"9" "A"-"Z" "_")* name := "a"-"z" ( "a"-"z" "0"-"9" "A"-"Z" "_")* number := "0"-"9" ("0"-"9")* string := " " ( (~[" ","\\","\n","\r"]) ("\\"( ["n","t","b","r","f","\\"," ","\""] ["0"-"7"] ( ["0"-"7"] )? ["0"-"3"] ["0"-"7"] ["0"-"7"])))*" " 129