Lessons from DEPLOYment
📝 Abstract
This paper reviews the major lessons learnt during two significant pilot projects by Bosch Research during the DEPLOY project. Principally, the use of a single formalism, even when it comes together with a rigorous refinement methodology like Event-B, cannot offer a complete solution. Unfortunately (but not unexpectedly), we cannot offer a panacea to cover every phase from requirements to code; in fact any specific formalism or language (or tool) should be used only where and when it is really suitable and not necessarily (and somehow forcibly) over the entire lifecycle.
💡 Analysis
This paper reviews the major lessons learnt during two significant pilot projects by Bosch Research during the DEPLOY project. Principally, the use of a single formalism, even when it comes together with a rigorous refinement methodology like Event-B, cannot offer a complete solution. Unfortunately (but not unexpectedly), we cannot offer a panacea to cover every phase from requirements to code; in fact any specific formalism or language (or tool) should be used only where and when it is really suitable and not necessarily (and somehow forcibly) over the entire lifecycle.
📄 Content
Lessons from DEPLOYment Manuel Mazzara, Cliff Jones, Alexei Iliasov School of Computing Science, Newcastle University, UK 1 Overview This paper reviews the major lessons learnt during two significant pilot projects by Bosch Research during the DEPLOY project [1]. Principally, the use of a single formalism, even when it comes together with a rigorous refinement methodology like Event-B, cannot offer a complete solution. Unfortunately (but not unexpectedly), we cannot offer a panacea to cover every phase from requirements to code; in fact any specific formalism or language (or tool) should be used only where and when it is really suitable and not necessarily (and somehow forcibly) over the entire lifecycle. 2 DEPLOY and its scenarios DEPLOY is an ambitious project addressing diverse major industrial areas: automotive, train transportation, business and aerospace software. Putting all of them under the same hat is a difficult (if not impossible) task for both instrinsic and extrinsic reasons. We recognised from the very beginning that each deployment scenario would be different and would need (at least partially) different approaches, concepts and tools. Industries are different, development process differs, internal organizations are varied and, to some extent, business models are different as well as politics. Most importantly, target applications and inhouse engineering tools/standards show little similarity. Therefore, integration needs are different. The RODIN project [2] consituted a solid basis for DEPLOY giving us valid reasons to claim that the Rodin tools [3] were moderately mature. The tools were well designed by an outstanding team and the experience, including with industrial partners (although RODIN was a STREP rather than an IP), taught us that tool support is essential for most technology transfer undertakings. Although at the end of RODIN we were aware of the need to support the tools and their evolution, the reality we had to face in DEPLOY was tougher than expected for both academia and industry. Effort was immediately put in place to train industry partners via a “block course” to provide knowledge and skills leading to mini-pilots 2 first, and then major case studies (in the case of Bosch specifically two: Cruise Control and Start/Stop system [4]).
3 Problems and opportunities The Event-B notation favours a style of modelling that may be loosely characterised as event-based or reactive. There are examples where this works well and models appear natural and elegant. Unsuprisingly, there are also cases where there is a misfit between the style and developers’ expectations or system requirements. This issue is more pronounced where an industrial user is involved. In an academic setting, there is a greater degree of flexibility of how a model is developed since the construction of a piece of software is rarely an end in itself. A researcher has the advantage of a broader perspective giving the ability to recognise, without investing considerable effort, that a method is not suitable for a given problem. In the DEPLOY project, few industrial users had prior exposure to formal methods and their perspective was limited to Event-B method and tools. Obviously, they also did not have an opportunity nor the desire to avoid, or adapt their problems to the Event-B style. This steadfastness, while at times frustrating for academic partners, has resulted in a stream of feature requests, some of which were, at least partially, addressed by offering methodological and tooling extensions. Once beyond the stage of the mini-pilots, all the industrial users raised the issue of notation expressiviness. Many concepts found in programming and specification languages (records, procedure calls, macro definitions, modules, polymorphic types, meta-theorems, etc.) are not part of core Event-B. This is not a fundamental problem since the Rodin Platform is designed to be extensible and the core Event-B was purposely made compact. Still, the tool developers were surprised when industrial users indicated what they believed to be essential features missing in the Platform. The reaction took some time as effort had to be reallocated from already planned activities. In the meanwhile, industrial users still proceeded without these additional tools. At least four tools were developed in response to Bosch team requests (group refinement, records, flow and team work) and some methodological work was inspired by the problems the Bosch team has encountered applying Event-B. With hindsight, the tool developers should have spent more time with the industrial partners compiling tool requirements. Initial version of these additional tools did not fit the industry expectations. The transition from mini-pilots to larger case studies has identified a number of weaknesses in the tool implementation. The user interface did not cope well with machines comprising even
This content is AI-processed based on ArXiv data.