Méthode B pour la Spécification et la vérification formelle des systèmes répartis ouverts

Transcription

1 UNIVERSITE MOHAMMED V AGDAL FACULTE DES SCIENCES Service des affaires estudiantines RABAT N d ordre : 2577 THÈSE DE DOCTORAT Discipline : Informatique Spécialité : Systèmes répartis ouverts Hafid BELHAJ Titre de thèse : Méthode B pour la Spécification et la vérification formelle des systèmes répartis ouverts Président : Soutenue le 21 Juin 2012 devant le jury composé de : S. EL HAJJI Professeur (PES) à la Faculté des Sciences Rabat Examinateurs : M. Mohammed BOUHDADI Professeur Habilité (PH) à la Faculté des Sciences Rabat M. Mohamed EL MARRAKI Professeur (PES) à la Faculté des Sciences Rabat M. Mohamed RZIZA Professeur Habilité (PH) à la Faculté des Sciences Rabat A. KABBAJ Professeur (PES) à l Institut National des Statistiques et d Economie Appliquée Rabat Faculté des Sciences, 4 Avenue Ibn Battouta B.P RP, Rabat-Maroc. Tel : (0) /35/38, Fax : (0) ,

2 REMERCIEMENTS Les travaux présentés dans ce mémoire ont été effectués au sein du laboratoire Mathématiques, informatoques et Applications au département des Mathématiques et Informatiques à la faculté des sciences de rabat sous la direction conjointe de Mrs Saïd Elhajji et Mohammed Bouhdadi. Je tiens à remercier vivement mon directeur de thèse Saïd Elhajji, pour m avoir accepté dans son équipe et constamment soutenu dans mes recherches. Je tiens à remercier sincèrement Monsieur Mohammed Bouhdadi, pour la confiance qu il m a témoignée dans cette aventure passionnante et pour son encadrement tout au long de cette thèse. Je lui dois le goût pour les systèmes répartis ouverts et pour la recherche en général. Je remercie plus particulièrement Monsieur Mohamed EL MARRAKI pour son intérêt envers mon travail et ses critiques constructives sur mon manuscrit. Je remercie aussi Monsieur Mohammed RZIZA, professeur à la faculté des sciences de Rabat, pour tout l intérêt qu il a porté à ce travail. Je souhaite remercier Monsieur Adil KABBAJ, professeur à l INSEA, pour avoir accepté la lourde charge d être Rapporteur et pour ses précieuses remarques qui m ont permis d améliorer ce manuscrit. Je tiens à remercier mes parents pour avoir cru en moi et pour m avoir soutenu tout au long de mes études. Je leur dois beaucoup. Que cette thèse soit pour eux un juste retour de leur dévouement. Enfin, il est toujours délicat de remercier cet Autre qui vous accompagne. Merci Labrouzi- Naima pour ces nuits passées à m épauler, pour ton soutien inconditionnel, pour ta patience angélique, pour tes remarques précieuses, pour ton amour. À ma femme, à notre enfant BARAA I

3 RESUME Le modèle de référence pour le traitement réparti ouvert (RM-ODP) fournit un cadre dans lequel le support de la distribution, l'interfonctionnement et la portabilité peuvent être intégrés. Cependant, la sémantique de ses langages de points de vue est informelle. Notre objectif est de contribuer à la précision de la sémantique des concepts de base du système ODP permettant ainsi de construire correctement ces systèmes. Pour la spécification des concepts ODP, les langages Z, SDL, LOTOS, et Estelle sont utilisés dans la sémantique architecturale de RM-ODP. Toutefois, aucune méthode formelle n est susceptible d'être adaptée pour spécifier tous les aspects d'un système ODP. Dans ce contexte, nous avons proposé l utilisation de la méthode event-b tirant ainsi profit de la puissance de cette méthode afin d aboutir à des systèmes ODP corrects par construction. Nous avons d abord utilisé la méthode event-b pour la spécification précise des politiques ODP du point de vue entreprise. Puis, nous avons présenté une approche formelle pour la modélisation et l'analyse de la fonction de courtage en utilisant event-b. Enfin, nous avons développé le processus de négociation de la qualité de service nécessaire pour la coopération entre les objets. La Plate-forme Rodin pour event-b fournit un support efficace pour le raffinement et la preuve mathématique. Nous avons utilisé cette plate forme pour vérifier l exactitude des machines B conçues. Mots clés : RM-ODP, Langages de point de vue, QoS, fonction de courtage, politiques ODP, event-b, Rodin. II

4 ABSTRACT RM-ODP provides a framework within which support of distribution, interworking and portability can be integrated. However, the semantic of their viewpoint languages is informal. Our goal is to contribute to the precision of the semantics for a fragment of ODP concepts allowing to build correctly these systems. The languages Z, SDL, LOTOS, and Esterel are used in RM-ODP architectural semantics part for the specification of ODP concepts. However, no formal method is likely to be suitable for specifying every aspect of an ODP system. In this context, we proposed the use of event-b method. Hence we can benefit from the power of this method in order to be sure that the final system will be indeed correct by construction. First, we used the method event-b for the precise specification of ODP policies in the enterprise viewpoint. Then, we presented a formal approach for modelling and analyzing trading function using event-b. Finally, we developed the process of negotiation QoS requirements between objects. The Rodin Platform for Event-B provides effective support for refinement and mathematical proof. We used this platform to verify the accuracy of the B machines designed. Keywords: RM-ODP, viewpoint languages, QoS, trading function, ODP policies, event-b, Rodin. III

5 TABLES DES MATIERES Remerciements... I Résumé... II Abstract... III Tables des matières... IV Index des figures... VII Introduction générale De l Orienté Objet aux systèmes répartis ouverts Le besoin d un standard pour le traitement réparti ouvert Thème et objectifs de la recherche Plan de mémoire et travaux réalisés :... 5 Chapitre I : État de l art... 7 I.1. Introduction... 7 I.2. Le modèle de référence pour le traitement réparti ouvert RM-ODP... 9 I.2.1. Vue générale du modèle RM-ODP... 9 I.2.2. Fondements I.2.3. Architecture I.3. Sémantique dénotationnelle I.3.1. Principes généraux I.3.2. Constituants d'une sémantique dénotationnelle I.4. Ingénierie dirigée par les modèles et approche MDA I.4.1. Les principes généraux de l IDM I.4.2. La métamodélisation I.4.3. L approche MDA I.4.4. Transformation des modèles I.5. Spécification formelle en utilisant la méthode B I.5.1. Présentation de la méthode B I.5.2. Présentation du B événementiel I.5.3. Plateforme RODIN I.6. Conclusion Chapitre II : Modèles B pour la spécification des concepts de base du point de vue entreprise II.1. Introduction II.2. Langage d entreprise de RM-ODP II.3. Cohérence du point de vue entreprise avec les autres points de vue II.4. Concepts de base du langage d entreprise de RM-ODP II.5. Spécification informelle des concepts de base du langage d entreprise II.5.1. Niveaux abstraits et concrets des concepts de base du langage d entreprise II.5.2. Relations entre niveaux abstrait et concret : Play, Use et belong II.5.3. Modélisation informelle des concepts de base du point de vue entreprise IV

6 II.6. Spécification des concepts de base du point de vue entreprise par la méthode event-b II.6.1. Modèle abstrait tenant compte des politiques ODP II.6.2. Raffinement: Modèle concret tenant compte des politiques ODP II.7. Conclusion Chapitre III :Spécification et vérification de la fonction de courtage par event-b III.1. Introduction III.2. Fonctions ODP III.2.1. RM-ODP III.2.2. Fonctions ODP III.3. La fonction de courtage III.3.1. Aperçu général III.3.2. Description du trader du point de vue entreprise III.3.3 Description du trader du point de vue information III.3.4. Description du trader du point de vue ingénierie III.3.5. Description du trader du point de vue technologie III.3.6. Description du trader du point de vue traitement III.4. Spécification du trader ODP en utilisant event-b III.4.1. Stratégie de raffinement III.4.2. Modèle abstrait de la fonction de courtage III.4.3. Modèle de raffinement : Introduction de la fonction base de données du trader. 77 III.5. Vérification des modèles du trader III.6. Conclusion Chapitre IV : Utilisation de la méthode B événementielle pour la spécification de la qualité de service dans le langage de point de vue entreprise IV.1. Introduction IV.2. RM-ODP et qualité de service (QoS) IV.2.1. RM-ODP IV.2.2. Fonction de courtage IV.3. La spécification d entreprise de la QoS IV.3.1. Le modèle objet de la QoS du point de vue entreprise IV.3.2. Négociation de la QoS dans une communication client-serveur pour parvenir à un accord de QoS IV.4. Spécification de la négociation de paramètre unique de QoS en utilisant event-b IV.4.1. Représentation informelle du protocole de négociation de paramètre unique de QoS IV.4.2. Document des exigences IV.4.3. Stratégie de raffinement IV.4.4. Modèle initial IV.4.5. Premier raffinement IV.4.6. Second raffinement IV.4.7. Troisième raffinement IV.5. Travaux similaires V

7 IV.6. Conclusion Conclusion générale et perspectives Bibliographie Webiographie VI

8 INDEX DES FIGURES FIGURE 1. MODELE ARCHITECTURAL DE RM-ODP FIGURE 2. LA RELATION ENTRE LES POINTS DE VUE ODP FIGURE 3. PYRAMIDE DE MODELISATION DE L OMG FIGURE 4. MDA : UN PROCESSUS EN Y DIRIGE PAR LES MODELES FIGURE 5. PROCESSUS DE DEVELOPPEMENT EN B FIGURE 6. STRUCTURE D UNE MACHINE ABSTRAITE B FIGURE 7. UNE MACHINE B ET UN RAFFINEMENT POSSIBLE FIGURE 8. ÉVENEMENTS EN EVENT-B FIGURE 9 SUBSTITUTIONS EN B EVENEMENTIEL FIGURE 10. SCHEMA DE MODELES EN B EVENEMENTIEL FIGURE 11. L HORLOGE EN EVENT-B, ET SON RAFFINEMENT FIGURE 12. CONCEPTS DE BASE DU POINT DE VUE ENTREPRISE FIGURE 13 NIVEAUX ABSTRAITS ET CONCRETS DES CONCEPTS DE BASE DU POINT DE VUE ENTREPRISE FIGURE 14. ETAPES DE CONCEPTION D UN MODELE EVENT-B DES CONCEPTS D ENTREPRISE ODP FIGURE 15. TRADER ET SES UTILISATEURS FIGURE 16. EXEMPLE D UNE STRUCTURE DE CONTEXTE FIGURE 17. REPRESENTATION DE LA STRUCTURE DE CONTEXTE DE LA FIGURE FIGURE 18. SCENARIO D INTERACTION DU TRADER FIGURE 19. MODELE ABSTRAIT DE LA FONCTION DE COURTAGE] FIGURE 20. COMMUNICATION ENTRE LE TRADER ET SES UTILISATEURS TENANT COMPTE DE LA FONCTION DE BASE DE DONNEES FIGURE 21. COMMUNICATION ENTRE LE TRADER ET SES UTILISATEURS TENANT COMPTE DE LA BD: INITIALISATION VII

9 FIGURE 22. COMMUNICATION ENTRE LE TRADER ET SES UTILISATEURS TENANT COMPTE DE LA BD: EVENTS FIGURE 23. LE CONTEXTE DU MODELE ABSTRAIT DU TRADER FIGURE 24. LA MACHINE DU MODELE ABSTRAIT DU TRADER FIGURE 25. LE CONTEXTE DU MODELE DE RAFFINEMENT DU TRADER.. 82 FIGURE 26. LA MACHINE DU MODELE DE RAFFINEMENT DU TRADER FIGURE 27. TRADER ET SES UTILISATEURS FIGURE 28. MODELISATION DE LA QOS DU POINT DE VUE ENTREPRISE DE LA FONCTION DE COURTAGE FIGURE 29. NEGOCIATION DE PARAMETRE UNIQUE DE QOS FIGURE 30. NEGOCIATION BORNEE DE LA QOS FIGURE 31. SCHEMA DU PROTOCOLE DE NEGOCIATION DE QOS VIII

10 INTRODUCTION GENERALE 1. De l Orienté Objet aux systèmes répartis ouverts Le logiciel prend une place de plus en plus importante dans les systèmes. Ainsi, là où se trouvait un opérateur humain pour surveiller la température d'une centrale thermique, se trouve désormais un logiciel. L'émergence des technologies de l'information a également été un moteur pour l'essor de l'industrie du logiciel. Face à cette émergence du logiciel dans la vie quotidienne, l'industrie du logiciel a du évoluer au cours du temps afin de répondre aux exigences métiers en perpétuelle évolution. Cette évolution ne s'est pas faite sans heur et l'industrie a traversé plusieurs crises dans son existence. Ces crises lui ont fait prendre conscience de la nécessité d'augmenter la qualité de ces produits tout en conservant, voir en augmentant, sa productivité. La demande de la part des utilisateurs pour que les concepteurs de logiciel fournissent des produits avec des critères de qualité et de sûreté est de plus en plus grande. Ceci est principalement dû au fait que les logiciels sont de plus en plus complexes. Cette complexité est due aux difficultés à appréhender le domaine du problème dans sa totalité, à construire des logiciels flexibles et aussi à la difficulté de gérer leur processus de développement. Ces dernières années, l ingénierie des logiciels modélisés par des objets a été acceptée comme une des meilleures approches pour outrepasser les difficultés inhérentes à la construction des applications complexes. De nos jours, on utilise la conception Orienté Objet dans des secteurs industriels très variés comme les Bases de Données, les applications de gestion, de tarification et de provision de services, etc. Parallèlement à l émergence de l orienté objet, il devient de plus en plus difficile de parler d applications informatiques sans parler de répartition, de réseaux et de communication. Ceci est dû principalement à l amélioration des performances de communication. Les débits de transfert d informations sont passés de quelques centaines d octets par seconde, il y a quelques années, à plusieurs giga octets par seconde aujourd hui. L amélioration des 1

11 Introduction générale performances et le développement des fonctionnalités qui permettent un accès aux systèmes informatiques en améliorant les interfaces utilisateurs ont fait que les nouveaux systèmes informatiques sont basés sur la répartition et l échange des informations. Ainsi le concept qui allie à la fois l orienté objet et la répartition de l information est apparu, c est celui des systèmes répartis. Plutard ; un autre concept aussi important a vu le jour, c est celui des systèmes multi agents. Le standard ODP (Open Distributed Processing) a pour but de gérer les problèmes liés aux systèmes répartis. Selon ce standard, les caractéristiques de tels systèmes sont principalement: La répartition : les composants d'un système réparti sont répartis dans l'espace, et leurs interactions peuvent êtres locales ou réparties, L hétérogénéité des matériels, systèmes d'exploitation, protocoles, etc., La portabilité : Les composants logiciels sont indépendants de la plate forme matérielle. 2. Le besoin d un standard pour le traitement réparti ouvert Dans un système réparti ouvert idéal, les applications devraient être 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. Le modèle de référence d'odp (RM-ODP) fournit ce cadre [1-4]. Le modèle de référence pour le traitement réparti ouvert (RM-ODP) fournit un cadre dans lequel le support de la distribution, l'interfonctionnement et la portabilité peuvent être intégrés. Le RM-ODP est divisé en quatre parties : La partie «Vue générale» introduit le standard et son utilité. elle contient un aperçu général du modèle de référence ODP, en précise les motivations, le domaine 2

12 Introduction générale d'application et la justification, et propose une explication des concepts clés, ainsi qu'une présentation de l'architecture ODP ; La partie «fondement» contient la définition des concepts et du cadre analytique pour la description normalisée des systèmes de traitement distribué. Ces concepts sont regroupés en plusieurs catégories ; La partie «sémantique architecturale» contient une formalisation des concepts de modélisation définis dans la partie fondement ; La partie «architecture» contient les spécifications des caractéristiques requises pour qualifier un traitement réparti d ouvert. Il définit un cadre de travail composé de cinq points de vue, des langages de points de vue, des fonctions ODP et des transparences ODP. Les cinq points de vue, appelés point de vue entreprise, information, traitement, ingénierie et technologie, fournissent une base pour la spécification des systèmes ODP : Le point de vue entreprise : focalise sur les objectifs, le domaine d application et les stratégies de ce système, à l aide des concepts suivants: rôle, communauté, processus, étape, objectif, artefact, acteur et ressource ; Le point de vue information : permet la définition des informations traitées par les différentes ressources systèmes, à l aide des concepts suivants: schéma dynamique, schéma statique et schéma invariant ; Le point de vue traitement : décrit la décomposition fonctionnelle d'un système et les interactions entre les interfaces des différents objets, à l aide des concepts: signal, opération et flux ; Le point de vue ingénierie : décrit les moyens mis en œuvre pour que les objets du système interagissent, à l aide des concepts: grappe, capsule, noyau, nœud, canal, souche et éditeur de liens ; 3

13 Introduction générale Le point de vue technologie : définit les technologies logicielles et matérielles utilisées, à l aide des concepts standards implantables, implantation et informations supplémentaires sur l exécution. A chaque point de vue correspond un langage de point de vue qui définit les concepts et les règles pour la spécification des systèmes ODP dans ce point de vue. Le modèle de référence identifie un certain nombre de fonctions fondamentales pour la construction des systèmes ODP. 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. On cite entre autres : la fonction de courtage, la fonction de sécurité, la fonction de gestion, etc. Pour résoudre les problèmes liés à la répartition (hétérogénéité, tolérance aux pannes, répartition) dans un cadre normatif, RM-ODP définit des fonctions de transparences. Le but des transparences à la répartition est de transférer les difficultés liées à la répartition effective de l application du programmeur à l infrastructure sous-jacente. 3. Thème et objectifs de la recherche 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 précités : Entreprise, Information, Traitement, Ingénierie et Technologie. Cependant, le RM-ODP ne définit pas de méthodologie concrète pour guider les architectes (RM-ODP, partie 1, clause 8.1.1) [1]. Chaque organisme choisit des méthodes et des outils qui lui conviennent. 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. Par ailleurs et en dépit de la grande richesse de RM-ODP, 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é. 4

14 Introduction générale Notre premier objectif est de contribuer à la précision de la sémantique des concepts de base du système ODP, en utilisant la méthode B, permettant ainsi de construire correctement ces systèmes. D autre part, la phase de vérification prend beaucoup de temps de travail d une équipe pour produire un logiciel de qualité acceptable. Elle permet de prouver formellement qu une spécification (formelle) satisfait bien certaines propriétés désirées, en utilisant certaines méthodes rigoureuses. L activité de validation a nécessairement besoin d une spécification formelle qui doit être non ambiguë, claire et compréhensible pour qu il n y ait qu une seule interprétation possible de la description. Elle a aussi besoin d outils puissants supportant les descriptions formelles du système. Les langages Z [39], SDL [40], LOTOS [41], et Estelle [42] sont utilisés dans la sémantique architecturale de RM-ODP pour la spécification des concepts ODP. Toutefois, aucune de ces méthodes formelles n est susceptible d'être adaptée pour spécifier tous les aspects d'un système ODP. Notre deuxième objectif est d investiguer l utilisation de la méthode B[28], comme méthode formelle de spécification et de vérification des systèmes répartis ouverts, tirant ainsi profit de la puissance de cette méthode et des outils supportant les spécifications B, entre autre la plate forme Rodin[94], et ce afin d aboutir à des systèmes ODP corrects par construction. L ensemble des recherches conduites au cours de cette thèse contribuent de manière générale à combler ce manque de spécification formelle et d outils de vérification dans le contexte des systèmes répartis ouverts. 4. Plan de mémoire et travaux réalisés : Dans le premier chapitre, nous présentons principalement les concepts et principes nécessaires à la compréhension de notre sujet. Dans un premier temps, nous présentons le modèle de référence pour le traitement réparti ouvert RM-ODP. Dans un deuxième temps, nous introduisons la sémantique dénotationnelle. Puis, nous résumons les concepts clé de l ingénierie dirigée par les modèles et de l approche MDA. Enfin, nous présentons les deux 5

15 Introduction générale méthodes : méthode B et son extension B événementielle en mettant l accent principalement sur les concepts utilisés dans cette thèse Les trois prochains chapitres présentent notre contribution à la spécification formelle et à la vérification des systèmes répartis ouverts. Dans le chapitre 2, nous traitons la nécessité de la notation formelle des langages de point de vue 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 du système. Nous avons utilisé la méthode B événementielle pour la spécification précise des concepts de base du point de vue entreprise. Nous avons d abord classé les concepts du point de vue entreprise en deux niveaux : abstraits et concrets, puis proposé le modèle abstrait et le modèle de raffinement pour ces concepts tenant compte des politiques ODP. Dans le chapitre 3, nous avons présenté une approche formelle pour la modélisation et l'analyse de la fonction de courtage en utilisant event-b. Le modèle abstrait du trader est établit abstraction faite de sa fonction de base de données. Dans le modèle du raffinement, nous avons introduit la notion de fonction de base de données du trader. En effet, pour confronter les demandes de service avec les offres de service, le trader interagit avec la fonction de base de données de type fourni par l'infrastructure ODP. Dans le chapitre 4, nous utilisons la méthode event-b comme cadre formel pour le développement du processus de négociation de la QoS, en utilisant la fonction de courtage. Un des grands avantages de B est de disposer d ateliers logiciels performants pour sa mise en œuvre dans des projets industriels. En particulier, la Plate-forme Rodin pour event-b fournit un support efficace pour le raffinement et la preuve mathématique. Nous avons utilisé cette plate forme pour vérifier l exactitude des machines B conçus. Finalement, nous concluons ce travail en reprenant les résultats obtenus et en proposant différentes perspectives. 6

16 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) [1]. Le modèle de référence RM-ODP fournit ce cadre. Il établit une architecture qui permet la prise en compte de la répartition, l'interfonctionnement et la portabilité. Le modèle de référence ODP (RM-ODP) repose sur des concepts précis issus des développements récents dans le domaine des systèmes répartis [7], en particulier du projet Advanced Networked Systems Architecture (ANSA). Cette série de standards résulte d un travail commun entre l ISO [91] et l ITU-T [92]. Ce travail se situe actuellement comme le modèle de référence pour l interfonctionnement des systèmes ouverts. Il vise notamment à ce que les divers composants des applications réparties inter-opèrent entre eux et ce malgré l hétérogénéité des équipements, des systèmes opératifs, des réseaux, des langages, des modèles de bases de données ou des autorités de gestion. Il s'appuie, dans la mesure du possible, sur l'utilisation des techniques de descriptions formelles pour la spécification de l'architecture. Le développement formel de logiciel est une technique de production de logiciel destinée à répondre à des préoccupations de fiabilités du logiciel en permettant de spécifier un système de manière non ambiguë et de raisonner par le biais de preuves ou de manipulations mathématiques. D'après Hinchey et Bowen [8], une méthode formelle est un ensemble d'outils et de notations (avec une sémantique formelle), utilisés pour spécifier de manière non ambiguë les spécificités du système et supportant les preuves de propriétés sur ces spécifications et les preuves de corrections d'une implémentation éventuelle par rapport à la spécification. Les méthodes de spécification formelle sont utilisées en génie logiciel pour raisonner sur des modèles mathématiques. L intérêt est de pouvoir prouver ou vérifier des propriétés sur ces 7

17 Chapitre I : État de l art modèles. Malgré les coûts supplémentaires liés au travail d analyse et de vérification, l utilisation de telles méthodes est de plus en plus justifiée pour des logiciels qui impliquent des données ou des conditions de sécurité critiques, car elles permettent d assurer leur bon fonctionnement et évitent ainsi des risques d erreur. Trois méthodes nous semblent adaptées pour spécifier formellement des systèmes répartis ouverts : la sémantique dénotationnelle, l ingénierie dirigée par les modèles et la méthode B. La sémantique a une importance décisive sur la spécification d un système [19]. 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 proposent une approche de définition claire et nonambigüe. Elles peuvent être classées selon trois catégories complémentaires: Opérationnelles, Axiomatiques, et Dénotationnelles [19]. L ingénierie dirigée par les modèles (MDE-Model Driven Engineering) a permis plusieurs améliorations significatives dans le développement de systèmes complexes en permettant de se concentrer sur une préoccupation plus abstraite que la programmation classique [22]. Il s agit d une forme d ingénierie générative dans laquelle tout ou partie d une application est engendrée à partir de modèles. Un modèle est une abstraction, une simplification d un système qui est suffisante pour comprendre le système modélisé et répondre aux questions que l on se pose sur lui [25]. Un système peut être décrit par différents modèles liés les uns aux autres. L idée phare est d utiliser autant de langages de modélisation différents (Domain Specific Modeling Languages DSML) que les aspects chronologiques ou technologiques du développement du système le nécessitent. La définition de ces DSML, appelée métamodélisation, est donc une problématique clé de cette nouvelle ingénierie. Par ailleurs, afin de rendre opérationnels les modèles (pour la génération de code, de documentation et de test, la validation, la vérification, l exécution, etc.), une autre problématique clé est celle de la transformation de modèle [25]. La méthode B [28] est à la fois un langage et une méthode de spécification formelle. Elle a l avantage de traiter toutes les phases du cycle de conception, depuis l analyse des besoins jusqu à l implémentation finale. Elle est de plus très bien outillée. Ces raisons nous ont conduit à considérer B plutôt que d autres langages du même type comme VDM ou Z, qui ne 8

18 Chapitre I : État de l art couvrent pas tous ces aspects. Le langage B est basé sur la notion de machine abstraite qui est fondée sur les notions d état et de propriétés d invariance. Les outils associés à la méthode permettent d une part de vérifier la correction des machines spécifiées et d autre part de prouver des propriétés sur les spécifications obtenues. Ce chapitre est organisé de la manière suivante : dans la première section nous présentons le modèle de référence pour le traitement réparti ouvert (RM-ODP), dans la section suivante nous allons présenter la méthode B et son extension B-événementielle. I.2. Le modèle de référence pour le traitement réparti ouvert RM-ODP I.2.1. Vue générale du 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; 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 des systèmes de traitement répartis; 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; 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. La vue générale du modèle RM-ODP est présentée dans la figure suivante : 9

19 Chapitre I : État de l art RM-ODP RM-ODP Architecture Architecture Model Model Trminology Trminology Fundations Fundations Viewpoints Viewpoints Management Management Object Object Model Model Structuring Structuring Rules Rules Specification Specification Rules Rules Conformance Conformance Rules Rules Enterprise Enterprise VP VP Information Information VP VP Computational VP VP Engineering Engineering VP VP Technology Technology VP VP Scope Scope Objectives Objectives Policies Policies Community Community Action Action Role Role Information Information Objects Objects Static Static scema scema Dynamic Dynamic scema scema Invaraint Invaraint Scema Scema Conformance Conformance Info Info Interactions Interactions Interfaces Interfaces Service Service Behavior Behavior Policy Policy Binding Binding Computational Objects Objects Policy Policy Control Control Node Node Capsule Capsule Chanel Chanel Cluster Cluster Conformance Conformance Points Points Engineering Engineering Objects Objects Engineering Engineering Interfaces Interfaces Engineering Engineering Binding Binding Engineering Engineering Behavior Behavior Conformance Conformance Info Info Entreprise Entreprise Object Object ODP ODP Functions Functions Federation Federation Domain Domain Conformance Conformance Info Info Figure 1. Modèle architectural de RM-ODP [9] Le modèle de référence ODP est de nature générique, c'est-à-dire qu'il ne dépend d'aucun des domaines d'application qui font appel aux techniques de systèmes répartis. Il reste donc applicable à n'importe lequel de ces domaines. Dans le cas de certains domaines d'application particuliers, il y aura lieu de raffiner et de spécialiser le modèle de référence ODP pour l'adapter à des besoins spécifiques I.2.2. Fondements La Rec. UIT-T X.902 ISO/CEI définit un ensemble de concepts de modélisation sur lesquels se fonde l'expression de l'architecture des systèmes ODP définis dans la Rec. UIT-T X.903 ISO/CEI Ces concepts se regroupent en trois catégories: 10

20 Chapitre I : État de l art I Concepts de modélisation de base Les concepts de modélisation de base présentent un modèle général par objets. Un objet est une représentation d'une entité du monde réel. Il contient de l'information et offre des services. Il se caractérise par ce qui le distingue de tout autre objet et par ses aspects en termes d'encapsulation, d'abstraction et de comportement. Un système se compose d'objets en interaction mutuelle. Les objets ne peuvent agir les uns sur les autres que par des interfaces. Une interface représente une partie du comportement de l'objet. Chaque interface est identifiable à un ensemble d'interactions auxquelles l'objet peut participer. Une importante caractéristique des objets du modèle de référence ODP est qu'un objet peut disposer de plusieurs interfaces. Le comportement d un objet est une collection d actions auxquelles peut prendre part cet objet. Les actions peuvent être soit des interactions entre l'objet et son environnement, soit des actions internes. Les concepts d'état et de comportement sont liés. L'état d'un objet est la condition de cet objet à un instant donné. Il détermine les séquences d'actions dans lesquelles il est possible que l'objet soit impliqué. En même temps, les actions induisent des transitions d'état. Par conséquent, l'état d'un objet est déterminé en partie par son comportement passé. I Concepts de spécification Les concepts de spécification ne font pas partie intégrante des systèmes répartis, mais permettent à l utilisateur de décrire les spécifications et raisonner à leur sujet. Les concepts de composition et de décomposition sont utilisés pour organiser la spécification d'un système réparti sous forme d'un ensemble de spécifications dont chacune traite d'un niveau différent d'abstraction. Un type est un prédicat, c'est-à-dire une propriété, portant sur une collection de choses (objets, interfaces, etc.). Par exemple, "est rouge" est un type. Les types organisent implicitement les choses sous forme d'ensembles appelés classes. Une classe est la collection des choses qui présentent les propriétés décrites par le type. 11

21 Chapitre I : État de l art Un gabarit décrit une collection de choses (objets, interfaces, etc.) à un niveau de détail suffisant pour pouvoir créer une nouvelle instance de chose. Dans le cadre d un gabarit d objet composite, un rôle détermine un comportement à associer à l'un des objets composants. Un rôle peut correspondre à un sous-ensemble du comportement total d'un objet composant. I Concepts de structuration Un groupe est un ensemble d'objets rassemblés pour des raisons structurelles ou parce que leur comportement présente des aspects communs. Un domaine est une forme particulière de groupe, dans laquelle un aspect particulier du comportement des objets du groupe est sous le contrôle d'une même autorité. Dans un domaine de sécurité par exemple, les politiques de sécurité qui s'appliquent aux objets du domaine sont établies par la même autorité de sécurité. Il est essentiel de savoir désigner les composants d'un système réparti pour les distinguer les uns des autres et pour y avoir accès. La fonction de désignation constitue donc un élément fondamental de la construction d'un système réparti. Un contrat est un accord qui régit la coopération entre un certain nombre d'objets. Il emporte des idées d'obligation, de permission, d'interdiction et d'attente associées aux objets coopérants [7]. Un contrat d environnement est un type particulier de contrat passé entre un objet et son environnement. Il explicite ce que l'objet exige de son environnement et réciproquement. Il se préoccupe en particulier des contraintes portant sur la qualité de service. I.2.3. Architecture La Rec. UIT-T X.903 ISO/CEI formule les prescriptions normatives auxquelles doit se soumettre tout système pour pouvoir prétendre à la qualification ODP. Sur la base de la terminologie et des concepts définis dans la Rec. UIT-T X.902 ISO/CEI , elle définit: 12

22 Chapitre I : État de l art Un cadre architectural, dans lequel la spécification des systèmes ODP est structurée par application des concepts de points de vue, de spécifications de point de vue et de transparences à la répartition; Un ensemble de langages, dans les termes desquels peuvent s'exprimer les différentes spécifications de points de vue; Une infrastructure de système, qui apporte aux applications les transparences à la répartition. I Cadre architectural Les systèmes répartis sont vastes et compliqués. Un bon cadre architectural serait celui qui permettrait de travailler séparément sur les parties indépendantes du projet, tout en donnant les moyens de déterminer clairement les contraintes mutuelles qu'imposent leurs différents aspects. Deux approches structurantes sont utilisées à cette fin dans l'architecture ODP, les points de vue et les transparences. Un point de vue est une subdivision de la spécification d'un système complet conçue pour rassembler ceux des éléments d'information qui relèvent d'un domaine sur lequel porte un effort particulier au cours de la conception du système. Le modèle de référence ODP définit cinq points de vue entreprise, information, traitement, ingénierie et technologie. Afin de représenter un système ODP sous un point de vue donné, il faut définir un langage adapté à l'écriture des spécifications sous ce point de vue. Le but des transparences à la répartition est de transférer les difficultés liées à la répartition effective de l application du programmeur à l infrastructure sous-jacente. Le modèle de référence ODP définit un ensemble de transparences aux répartitions citées plus loin. I Langage d entreprise Le langage d'entreprise propose les concepts fondamentaux qui sont nécessaires pour représenter un système ODP dans le contexte de l'entreprise dans laquelle il fonctionne. Le but d'une spécification d'entreprise est d'exprimer les objectifs et les contraintes d'ordre politique qui pèsent sur le système considéré. A cette fin, le système est représenté par un ou plusieurs objets d'entreprise au sein d'une communauté d'objets d'entreprise qui représente 13

23 Chapitre I : État de l art cette entreprise et par les rôles auxquels participent ces objets. Ces rôles représentent, par exemple, les utilisateurs, les propriétaires ou les fournisseurs de l'information que traite le système. Une des idées principales qui apparaît dans le langage d'entreprise est celle d'un contrat qui lie les acteurs des différents rôles au sein d'une communauté et exprime leurs obligations mutuelles [10]. Un contrat peut exprimer les buts communs et les responsabilités qui particularisent les rôles dans une communauté, telle qu'une entreprise et ses clients ou qu'une administration et ses assujettis, comme s'ils étaient associés d'une manière particulière au sein d'une même entreprise. Une spécification d'entreprise définit les politiques qui régissent le comportement des communautés qu'elle spécifie. Ces politiques déterminent les actions exercées par les objets d'entreprise qui participent à ces communautés. Elles s'intéressent aux questions touchant à l'assignation et à l'accomplissement des obligations comme, par exemple, demande de livraison ou livraison, et à l'autorisation ou à l'interdiction des actions comme, par exemple, permission ou déni d'accès aux ressources du système. I Langage d information Le langage d'information définit des concepts qui servent à spécifier la signification de l'information que conserve et manipule un système ODP, indépendamment de la manière dont seront réalisées les fonctions de traitement de l'information elles-mêmes. Les informations que contient un système ODP sur des entités du monde réel sont représentées dans une spécification d'information en termes d'objets d'information, de leurs relations et de leur comportement. La spécification d'information se compose d'un ensemble de schémas apparentés, à savoir les schémas d'invariant, statique et dynamique. Un schéma d'invariant exprime des relations entre objets d information qui doivent rester toujours vraies dans tous les comportements valides du système. 14

24 Chapitre I : État de l art Un schéma statique exprime des affirmations qui doivent être vraies à un instant donné. Les schémas statiques sont communément utilisés pour spécifier l'état initial d'un objet d'information. Le schéma dynamique décrit comment un système peut modifier son état ou sa structure. Il décrit la transition d un schéma statique initial vers un schéma statique final tout en vérifiant un schéma d invariant. I Langage de traitement 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 [1]. 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 et les actions qu'un objet peut exécuter. Les interactions qui se produisent entre objets de traitement sont essentiellement asynchrones; elles peuvent prendre trois formes: Les opérations, qui ressemblent aux procédures, et sont appelées sur des interfaces désignées; Les flux, qui sont des abstractions de successions continues de données entre interfaces; Les signaux, qui sont des interactions atomiques élémentaires. I Langage d'ingénierie Alors que le point de vue traitement se soucie du quand et du pourquoi des interactions entre objets, le point de vue ingénierie spécifie la manière dont sont réalisées les interactions entre objets et sur les ressources nécessaires à cet effet (le comment ). Il définit les concepts qui servent à décrire l'infrastructure requise pour assurer aux interactions entre objets les diverses transparences à la répartition, ainsi que les règles qui servent à organiser des canaux de communication entre les objets et à organiser les systèmes aux fins de gestion des ressources. Les entités fondamentales décrites dans le point de vue Ingénierie sont des objets et des canaux [1]. 15

25 Chapitre I : État de l art I Langage de technologie La spécification 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. Elle est soumise à des contraintes de coût et de disponibilité des objets techniques matériels et logiciels susceptibles de répondre à la spécification. 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. La spécification de technologie joue un rôle très important dans le processus de vérification de la conformité. Elle donne l'information nécessaire pour réussir à interpréter les observations que peut faire un testeur dans les termes des vocabulaires dont se servent les autres points de vue de spécification du système. La Figure 2 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. Entreprise Cahier des charges Information Traitement Spécification fonctionnelle Ingénierie Conception Technologie Implantation Figure 2. La relation entre les points de vue ODP [12] 16

26 Chapitre I : État de l art I Fonctions ODP Le modèle de référence identifie un certain nombre de fonctions fondamentales pour la construction des systèmes ODP [5] [6]. 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. L'ensemble complet des fonctions ODP se répartit en quatre groupes: a) fonctions de gestion qui comprennent la gestion de nœud, d objet, de grappe et de capsule ; b) fonctions de coordination ; c) fonctions de conteneur qui comprennent la fonction de stockage, la fonction de gestion de base d'information, la fonction de relocalisation, la fonction de conteneur de types et la fonction de courtage. La fonction de courtage [5][6] donne le moyen aux prestataires de services d'exporter des offres de service sous la forme d'informations sur l'interface où est fourni un service et aux utilisateurs de services d'importer les offres de service qui concordent avec leurs exigences particulières ; d) fonctions de sécurité : traitent des exigences relatives à la confidentialité, à l'intégrité, à la disponibilité et à la capacité de tenir des comptes. Elles comprennent la fonction de contrôle d'accès, la fonction d'audit de sécurité, la fonction d'authentification, la fonction d'intégrité, la fonction de confidentialité, la fonction de non répudiation et la fonction de gestion de clés. I Transparences ODP à la répartition Lorsque l'on conçoit un système réparti, il survient un certain nombre de difficultés qui résultent directement de la répartition: les composants du système sont hétérogènes, ils peuvent tomber isolément en panne, ils se trouvent à des endroits différents sinon même variables, et ainsi de suite. Ou bien on résout directement ces difficultés dans le cadre de la conception des applications, ou bien on choisit des solutions normalisées fondées sur les meilleurs usages. Le but des transparences à la répartition est de transférer les difficultés liées à la répartition effective de l application du programmeur à l infrastructure sous-jacente. S'il fait le choix de 17

27 Chapitre I : État de l art mécanismes normalisés, le concepteur d'application travaille dans un monde "transparent" à cette difficulté particulière, car elle n'apparaît plus. Le modèle de référence ODP définit un ensemble de transparences à la répartition: la transparence à l accès, la transparence à la défaillance pour garantir la tolérance aux pannes, la transparence à la localisation, la transparence à la migration, la transparence à la relocalisation, la transparence à la duplication, la transparence à la persistance et la transparence aux transactions pour en assurer la cohérence. I.3. Sémantique dénotationnelle I.3.1. Principes généraux Les aspects les plus importants dans la définition d un langage de programmation sont [17]: La syntaxe : C est la définition formelle de ce que c est un programme dans le langage. On doit donner un moyen pour décider si une chaîne de caractères donnée fait partie du langage. La syntaxe traite seulement la forme et la structure des symboles sans donner de l importance à leur signification. On distingue entre : syntaxe concrète [18] qui décrit le programme sous forme de chaîne de caractères, et syntaxe abstraite qui décrit le programme sous forme d arbre syntaxique ; La pragmatique : est-ce ceci le bon langage pour écrire le programme qui m intéresse. La sémantique : vise, pour l'essentiel, à définir comment attribuer une signification à chacune des phrases des programmes en s'appuyant sur la syntaxe abstraite du langage. Une sémantique formelle s'attache à prendre comme éléments de signification des objets mathématiques formellement manipulables. Le choix des objets mathématiques utilisés pour ce faire est ce qui distingue les différents types de sémantiques dont les plus connus sont : - Sémantique opérationnelle [19]: Le but de la sémantique opérationnelle est de décrire comment un calcul est exécuté. Dans l approche opérationnelle, on définit une machine abstraite qui est typiquement un ensemble d états et une relation de transition entre les états. - 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 18

28 Chapitre I : État de l art mathématique permettant de spécifier et prouver les propriétés des programmes écrits dans ce langage [19]. -Sémantique dénotationnelle: Dans l approche dénotationnelle, on associe à chaque construction du langage de programmation certaines entités mathématiques, tels les entiers, les fonctions, les ensembles et les relations [19]. On définit d abord l ensemble de ces objets mathématiques, appelés dénotations, et ensuite on associe une dénotation à chaque phrase du langage. 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. La sémantique dénotationnelle repose sur deux grands principes : la compositionalité et le calcul de points fixes [20]. La compositionalité est la propriété d'une sémantique dont la signification d'une phrase ne dépend que de la signification de ses sous-phrases [21]. 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é est importante dans la mesure où elle permet de faire des preuves de 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. I.3.2. Constituants d'une sémantique dénotationnelle La maturation de l'approche dénotationnelle a amené plusieurs auteurs à proposer ce que l'on peut appeler des présentations structurées de sémantiques dénotationnelles [20]. En gros, on distingue : La syntaxe abstraite : est spécifiée par la définition des domaines syntaxiques et la grammaire abstraite. Les domaines syntaxiques sont des collections d'objets syntaxiques qui peuvent se produire dans des expressions définies par la syntaxe du langage [18] ; L'algèbre sémantique : définit l'ensemble des domaines de valeurs des objets mathématiques qui vont servir de dénotations pour les phrases de la syntaxe abstraite. 19

29 Chapitre I : État de l art 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 [20] ; Les fonctions de valuation : indique comment calculer la dénotation d'une phrase d'un programme selon son domaine syntaxique. Ces fonctions de valuation se présentent sous la forme d'équations. Pour chaque domaine syntaxique, une fonction de valuation différente est définie. On lui donne un nom, puis on la définit par une suite d'équations sémantiques [20]. I.4. Ingénierie dirigée par les modèles et approche MDA I.4.1. Les principes généraux de l IDM Suite à l approche objet des années 80 et de son principe du «tout est objet», l ingénierie du logiciel s oriente aujourd hui vers l ingénierie dirigée par les modèles (IDM) et le principe du «tout est modèle» [22]. Le concept central de l IDM est la notion de modèle pour laquelle il n existe pas à ce jour de définition universelle. A partir des travaux de l OMG [93], nous considérerons dans la suite de cette thèse la définition suivante d un modèle. Définition (Modèle) Un modèle est une abstraction d un système, modélisé sous la forme d un ensemble de faits construits dans une intention particulière. Un modèle doit pouvoir être utilisé pour répondre à des questions sur le système modélisé. La notion de modèle dans l IDM fait explicitement référence à la notion de langage bien défini. En effet, pour qu un modèle soit productif, il doit pouvoir être manipulé par une machine. La définition d un langage de modélisation a pris la forme d un modèle, appelé métamodèle. Définition (Méta-modèle) Un méta-modèle est un modèle qui définit le langage d expression d un modèle [26], c.-à-d. le langage de modélisation. 20

30 Chapitre I : État de l art I.4.2. La métamodélisation Définition: La métamodélisation est l activité consistant à définir le métamodèle d un langage de modélisation. Elle vise donc à bien modéliser un langage, qui joue alors le rôle de système à modéliser [22]. 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. Des standards telles que XML et MOF peuvent être utilisées. 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 [23]. I.4.3. L approche MDA Après l acceptation du concept clé de méta-modèle comme langage de description de modèle, de nombreux méta-modèles ont émergés afin d apporter chacun leurs spécificités dans un domaine particulier (développement logiciel, entrepôt de données, procédé de développement, etc.). Devant le danger de voir émerger indépendamment et de manière incompatible cette grande variété de méta-modèles, il y avait un besoin urgent de donner un cadre général pour leur description. La réponse logique fut donc d offrir un langage de définition de métamodèles qui prit lui-même la forme d un modèle : ce fut le méta-méta-modèle MOF (Meta- Object Facility) [26]. En tant que modèle, il doit également être défini à partir d un langage de modélisation. Pour limiter le nombre de niveaux d abstraction, il doit alors avoir la propriété de métacircularité, c.-à-d. la capacité de se décrire lui-même. Définition (Méta-méta-modèle) Un méta-méta-modèle est un modèle qui décrit un langage de méta-modélisation, c.-à-d. les éléments de modélisation nécessaires à la définition des langages de modélisation. Il a de plus la capacité de se décrire lui-même. 21

31 Chapitre I : État de l art C est sur ces principes que se base l organisation de la modélisation de l OMG généralement décrite sous une forme pyramidale (cf. figure 3). Le monde réel est représenté à la base de la pyramide (niveau M0). Les modèles représentant cette réalité constituent le niveau M1. Les métamodèles permettant la définition de ces modèles (p. ex. UML) constituent le niveaum2. Enfin, le métamétamodèle, unique et métacirculaire, est représenté au sommet de la pyramide (niveau M3). Figure 3. Pyramide de modélisation de l OMG [22] Le principe clé du MDA consiste à s appuyer sur le standard UML pour décrire séparément des modèles pour les différentes phases du cycle de développement d une application [24]. Plus précisément, le MDA préconise l élaboration de modèles (cf. figure 4) d exigence (Computation Independent Model CIM) dans lesquels aucune considération informatique n apparait, d analyse et de conception (Platform Independent Model PIM) et de code (Platform Specific Model PSM). Le passage de PIM à PSM fait intervenir des mécanismes de transformation de modèle et un modèle de description de la plateforme (Platform Description Model PDM). Cette démarche s organise donc selon un cycle de développement «en Y» propre au MDD (Model Driven Development) (cf. figure 4). 22

32 Chapitre I : État de l art Figure 4. MDA : Un processus en Y dirigé par les modèles [24] I.4.4. Transformation des modèles La deuxième problématique clé de l IDM consiste à pouvoir rendre opérationnels les modèles à l aide de transformations. Cette notion est au centre de l approche MDA [22]. D autre part, l approche MDA repose sur le principe de la création d un modèle indépendant de toute plateforme (PIM) pouvant être raffiné en un ou plusieurs modèle(s) spécifique(s) à une plateforme (PSM). Les méthodes de transformation sont là aussi indispensables pour changer de niveau d abstraction (transformation verticale), dans le cas du passage de PIM à PSM et inversement, ou pour rester au même niveau d abstraction (transformation horizontale) dans le cas de transformation PIM à PIM ou PSM à PSM [25]. Les règles de transformation sont appliquées au modèle source pour produire un modèle cible. Selon le standard MOF 2.0 Q/V/T, l'application des règles de transformations doit être automatisée par un moteur de transformation [26]. I.5. Spécification formelle en utilisant la méthode B Les idées qui président à la fondation de la méthode B remontent à la première moitié de la décennie : Jean-Raymond Abrial avait proposé auparavant une notation appelée Z [27], servant à spécifier de manière mathématique, via la théorie des ensembles et la logique du premier ordre, un système informatique. Cherchant à aller plus loin, il a conçu la méthode 23

33 Chapitre I : État de l art B pour pouvoir développer un logiciel de manière correcte et sûre. C'est une méthode «formelle» car elle s'appuie sur des bases mathématiques (la logique du premier ordre, la théorie des ensembles et les transformateurs de prédicats); elle propose un langage pour exprimer les spécifications; elle fournit une technique de développement précise par les raffinements; enfin elle définit les règles de cohérence des spécifications et des développements par le biais des obligations de preuves. La totalité des idées présentant la méthode B dans ses plus infimes détails est regroupée dans le B-Book [28]. Notons que le nom de «B» a été choisi pour rendre hommage aux mathématiciens qui ont repensé les mathématiques à partir du début du vingtième siècle et qui signaient sous le pseudonyme commun de Nicolas Bourbaki. Les travaux de ce «groupe Bourbaki» continuent encore aujourd hui. La méthode B est utilisable industriellement car il existe des outils commercialisés, en particulier la plate forme Rodin [94]. En guise d'application réussie, on peut citer la ligne de métro, Météor, dont le système de pilotage sans chauffeur a été développé en B et est opérationnel [29]. Ce projet Météor a été réalisé par Matra Transport International pour le compte de la Régie Autonome des Transports Parisiens. Au cours des dernières années, la technologie standard B s'est étendue à d'autres domaines d'applications que les transports ferroviaires. Il s'agit essentiellement des applications pour lesquelles on doit garantir un haut degré de fiabilité et pour lesquelles les fournisseurs veulent satisfaire les nouvelles normes de qualité. L utilisation de la méthode B est en pleine émergence dans la spécification des systèmes ODP. En 1996, Jean-Raymond Abrial a étendu les possibilités d'application de la méthode, sans changer la théorie sous-jacente, dans ce qu'il est convenu d'appeler le B-événementiel [30]. Dans ce qui suit, on va présenter les deux méthodes : B et son extension B événementiel en mettant l accent principalement sur les concepts utilisés dans cette thèse. 24

34 Chapitre I : État de l art I.5.1. Présentation de la méthode B I Processus de développement en B Partant d une spécification mathématique abstraite de haut niveau, et par une suite de raffinements prouvés aboutissant à la production de code exécutable, la méthode B [28], se présente comme une méthode formelle couvrant toutes les phases d un cycle de développement formel. En effet, les documents formels (figure 5) expriment différents niveaux d abstraction allant de la phase de conception préliminaire jusqu à la phase de codage. Analyse des besoins Spécification informelle Conception préliminaire Spécification abstraite Obligations de preuves Obligations de preuves Documents formels Exprimés en B Conception détaillée Obligations de preuves Raffinement Raffinement 1 Obligations de preuves Obligations de preuves Raffinement Successif Raffinement n Obligations de preuves Raffinement Codage Implémentation Figure 5. Processus de développement en B [31] Le passage d une phase à une autre dans un processus de développement en B correspond à un incrément (dit raffinement) de spécifications et est guidé par un ensemble d obligations de preuves dont l objectif est de valider les composants en cours de développement. Cette 25

35 Chapitre I : État de l art décomposition par raffinements successifs prouvés de spécifications a pour objectif de permettre un développement modulaire, sûr et fiable des systèmes. L abstraction utilisée pour spécifier les composants B se base sur la théorie des ensembles et la logique du premier ordre, pour spécifier les propriétés statiques, et un langage de substitutions pour spécifier les propriétés dynamiques des machines. Un composant B est la donnée d une machine abstraite qui spécifie les propriétés du composant, et de ses raffinements. I Machine abstraite Cette notion de machine abstraite est une notion fondamentale dans un développement en B. Elle correspond à l élément de structuration de base des spécifications et est composée de trois parties (Figure 6) : Structure d une machine abstraite MACHINE PARTIE ENTETE Nom de la machine Paramètres de la machine Contraintes sur les paramètres PARTIE STATIQUE (DECLARATIVE) Déclarations d ensembles Déclarations de constantes Propriétés de constantes Déclarations des variables (état) Invariant (caractérisation de l état) PARTIE DYNAMIQUE (OPERATIONNELLE) Initialisation des variables Opérations END Figure 6. Structure d une machine abstraite B [31] - La partie entête : Permet l identification de la machine abstraite. Elle contient la clause MACHINE suivi éventuellement de paramètres, ainsi que la clause CONSTRAINTS où il s agit de caractériser ces paramètres. 26

36 Chapitre I : État de l art - La partie statique : regroupe les déclarations d ensembles (clause SETS), de constantes (clause CONSTANTS) et de variables (clause VARIABLES). Ces déclarations sont complétées par un ensemble de prédicats décrivant les propriétés des constantes (clause PROPERTIES) ainsi que les invariants (clause INVARIANTS) qui explicitent précisément les propriétés qui doivent toujours être satisfaites par l état de la machine. Les données définies au niveau de ces clauses sont spécifiées en utilisant des formules de la logique du premier ordre et des concepts mathématiques de la théorie des ensembles. - La partie dynamique : décrit l évolution de l état de la machine. Ceci comprend son initialisation et les opérations offertes par la machine. Les transitions entre états peuvent s effectuer de manière largement non-déterministe. Pour ce faire, le langage défini est celui des substitutions généralisées qui est une notion spécifique à B. I Typage de données en B Le typage en B est un mécanisme de vérification statique des données [28]. En B, ce mécanisme s effectue en utilisant des prédicats ou des substitutions particulières désignées par prédicats de typage ou substitution de typage. Dans notre travail nous allons nous intéresser plutôt aux prédicats de typage (l appartenance (Є), l inclusion (Ϲ, ) et l égalité (=)). Ces prédicats permettent d associer explicitement un type à une donnée B, par exemple, le prédicat d Є NAT spécifie que la donnée «d» est de type entier. I Langage des substitutions généralisées Les opérations d une machine abstraite représentent un ensemble de services permettant d initialiser puis de faire évoluer les données de la machine (ou état de la machine). Le langage des substitutions généralisées est défini pour exprimer ce mécanisme d évolution de données. La sémantique des substitutions généralisées en B est précisée par le calcul de la plus faible pré-condition (ou Wp) défini par dijkstra en 1975 [32] [33] et inspiré de la logique de hoare [34]. 27

37 Chapitre I : État de l art I Raffinement Le raffinement en B est une technique de développement incrémental permettant de préciser progressivement les données et les opérations de la spécification abstraite de départ. L objectif de cette technique est de passer progressivement d une spécification non déterministe de haut niveau à une spécification concrète déterministe, automatiquement traduisible dans un langage de programmation. Le raffinement d une machine par une autre permet de préciser deux aspects de la machine : son état, et son comportement dynamique. Lors du raffinement, l état de la machine peut être détaillé en précisant avec une granularité plus fine les variables de la machine, ou en ajoutant de nouvelles variables. De manière duale, le comportement dynamique de la machine est précisé en modifiant les opérations conformément aux anciennes et nouvelles variables. La figure 7 illustre une machine Clock et son raffinement. MACHINE Clock VARIABLES hour INVARIANT hour INITIALISATION hour : OPERATIONS tick = CHOICE IF hour=23 THEN hour :=0 ELSE hour :=hour+1 END OR skip END END REFINEMENT Clockhm REFINES Clock VARIABLES h, minute INVARIANT minute h=hour INITIALISATION h:=11 minute : OPERATIONS tick = IF minute=59 THEN IF h=23 THEN h:=0 minute:=0 ELSE h:=h+1 minute:=0 END ELSE minute:=minute+1 END END Figure 7. Une machine B et un raffinement possible [95] Cette machine spécifie un état conservant les heures (hour), initialisé à la mise en route de l horloge à un nombre entre 10 et 16. Cela spécifie par exemple que l horloge sera forcément mise en route pendant ces heures. La condition de sûreté pour que l horloge fonctionne 28

38 Chapitre I : État de l art correctement, est que les heures affichées restent bien entre 0 et 23. Enfin une opération tick permet de faire avancer l heure. Ce raffinement appelle à plusieurs commentaires : Le raffinement définit une nouvelle variable h : comme les heures ont un comportement plus précis dans le raffinement (à cause de l initialisation), alors il est nécessaire de définir cette nouvelle variable. Ensuite il est nécessaire de spécifier quelle est la relation entre h et hour : le prédicat hour = h est dit de collage, car il fait la relation entre les états de la machine abstraite et ceux du raffinement ; L initialisation dans le raffinement est plus précise : l heure qui auparavant pouvait être initialisée entre 10 et 16, est désormais initialisée à 11 ; Le raffinement ajoute une variable minute qui permettra de préciser à quel moment la variable des heures changera ; L opération tick est modifiée pour exprimer le changement d état de la machine lorsque cette opération est appelée. Or nous nous rendons compte que cette fois-ci, lorsque l opération tick est appelée, la variable des heures ne change pas forcément. Donc l opération de la machine abstraite n était pas correcte : il nous faut désormais spécifier que les heures peuvent ne pas changer. La machine abstraite est corrigée dans ce sens. I Obligations de preuve Une obligation de preuve est une formule mathématique à démontrer afin d assurer qu un composant B (une machine abstraite) est correct [31]. Dans cette optique, les obligations de preuve sont une aide au processus de vérification. Les obligations de preuve sont générées à partir du calcul de la plus faible pré-condition. Il s agit de vérifier que l invariant est respecté aussi bien par l initialisation que par les opérations de la machine. L exemple de l horloge en figure 7 spécifie comment évolue l horloge, mais pas ce qu elle fait, i.e. son but final. De plus, le fonctionnement de la machine est dévolu à une machine tiers 29

39 Chapitre I : État de l art qui appellerait le tick d horloge lorsque nécessaire. Cette manière de faire est contre-intuitive, puisque ce qui est attendu ici est plutôt que l horloge avance par elle-même, et d autres composants se mettent à jour en fonction de celle-ci. Cette manière de faire n est pas possible en B, puisque cette notion de fonctionnement perpétuel est interdite par le fait que les boucles doivent s arrêter, alors que ce sont les seules structures de contrôle exprimant une notion de répétition. La méthode B possède des limitations dans les domaines suivants [39]: L apparition d étapes de calcul auparavant indiscernables ; L impossibilité d accéder aux états intermédiaires d une machine lors d une opération (la Granularité observable se limite aux états entre les opérations) ; L impossibilité de spécifier qu un système fonctionne tout le temps. Les réponses à ces problèmes sont apportées par le B événementiel. I.5.2. Présentation du B événementiel I Historique Le déplacement de paradigme de modèles invoqués vers des modèles autonomes provient d un article sur la spécification de contraintes dynamiques en B [35]. Il illustre que la méthode B peut être utilisée pour spécifier des systèmes distribués. L idée initiale est de spécifier un projet B normalement, et d ajouter des contraintes dynamiques, compatibles avec les contraintes statiques déjà spécifiées, pour garantir que la machine atteindra un certain état futur. Cet ajout de contraintes dynamiques, et les problèmes de B évoqués plus haut ont amené à repenser la notion de fonctionnement et de raffinement d un projet B. Les systèmes ne sont plus vus comme des composants contrôlés, mais comme des systèmes autonomes où différents événements activent différents comportements au sein du système. Le raffinement est pensé comme une vue de plus en plus précise de ces événements et de ces comportements. 30

40 Chapitre I : État de l art Une première description d un système conçu dans cet esprit a vu le jour au sein du projet Matisse [36] et jette les bases d un B événementiel. Les exemples se succèdent depuis, notamment une modélisation complète d algorithmes [37] pour la recherche d arbres minimaux couvrants de graphes, nécessaires dans le cadre du protocole IEEE1394. I Différences avec B Les avantages d event-b par rapport au B classique sont déjà résumés précédemment : Un composant n est plus «appelable» : il est désormais un système autonome dénommé modèle ; Chaque modèle est composé de plusieurs actions activables lorsque les gardes de celles-ci sont déclenchables. Ces actions gardées sont appelées événements ; Chaque modèle définit un invariant qui établit une propriété qui restera vraie tout le temps de l exécution du système ; Un modèle fonctionne tant qu un de ses événements est activable. Dans le cas contraire, soit le calcul fait par le système est terminé, soit le système est bloqué. Cette dernière propriété n est pas désirable lorsque le système est conçu justement pour ne pas s arrêter ; Un modèle peut être raffiné en un ou plusieurs sous-modèles reprenant les anciens événements et en définissant de nouveaux. Ce raffinement de modèles est très similaire à celui de B : le nouveau système raffiné rend plus déterministe le système abstrait. Les événements, construits sur les substitutions, ont la forme décrite en figure 8. Ils sont définis par un nom, une garde optionnelle et une substitution. Event_name WHEN Guard THEN Substitution END Figure 8. Événements en event-b [38] Les substitutions autorisées en event-b sont moins nombreuses, elles sont indiquées dans la figure 9. 31

41 Chapitre I : État de l art Vide Déterministe skip x :=E(v) Non-déterministe ANY t WHERE P(t,v) THEN x :=t END Parallèle S T Figure 9 Substitutions en B événementiel [38] Les systèmes décrits en event-b ont la forme indiquée en figure 10. REFINEMENT M2 MODEL M1 REFINES M1 VARIABLES x VARIABLES y INVARIANT I1 VARIANT A2 INITIALISATION U1 INVARIANT I2 INITIALISATION U2 OPERATIONS OPERATIONS event1 event1 eventn+1 WHEN Q1 WHEN R1 WHEN Rn+1 THEN V1 END THEN W1 END THENWn+1 END eventn eventn eventn+m WHEN Qn WHEN Rn WHEN Rn+m THEN Vn END THEN Wn END; THENWn+m END END Figure 10. Schéma de modèles en B événementiel [38] Nous ajoutons deux remarques sur ces schémas de modèles : Il n y a pas en fait de clause PROPERTIES : les modèles event-b ont à la place une clause SEES qui «voit» un contexte qui définit des ensembles, des constantes et des propriétés sur ceux-ci. Son rôle est similaire à la clause du même nom en B classique 32

42 Chapitre I : État de l art Il n y a pas non plus de clause INITIALISATION : l initialisation des variables se fait dans un événement spécial, sans garde, appelé initialisation. Son rôle est similaire à la clause d initialisation du B classique. En event-b, un événement est donc composé d un prédicat appelé garde et de l action correspondante à ce garde. Le garde est un prédicat qui définit la condition d activation, et l action est définie par une substitution. La modularité en event-b est en quelque sorte l inverse de celle du B classique. Alors que des machines B peuvent être développées séparément puis composées plus tard, le développement en event-b part de l expression des propriétés les plus abstraites du modèle, puis au fur et à mesure des raffinements, les modèles peuvent être séparés en différents sous-modèles. Ils peuvent également être rassemblés plus tard en un autre point du raffinement, bien que l utilité de ce rassemblement soit discutable, puisqu il fait perdre la modularité. Un modèle event-b est correct s il ne diverge pas. La divergence, mentionnée à plusieurs reprises dans le document de référence d event-b, peut désigner différentes notions : L invariant n est plus établi (le système n est plus sûr) ; Les calculs sont incohérents (le système atteint un état incohérent) ; Aucune garde ne peut plus être activée (le système est bloqué). I Raffinement de données et d opérations En B événementiel, le raffinement gère la complexité pour les deux aspects : Des données correspondant à une vue de plus en plus précise peuvent être introduites au fur et à mesure des raffinements, à l instar du B classique. De nouveaux événements peuvent être définis pour prendre en compte le comportement de ces nouvelles données. Si nous reprenons l exemple de l horloge en figure 7, le modèle en B événementiel correspondant peut être décrit comme en figure

43 Chapitre I : État de l art MODEL Clock VARIABLES hour INVARIANT hour INITIALISATION hour : EVENTS update_h = WHEN hour <23 THEN hour :=hour+1 END; reset_h = WHEN hour =23 THEN hour :=0 END END REFINEMENT Clockhm REFINES Clock VARIABLES h, minute INVARIANT minute h=hour INITIALISATION h: =11 minute : EVENTS update_h = WHEN hour <23 m=59 THEN hour := hour+1 m:=0 END; reset_h = WHEN hour =23 m=59 THEN hour: = 0 m: =0 END; update_m = WHEN m <59 THEN m: = m+1 END END Figure 11. L horloge en event-b, et son raffinement [95] Cette introduction courte des deux formalismes va nous permettre de décrire les solutions qu ils apportent à l expression et à la validation des systèmes ODP. I Notations Event-B Les notations Event-B sont basées sur celles de la théorie des ensembles. Nous allons présenter les notations fréquemment utilisées dans nos modèles ci-après. Soit A et B deux ensembles, le constructeur relationnel ( ) définit l ensemble des relations entre A et B comme suit : A B =P (A B) 34

44 Chapitre I : État de l art Où est le produit cartésien de A et B. L élément a A et b B sont en relation R A B est schématisé par : a b. Le domaine de la relation R A B est l ensemble d éléments de A que R relie à un élément de B noté : Dom (R) = {a a A b. (b B a b R)} De la même manière, le rang de la relation R A B est l ensemble d éléments de B reliés à un élément de A et est défini par : Ran (R) = {b b B a. (a A a b R)} Une relation R A B peut être projetée sur un domaine U A. cette relation est appelée restriction de domaine ( ) U R = {a b a b R a U} L anti-restriction de domaine (U R) est définie par : U R = {a b a b R a U} L image relationnelle R [U] où U A est définie par : R [U] = {b a. a b R a U} Le relationnel inverse (R 1 ) de la relation R est défini par : R 1 = {b a a b R} Soient R 0 A B et R1 A B deux relations définies sur les ensemble A et B, l opérateur de surcharge relationnel (R 0 <+ R 1 ) remplace les schémas en relation R 0 par ceux en relation R 1. R 0 <+ R 1 = (dom(r 1 ) R 0 ) R 1 35

45 Chapitre I : État de l art Une fonction est une relation avec certaines restrictions. La fonction peut être une fonction partielle ( ) ou totale ( ). Une fonction partielle d un ensemble A vers B (A B) est une relation reliant un élément de A avec au plus un élément de B. Une fonction totale de A vers B (A B) est une fonction partielle telle que dom(f)=a. c.à.d. chaque élément de A est relié exactement un élément de B. étant donné, f A B et a dom(f), f(a) représente la valeur unique transformant «a» par f. I Le système Event-B Les fondements mathématiques pour le développement du système par event-b sont discutés dans [28]. Une machine abstraite se compose des clauses ensembles, constantes et variables modélisées par des constructions de la théorie des ensembles. Les invariants et les propriétés sont définis comme des prédicats du premier ordre. Le système d événements est défini par ses états et contient plusieurs événements. L état est défini par des variables. Les constantes et les variables sont contraintes par des conditions définies dans les clauses «invariant» et «properties» appelés propriétés des invariants du système. Chaque événement dans le modèle abstrait est composé d'un garde et d une action. L exemple d une machine abstraite simple est donné ci-dessous. MACHINE M SETS S1, S2, S3... CONSTANTS C PROPERTIES P VARIABLES v1, v2, v3 INVARIANTS I INITIALISATION init EVENTS E1 = WHEN G1 THEN S1 END; END 36

46 Chapitre I : État de l art Dans la syntaxe du garde (WHEN G THEN S END), les gardes des événements sont exprimés sous forme de prédicat du premier ordre. Les événements se produisent spontanément chaque fois que leur garde est vrai et ils sont exécutés de façon atomique. Après avoir construit le modèle d'un système comme machine abstraite, il faut prouver que le système respecte les propriétés des invariants. La machine est dite cohérence si chaque événement du système préserve l'invariant. I.5.3. Plateforme RODIN La plate-forme Rodin est un outil libre mis en œuvre sur Eclipse [70] [71]. Il a été développé dans le cadre du projet européen Rodin pour supporter le développement de systèmes basé sur la méthode B [94]. L'objectif de RODIN est de créer une méthodologie unifiée et des outils supportant le développement rigoureux des systèmes. Le développement de logiciels corrects nécessite la vérification de la spécification formelle. Par exemple, il faut vérifier que le modèle B événementiel ne viole pas son invariant. Les autres conditions d exactitude sont liées au raffinement ou aux propriétés associées à des constantes [71]. Les obligations de preuve qui doivent être vérifiées peuvent être extraites systématiquement à partir d'un modèle B événementiel. Par exemple, une obligation de preuve stipule que l'initialisation d'un modèle B événementiel doit respecter l'invariant. Outre l'analyseur de spécifications, la plate-forme RODIN contient un générateur d'obligations de preuves, un démonstrateur automatique, un démonstrateur interactif et un générateur de code [94]. C est un outil puissant et indispensable pour exploiter le potentiel de la méthode B-événementiel. Son rôle est moins d'aider à réaliser des tâches fastidieuses que de révéler les erreurs : l'échec d'une preuve signe une erreur de spécification. De ce fait, nous utilisons Rodin et nous nous reposons beaucoup sur lui pour spécifier et prouver les machines B proposées. I.6. 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, 37

47 Chapitre I : État de l art 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 (RM-ODP, partie 1, clause 8.1.1) [1]. 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. Par ailleurs et en dépit de la grande richesse de RM-ODP, ses langages de point de vue possèdent une sémantique informelle qui n est décrite qu en langage naturel. Nous avons présenté trois méthodes de spécification formelles: la sémantique dénotationnelle, l ingénierie dirigée par les modèles et la méthode B. Dans des travaux antérieurs, nous avons utilisé les deux premières approches pour la précision de la sémantique des systèmes ODP [81-84]. Dans cette thèse nous avons proposé l utilisation de la méthode B pour rendre cette sémantique plus précise et profiter des outils supportants les spécifications B en particulier la plateforme Rodin. La méthode B est une méthode formelle qui couvre toutes les étapes de développement du logiciel, de la spécification jusqu à la génération de code exécutable, par une succession d étapes de raffinement. Elle se présente comme une méthode de développement formelle mettant en valeur aussi bien les aspects statiques que dynamiques d un système, en particulier un système ODP. D un côté, les aspects statiques sont définis au moyen de concepts mathématiques de la théorie des ensembles et de la logique des prédicats, et d un autre côté, les aspects dynamiques sont modélisés en utilisant le langage des substitutions généralisées. Dans notre travail, nous allons exploiter ces deux caractéristiques d une spécification B en vue d en dériver des machines B qui spécifient les systèmes répartis. Il n est certes pas possible de décrire d une manière exhaustive, tous les fondements théoriques de B, nous nous en sommes tenus, dans ce chapitre, aux notions essentielles qui sont en rapport avec la problématique à laquelle nous nous intéressons. En somme, les points forts de la méthode B sont : la modularité du développement, la preuve des propriétés du système, la génération automatique du code et la disponibilité d outils adéquats. 38

48 CHAPITRE II : MODELES B POUR LA SPECIFICATION DES CONCEPTS DE BASE DU POINT DE VUE ENTREPRISE II.1. Introduction Le modèle RM-ODP [1-4] est de plus en plus utilisé pour la modélisation des systèmes répartis ouverts complexes, tels que ceux des domaines des télécommunications, des finances, de l'éducation et de la défense. Bien que certains langages de point de vue ODP, en particulier d ingénierie et de traitement, sont développés dans des détails suffisants pour décrire la programmation et les objets d'architecture de tout système distribué, ce n'est pas le cas du langage d'entreprise. D'autre part, la disponibilité et la maturation des plateformes d'infrastructure distribués, tels que CORBA [11], DCOM, DCE et Java-RMI encourage de plus en plus l'utilisation des objets distribués pour les applications de gestion. En conséquence, les intérêts de la communauté informatique s orientent de plus en plus vers les spécifications de l'entreprise que vers les questions de plate-forme. Il y a une demande croissante de l'industrie à utiliser les spécifications d'entreprise pour améliorer la précision de la conception des systèmes distribués, en particulier ceux qui traitent les aspects administratifs et organisationnels [44]. Le langage d'entreprise ODP existant, composé d'un nombre limité de concepts et de règles de structuration, a besoins des extensions et des raffinements afin d'être mieux adapté pour la modélisation d entreprise des systèmes répartis ouverts. Par exemple, il y a un besoin imminent pour une spécification rigoureuse des politiques régissant le comportement des systèmes complexes et des sous-systèmes automatisés. Ces politiques doivent être explicites parce que leur surveillance et leur application nécessitera des actions mises en œuvre par le système, et l'exactitude de telles actions ne peut être garantie que s il existe un cadre bien défini pour la description des concepts tels que l objectif et la politique. 39

49 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Pour modéliser les spécifications d'entreprise des systèmes répartis ouverts, nous utiliserons les concepts fournis par le point de vue entreprise de RM-ODP [45]. Ce point de vue se concentre sur l'objectif, la portée et les politiques pour le système et son environnement. Il décrit les besoins d'entreprise et comment y répondre, mais sans avoir à se soucier des autres considérations du système, tels que notamment les détails de sa mise en œuvre, ou la technologie utilisée pour implémenter le système. Plus précisément, ce chapitre met l'accent sur un sous-ensemble de concepts d'entreprise, notamment sur les notions de communauté, rôle, processus, objet d entreprise, action et politiques (autorisations, interdictions et obligations), et essaie de fournir un cadre plus précis pour raisonner sur ces concepts fondamentaux du point de vue entreprise. Il vise à permettre la spécification précise des exigences d'entreprise. Nous utilisons le formalisme event-b comme cadre formel pour l'élaboration des concepts de base du point de vue entreprise. Event-B [96] est une méthode, supportée par des outils, pour la spécification formelle des systèmes. On peut donc bénéficier du formalisme ; pour raisonner sur les systèmes distribués, basé sur les techniques de raffinement et les outils associés. La Plate-forme Rodin pour Event-B fournit un outil efficace pour le raffinement et la preuve mathématique. [94]. La structure de ce chapitre se présente comme suit. Tout d'abord, les sections 2 et 3 servent de brèves introductions aux RM-ODP et event-b, respectivement. Ensuite, la section 4 décrit notre proposition de spécifier les concepts d'entreprise par la méthode event-b. Enfin, la section 5 tire des conclusions et décrit certaines activités de recherche futures. II.2. Langage d entreprise de RM-ODP RM-ODP [1-4] fournit cinq points de vue génériques et complémentaires sur le système et son environnement: entreprise, information, traitement, ingénierie et technologie. Ils offrent différents points de vue d'abstraction, permettant aux participants d'observer un système dans différentes perspectives [46]. 40

50 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Le langage d'entreprise propose les concepts fondamentaux qui sont nécessaires pour représenter un système ODP dans le contexte de l'entreprise dans laquelle il fonctionne [1]. Le but d'une spécification d'entreprise est d'exprimer les objectifs et les contraintes d'ordre politique qui pèsent sur le système considéré. A cette fin, le système est représenté par un ou plusieurs objets d'entreprise au sein d'une communauté d'objets d'entreprise qui représente cette entreprise et par les rôles auxquels participent ces objets. Ces rôles représentent, par exemple, les utilisateurs, les propriétaires ou les fournisseurs de l'information que traite le système. En créant un point de vue séparé pour transmettre cette information, on découple la spécification des objectifs assignés à un système de la manière dont ce système doit être réalisé. Une des idées principales qui apparaît dans le langage d'entreprise est celle d'un contrat qui lie les acteurs des différents rôles au sein d'une communauté et exprime leurs obligations mutuelles. Un contrat peut exprimer les buts communs et les responsabilités qui particularisent les rôles dans une communauté, telle qu'une entreprise et ses clients ou qu'une administration et ses assujettis, comme s'ils étaient associés d'une manière particulière au sein d'une même entreprise. Là où la nécessité en apparaîtra, la spécification d'entreprise exprimera aussi des aspects relatifs à la propriété des ressources et aux responsabilités portant sur le paiement des marchandises et des services afin de déterminer, par exemple, les contraintes qui pèsent sur les opérations comptables et les mécanismes de sécurité au sein de l'infrastructure qui soustend le système. Il existe un type particulier de communauté, la fédération, qui est l'association d'un certain nombre de groupes qui, ressortissant à des autorités différentes et pouvant être représentés sous forme de domaines distincts, cherchent à coopérer pour atteindre un objectif commun. Comme l'évolution des systèmes répartis entraînera, pour partager les informations ou prendre en charge les intérêts commerciaux, une succession de fusions de sous-systèmes existants distincts et séparément gérés, la spécification de la création de fédérations et l'expression des règles applicables à ces structures constituent une part importante de la spécification des systèmes dans le point de vue entreprise. 41

51 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Les domaines considérés dans une fédération sont soit administratifs, chacun d'eux pouvant, par exemple, répondre à des règles particulières de sécurité ou de gestion, soit techniques, chacun d'eux acceptant, par exemple, un même choix de logiciels ou de matériels. La spécification d'une fédération comporte celle des objectifs en matière d'interfonctionnement entre les différents domaines et des politiques qui régissent ces interfonctionnements. Une fédération de domaines administratifs concerne l'interfonctionnement entre domaines appartenant à une même entreprise ou à différentes entreprises en vue du partage, de l'intégration et de la répartition des ressources entre les systèmes et les lieux en réponse aux besoins des utilisateurs. Une fédération de domaines techniques concerne l'intégration de systèmes qui diffèrent par leurs architectures, leurs ressources ou leurs performances; elle apporte la modularité qui autorise une croissance par étapes sans impact sur les applications en service. Les deux types de fédération coïncident souvent car des différences au plan administratif peuvent conduire à des différences quant aux choix de solutions techniques. Entre domaines administratifs, l'une ou l'autre des administrations, ou les deux, peut vouloir imposer ses propres contrôles d'accès pour des raisons de sécurité, de gestion comptable et de surveillance, en plus des contrôles qu'imposent les objets eux-mêmes. C'est aux frontières administratives que s'effectue aussi le transfert des responsabilités de gestion, celles, par exemple, de l'allocation des ressources et de la garantie de sûreté de fonctionnement. Parmi les politiques qui régissent le fonctionnement des fédérations figurent celles qui régissent les questions d'interfonctionnement. La spécification d'une fédération peut ainsi se rapporter à la spécification d'une fonction d'intercepteur dans la description d'ingénierie; les objectifs et les contraintes portant sur la fédération déterminent les contraintes qui pèsent sur la fourniture des services d'interception. Une spécification d'entreprise définit les politiques qui régissent le comportement des communautés qu'elle spécifie. Ces politiques déterminent les actions exercées par les objets d'entreprise qui participent à ces communautés. Elles s'intéressent aux questions touchant à l'assignation et à l'accomplissement des obligations comme, par exemple, demande de 42

52 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise livraison ou livraison, et à l'autorisation ou à l'interdiction des actions comme, par exemple, permission ou déni d'accès aux ressources du système. Les politiques peuvent concerner: a) La structuration de la communauté en termes de rôles et l'affectation des rôles aux objets d'entreprise. Des règles communautaires, par exemple, peuvent énoncer: comment sont assignés les rôles et les responsabilités des objets d'entreprise au sein de la communauté; comment les objets d'entreprise se relient à la structure communautaire (par exemple, hiérarchie ou égalitarisme). Une spécification d'entreprise peut aussi comporter des règles d'entreprise qui expriment: l'entreprise en tant qu'entité faisant des affaires; les exigences portant sur la gestion comptable; l'évolution de l'entreprise pour accomplir ses objectifs. b) Les interactions autorisées entre objets d'entreprise tenant différents rôles, c'est-à-dire le contrôle d'accès. Des règles de sécurité, par exemple, peuvent définir: les relations entre rôle, activité et objet, ainsi que les exigences qu'elles portent sur les activités et les objets en matière d'intégrité et de confidentialité; les règles applicables à la détection des menaces pesant sur la sécurité; les règles applicables à la protection contre les menaces pesant sur la sécurité; les règles applicables à la limitation des dommages causés par toute atteinte à la sécurité. 43

53 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise c) La responsabilité déléguée aux objets de l'entreprise. Des règles de délimitation d'autorité, par exemple, servent à affecter: des privilèges aux objets d'entreprise (confiance); l'autorisation donnée ou l'interdiction faite aux objets d'entreprise de mener des actions. d) La comptabilisation de l'usage des ressources. Des règles d'usage des ressources, par exemple, définissent les contraintes que peuvent imposer de l'extérieur: des organismes de réglementation; les demandes du marché; l'environnement; Selon que l'usage fait de la ressource est: public, privé ou de tierce partie. e) La propriété des ressources. Des règles de transfert, par exemple, peuvent formuler les changements de propriétaire ou de responsable des ressources parmi les objets d'entreprise. f) Le sociétariat des fédérations. La spécification d'entreprise peut par exemple inclure des règles de domaine qui spécifient: les règles applicables au sociétariat d'un domaine; les règles applicables aux interactions entre domaines du même type; les règles applicables à la désignation dans un domaine. Il est prévu qu'il existera différentes notations pour exprimer les spécifications d'entreprise dans le cas de structures d'organisation et d'usages commerciaux particuliers. Le modèle de référence ODP exige que soit établie une spécification adéquate, mais impose peu de contraintes sur la forme que doit prendre l'organisation. L'évaluation de la conformité à la spécification d'entreprise d'un système demande de lier les exigences exprimées dans la spécification, qui sont du genre temps de réponse pour accomplir 44

54 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise une obligation donnée, à des ensembles d'observations du comportement du système effectuées en des points de conformité précisés dans les spécifications d'ingénierie et de technologie et de mesurer le degré de cohérence entre les exigences et les observations. II.3. Cohérence du point de vue entreprise avec les autres points de vue Le langage d'entreprise devrait servir de base pour la spécification des buts de l'entreprise que toutes les autres spécifications de point de vue doivent refléter, explicitement ou implicitement. Le point de vue entreprise décrit explicitement les objectifs du système en termes de sociétariat, de rôles, d'actions, d'intentions, d'usage et de politiques [1]. Une spécification de point de vue d'information, de traitement, d'ingénierie ou de technologie est donc cohérente avec la spécification d'entreprise si tous les rôles, activités et politiques que décrit la spécification d'entreprise sont correctement reflétés. Par exemple, les schémas dynamiques définis dans une spécification d'information doivent respecter les politiques décrites dans la spécification d'entreprise. Des rôles différents que reconnaît la spécification d'entreprise peuvent se voir pris en charge par des objets de calcul différents, qui présentent des exigences de transparences différentes. Donc les besoins de transparence afférents à chaque rôle de la spécification d'entreprise devraient se refléter sur l'emploi des mécanismes correspondants dans la spécification d'ingénierie. Une exigence de souplesse ou une politique exprimée dans la spécification d'entreprise peuvent amener à faire le choix de solutions techniques particulières pour la réalisation d'un système réparti. II.4. Concepts de base du langage d entreprise de RM-ODP Le point de vue entreprise se concentre sur l'objectif, la portée et les politiques pour le système [45] et son environnement. Ci-dessous, nous résumons les concepts de base du point de vue entreprise. La communauté est le concept clé du point de vue d entreprise. Elle est définie comme une configuration d'objets d'entreprise formée pour répondre à un objectif. L'objectif est exprimé comme un contrat qui spécifie comment l'objectif peut être atteint [43]. 45

55 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Un contrat est un concept générique qui spécifie un accord régissant le cadre du comportement collectif d'un ensemble d'objets. Un contrat précise les obligations, les permissions et les interdictions applicables aux objets concernés. La portée du système est définie en termes de comportement prévu, et cela est exprimé en termes de rôles, de processus, de politiques, et de leurs relations. Les rôles identifient les abstractions du comportement de la communauté, et sont remplis par des objets d'entreprise de la communauté. Le processus décrit le comportement de la communauté par un ensemble d'actions (partiellement ordonné), qui sont associées pour la réalisation de certains sous-objectifs particuliers au sein de la communauté. Enfin, les politiques sont les règles qui contraignent le comportement et les membres des communautés afin d'atteindre leurs objectifs. Une politique peut être exprimée comme une obligation, une permission ou une interdiction: -Obligation: Une prescription qu un comportement particulier est nécessaire. Une obligation est remplie par l'apparition du comportement prescrit (RM-ODP, part 2, clause ). -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 ). -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 ). En général, les systèmes ODP sont modélisés en termes d'objets. Un objet est un modèle d'une entité qui contient des informations et offre des services. Un système se compose donc d objets qui interagissent. Dans le cas du point de vue entreprise, on parle d objets d'entreprise, qui modélisent les entités définies dans une spécification d entreprise [48]. 46

56 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Un objet d'entreprise est un objet qui remplit un ou plusieurs rôles dans une communauté. Il peut aussi participer à plus d'une communauté à un moment donné [43]. Figure 12. Concepts de base du point de vue entreprise [43]. II.5. Spécification informelle des concepts de base du langage d entreprise II.5.1. Niveaux abstraits et concrets des concepts de base du langage d entreprise L'interaction des différents utilisateurs avec les systèmes informatiques génèrent différents besoins de restriction pour garantir que chaque utilisateur du système bénéficie de ses 47

57 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise prestations sans empiéter sur les droits d'un autre utilisateur. Ces besoins varient selon le domaine d'activité requis. Ces restrictions peuvent concerner: la confidentialité (Non divulgation des informations sensibles à des personnes non autorisées), l'intégrité (non altération des informations sensibles), la disponibilité (Fourniture d'informations aux utilisateurs, selon leurs droits d'accéder à ces informations), vérifiabilité (La capacité de retracer et de déterminer les actions menées dans le système). Ces exigences mènent généralement à exprimer des politiques, définir pour chaque utilisateur ses permissions, ses interdictions et ses obligations. Ces utilisateurs (ou type d'objets : client, serveur, administrateur, trader, créateur de politiques) sont des entités actives opérant sur les objets d'entreprise (entités passives) du système. En résumé, une spécification d'entreprise est composée des spécifications des éléments mentionnés précédemment, à savoir les communautés du système (des ensembles d'objets d'entreprise), les rôles (les identificateurs du comportement), les processus (ensembles d'actions menant à un objectif), les politiques (les règles qui régissent le comportement et les membres des communautés pour atteindre un objectif), et leurs relations [45]. Un contrat précise les obligations, les permissions et les interdictions applicables aux objets compris dans une communauté. Tout comme pour les objets, les actions sont également regroupées dans des processus, ce qui implique qu'il y a deux niveaux d'abstraction pour les concepts du point de vue entreprise (Belhaj et al, 2010) [49]: - Niveau abstrait regroupant les concepts: rôles, processus et point de vue entreprise du système sur lesquels diverses permissions, interdictions et obligations sont exprimées. - Niveau concret regroupant les concepts : type d'objet (client, serveur, décideur de la politique, administrateur de la politique), actions (création, suppression) et objets d'entreprise du système. 48

58 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Types d'objet, actions et objets d'entreprise sont respectivement affectés aux rôles, processus et point de vue entreprise par des relations définies sur ces entités (voir figure 13). Nous détaillons ces relations dans la prochaine sous-section. II.5.2. Relations entre niveaux abstrait et concret : Play, Use et belong II Affectation du type d'objets à des rôles: Les types d'objets sont affectés à un ou plusieurs rôles afin de définir leurs privilèges. Les types d'objets jouent leur rôle dans les communautés, ce qui implique que ces objets sont affectés à des rôles à travers une relation ternaire comprenant la communauté, comme suit : Play (com, Ot, r): signifie que le type d'objet «Ot» joue le rôle «r» dans la Communauté «com». II Affectation d'actions à des processus: Pareil pour les rôles et les types d objets, les processus constituent une abstraction de diverses actions autorisées dans le système. La relation entre actions et processus est également une relation ternaire qui comprend la communauté: Belong (com, a, p): signifie que l'action «a» est considérée comme un processus «p» dans la Communauté «com». II Assignation des objets d'entreprise au point de vue entreprise: La relation liant les objets d'entreprise au point de vue entreprise à laquelle ils appartiennent est aussi une relation ternaire comprenant la communauté: Use (com, o, v): signifie que la Communauté «com» utilise l'objet «o» dans le point de vue entreprise «v». 49

59 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Permission Obligation Prohibition (com, role, process, enterprise viewpoint,) Play Belong Use Abstract level Concret level (object type, action, enterprise object ) Figure 13 Niveaux abstraits et concrets des concepts de base du point de vue entreprise [49]. II.5.3. Modélisation informelle des concepts de base du point de vue entreprise Lorsque des types d objets, les actions, et les objets d entreprise sont respectivement affectés à des rôles, des processus et au point de vue entreprise, il est maintenant possible de décrire la politique. Elle consiste à définir différentes permissions, interdictions et obligations: - Permission (com, r, p, v): signifie que la communauté «com» donne au rôle «r» la permission d'effectuer le processus «p» dans le point de vue entreprise «v». - Interdiction (com, r, p, v): signifie que la Communauté «com» interdit au rôle «r» d'effectuer le processus «p» dans le point de vue entreprise «v». - Obligation (com, r, p, v): signifie que la Communauté «com» exige au rôle «r» de réaliser le processus «p» dans le point de vue entreprise «v». 50

60 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Dans les situations où deux ou plusieurs groupes d'objets, sous le contrôle de différentes Autorités, s'engagent dans une coopération pour répondre à un objectif commun, elles forment une sorte spécifique de communauté appelée fédération. Les hiérarchies permettent l'héritage des privilèges (permissions, interdictions ou obligations), si par exemple «r2» est un sous-rôle de «r1», pour une communauté «com», un processus «p» et un point de vue entreprise «v»: Si permission (com, r1, p, v) est vrai, alors permission (com, r2, p, v) est vrai. Si interdiction (com, r1, p, v) est vrai, alors interdiction (com, r2, p, v) est vrai. Si obligation (com, r1, p, v) est vrai, alors obligation (com, r2, p, v) est vrai. De la même façon pour les communautés, si com2 est une sous-communauté de com1 alors, pour un rôle «r», un processus «p» et un point de vue entreprise «v»: Si permission (com1, r, p, v) est vrai, alors permission (com2, r, p, v) est vrai. Si interdiction (com1, r, p, v) est vrai, alors interdiction (com2, r, p, v) est vrai. Si obligation (com1, r, p, v) est vrai, alors obligation (com2, r, p, v) est vrai. II.6. Spécification des concepts de base du point de vue entreprise par la méthode event-b L'expression des concepts de base du point de vue entreprise en event-b comprend plusieurs étapes successives. Un premier modèle B est établi, puis d'autres raffinements successifs sont réalisés comme le montre la figure 14. Le premier raffinement valide le lien entre le niveau abstrait (rôle, communauté, processus) et le niveau concret (type d'objet, action, objet d entreprise). L'approche est basée sur le raffinement et chaque modèle ou modèle de raffinement est enrichi par les contraintes exigés par la spécification du système. Chaque contrainte est exprimée par un invariant. L'invariant devient plus complexe après chaque raffinement. 51

61 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Politiques ODP Contrôle de la Cohérence Modèle B abstrait comprenant les politiques permissions, obligations et interdictions Raffinement Modèle B Concret comprenant les politiques permissions, obligations et interdictions Specification des politiques par event B Continuer le développement du système par B Raffinement Figure 14. Etapes de conception d un modèle event-b des concepts d entreprise ODP [49] II.6.1. Modèle abstrait tenant compte des politiques ODP Comme présenté auparavant, la spécification d'entreprise a deux niveaux d'abstraction (voir figure 13). La première étape consiste en un modèle B spécifiant la partie abstraite de la politique, c'est à dire que, les concepts considérés sont ceux de la communauté, rôle, point de vue entreprise et processus. Dans le premier modèle, les permissions, les obligations et les interdictions doivent être décrites. - La clause SETS contient les ensembles de base représentant la communauté, les rôles, les processus et le point de vue entreprise comme suit : COMS, ROLES, PROCESSES, ENT VP. Les clauses CONSTANTS et PROPERTIES contiennent des constantes comme la permission, l'obligation et l'interdiction qui vont contenir des privilèges de la description du système ODP. 52

62 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Deux nouvelles constantes sub_role et sub_com sont introduites pour prendre en compte respectivement la hiérarchie du rôle et de la communauté. Il suffit de préciser quels rôles et quelles communautés sont concernées par l héritage, et les permissions, les obligations et les interdictions correspondant aux héritages sont générées par déduction. SETS CONSTANTS COMS; ROLES; permission, prohibition, ROCESSES;ENT VP; obligation, sub_com, sub_role PROPERTIES permission COMS ROLES PROCESSES ENT VP prohibition COMS ROLES PROCESSES ENT VP obligation COMS ROLES PROCESSES ENT VP sub_com COMS COMS sub_role ROLES ROLES / * Hiérarchie des communautés * / (com1, com2, r, p, v). ((com1 COMS com2 COMS r ROLES p PROCESSES v ENT VP (com1 com2) sub_com (com2 r p v) permission) (com1 r p v) permission) / * Hiérarchies des rôles * / (com, r1, r2, p, v). ((r1 ROLES r2 ROLES com COMS p PROCESSES v ENT VP (r1 r2) sub_role (com r2 p v) permission) (com r1 p v) permission) / * Same properties for prohibitions and obligation * / 53

63 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Dans un cas particulier, il suffit d'initialiser les ensembles de la clause SETS par les entités, communautés, rôles, point de vue entreprise, processus. Les propriétés des constantes, comme la permission, l'interdiction, l obligation, sub_role et sub_com, devrait également être défini dans la clause PROPERTIES. En conséquence, les permissions, les interdictions et obligations ne peuvent pas être modifiés, puisqu ils sont définis comme des constantes. Introduction des variables d'état. Un modèle event-b exprime des propriétés sur l'état et sur les variables d'état. Les variables sont utilisées pour modéliser l'état du système par rapport aux politiques: La clause VARIABLES contient la variable d état hist_abst qui contient l'historique des processus système et qui satisfait les propriétés suivantes ajoutées dans l'invariant: INVARIANT Hist_abst COMS ROLES PROCESSES ENT VP Hist_abst permission La valeur initiale de la variable est attribuée comme suit : hist_abst := Comme la politique est censée être compatible, nous devons être en mesure de prouver dans la clause ASSERTIONS : ASSERTIONS Permission prohibition= Hist_abst prohibition = permission obligation = hist_abst obligation = La clause EVENTS contient l événement suivant : L événement action modélise une demande de permission d'un type d'objet pour l'accès à un objet d'entreprise du système. 54

64 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise action any com, r, v, p where com COMS r ROLES v ENT VP p PROCESSES (com r p v) permission then hist_abst := hist_abst {(com r p v)} end L'invariant doit être préservé et cela signifie que tout processus dans le système est contrôlé par la politique à travers la variable hist_abst. II.6.2. Raffinement: Modèle concret tenant compte des politiques ODP Nous avons défini deux niveaux d'abstraction et le modèle abstrait défini est raffiné en un modèle concret. Le raffinement introduit les types d'objets, les actions et les objets d'entreprise: Les ensembles OBJTYPES, ACTIONS et ENTOBJ contiennent respectivement les types d'objets, les actions et les objets d'entreprise du système en cours de développement. La clause CONSTANTS comprend les constantes suivantes: play (affectation des types d'objets à des rôles), use (affectation des objets au point de vue entreprise) et belong (Affectation d'actions à des processus). Les propriétés des constantes sont définies comme suit: PROPERTIES Play COMS OBJTYPES ROLES Use COMS ENTOBJ ENT VP Belong COMS ACTIONS PROCESSES 55

65 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Variables concrètes : Une nouvelle variable hist_conc modélise le contrôle du système en fonction de la politique, il contient l'historique des actions effectuées par un type d'objet sur un objet d entreprise donné. La relation entre hist_conc et la variable hist_abst du modèle abstrait est exprimée dans l'invariant de collage, la première partie de l invariant définit les propriétés satisfaites par les variables en respect des permissions. INVARIANT (ot, a, o).( (ot OBJTYPES a ACTIONS o ENTOBJ (ot a o ) hist_conc) ( (com, r, p, v).(com COMS r ROLES p PROCESSES v ENTVP (com ot r) play (com o v) use (com a p) belong (com r p v) hist_abst))) L invariants garantit que chaque action effectuée par le système satisfait la politique. Pour les interdictions, quand un type d objet «ot» veut effectuer une action «a» sur un objet «o» dans une communauté «com», il est nécessaire de vérifier qu'aucune interdiction n existe pour cette action. La deuxième partie de l invariant précise les propriétés satisfaites par les variables en ce qui concerne les interdictions et les obligations: INVARIANT (ot, a, o).( (ot OBJTYPES a ACTIONS o ENTOBJ (ot a o) hist_conc) ( (com, r, p, v). (com COMS r ROLES p PROCESSES v ENTVP (com ot r) play (com o v) use (com a p) belong) (com r p v) prohibition) (com r p v) obligation)) 56

66 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise action any ot, a, o, com, r, v, p where ot OBJTYPES a ACTIONS o ENTOBJ com COMS r ROLES p PROCESSES v ENTVP (com ot r) play (com o v) use (com a p) belong / permission / (com r p v) permission / prohibition and obligation / ( (comi, ri, pi, vi).((comi COMS ri ROLES pi PROCESSES vi ENTVP (comi ot ri) play (comi o vi) use (comi a pi) belong) ((comi ri pi vi) prohibition) (comi ri pi vi) obligation)) Then hist_conc := hist_conc {(ot a o)} End Les événements. Le modèle abstrait doit tenir compte des permissions, des interdictions et des obligations pour un type d'objet «ot» qui demande d'effectuer une action «a» sur un objet d entreprise «o». II.7. Conclusion Le modèle de référence pour le traitement réparti ouvert (RM-ODP) est une méta-norme pour d'autres normes ODP. Nous avons abordé dans ce chapitre la nécessité de langages formels dans les points de vue ODP. En effet, les langages de point de vue ODP définissent quels concepts doivent être définis et non la façon dont ces concepts doivent être représentés. L'utilisation des méthodes formelles dans le processus de conception des systèmes ODP est explicitement requise. Un point important à prendre en compte est l'incorporation de nombreuses preuves qui doivent être effectués afin de s'assurer que le système final soit en effet «correcte par construction». 57

67 CHAPITRE II : Modèles B pour la spécification des concepts de base du point de vue entreprise Dans ce chapitre nous avons présenté notre approche pour le développement des systèmes répartis. Nous avons utilisé event-b pour la modélisation des concepts de base du point de vue entreprise d ODP. Les modèles B conçus ont été implémenté sur la plateforme Rodin. Afin de vérifier nos modèles, le modèle abstrait et de raffinement des politiques ODP sont développés à l'aide de la méthode event-b, chaque modèle est analysé et vérifié par l outil Rodin. Ce chapitre montre que les techniques d'abstraction et de raffinement sont très intéressantes pour la modélisation de systèmes distribués complexes. 58

68 CHAPITRE III : SPECIFICATION ET VERIFICATION DE LA FONCTION DE COURTAGE PAR EVENT-B III.1. Introduction Une des propriétés d'un système distribué est que l utilisateur ne connaît pas nécessairement les emplacements des machines ni les systèmes d exploitation sur lesquels leurs applications fonctionnent. De tels systèmes sont très complexes. Cependant, le traitement réparti est en pleine croissance, principalement en raison de la capacité de l'industrie de l'informatique à produire des ordinateurs plus puissants à moindre coût. En conséquence, la définition de standards pour le traitement réparti ouvert devient nécessaire. Un trader [6] est un objet qui effectue le courtage qui est une fonction commune ODP. ODP vise à fournir une utilisation de services transparente à la distribution sur des environnements hétérogènes. Pour utiliser les services, les utilisateurs doivent être conscients des prestataires de services potentiels et capables d'y accéder. Du moment que les sites et les applications sont susceptibles de changer fréquemment dans les systèmes distribués, il est avantageux de permettre une liaison tardive entre les utilisateurs et les fournisseurs de service. Pour cela, un composant doit être en mesure de trouver des fournisseurs appropriés de services de façon dynamique. La fonction de courtage ODP [6] prévoit cette sélection dynamique de fournisseurs de services au moment de l'exécution. Les langages Z, SDL, LOTOS, et Estelle sont utilisés dans la sémantique architecturale de RM-ODP [4] pour la spécification des concepts ODP. Toutefois, aucune méthode formelle n est susceptible d'être adapté pour spécifier tous les aspects d'un système ODP. Par ailleurs, l'approche de méta-modélisation a été utilisée dans [64] [82] pour définir la syntaxe d'un sous-langage pour la spécification de la QoS-ODP du point de vue entreprise. Nous avons défini un méta-modèle pour la sémantique des concepts de base d un système ODP dans le point de vue entreprise [81] basée sur UML et OCL. 59

69 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b Nous avons également utilisé les deux approches : méta-modélisation et dénotationnelle pour spécifier de manière précise les concepts de comportement dans la partie fondement et dans le langage de point de vue entreprise [83] [84] [91]. Aussi, avons-nous introduit un profile UML pour les processus automatisés de comportement avec un transformateur automatique d UML à BPEL [47]. En outre, pour la vérification des systèmes ODP [2] [3], les techniques de tests actuelles [56] [57] ne sont pas largement acceptées. Une nouvelle approche de test, nommée programmation agile [58] ou l approche de test first [59] est de plus en plus adoptée. Le principe est l'intégration du modèle du système et le modèle de test en utilisant l approche de métamodélisation UML [60]. Cette approche est basée sur l'uml exécutable [61]. Dans ce contexte OCL est utilisé pour spécifier les propriétés à tester. Les méta-modèles UML fournissent une base précise pour les testeurs d ODP. Dans ce chapitre, nous utilisons la méthode B comme cadre formel pour le développement de la fonction de courtage dans les systèmes distribués. Event-B [96] est une méthode avec des outils supportant les spécifications B des différents systèmes. Ainsi, on peut bénéficier du formalisme pour raisonner sur les systèmes distribués, caractérisé par les techniques de raffinement, et de l'appui des outils B. La Plate-forme Rodin fournit un outil efficace pour le raffinement et la preuve mathématique [94]. Le chapitre est organisé comme suit. La section 2 présente brièvement RM-ODP et les fonctions ODP. La section 3 donne un aperçu sur la fonction de courtage et détaille ses spécifications dans les cinq points de vue ODP. La section 4, présente une introduction à la notation du B événementielle. Dans la section 5, nous utilisons event B pour spécifier la fonction de courtage. La section 6 présente la plateforme Rodin comme outil de preuve pour les machines B définies. Enfin, la section 8 conclut le chapitre. III.2. Fonctions ODP III.2.1. RM-ODP Le modèle de référence RM-ODP [1-4] fournit un cadre dans lequel la répartition, l'interfonctionnement et la portabilité peuvent être intégrés.il consiste en quatre parties. La 60

70 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b partie architecturale contient les spécifications des caractéristiques requises pour qualifier le système réparti d ouvert. Il définit un cadre de travail composé de cinq points de vue, des langages de points de vue, des fonctions ODP et des transparences ODP. Les cinq points, appelés point de vue entreprise, information, traitement, ingénierie et technologie. Les fonctions ODP sont nécessaires pour supporter les systèmes ODP. Les prescriptions de transparences montrent comment utiliser les fonctions ODP pour assurer la transparence à la répartition. Le modèle de référence identifie un certain nombre de fonctions fondamentales pour la construction des systèmes ODP [5] [6]. 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. III.2.2. Fonctions ODP L'ensemble complet des fonctions ODP se répartit en quatre groupes: a) Fonctions de gestion qui comprennent la gestion de nœud, d objet, de grappe et de capsule. b) Fonctions de coordination qui incluent la fonction de notification d événements, la fonction de point de reprise et de reprise, la fonction de désactivation et de réactivation, la fonction de groupe, la fonction de duplication, la fonction de migration, la fonction de transaction et la fonction de ramasse-miettes pour les références d'interfaces d'ingénierie c) Fonctions de sécurité : traitent des exigences relatives à la confidentialité, à l'intégrité, à la disponibilité et à la capacité de tenir des comptes. Elles comprennent la fonction de contrôle d'accès, la fonction d'audit de sécurité, la fonction d'authentification, la fonction d'intégrité, la fonction de confidentialité, la fonction de non répudiation et la fonction de gestion de clés. Ces fonctions fournissent des services qui sont applicables tant aux objets eux-mêmes qu'aux interactions entre objets. Les mécanismes de sécurité eux-mêmes ont besoin de protection puisque des menaces intelligentes et malignes sont une des caractéristiques des environnements qu'il est nécessaire de sécuriser. L'encapsulation d'ingénierie peut participer à la fourniture de cette protection. Dans de nombreux cas, il est possible d'offrir des services de sécurité sans avoir besoin de recourir à une référence dans les spécifications de traitement. 61

71 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b d) fonctions de conteneur qui comprennent la fonction de stockage, la fonction de gestion de base d'information, la fonction de relocalisation, la fonction de conteneur de types et la fonction de courtage. RM-ODP définit un certain nombre de fonctions de conteneur [5] pour maintenir une base de données des informations spécifiques. Il y a principalement trois fonctions de conteneur: la fonction de relocalisation, la fonction de conteneur de types et la fonction de courtage [6]. La fonction de courtage donne le moyen aux prestataires de services d'exporter des offres de service sous la forme d'informations sur l'interface où est fourni un service et aux utilisateurs de services d'importer les offres de service qui concordent avec leurs exigences particulières. III.3. La fonction de courtage III.3.1. Aperçu général Un trader [6] est un objet tiers qui permet de lier les clients et serveurs dans un système distribué. La figure 15 montre les interactions entre un trader et ses utilisateurs: Le trader accepte l'offre de service des exportateurs (serveurs) lorsqu'un serveur souhaite publier une offre de service. Une offre de service contient les caractéristiques du service que l'exportateur peut fournir. Les offres de service sont stockées, par le trader, dans une base de données centralisée ou distribuée. Un trader accepte une demande de service auprès des importateurs de services (clients) quand un client a besoin d'un service. Un trader recherche dans sa base de données l offre de service qui correspond à la demande de service de l'importateur. Et, si nécessaire, un trader peut choisir l'offre de service le plus approprié (s'il en existe un) qui satisfait la demande de service de l'importateur. La liste d'offres de services ou l'offre de service sélectionnée est retourné à l'importateur. Après un échange réussi, le client peut interagir avec le serveur correspondant. La sélection du service approprié au moment de l'exécution par un trader permet de configurer les objets client dans un système ODP sans connaissance préalable des objets serveur pouvant satisfaire leurs besoins. 62

72 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b Trader Result IMPORTER Import Invoke Export EXPORTER Figure 15. Trader et ses utilisateurs [65]. Il est important de noter que le même objet peut être un exportateur d'un service et un importateur d'un autre service. En fait, un importateur ou un exportateur peut être un autre opérateur. L'importateur et l'exportateur correspondant peuvent être: Co-localisés, Physiquement éloignés les uns des autres, ou Dynamiquement amovibles. La fonction ODP de la transparence à la distribution cache de tels changements d emplacement [3]. III.3.2. Description du trader du point de vue entreprise Dans le point de vue entreprise, les objectifs, les exigences fonctionnelles, et les politiques qui régissent les activités du trader sont identifiés. Un trader est le centre d'une communauté établie dans le but de courtage. Les activités de courtage de la communauté sont l exportation et l importation de services, et sont régis par une politique du courtage du trader. La communauté se compose de membres (agents) qui ont des rôles tels que: trader, exportateur, importateur, administrateur de courtage et fabricant de la politique du courtage. Un objet peut avoir plusieurs rôles au sein de la même communauté. Par exemple, un objet peut être à la fois un importateur et un exportateur, un objet peut être à la fois le décideur et l'administrateur de la même communauté du trading. 63

73 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b Chaque importateur peut aussi avoir une politique d'importation propre qui limite l'ensemble d'offres de services examinés par un trader dans un service d'importation. Chaque exportateur peut également avoir sa propre politique d'exportation qui restreint l'ensemble des importateurs aux quels un trader peut transmettre une offre de service. Le processus d importation de service effectué par un trader est donc régi par: La politique de courtage de la communauté de courtage, La politique d exportation de l exportateur de l offre de service, et La politique d importation de l importateur [3]. Les politiques sont exprimées sous forme de règles. Les membres de la communauté de courtage sont tenus de respecter les règles. Ces règles fournissent les lignes directrices pour les décisions afin de répondre aux exigences fonctionnelles de la communauté. Les règles les plus importantes sont pour: Les exigences de sécurité pour les importateurs et exportateurs - règles visant à empêcher l'utilisation non autorisée, la divulgation et la modification des offres de service, à détecter les manques de sécurité, etc.; Les exigences de comptabilité - les règles pour déterminer les redevances pour l'importation et l'exportation, la certification de crédit, de contrôle et d'audit, etc.; Les exigences de transfert - règles pour affirmer que les importateurs peuvent importer des offres de service pour leur propre usage ou pour les transmettre à d'autres entités; que les exportateurs peuvent exporter leurs services ou des services fournis par d'autres entités, etc.; Les exigences de qualité de services - les règles d'exigences de performance, les exigences de la cohérence entre ce qui est donné et ce qui est attendu ou entre les valeurs annoncées et la réalité, etc. La spécification d'une exigence d entreprise a des conséquences sur les autres points de vue. Par exemple, pour répondre à l exigence de qualité de service d'entreprise : rapidité de réponse, le modèle d'information peut exiger une répartition particulière de ses informations, 64

74 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b le modèle d'ingénierie peut exiger la réplication de données, et le modèle de la technologie peut exiger une large bande la transmission des données. III.3.3 Description du trader du point de vue information Dans le point de vue information, les éléments d'information, les structures d'information, et les exigences de traitement de l'information du Trader sont identifiés. III Services Un service est une fonction fournie par un objet à une interface de traitement. Il s'agit d'un ensemble de capacités disponibles à l'interface d'un objet, et peut être : Une opération atomique, par exemple : «écrire», Une séquence d opérations, par exemple «ouvrir», «écrire», «fermer», Un ensemble d opérations, par exemple plusieurs opérations «écrire» à exécuter dans n importe quel ordre, non-opérationnel, par exemple fournir/ consommer un flux d informations, chacune avec des propriétés associées. Chaque service est une instance d'un type de service. Associé à chaque type de service est un type d'interface qui détermine le comportement de traitement à l'interface de service. Les interfaces qui sont des instances du même type d interface ont un comportement identique en termes d'actions. Autrement dit, le type d'interface détermine les opérations permises à cette interface. Les interfaces du même type offrent les mêmes fonctionnalités et ont les mêmes signatures et le même comportement de traitement. Pour une interface non-opérationnelle, l'interface spécifie la signature de flux et les détails des informations transmises ou reçues comme le format et le codage. Toutefois, les instances du même type de service peuvent différer dans certains aspects non informatiques (tels que le coût d'utilisation du service). Ces aspects sont appelés propriétés du service. Ainsi, un service peut être décrit par un identifiant de type d'interface, plus les valeurs pour un ensemble de propriétés du service. L ensemble permis de propriétés de service est déterminé 65

75 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b par les types de propriétés de services recensés dans le type d un service donné. Autrement dit, le type de service = <type d interface, types de propriétés de service>. Les propriétés de service sont des instances de types de propriétés de services et consistent en des ensembles de nom de la propriété et de valeur de propriété. Les propriétés de service dans un type de service peuvent avoir des valeurs par défaut (par exemple rouge, 10, null). Pour le courtage, les propriétés de service peuvent être classées comme statiques ou dynamiques. Une propriété statique correspond à une propriété déterminée d'un service, par exemple, la vitesse d'une imprimante. Les valeurs des propriétés statiques sont stockées dans la base de données du trader. Bien que les propriétés statiques puissent changer de valeur, de tels changements sont rares et peuvent être facilement maintenus par des mises à jour de la base de données du trader. Une propriété dynamique correspond à une propriété d'un service qui change fréquemment, par exemple, la longueur du bas de page d'une imprimante. La fréquence de changement des valeurs pour une telle propriété de service est bien plus grande que la vitesse à laquelle le trader est invité à faire une correspondance basée sur cette valeur de la propriété. Les valeurs des propriétés dynamiques sont obtenues par le trader à la demande. III Offres de services Une offre de service désigne un service qui a été négocié. Il s'agit d'une affirmation faite par un serveur à propos d un service offert pour être utilisé par d'autres objets via une interface de traitement. Il se compose de: Identificateur d une interface de service - identifie une interface de traitement où le service peut être obtenu. Identificateur du client - identifie l exportateur de l offre de service. Description du type de service - désigne le type de service offert. Il peut être décrit soit par un identificateur de type de service ou un identifiant de type d'interface avec un ensemble de types de propriétés du service. 66

76 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b Propriétés de service - affirmations faites par un exportateur sur le service qu'il peut offrir. Une offre de service doit spécifier des valeurs pour toutes les propriétés statiques qui n'ont pas de valeurs par défaut. Propriétés de l offre de service - assertions faites par un exportateur à propos d une offre de service particulière. Par exemple, la «durée de conservation» de l'offre qui permet une estimation de «l'âge de l offre». Identificateur de l interface du contrôleur de la politique d exportation - un identifiant d'interface optionnel pour permettre à un exportateur d'exercer plus de contrôle dynamique de la politique de courtage. L'identifiant permet au trader d'interagir avec l'exportateur pour : * Obtenir de l aide supplémentaire pour la sélection d'un service d'exportation (par exemple pour effectuer des vérifications de contrôle d'accès), * Obtenir des valeurs pour les propriétés dynamiques de services, y compris la disponibilité du service. III Contextes L'espace de l offre de service peut être structuré en groupes (ensembles) appelé contextes. Associés avec les groupes constituent les propriétés du groupe [85], qui permettent de décrire: Certains aspects des caractéristiques du groupe lui-même (par exemple, la structure physique des lieux de stockage de l'offre de service), Certaines propriétés communes des offres de service (par exemple des offres disponibles pour les importateurs avec des critères de sécurité), Certaines propriétés communes de services (par exemple les services de certains types). Les propriétés du groupe peuvent être utilisées comme base pour la mise en place (ou la recherche) des offres de services. Ainsi, l'opération d'exportation d'une offre de service désigne également un contexte pour le placement de l'offre de service. Le contexte contraint la visibilité de l'offre de service. 67

77 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b III structure du contexte La structure du contexte est la relation entre les sous-ensembles de contextes. La figure 16 montre un exemple d'une structure de contexte du trader, où TC-a est l'ensemble des offres de services disponibles dans un trader. La structure du contexte du trader peut être représentée comme un graphe orienté acyclique (DAG), comme illustré dans la figure 17, où les nœuds représentent les contextes de courtage et les arcs représentent le sous-ensemble de relations. Figure 16. Exemple d une structure de contexte [85] Figure 17. Représentation de la structure de Contexte de la Figure 16 [85] 68

78 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b III Demandes de service Une demande de service est une demande d'un client d une offre de service satisfaisant la spécification des besoins de ce service. La spécification des besoins peut être considérée en deux parties: le comportement du service de traitement requis, décrit par un identificateur de type de service ou un identifiant de type d'interface, les propriétés requises exprimées par une contrainte de concordance. Une contrainte de concordance est une expression booléenne composée des valeurs de propriétés de service et (éventuellement) des valeurs de propriétés de l offre de service. Par exemple, une contrainte de concordance peut être: Printer_type = Laser and Cost_Per_Page < $1.00. Une contrainte de concordance ne doit pas indiquer des valeurs pour toutes les propriétés d'une offre de services d exportation. Les propriétés non-spécifiées sont essentiellement des valeurs «Don't Care». Une demande de service peut également inclure un ensemble optionnel de critères de sélection. Un critère de sélection est une expression de propriétés de service qui fournit les règles de comparaison d une paire d'offres de services. Un critère de sélection peut également appliquer une fonction superlative (minimiser, maximiser) à un nom de propriété de service. Par exemple, une règle de sélection: minimum (Cost_Per_Page), choisit l imprimante laser la moins chère avec un coût par page inférieur à 1 $. III Demande d importation Une demande de service s'inscrit dans le cadre d'une demande d'importation, qui désigne également: L identité d un importateur, Un champ de recherche qui limite la recherche à un ensemble de contextes. (On peut aussi limiter la recherche par le temps et la taille de la liste retournée), 69

79 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b Une méthode de recherche qui spécifie les exigences sur la façon de la recherche. Une politique d'importation identifie un champ de recherche et / ou une méthode de recherche prédéfinis. Une politique d'importation par défaut ou explicitement identifiée peut être utilisée lors d une demande d'importation. Le résultat d une demande d'importation est trouvé seulement si l'offre de service est dans le contexte (ou leurs sous-contextes) désigné dans le champ de recherche. III.3.4. Description du trader du point de vue ingénierie Dans ce point de vue, les structures et mécanismes nécessaires pour implémenter les fonctions de traitement sont visibles. De toute évidence, les différentes réalisations des fonctions sont possibles. La distribution de l'information de courtage est également visible dans ce point de vue. Les informations de courtage peuvent être distribuées sous une seule administration avec une base de données distribuée ou au titre des différentes administrations avec des traders distribués. Différents traders auront des autorités et des politiques différentes. III.3.5. Description du trader du point de vue technologie Le point de vue technologie s intéresse aux plates formes matérielles et logicielles qui constituent la mise en œuvre du trader. Le système matériel et logiciel disponibles limitent les choix précis de la façon d'échanger les données, la façon de stocker les données, et comment mettre en œuvre les structures et les fonctions spécifiées dans les points de vue information, traitement et ingénierie. La norme du trader inclura des spécifications formelles. Il a été déterminé que le langage Z sera utilisé pour la spécification formelle du modèle d'information. La notation ISO de définition d interface (RPC) a été désignée pour la spécification formelle des signatures d'opération. Les langages LOTOS, Z, et SDL'92 peuvent être utilisés pour la spécification formelle du comportement de traitement. 70

80 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b III.3.6. Description du trader du point de vue traitement Dans le point de vue traitement, les interfaces du trader avec son environnement sont visibles. La norme de la fonction de courtage prescrit les interfaces de traitement du trader pouvant être utilisées par d'autres applications dans un système ODP. Le courtier fournit un ensemble d'interfaces de gestion et un ensemble d'interfaces de négociation. III Opérations pour les interfaces de gestion Pour les interfaces de gestion, les opérations d administration internes telles que la création et la suppression des interfaces de négociation ne sont pas prescrites par la norme Trader. Toutefois, les opérations de gestion des contextes [85] et des politiques d'importation [87] sont prescrites. L'espace de l offre de service peut être structuré en groupes (ensembles) appelé contextes. Les administrateurs et les utilisateurs (sous réserve de certaines politiques de sécurité) peuvent manipuler la structure du contexte. Les opérations de gestion de contexte [86] sont les suivantes: Ajouter un contexte : ajoute un contexte à la structure du contexte en précisant les liens avec les super-contextes nominatifs ; Supprimer un contexte : supprime le contexte proposé (et les liens associés) de la structure du contexte; Lister un contexte : affiche le détail d'un contexte : l'identificateur du contexte, les propriétés du contexte, et les relations avec d'autres contextes ; Lister le contenu du contexte : liste les offres de service stockées dans un contexte. Un utilisateur peut demander la liste des offres de service dans un contexte avec toutes les propriétés du service, seulement les propriétés communes du service ou une synthèse en termes de nombre. 71

81 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b III Operations pour les interfaces de courtage L'ensemble des opérations pour l'interface de courtage peuvent être regroupées en opérations pour les exportateurs et celles pour les importateurs. Pour l exportateur, l ensemble d opérations est : Export : annonce une offre de service dans un contexte désigné ou par défaut. Le service exporté est assigné d un identifiant d'exportation unique dans le contexte; Withdraw : supprime une offre de services à partir d'un contexte. L'offre de service n'est plus disponible pour les opérations d'importation; Replace : une séquence atomique du retrait d'une offre de service suivie d'une exportation d'une offre de services dans un contexte précisé. L'offre de services nouvellement remplacée a le même identifiant à l'exportation que l'offre de service d'origine. Il peut être utilisé pour modifier les propriétés du service, par exemple, le coût du service. Pour l importateur, l ensemble d opérations est : List : une demande pour retourner les valeurs des propriétés du service courant et/ou les valeurs des propriétés de l offre de service d une offre de service précise; Search : une demande pour retourner un ensemble (éventuellement vide) d offres de service dans le contexte désigné qui satisfait la description du type de service de l'importateur et de la contrainte correspondante. Un importateur peut spécifier un champ de recherche et une méthode de recherche; Select : une demande pour retourner la meilleur offre de service (selon les critères de sélection de l'importateur) de l'ensemble des offres de service correspondantes. III Opérations disponibles pour un Trader Les opérations suivantes sont disponibles au trader si un exportateur comprend l identifiant d'interface du contrôleur de la politique d'exportation dans son offre de services: 72

82 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b Demande du statut : une demande auprès du trader pour obtenir des renseignements sur l'état actuel des propriétés dynamiques du service proposé d'un service d'exportation; Politique de l'exportateur : une demande auprès du trader au contrôleur de la politique d export sur le service sélectionné. Le trader envoie un identifiant d'interface de service et reçoit: - L'identifiant d interface de service original (tout va bien), - Un identifiant d interface de service substitué (en raison, par exemple, de la congestion du réseau), - Un identifiant d interface de service nul (indiquant l'échec de l'opération, en raison, par exemple, du manque de ressources). III Scénario d interaction du trader Pour comparer les demandes de service avec les offres de service, le trader interagit avec la fonction de base de données de types fournie par l'infrastructure ODP [5]. L'ensemble de tous les types de service connus par le trader est appelé sa base de donnée de type. Le référentiel de type contient aussi les types d'interface associés à chaque type de service et maintient un ensemble de relations pour les types d'interface. Les relations comprennent des relations d'équivalence et des relations de super /sous-type. En outre, le référentiel de type maintient la relation de super/sous-type des types de services connus. Un trader exige les opérations suivantes: Contrôle de type : une demande de vérifier la validité des types dans les offres de service et les demandes de service ; Contrôle de compatibilité : une demande pour vérifier si un service ou un type d'interface est compatible avec un autre service ou type d'interface ; Affichage des relations de type : une demande pour obtenir une liste des sous-types d'un service désigné ou un type d'interface. La figure 18 montre un scénario d interaction possible du trader avec son environnement. 73

83 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b Figure 18. Scénario d interaction du trader [88] Interaction 1. Service Export le trader reçoit une offre de service d'un exportateur. Le trader vérifie dans sa base de données (interaction 1a) que le type de service (ou type d'interface), les propriétés du service et les propriétés d offre de services spécifiées dans l'offre sont valides. L'offre de service est stockée dans la base de données du trader incluant l identificateur de type de l'offre de services (si disponible), l'identificateur de type d'interface, les propriétés de service et de l offre de service. Interaction 2. Service import le trader reçoit une demande de service d'un client. Le trader vérifie dans sa base de données de type (interaction 2a) que la requête contient un service ou un type d'interface connu et que les propriétés ou les paramètres correspondants sont valables. Interaction 3. Offre correspondante- le trader retourne l offre recherchée (éventuellement vide) à l'importateur. C est l offre qui correspond aux spécifications exigées par l'importateur. Le trader doit d abord consulter sa base de données de type : Le trader soumet l identifiant de type (d une demande de service valide) à sa base de données de type (interaction 3a). Le référentiel de type retourne une liste (d identificateurs) de types compatibles (identique et/ou super-type) avec le type en question. 74

84 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b Pour trouver un service, le trader cherche dans sa base de données, contraint par la politique d'importation (en limitant la portée de la recherche) et la politique d'exportation (en limitant la visibilité de l'offre), des offres de services qui correspondent au(x): Service ou type d'interface (s) (comme indiqué par son référentiel de type), Exigences de propriétés de service et de l offre de service (comme spécifié dans la contrainte de concordance), Les exigences de gestion (tel que spécifié par le trader. Par exemple : exigences de sécurité). Dans la liste des offres de service correspondant, le trader sélectionne, si nécessaire, une offre de service basée sur les critères de sélection spécifiés. Si la liste des offres correspondantes n'est pas vide, le trader retourne l identifiant d une interface de services à l importateur. Si une correspondance ou une sélection de propriétés de service dynamique est nécessaire, l identifiant d'interface du contrôleur de la politique d'exportation, si disponible, est utilisé pour déterminer les valeurs des propriétés dynamiques (interaction 3b). L identifiant d'interface du contrôleur de la politique d'exportation peut également être utilisé pour affiner la sélection d'un service d'exportation. Enfin, pour utiliser le service, l'importateur utilise l'identifiant de l'interface de service pour connaitre la localisation d'interface du service, et par la établir une liaison avec le serveur et, finalement, appeler le service. III.4. Spécification du trader ODP en utilisant event-b III.4.1. Stratégie de raffinement Dans cette section, nous allons présenter notre stratégie pour la construction du scénario de négociation entre l objet trader et ses utilisateurs. Ce scénario sera réalisé par un modèle initial suivi par un modèle de raffinement (Belhaj et al, 2010) [88]. a) Le modèle initial présente essentiellement le protocole sans intervenir la fonction de base de données du trader ; 75

85 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b b) Dans le modèle de raffinement, nous allons introduire la fonction de base de donnée du trader. Ce dernier a besoin d interagir avec sa base de données pour vérifier que le type de service spécifié est valide. III.4.2. Modèle abstrait de la fonction de courtage Le modèle abstrait du protocole de communication du trader est présenté comme une machine B dans la figure 19. Les processus et les messages sont définis comme des ensembles. Une description brève de cette machine est donnée ci-dessous (Belhaj et al, 2010) [89]. MACHINE SETS Trader and users communication PROCESS = {importer, exporter, trader} MESSAGE = {import, export, result, invoke} VARIABLES sender, receiver INVARIANT /* I-1*/ sender MESSAGE PROCESS /* I-2*/ receiver PROCESS MESSAGE /* I-3*/ ran(receiver) dom(sender) INITIALISATION sender := Ф receiver:= Ф OPERATIONS Send (pp PROCESS, mm MESSAGE) = WHEN mm dom (sender) pp dom(receiver) THEN sender := sender U {mm pp} END; Receive (pp PROCESS, mm MESSAGE) = WHEN mm dom(sender) pp dom(receiver) THEN receiver := receiver U {pp mm} END ; END Figure 19. Modèle abstrait de la fonction de courtage [89]. 76

86 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b L'expéditeur est une fonction partielle de message vers processus défini dans l invariant I-1. La notation (m p) expéditeur indique que le message «m» a été envoyé par le processus «p». Le récepteur est une relation entre le processus et le message définis dans l invariant I- 2. La notation (p m) récepteur indique qu'un processus «p» a livré un message «m». L'expéditeur et le récepteur sont initialisés comme ensemble vide. Dans notre modèle de communication du trader avec ses utilisateurs, un message envoyé est également délivré à son expéditeur. Il faut noter que tous les messages envoyés doivent être des messages dont l événement d envoi de message est également enregistré. Cette propriété est définie dans l invariant I-3. Les événements d'envoi et de réception de messages sont modélisés par Send (pp, mm) et Receive (pp, mm). Quand un événement d envoi est invoqué, les deux paramètres processus et message correspondants sont fournis à l'expéditeur. III.4.3. Modèle de raffinement : Introduction de la fonction base de données du trader Pour comparer les demandes de service avec les offres de service, le trader interagit avec la fonction de base de données de types fournie par l'infrastructure ODP [5]. L'ensemble de tous les types de service connus par le trader est appelé sa base de donnée de type. Le scénario d'interaction possible entre le trader et son environnement est donné ci-dessous: Interaction 1. Service d exportation : le trader reçoit une offre de service d'un exportateur. Le trader vérifie dans sa base de données que le type de service (ou type d'interface), les propriétés du service et les propriétés d offre de services spécifiées dans l'offre sont valides. L'offre de service est stockée dans la base de données du trader incluant l identificateur de type de l'offre de services (si disponible), l'identificateur de type d'interface, les propriétés de service et de l offre de service. Interaction 2. Service d'importation : le trader reçoit une demande de service d'un client. Le trader vérifie dans sa base de données de type que la requête contient un service ou un type d'interface connu et que les propriétés ou les paramètres correspondants sont valables. Interaction 3. Offre correspondante- le trader retourne l offre recherchée (éventuellement vide) à l'importateur. C est l offre qui correspond aux spécifications exigées par l'importateur. 77

87 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b Enfin, pour utiliser le service, l'importateur utilise l'identifiant de l'interface de service pour connaitre la localisation d'interface du service, et par la établir une liaison avec le serveur et, finalement, appeler le service. Trader Result -Service offer properties -Offers s service type identifier Import -Service type Export -Service type -Service properties -Service offer properties -Offers s service type identifier -Service properties IMPORTER Invoke Offers s service type identifier EXPORTER Figure 20. Communication entre le trader et ses utilisateurs tenant compte de la fonction de base de données [88]. Dans ce raffinement, nous introduisons l'interface de base de données du trader. Le raffinement du modèle abstrait est donné dans la Figure 21 et Figure 22. Une brève description des étapes de raffinement sont donnés ci-dessous (Belhaj et al, 2010) [88]. L'interface abstrait de base de données est représentée par une variable «repository». La forme (p1 m1) repository indique que le paramètre p1 est envoyé avec le message m1 (Inv I-4). Un référentiel des messages peut être défini uniquement pour les messages dont l événement d envoi de message est enregistré (Inv I-5). 78

88 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b REFINEMENT REFINE SETS Repository interface Trader and users communication PROCESS = {importer, exporter, trader); MESSAGE = {import, export, result, invoke}; PARAMETER={Service type, Service properties, Service offer properties, Offers service type identifier} CONSTANT VARIABLES Trader_type_repository Sender, receiver, repository INVARIANT /* I-4*/ repository PARAMETER MESSAGE /* I-5*/ ran(repository) dom(sender) INITIALISATION sender := Ф receiver := Ф repository := Ф Figure 21. Communication entre le trader et ses utilisateurs tenant compte de la BD: Initialisation [88] Les événements send (pp, mm, param) et receive (pp, mm, param) représentent respectivement les événements d'envoi et de réception d'un message. Comme indiqué dans les opérations, seul le processus exportateur peut exporter une offre de service. Lorsque le trader reçoit une offre de services d'un exportateur pp, il vérifie auprès de son référentiel de type que le type de service est valide. L'offre de services est stockée dans la base de données, comprenant l identificateur de type de l'offre de services, l'identificateur de type d'interface, les propriétés de service et de l offre de service. En outre, seul le processus importateur peut importer un service. Lorsque l'opérateur reçoit une demande de service d'un client. Le trader vérifie dans sa base de données que la requête 79

89 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b contient un service ou un type d interface connu et que les propriétés correspondantes sont valables. OPERATIONS Send ( pp PROCESS, mm MESSAGE, param PARAMETER) = WHEN mm dom(sender) pp dom(receiver) param dom(repository) pp =exporter Service_type = Trader_type_repository END; THEN sender := sender U {mm pp} repository := repository U {param mm} Receive (pp PROCESS, mm MESSAGE, param PARAMETER) = END ; WHEN mm dom(sender) pp dom(receiver) param dom(repository) pp = importer Service_type = Trader_type_repository THEN receiver := receiver U {pp mm} repository := repository U {param mm} Figure 22. Communication entre le trader et ses utilisateurs tenant compte de la BD: Events [88] 80

90 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b III.5. Vérification des modèles du trader Le modèle initial de la communication du trader avec ses utilisateurs et les modèles de raffinements sont développés à l'aide du B-événementielle. Chaque modèle a été analysée et prouvé d être correcte en utilisant la plateforme Rodin. L'exactitude de chaque étape est justifiée pour parvenir à un protocole de communication fiable entre les objets trader, clients et serveur. Les modèles abstraits et de raffinement issus des deux constructions du B événementielle (machine et contexte) sont illustrés ci-après : Figure 23. Le contexte du modèle abstrait du trader [89]. 81

91 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b Figure 24. La machine du modèle abstrait du trader [89]. Figure 25. Le contexte du modèle de raffinement du trader [88]. 82

92 CHAPITRE III : Spécification et vérification de la fonction de courtage par event-b III.6. Conclusion Figure 26. La machine du modèle de raffinement du trader [88]. Dans ce chapitre nous avons présenté une approche formelle pour la modélisation et l'analyse de la fonction de courtage en utilisant event-b. Le modèle abstrait du trader est établit abstraction faite de sa fonction de base de données. Dans le modèle du raffinement, nous avons introduit la notion de fonction de base de données du trader. En effet, pour confronter les demandes de service avec les offres de service, le trader interagit avec la fonction de base de données de type fourni par l'infrastructure ODP. L'ensemble de tous les types de service fournis par le trader est appelé son référentiel de type ou sa base de données de type. L'approche de développement adoptée est basée sur event-b. cette approche facilite le développement incrémental des systèmes distribués. La plateforme Rodin est choisie comme outil d implémentation. Pour vérifier nos modèles du trader, le modèle initiale et ses modèles de raffinement sont développés à l'aide de la méthode B, chaque modèle est analysé et vérifié par l outil Rodin. 83