Detecting Implied Scenarios in Message Sequence Chart Specifications Sebastian Uchitel, Jeff Kramer and Jeff Magee Department of Computing, Imperial College, 180 Queen's Gate, London SW7 2BZ, UK. {su2, jk, jnm}@doc.ic.ac.uk ABSTRACT Scenario-based specifications such as Message Sequence Charts (MSCs) are becoming increasingly popular as part of a requirements specification. Scenarios describe how system components, the environment and users work concurrently and interact in order to provide system level functionality. Each scenario is a partial story which, when combined with other scenarios, should conform to provide a complete system description. However, although it is possible to build a set of components such that each component behaves in accordance with the set of scenarios, their composition may not provide the required system behaviour. Implied scenarios may appear as a result of unexpected component interaction. In this paper, we present an algorithm that builds a labelled transition system (LTS) behaviour model that describes the closest possible implementation for a specification based on basic and high-level MSCs. We also present a technique for detecting and providing feedback on the existence of implied scenarios. We have integrated these procedures into the Labelled Transition System Analyser (LTSA), which allows for model checking and animation of the behaviour model. Categories and Subject Descriptors D.2.2 [Software Engineering]: Requirements/Specifications – Languages, Tools. I.6.4 [Simulation and Modelling]: Model Validation and Analysis. General Terms Algorithms, Languages, Verification. Keywords Synthesis, message sequence charts, implementability, labelled transition systems, FSP, LTSA. 1. INTRODUCTION Scenarios are becoming increasingly popular as tools for requirement elicitation and specification. Scenarios describe how system components, the environment and users interact in order to provide system level functionality. Each scenario is a story which, when combined with all other scenarios, should conform to provide a complete system description. Their simplicity and intuitive graphical representation allows stakeholder involvement and helps to build a common ground with the developers. Besides, as they are partial system descriptions, stakeholders can develop descriptions independently, contributing their own view of the system to those of other stakeholders. The components participating in scenario-based specifications are assumed to work independently synchronising through message exchange. The resulting concurrent systems are amenable to analysis through the construction of behaviour models. A behaviour model can be used as a precise specification of intended behaviour of a system, as a prototype for exploring the system behaviour and also to allow for automated checking of model compliance to properties (model checking). Numerous tools that allow model checking and animation of behaviour models exist (e.g. [6, 8]). Our objective is to facilitate the development of behaviour models in conjunction with scenario-based specifications. Such models are complementary and provide an alternative view of how system components interact. In particular, we believe that there is benefit to be gained by experimenting with and replaying analysis results from behaviour models in order to help correct, elaborate and refine scenario-based specifications. Scenario specifications depict a set of acceptable system behaviours and show how these behaviours are shared out among the system components. This information can be used to synthesise [2, 10, 15] a behaviour model for a possible implementation of such system. Initially one would expect the model to have exactly the same set of behaviours as those depicted in the scenario specification. However, this is not always the case. Scenarios can combine in unexpected ways and certain system behaviours, not present in the scenario specification, may appear in all possible implementations of the system. These behaviours are called implied scenarios, and they arise because components have a local view of what is happening in the system. If this view has insufficient information, a component may behave incorrectly in terms of the expected behaviour at a system level. The existence of implied scenarios is an indication of unexpected system behaviour, and detecting them can be critical. An implied scenario may simply mean that an acceptable scenario has been overlooked and the scenario specification needs to be completed. Alternatively, the implied scenario may represent an unacceptable behaviour and therefore imply a need to modify the scenario specification to avoid the undesired situation.