Message Sequence Chart Specifications Research Articles

The Oracle Problem When Testing from MSCs

Message Sequence Charts (MSCs) form a popular language in which scenariobased specifications and models can be written. There has been significant interest in automating aspects of testing from MSCs. This paper concerns the Oracle Problem, in which we have an observation made in testing and wish to know whether this is consistent with the specification. We assume that there is an MSC specification and consider the case where we have entirely independent local testers (local observability) and where the observations of the local testers are logged and brought together (tester observability). It transpires that under local observability the Oracle Problem can be solved in low-order polynomial time if we use sequencing, loops and choices but becomes NP-complete if we also allow parallel components; if we place a bound on the number of parallel components then it again can be solved in polynomial time. For tester observability, the problem is NP-complete when we have either loops or choices. However, it can be solved in low-order polynomial time if we have only one loop, no choices, and no parallel components. If we allow parallel components then the Oracle Problem is NP-complete for tester observability even if we restrict to the case where there are at most two processes.

A framework for pathologies of message sequence charts

ContextIt is known that a Message Sequence Chart (MSC) specification can contain different types of pathology. However, definitions of different types of pathology and the problems caused by pathologies are unclear, let alone the relationships between them. In this circumstance, it can be problematic for software engineers to accurately predict the possible problems that may exist in implementations of MSC specifications and to trace back to the design problems in MSC specifications from the observed problems of an implementation. ObjectiveWe focus on generating a clearer view on MSC pathologies and building formal relationships between pathologies and the problems that they may cause. MethodBy concentrating on the problems caused by pathologies, a categorisation of problems that a distributed system may suffer is first introduced. We investigate the different types of problems and map them to categories of pathologies. Thus, existing concepts related to pathology are refined and necessary concepts in the pathology framework are identified. Finally, we formally prove the relationships between the concepts in the framework. ResultsA pathology framework is established as desired based on a restriction that considers problematic scenarios with a single undesirable event. In this framework, we define disjoint categories of both pathologies and the problems caused; the identified types of pathology are successfully mapped to the problems that they may cause. ConclusionThe framework achieved in this paper introduces taxonomies into and clarifies relationships between concepts in research on MSC pathologies. The taxonomies and relationships in the framework can help software engineers to predict problems and verify MSC specifications. The single undesirable event restriction not only enables a categorisation of pathological scenarios, but also has the potential practical benefit that a software engineer can concentrate on key problematic scenarios. This may make it easier to either remove pathologies from an MSC specification M or test an implementation developed from M for potential problems resulting from such pathologies.

Timing analysis of MSC specifications with asynchronous concatenation

Message Sequence Chart (MSC) is a graphical and textual language for describing the interactions between system components, and MSC specifications (MSSs) are a combination of a set of basic MSCs (bMSCs) and a High-level MSC that describes potentially iterating and branching system behavior by specifying the compositions of basic MSCs, which offer an intuitive and visual way of specifying design requirements. With concurrent, timing, and asynchronous properties, MSSs are amenable to errors, and their analysis is important and difficult. This paper deals with timing analysis of MSC specifications with asynchronous concatenation. For an MSC specification, we require that for any loop, its first node be flexible in execution time and its any associated external timing constraint be enforced on the entire loop. Such an MSC specification is called a flexible loop-closed MSC specification (FLMSS). We show that for FLMSSs, the reachability analysis and bounded delay analysis problems can be solved efficiently by linear programming. The solutions have been implemented into our tool TASS and evaluated by experiments.

Symbolic Message Sequence Charts

Message sequence charts (MSCs) are a widely used visual formalism for scenario-based specifications of distributed reactive systems. In its conventional usage, an MSC captures an interaction snippet between concrete objects in the system. This leads to voluminous specifications when the system contains several objects that are behaviorally similar. MSCs also play an important role in the model-based testing of reactive systems, where they may be used for specifying (partial) system behaviors, describing test generation criteria, or representing test cases. However, since the number of processes in a MSC specification are fixed, model-based testing of systems consisting of process classes may involve a significant amount of rework: for example, reconstructing system models, or regenerating test cases for systems differing only in the number of processes of various types. In this article we propose a scenario-based notation, called symbolic message sequence charts (SMSCs), for modeling, simulation, and testing of process classes. SMSCs are a lightweight syntactic and semantic extension of MSCs where, unlike MSCs, a SMSC lifeline can denote some/all objects from a collection. Our extensions give us substantially more modeling power. Moreover, we present an abstract execution semantics for (structured collections of) SMSCs. This allows us to validate MSC-based system models capturing interactions between large, or even unbounded, number of objects. Finally, we describe a SMSC-based testing methodology for process classes, which allows generation of test cases for new object configurations with minimal rework. Since our SMSC extensions are only concerned with MSC lifelines, we believe that they can be integrated into existing standards such as UML 2.0. We illustrate our SMSC-based framework for modeling, simulation, and testing of process classes using a weather-update controller case-study from NASA.

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

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.

Negative scenarios for implied scenario elicitation

Scenario-based specifications such as Message Sequence Charts (MSCs) are popular for requirement elicitation and specification. MSCs describe two distinct aspects of a system: on the one hand they provide examples of intended system behaviour and on the other they outline the system architecture. A mismatch between architecture and behaviour may give rise to implied scenarios. Implied scenarios occur because a component's local view of the system state is insufficient to enforce specified system behaviour. An implied scenario indicates a gap in the MSC specification that needs to be clarified. It may simply mean that an acceptable scenario has been overlooked and should be added to the scenario specification. Alternatively, it may represent an unacceptable behaviour which should be documented and avoided in the final implementation. Thus implied scenarios can be used to iteratively drive requirements elicitation. However, in order to do so, tools for coping with rejected implied scenarios are needed. The contributions of this paper are twofold. Firstly, we define a language for describing negative scenarios. Secondly, we complement existing implied scenario detection methods with techniques for accommodating negative scenarios.

Checking MSC specifications for timing inconsistency

Message sequence chart (MSC) is a graphical and textual language for the description and specification of the interactions between system components. MSC specifications allow convenient expression ...

A method of applying message sequence chart specifications for services with variant process structure

AbstractMessage sequence charts have recently been the focus of considerable attention as formal specification descriptions and become standardized. However, At is difficult to use them for specifying services with variant process structure, such as interrupt services.This paper proposes a method that allows the number of processes in a service to change by selecting a suitable message sequence chart and switching the operation of each process over from the previous message sequence chart according to a specific procedure. Using this method, conventional synthesizing and verification techniques that deal with services with constant process structure can be applied to services with variant process structure.