Service des affaires estudiantines RABAT
N° d’ordre : 2577
THÈSE DE DOCTORAT
Hafid BELHAJ
Discipline : InformatiqueSpécialité : Systèmes répartis ouverts
Titre de thèse :
Soutenue le 21 Juin 2012 devant le jury composé de :
Président :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. 1014 RP, Rabat-Maroc.
Tel : + 212 (0) 37 77 18 34/35/38, Fax : + 212 (0) 37 77 42 61, http://www.fsr.ac.ma.
Méthode B pour la Spécification et la vérification
I 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.
II 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,
III 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,
IV
Remerciements ... I
Résumé ... II
Abstract ... III
Tables des matières ... IV
Index des figures ... VII
Introduction générale ... 1
1. De l’Orienté Objet aux systèmes répartis ouverts ... 1
2. Le besoin d’un standard pour le traitement réparti ouvert ... 2
3. Thème et objectifs de la recherche ... 4
4. 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 ... 10
I.2.3. Architecture ... 12
I.3. Sémantique dénotationnelle ... 18
I.3.1. Principes généraux ... 18
I.3.2. Constituants d'une sémantique dénotationnelle ... 19
I.4. Ingénierie dirigée par les modèles et approche MDA... 20
I.4.1. Les principes généraux de l’IDM... 20
I.4.2. La métamodélisation ... 21
I.4.3. L’approche MDA ... 21
I.4.4. Transformation des modèles ... 23
I.5. Spécification formelle en utilisant la méthode B ... 23
I.5.1. Présentation de la méthode B ... 25
I.5.2. Présentation du B événementiel ... 30
I.5.3. Plateforme RODIN ... 37
I.6. Conclusion ... 37
Chapitre II : Modèles B pour la spécification des concepts
de base du point de vue entreprise... 39
II.1. Introduction ... 39
II.2. Langage d’entreprise de RM-ODP ... 40
II.3. Cohérence du point de vue entreprise avec les autres points de vue ... 45
II.4. Concepts de base du langage d’entreprise de RM-ODP ... 45
II.5. Spécification informelle des concepts de base du langage d’entreprise ... 47
II.5.1. Niveaux abstraits et concrets des concepts de base du langage d’entreprise ... 47
II.5.2. Relations entre niveaux abstrait et concret : Play, Use et belong ... 49
V
II.6.1. Modèle abstrait tenant compte des politiques ODP ... 52
II.6.2. Raffinement: Modèle concret tenant compte des politiques ODP... 55
II.7. Conclusion ... 57
Chapitre III :Spécification et vérification de la fonction de
courtage par event-B ... 59
III.1. Introduction ... 59
III.2. Fonctions ODP ... 60
III.2.1. RM-ODP ... 60
III.2.2. Fonctions ODP ... 61
III.3. La fonction de courtage ... 62
III.3.1. Aperçu général ... 62
III.3.2. Description du trader du point de vue entreprise ... 63
III.3.3 Description du trader du point de vue information ... 65
III.3.4. Description du trader du point de vue ingénierie ... 70
III.3.5. Description du trader du point de vue technologie ... 70
III.3.6. Description du trader du point de vue traitement ... 71
III.4. Spécification du trader ODP en utilisant event-B ... 75
III.4.1. Stratégie de raffinement ... 75
III.4.2. Modèle abstrait de la fonction de courtage ... 76
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 ... 81
III.6. Conclusion ... 83
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 ... 84
IV.1. Introduction ... 84
IV.2. RM-ODP et qualité de service (QoS) ... 87
IV.2.1. RM-ODP ... 87
IV.2.2. Fonction de courtage ... 88
IV.3. La spécification d’entreprise de la QoS ... 91
IV.3.1. Le modèle objet de la QoS du point de vue entreprise ... 92
IV.3.2. Négociation de la QoS dans une communication client-serveur pour parvenir à un accord de QoS ... 95
IV.4. Spécification de la négociation de paramètre unique de QoS en utilisant event-B .... 97
IV.4.1. Représentation informelle du protocole de négociation de paramètre unique de QoS ... 97
IV.4.2. Document des exigences ... 98
IV.4.3. Stratégie de raffinement ... 99
IV.4.4. Modèle initial ... 100
IV.4.5. Premier raffinement ... 101
IV.4.6. Second raffinement ... 103
IV.4.7. Troisième raffinement ... 105
VI
Bibliographie ... 111
Webiographie ... 119
VII
FIGURE 1 . MODELE ARCHITECTURAL DE RM-ODP ... 10
FIGURE 2. LA RELATION ENTRE LES POINTS DE VUE ODP ... 16
FIGURE 3. PYRAMIDE DE MODELISATION DE L’OMG ... 22
FIGURE 4. MDA : UN PROCESSUS EN Y DIRIGE PAR LES MODELES ... 23
FIGURE 5. PROCESSUS DE DEVELOPPEMENT EN B ... 25
FIGURE 6. STRUCTURE D’UNE MACHINE ABSTRAITE B ... 26
FIGURE 7. UNE MACHINE B ET UN RAFFINEMENT POSSIBLE ... 28
FIGURE 8. ÉVENEMENTS EN EVENT-B ... 31
FIGURE 9 SUBSTITUTIONS EN B EVENEMENTIEL ... 32
FIGURE 10. SCHEMA DE MODELES EN B EVENEMENTIEL ... 32
FIGURE 11. L’HORLOGE EN EVENT-B, ET SON RAFFINEMENT ... 34
FIGURE 12. CONCEPTS DE BASE DU POINT DE VUE ENTREPRISE . ... 47
FIGURE 13 NIVEAUX ABSTRAITS ET CONCRETS DES CONCEPTS DE BASE DU POINT DE VUE ENTREPRISE. ... 50
FIGURE 14 . ETAPES DE CONCEPTION D’UN MODELE EVENT-B DES CONCEPTS D’ENTREPRISE ODP ... 52
FIGURE 15. TRADER ET SES UTILISATEURS. ... 63
FIGURE 16. EXEMPLE D’UNE STRUCTURE DE CONTEXTE ... 68
FIGURE 17. REPRESENTATION DE LA STRUCTURE DE CONTEXTE DE LA FIGURE 16 ... 68
FIGURE 18. SCENARIO D’INTERACTION DU TRADER ... 74
FIGURE 19. MODELE ABSTRAIT DE LA FONCTION DE COURTAGE]. ... 76
FIGURE 20. COMMUNICATION ENTRE LE TRADER ET SES UTILISATEURS TENANT COMPTE DE LA FONCTION DE BASE DE DONNEES ... 78
FIGURE 21. COMMUNICATION ENTRE LE TRADER ET SES UTILISATEURS TENANT COMPTE DE LA BD: INITIALISATION ... 79
VIII
TENANT COMPTE DE LA BD: EVENTS ... 80
FIGURE 23. LE CONTEXTE DU MODELE ABSTRAIT DU TRADER. ... 81
FIGURE 24. LA MACHINE DU MODELE ABSTRAIT DU TRADER. ... 82
FIGURE 25. LE CONTEXTE DU MODELE DE RAFFINEMENT DU TRADER. . 82
FIGURE 26. LA MACHINE DU MODELE DE RAFFINEMENT DU TRADER. .. 83
FIGURE 27. TRADER ET SES UTILISATEURS ... 90
FIGURE 28. MODELISATION DE LA QOS DU POINT DE VUE ENTREPRISE DE LA FONCTION DE COURTAGE ... 93
FIGURE 29. NEGOCIATION DE PARAMETRE UNIQUE DE QOS ... 96
FIGURE 30. NEGOCIATION BORNEE DE LA QOS ... 97
1
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
2 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
3 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 ;
4 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é.
5 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
6 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.
7
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
8 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 non-ambigü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éta-modé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
9 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 10746-1[1]: aperçu général: elle contient un aperçu général du modèle de référence ODP, en précise les motivations, le domaine d'application et la justification, et propose une explication des concepts clés, ainsi qu'une présentation de l'architecture ODP;
– La Rec. UIT-T X.902 | ISO/CEI 10746-2 [2]: fondements: elle contient la définition des concepts et le cadre analytique à utiliser pour la description normalisée des systèmes de traitement répartis;
– La Rec. UIT-T X.903 | ISO/CEI 10746-3 [3]: architecture: elle contient la spécification des caractéristiques d'un système réparti ouvert. Ce sont les contraintes auxquelles les normes ODP doivent se soumettre;
– La Rec. UIT-T X.904 | ISO/CEI 10746-4 [4]: sémantique d'architecture: elle contient une formalisation des concepts de modélisation ODP définis dans la Rec. UIT-T X.902 | ISO/CEI 10746-2, articles 8 et 9. La formalisation s'obtient en interprétant chaque concept à partir d'éléments des différentes techniques normalisées de descriptions formelles.
10
RM-ODP Architecture Model
Fundations
Trminology Viewpoints Management
Structuring Rules Object Model
Specification Rules Conformance Rules
Enterprise VP Information VP Computational VP Engineering VP
Objectives Scope Policies Community Role Action Entreprise Object Federation Conformance Info Domain Static scema Information Objects Dynamic scema Invaraint Scema Policy Control Node Chanel Capsule Cluster ODP Functions Engineering Interfaces Engineering Objects Engineering Binding Engineering Behavior Interactions Interfaces Service Binding Computational Objects Policy Behavior Conformance Info Conformance Points Technology VP Conformance Info RM-ODP Architecture Model
Fundations
Trminology Viewpoints Management
Structuring Rules Object Model
Specification Rules Conformance Rules
Enterprise VP Information VP Computational VP Engineering VP
Objectives Scope Policies Community Role Action Entreprise Object Federation Conformance Info Domain Static scema Information Objects Dynamic scema Invaraint Scema Policy Control Node Chanel Capsule Cluster ODP Functions Engineering Interfaces Engineering Objects Engineering Binding Engineering Behavior Interactions Interfaces Service Binding Computational Objects Policy Behavior Conformance Info Conformance Points Technology VP Conformance 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 10746-2 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 10746-3. Ces concepts se regroupent en trois catégories:
11
I.2.2.1. 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.2.2.2. 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.
12 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.2.2.3. 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 10746-3 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 10746-2, elle définit:
13 • 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.2.3.1. 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.2.3.2. 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
14 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.2.3.3. 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.
15 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.2.3.4. 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.2.3.5. 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].
16
I.2.3.6. 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
Information Traitement
Ingénierie
Technologie
Cahier des charges
Spécification fonctionnelle
Conception
Implantation
17
I.2.3.7. 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.2.3.8. 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
18 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
19 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.
20 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
21
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 modélisation est habituellement appelé méta-modè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éta-modè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.
22 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).
23
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 1980-1990 : 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
24 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.
25
I.5.1. Présentation de la méthode B
I.5.1.1. 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.
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
Obligations de preuves Obligations de preuves Documents formels Spécification informelle Exprimés en B Conception détaillée Raffinement 1 Raffinement n Obligations de preuves Successif Obligations de preuves Spécification abstraite Conception préliminaire Raffinement Obligations de preuves Implémentation Codage Raffinement Obligations de preuves Raffinement Analyse des besoins
26 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.5.1.1.1. 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) :
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.
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
27 - 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.5.1.1.2. 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.5.1.2. 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].
28
I.5.1.3. 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.
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
MACHINE Clock VARIABLES hour INVARIANT hour ∈ 0..23 INITIALISATION hour :∈ 10..16 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 ∈ 0..59 ∧ h=hour INITIALISATION h:=11 || minute :∈ 0..45 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
