Using Event-B and the Rodin Platform to Teach Formal Methods in Software Engineering

1. Using Event-B and the Rodin Platform to Teach Formal Methods in Software Engineering Marius Brezovan and Eugen Ganea University of Craiova Faculty of Automation, Computers and Electronics Computers and Information Technology Department 14th Workshop Software Engineering Education and Reverse Engineering

2. Outline of this presentation • Introduction • Challenges of teaching Formal Methods • Choosing the notation • Event-B and Rodin • Teaching method • Conclusions 14th Workshop Software Engineering Education and Reverse Engineering

3. Introduction • An important goal of the Software Engineering (SwE) is to allow the development of the reliablesoftware products despite their complexity • One way of achieving this goal is to use Formal Methods (FM) in software development process • From the SwE point of view: • FM are mathematically based languages, techniques, and tools for specifying and verifying software products 14th Workshop Software Engineering Education and Reverse Engineering

4. Introduction • ACM and IEEE Computer Society specify FM as one of the concepts that an graduate program in SwE should incorporate: • Curriculum Guidelines for Graduate Degree Programs in Software Engineering - GSwE2009 • From GSwE2009, FM in SwE are present in disciplines from the Core Body of Knowledge (CBOK): • Requirements Engineering: Req. Analysis, Req. Spec. Techniques, Model Validation • Software Design: Notations and Methods 14th Workshop Software Engineering Education and Reverse Engineering

5. Introduction • In SwE master programs from several Universities, at least one FM for Sw development is taught: • as a separate course, or integrated into other courses • At the University of Craiova, Faculty of Automation, Computers and Electronics we have a "Software Engineering" master program 2 years) • The curriculum of our program contains "Formal Methods in Software Engineering": • as a core discipline, taught in the first semester 14th Workshop Software Engineering Education and Reverse Engineering

6. Challenges when teaching Formal Methods • Generally speaking, using a FM should involve: • Building a formal specification model of a system, once its requirements have been analyzed • Using this specification during system development: • Design • Construction • Teaching FM presents several challenges: • The difficulty of attracting students • The need for mathematical skills • Tool support 14th Workshop Software Engineering Education and Reverse Engineering

7. Challenges when teaching Formal Methods • A. The difficulty of attracting students: • Students are focused on gaining skills that industry demands • FM are generally not related with the object-oriented software construction • FM are perceived as difficult because of their mathematical background • Remarks: • For the 2nd and the 3rd issue: • they can be addressed by a suitable choice of methods and tools 14th Workshop Software Engineering Education and Reverse Engineering

8. Challenges when teaching Formal Methods • Remarks continued: • For the first issue: • It is a reality the fact that only a small percentage of commercial software projects use formal methods • In our opinion, two solutions on this problem seem to be feasible: • A direct awareness of the IT industry: a closer connection between the academic community and the IT industry in Craiova and in South-West Oltenia county • An indirect awareness of the IT industry: to provide to the IT industry more MScSE graduates who possess skills related to the design and construction of software by using FM 14th Workshop Software Engineering Education and Reverse Engineering

9. Challenges when teaching Formal Methods • B. The need for mathematical skills: • The notations used are often based on (more or less) mathematical notation • Most tools supporting formal methods require the user to assist in constructing a substantial proportion of the proofs needed to discharge the verification conditions • Remarks: • For the second issue: • The need for the user to assist in constructing proofs makes formal methods hard to use • A solution to this problem is to choose those FM that allow the automatic construction of proofs 14th Workshop Software Engineering Education and Reverse Engineering

10. Challenges when teaching Formal Methods • Remarks continued: • For the first issue: • There is not a prerequisite for admission to MScSwE of graduate mathematics courses from the bachelor level • A solution to this problem is to restructure the interview for admission to the SwE master • Now the admission interview has 3 components: • Computer programming, Databases, Network application development • A better solution could contain the following components: • Discrete mathematics, Computer programming, Introduction to Software engineering 14th Workshop Software Engineering Education and Reverse Engineering

11. Challenges when teaching Formal Methods • C. Tool support: • Used only as mathematically based languages and techniques, FM are difficult to be understood by students, and also by software engineers • Several tools supporting most of FM were developed • Remarks: • Tools may offer support to the two main aspects of FM: • The model validation problem (automated theorem provers, proof assistants, model checkers) • The relation between specification and implementation problem (refinement, transforming and code generation) 14th Workshop Software Engineering Education and Reverse Engineering

12. Challenges when teaching Formal Methods • Remarks continued: • Unfortunately there are few FM for which there are developed tools covering both aspects • Most FM have tools for model checking (VDM, Z, B, Event-B) • Few FM have tools for vertical approach: relation between specification and implementation (VDM, B, Event-B) • Most of them have commercial licenses (VDM, B) • Event-B is a notable exception (it has the free and open source RODIN platform) • Tools from the vertical approach are closer related to the classic SwE processes 14th Workshop Software Engineering Education and Reverse Engineering

13. Choosing the notation • Two main approaches to FM: • Model-basedspecification languages, where the behavior of the modeled system is expressed by its operations, or actions that can be performed • The underlying foundations are in discrete mathematics, set theory, category theory, and logic • Set and Category Theory: • VDM(Vienna Development Method): Bjørner and Jones (1972-1978) – ISO Standard, 1996 • Z, proposed by Abrial (1974) – ISO Standard, 2002 • Abstract State Machines (ASM): • B method, proposed by Abrial (1996), • Event-B, proposed by Abrial (2005) 14th Workshop Software Engineering Education and Reverse Engineering

14. Choosing the notation • Two main approaches to FM continued: • Algebraic specifications, where the behavior of the target system can be expressed by focusing on the manipulated data • The mathematical foundation is based on the use of multi-sorted algebras • Some languages: • OBJ (developed by Goguen), 1976 • Clear (developed by Burstall and Goguen), 1977 • CASL (from the group Common Framework Initiative), 1997 • LOTOS (developed by an international group), ISO Standard, 1990 14th Workshop Software Engineering Education and Reverse Engineering

15. Choosing the notation • From the two main FM approaches we chosen to use model-based specification languages for the “Formal Methods in Software Engineering” course • The main reason: • In our opinion the main obstacle for FM both in academia and in industry = lack of scalable and practical tool support • The group of model-based specification languages has more tool support than the group of algebraic specifications 14th Workshop Software Engineering Education and Reverse Engineering

16. Choosing the notation • We choose a FM, which contains: • A specification language with • A formal syntax • A formal semantics • A tool support with • A formal proof system • A refinement and transforming system • A code generation system (if possible) • Since 2004 we have used several FM: • 2004-2007: VDM • 2007-2009: Z; 2009-2011: Object Z • 2011-2013: Event-B 14th Workshop Software Engineering Education and Reverse Engineering

17. Choosing the notation • VDM and Z are FM from the same category • Both languages had in that period free tools that allowed: • Model checking • Model animation • In addition, Object Z is an extension of Z that • Includes object-oriented concepts • Allows specifying systems in an object-oriented manner • Event-B, and its associated tool (the Rodin platform) allows in addition: • The refinement operation • Code generation 14th Workshop Software Engineering Education and Reverse Engineering

18. Event-B and Rodin • Event-Bis an extension of the B method, which allows the refinement of a modeled system • Event-B models use two basic constructs: • Contexts, which contain the static part of a model • Machines, which contain the dynamic part • Event-B implements stepwise refinement: • progressively making an abstract specification more precise through a series of incremental steps • each step creates a more detailed model, which is a refinement of the previous one 14th Workshop Software Engineering Education and Reverse Engineering

19. Event-B and Rodin • In an Event-B model: • contexts are extended, while machines are refined • Event-B developments are verified through the use of Proof Obligations (POs) 14th Workshop Software Engineering Education and Reverse Engineering

20. Event-B and Rodin • Rodin is a platform implemented on top of the Eclipse • for the development and verification of Event-B specifications • This is achieved by automatically generating and discharging POs • allows the integration of reasoning during the development of Event-B models • The Rodin tool chain contains: • The static checker • The proof obligation generator • The proof obligation prover 14th Workshop Software Engineering Education and Reverse Engineering

21. Event-B and Rodin • Rodin was initially developed as part of the European Union ICT Project RODIN (2004 - 2007) • and then continued by the EU ICT research projects DEPLOY (2008 - 2012) and ADVANCE (2011 - 2014) • The tool is implemented in Java and it uses several plug-ins that extend its basic functionality, such as: • UML-B: graphical front-end for the modeling as UML-like diagrams • ProB: provides animation and model checking capabilities • ProR : provides requirement traceability between an Event-B model and the natural language requirements 14th Workshop Software Engineering Education and Reverse Engineering

22. The teaching method • We moved from Object Z to Event-B method in 2011 because Event-B + Rodin : • Allow the formal program development (specification  code generation) • Allow stepwise refinement of successive models • Allow verification of correctness of the refined models • Allow the code generation (in C, C++, and Java) • The only deficiency of the Event-B method: • It is not object-oriented • it does not allow an object-oriented modeling of software programs 14th Workshop Software Engineering Education and Reverse Engineering

23. The teaching method • The content of the “Formal Methods in Software Engineering” course has several types of activities: • Teaching activities: • Presenting the Event-B language and its mathematical background • Presenting the refinement method and the proof obligations • Tutorials on the Rodin platform • Practical activities : • Developing a small software project using Rodin platform • Starting to the initial requirement of the system • Ending to generating code in some programming language 14th Workshop Software Engineering Education and Reverse Engineering

24. The teaching method • A. Teaching activities Abrial’s slides + auxilliary material • Presenting mathematical background of the Event-B method (sets, predicates, relations, functions) • No “Discrete Mathematics” course in the master program • There is no prerequisite for a mathematical course from the bachelor degree • Presenting the Event-Bmodeling language • Contexts, machines, events, etc. • Presenting the refinement method and the eight types of proof obligations • Presenting some small examples for these notions 14th Workshop Software Engineering Education and Reverse Engineering

25. The teaching method • Remarks: • The most difficult is the lecturesteaching activity • Student do no like it because: • Their mathematical knowledge (from the bachelor degree) is weak • They do not understand (and they do not agree with) the role of mathematics in the SwE activities • For a better understanding of these notions • Presentation of the mathematics + the modeling Event-B language must be more practical andoverlapwith some Rodin tutorials 14th Workshop Software Engineering Education and Reverse Engineering

26. The teaching method • B. Tutorials on the Rodin platform • Have a twofold role: • To present the Rodin Platform • To present the useful plug-ins developed for Rodin • This is the easiest activity (agreed by students) • Presenting plug-ins has also a twofold role: • Showing their role in the software development process • Reduction of the fact that the Event B is not O-O • Some presented plug-ins (in addition to ProB and ProR): • Decomposition (decomposition of Event-B machines/contexts) • Modularization (provides modular development) • UML-B (UML-like graphical front end for Event-B) 14th Workshop Software Engineering Education and Reverse Engineering

27. The teaching method • C. Practical activities : • Developing a small software project by using the Rodin platform (represent the assessment of this course) • Translating requirements to the first Event-B abstract model • Stepwise refinement of the successive models (toward the last concrete model) • Generating code in a programming language for the last concrete model • Remarks • Generally is an activity agreed by students • Some drawbacks: • Problems with requirements engineering • There is no “Requirements Engineering” course at the master • Some problems with code generation plug-in (not so mature) 14th Workshop Software Engineering Education and Reverse Engineering

28. Conclusions • A difficult course for teaching (see “Challenges when teaching Formal Methods”) • Students are not very well motivated (despite of fact that it is a compulsory course): • Difficulty of the mathematical background • Gradual introduction (and more practical) to important concepts • Most students are already working in IT companies • A small percentage of IT companies use formal methods • Difficulty in choosing an appropriate FM + its related tool support 14th Workshop Software Engineering Education and Reverse Engineering

29. Conclusions • Some proposals for the future: • Increasing the necessary skills of the students by modifying the admission interview : • Discrete mathematics, Computer programming, Introduction to Software engineering • Incorporating in the Rodin platform (by own research, which is already started) the main Object-Oriented concepts (other than UML formalism) • or switching to the VDM language + VDMTools (which has a free license now, and a code generator module) 14th Workshop Software Engineering Education and Reverse Engineering

30. Conclusions • Some proposals for the future continuaed: • To add a new action when teaching FM in SwE: • Automatic generation of test cases Thank you for your attention! 14th Workshop Software Engineering Education and Reverse Engineering