Adoption Eased by Using Formal Models behind Domain Specific Notations

From Evidence on Formal Methods Uses and Impact on Industry
Jump to: navigation, search
Success Story
Domain Business Information
Keywords domain specific languages, hidden formal methods, model verification
Source SAP (DEPLOY)

Main -> DEPLOY Success Stories -> BusInfo-1

Short description

This success story report about the approach taken by SAP to integrate Event-B behind domain specific notations in use at SAP for business modelling and to use the RODIN tool as a back end for performing formal checks on those models.


SAP User Interface Integration with RODIN

Related FAQ

of Interest to Engineers and Analysts

  • CIF-EA-1 When hiding a formalism, is it possible to fully automate its use to avoid overloading the few expert?

of Interest to QA Practitioners

  • CIF-QAP-1 Can QA practitioner avoid learning a formalism by hiding it and making the requirements design outcome be expressed using traditional well-known notations or languages?

Benefits

  • Ease adoption by hiding formal methods behind notations already familiar to the target users
  • Enable powerful verification on existing models

Limitations

  • Improvement of prover performance required
  • Reporting errors found at the Event-B level using DSL level language is difficult problem, not easy to generalise

Elaboration

SAP domain specific language is based on a form of business processing notation allowing the analyst to specify processes and messages exchanges.

In order to achieve integration with SAP, a number of challenges had to be solved. Those will be typically encountered in other deployment following a similar strategy.

1 – Mapping the semantics of Event-B on those of the domain specific language

Model verification cover a rich range of checks:

  • Checking the local enforceability by proving a refinement relation between the global and a local model.
  • Checking the global choreography model for internal well-definedness, such as checking for the absence of inconsumable messages, i.e. messages transmitted which cannot be received at all.
  • Checking for the absence of livelocks and deadlocks

2 – Ensuring a good level of automation

About 70% of the generated proof obligations for checking model properties could be proved automatically. Up to 80% of the remaining proof obligations could be successfully discharged by manually calling the ML, P0 and P1 provers of RODIN (not found due to the relatively short internal time-out set). The remaining POs (about 6%) had to be discharged manually.

Despite the use of techniques for automatically generate invariants through templates is helping raise the ratio of automated, the current level of automation is still not high enough to be used by users not experienced with verification work.

3 – Providing useful explanation in case of failed proof at the DSL level

Explanations could be provided using model checking results, animation snapshots, or even proof results and report them at the diagram level.

4 – Achieving User interface integration

It was achieved entirely on the Eclipse platform as MCM Editor is based on the SAP NetWeaver Developer Studio (NWDS) which is an Eclipse IDE extended by SAP specific plug-ins. The MCM component. The plug-in architecture of Eclipse permitted the seamless integration of MCM, ProB and RODIN into the SAP NWDS.

A validation was performed by 5 MCM users based on a choreography model with a non trivial error that was detectable by the tool. The model was first proposed for review and found bug free by all the users. In second part of the experiment, the experts were given the tool and could identify some bugs in the model within reasonable amount of time. The feedback was that tool was easy to learn and use. Visual feedback and simple model checks such as simulation seem to be of high importance.

A second experiment involved a semi-automated tool requiring some expert input (theorem prover). It was rated as average usability by the users. On the other hand, a similar tool (automated disprover) was rated as highly useable by the same users.

Related Work

DSLs provide a high-level means of implementing solutions to complex problems within a given domain. When a domain has critical safety or security requirements, verifying their proper implementation is essential. Bodeveix [1] shows a systematic means of using the formal method (here B) to verify a process scheduling policy implemented using the Bossa DSL.

Specific Contributions

  • DSL to Event-B translator with generation of domain specific invariant
  • DSL level explanation of model-checking results
  • Full tool integration based on the Eclipse platform

Further work

  • Elaboration of proof explanation, investigation of pattern-based techniques
  • Validation and integration in production environment
  • Similar work to be explored in transportation deployment related to similar requirements on automata to be used by system architects.

References

  1. Jean-Paul Bodeveix, Mamoun Filali, Julia Lawall, and Gilles Muller. Formal Methods Meet Domain Specific Languages. In Proceedings of the 5th International Conference on Integrated Formal Methods, Eindhoven, The Netherlands, pages 187-206, 2005.

-->


Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox