UNIVERSITÉ MOHAMMED V – AGDAL
FACULTÉ DES SCIENCES
Rabat
Faculté des Sciences, 4 Avenue Ibn Battouta B.P. 1014 RP, Rabat – Maroc Tel +212 (0) 37 77 18 34/35/38, Fax : +212 (0) 37 77 42 61, http://www.fsr.ac.ma
N° d’ordre 2502
THÈSE DE DOCTORAT
Présentée par
Jalal LAASSIRI
Discipline : Informatique
Spécialité : Systèmes informatiques
Titre :
Spécification et Vérification des Systèmes Informatiques Distribuées
Conformément au Modèle de Référence du Traitement Réparti Ouvert
(RM-ODP)
Soutenue le 24 juin 2010
Devant le jury
Président :
M. Noureddine ZAHID,
Professeur (PES) à la Faculté des Sciences, Rabat
Examinateurs :
Mohamed EL MARRAKI, Professeur (PES) à la Faculté des Sciences, Rabat
M. Mohamed BOUHDADI, Professeur (PH ) à la Faculté des Sciences, Rabat
M. Mohammed EL KOUTBI, Professeur (PES) à ENSIAS Rabat
M. Mohammed RZIZA,
Professeur (PH ) à la Faculté des Sciences, Rabat
M. Said EL HAJJI,
Professeur (PES) à la Faculté des Sciences, Rabat
DEDICACES
A mes parents,
A toute la famille
A Tous mes amies
REMERCIEMENTS
Les travaux présentés dans cette thèse ont été effectués au sein de l’UFR de " Ma-thématiques et Informatique et Applications " du Département de MaMa-thématiques et Informatique à la faculté des sciences de l’Université Mohammed V- Agdal.
Je tiens à remercier tout d’abord très vivement mon encadrant de thèse Monsieur Said ELHAJJI, Professeur d’enseignement supérieures à la faculté des sciences de Rabat, pour son soutien, sa disponibilité, sa patience, sa collaboration étroite et son aide qui m’ont permis de mener à bien cette thèse. J’espère avoir été à la hauteur de ses attentes. Je suis aussi particulièrement reconnaissant envers Monsieur Mohamed BOUHDADI, Professeur à la faculté des sciences de Rabat, pour avoir accepté de diriger cette thèse mais aussi pour sa disponibilité et ses nombreux conseils et orientations décisives pour la concrétisation de la présente recherche.
J’exprime ma profonde gratitude à Monsieur Noureddine ZAHID, Professeur à la faculté des sciences de Rabat, pour l’honneur qu’il me fait d’évaluer ce travail, d’une part, et de présider le jury de thèse, de l’autre part. Qu’il trouve ici l’expression de ma profonde gratitude.
Je souhaite remercier Monsieur Mohamed EL MARRAKI,professeur à la faculté des sciences de Rabat, et Monsieur Mohammed EL KOUTBI, professeur à l’école nationale supérieure d’informatique et d’analyse des systèmes rabat, pour avoir accepté la lourde charge d’être Rapporteur et pour leurs précieuses remarques qui m’ont permis d’amélio-rer ce manuscrit. Je remercie aussi Monsieur Mohammed RZIZA, professeur à la faculté des sciences de Rabat, pour avoir accepté la lourde charge d’être Rapporteur et pour les nombreuses discussions que nous avons eu ensemble.
ii
recherche du " Laboratoire Mathématiques, Informatique et Applications " à la faculté des sciences de Rabat qui m’ont beaucoup soutenu, tout au long de mes études docto-rale, en m’apportant leur savoir, leurs expériences et leurs orientations académiques et pédagogiques.
Mes remerciements vont naturellement à l’ensemble des personnes que j’ai côtoyé durant ces quatre années et qui m’ont aidé ou tout simplement rendu agréable le déroulement de cette thèse.
Finalement, mes grands remerciements sont adressés à toutes les personnes qui ont contribué de près ou de loin dans la réussite de ce travail.
Résumé
La conception et le design des systèmes distribués ont besoin d’un Framework struc-turé afin qu’ils puissent être gérés et contrôlés avec succès. L’objectif du Modèle de ré-férence du traitement réparti ouvert (RM-ODP) est donc de définir ce Framework. C’est dans ce cadre que s’inscrit cette thèse. En effet, elle présente une approche basée sur la sémantique dénotationnelle à partir des spécifications informelles relatives au point de vue traitement et aussi au point de vue ingénierie dans le traitement réparti ouvert (ODP). La sémantique proposée se base aussi sur l’utilisation des langages UML et OCL afin de pouvoir effectuer des vérifications automatiques. Par ailleurs, la composante in-novante de notre thèse, qui consiste en l’approche sémantique dénotationnelle, nous a permis d’identifier un sous-ensemble de concepts définis dans la norme RM-ODP et de décrire, en OCL, la formalisation des contraintes statiques et les clauses liées aux concepts d’ODP. En outre, nous avons mis l’accent sur la sémantique des concepts asso-ciés aux deux points de vue cités auparavant et de relever les correspondances entre les concepts du comportement du langage de traitement et les concepts du langage BPEL. Pour se faire, nous avons utilisé le ’mapping’ entre UML et BPEL et nous avons ainsi montré l’applicabilité de l’approche proposée. Nous nous sommes intéressés également au problème de l’utilisation d’un outil de preuve Event-B pour des spécifications et vérification de systèmes distribuées. Et enfin, nous avons spécifié une sémantique des concepts de bases de données en utilisant le langage d’ingénierie de RM-ODP.
Mots clés : BPEL, Comportement, Framework, Langages de point de vue, Event-B, Spécifications, RM-ODP, Sémantique dénotationnelle, UML/OCL, Vérifications.
Abstract
Abstract The conception and the design of the distributed systems is an important issue and in order to be managed and controlled successfully, a structured Framework is needed. To fulfill this need, we are using the Reference Model of the Open Distribu-ted Processing (RM-ODP) whose objective is then to define this Framework. This last issue defines the main context of our thesis. Indeed, our thesis presents a denotational semantics approach based on the ODP (distributed opened processing) informal spe-cifications relative on one side to the Computational viewpoint and on the other side to the engineering viewpoint. The proposed Semantics is also based on the use of the UML and OCL languages to allow the automatic verifications. Furthermore, our inno-vative semantic denotational approach, gived us the possibility to identify a sub-set of concepts defined in the RM-ODP standard and to describe, in OCL language, the static constraints and the clauses related to the ODP concepts. Moreover, we have focused on the semantics of the concepts related to both points of view mentioned above as well as on the relationship transformations between the concepts of the behavior of the computational language and the concepts of the BPEL language. To achieve this, we have used the mapping between UML and BPEL. We were then able to illustrate and show the applicability of the proposed approach. In addition, we were interested in the use of a proof tool named Event-B, needed for the specification and the verification of distributed systems. Finally, we have specified semantics for databases concepts of RM-ODP Engineering Language.
Keywords : RM-ODP, information viewpoint, engineering viewpoint, computational
lan-guage, engineering specifications, Behaviour Semantics, UML/OCL, B-Method, Object DBMS.
Table des matières
REMERCIEMENTS i
Résumé iii
Abstract iv
Table des matières vii
Table des figures ix
1 LITERATURE SURVEY 4
1.1 RM-ODP . . . 4
1.1.1 RM-ODP Viewpoints And Specifications . . . 5
1.1.2 Formalization And Categorization Of Specification Of Concepts . 10 1.2 Denotational Semantics . . . 13
1.2.1 The Syntactic World . . . 15
1.2.2 The Semantic World . . . 15
1.2.3 The Connection Between Syntax And Semantics . . . 16
1.3 Formal Method . . . 17
1.3.1 Structuring The Requirement Document . . . 19
1.3.2 Informal Overview Of Discrete Models . . . 21
1.3.3 Managing The Complexity Of Closed Models . . . 22
1.3.4 The Structure Of The Event-B Notation . . . 24
1.3.5 Verification Of The Specification . . . 29
1.4 Conclusion . . . 31
INFORMA-vi
TION LANGUAGE 33
2.1 Introduction . . . 34
2.1.1 Literature Of Review . . . 37
2.2 RM-ODP . . . 38
2.2.1 RM-ODP Object Model (Foundations Part) . . . 39
2.2.2 RM-ODP Information Language . . . 41
2.3 Syntax Domain . . . 42
2.4 Semantics Domain . . . 44
2.5 Meaning Function . . . 46
2.6 Conclusion . . . 48
3 SPECIFYING DATA BASES MANAGEMENT SYSTEMS BY USING RM-ODP ENGINEERING LANGUAGE 49 3.1 State of the art . . . 50
3.1.1 RM-ODP Overview . . . 50
3.1.2 UML Meta-Model Adoption . . . 52
3.2 RM-ODP Presentation . . . 53
3.3 DBMS Object Model . . . 55
3.4 Engineering Language and DMBS Structure . . . 56
3.4.1 RM-ODP Common Functions . . . 56
3.4.2 DBMS Structure . . . 57
3.4.3 Syntax Domain . . . 58
3.4.4 Semantics Domain . . . 59
3.5 Conclusion . . . 62
4 MODEL OBJECT OF RM-ODP STANDARD IN DYNAMIC DISTRIBUTED DATABASES 63 4.1 Overview Of The RM-ODP Standard . . . 64
4.2 Distributed Databases Syntax . . . 66
4.3 Semantics Domain . . . 67
4.4 Meaning Function . . . 69
4.5 Function Trader And Activity Diagram For The DDB Process . . . 69
4.6 Conclusion . . . 70
5 USING BPEL FOR BEHAVIORAL CONCEPTS IN ODP COMPUTATIONAL LANGUAGE 72 5.1 Introduction . . . 73
5.2 Preliminaries . . . 75
5.2.1 BPEL . . . 76
5.2.2 The Core behavioral Concepts in RM-ODP Foundations Part . . 77
vii
5.4 Mapping to BPEL . . . 82
5.4.1 From UML to BPEL . . . 82
5.4.2 Execution of the Behavior processes . . . 83
5.5 The UML to BPEL Mapping Transformation . . . 84
5.6 Conclusion . . . 85
6 VERIFYING ODP COMPUTATIONAL BEHAVIORAL SPECIFICATION BY USING B-METHOD 87 6.1 Introduction . . . 88
6.2 Meta-Modeling Core Behavior Concepts in RM-ODP Foundations Part 90 6.2.1 Meta-Modeling Time and Behavioral Constraints . . . 91
6.3 Modeling Behavior constraints Specifications in Event-B . . . 96
6.4 Conslusion . . . 99
Table des figures
1.1 RM-ODP viewpoints and specifications . . . 6
1.2 Behavior diagram and Structure diagram . . . 13
1.3 Machines and contexts . . . 25
1.4 Machines and contexts Relationships . . . 25
1.5 Examples of Correct Visibilities . . . 26
1.6 context structure . . . 26
1.7 Context Example . . . 27
1.8 Machine Example . . . 28
1.9 Machines and Context . . . 29
1.10 Algorithmic Refinement . . . 29
1.11 Proof Obligation Generator . . . 30
2.1 RM-ODP Foundation Object Model . . . 42
2.2 Information concepts . . . 43
2.3 Semantic Domain . . . 45
3.1 client system- server system interactions and data base management . . 56
3.2 RM-ODP Foundation and DBMS concepts . . . 58
3.3 DBMS Semantic Domains . . . 60
3.4 Organization of the DBMS objects . . . 61
3.5 An example of a basic system client / system server channel . . . 61
4.1 Dynamic Distributed databases model . . . 65
4.2 DDB Information concepts . . . 67
4.3 Semantic Domain . . . 68
4.4 Activity Diagram for the DDB Process . . . 70
ix
5.2 Core Behavior Concepts . . . 79
5.3 table1 . . . 80
5.4 A UML class used to model a Behavior BPEL Process . . . 81
5.5 An Activity Diagram for the Behavior Process . . . 81
5.6 UML to BPEL mapping overview . . . 82
5.7 schema1 . . . 83
5.8 Listing 1 Excerpt of the BPEL listing . . . 84
5.9 a process of Developing . . . 85
6.1 Core Behavior Concepts . . . 92
6.2 Sequential deterministic constraints . . . 94
6.3 RM-ODP diagram : Example constraints of concurrency . . . 95
6.4 Example Constraints example of non-determinism . . . 95
6.5 table3 . . . 97
6.6 A context of sequential constraint . . . 97
1
INTRODUCTION GÉNÉRALE
Les systèmes distribués utilisés dans les réseaux informatiques peuvent être très complexes. De ce fait, les différentes considérations qui influencent leur conception et leur design peuvent aboutir à un ensemble structuré et consistant de spécifications. Ces derniers ont besoin d’une architecture ordonnée afin qu’elles puissent être gérées et contrôlées avec succès. Le modèle de référence pour le traitement réparti ouvert RM-ODP (Reference Model for Open Distributed Processing) a pour objectif de la définir. RM-ODP doit assurer la répartition, l’interfonctionnement et la portabilité des res-sources informatiques et définit un modèle objet et une architecture. Le modèle objet définit l’ensemble des concepts objets à utiliser pour une description unifiée d’un sys-tème.
Il définit les concepts de modélisation basée objet de l’information et du traitement. L’ar-chitecture définit les points de vues, les langages de points de vue, les fonctions ODP et les transparences ODP. Le concept de point de vue permet de réduire la complexité de développement des systèmes répartis en ne s’intéressant qu’à un seul aspect particulier à la fois. Il fournit un cadre de description des architectures selon plusieurs niveaux d’abstraction.
En effet, il définit un modèle d’objet, des concepts architecturaux et une architecture pour le développement des systèmes traitement réparti ouvert ’ODP’ (Open Distributed Processing) en termes de cinq points de vue.
Cependant, RM-ODP est une méta-norme assez abstraite et ne vise pas à fournir une méthodologie concrète de conception ou de développement. De ce fait, plusieurs stan-dards ODP doivent être définis. Des méthodes de spécifications et vérifications des systèmes distribués ont été, alors, conçues pour simplifier tous ces problèmes.
Thème de recherche :
Notre thème de recherche porte sur la spécification formelle des systèmes informatiques. Aussi, de ce qui précède, on déduit qu’il s’agit de spécifier formellement un logiciel ré-parti ouvert. L’objectif de RM-ODP est de construire des systèmes réré-partis ouverts. Cependant, il ne constitue pas une méthodologie en soi.
En fait, il n’est qu’un fil banalisant l’ingénierie de systèmes répartis en environnement hétérogènes. C’est une norme qui guide le développement d’autres normes qui permet-tront à long terme de développer de tels systèmes. C’est dans le but de contribuer à résoudre cette problématique, et de rendre plus précise la sémantique formelle du mo-dèle de référence ODP que s’inscrit la présente thèse.
Cette thèse intitulée Spécification et vérification de systèmes informatiques distribués conformement au modèle de référence du traitement répartis ouvert s’inscrit dans le cadre de l’ingénierie des systèmes répartis ouverts, on a traité plusieurs problèmes qui peuvent être regroupés en trois parties.
2
1)La Sémantique formelle des langages : En se basant sur l’approche dénotationnelle de spécification de sémantique constituée de trois composants : le domaine syntaxique, le domaine sémantique et la fonction sémantique qui affecte à chaque instance du domaine syntaxique une instance, dans le but de définir la sémantique formelle de différentes catégories de concepts de différents langages de point de vue. En effet, on va a étudié les concepts de structure et de comportement du langage d’information et des concepts de comportement des langages de traitement et d’ingénierie.
2) La Transformation de modèles : Pour rendre les processus d’entreprise exécutables et contrôlables, on va traiter l’utilisation de langage BPEL pour les concepts de compor-tement dans le point de vue traicompor-tement. Par la définition de la traduction des concepts du comportement du langage de traitement avec les concepts BPEL et la présentation de la syntaxe et la sémantique et la sémantique d’un processus de comportement BPEL. Ceci lui a permis de générer les fichiers BPEL nécessaire pour implémenter le processus spécifié.
3) La Transformation des concepts de comportement du langage de traitement avec les concepts de la méthode de spécification et de vérification formelle Event B qui d’aboutir à un programme correct par construction. Ces orientations rappellent les ten-dances du traitement réparti.
Plan de mémoire et travaux réalisés :
Vue la complexité de la tâche, nous avons eu à étudier les méthodes de génie logi-ciel, et les techniques de spécification formelle actuelles. Nous en avons déduit que les orientations actuelles sont d’une part l’unification et l’intégration des méthodes de génie logiciel aussi bien que des techniques de spécification et de description formelle que l’inter-intégration de ces méthodes et techniques. Ces orientations rappellent les tendances du traitement réparti.
Dans le premier chapitre constituant l’état de l’art des travaux relatifs au sujet traité dans ce mémoire, nous présentons uniquement les concepts et principes nécessaires à la compréhension de notre propos et nous donnons des références aux sources permettant au lecteur d’approfondir ses connaissances sur le sujet. Ainsi, Dans un premier temps, nous exposons le modèle de référence pour le traitement réparti ouvert RM-ODP et ensuite nous donnons la description des spécifications du comportement en précisant les diagrammes d’activité.
Dans le chapitre 2, nous traitons la nécessité de la notation formelle des langages de point de vue ODP. Ces langages sont abstraits dans la mesure où ils définissent les concepts qui devraient être employés, mais pas la manière dont ils devraient être représentés. Nous avons adopté l’approche méta-modélisation basée UML/OCL et l’ap-proche dénotationnelle pour la spécification précise de la sémantique des langages de point de vue ODP, en particulier du langage d’information. Nous avons proposé le
méta-3
modèle de la syntaxe abstraite qui se compose aussi bien de diagrammes de classe que de contraintes OCL. Une approche très efficace pour simplifier ce problème consiste à utiliser le méta-modèle des instances des modèles en UML/OCL et la relation entre les modèles et leurs instances. Par ailleurs, afin de spécifier le comportement exécu-table d’un système et rendre les processus de traitement exécuexécu-tables et contrôlables, nous avons défini une sémantique formelle pour un sous-ensemble de concepts de com-portement ODP dans le langage de traitement (temps, comcom-portement, action, rôle et processus) en utilisant UML couplé avec le langage de contraintes OCL.
Dans le chapitre 3 et 4, récapitule les différents niveaux que nous avons effectués pour les spécifications des systèmes distribués en particulier les systèmes de gestion de bases de données (DBMS). En effet, puisque l’utilisation de DBMS dans les réseaux informa-tiques complexes augmente de plus en plus de nos jours, nous nous sommes intéressés, dans ce chapitre aux spécifications de traitement des concepts ODP par l’utilisation de trois schémas (statique, dynamique, invariable) aussi bien qu’aux spécifications d’ingé-nierie et qu’à la structure de DMBS en décrivant essentiellement des modèles objets du système de gestion de bases de données.
Dans le chapitre 5, nous proposons une méthodologie de modélisation de
comporte-ment du langage de traitecomporte-ment ODP à travers la création d’un profil UML spécifique au comportement. Ce profil sera traduit au langage BPEL en faisant une correspondance entre les concepts du comportement du langage de traitement et les concepts du langage BPEL. Cette transformation, orientée MDA, va être assurée par l’utilisation de l’outil Rational/Rose. Finalement, nous concluons ce travail en récapitulant les résultats obte-nus et en évoquant différentes possibilités de continuation et d’extension de ces travaux. Enfin, Dans le chapitre 6, nous décrivons la spécification du comportement exécutable d’un système et le moyen de rendre les processus de traitement exécutables et contrô-lables. Nous nous concentrons principalement sur le temps, l’action, les contraintes de comportement (Séquentielle contraintes de non déterminisme et de simultanéité), et les politiques (permission, autorisation, interdiction). Nous donnons également une trans-formation des concepts considérés vers le concept de méthode B. celui-ci consiste à appliquer une technique de modélisation au développement de logiciels par l’associa-tion à des mécanismes de preuve. Cette transformal’associa-tion permettra la vérifical’associa-tion des spécifications décrites. En guise de conclusion, nous présentons des spécifications de traitement et d’ingénierie du système de gestion de bases de données et nous établis-sons la correspondance entre les modèles et leurs instances. Ceci présente la forme de base de notre approche sémantique dénotationnelle.
Chapitre 1
LITERATURE SURVEY
1.1
RM-ODP
RM-ODP is a framework for the construction of open distributed systems. It defines a generic object model in foundations part, It also defines an architecture which contains specifications of the required characteristics that qualify distributed processing as open. The architecture extends and Specializes object concepts of foundations part. The RM-ODP architecture model consists of a set of five viewpoint models, the concepts and rules associated with the language of each model, the distribution transparency constructs, and the ODP functions. The entire RM-ODP model is based on the RM-ODP foun-dations of an object model, rules for specification, and rules for structuring RM-ODP (Model Reference - Open Distributed Processing) [1] [2] [3] is an international stan-dard published by ISO/IEC. It provides a reference model for the specification of open distributed applications. The RM-ODP model can describe a system according to five viewpoints ; each viewpoint is interested in a particular aspect of the system.
The Reference Model of Open Distributed Processing is based on precise concepts derived from current distributed processing developments and, as far as possible, on the use of formal description techniques for specification of the architecture.
RM-ODP Standards
RM-ODP consists of four basic ITU-T Recommendations and ISO/IEC International Standards :
•Overview (ISO/IEC 10746-1 ITU-T Rec. X.901) [1] : Contains a motivational overview of ODP, giving scoping, justification and explanation of key concepts, and an outline of the ODP architecture. It contains explanatory material on how the RM-ODP is to be interpreted and applied by its users, who may include standard writers and architects
1.1.1 RM-ODP Viewpoints And Specifications 5
of ODP systems.
•Foundations (ISO/IEC 10746-2 ITU-T Rec. X.902) [2] : Contains the definition of the concepts and analytical framework for normalized description of (arbitrary) distributed processing systems. It introduces the principles of conformance to ODP standards and the way in which they are applied. In only 18 pages, this standard sets the basics of the whole model in a clear, precise and concise way.
•Architecture (ISO/IEC 10746-3 ITU-T Rec. X.903) [3] : Contains the specification of the required characteristics that qualify distributed processing as open. These are the constraints to which ODP standards must conform with. This recommendation also defines RM-ODP viewpoints, subdivisions of the specification of a whole system, establi-shed to bring together those particular pieces of information relevant to some particular area of concern.
•Architectural Semantics (ISO/IEC 10746-4 ITU-T Rec. X.904) [4] : Contains a for-malization of the ODP modeling concepts by interpreting each concept in terms of the constructs of the different standardized formal description techniques.
In the same series as the RM-ODP are a number of other standards and recommen-dations for the specification and development of open and distributed system, for which RM-ODP provides a standardization framework :
1.1.1 RM-ODP Viewpoints And Specifications The complete specification of any
non-trivial distributed system involves a myriard of information. Attempting to capture all aspects of the design in a single description is generally unworkable. Most design methodologies aim at establishing a co-ordinated, interlocking set of models, each aimed at capturing one facet of the design, satisfying the requirements which are the concern of some particular groups involved in the design process.
In ODP, this separation of concerns is established by identifying of five viewpoints, each with an associated viewpoint language which expresses concepts and rules relevant to a particular area of concern in terms of which of a system can be described from that viewpoint. These five viewpoints are :
- Enterprise Viewpoint : It is directed to the needs of the users of an information system. It describes the (distributed) system in terms of answering what it is required to do for the enterprise or business. It is the most abstract of the ODP framework of viewpoints stating high level enterprise requirements and policies.
1.1.1 RM-ODP Viewpoints And Specifications 6
Figure 1.1 – RM-ODP viewpoints and specifications
- Information Viewpoint : It focuses on the information content of the enterprise. The information modelling activity involves identifying information elements of the system, manipulations that may be performed on information elements, and the information flows in the system.
- Computational Viewpoint : It deals with the logical partitioning of the distributed applications independent of any specific distributed environment on which they run. It hides from the application designer the details of the underlying machine (distributed platform) that supports the application [5-6].
- Engineering Viewpoint : It addresses the issues of system support for distributed applications. It also identifies the functionality of the distributed platform required for the support of the computational model.
- Technological Viewpoint : The technology model identifies possible technical arte-facts for the engineering mechanisms, computational structures, information structures, and enterprise structures.
1.1.1 RM-ODP Viewpoints And Specifications 7
The viewpoints should be considered as projections on to certain sets of concerns rather than layers or design methods.
The set of viewpoints are chosen to be both simple and complete and covers all the domains of architectural design needed.
An enterprise specification of an ODP system is a model of the system and the environment with which the system interacts. Moreover, it covers the roles as well as of the system in the business, and the human user roles and business policies related to the system.
An information specification of an ODP system is a model of the information that it holds and of the information processing that it carries out. Note, Moreover, that the information model is extracted from the individual components and provides a consistent common view which can be referred to by the specifications of information sources and sinks, and the information flows between them.
The information specification comprises a set of related schemata, namely, the inva-riant, static and dynamic one :
•An invariant schema models relationships between information objects which must always be true, for all valid behavior of the system.
•A static schema models assertions which must be true at a single point in time. A common use of static schemata is to specify the initial state of an information object.
•A dynamic schema specifies how the information can evolve as the system operates. A computational specification of an ODP system is a model of the system in terms of the individual, logical components which are sources and sinks of information. Using the computational language, computational specifications can express the requirements of the full range of distributed systems, providing the maximum potential and interwor-king and enabling the definition of constraints on distribution, while not specifying the detailed mechanisms involved.
The heart of the computational specification is the computational object model which constrains the computational specification by defining :
The form of interface an object can have ; the way that interfaces can be bound and the forms of interaction that can take place at them ; the actions an object can perform,
1.1.1 RM-ODP Viewpoints And Specifications 8
in particular the creation of new objects and interfaces, and finally the establishment of bindings.
An engineering specification of an ODP system defines a networked computing in-frastructure that supports the system structure defined in the computational specification and provides the distribution transparencies that it identifies. It describes mechanisms corresponding to the elements of the programming model, effectively defining an abstract machine which can carry out the computational actions, and the provision of the various transparencies needed to support distribution.
A technology specification defines how a system is structured in terms of hardware and software components.
The viewpoints are not independent. Specifications of a system from each viewpoint are partial views of the complete system and there are consistent constraints between the different viewpoint specifications that arise from the relationships between the real word entities represented in the different specifications and from the fact that the same entities may be represented in more than one specification.
RM-ODP Common Functions
Furthermore, the model is composed of a set of functions being called the ODP functions. They are among 24, organized in four categories which participate in the simplification of the description of the model of architecture :
In addition to these structuring approaches, RM-ODP gives outline definitions of a number of common functions. Those functions [7, 8] provide a set of common services that are either fundamental or widely applicable to the construction of ODP systems. Detai-led specifications for those functions are the subject of separate and specific standards. The functions are organized into four categories that can be stated as the following : 1)Management functions : node management function ; object management function ; cluster management function ; capsule management function.
2)Coordination functions : event notification function ; check pointing and recovery function ; deactivation and reactivation function ; group function ; replication function ; migration function ; engineering interface reference tracking function ; transaction func-tion.
1.1.1 RM-ODP Viewpoints And Specifications 9
3)Repository functions : storage function ; information organization function ; reloca-tion funcreloca-tion ; type repository funcreloca-tion ; trading funcreloca-tion.
4)Security functions : access control function ; security audit function ; authentica-tion funcauthentica-tion ; integrity funcauthentica-tion ; confidentiality funcauthentica-tion ; non-repudiaauthentica-tion funcauthentica-tion ; key management function.
Those forming an integral part of the computational language and integral part of the engineering language, most of them are either introduced by the engineering language to provide the support needed for its structures.
Distribution Transparencies
Transparencies arise from the fact that, when contemplating a distributed system, a number of concerns become apparent which is a direct result of the distribution : the system components are heterogeneous, they can fail independently, and they are at different and, possibly, varying locations, and so on. These concerns can either be solved directly as part of the application design, or standard solutions can be selected, based on best practice. If standard mechanisms are chosen, the application designer works in a world which is transparent to that particular concern ; the standard mechanism is said to provide a distribution transparency.
RM-ODP defines several distribution transparencies [9] : -The access transparency masks differences in data representation and invocation mechanisms to enable interwor-king between heterogeneous objects.
-The failure transparency masks from an object the failure and possible recovery of other objects (or itself) to enable fault tolerance.
-The location, migration and relocation transparencies allow the search and invoca-tion of services independently from their locainvoca-tion, and from any relocainvoca-tion or migrainvoca-tion of the calling or called objects.
-The replication transparency masks the use of a group of compatible server objects to support an interface, whereas the persistence transparency permits the state of objects to be saved and restored.
-Finally, the transaction transparency masks coordination of activities amongst a configuration of objects to achieve consistency.
1.1.2 Formalization And Categorization Of Specification Of Concepts 10
The system designer can choose which ones to use, since each one may or may not be relevant to a particular application, and each one conveys a cost (in time and resources). RM-ODP does not force the designer to select them all, but in case one is incorporated, it should conform to the model.
1.1.2 Formalization And Categorization Of Specification Of Concepts Specification
concepts introduce the means to be used by a modeler for modeling. Basic concepts interpretation represent any modeling activity identifies :
a) Elements of the universe of discourse ; b) One or more pertinent levels of abstraction.
Basic linguistic concepts : The following concepts provide a common framework for relating the syntax of any language used for the ODP Architecture to the interpretation concepts.
Basic modeling concepts : In many specification languages, the environment can be considered to include at least one object which is able to participate without constraint in all possible interactions, representing the process of observation.
Environment (of an object) : the part of the model which is not part of that object.
Action : Something which happens.
Interface : An abstraction of the behavior of an object that consists of a subset of the
interactions of that object together with a set of constraints when they may occur.
Activity : A single-headed directed acyclic graph of actions, where occurrence of each
action in the graph is made possible by the occurrence of all immediately preceding actions.
Behavior (of an object) : A collection of actions with a set of constraints on when they may occur.
State (of an object) : At a given instant in time, the condition of an object that determines the set of all sequences of actions in which the object can take part.
Communication : The conveyance of information between two or more objects as a result of one or more interactions, possibly involving some intermediate objects.
1.1.2 Formalization And Categorization Of Specification Of Concepts 11
Location in space : An interval of arbitrary size in space at which an action can occur. Location in time : An interval of arbitrary size in time at which an action can occur. Interaction point : A location at where there is a set of interfaces.
In this regards, we find the concepts like “type”, “class”, “interface signature”, “pre-condition”, “post condition are examples of the concepts
Concepts of specifications
Composition :
- (of objects) A combination of two or more objects yielding a new object, at a different level of abstraction.
- (of behaviours) A combination of two or more behaviours yielding a new behaviour. The characteristics of the resulting behaviour are determined by the behaviours being combined and the way they are combined.
Examples of combination techniques are sequential composition, concurrent composi-tion, interleaving, choice, and hiding or concealment of actions. These general definitions will always be used in a particular sense, identifying a particular means of combination. In some cases, the composition of behaviours may yield a degenerate behaviour, e.g. deadlock, due to the constraints on the original behaviours.
Decomposition :
a) (of an object) The specification of a given object as a composition. b) (of a behaviour) The specification of a given behaviour as a composition.
For example, type of type , composition of templates , or class of composite object is valid complex specification concepts :
UML/OCL For Modeling In RM-ODP
1.1.2 Formalization And Categorization Of Specification Of Concepts 12
We use the Unified Modeling Language (UML) [7] to specify, visualize, modify, construct and document the artifacts of an object-oriented software intensive system under development. UML offers a standard way to visualize a system’s architectural, including elements such as : actors, business processes, logical components, activities, programming language statements and database schemas.
It is very important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphical representation of a system’s model.
the Infrastructure that defines the core meta-model on which the Superstructure is based. The Object Constraint Language (OCL) for defining rules for model elements ; and the UML Diagram Interchange that defines how UML diagram layouts are exchanged.
UML diagrams represent two different views of a system model.
Static (or structural) view : It emphasizes on the static structure of the system using objects, attributes, operations and relationships. The structural view also includes class diagrams and composite structure diagrams.
Dynamic (or behavioral) view : It emphasizes on the dynamic behaviour of the system by showing collaborations among objects and changes to the internal states of objects. In addition, this view includes sequence diagrams, activity diagrams and state machine diagrams.
The class diagram describes the structure of a system by showing the system’s classes, their attributes, and the relationships among the classes. Besides, and Beha-vior diagrams emphasize on what must happen in the system being modeled. However, interaction diagrams, a subset of behavior diagrams, emphasize on the flow of control and data among the things in the system being modeled.
A profile in the Unified Modeling Language (UML) provides a generic extension mechanism for customizing UML models for particular domains and platforms. Extension mechanisms allow refining standard semantics in strictly additive manner, so that they can’t contradict standard semantics.
Object Constraint Language
The Object Constraint Language (OCL) [10] is a declarative language for describing rules that can be applied on Unified Modeling Language (UML). Initially, OCL was only a formal specification language extension to UML. OCL may now be used with any
1.2 Denotational Semantics 13
Figure 1.2 – Behavior diagram and Structure diagram
Meta-Object Facility (MOF) Object Management Group (OMG) meta-model, including UML the Object Constraint Language is a precise text language that provides constraint and object query expressions on any MOF model or meta-model that cannot otherwise be expressed by diagrammatic notation, OCL is a key.
We use OCL to give supplements for UML specifications by providing expressions that have neither the ambiguities of natural language nor the inherent difficulty of using complex mathematics. Because OCL makes a Meta-Object Facility model more precise by associating assertions with its meta-elements.
OCL is a typified language so that each expression OCL has a type, Consequently, each expression must this conform to the typological rules of conformance with an aim that it is well-formed.
1.2
Denotational Semantics
With formal semantics we give programs meaning by mapping them into some abstract but precise domain of objects. Using denotational semantics, we provide meaning in terms
1.2 Denotational Semantics 14
of mathematical objects, such as integers, truth values, tuples of values, and functions. [11] [12] for this reason, denotational semantics was originally called mathematical semantics.
Concepts and examples
Denotational semantics is based on the recognition that programs and the objects they manipulate are symbolic realizations of abstract mathematical objects, for example,
strings of digits realize numbers, and
function subprograms realize mathematical functions.
The idea of denotational semantics is to associate an appropriate mathematical ob-ject, such as a number, a tuple, or a function, with each phrase of the language. The phrase is said to denote the mathematical object, and the object is called the denotation of the phrase.
Syntactically, a phrase in a programming language is defined in terms of its consti-tuent parts by specification. The decomposition of language phrases into their subphrases is reflected in the abstract syntax of the programming language as well. A fundamental principle of denotational semantics is that the definition be compositional. [13, 14]That means the denotation of a language construct is defined in terms of the denotations of its subphrases.
Traditionally, denotational definitions use special brackets, the emphatic ones bra-ckets [ ], to separate the syntactic world from the semantic world. If p is a syntactic phrase in a programming language, then a denotational specification of the language will define a mapping meaning, so that meaning [p] is the denotation of p namely, an abstract mathematical entity that models the semantics of p.
For example, the expressions “2*4”, “(5+3)”, “008”, and “8 are syntactic phrases that all denote the same abstract object, namely the integer 8. Therefore with a denotational definition of expressions we should be able to show that
meaning [2*4] = meaning [(5+3)] = meaning [008] = meaning [8] = 8.
Functions play a prominent role in denotational semantics, modeling the bindings in stores and environments as well as control abstractions in programming languages. For example, the “program”
1.2.1 The Syntactic World 15
fact(n) = if n=0 then 1 else n* fact (n–1)
denotes the factorial function, a mathematical object that can be viewed as the set of ordered pairs,
{< 0, 1 >,<1, 1 >,< 2, 2 >,< 3, 6 >,<4, 24 >,< 5, 120 >,<6, 720 >, ...}, and a denotational semantics should confirm this relationship.
A denotational specification of a programming language consists of five components, two specifying the syntactic world, one describing the semantic domains, and remaining two defining the functions that map the syntactic objects to the semantic objects.
1.2.1 The Syntactic World Syntactic categories or syntactic domains name collections
of syntactic objects that may occur in phrases in the definition of the syntax of the language for example, [15]
Numeral, Command, and Expression.
Commonly, each syntactic domain has a special metavariable associated with it to stand for elements in the domain for example,
C : Command E : Expression N : Numeral I : Identifier
With this traditional notation, the colon means “element of”. Subscripts will be used to provide additional instances of the metavariables.
1.2.2 The Semantic World Semantic domains are “sets of mathematical objects of
a particular form. The sets serving as domains have a lattice. For now we view these semantic domains as normal mathematical sets and structures for example,
Boolean = {true, false} is the set of truth values,
1.2.3 The Connection Between Syntax And Semantics 16
Store = (Variable →Integer) consists of sets of bindings (functions mapping variable names to values).
We use the notation A → B to denote the set of functions with domain A and codomain B.
1.2.3 The Connection Between Syntax And Semantics Semantic functions map
ob-jects of the syntactic world into obob-jects in the semantic world. Constructs of the subject language namely elements of the syntactic domains are mapped into the semantic do-mains. These functions are specified by giving their syntax (domain and codomain), called their signatures. For instance,
Meaning : Program * Store
Evaluate : Expression * (Store * Value)
and by using semantic equations to specify how the functions act on each pattern in the syntactic definition of the language phrases. For example,
Evaluate [E1 + E2] sto = plus (evaluate [E1] sto, evaluate [E2] sto)
states that the value of an expression E1 + E2 is the mathematical sum of the values of its component subexpressions. Note that the value of an expression will depend on the current bindings in the store, here represented by the variable “sto”. The function evaluate maps syntactic expressions to semantic values namely, integers using mathe-matical operations such as plus We need two syntactic domains for the language of numerals. Phrases in this language are mapped into the mathematical domain of natural numbers. Generally we have one semantic function for each syntactic domain and one semantic equation for each production in the abstract syntax. To distinguish numerals (syntax) from numbers (semantics), different typefaces are employed. Note the composi-tionality of the definition in that the value of a phrase ’N D is defined in terms of the value of N and the value of D.
Compositionality
The principle of compositionality has a long history in mathematics and the speci-fication of languages. On the semantics of programming languages,[16] there are three reasons for using compositional definitions :
1.3 Formal Method 17
describes its contribution to the meaning of a complete program that contains it. Fur-thermore, the meaning of each phrase is formulated as a function of the denotations of its immediate subphrases. As a result, whenever two phrases have the same denotation, one can be replaced by the other without changing the meaning of the program. Therefore a denotational semantics supports the substitution of semantically equivalent phrases.
2.Since a denotational definition parallels the syntactic structure of its BNF speci-fication, properties of constructs in the language can be verified by structural induction. 3.Compositionality lends certain elegance to denotational definitions, since the se-mantic equations are structured by the syntax of the language. Moreover, this structure allows the individual language constructs to be analyzed and evaluated in relative iso-lation from other features in the language.
As a consequence of compositionality, the semantic function value is a homomorphism, which means that the function respects operations.
As an illustration, consider a function H : A → B where A has a binary operation f : AxA → A and B has a binary operation g : B ×B → B.
The function H is a homomorphism if H(f(x, y)) =g(H(x), H(y)) for all x, y ∈ A.
Development of Denotational Semantics
Denotational semantics provided the denotation (meaning) of a computer program as a function that mapped input into output. To give denotations to recursively defined programs, Scott proposed working with continuous functions between domains, specifi-cally complete partial orders. As described below, work has continued in investigating appropriate denotational semantics for aspects of programming languages [17] such as sequentiality, concurrency, non-determinism and local state.
1.3
Formal Method
The term "formal method" leads nowadays to a great confusion because its usage has been enlarged to many different activities. some typical questions we can ask about methods are the following : why use formal methods ? What are they used for ? When do we need to use such methods ? Is UML a formal method ? Are they needed in object
1.3 Formal Method 18
oriented programming ? How can we define method ?
I will answer these questions gradually. Formal methods have to be used by people who have recognized that the (internal) program development process they use is inade-quate. There may be several reasons for such inadequacies : e.g. failure, cost, risk.
The choice of a formal method is not an easy one. Partly because there are many formal method vendors. More precisely, the adjective "formal" does not mean anything. Here are some questions you may ask to a formal Methods vendor. Is there any kind of refinement mechanism associated with your formal method ? What is your way of reasoning with your formal method ? Do you prove anything when using your formal method ?
Using formal method recognizes some real difficulties, which are the following : 1. When using formal methods, you have to think a lot before coding, which is not, as we know, the current practice.
2. The usage of formal methods has to be incorporated within a certain development process, and this incorporation is not easy.
3. Model building is not a simple activity : One has to be careful not to confuse modeling and programming.
4. Modeling has to be accompanied by reasoning. In other words, the model of a program is not just a piece of text, whatever the formalism being used. It also contains proofs that are related to this text.
5. Finally, one important difficulty encountered in modeling is the very frequent lack of good requirement documents associated with the programming job we have to perform. Most of the time, the requirement document which can be found in industry are either almost inexistent or far too verbose.
Blue-prints
The people in charge of the development of large and complex computer systems should adopt a point of view shared by all mature engineering disciplines, namely that of using an artifact to reason about their future system during its construction. In these disciplines, people use blue-prints in the wider sense of the term, which allows them to reason formally during the very construction process.
1.3.1 Structuring The Requirement Document 19
It is possible to use a number of "blue-print techniques which we are going to review now. While blue-printing, one is using a number of pre-defined conventions, which helps reasoning but also allows sharing blue-prints among large communities.
Blue-print are usually organized as sequences of more and more accurate versions where each more recent version is adding details which could not be visible in previous ones.
Most of the time, in engineering discipline of software construction, people do not use such blueprinting artifacts. This results in a very heavy testing phase on the final product, which is well known to happen quite often too late.
The Requirement Document
The blue-print we have quickly described in the previous section is not however the initial phase of the development process. It is preceded by a very important one which consists of writing a, so-called, requirement document [18].
First, we are going to recall what is the place of this activity, namely that of the requirement document writing, within the life cycle of a program development. Here is a rough list of the various phases of the life cycle : system analysis, requirement document, technical specification, design, implementation, tests, and maintenance.
The requirement document phase clearly states what the functions and constraints of the system are. It is mostly written in natural language. The technical specification contains the structured formalization of the previous document using some modeling techniques. The design phase develops the previous one by taking and justifying tire decisions which implement the previous specification and also defines the architecture of the future system. The implementation phase contains the translation of the outcome of the previous phase into hardware and software components. The test phase consists of the experimental verifications of the final system.
Requirement Document Writing a good requirement document is a difficult task. The readers of such a document are the people who are conducting the next phases, namely technical specification and design. It is usually very difficult for them to exploit the requirement document because they cannot clearly identify what they have to take into account and in which order.
1.3.1 Structuring The Requirement Document The labels of the requirement
1.3.1 Structuring The Requirement Document 20
are the following : [19] [20]
FUN : for functional requirements, ENV : for environment requirements, SAF : for safety properties,
DEG : for degraded mode requirements, DEL : for requirements concerned with delays, etc.
Most of the time, the requirement fragments are made of short statements. Definition of the Term “Formal Method
Formal methods are techniques used to build blue-prints adapted to our discipline. Such blue-prints are called formal models [21].
As for real blue-prints, we shall use some pre-defined conventions to write our models. There is no point in inventing a new language : we are going to use the language of classical logic and set theory.
Complex Systems
To begin with, here are the kind of questions we might ask to begin with. What is common among, say, an electronic circuit, a file transfer protocol, an airline seat booking system, a sorting program, a PC operating system, a network routing program, a nuclear plant control system, a Smart Card electronic purse, a launch vehicle flight controller, etc. ? Does there exist any kind of unified approach to in depth study and formally prove the requirements, the specification, the design and the implementation of systems that are so different in size and purpose ?
We shall only give for the moment a very general answer. Almost all such systems are complex in that they are made of many parts interacting with a highly evolving and sometimes hostile environment. They also quite often involve several concurrent executing agents. They require a high degree of correctness.
1.3.2 Informal Overview Of Discrete Models 21
Discrete Systems
Although their behavior is certainly ultimately continuous, the systems listed in the previous section operate most of the time operating in a discrete fashion. This means that their behavior can be faithfully abstracted by a succession of steady states intermixed with jumps which cause sudden state changes. Of course, the number of such possible changes is enormous, and they are occurring in a concurrent fashion at an unthinkable frequency. But this number and this high frequency do not change the very nature of the problem : such systems are intrinsically discrete.
The technology we consider is concerned with the construction of complex discrete systems. As long as the main validation method used is testing, we consider that this technology will remain in an underdeveloped state. Testing does not involve any kind of sophisticated reasoning. It rather consists of always postponing any serious thinking during the specification and design phase. The construction of the system will always be re-shaped and re-shaped according to the testing results.
In conclusion, testing always gives a short sighted operational view of the system under construction :
The purpose of this study is to incorporate such a “blue print approach in the design of complex discrete systems. It also aims at presenting a theory which is able to facilitate the elaboration of some proved reasoning on such blue prints. Such reasoning will thus take place far before the final construction. In the present context, the “blue prints are called discrete models. We shall now give a brief informal overview of the notion of discrete models,
1.3.2 Informal Overview Of Discrete Models In this section, we give an informal description of discrete models. A discrete model is made of a state and a number of transitions.
We then give an operational interpretation of discrete models. We then present the kind of formal reasoning we want to express. Finally, we shortly address the problem of mastering the complexity of models by means of three concepts : refinement, decompo-sition, and generic development.
State and Transitions
a discrete model is made of a state represented by some constants and variables at a certain level of abstraction with regards to the real system under study. Such variables
1.3.3 Managing The Complexity Of Closed Models 22
are very much the same as those used in applied sciences (physics, biology, operational research) for studying natural systems.
Besides the state, the model also contains a number of transitions that can occur under certain circumstances. Such transitions are called here “events”, each event is first made of a guard, which is a predicate built on the state constants and variables. It represents the necessary conditions for the event to occur. Each event is also made of an action, which describes the way certain state variables are modified as a consequence of the event occurrence.
Operational Interpretation
As can be seen, a discrete dynamical model thus indeed constitutes a kind of state transition machine. We can give such a machine an extremely simple operational In-terpretation. Notice that such an interpretation should not be considered as providing any operational semantics to our models ; First of all, the execution of an event, which describes a certain observable transition of the state variables, is considered to take no time. As an immediate consequence, no two events can occur simultaneously.
The execution is then the following :
-When no event guards are true, then the model execution stops : it is said to have deadlocked.
-When some event guards are true, then one of the corresponding events necessarily occurs and the state is modified accordingly, subsequently the guards are checked again, and so on.
This behavior clearly shows some possible non-determinism as several guards may be true simultaneously.
The very elementary transition machine we have described in previous, although primitive, is nevertheless sufficiently elaborate to allow us to undertake some interesting formal reasoning.
1.3.3 Managing The Complexity Of Closed Models Note that the models we are going to construct will not just describe the control part of our intended system. It they will also contain a certain representation of the environment within which the system we build is supposed to behave. In fact, we shall quite often essentially construct closed models which are able to exhibit the actions and reactions taking place between a certain
1.3.3 Managing The Complexity Of Closed Models 23
environment and a corresponding, possibly distributed, controller.
In doing so, we shall be able to insert the model of the controller within an abstraction of its environment, which is formalized as yet another model. The state of such a closed system thus contains physical variables, describing the environment state, as well as logical variables, describing the controller state. And, in the same way, the transitions will fall into two groups : those concerned with the environment and those concerned with the controller. We shall also have to put into the model the way these two entities communicate.
But as we mentioned earlier, the number of transitions in the real systems under study is certainly enormous. And, needless to say, the number of variables describing the state of such systems is also extremely large. How are we going to practically manage such a complexity ? The answer to this question lies in three concepts : refinement, decomposition, and generic instantiation. [22] [23] [24]It is important to notice hero that these concepts are linked together As a matter of fact, one refines a model to later decompose it, and, more importantly, one decomposes it to further refine it more freely. And finally, a generic model development can be later instantiated, thus saving the user of redoing similar proofs.
Refinement
Refinement allows us to build a model gradually by making it more and more precise, that is closer to the reality. In other words, we are not going to build a single model representing once and for all our reality in a flat manner : this is clearly impossible due to the size of the state and the number of its transitions. It would also make the resulting model very difficult to master, if not just to read. We are rather going to construct an ordered sequence of embedded models, where each of them is supposed to be a refinement of the one preceding it in that sequence. This means that axe refined, more concrete, model will have more variables than its abstraction : such new variables are visible consequence of a look at our system from closer range.
Refinement is used in order to modify the state so that it can be implemented on a computer by means of some programming language. This second usage of refinement is called data-refinement. It is used as a second technique, once all important properties have been modeled.
Decomposition
1.3.4 The Structure Of The Event-B Notation 24
more and more refined, the number of its state variables and that of its transitions may augment in such a way that it becomes impossible to manage them as a whole. At this point, it is necessary to cut our single refined model into several almost independent pieces.
Decomposition is precisely the process by which a single model can be split into various component models in a systematic fashion [26]. Reduce the complexity of the whole by studying, and thus refining, each component model independently of the others. The very definition of such decomposition implies that independent refinements of the component models could always be put together again to form a single model that is guaranteed to be a refinement of the original one.
Generic Development
Any model development done by applying refinement and decomposition, is parame-terized by some carrier sets and constants defined by means of a number of properties. Such a generic model may be instantiated within another development in the same way as a mathematical theory like, say, group theory, can be instantiated in a more specific mathematical theory. This can be done providing that one has been able to prove that the axioms of the abstract theory are mere theorems in the second one. The interest of this approach of generic instantiation is that it saves us redoing the proofs already done in the abstract development.
The Event-B Modeling Notation and Proof Obligation Rules
Event-B is a tool-supported formal method based around AMN (Abstract Machine Notation), used in the development of computer software. It was originally developed by Jean-Raymond Abrial. IT related to the Z [7-8] notation and supports development of programming language code from specifications.
1.3.4 The Structure Of The Event-B Notation The primary concept in doing formal
developments in Event-B is that of a model. A model contains the complete mathematical development of a Discrete Transition System. It is made of several components of two kinds Machines and Contexts. Machines contain the dynamic parts of a model, namely variables, invariants theorems and events, whereas contexts contain the static parts of a model, namely carrier sets, constants, axioms, and theorems.
A model can contain contexts only, or machines only, or both. In the first case, the model represents a pure mathematical structure with sets, constants, axioms, and
1.3.4 The Structure Of The Event-B Notation 25
Figure 1.3 – Machines and contexts
theorem. In the third case, the model is parameterized by the contexts. Finally, the second case represents a model which is not parameterized.
Machines and Contexts have various relationships
A machine can be "refined" by another one ; and context can be "extended" by another one, Moreover, a machine can "see" one or several contexts. Machines and Contexts relationships are illustrated in figure 1.3 .
•A machine can see several contexts (or no context at all). •A context may extend several contexts (or no context at all).
Figure 1.4 – Machines and contexts Relationships
1.3.4 The Structure Of The Event-B Notation 26
•A machine only sees a context either explicitly or implicitly. •A machine only refines at most one other machine.
•No cycle in the "refines" or "extends" relationships. Machines see contexts and
Figure 1.5 – Examples of Correct Visibilities
Contexts can be extended and Machines can be refined. Context Structure The most general context structure is the one shown here.
Figure 1.6 – context structure This example of context represents
A set D is defined in context ctx_0, Moreover, three constants, n, f, and v, are defined
1.3.4 The Structure Of The Event-B Notation 27
Figure 1.7 – Context Example
.. n to the set D (axm2), v is supposed to belong to the range of f (axm3). A theorem is proposed : n is a positive number (thm1).
1.3.4 The Structure Of The Event-B Notation 28
MachineStructure
The most general machine structure is shown here
Figure 1.8 – Machine Example
Each machine has exactly one initialization event
- All labels are generated automatically by the Rodin Platform (but can be modified) Let us now describe the contents of each clause in Machine Structure.
- "variables" lists the state variables of the machine
- "invariants" states the properties of the variables and are defined in terms the seen sets and constants.
- "theorems" are provable from invariants and seen axioms and thms. - "events" defines the dynamics of the transition system.
- "variant" is : The variant of a machine is either a natural number expression or a finite set expression and it has to be present in any machine with convergent events.
Machine m_0 a sees the previously defined context ctx_0
The event-B prescribes how to check the specification for consistency (preservation of invariant) and how to check designs and implementations for correctness (correctness of data refinement and correctness of algorithmic refinement).
1.3.5 Verification Of The Specification 29
Figure 1.9 – Machines and Context
Figure 1.10 – Algorithmic Refinement
1.3.5 Verification Of The Specification The machine shall initiate in a valid state and
the initialization shall establish the invariant and the operations of the machine shall not take it into an invalid state, assuming that their pre-conditions are respected :
The Proof obligations are automatically generated by a Rodin Platform tool called the Proof Obligation Generator [28] [29].
This tool static checks contexts or machine texts and it decides then what is to be proved after execution process the outcome is various sequents, which are transmitted to the provers performing automatic or interactive proofs.
1.3.5 Verification Of The Specification 30
Figure 1.11 – Proof Obligation Generator
Generalities on Refinement
Refinement is the name given to the process of transforming an abstract specification into a concrete implementation by reflecting a design decision and defines the concrete version of the specification variables, and initialization and operations ;
a so-called refinement relation establishes the mapping between the values of concrete variables and abstract variables ;
The concrete operations shall preserve the interface and observable behaviour of the abstract operations.
The different kinds of refinement correspond to the different kinds of design decisions : Data refinement provides a more concrete vision of how a variable (or a set of va-riables) can be modeled ;
Operation refinements provide indications of how operations are to be computed by algorithms, and may also :
Allow more input values, i.e. weaken the pre-condition ;
Restrict or even remove non-determinism, i.e. strengthen the post-condition. In general, we will use the term refinement to cover either or both.
1.4 Conclusion 31
The refinement of a construct for example an event promises behavior that is consistent with the behavior of the construct being refined.
That is, in the context, the behavior offered by the refining construct could have been offered by the refined construct.
Our objectives are to take non-determinism into account and reduce non-determinism : non determinism in a construct is interpreted as a choice in which any of the outcomes are satisfactory, so the refiner can choose between those options.
Strengthening guards : individual guards of an event may be strengthened and sub-ject to the disjunction of all the guards remaining equivalent.
1.4
Conclusion
After description of the Unified Modeling Language (UML)/OCL (Object Constraints Language) we define a formal semantics for a fragment of ODP behavior concepts defined in the RM-ODP foundations part and in the Computational language. We mainly focus on time, action, behavior constraints (sequentiality, non determinism and concurrency constraints), and policies (permission, obligation, prohibition). We also give a mapping of the considered concepts to Event-B. This will permit the verification of such specifi-cations. The archive contains and explores the benefits provided by the new extension mechanisms of Event-B development for verifying the ODP computational specifications. Refinement is accomplished by mapping all of the elements of an upper level specifi-cation into lower level elements that may be split among several events. In addition, actions that can occur in the upper level are mapped to actions of events operating at the lower level. This allows several types of implementation strategies to be specified in a natural way. The methodology consists of a development process, containing a set of activities that result in a set of specifications. These specifications are described in terms of UML diagrams, prose text, sketches and code.
The methodology of conception process encourages iterative development, by allowing the various modelling activities to provide input to each other. Four major complementary activities are defined, which are refined into finer grained activities. Enterprise modelling covers the enterprise specifications requirements and goals, Enterprise organisation, En-terprise processes and enEn-terprise distribution. It is related to the enEn-terprise viewpoint. We update requirements for the systems as far as necessary, behavior processes by the activity diagrams, and generate the corresponding BPEL and computational files to
