Concurrent Development of Model and Implementation

This paper considers how a formal mathematically-based model can be used in support of evolutionary software development, and in particular how such a model can be kept consistent with the implementation as it changes to meet new requirements. A number of techniques are listed can make use of such a model to enhance the development process, and also ways to keep model and implementation consistent. The effectiveness of these techniques is investigated through two case studies concerning the development of small e-business applications, a travel agent and a mortgage broker. Some successes are reported, notably in the use of rapid throwaway modelling to investigate design alternatives, and also in the use of close team working and modelbased trace-checking to maintain synchronisation between model and implementation throughout the development. The main areas of weakness were seen to derive from deficiencies in tool support. Recommendations are therefore made for future improvements to tools supporting formal models which would, in principle, make this co-evolutionary approach attractive to industrial software developers. It is claimed that in fact tools already exist that provide the desired facilities, but these are not necessarily production-quality, and do not all support the same notations, and hence cannot be used together.

💡 Research Summary

The paper investigates how a mathematically‑based formal model can be integrated into evolutionary or agile software development and kept consistent with the implementation as both evolve. Traditional top‑down, waterfall‑style formal methods require a complete specification before coding, which is impractical for most commercial projects. Instead, the authors propose treating the formal model as a “partially complete” design artifact that co‑evolves with the code.

Four categories of benefits are outlined: (1) animation/visualisation of model execution, which helps developers understand intended behaviour and catch early mistakes; (2) model‑checking, which exhaustively explores the state space to detect invariant violations or temporal‑logic property breaches; (3) assertion insertion based on pre‑ and post‑conditions, enabling runtime checks during debugging; and (4) model‑based testing, including systematic test‑case generation and trace‑checking, where execution logs are compared against the model using a model‑checker such as ProB. The authors stress that these techniques are most valuable when the model and implementation remain tightly coupled; otherwise, testing against an outdated model is meaningless.

Two case studies are presented: a travel‑agent system and a mortgage‑broker application, both built with Java Servlets, JDBC, and a three‑tier architecture. The development team consisted of four members, one with strong B/AMN expertise and the others with Java experience; one member also knew Spin/Promela. Early in each project, the team performed “throwaway modelling” of high‑risk components to explore design alternatives. UML class diagrams were annotated and automatically transformed into B machines using the U2B tool, while concurrent communication aspects were modelled in Spin/Promela.

In the travel‑agent case, the team attempted a two‑level modelling approach (high‑level user view plus component‑level models). This proved time‑consuming and delivered limited additional insight, suggesting that multi‑level formal modelling may not scale well without strong tool support. In the mortgage‑broker case, the team worked in a single open‑plan office, enabling continuous dialogue between modelers and programmers. ProB and Promela animation were used to demonstrate model behaviour, and model‑based trace‑checking was applied to verify that runtime logs conformed to the formal specification. This close collaboration reduced the incidence of naming mismatches and kept the model up‑to‑date with evolving requirements.

The evaluation highlights several successes: (i) rapid prototyping with formal models helped identify design risks early; (ii) animation and trace‑checking facilitated communication across roles; (iii) model‑based testing uncovered defects that would have been missed by manual tests. However, significant weaknesses emerged, primarily related to tool support. Existing tools (B‑tools, Spin, UML‑to‑B converters, ProB) each work well in isolation but lack seamless integration; they often require manual glue code, suffer from performance limitations on larger state spaces, and are not production‑grade. Formal inspections were effective for spotting divergences but were labor‑intensive.

The authors conclude that formal models can add value to evolutionary development even when full formal proof is not pursued, provided that (a) the model is kept in sync with code through regular reviews or co‑location, (b) appropriate tool chains support animation, checking, and trace analysis, and (c) the team adopts a culture of model‑driven communication. They recommend future work on unified, extensible tool platforms that can handle multiple notations, automate model‑code synchronization, and integrate with mainstream IDEs. Improving tool robustness and usability is seen as the key to making the co‑evolutionary approach attractive to industrial developers.