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

93 CHAPITRE IV : UTILISATION DE LA METHODE B EVENEMENTIELLE POUR LA SPECIFICATION DE LA QUALITE DE SERVICE DANS LE LANGAGE DE POINT DE VUE ENTREPRISE IV.1. Introduction La qualité est un élément essentiel dans la caractérisation des produits et services. La définition et la mesure de la qualité, qui est facile dans certains contextes spécifiques (par exemple, lorsque nous achetons une voiture ou un autre produit réel), il devient très difficile lorsque nous décidons d'évaluer la qualité de quelque chose qui est «immatériel», tels que les services de systèmes informatiques. Par conséquent, il est nécessaire de clarifier et d'identifier les aspects clés de Qualité de Service (QoS) pour toutes les entités impliquées dans le service: le système, ses infrastructures et ses utilisateurs. Une définition générale de la qualité est la suivante: «toutes les propriétés et caractéristiques d'une entité qui lui confèrent la capacité de répondre aux besoins exprimés ou implicites» [50]. Dans le contexte international, selon des ITU (International Telecommunication Union) Recommandation E.800, la qualité de service est défini comme étant «l effet collectif de la performance du service qui détermine le degré de satisfaction d'un utilisateur du service» et, du point de vue du système, en particulier, «la qualité de service est la capacité d'un réseau (ou d'un système) pour assurer un certain niveau de service» [51]. A partir de ces définitions, l'importance de la notion de qualité, comme valeur qui doit être garanti à l'utilisateur final, devient évidente [50]. Pour cette raison, il est essentiel que ce concept devient "commun", même s'il est difficile qu'un utilisateur soit vraiment conscient du niveau de qualité attendu d'un produit (ou plutôt, d'un service), dans un environnement dynamique comme les technologies de l'information. 84

94 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 La Qualité de Service (QoS) de gestion des systèmes informatiques est l'un des aspects clés de leur succès en raison de la grande compétitivité de l'environnement dans lequel elles sont déployées: quelle que soit la technologie de base, seuls les systèmes garantissant un degré de satisfaction à leurs utilisateurs seront acceptés. Ainsi, bien qu on puisse trouver plusieurs définitions du terme qualité de service, dans le cadre de cette thèse, la qualité de service sera comprise comme étant l'ensemble des aspects non fonctionnels d'un système qui déterminent le niveau de satisfaction des utilisateurs de la fonctionnalité qu'ils fournissent [52]. La gestion de la qualité de service désigne l'ensemble des activités consacrées à la surveillance et au contrôle des ressources impliquées dans la fourniture d'un niveau suffisant de qualité de service. C est une tâche globale dans le sens où elle prend en compte tous les types de ressources supportant le service fourni par un système d'information: ressources du réseau, ressources système, ressources middleware, applications, etc. Tout doit être synchronisé pour atteindre l'objectif global d'obtenir des niveaux de qualité de service qui répondent aux exigences des utilisateurs. Cette compréhension de la qualité de service est appelé «La QoS de bout en bout» [51]. QoS de bout en bout implique une traduction du haut en bas des exigences de QoS niveau utilisateur vers un niveau inférieur d exigences de QoS. Nous nous intéressons particulièrement, dans la gestion de la QoS, à un type particulier de ressources: les applications, plus précisément à un type particulier d'applications : celles supportées par les plates-formes de traitement distribués à base d'objets [53]. Ces applications sont devenues de plus en plus importantes dans le domaine de technologie de l information parce qu'elles peuvent être facilement déployées dans des environnements hétérogènes, elles présentent des avantages importants pour les développeurs et parce qu'elles peuvent intégrer les applications existantes dans les nouveaux systèmes. RM-ODP [2] fournit une définition très large de la qualité de service et qui a besoin de quelques améliorations, à savoir: la qualité du service est un ensemble d'exigences de qualité sur le comportement collectif d'un ou plusieurs objets. La qualité de service peut être spécifiée dans un contrat ou mesurée et communiquée après l exécution [54]. 85

95 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 Un cadre générique a été affiné pour être utilisé dans deux domaines particuliers: les communications basées sur des architectures compatibles avec le modèle de référence OSI et les applications distribuées à base d'objets compatibles avec les standards RM-ODP [13] [14]. Cette dernière spécification a été adoptée comme base conceptuelle pour notre travail. Un des éléments, figurant dans le travail développé par l'iso / UIT-T sur la QoS dans ODP, est le besoin d'un langage de qualité de service capable de représenter toutes les informations relatives à la qualité de service dans tous les points de vue d un système ODP. C'est le problème concret de QoS présenté dans ce chapitre. Il présente un langage de qualité de service qui est compatible avec les concepts de qualité de service de la norme ISO / UIT-T et qui peut être utilisé dans une spécification d'entreprise de QoS d'un système ODP (Belhaj et al, 2010 et 2011) [66] [90]. Ce langage de QoS est exprimé par la méthode-b, afin de tirer parti des outils B en l occurrence la plateforme Rodin [94] [55]. Dans ce chapitre, nous utilisons la méthode B comme cadre formel pour le développement des systèmes distribués corrects par construction. Event B 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 [96] [62] [63]. Dans ce contexte, nous avons développé le processus de négociation de la QoS, en utilisant la fonction de courtage, avec event-b. Ceci a été réalisé de manière progressive de la spécification abstraite jusqu à l implémentation en utilisant les techniques de raffinement. L'exactitude de chaque étape est prouvée, afin d'aboutir à un système fiable. Les outils B nous ont assistés dans le processus de développement en générant les obligations de preuve nécessaires. Ces obligations de preuve peuvent être vérifiées automatiquement ou de manière interactive. La Plate-forme Rodin pour event-b fournit un support efficace pour le raffinement et la preuve mathématique [94] [55]. Le chapitre est organisé comme suit. La section 2 présente le langage entreprise de RM-ODP et la QoS. La section 3 décrit et spécifie le processus de négociation de la QoS du point de vue entreprise d ODP en utilisant la fonction de courtage. Dans la section 4, nous utilisons 86

96 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 event-b comme méthode de raffinement pour spécifier ce processus de négociation. La section 5 décrit les travaux connexes. Nous terminons par une conclusion. IV.2. RM-ODP et qualité de service (QoS) IV.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. La partie fondement [2] 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 architecture [3] 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, cinq 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, fournissent une base pour la spécification des systèmes ODP. Chaque langage point de vue définit les concepts et les règles pour la spécification des systèmes ODP dans ce point de vue. Cependant, le RM-ODP est aussi une méta-norme dans le sens où il définit une norme pour la définition d autres normes ODP [64]. Les normes ODP comprennent les langages de modélisation, langages de spécification et de vérification. Les fonctions ODP sont nécessaires pour supporter les systèmes ODP. Les prescriptions de transparence montrent comment utiliser les fonctions ODP pour assurer la transparence de la distribution. Les trois premiers points de vue ne tiennent pas compte des problèmes inhérents à la répartition et à l'hétérogénéité. Cela correspond étroitement aux concepts de modèles PIM (Platform Independent Model) et PSM (Platform Specific Model) définis dans l'architecture MDA [15] de l OMG [93]. Toutefois, RM-ODP ne peut pas être directement applicable [64]. En effet, RM-ODP fournit seulement un cadre pour la définition de nouveaux standards ODP incluant les standards pour les fonctions ODP [5][6], les standards pour la modélisation et la 87

97 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 spécification des systèmes ODP; les standards de programmation, d'exécution et de test des systèmes ODP. 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. Les objets serveur publient leurs services via le trader en utilisant les opérations d exportation; l'annonce de service précise le type d'interface et les attributs de service. Les objets clients choisissent les services en précisant le type et les attributs nécessaires à des opérations d'importation. Le Trader fournit "un service de rencontres pour les objets", son but est d offrir la liaison dynamique en permettant de découvrir les services au moment de l'exécution. Le trader constitue un référentiel de service. IV.2.2. Fonction de courtage IV Aperçu général Le traitement réparti ouvert vise à assurer un partage transparent des services (et des ressources) sur différentes architectures, différents réseaux et différents systèmes d'exploitation [1]. Pour assurer le partage des services, les demandeurs de services doivent prendre conscience des fournisseurs potentiels de services requis et être capable d'y accéder. En outre, dans un système distribué complexe, les sites et les applications ont tendance à changer fréquemment. Pour cela, il faut prévoir l ajout de nouveaux services et la mise à jour ou la suppression des anciens services. Il est donc avantageux de permettre la liaison tardive entre les consommateurs et les prestataires de service. Une application doit être en mesure de 88

98 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 sélectionner les serveurs qui répondent à ces exigences de façon dynamique si la liaison tardive, ou contraignante au moment de l'exécution, doit être prise en charge. Cette sélection dynamique de service approprié au moment de l'exécution est assurée par la fonction de courtage dans ODP [6]. Un trader est un objet tiers qui permet de lier les clients et serveurs dans un système distribué. La figure 27 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. Une demande de service est l'expression d'un besoin de service effectuée par un importateur quand il a besoin de ce 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. 89

99 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 Figure 27. Trader et ses utilisateurs [65] Le même objet peut être exportateur d'un service et importateur d'un autre service. En fait, un importateur ou un exportateur peut être un autre trader. L'importateur et l'exportateur correspondant peuvent être: Co-localisés, Eloignés physiquement les uns des autres, ou Relogeable dynamiquement. Les fonctions ODP de transparence à la répartition cachent ces différences de localisation [3]. IV La fonction de courtage dans le 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 pour assurer la négociation (courtage). Les activités de la communauté de courtage sont l export et l import de services, et sont régis par une politique du trader. La communauté se compose de membres qui ont des rôles tels que: trader, exportateur, importateur, administrateur de négociation et décideur de la politique de 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é de courtage. 90

100 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 Chaque importateur peut avoir aussi une politique d'importation propre qui limite l'ensemble d'offres de services examinées par un trader dans l'importation d un service. Aussi, chaque exportateur peut avoir sa propre politique d exportation qui restreint l'ensemble des importateurs à laquelle un trader peut transmettre une offre de service. Dans l'importation de service, le processus de courtage effectué par un trader est donc régi par: La politique de courtage de la communauté de courtage, La politique d'exportation concernant l'exportateur de l'offre de service, et La politique d importation concernant l importateur de service [3]. Les politiques sont exprimés sous forme de règles. Les membres de la communauté de courtage sont obligés de respecter les règles. Ces règles guident les décisions pour répondre aux exigences fonctionnelles de la communauté. Par exemple, les règles pour la qualité de service, 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 réelles, etc. La spécification d'une exigence du point de vue entreprise a des conséquences sur les autres points de vue. Par exemple, l exigence de qualité de service du temps de réponse. IV.3. La spécification d entreprise de la QoS Les spécifications de la QoS dans le point de vue entreprises sont reliées aux objectifs, aux responsabilités et aux politiques du système ODP dans son environnement. En général, ces spécifications expriment les exigences de qualité de service, qui sont prises pour inclure des exigences de l environnement extérieur sur le système (besoins des utilisateurs), ainsi que les revendications à prendre en compte par les concepteurs afin de répondre aux besoins des utilisateurs. Les exigences de qualité de service sont associées aux objectifs du point de vue entreprise, aux responsabilités et aux politiques. Celles-ci correspondent aux besoins exprimés sur les objets d'entreprise et leurs interactions. 91

101 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.3.1. Le modèle objet de la QoS du point de vue entreprise Dans les systèmes informatiques, effectuer une requête de QoS ou s'engager sur un niveau de qualité impose des engagements contractuels entre le client, l opérateur (le trader dans le contexte ODP) et le fournisseur de services. Un premier contrat, appelé «Service Level Agreement (SLA)» [67] fixe les règles d'utilisation du service par un client pour le fournisseur de services qui en retour s'engage à garantir une disponibilité de son service. Il est donc négocié entre l'utilisateur et le fournisseur de service. L'objectif d'un SLA est de parvenir à la qualité de service convenue et d'obtenir ainsi la satisfaction du client. Les utilisateurs, en général, ne se soucient pas de la technologie des produits, ils sont plutôt intéressés par les bénéfices qu'ils peuvent obtenir et par la facilité d'utilisation de ces produits. Afin d'acheminer correctement les données de services, le fournisseur va à son tour passer un contrat avec l'opérateur appelé «Service Level Specification (SLS)» [68], il fixe les règles d'usage des capacités du réseau par le fournisseur de service pour l'opérateur qui, en retour, s'engage à garantir une QoS pour l'acheminement des données du service. En général, le SLS est considéré comme étant l'annexe technique du SLA bien qu'il ne soit pas vu de l'utilisateur final, étant ajouté par le fournisseur de service. La garantie de service et de QoS ne sera assurée que dans le cadre de ces contrats. Les opérateurs utilisent la même notion de contrat lorsqu'ils souhaitent s'échanger du trafic. Ils sont également appelés «Peering Agreement» car ils sont souvent réciproques dans le sens où il s'agit d'un échange mutuel et si possible symétrique [68]. Nous montrons comment la fonction de courtage est utilisée pour spécifier la qualité de service lors de la modélisation d'un système réparti ouvert dans le point de vue entreprise. Nous étudions la qualité de service (QoS) de bout en bout et mettons en évidence que cette QoS a de multiples facettes et nécessite des accords complexes entre les objets d'entreprise et la communauté. La qualité de service peut être spécifiée dans un contrat ou mesurée et communiquée après l exécution (Figure 28). 92

102 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 QoSType 1..* QOSCharacteristics * -base -derived Objective -require 1..* 1 QoS Contact 0..* -require QOSPermission QOSInterdiction QOSObligation 1 -member 1 Community 0..* -abstaction 0..1 CommunityObject * EnterpriseObject -filler Policy Role 1..* 1..* 1..* * * 1..* * Interaction 1 Trader Server 1 Client 1 1 Figure 28. Modélisation de la QoS du point de vue entreprise de la fonction de courtage [66] Dans ce modèle, une activité de gestion de la QoS est dirigée par un trader qui veille au respect des politiques du système qui sont en vigueur sur les interactions entre les objets en remplissant leurs rôles pour répondre aux besoins des utilisateurs (Belhaj et al, 2010) [66]. La gestion de la QoS serait utilisée sur les phases suivantes d'une activité: A priori les besoins de QoS peuvent être intégrées dans la configuration du système lors de la conception; Avant l initialisation, la gestion de la QoS peut être confiée à un trader avant le début d exécution de l activité; 93

103 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 Lors de l initialisation de l activité, les exigences de qualité de service peuvent être négociées entre le serveur et le trader; Au cours de l exécution de l'activité, les exigences de qualité de service peuvent changer en raison de changement des exigences, de détection d une perte de performances et des indications explicites des objets serveur ou d'un ou plusieurs objets clients; Après l'activité, la gestion de la QoS consiste éventuellement à procéder à l'analyse des tendances, l analyse de contrats, le suivi de performance, etc. Certaines exigences de qualité de service sont placées sur les objets entreprises eux-mêmes, d'autres sur les interactions entre les objets d'entreprise. Celles placées sur les objets d entreprise vont définir des exigences sur les caractéristiques de QoS telles que la fiabilité, la sécurité et la capacité. Celles placées sur les interactions (comme la précision liée à la granularité) ou sur les ensembles d'interactions entre les objets d'entreprises concernent la définition des interactions ou des ensembles d'interactions eux-mêmes. Dans une spécification d'entreprise, une interaction est définie quand il est nécessaire de définir les finalités des objets d'entreprise en interaction. Cette notion de QoS inclue la définition : des objets d entreprise en interaction; du but de l interaction; des politiques du système ODP (obligation, permission, interdiction). Les caractéristiques de QoS sont fondamentales pour l'expression des besoins ou d'autres spécifications concernant la qualité de service. Ils représentent un aspect de la QoS d'un système, un service ou une ressource qui peut être identifiée et quantifiée (par exemple: le délai, la disponibilité, la fiabilité, la confidentialité...). Elles sont définies indépendamment des moyens par lesquels la qualité de service est représentée ou contrôlée. 94

104 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.3.2. Négociation de la QoS dans une communication client-serveur pour parvenir à un accord de QoS Le concept de négociation de QoS entre les objets d'entreprise inclue l'objet trader entre eux. En général, les mécanismes de négociation de trois parties sont utilisés [52]. Dans notre contexte, ces mécanismes incluent l objet client, le serveur et le trader. Nous définissons deux mécanismes de négociation entre les trois parties: Le premier mécanisme utilise un seul paramètre et permet la négociation d'une maximale proposée; Le second mécanisme permet aux parties de préciser une plage de valeurs dans laquelle ils sont capables d'agir. Ces parties peuvent convenir sur une limite, une valeur ou un seuil dans une fourchette. Chaque mécanisme fournit un utilisateur initial proposant une valeur initiale, qui peut être modifiée par d'autres parties. L objectif étant d atteindre un degré de symétrie, car le résultat de la négociation doit être une valeur acceptable par toutes les parties de la communication. Comme mentionné précédemment, la négociation peut concerner un seul paramètre (négociation de paramètre unique) ou des limites de paramètres (négociation bornée). IV Négociation de paramètre unique 1) Le client (initiateur de la communication) propose une valeur «P» au trader ; 2) Le trader peut refuser la requête, mais, s il accepte, il pourrait choisir une nouvelle valeur «P '» qui n'est pas supérieure que celle proposée par le serveur, P' <= P ; 3) Le serveur pourrait refuser la demande. Sinon, lorsque le serveur accepte, il pourrait proposer une nouvelle valeur «V» inférieure à la valeur initiale proposée par le client, à savoir V <= P '. Le serveur donne cette valeur au trader ; 5) Le trader laisse inchangée la valeur V ; 95

105 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 6) La valeur proposée «V» est retournée au client et constitue la valeur négociée. Ce mécanisme est illustré dans la figure 29. Client Trader Server Trader Client P P V Figure 29. Négociation de paramètre unique de QoS [69] IV Négociation bornée 1) Le client spécifie une plage de valeurs désirée, en fournissant une limite inférieure «L» et une limite supérieure «U», où L <= U ; 2) Le serveur pourrait refuser la demande s il s aperçoit qu il ne peut pas satisfaire le client. Si le serveur accepte mais ne peut pas fonctionner sur la marge complète proposée par le client, il peut déterminer une nouvelle valeur «U» pour la limite supérieure, telle que, L <= U ' <= U (le serveur peut aussi choisir de travailler en interne pour une meilleure qualité, mais ne signale pas ce fait au trader). Le serveur ne modifie pas la valeur de la limite inférieure «L». La nouvelle limite supérieure «U» et la limite inférieure sont fournies au trader; 3) Le trader peur refuser la requête, s il accepte, il pourrait sélectionner une valeur V telle que L<= V<= U '. Cette valeur est retournée au serveur ; 4) Le serveur laisse la valeur «V» inchangée ; 5) La valeur «V» est choisie et retournée au client. C est la valeur négociée. 96

106 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 Ce mécanisme est illustré dans la figure 30. Client Server Trader Server Client U U V L Figure 30. Négociation bornée de la QoS [69] Les deux mécanismes peuvent également être réalisés par l adoption de certaines restrictions, qui peuvent dépendre du comportement des parties: par exemple, le mécanisme de négociation bilatérale est une version restreinte des mécanismes décrits plus haut et stipule que le serveur ne modifie pas les valeurs reçues par le client et les transmet au trader, les laissant inchangées. En outre, un client ne peut négocier un seuil avec le serveur que si le client souhaite être informé lorsque la qualité de service atteint un certain niveau. 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 La négociation d un seul paramètre de QoS (Figure 29) peut être représentée dans le schéma de la figure 31, où les événements (Client_snd, Server_snd, Trader_snd, Client_rcv, Server_rcv, Trader_rcv) sont censés représenter les différentes phases que nous venons de décrire, comme indiqué par les flèches : 97

107 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 Trader Snd Rcv V P P V Client Server Snd Rcv Snd Rcv Figure 31. Schéma du protocole de négociation de QoS [66] Nous avons décrit le comportement normal du protocole, où les objets d entreprise client et serveur négocient avec succès une valeur de qualité de service. Nous allons également décrire ci-dessous un comportement dégradé, où les deux objets ne parviennent pas à atteindre cette valeur de qualité de service. Afin de faire face à cette éventualité, l'objet client démarre une minuterie quand il propose la valeur de qualité de service souhaitée. Cet appareil est réglé de sorte qu'il rappelle l'expéditeur après un certain délai. Ce délai est jugé en retard s il est supérieur au délai maximum «dl» qui est nécessaire entre l envoi de la valeur de QoS recherchée par le client et la réception de la valeur possible de QoS du serveur. En d'autres termes, le client peut conclure que le message a nécessairement été perdu lorsque le temps est dépassé, c.à.d. si un délai «dl» s'est écoulé depuis l envoi du dernier message au serveur sans avoir reçu de réponse. IV.4.2. Document des exigences Le document des exigences que nous proposons offre des explications informelles que nous avons données précédemment. Il ne propose pas une mise en œuvre, mais consiste essentiellement à expliquer quelle intention que chaque objet d entreprise peut avoir à la fin du protocole: 98

108 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 Le système négocie la QoS entre les objets d entreprise FUN-1 Ensuite nous expliquons ce que signifie une négociation réussie: La valeur finale de QoS est publiée par l'objet trader FUN-2 Nous expliquons également ce qu'est une qualité de service proposée: La valeur initiale de QoS est proposée par l objet client FUN-3 Nous décrivons maintenant ce que le client et le serveur peuvent croire à la fin du protocole de négociation: Les objets client et serveur doivent avoir la même intention de la réussite ou de l échec de la négociation de la valeur de QoS FUN-4 Nous lions les intentions du client et du serveur : Lorsque la valeur de QoS est publiée par le trader, le client et le server sont conscients que la négociation a réussi. Autrement, ils savent tous les deux que la négociation a échoué. FUN-5 Nous expliquons qu il est possible que le client refuse: Cependant, si le client refuse la valeur de QoS proposée par le serveur, la négociation est abandonnée FUN-6 IV.4.3. Stratégie de raffinement Dans cette section, nous présentons notre stratégie de construction du protocole de négociation de paramètre unique de la QoS. Ceci, sera réalisé par un modèle initial suivi de trios raffinements. 99

109 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 a) le modèle initial met en place le protocole tenant compte des exigences FUN-1, FUN-2 et FUN-3. Il le présente comme si le protocole se fait d'un seul coup ; b) Dans le premier raffinement, nous prenons en considération les obligations restantes de FUN-4 à FUN-6 d'une manière abstraite. La QoS est approuvée étape par étape, mais nous sommes encore abstraits dans le sens où le client et le serveur peuvent avoir un accès direct aux états l un de l'autre ; c) Dans le second raffinement, nous introduisons le trader entre le client et le serveur pour que chacun d'entre eux ne réagisse qu avec les messages du Trader: chacun ne peut pas accéder directement à la valeur de l autre comme ce fut le cas dans les raffinements précédents. Pour ces messages, nous introduisons le trader entre le client et le serveur (en tant que négociateur) ; d) dans le troisième raffinement, nous introduisons les délais entre les deux participants. IV.4.4. Modèle initial Notre modèle initial contient une spécification partielle du protocole de négociation de paramètre unique de QoS. Il traite les exigences FUN-1, FUN-2 et FUN-3. Le protocole est exécuté en un seul coup. IV État L'État est composé de l'ensemble des nombres naturels IN pour représenter l'ensemble des valeurs de qualité de service. La valeur de QoS est limitée par une valeur positive constante Vserver_max qui est la valeur maximale de QoS autorisée par l objet serveur, défini de façon simple dans l axiome axm0_1. Sets: IN Constants: Vserver_max P Axm0_1 : Vserver_max Є IN Axm0_2: P Є IN La valeur de QoS négociée est une variable typée dans les invariants inv0_1 et inv0_2. 100

110 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 Inv0_1 : Vnegoc Є IN variables : Vnegoc Vfinal Inv0_2 : Vnegoc Vserver_max Inv0_3 : Vfinal Є IN Inv0_4 : Inv0_5 : Vfinal Vserver_max Vfinal P IV Événements La valeur initiale de Vnegoc est P. La valeur finale du protocole est définie de manière non-déterministe par l événement QoSspnp, qui indique que la valeur Vfinal devient Vnegoc. Init : Vnegoc := P Vfinal := 0 QoSspnp Vfinal : Vfinal = Vnegoc IV.4.5. Premier raffinement Le rôle de ce raffinement est de spécifier la valeur finale de l'état du client et du serveur tel que défini dans les exigences FUN-4 à FUN-6. Nous verrons également comment la valeur de qualité de service est négociée, étape par étape entre l'objet client et l'objet serveur. IV État Dans ce premier raffinement, nous introduisons la notion de statut. Pour ce faire, nous introduisons un ensemble nommé STATUS. Il est composé de trois éléments distincts: proposer, accepter et refuser, comme illustré ci-dessous: 101

111 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 Sets: STATUS Axm1_1: STATUS ={Propose, Accept, Refuse} Axm1_2 : Propose Accept Constants: Propose Accept Refuse Vserver Axm1_3 : Propose Refuse Axm1_4 : Accept Refuse Axm1_5 : Vserver Є IN Axm1_6 : Vserver Vserver_max Nous introduisons les variables d'état c_st et s_st de l'objet client et serveur respectivement. Ces variables sont membres de STATUS. variable: c_st s_st Vnegoc Vfinal Inv1_1 : c_st Є STATUS Inv1_2 : s_st Є STATUS Inv1_3 : c_st = Accept P Vserver Inv1_4 : s_st = Accept ==> c_st = Accept L exigence FUN-5 est formalisée dans inv1_4 et stipule que le client accepte lorsque le serveur accepte. IV Événements Dans ce raffinement, nous introduisons plusieurs nouveaux événements: Client_accept, Client_refuse, Server_accept et Server_refuse. Les événements Client_accept, Client_refuse et Server_refuse sont encore très abstraits parce que dans les deux premiers, le client est au courant de l'état du serveur et dans le second le serveur est conscient de l état du client. Ce 102

112 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 n'est évidemment pas possible et ça sera mis en œuvre correctement dans le prochain raffinement. Client_accept Client_refuse Server_accept Server_refuse When When When When c_st = Propose s_st = Propose s_st = Propose s_st = Propose s_st = Accept Then Then c_st = Refuse Then c_st := Accept c_st := Refuse s_st := Accept Then Vfinal :=Vserver End End s_st := Refuse End End Il s'agit clairement d'une abstraction commode, mais pas une mise en œuvre finale. En effet, cet accès direct sera supprimé dans le prochain raffinement.. Init : Vnegoc := P QoSspnp Vfinal := 0 When c_st Propose c_st := Propose s_st Propose s_st := Propose Then skip End Le raffinement de l'événement QoSspnp doit affiner son abstraction, qui est un événement non-déterministe. IV.4.6. Second raffinement Dans ce raffinement, le trader va entrer en scène en coopérant avec les objets client et serveur pour négocier la valeur de QoS. En fait, le client ne pourra plus accéder directement à la valeur du serveur comme c'était le cas dans le raffinement précédent, cela sera fait par 103

113 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 l intermédiaire du trader. Nous introduisons alors ce trader qui se situe entre le client et le serveur. IV État L'état est d'abord élargi avec une valeur constante de qualité de service du trader: Vtrader désignée par les axiomes axm2_1 et axm2_2, et une variable booléenne Publish indiquée implicitement par inv2_1 et inv2_2. Constants: Vtrader True Axm2_1: Vtrader Є IN Axm2_2: Vtrader Vserver_max False Axm2_3: B={True, False} Sets: B variables: Publish Inv2_1: Publish Є B Inv2_2: Publish=True ==> Vtrader Vserver IV Événements L'événement d'initialisation est étendu d'une manière simple, comme indiqué ci-dessous. La valeur booléenne publish est mise à «False» au début. Init : Vnegoc := P Vfinal := 0 c_st := Propose s_st := Propose Publish := False Client_accept When c_st = Propose Publish = True Then c_st := Accept Vfinal := Vserver End Client_refuse When s_st = Propose Publish = False Then c_st := Refuse End 104

114 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 Server_accept: When s_st = Propose Publish = True Then s_st:= Accept End Server_refus: When s_st = Propose Publish = False Then s_st := Refuse End IV.4.7. Troisième raffinement IV État Dans ce raffinement, nous allons introduire la notion de délai. En fait, la communication entre les objets client et serveur peuvent être basée sur un canal non fiable. Cela se fera par l'ajout de nouvelles variables et une constante. Constants: max_timer Axm3_1: Max_timer Є IN Axm3_2 : Max_timer 0 variables: C_timer S_timer Inv3_1 : C_timer Є 0.. Max_timer Inv3_2 : S_timer Є 0.. Max_timer Inv3_4 : C_timer = Max_timer + 1 C_st = refuse Inv3_5 : S_timer = Max_timer + 1 S_st = refuse IV Événements L'événement d initialisation est étendu d'une manière simple. 105

115 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 L Événement QoSspnp n'est pas modifié dans ce raffinement. Init : Vnegoc := P Vfinal := 0 C_st := propose S_st := propose publish := FALSE C_timer := 0 S_timer := 0 QoSspnp When C_st propose S_st propose Then skip End Client_accept When C_st = propose Publish = TRUE C_timer <= Max_timer Then C_st := accept Vfinal Vserver End Server_accept When S_st = propose Publish = TRUE S_timer <= Max_timer Then S_st := accept End Client_refuse When S_st = propose Publish = FALSE C_timer > Max_timer Then C_st := refuse End Server_refuse When S_st = propose Publish = FALSE S_timer > Max_timer Then S_st := refuse End 106

116 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.5. Travaux similaires Plusieurs travaux utilisent event-b pour spécifier les systèmes. Par exemple, Abrial [72] introduit des patrons pour les spécifications en event-b basées sur les états et utilise les notations graphiques informelles semblables à TD pour représenter les patrons. Cansell et al. [73] introduit un modèle de contraintes temporelles basé sur event-b pour les applications distribuées. Ce travail utilise le temps global qui interagit avec un nombre de temps actifs comme dans les modèles classiques. Bicarregui [74] étend les notations d'event-b à trois opérateurs de logique temporelle linéaire (LTL). Ce travail propose d'utiliser trois nouveaux concepts pour remplacer la structure standard d event-b, WHEN... THEN... END, pour représenter les trois opérateurs de LTL. KAOS [75] est une technique de modélisation orientée objectif pour la spécification des besoins, dans laquelle un objectif définit un objectif du système complexe. KAOS utilise un modèle objectif pour déclarer les exigences du système. Une tentative de combiner KAOS avec la méthode B est introduit par Ponsard et Dieul [76]. Dans [77], Rezazadeh élucide comment une nouvelle notation formelle et un outil peuvent aider à surmonter les difficultés de compréhension de la spécification d'origine de la fonction centrale de contrôle d'affichage et du système d'information (CDIS) grâce à un processus de raffinement itératif. Divakar Yadav et Michael Butler [78] présentent un développement formel, utilisant event-b, d'un système où les processus communiquent par diffusion de messages, ces derniers sont délivrés selon une causalité et un ordre total. Richard O et al. [79] introduit le trader ODP et montre comment il peut être précisé en LOTOS en utilisant la sémantique architecturale. Dans [80], l'utilisation des techniques formelles de spécification (FDT) Z, LOTOS et SDL'92 est étudiée et évaluée pour la spécification du trader ODP. Bouhdadi M et al. [81] montre comment traduire les concepts de spécification du point de vue traitement et entreprise, respectivement, en event-b. Le travail présenté dans ce chapitre est le seul à proposer des techniques de spécification et de vérification de QoS dans ODP en utilisant la méthode B. 107

117 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.6. Conclusion Le modèle de référence du traitement réparti ouvert (RM ODP) est destiné à créer une norme internationale pour la conception et la réalisation de systèmes répartis ouverts. L'utilisation des méthodes formelles dans le processus de conception de systèmes ODP est explicitement requise. Un point important à prendre en compte est l'incorporation et l amélioration des techniques de preuves nombreuses afin d'assurer que le système final soit «correcte par construction». Dans ce chapitre, l'utilisation de la technique de description formelle event-b est utilisée et vérifiée avec la plateforme Rodin. Nous avons présenté notre approche pour le développement de systèmes distribués en Event-B. Nous avons proposé un protocole de négociation des exigences de qualité de service entre les objets de l'entreprise en utilisant les techniques de raffinement de la méthode B. En outre, afin de vérifier notre modèle final, les modèles issus des machines B sont implémentés dans la plate-forme Rodin. 108

118 CONCLUSION GENERALE ET PERSPECTIVES L objectif de cette thèse est de contribuer à la spécification et à la vérification des systèmes distribués conformément au modèle de référence du traitement réparti ouvert (RM-ODP). Nous avons choisi d utiliser uniquement des notations et des techniques formelles pour les concevoir. La spécification formelle a l avantage de permettre au concepteur de constater une erreur au plus tôt, notamment grâce aux vérifications mathématiques sur le modèle. Notre intérêt a porté sur la méthode B. C est une méthode formelle utilisée pour modéliser des systèmes et vérifier la correction de leur conception afin d aboutir à des systèmes corrects par construction. 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. Nos contributions sont organisées en trois chapitres : - Le Chapitre 2 [49] traite la nécessité de la notation formelle des langages de point de vue ODP. Nous avons utilisé la méthode B événementielle pour la spécification précise des politiques ODP 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. - Le chapitre 3 [88] [89] présente 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. - Le chapitre 4 [66] [90] modélise le processus de négociation de la QoS par l intermédiaire du trader en utilisant la méthode event-b. 109

119 Conclusion générale et perspectives Nous avons utilisé la plate-forme Rodin pour vérifier l exactitude des machines B conçus. Les obligations de preuves générées par l outil de preuves nous ont permis de valider et de vérifier les spécifications proposées. Les travaux présentés dans cette thèse, concernant l investigation de l utilisation de la méthode B dans le processus de développement des systèmes répartis ouverts, s inscrivent dans un champ encore peu exploré de la recherche. Nous pensons que l approche présentée dans cette thèse permet de donner un cadre rigoureux pour définir les outils de vérification pour un système ODP. Ces travaux ouvrent maintenant de nombreuses perspectives, à court terme comme à long terme, afin d aider le concepteur à définir l ensemble des aspects d un système ODP. Pour les travaux futurs, nous allons généraliser notre approche à d'autres concepts des systèmes ODP. Ce sera notre base pour une investigation plus approfondie de l'utilisation de la méthode event-b dans le processus de conception des systèmes ODP. En outre, des études de cas devraient être développées en utilisant ces modèles. Nous projetons, également de généraliser notre approche de négociation de la QoS à d'autres méthodes de négociation de qualité de service dans les systèmes ODP en l occurrence au protocole de négociation bornée et aux négociations multi-parties 1 x N et M x N de QoS. Un système multi-agents est un ensemble d agents qui évoluent dans un environnement commun [16]. Plusieurs méthodes d analyse et de conception des systèmes multi agents (SMA) ont été proposées récemment. La plupart d entre elles, s appuient sur des techniques de modélisation empruntées à des méthodes connues en développement orienté-objets ou en ingénierie des connaissances pour aider à la construction des SMA. Une autre perspective de cette thèse consisterait à vérifier dans quelle mesure notre approche de spécification des systèmes répartis ouverts pourrait être appliquée aux SMAs et inversement, comment pourrait-on adapter les méthodes et outils de spécification des SMA au contexte des systèmes répartis ouverts. 110

120 Bibliographie BIBLIOGRAPHIE 1. ISO/IEC, Basic Reference Model of Open Distributed Processing-Part1: Overview and Guide to Use, ISO/IEC CD , ISO/IEC, RM-ODP-Part2: Descriptive Model, ISO/IEC DIS , ISO/IEC, RM-ODP-Part3: Prescriptive Model, ISO/IEC DIS , ISO/IEC, RM-ODP-Part4: Architectural Semantics, ISO/IEC DIS , July ISO/IEC, ODP Type Repository Function, ISO/IEC JTC1/SC7 N2057, ISO/IEC, the ODP Trading Function, ISO/IEC JTC1/SC M. Sandro: Spécification et Génération de Tests du Comportement Dynamique des Systèmes à Objets Répartis, Thèse de doctorat, spécialité informatique, université de Nice Sophia Antipolis, 232 p. 8. G.Michaek and P.Jonathan. Applications of Formal Methods, chap. Applications of Formal Methods FAQ. -- Prentice Hall, J-R. Putman. Architecting with RM-ODP, Prentice-Hal, ISO/IEC, Use of UML for ODP system specifications, ISO/IEC 19793, may M.-P. Gervais. Méthodologie ODAC: Le guide de spécification comportemental, Rapport de recherche LIP A. Corbière (2006). Analyses des apports du méta-standard ODP-RM à la communauté EIAH Instances sur un système de formation, Thèse de doctorat, spécialité informatique, l Université du Maine, 182 p. 13. ISO. Working Draft for: Open Distributed Processing - Reference Model - Quality of Service. ISO/IEC JTC1/SC N Ed 6.4, January ITU-T. Information Technology - Open Distributed Processing - Reference Model: Overview. ITU-T Recommendation X.901 (ISO/IEC DIS ), December Xavier BLANC. MDA en action. EYROLLES, mars

121 Bibliographie 16. J. Jamont (2005). Diamond: Une approche pour la conception de systèmes multi-agents embarqués, Thèse de doctorat, spécialité informatique, institut national polytechnique de Grenoble, 304 p. 17. J. Malenfant. Modélisation de la sémantique formelle des langages de programmation en UML et OCL. Rapport technique, IRISA, K. Slonneger. Formal Syntax and Semantics of Programming Languages. Addison-Wesley Publishers, D.A. Schmidt. Denotational Semantics : a methodology for language development. Wm.C. Brown Publishers, D. Scott. Domains for denotational semantics. In Proceedings International Colloquium on Automata, Languages, and Programming '82, D. Scott. Domains for denotational semantics. In Proceedings International Colloquium on Automata, Languages, and Programming '82, F. Jean-Marie, E. Jacky and B. Mireille : L Ingénierie Dirigée par les Modèles : au-delà du MDA. Informatique et Systèmes d Information. Hermès Science, lavoisier édition, février Hervé Panetto, Meta-modèles et modèles pour l intégration et l interopérabilité des applications d entreprises de production, rapport de thèse, J. Miller and J. Mukerji: Model Driven Architecture (MDA) Guide. Object Management Group, Inc., juin B. Combemale (2008). Approche de métamodélisation pour la simulation et la vérification de modèle Application à l ingénierie des procédés, Thèse de doctorat, spécialité informatique, l Université de Toulouse, 198 p. 26. Object Management Group, Inc. Meta Object Facility (MOF) 2.0 Query/View/Transformation (QVT) Specification, version 1.0, avril J. Abrial. Data semantics. In IFIP Working Conference Data Base Management, pages 1 60, J. Abrial. The B-book: assigning programs to meaning, Cambridge university press,

122 Bibliographie 29. P. Behm and al., Meteor: A successful application of B in a large project. In World Congress on Formal Methods 1999, number 1709 in Lecture Notes in Computer Science, pages Springer Verlag, September J. Abrial. Extending B without changing it (for developing distributed systems). In Henri Habrias, editor, Proceedings of 1st Conference on the B method, Putting into Practice methods and tools for information system design, pages I. Akram (2006). B/UML : mise en relation de spécifications B et de description UML pour l aide à la validation externe de développement formel en B, Thèse de doctorat, spécialité informatique, l Université de Grenoble 1, 290 p. 32. E. Dijkstra. A discipline of programming, prentice hall, E. Dijkstra. Guarded Commands, Non determinacy and formal derivation of programs, Communication of the ACM, vol. 18, n 8, pp , C. Hoare. An axiomatic basis for computer programming, communication of the ACM, vol. 12, n 10, pp , J. Abrial and L. Mussat. Introducing dynamic constraints in B. In Didier Bert, editor, B, volume 1393 of Lecture Notes in Computer Science, pages Springer, J. Abrial. Event driven sequential program construction. MATISSE project, October J. Abrial, D. Cansell, and D. Méry. A mechanically proved and incremental development of IEEE 1394 tree identify protocol. Formal aspects of computing, 14(3), April S. Colin. (2006). Contribution `a l intégration de temporalité au formalisme B : Utilisation du calcul des durées en tant que sémantique temporelle pour B, Thèse de doctorat, spécialité informatique, l Université de Valenciennes et du Hainaut-Cambrésis, 212 p. 39. J.M. Spivey, The Z Reference manual, Prentice Hall, IUT, SDL: Specification and Description Language, IUT-T-Rec. Z.100, ISO/IUT, LOTOS: a formal description technique based on the temporal ordering of observational behavior, ISO/IEC 8807, August

123 Bibliographie 42. H. Bowman and al., FDTs for ODP, Computer Standards & Interfaces Journal, vol. 17, no.5-6, Elsevier Science Publishers, pp , M. Bouhdadi, E. Chabbar and Y. Balouki. A UML/OCL Meta-model Syntax of Structural Constraints in ODP Enterprise Language, WSEAS Transactions on. Computers, vol. 6, no.1, pp , P.F. Linington, Z Milosevic, and K. Raymond, policies in communities: Extending the enterprise viewpoint. In Proc. 2nd International Workshop on Enterprise Distributed Object Computing (EDOC'98), San Diego, USA, page 11, November ISO/IEC. RM-ODP Enterprise Language. Draft International Standard ISO/IEC 15414, ITU-T X.911, ISO, P. Linington. RM-ODP: The architecture. In K. Milosevic and L. Armstrong, editors, open distributed processing II, pages Chapman & Hall, Feb H. Belhaj, Y. Balouki, J. Laassiri, R. Benaini, M. Bouhdadi and S. El Hajji. Using BPEL for Behavioral Concepts in ODP Computational Language. Proceedings of the World Congress on Engineering 2009 Vol I, WCE '09, July 1-3, 2009, London, U.K., Lecture Notes in Engineering and Computer Science, pp , Newswood Limited, F. Duran, J. Herrador, and A. Vallecillo. Using UML and Maude for Writing and Reasoning about ODP Policies. Proceedings of the 4th International Workshop on Policies for Distributed Systems and Networks (POLICY 03), Lake Como (Italy). pp , IEEE Computer Society Press, June H. Belhaj, M. Bouhdadi and S. Elhajji. Modeling ODP Policies by using event-b. IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 6, November M. Di Micheli, G. Cotta. Qualité de service dans les réseaux de valeur des TIC et de la sécurité pour l'utilisateur, ISCOM (Institut supérieur de communication et de technologie de l information) March ). 51. ITU-T Recommendation E.800 Term and definition related to Quality of Service and network performance including dependability (August 1994 ). 114

124 Bibliographie 52. ISO/IEC TR Information technology Quality of service Guide to methods and mechanism ( November 1999). 53. ITU-T Recommendation G Communications quality of service: a framework and definitions ( November 2001 ). 54. ITU-T E.860 Framework of a service level agreement (June 2002). 55. J. Abrial. A system development process with Event-B and the Rodin Platform. ICFEM (2007) G. Myers. The art of Software Testing, John Wiley &Sons, New York, R. Binder. Testing object oriented systems. Models. patterns, and tools, Addison-Wesley, B. Rumpe. Agile Modeling with UML, LNCS vol. 2941, Springer, 2004, pp K. Beck. Column on Test-First Approach. IEEE Software, vol. 18, no. 5, pp.87-89, L. Briand. A UML-based Approach to System testing, LNCS vol Springer, 2001, pp Rumpe. Executable Modeling UML. A Vision or a Nightmare?, in: issues and trends of information technology management in contemporary associations, seattle, Idea Group, London, pp T. Joochim, C. Snook, M. Poppleton and A.Gravell (2010) timing diagrams requirements modelling using event-b formal methods. In: IASTED International Conference on Software Engineering (SE2010), February 16 18, 2010, Innsbruck, Austria. 63. C. Snook & M. Butler. UML-B and Event-B: an integration of languages and tools. Proc. IASTED International Conf. on Software Engineering (SE2008), Innsbruck, Austria, M. Bouhdadi, B. El Ouahidi and D. Bourget. An UML-based Meta-language for the QoSaware Enterprise Specification of Open Distributed Systems, IFIP International Federation for Information Processing Series, vol. 85, Springer Boston, pp

125 Bibliographie 65. Tutorial on ODP Trading Function, Mirion Bearman, DSTC, Faculty of Information Sciences & Engineering, University of Canberra. 66. H. Belhaj, Y. Balouki, M. Bouhdadi and S. Elhajji. Using Event B to specify QoS in ODP Enterprise language. PRO-VE'10 11th IFIP Working Conference on virtual enterprises, Saint-Etienne, France, October Verma. Service Level Agreements on IP Networks, Proceedings of the IEEE, Volume 92, (9), September, D. Goderis and al., Service Level Specification Semantics, Parameters and negotiation requirements, draft-tequila-sls-02.txt, February, E. Campagna and V. De Nitto Personè. Quality of Service: definitions and methods in the international standard. Settembre 2008 RR J.-R. Abrial, M. Butler, S. Hallerstede, L. Voisin. An Open Extensible Tool Environment for Event-B. ICFEM M.J. Butler and S. Hallerstede. The Rodin Formal Modelling tool. BCS-FACS Christmas 2007 Meeting Formal methods in Industry London, J.-R. Abrial. Tutorial - Case study of a complete reactive system in Event-B: A mechanical press controller. Proc. 5th International Symposium on Formal Methods (FM 2008), Turku, Finland, D. Cansell, D. Méry and J. Rehm. Time Constraint Patterns for Event B Development. Proc. Formal Specification and Development in B, 7th International Conf. of B (B 2007), Besancon, France, P J. Bicarregui, and al., Towards Modelling Obligations in Event-B. Proc. International Conf. of ASM, B and Z Users, London, UK, 2008, E. Letier and A.V. Lamsweerde. Agent-Based Tactics for Goal-Oriented Requirements Elaboration. Proc. 24th International Conf. on Software Engineering (ICSE 02), Or-lando, Florida, USA, 2002,

126 Bibliographie 76. C. Ponsard and E. Dieul. From Requirements Models to Formal Specifications in B. Proc. International Workshop on Regulations Modelling and their Validation and Verification (REMO2V 06), Universitaires de Namur, Luxemburg, 2006, A. Rezazadeh, N. Evans and M.Butler. Redevelopment of an Industrial Case Study Using Event-B and Rodin. In: BCS-FACS Christmas 2007 Meeting - Formal Methods In Industry, 17 December 2007, London. 78. D. Yadav and M. Butler. Formal Specifications and Verification of Message Ordering Properties in a Broadcasting System using Event B. Technical Report, School of Electronics and Computer Science, University of Southampton. 79. R. O. Sinnott, K. J. Turner. Applying the architectural semantics of ODP to develop a trader specification. Computer networks and ISDN systems ISSN CODEN CNISE9 1997, vol. 29, no 4 pp Elsevier, Amsterdam, PAYS-BAS. 80. J. Fischer, A. Prinz and A. Vogel. Different FDT's confronted with different ODP-viewpoints of the trader. Book Series Lecture Notes in Computer Science Éditeur Springer Berlin / Heidelberg Volume 670/1993, Pages Y. Balouki, J. Laassiri, H. Belhaj, S. El hajji and M. Bouhdadi. Event B for ODP Enterprise Behavioral Concepts Specification, Proceedings of the World Congress on Engineering 2009 Vol I, WCE '09, July 1-3, 2009, London, U.K., Lecture Notes in Engineering and Computer Science, pp , Newswood Limited, M. Bouhdadi and al., A Semantics of Behavioural Concepts for Open Virtual Enterprises. Series: Lecture Notes in Electrical Engineering, Vol. 27.Springer, P Y. Balouki and M. Bouhdadi. Using BPEL for Behavioural Concepts in ODP Enterprise Language, Virtual Enterprises and Collaborative Networks, IFIP, Vol. 283, pp , Springer, M. Bouhdadi, Y. Balouki and E. Chabbar. Meta-modelling Syntax and Semantics of Structural Concepts for Open Networked Enterprises, Lecture Notes in Computer Science, Vol. 4707, pp , Springer, ISO/IEC JTC1/SC21/WG7/N812, Documentation of Discussion on Trader Information Model, June

127 Bibliographie 86. ISO/IEC JTC1/SC21/WG7/N783, An Integrated Approach to Trader Contexts, May ISO/IEC JTC1/SC21/WG7/N790, A Proposed Trader Information model, May H. Belhaj, M. Bouhdadi and S. Elhajji. Verifying ODP trader function by using Event B. IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 4, No 9, July H. Belhaj, M. Bouhdadi and S. Elhajji. Using event B to specify trader function in ODP. Journal of Computer Science and Control Systems (JCSCS) Volume 3, Number 2, H. Belhaj, S. El hajji and M. Bouhdadi. Modelling QoS bounded parameter negotiation protocol by event-b. International Conference on Multimedia Computing and Systems (ICMCS'11), Ouarzazate, Morocco April 7-9, Mohamed Bouhdadi, El maati Chabbar et Hafid. Belhaj: A Meta-model Semantics for Structural Constraints in ODP Computational Language WSEAS Transactions on Computers, Volume 6, Issue 2, WSEAS Press, pp: ,

128 WEBIOGRAPHIE 91. ISO : International Organization for Standardization, Telecommunication Standardization Sector (ITU-T), The Object Management Group (OMG), cf RODIN. Development Environment for Complex Systems (Rodin)