Introduction to the Event-B Method

An Introduction to Event-B

• In this course we will be introducing you to the formal method known as Event-B. Event-B is a development from an earlier formal specification system, known as the B Method, itself a development from the Z specification notation.
• Event-B is one of the few formal software development methods that covers the complete software lifecycle, from requirements (specification), through design (refinement) to implementation, code generation, and maintenance.
• In this course we will be concerned only with the use of Event-B for specification.
• To assist developments in Event-B, we will be use the Rodin Toolkit, a complete life-cycle software development tool.

What do we mean by Formal Methods?

• In our use of the term Formal Methods we mean the application of mathematics to specify, design and implement software in such a way that the resulting code has been proved to be consistent with the original specification.
  • by mathematics we mean set theory and logic
  • by software we mean software systems
• In Event-B, a specification is a mathematical model of the required behaviour of a system.
• Specifications are generally abstract.
• We then transform the specification through a sequence of formally defined refinement steps towards a concrete implementation.
• During the process we have a number of proof obligations that must be discharged.

Comparison with other Engineerings

Connection with "conventional" methods

• Conventional software development methods usually express the requirements informally:
  • either structured or unstructured English,
  • or using some structured notation: dataflow, entity relationship diagrams,
  • or the unified modelling language (UML).
• Specifications are frequently expressed directly in programming code.
• Design then consists of "fleshing out" the code to produce an implementation.

Comparison with other Engineerings

Connection with "conventional" methods

• In contrast, when using a formal development method, like Event-B, the specification is an abstract description of the requirements, expressing what behaviour is required, rather than how to produce that behaviour.
• It follows the design phase must effect a radical transformation of the specification in order to obtain executable code.

Testing within traditional engineering disciplines

• Consider traditional engineering disciplines, such as electrical engineering, or civil engineering
• Designs are based on a mathematical theory of materials, components, used in the implementation of bridges, electronic circuits, etc..
• Testing consists of physical testing of the implementation, or a model of the implementation.
• Successful strategy because domains are described by continuous mathematics: if a model conforms for some specific test input, it will also conform for input that is "less than" that input. Hence we need only test for extreme values.
• This strategy would not work for discrete valued domains.

Contrast with testing of software

• Software executes over discrete domains, and testing usually consists of probing points within that space. Thus testing can only confirm conformance of behaviour at specific points. Testing is therefore incapable, in general, of demonstrating conformance over the complete application domain.
• Thus testing may confirm the presence of bugs, but not their absence.

Model Development with Event-B

• Event-B is not a programming language (not even an abstract one)!
• Event-B is a notation used for developing mathematical models of discrete transition systems
• Event-B used in conjunction with the Rodin Platform

Model Development with Event-B (2)

• Such models, once complete, can be used to construct:
  • sequential programs
  • distributed programs
  • concurrent programs
  • electronic circuits (!)
  • large systems involving possibly fragile environments
• The last statement is an important case, but ..
• .. here, demonstrate with small sequential programs

Machines and Contexts

• A model is made from several components
• A component is either a machine or a context
• Machines and contexts have names

  Machine variables invariants theorems events variant

  Context carrier sets constants axioms theorems

• Such names must be distinct in a given model

Machines and Contexts (2)

• Contexts contain the static structure of a discrete system (constants and axioms)
• Machines contain the dynamic structure of a discrete system (variables, invariants, and events)
• Machines see contexts
• Contexts can be extended
• Machines can be refined

Relationship Between Machines and Contexts

Advantages of formal development and proof

• Using a formal development method, build a model using constructs described by precise mathematical theories. These models capture the behaviour in a complete application domain.
• As we develop our specifications into implementations, the formal method produces proof obligations that describe the complete set of tests that confirm that the behaviours of the specification and the design are consistent —more correctly, not inconsistent.
• Discharging the proof obligations is thus the counterpart of testing in other engineering disciplines.
• A proof validates behaviour in a complete domain, not simply at a single point.

What has been done with formal methods?

• Formal methods have been used in various mission critical applications, for example train control systems and smart cards.
• In some countries the use of formal methods is mandatory for certain critical systems.
• The most famous and significant use of B is for the control system of the M\'et\'eor line, a new driverless train line of the Paris metro opened in October 1998.
• See
  http://www.siemens-ts.com/pagesUS/realisations/Paris.htm http://www.siemens-ts.com/pagesUS/produits/Meteor.htm

What has been done with formal methods?

• The distributed control system handled the critical parts of the central control room, the wayside equipment along the track and on the platform, the onboard train control.
• The use of B was mandated by the Paris transit authority, RATP. The M\'et\'eor system was developed by Matra Transport, now owned by Siemens.

More Industrial Pages

• The following pages on the Siemens site mention the B-Method in connection with Safety and Innovation
  \tt http://www.siemens-ts.com/pagesUS/Engagements/ \{Securite.htm,Innovation.htm\}
• The following page talks about the announcement of the award of contract to install the M\'et\'eor system on the New York subway.
  http://www.siemens-ts.com/pagesUS/realisations/NewYork.htm
• Or, see the pages at
  \footnotesize http://www.gemplus.com/smart/r\_d/trends/system\_model/b\_method/
  GEMPLUS is a company that develops smart cards.

Formality is inexorable

• The increase in the use of formality in software development has been continuous, from
  • formal grammars to specify programming language syntax,
  to
  • the semi-formal application of translator generators in compiler implementation.
• High-level programming languages themselves are an instance of increased formality, over machine level (assembler) programming in this case.

Formality is inexorable

• Everywhere rigour and formality has been used there has been an increase in the reliability of implementations.
• There is no reason to believe that this "progress" will not continue.

Summary of Main Points

• The Event-B Method is a formal method for software development.
• Here focus on use of Event-B for specification.
• Formal methods bring mathematical rigour to software development.
• Formal methods have been used to build practical computer systems.

This page maintained by John Hurst. Copyright Monash University Copyright Policy	89 accesses since 18 Aug 2008
Generated at 20090703:1343 from an XML file modified on 20080626:1254 Maintainer use only; not generally accessible: Local ServerWork ServerCSSE Server

136 accesses since 09 Jul 2009, HTML cache rendered at 20120508:1831