8.2.1 Automated tool for transforming the ORDER model to Event-B
At the current state of this research, after all the diagrams of the ORDER model are drawn, we have to manually transform the diagrams to Event-B. This process is simple in the case of small systems. But, this process becomes more tedious and needs more effort, if the systems become larger. This is trivial that it is better to have an automated tool to transform the diagrams to Event-B.
This idea is possible, since the Rodin platform is constructed on top of Eclipse [Ecl07], an open development platform. The Rodin platform allows creating plug-ins to support the Event-B modeling. UML-B [SBS09] is one of the plug-ins in Event-B supporting graphical approach. One direction might to create a plug-in for the ORDER model in Rodin platform from scratch. Another better direction is by extending the existing plug-ins which are related to graphical modeling.
8.2.2 Extension of the ORDER model
Even though the ORDER model is defined in a way that follows the Event-B specifications, not all the components of the Event-B can be supported by the ORDER model. One example is that Event-B has three kinds of events: ordinary,convergent, andanticipated.
The events used throughout this thesis are ordinary ones. The convergent and anticipated events are the events that are needed to take the termination of events in account. This is to ensure the events cannot keep control of a machine forever. To ensure that, the machine must have variants which are mathematical expressions for guaranteeing that the events can be terminated through the proof obligation named V AR. These kinds of event and the variants are also crucial for the safety requirements specification. The ORDER model should support these notations of Event-B as well.
As discussed in Chapter 4, we assumed that before using the ORDER model, all the variables, carrier sets, and constants are already identified. The current ORDER model does not support the identification of these components. We suggested that it is possible to
use other approaches which contain the notions of class diagram to help the identification.
Thus, one possible further work is to extend the ORDER model with the class-diagram-like diagram.
8.2.3 Modularization
If a model becomes too large, it is difficult to manage and comprehend. This is also true for the ORDER model. Usually, most models with the problems should be able to be modularized. For examples, UML [SB06] has the notions of packages to group the classes in a class diagram and communicate with other packages through some interface. Event-B also contains the notions of ‘Event-B decomposition’ to decompose a single machine into several sub-machines that can be still be seen as one machine. To modularize the ORDER model, the Event-B decomposition is one candidate to be applied in the ORDER model.
8.2.4 Formalization of the ORDER model
We presented the refinement tree diagram and the event transition diagram along with their construction rules in a semi-formal way. This might be sufficient in the short-term of this research. While, in the long-term, the formal semantics of the ORDER model must be defined. The formal semantics are important for analysis and improving the precision of the model. The precision is needed for avoiding ambiguity and inconsistency of the model. Such concepts can support the implementation of the automated tool and the extension of the model.
Appendix A
Powered sliding door case study
A.1 Refinement tree diagram
T
INPUT When input=TRUE and Then input:=FALSE
RESULT Wheninput = FALSE Then input:=TRUE INPUT_2
When input=TRUE and Then skip
[Parallel]
INPUT When input=TRUE and Then input:=FALSE INPUT_speed_changed_door_closing
Any d When input=TRUE and door is closed and d is a possible value of speed Then speed := d
INPUT_speed_changed_door_opening Any d
When input=TRUE and door is opened and d is less than 15 Then speed := d If input=TRUE then
Door is either opened or closed
RESULT_close When input = FALSE and speed>15 Then input:=TRUE and close the door
RESULT When input = FALSE and speed≤15 Then input:=TRUE and door is either closed or opened
If input=FALSE then Speed is either more than 15 or less than or
equal to 15
If door is opened then Speed is below 15
A B C
D E
95
INPUT When input=TRUE and Then input:=FALSE INPUT_speed_changed_door_closing
Any d When input=TRUE and door is closed and d is a possible speed in case of speeding up and speed_checked=FALSE Then speed := d
INPUT_speed_changed_door_closing Any d
When input=TRUE and door is closed and d is a possible speed in case of slowing up and speed_checked=FALSE Then speed := d
INPUT_speed_changed_door_opening Any d
When input=TRUE and door is opened and d is more than or equal to the current speed but less than 15 and speed_checked=FALSE Then speed := d
INPUT_speed_changed_door_opening Any d
When input=TRUE and door is opened and d is less than or equal to the current speed but more than 0 and speed_checked=FALSE Then speed := d
Request When input=TRUE and Then input:=FALSE and request is sent or not INPUT_speed_changed_door_closing
Any d When input=TRUE and door is closed and d is a possible speed in case of speeding up and speed_checked=FALSE Then speed := d
INPUT_speed_changed_door_closing Any d
When input=TRUE and door is closed and d is a possible speed in case of speeding up and speed_checked=FALSE Then speed := d
INPUT_speed_changed_door_opening Any d
When input=TRUE and door is opened and d is more than or equal to the current speed but less than 15 and speed_checked=FALSE Then speed := d
INPUT_speed_changed_door_opening Any d
When input=TRUE and door is opened and d is less than or equal to the current speed but more than 0 and speed_checked=FALSE Then speed := d
A B C
RESULT_close When speed_checked=TRUE and switch is off Then input:=TRUE and close the door and speed_checked=FALSE
RESULT When speed_checked=TRUE and switch is on Then input:=TRUE and door is either closed or opened and speed_checked=FALSE switch_off
When input = FALSE and speed>15 and speed_checked=FALSE Then speed_checked:=TRUE and switch is off
<<before>>
Switch_off <<before>>
Switch_on switch_on
When input = FALSE and speed≤15 and speed_checked=FALSE Then speed_checked:=TRUE and switch is on
If speed_checked=TRUE and switch is off then Speed is more than 15
If speed_checked=TRUE and switch is on then Speed is less than or equal to 15
switch_off When input = FALSE and speed>15 and speed_checked=FALSE Then speed_checked:=TRUE and switch is off
RESULT_close When speed_checked=TRUE and switch is off Then input:=TRUE and close the door and speed_checked=FALSE
switch_off When input = FALSE and speed≤15 and speed_checked=FALSE Then speed_checked:=TRUE and switch is on
RESULT_no_request When speed_checked=TRUE and switch is on and no request Then input:=TRUE and door’s status is not changed and speed_checked=FALSE
RESULT_request_open When speed_checked=TRUE and switch is on and request is received and door is closed Then input:=TRUE and door is opened and speed_checked=FALSE
RESULT_request_close When speed_checked=TRUE and switch is on and request is received and door is opened Then input:=TRUE and door is closed and speed_checked=FALSE If speed_checked=TRUE and switch is on then
Either no request or request and door is opened or request and door is closed
D E
96