Lessons Learnt from Pilot Deployment. During pilot deployment we went from the Problem Frames Model to an Event-B model without an intermediate specification. We directly mapped Problem Frames elements to Event-B elements and used data refinement in Event-B. Details of our Event-B modelling approach for pilot deployment are described in the DEPLOY deliverable D19 [D19]. We learnt the following lessons with regard to Event-B. Some of these lessons are also described in a paper that will be presented at ICFEM 2011 [GGH+11]: • Refinement Strategy Event-B supports horizontal (superposition) and vertical (data) refinement. Both refinement strategies can be used in an Event-B model. Typically, horizontal (superposition) refinement is used for augmenting the model with additional events and variables whereas vertical (data) refinement is used to refine abstract data types. We started with an abstract model containing abstract data types and abstract events corresponding to the abstract context diagram in our Problem Frames model. We then applied vertical refinement to make those abstract data structures more concrete. Although Event-B in principle supports vertical refinement, we had difficulties in finding the best way to do the vertical refinement. In the end we used a special form of instantiation of abstract data types for modelling the relationship between abstract and concrete types. Since this special form of instantiation was not directly supported by the RODIN tool we had to manually add axioms to the context that were both difficult to understand and cumbersome to maintain. The lesson we learnt during pilot deployment was that XXXXX is better suited for horizontal refinement than for vertical refinement. 41 • Modularization The Problem Frames model we built for the case study for pilot deployment contained several subproblems on different abstraction layers (see deliverable D19 for details [D19]). The sub- problems in our Problem Frames model were linked by elaboration and projection operations. We wanted to map this structure to the Event-B model. Although we were able to model the different abstrac- tion levels of our Problem Frames model using Event-B refinement it was very difficult to model projections of subproblems with Event-B means. Besides refinement Event-B and the RODIN tool provide very little additional structuring mechanisms. Especially a clear modular- ization concept found in many programming languages and even in classical B is missing in Event-B. The decomposition appro...
Lessons Learnt from Pilot Deployment. There are several lessons learnt from the pilot deployment we tried to respect in the enhanced deployment. We will seperate them into three subsections: application, method/process and tools.
Lessons Learnt from Pilot Deployment. We learnt many lessons from the pilot deployment of Event-B to the cruise control system [D19]. During pilot deployment we directly mapped elements of the Problem Frames Model to Event-B elements. Although this direct mapping provides good traceability it has several drawbacks which are de- scribed below: • Requirements Analysis and Specification During pilot deploy- ment the Problem Frames model was used as a documentation of both the requirements and the specification. The problem was that the Prob- lem Frames approach is better suited for requirements development than for specification. The Problem Frames approach does not pro- vide means of describing a specification other than natural language descriptions of machine domains. Therefore our specification during pilot deployment had to be written in terms of machine descriptions that are mainly based on natural language. • Structure/Architecture The decision we made during pilot deploy- ment to use the Problem Frames model as a documentation for both requirements and specification clearly constrained us in the structure, i.e., the structure of the Problem Frames model dictated the structure of the specification because the specification was contained within the model itself. This caused problems when we mapped the structure of the Problem Frames model to Event-B. The hierarchical structure of the Problem Frames model we used during pilot deployment was in fact a stepwise refinement from an abstract design to a concrete design, i.e., a specification of the system. • Description of State Machines During pilot deployment we had to specify a state machine for the cruise control system. Each transition of the state machine was described as a separate requirement in the Problem Frames model. Sometimes the conditions for a transition in the state machine were split to more than one requirement due to the subproblem structure of the Problem Frames model. When we tried to map that structure to Event-B it became very difficult to under- stand the resulting Event-B model because the conditions for a single transition in the state machine were scattered to multiple events in the Event-B model. Since the Problem Frames approach did not provide additional means for the specification of state machines we used an external drawing tool for drawing the states and the transitions. This meant additional work for synchronizing the conditions on the transi- tions in the drawing tool with the requirements text in the Proble...
