Incremental elaboration of scenario-based specifications and behavior models using implied scenarios

Abstract

Behavior modeling has proved to be successful in helping uncover design flaws of concurrent and distributed systems. Nevertheless, it has not had a widespread impact on practitioners because model construction remains a difficult task and because the benefits of behavior analysis appear at the end of the model construction effort. In contrast, scenario-based specifications have a wide acceptance in industry and are well suited for developing first approximations of intended behavior; however, they are still maturing with respect to rigorous semantics and analysis tools.This article proposes a process for elaborating system behavior that exploits the potential benefits of behavior modeling and scenario-based specifications yet ameliorates their shortcomings. The concept that drives the elaboration process is that of implied scenarios . Implied scenarios identify gaps in scenario-based specifications that arise from specifying the global behavior of a system that will be implemented component-wise. They are the result of a mismatch between the behavioral and architectural aspects of scenario-based specifications. Due to the partial nature of scenario-based specifications, implied scenarios need to be validated as desired or undesired behavior. The scenario specifications are then updated accordingly with new positive or negative scenarios. By iteratively detecting and validating implied scenarios, it is possible to incrementally elaborate the behavior described both in the scenario-based specification and models. The proposed elaboration process starts with a message sequence chart (MSC) specification that includes basic, high-level and negative MSCs. Implied scenario detection is performed by synthesis and automated analysis of behavior models. The final outcome consists of four artifacts: (1) an MSC specification that has been evolved from its original form to cover important aspects of the concurrent nature of the system that were under-specified or absent in the original specification, (2) a behavior model that captures the component structure of the system that, combined with (3) a constraint model and (4) a property model that provides the basis for modeling and reasoning about system design.