Advertisement

Developing A New Language to Construct Algebraic Hierarchies for Event-B

  • James Snook
  • Michael Butler
  • Thai Son Hoang
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 10998)

Abstract

This paper proposes a new extension to the Event-B modelling method to facilitate the building of hierarchical mathematical libraries to ease the formal modelling of many systems. The challenges are to facilitate building mathematical theories, be compatible with the current method and tools, and to be extensible by users within the Rodin Platform supporting Event-B.

Our contribution is a new language, called B\(^\sharp \), which includes the additional features of type classes and sub-typing. The B\(^\sharp \) language compiles to the current language used by the Rodin’s Theory Plug-in, which ensures consistency, and also gives compatibility with the current Rodin tools. We demonstrate the advantages of the new language by comparative examples with the existing Theory Plug-in language.

Keywords

Formal methods Event-B Theorem prover Mathematical extensions 

1 Introduction

The Open image in new window method [1] and its supporting Rodin [2] are designed specifically for system modelling. Open image in new window incorporates mechanisms such as refinement and decomposition to cope with the system complexity. Rodin includes facilities such as animation, model checking, and theorem proving for validating and verifying the Open image in new window models. Often, during system development, in order to ensure system dependability, developers need to model the system’s operating environment. Having extensive mathematical libraries makes this modelling task faster and easier. Building these libraries of mathematical definitions and theorems is made considerably easier with the right tools and language features.

The challenges addressed in this paper are designing a language with the required features to enable the development of consistent mathematical theories, in such a way that minimises repeated proofs. Moreover, the mathematical theories can be used within the Open image in new window models.

Our contribution therefore is the design of a new language, called B\(^\sharp \), with features to aid the construction of mathematical libraries. The new features are designed to reason about abstract and concrete mathematical types. The B\(^\sharp \) language is mapped to the current Open image in new window syntax as supported by Rodin and its Theory Plug-in. The mapping phase will generate necessary theorems that required to be discharged by the developers. Other proof rules will be generated which would (normally) have required a manual proof in Open image in new window , however, the new language will generate the proof itself.

Structure. The rest of this paper is structured as follows. Section 2 examines the mathematics that we want to model, and the relationships between mathematical types. We also summarise the modelling task in Open image in new window and its Theory extension. Section 3 shows the problems with the current tools by describing a case study, and presents elements of the B\(^\sharp \) language to facilitate the construction of mathematical definitions and theorems. Section 4 discusses the related work and gives some conclusion of our work.

2 Background

2.1 Mathematical Data Structures

Within mathematics, the study of abstract algebra deals with abstract structures. Rather than dealing with specific functions and sets, they generalise to deal with all sets and functions that have given properties. For instance, the abstract structure of a monoid is a set S and a binary function f and an identity element e, such that:
$$\begin{aligned} \forall x, y, z \in S \cdot f(x, f(y, z)) = f(f(x, y), z)\text {, and} \end{aligned}$$
(1)
$$\begin{aligned} \forall x \in S \cdot f(x, e) = x \wedge f(e, x) = x. \end{aligned}$$
(2)
Property (1) declares that the function f is associative. Property (2) defines e as an identity element.

Many concrete structures are examples of this abstract type such as, addition and zero on the real numbers, or matrix multiplication with the identity matrix. Theorems and functions on the abstract type apply to all of the concrete examples, so the proof only has to be done on the abstract type.

Axioms can be added to abstract types to form new types e.g., a group is a monoid where all elements have an inverse. A group can utilise all the results from a monoid (as the group has all of the monoid’s axioms), and can have new theorems provable with the new axioms.

Reasoning like this reduces the proof burden as proofs done on the abstract type do not need to be repeated by either concrete instances, or abstract types that extend the current type. The proofs are inherited by the new types.

2.2 Event-B and the Theory Plug-In

The Open image in new window modelling method [1] allows the modelling of discrete event systems. The Open image in new window modelling language is supported by the Rodin Platform [2], an open and extensible toolset for constructing formal models. To increase the ability of Open image in new window to model systems the Theory Plug-in [5] was added to Open image in new window allowing the extension of the Open image in new window mathematical language with user-defined operators and proof rules. The Theory Plug-in can be used as a theorem prover to create domain-specific mathematical theories. In [4] a 3-D Euclidean space was modelled, and used to formally verify the safety of a set of paths of Open image in new window . The Euclidean space model would be useful to any other system requiring a safe distance is maintained. Other mathematical structures that model environment are also widely reusable e.g., two’s complement arithmetic would be useful to many software system models. The aim of creating the new language B\(^\sharp \)  is to improve the tools for building these mathematical models for Event-B.

3 A Language for Mathematical Libraries in Open image in new window

3.1 A Case Study Using Theory Plug-In

This section summarises the result of a case study evaluating the ability of the current Theory Plug-in to build and use algebraic hierarchies. The case study used the Theory Plug-in to construct abstract and concrete mathematical classes, and then see how they can be related.

On the one hand, our case study shows that abstract mathematical types were representable within in the Event-B syntax. It also found that abstract types could be extended to make new abstract types, and that concrete types could be related to the abstract types. On the other hand, the following issues with the representation were identified:
  1. 1.

    Event-B operators are not first class members of the language, resulting in the need to encapsulate them within total functions to relate concrete types to abstract types, e.g., showing addition and zero form a monoid required a theorem such as: \(zero \mapsto (\lambda x, y \vert x\ add\ y) \in Monoid(pNat)\) (the operator is encapsulated within a lambda construct).

     
  2. 2.

    Demonstrating that a concrete object forms an algebraic type does not make it inherit the theorems/proof rules of the algebraic type. These have to be re-written and proved (although the proof can be constructed by instantiating the theorems/proof rules of the algebraic type).

     
  3. 3.

    When making theorems about an abstract type the type required construction from its constituent parts, resulting in verbose theorem definitions. Alternatively the abstract types can be passed in and deconstructed with the Event-B projection operators making the theorem difficult to read/understand (this can be helped by the user making operators to deconstruct the abstract types).

     
  4. 4.

    The Event-B language is not able to reason about subsets as types, this resulted in the user having to manually do many well-definedness proofs.

     
  5. 5.

    Predicates in Event-B are not expressions. This makes it difficult to reason about relations (instead the BOOL type was used and turned back into a predicate where necessary using equality).

     
  6. 6.

    Abstract types definitions and declarations rapidly increased in complexity.

     

3.2 The B\(^\sharp \) Language

This section gives a brief introduction to the B\(^\sharp \) language, in particular focusing on the \(\mathbf {Class}\) declaration, allowing the user to create new type classes, and new subtypes, fully supported by the language. A type class allows the definition of a subtype of some existing type structure such that the subtype has additional properties and operators. A type class also allows us to constrain polymorphism. For example, the following declaration defines the ReflexRel class:
$$\begin{aligned} \begin{aligned} \mathbf {Class}&\ ReflexRel\langle T\rangle : T \times T \rightarrow Pred \\&\mathbf {where}\ \forall x : T, rel : ReflexRel\langle T\rangle \cdot rel(x, x) \{\} \end{aligned} \end{aligned}$$
(3)
This class declaration creates a type class ReflexRel a subtype of \(T \times T \rightarrow Pred\), any relation in ReflexRel must have the additional property that all elements are related to themselves.

Some differences to the Open image in new window syntax can be seen immediately. The polymorphic type T can be a subtype i.e., a type created using the subtyping mechanism above. In Open image in new window this is the equivalent of allowing entities created with the subset syntax to be treated as types. The B\(^\sharp \) language does extra work to reason about subtypes and reduce well-definedness proofs. In Event-B predicates are a different syntactic category to boolean expressions and are not first class. In B\(^\sharp \), predicates are first class of type Pred.. It allows the language to create functions that return predicates without having to use the Open image in new window type as an intermediate.

This class declaration maps to the following underlying Open image in new window statement:
$$\begin{aligned} \begin{aligned} ReflexRel(t:\mathbb {P}(T)) \hat{=}&\{ rel \vert rel \in \mathbb {P}(t \times t) \\&\wedge \forall x \cdot x \in t \Rightarrow x \mapsto x \in rel \} \end{aligned} \end{aligned}$$
(4)
To allow the ReflexRel operator to work on subtypes the Event-B power set operator \(\mathbb {P}\) is used to give the type of t. Pred is replaced by constricting the set of rel. When using rel within an expression the mapping to Event-B will become \(x\mapsto x \in rel\) when the Event-B language requires a predicate value (e.g., as in the quantifier in (4)).
The class declaration can also be used to create type classes where the type class is required to have certain elements, e.g., a monoid:
$$\begin{aligned} \begin{aligned} \mathbf {Class}&\ Monoid : Setoid (ident : Monoid, op : AssocOp\langle Monoid\rangle ) \\&\mathbf {where}\ \forall x : Monoid ~\cdot ~ op(x, ident)\ Monoid.equ\ x \\&~~\wedge ~~ op(ident, x) \ Monoid.equ \ x \{ \} \end{aligned} \end{aligned}$$
(5)
Type classes create templates for new classes. For a class to become part of the monoid type class it needs to have an identity and an associative operator that follows the rules in the \(\mathbf {where}\) clauses. Monoid : Setoid means that Monoid is a subtype of the Setoid type class, which is a type which has an equivalence relation (this is created using a class declaration similar to the one above). Definition (5) maps to the following Open image in new window :
$$\begin{aligned} \begin{array}{rl} &{} Monoid(t : \mathbb {P}(T))\ \hat{=}\ \{ setoid \mapsto ident \mapsto op \ \vert \\ &{} \quad setoid \in Setoid(t) \wedge ident \in t \ \wedge \\ &{} \quad op \in AssocOp(t, setoid) \ \wedge \\ &{} \quad \forall x \cdot x \in t \Rightarrow \\ &{} \quad \quad op(x \mapsto ident) \mapsto x \in Setoid\_equ(setoid) \ \wedge \\ &{} \quad \quad op(ident \mapsto x) \mapsto x \in Setoid\_equ(setoid)\} \end{array} \end{aligned}$$
(6)
$$\begin{aligned} Monoid\_Setoid(m : Monoid(\mathbb {P}(T))) \ \hat{=} \ prj1(m) \end{aligned}$$
(7)
$$\begin{aligned} Monoid\_ident(m : Monoid(\mathbb {P}(T))) \ \hat{=} \ prj1(prj2(m)) \end{aligned}$$
(8)
$$\begin{aligned} Monoid\_op(m : Monoid(\mathbb {P}(T))) \ \hat{=} \ prj2(prj2(m)) \end{aligned}$$
(9)
Given a instance \(a = b_1\mapsto b_2 \dots \mapsto b_n\) prj1(a) will give \(b_1\) and prj2(a) will give \(b_2 \mapsto \dots b_n\). From (6) it can be seen that the B\(^\sharp \)   syntax is much more concise. It is useful to see how a type becomes a member of the Monoid type class:
$$\begin{aligned} \mathbf {Instance}\ Monoid (zero, add); \end{aligned}$$
(10)
This will make the pNat type (inferred from the zero and add arguments) an instance of a Monoid. A proof obligation to demonstrate that addition and zero form a monoid will be generated. Proof rules, theorems and functions from the Monoid are re-written to rules about zero and addition and added to the pNat type. As these have been proved in the Monoid type class they do not need to be reproved.
Polymorphic types can be restricted to a given type class, e.g.:
$$\begin{aligned} \begin{aligned} \!\!\!\!\mathbf {Class}\ AssocOp<\!T : Setoid\!> T \times T \rightarrow T \qquad \qquad \qquad \qquad \qquad \qquad \qquad \qquad \qquad \;\\ \mathbf {where}\ \forall x, y, z : T \cdot AssocOp(AssocOp(x, y), z)\ T.eq \ AssocOp(x, AssocOp(y, z)) \end{aligned} \end{aligned}$$
(11)
The polymorphic type T has to be a member of the Setoid type class (it has to have an equivalence relation). This will map to the following Event-B:
$$\begin{aligned} \begin{aligned} AssocOp&(t : \mathbb {P(T)}, setoid : Setoid(t)) \hat{=} \{op \vert op \in t \times t \rightarrow t \\&\wedge \forall x, y, z \cdot x \in t \wedge y \in t \wedge z \in t \\&\Rightarrow op(op(x \mapsto y) \mapsto z) \mapsto op(x \mapsto op(y\mapsto z)) \in Setoid\_Eq(setoid) \end{aligned} \end{aligned}$$
(12)
The polymorphic context in (11) (\(<\!T : Setoid\!>\)) becomes the arguments to the Event-B operator in (12). \(Setoid\_Eq\) is an Event-B deconstructor created from the Setoid type class mapping, in the Event-B mapping this is mapped from the B\(^\sharp \) T.eq statement.
The syntax for a \(\mathbf {Class}\) statement is:
$$\begin{aligned} \mathbf {Class}\ \gamma \langle \tau _1:\gamma _1, \dots , \tau _n:\gamma _n\rangle : S_1 \dots S_m \ (s_1 : T_1, \dots , s_p : T_p) \ \mathbf {where}\ e_1; \dots ; e_l; \{ \} \end{aligned}$$
(13)
This declaration has the following meanings:
  1. 1.

    \(\gamma \) is the name chosen for the new class, e.g., ReflexRel in Example (3), this maps to the Event-B operator name.

     
  2. 2.

    \(\langle \tau _1:\gamma _1, \dots , \tau _n:\gamma _n\rangle \) is the polymorphic context. \(\gamma _i\) are optional, and restrict \(\tau _i\) to a given type class. These map to the arguments of the Event-B operator.

     
  3. 3.

    \(S_1 \dots S_m\) are super types and \((s_1 : T_1, \dots , s_p : T_p)\) define addition structure. In the Event-B syntax they are mapped to a statement such as \(\{ \gamma \mapsto s_1 \mapsto \dots \mapsto s_p \vert \gamma \in S_1 \wedge \ldots \wedge \gamma \in S_m \wedge s_1 \in T_1' \dots \wedge s_p \in T_p' \vert \dots \}\). With multiple inheritance any shared supertypes remain shared, the mapping for these is more complex than shown above (it requires the supertypes to be deconstructed to their last shared ancestor). This is omitted for brevity.

     
  4. 4.

    Properties \(e_1; \dots ; e_l\) are predicate expressions. These create the subtype from the supertypes. Each \(e_i\) is translated to the Event-B syntax and they constrain the set returned.

     

Due to the space limit, we omit other features of B\(^\sharp \), such as B\(^\sharp \) functions, and their mapping to Open image in new window , or the generation of proof rules from the B\(^\sharp \) class statements (to make proving easier).

4 Related Work and Conclusion

There are many examples of similar constructs in other languages. Of particular interest is Coq [3] for which there has been an extensive library of abstract algebraic structures developed [6]. The language feature which makes building this library possible is called type classes [11] originally created for Haskell. Type classes set out a structure, which types can adopt, and inherit functions from the type class. Isabelle [10] also has a similar feature allowing abstract specifications called locales [9]. Algebraic Specification [8] languages give a formal specification to datatypes rather than describing the structure of the datatype. This abstraction means that many concrete datatypes could comply with the specification, giving a similar concept to the ones described above. For example, OBJ3 [7] has a similar concepts with parameterised modules and theories. Theories define a structure for an module, parameterised types can then be restricted to models with this structure.

The novelty in the B\(^\sharp \) language is not the invention of new language features but of tailoring and applying these to the Rodin toolset, mapping the extended B\(^\sharp \) features to the Open image in new window syntax for consistency and proof purposes. The work above demonstrates a method by which this can be achieved. These new features will allow for the development of hierarchies of generic theories and the ability to develop domain-specific specialisations of these, while avoiding the need to redo proofs over similar structures for each specialisation.

References

  1. 1.
    Abrial, J.-R.: Modeling in Event-B: System and Software Engineering. Cambridge University Press, Cambridge (2010)CrossRefGoogle Scholar
  2. 2.
    Abrial, J.R., Butler, M., Hallerstede, S., Hoang, T.S., Mehta, F., Voisin, L.: Rodin: an open toolset for modelling and reasoning in Event-B. STTT 12(6), 447–466 (2010)CrossRefGoogle Scholar
  3. 3.
    Bertot, Y., Castéran, P.: Interactive Theorem Proving and Program Development - Coq’Art: The Calculus of Inductive Constructions. Texts in Theoretical Computer Science. An EATCS Series. Springer, Heidelberg (2004).  https://doi.org/10.1007/978-3-662-07964-5CrossRefzbMATHGoogle Scholar
  4. 4.
    Bogdiukiewicz, C., et al.: Formal development of policing functions for intelligent systems. In: 28th IEEE International Symposium on Software Reliability Engineering, ISSRE 2017, Toulouse, France, 23–26 October 2017, pp. 194–204. IEEE Computer Society (2017)Google Scholar
  5. 5.
    Butler, M., Maamria, I.: Practical theory extension in Event-B. In: Liu, Z., Woodcock, J., Zhu, H. (eds.) Theories of Programming and Formal Methods. LNCS, vol. 8051, pp. 67–81. Springer, Heidelberg (2013).  https://doi.org/10.1007/978-3-642-39698-4_5CrossRefGoogle Scholar
  6. 6.
    Cruz-Filipe, L., Geuvers, H., Wiedijk, F.: C-CoRN, the constructive Coq repository at Nijmegen. In: Asperti, A., Bancerek, G., Trybulec, A. (eds.) MKM 2004. LNCS, vol. 3119, pp. 88–103. Springer, Heidelberg (2004).  https://doi.org/10.1007/978-3-540-27818-4_7CrossRefGoogle Scholar
  7. 7.
    Goguen, J.A., Winkler, T., Meseguer, J., Futatsugi, K., Jouannaud, J.P.: Introducing OBJ. In: Goguen, J., Malcolm, G. (eds.) Software Engineering with OBJ. Advances in Formal Methods, pp. 3–167. Springer, Boston (2000).  https://doi.org/10.1007/978-1-4757-6541-0_1CrossRefGoogle Scholar
  8. 8.
    Guttag, J.V., Horning, J.J.: The algebraic specification of abstract data types. Acta Inform. 10(1), 27–52 (1978)MathSciNetCrossRefGoogle Scholar
  9. 9.
    Kammüller, F., Wenzel, M., Paulson, L.C.: Locales a sectioning concept for isabelle. In: Bertot, Y., Dowek, G., Théry, L., Hirschowitz, A., Paulin, C. (eds.) TPHOLs 1999. LNCS, vol. 1690, pp. 149–165. Springer, Heidelberg (1999).  https://doi.org/10.1007/3-540-48256-3_11CrossRefGoogle Scholar
  10. 10.
    Nipkow, T., Paulson, L.C., Wenzel, M.: Isabelle/HOL - A Proof Assistant for Higher-Order Logic, vol. 2283. Springer, Heidelberg (2002).  https://doi.org/10.1007/3-540-45949-9CrossRefzbMATHGoogle Scholar
  11. 11.
    Wadler, P., Blott, S.: How to make ad-hoc polymorphism less ad hoc. In: Proceedings of the 16th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pp. 60–76. ACM (1989)Google Scholar

Copyright information

© Springer Nature Switzerland AG 2018

Authors and Affiliations

  1. 1.ECS, University of SouthamptonSouthamptonUK

Personalised recommendations