Recommendations for improving the usability of formal methods for product lines

Abstract

While there may be general agreement on what it means for a formal method to be usable (e.g., ease of modelling, automated and scalable analysis), there is no consensus in the software-engineering or formal-methods communities on what strategies lead to more usable formalisms. In this paper, we aim to raise discussion around such strategies by proposing fourteen concrete recommendations for achieving practical formal methods. Our recommendations apply to research in formal modelling, automated analysis, and automated transformation (e.g., transforming a model into the input to an analysis tool). Our recommendations focus on formal methods for functional requirements of software product lines, as per our experience in this area as part of a research project in collaboration with an automotive manufacturer; however, most of the recommendations apply to formal methods in general. We also provide a brief overview of a formal modelling language and an underdevelopment tool chain that realizes our recommendations.

Towards Modular Verification of Software Product Lines with mCRL2

“…In particular, we presented a basic example to illustrate the use of mCRL2's parametrized data language to model and select valid product configurations, in the presence of feature attributes and quantitative constraints, and to model and check the behavior of valid products. This is in line with the analysis recommendations from [3] to "adopt and extend state-of-the-art analysis tools" and to "examine [s] only valid product variants". We also hinted at the use of model reduction.…”

“…Using the example from [5], we show how its behavioral model can be modularized (in a feature-oriented fashion) into components, with interfaces that allow a driver process to glue them back together on the fly. This is a powerful abstraction technique that allows mCRL2 to concentrate on the relevant components (features) for the specific property under scrutiny, and in accordance with the modeling recommendation from [3] to "support (feature) modularity" in order "to visualize and (manually or automatically) analyze feature combinations corresponding to products of the product line".…”

Software product line analysis with mCRL2

“…In particular, we presented a basic example to illustrate the use of mCRL2's data language to model and select valid product configurations, in the presence of feature attributes and quantitative constraints, and to model and check the behavior of valid products. This is in line with the analysis recommendations from [5] to "adopt and extend state-of-the-art analysis tools" and to "examine[s] only valid product variants". In Sect.…”

“…Exploiting the same example from [8], we showed how its behavioral model can be modularized (in a feature-oriented fashion) into components, with interfaces that allow a driver process to glue them back together on the fly. This is a powerful abstraction technique that allows mCRL2 to concentrate on the relevant components (features) for a specific property under scrutiny, and in accordance with the modeling recommendation from [5] to "support (feature) modularity" in order "to visualize and (manually or automatically) analyze feature combinations corresponding to products of the product line". In Sect.…”

Flexible modular formalization of UML sequence diagrams

“…?m is equivalent to !m and ?m at the same time instant, and a pair of enclose the events that happen at the same time. 3 A general ordering is a binary relation between events that describes that an event must occur before another in a trace. at a single global time (SGT), or (b) each lifeline does it at particular independent local times (ILT).…”