Final Report Summary - PBM - FIMBSE (Partial Behaviour Modelling: A Foundation for Incremental and Iterative Model-Based Software Engineering)
Software systems are amenable to analysis through the construction of behaviour models. This corresponds to the traditional engineering approach to construction of complex systems. Models can be studied to increase confidence on the adequacy of the product to be built. The advantage of using behaviour models is that they are cheaper to develop than the actual system. Consequently, they can be analysed and mechanically checked for properties in order to detect design errors early in the development process and allow cheaper fixes.
Although behaviour modelling and analysis has been shown to be successful in uncovering subtle requirements and design errors, adoption by practitioners has been slow. Partly, this is due to the complexity of building behaviour models in the first place - behaviour modelling remains a difficult, labour-intensive task that requires considerable expertise. In addition, and perhaps more importantly, the benefits of the analysis appear only at the end of a costly process of constructing a comprehensive behaviour model.
The reason for the latter is that traditional behaviour models are required to be complete descriptions of the system behaviour. This completeness assumption is limiting in the context of software development process best practices which include iterative development, adoption of use-case and scenario-based techniques, and viewpoint- or stakeholder-based analysis; practices which require modelling and analysis in the presence of partial information about system behaviour.
In this project we have aimed to answer the following questions: Can we provide automated or semi-automated procedures to assist engineers in building initial approximations of system behaviour? Can we provide feedback early in the model construction effort, even in the presence of partial behaviour descriptions? Can such feedback prompt the elaboration of behaviour models towards complete behaviour descriptions? We have searched for answers to these questions in three different ways, leading to different and complementary results that help answering the questions above positively.
We investigated the use of behavior models (specifically Modal Transition Systems and its variants) that allow explicit representation of required, proscribed and unknown behavior. This allows reasoning about aspects of the system that remain to be elicited or decisions that have been deliberately postponed. We developed techniques for automatically constructing Modal Transition Systems from heterogeneous specifications that are commonly used by software engineers at early stages of software development. We established automated techniques that support reasoning about the resulting models. We developed theoretical foundations that allow the above results and also built a publicly available open-source tool called the Modal Transition System Analyser for others to build on our ideas.
We also investigated automated learning techniques to support extending and correcting behavior models through the provision of examples and counter-examples. The rationale is that when engineers analyse a behavior model to understand if it captures their design intent, they typically come up with examples of perceived problems. However, going from these examples to an understanding of what are the conceptual flaws in the model is notoriously hard, and then coming up with a fix that does not break other aspects of the model is even harder. We developed techniques, based on symbolic machine learning, that can automatically identify the cause for examples of bad behavior and fix behavior models to avoid these examples.
Finally, we studied discrete event controller synthesis as a way of supporting incremental elaboration of behavior models. Controller synthesis can resolve the question of whether the designed capabilities of the system (i.e. interface) can achieve the expected goals under assumed environment conditions. Such feasibility question helps identifying problems in all three crucial elements of early system design. We have demonstrated that controller synthesis can be used to validate assumptions, system capabilities and goals in early software engineering phases, prompting the elaboration of behavior models.
Although behaviour modelling and analysis has been shown to be successful in uncovering subtle requirements and design errors, adoption by practitioners has been slow. Partly, this is due to the complexity of building behaviour models in the first place - behaviour modelling remains a difficult, labour-intensive task that requires considerable expertise. In addition, and perhaps more importantly, the benefits of the analysis appear only at the end of a costly process of constructing a comprehensive behaviour model.
The reason for the latter is that traditional behaviour models are required to be complete descriptions of the system behaviour. This completeness assumption is limiting in the context of software development process best practices which include iterative development, adoption of use-case and scenario-based techniques, and viewpoint- or stakeholder-based analysis; practices which require modelling and analysis in the presence of partial information about system behaviour.
In this project we have aimed to answer the following questions: Can we provide automated or semi-automated procedures to assist engineers in building initial approximations of system behaviour? Can we provide feedback early in the model construction effort, even in the presence of partial behaviour descriptions? Can such feedback prompt the elaboration of behaviour models towards complete behaviour descriptions? We have searched for answers to these questions in three different ways, leading to different and complementary results that help answering the questions above positively.
We investigated the use of behavior models (specifically Modal Transition Systems and its variants) that allow explicit representation of required, proscribed and unknown behavior. This allows reasoning about aspects of the system that remain to be elicited or decisions that have been deliberately postponed. We developed techniques for automatically constructing Modal Transition Systems from heterogeneous specifications that are commonly used by software engineers at early stages of software development. We established automated techniques that support reasoning about the resulting models. We developed theoretical foundations that allow the above results and also built a publicly available open-source tool called the Modal Transition System Analyser for others to build on our ideas.
We also investigated automated learning techniques to support extending and correcting behavior models through the provision of examples and counter-examples. The rationale is that when engineers analyse a behavior model to understand if it captures their design intent, they typically come up with examples of perceived problems. However, going from these examples to an understanding of what are the conceptual flaws in the model is notoriously hard, and then coming up with a fix that does not break other aspects of the model is even harder. We developed techniques, based on symbolic machine learning, that can automatically identify the cause for examples of bad behavior and fix behavior models to avoid these examples.
Finally, we studied discrete event controller synthesis as a way of supporting incremental elaboration of behavior models. Controller synthesis can resolve the question of whether the designed capabilities of the system (i.e. interface) can achieve the expected goals under assumed environment conditions. Such feasibility question helps identifying problems in all three crucial elements of early system design. We have demonstrated that controller synthesis can be used to validate assumptions, system capabilities and goals in early software engineering phases, prompting the elaboration of behavior models.