Incremental Elaboration of Scenario-Based
Specifications and Behavior Models Using
Implied Scenarios
SEBASTIAN UCHITEL, JEFF KRAMER, and JEFF MAGEE
Department of Computing, Imperial College
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 scenariobased 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.
Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifications—elicitation methods; D.2.2 [Software Engineering]: Design Tools and Techniques—state
diagrams; D.2.4 [Software Engineering]: Software/Program Verification—model checking, validation; F.3.1 [Logics and Meaning of Programs]: specifying and Verifying and Reasoning about
Programs—mechanical verification, specification techniques
This research was supported by the European Union under grant STATUS (1ST-2001-32298) and
EPSRC under grant READS GR/S03270/01.
Authors’ address: Department of Computing, Imperial College, 180 Queen’s Gate, London, SW7
2BZ, UK; email: {s.uchitel,jnm,jk}@doc.ic.ac.uk.
Permission to make digital or hard copies of part or all of this work for personal or classroom use is
granted without fee provided that copies are not made or distributed for profit or direct commercial
advantage and that copies show this notice on the first page or initial screen of a display along
with the full citation. Copyrights for components of this work owned by others than ACM must be
honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers,
to redistribute to lists, or to use any component of this work in other works requires prior specific
permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 1515
Broadway, New York, NY 10036 USA, fax: +1 (212) 869-0481, or permissions@acm.org.
°
C 2004 ACM 1049-331X/04/0100-0037 $5.00
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004, Pages 37–85.
38
•
S. Uchitel et al.
General Terms: Design, Documentation, Languages, Theory, Verification
Additional Key Words and Phrases: MSC, implied scenarios, negative scenarios, LTSA
1. INTRODUCTION
1.1 Motivation
The design of the concurrent and distributed software is a complex task prone
to subtle errors that can have serious consequences [Clarke and Wing 1996].
Behavior models are precise, abstract descriptions of the intended behavior of
a system that can be used to support rigorous analysis and mechanical verification of properties. Effective techniques and tools have been developed for this
purpose and have shown that behavior modeling and analysis are successful in
uncovering the design flaws [Clarke and Wing 1996; Cleaveland and Smolka
1996]. Although there is substantial benefit to be gained in using behavior
models for developing complex system, industry has been slow in assimilating
behavioral modeling and verification technologies. Practitioners are not convinced that the benefit of rigorous and automated analysis justifies the cost of
constructing such models. We believe the reasons for this are twofold. Firstly,
the construction of behavior models remains a difficult task that requires considerable expertise in behavior model notations. Secondly, and perhaps more
importantly, the benefits of behavior analysis appear at the end of the considerable effort of constructing behavior models. Behavior analysis and verification
techniques have been developed under the assumption that a comprehensive
description of the system behavior (up to some level of abstraction) has been
constructed. Thus, they are generally not well suited for providing early feedback on partial system descriptions.
Scenario-based specifications, such as message sequence charts (MSCs) [ITU
1996] and UML sequence diagrams [OMG 2002], are popular as part of requirements specifications. Scenarios describe how system components, the environment and users work concurrently and interact in order to provide system
level functionality. Their simplicity and intuitive graphical representation facilitates stakeholder involvement and makes them popular for conveying and
documenting requirements. Each scenario is a partial description that, when
combined with all other scenarios contributes to the overall system description.
Although scenarios are widely used in industry, their use is mainly informal,
with no precise semantics associated with the scenario description (e.g., [Carrol
1995; Harmon and Watson 1998; Jacobson et al. 1999]). Consequently, analysis techniques and tools have restricted applicability, often limited to syntactic
consistency checks (e.g., Rational [2002]). Of course, there has been work on providing precise semantics to scenario-based specifications (e.g., Heymer [2000],
ITU [1996], Katoen and Lambert [1998], and Reniers [1999]) and developing
semantic analysis tools (e.g., Ben-Abdhallah and Leue [1998], Holzmann et al.
[1997], and Wakahara et al. [1989]). However, the main tendency has been to
view scenario-based specifications no differently than other behavior specification languages. Yet there is a fundamental difference. Scenario specifications
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
39
Fig. 1. A scenario for the Boiler Control system.
naturally result in partial descriptions. They depict a series of examples of
what the system is expected to do. In the best of cases, these examples cover
most common system behaviors and main exceptions. Expecting stakeholders
to produce, in one go, a set of scenarios that covers all possible system traces is
unrealistic, impractical and in general intractable. Thus, existing analysis tools
and techniques developed under the assumption of complete (or even relatively
complete) specifications cannot tackle the partial nature of such specifications.
They do not detect gaps in the specification that, if not elaborated, could result
in costly errors later on in the development process.
The main contribution of this article is a process for incremental behavior
elaboration. The process we present supports elaboration of behavior models in
conjunction with scenario-based specifications that include positive and negative scenarios. Scenario-based specifications and behavior models are complementary and provide alternative views of how system components interact.
Scenario specifications are still maturing with respect to rigorous semantics
and analysis tools, yet have a wide acceptance in industry and are well suited
for preliminary, partial descriptions of system behavior. Behavior models have
not had such a widespread impact on practitioners; nevertheless they boast
an important mathematical foundation, effective tools for behavior analysis,
and have proven success in uncovering flaws in fully developed system models.
There is a need to balance the benefits and the shortcomings.
The key concepts on which our contribution builds on are those of implied
scenarios and realizability. These concepts were first introduced by Alur et al.
[2000], and have led to a significant body of work some of which we discuss in the
Discussion section of this article. The problem underlying the notions of implied
scenarios and realizability relates to other notions such as nonlocal choice [BenAbdhallah and Leue 1997] and has been studied in settings such as procotol
synthesis [Saleh 1996]. We also discuss these relations in the Discussion section
of this article. A key assumption on which our process relies on is that the
scenario-based specifications provided by users determine regular languages.
1.2 Implied Scenarios
Scenario notations such as MSCs (see Figure 1) describe two distinct aspects
of a system. First, they depict a series of examples of what constitutes acceptable system behavior. These examples consist of sequences of messages—called
traces—that system components are expected to send each other. Second, scenario notations outline the high-level architecture of the system. Scenarios
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
40
•
S. Uchitel et al.
Fig. 2. The scenario and behavior model elaboration process.
depict with vertical arrows, or instances, which system components are involved
in providing the intended system behavior. They also describe component interfaces because they illustrate which messages are being sent and received by
each component. In this article, by architecture, we mean the system components and their interfaces.
Implied scenarios indicate gaps in a scenario-based specification that are
the result of specifying the behavior of a system from a global perspective yet
expecting the behavior to be provided in a local component-wise fashion by
independent entities with a local view of the system. If the specified architecture
does not provide components with a rich enough local view of what is happening
at a system level, components may not be able to enforce the intended system
behavior. Effectively, what may occur is that each component may, from its local
perspective, believe that it is behaving correctly, yet from a system perspective
the behavior may not be what is intended. Traces resulting from the inadequate
local view of components are called implied scenarios.
1.3 An Elaboration Process
Given that scenario-based specifications are partial system descriptions, it
would be erroneous to assume implied scenarios necessarily indicate incorrect
behavior. An implied scenario may simply mean that an acceptable scenario
has been overlooked and that the scenario specification needs to be completed.
Adding the implied scenario results in the partial description of system behavior
being extended. Alternatively, the implied scenario may represent unacceptable
behavior and therefore require careful documentation of the undesired situation so that it can be avoided when further elaborating the system specification
and implementation. Ultimately, the decision of whether to accept or reject
an implied scenario depends on the problem domain, and should therefore be
validated by stakeholders. Consequently, by detecting and validating implied
scenarios it is possible to drive the elaboration of scenario-based specifications.
Figure 2 depicts the elaboration process we present in this article. The bottom portion shows the validation of implied scenarios with stakeholders, while
the top portion describes how implied scenarios are detected. The left portion
of the diagram refers to the scenario language used in our approach. We use an
extended MSC language comprised of two parts: a positive part (PSpec) that
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
41
specifies the intended system behavior and a negative part (NSpec) that specifies the behaviors that the system is expected not to exhibit. The semantics of
our MSC language determines a set of traces for each part. We use L(PSpec) and
L(Nspec) to denote the sets of traces determined by the positive and negative
parts of the specification.
From the MSC specification, we synthesize three different behavior models
in the form of labeled transition systems (LTS) [Keller 1976] where transitions
are labeled with the messages that components send to each other. The first
is an architecture model, which is synthesized using the positive system traces,
L(PSpec), and architectural information of the MSC specification. The architecture model (A) is constructed as the parallel composition of components models
A1 , . . . , An where the alphabet of Ai coincides with the interface of component
i (the set of message labels that the instance can send and receive). Thus, we
have A = (A1 k · · · kAn ) where k is the LTS parallel composition operator, and
L(PSpec) ⊆ L(A) where L(A) is the set of maximal traces exhibited by LTS
A (Maximal traces correspond to infinitely long executions of A, or executions
that end in states with no outgoing transitions). In addition, A can be proven to
be the minimal model (with respect to trace inclusion) that complies with the
MSC architecture and that includes all the specified traces (L(PSpec)). Hence,
any behavior exhibited by the architecture model that has not been specified
explicitly in the MSC specification is an implied scenario (i ∈ L(A)\L(PSpec)).
The second behavior model we build is the trace model (T ). This model is
built from the set of positive system traces (L(PSpec)), ignoring the specified
architecture, such that L(T ) = L(PSpec). A key assumption on which this construction relies is that PSpec determines a regular language; more specifically,
it is a bounded [Alur and Yannakakis 1999], finitely generated MSC [Henriksen
et al. 2000]. Details on this are given in the following sections.
The third behavior model we build is the constraint model (C). This is built
from the set of negative system traces (L(NSpec)) so that it captures the complement of the traces the system should not exhibit: L(C) = L(NSpec)−1 .
We are interested in maximal traces that are exhibited by the architecture model (A), that have not been specified in the positive part of the MSC
specification (L(PSpec)) and that have not already been explicitly rejected by
stakeholders and hence included in the negative part of the MSC specification
(L(NSpec)). Thus, we are interested in the following set of implied scenarios:
(L(A)\L(NSpec))\L(PSpec). This amounts to model checking if L(AkC) ⊆ L(T )
holds, which we do using the LTSA tool [Magee and Kramer 1999]. If the
inclusion does not hold the tool produces the prefix of an implied scenario
(i ∈ (L(A)\L(NSpec))\L(PSpec)) up to the point where it deviates from specified
behavior. In fact, it produces a prefix that corresponds to an implied scenario
that deviates from L(PSpec) in the least number of messages. In accordance
with the outcome of implied scenario validation, the positive or negative part
of the scenario specification is updated.
Four artifacts are produced as a result of the incremental elaboration process.
The first is a MSC specification that has been evolved from its original form to
cover further aspects of the concurrent nature of the system being described,
including possible functional aspects. The second is the architecture model,
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
42
•
S. Uchitel et al.
which preserves the system architecture and provides the specified positive
behavior; however, it may exhibit additional unspecified behavior. The third
is the trace model, which captures precisely the traces specified as positive
behavior. The fourth is the constraint model, which captures the properties
that the architecture model should comply with if it is to avoid the negative
scenarios and provide only the specified system behavior.
The architecture model provides the basis for modeling and reasoning about
system design. In fact, it is the model that needs to be further developed through
architectural and design decisions as designers move towards implementation.
The constraint model aids the design process as it models the properties that
the architecture model must satisfy.
Note that our approach focuses on elaboration of system behavior, and in
particular in using implied scenarios to do so. Behavior elaboration could also be
driven by additional concepts such as safety and liveness properties. In addition,
we do not focus on supporting elaboration of the architecture of the system, such
as supporting changes in the system decomposition and component interfaces.
We discuss the limitations of our approach in Section 8.
1.4 Outline of the Article
In this article, we present both the theoretical and practical aspects involved
in using implied scenarios for the elaboration of scenario-based specifications
and behavior models. All aspects are first illustrated using a toy example based
on a Boiler Control system. In Section 2, we present a scenario-based specification language that includes basic and high-level MSCs. We adopt standard
partial order semantics with synchronous component communication for basic
MSCs and standard weak sequential composition for high-level MSCs. We then
discuss architecture models (Section 3), implied scenarios (Section 4) and how
to detect them (Section 5). In Section 6, we motivate and present a negative
scenario notation. With all elements of the process in place, we then present an
in-depth case study (Section 7). In Section 8, we present an extensive discussion
and evaluation that includes related work and our own previous work. Finally,
Section 9 presents the conclusion and related work.
2. MESSAGE SEQUENCE CHARTS
In this section, we describe a message sequence chart (MSC) language. We
introduce a simple example that is used to illustrate our approach. The example
is based on a Boiler Control system where a Control unit operates a Sensor
and an Actuator to control the pressure of a steam boiler. A Database is used
as a repository to buffer Sensor information while the Control unit performs
calculations and sends commands to the Actuator.
The language is a syntactic subset of the International Telecommunication
Union (ITU) standard for MSCs [ITU 1996]. A basic MSC (bMSC) describes
a finite interaction between a set of components (see Figure 1). Each vertical
arrow represents a component and is called an instance. Arrow must be horizontal and represents messages, the arrow source on one instance corresponds
to a message output and its target on a different instance corresponds to a
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
43
message input. We refer to message outputs and inputs as events. In addition,
we use the terms instance and component interchangeably. The formal definition of bMSCs is presented below. Note that a message label uniquely identifies
the sending and receiving component.
Definition 1 (Basic Message Sequence Charts). A basic message sequence
chart (bMSC) is a structure b = (E, L, I, M, instance, label, order) where: E is
a countable set of events that can be partitioned into a set of send and receive
events that we denote send(E) and receive(E). L is a set of message labels. We
use α(b) to denote L. I is a set of instance names. M : send(E) → receive(E)
is a bijection that pairs send and receive events. We refer to the pairs in M
as messages. The function instance: E → I maps every event to the instance
on which the event occurs. Given i ∈ I , we denote {e ∈ E | instance(e) = i}
as i(E). The function label: E → L maps events to labels. We require for all
(e, e0 ) ∈ M that label(e) = label(e0 ), and if (v, v0 ) ∈ M and label(e) = label(v),
then instance(e) = instance(v) and instance(e0 ) = instance(v0 ). order is a set of
total orders ≤i ⊆ i(E) × i(E) with i ∈ I and ≤i corresponding to the top-down
ordering of events on instance i.
The semantics of a bMSC is given by a set of sequences of message labels
or traces. The set of traces of a bMSC is determined by the top-down ordering of events in the chart. Contrary to the ITU interpretation of messages,
where asynchronous communication is assumed, we consider messages to be
synchronous, that is, message send and receive events are blocking. Note that
the introduction of bounded asynchronous communication can be modeled by
introducing buffer abstractions to decouple the message passing.
Definition 2 (Partial Ordering of Events). Given a bMSC (E, L, I, M, instance, label, order) where order is the set of total orders S
≤i , we define the
preorder ≺ ⊆ E × E to be the reflexive-transitive closure of i∈I ≤i ∪M ∪ M −1
and the preorder < ⊆ send(E)× send (E) to be the restriction of ≺ to elements
of send(E).
A bMSC is valid when no message arrows cross each other (this is equivalent
to requiring arrows to be horizontal in the bMSC diagram) and events are not
superimposed at the same point of an instance. This is equivalent to requiring
that the partial ordering < of a bMSC should not have different events mutually
precede each other (if e 6= e0 , then not (e0 < e and e0 < e)). In the remainder of
this article, we assume all bMSCs are valid.
As communication is considered synchronous, we can consider send and receive events of the same message to occur simultaneously. Thus, in the semantics, we can restrict the partial order to only send-events. In the case of Figure 1,
the bMSC semantics determines a set of two traces: <on, pressure, pressure,
query, data, command, pressure, off> and <on, pressure, pressure, query, data,
pressure, command, off>. Note that the difference between the two traces is
that the command message and the last pressure message appear in different
order. This is because their send events are not causally related in the scenario’s
partial ordering of events. According to the definitions, both must occur after
the sending (and receiving) of message data but before sending (and receiving)
message off.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
44
•
S. Uchitel et al.
Fig. 3. MSC specification for the Boiler Control system.
Definition 3 (Linearizations). Let b = (E, L, I, M , instance, label, order) be
a bMSC and < its partial ordering of events. A word l 1 , l 2 , . . . over the alphabet
L is a linearization of b only if there is a total ordering s1 , s2 , . . . of send(E) such
that si < s j implies i < j and label(si ) = l i for 0 ≤ i, j ≤ |send(E)|.
Definition 4 (bMSC Semantics). Given a bMSC b, we define the language
of b as a set L(b) of traces where L(b) = {w | w is a linearization of b}.
A high-level MSC (hMSC) provides the means for composing bMSCs. It is a
directed graph where nodes represent bMSCs and edges indicate their possible
continuations (see bottom right of Figure 3). hMSCs also have an initial node,
which is indicated using an arrow with a black filled circle as its tail. The ITU
standard includes hMSCs and permits hierarchies by allowing nodes to refer
to a new hMSC. To simplify this presentation, we have omitted this feature;
however, it could be introduced to our approach.
Definition 5 (High-Level Message Sequence Charts). A high-level message
sequence chart (hMSC) is a graph of the form (N , E, so ) where N is a set of
nodes, E ⊆ (N × N ) is a set of edges, and s0 ∈ N is the initial node. We say
that n is adjacent to n0 if (n, n0 ) ∈ E. A (possibly infinite) sequence of nodes
w = n0 , n1 , . . . is a path if n0 = s0 , and ni is adjacent to ni+1 for 0 ≤ i < |w|. We
say a path is maximal if it is not a proper prefix of any other path.
We can now define positive MSC specifications; we refer to them as positive
so as to distinguish them from negative scenarios, which are introduced later
in Section 6. Positive MSC specifications consist of a set of bMSCs, a hMSC
and a function that maps every node in the hMSC to a bMSC. For simplicity,
we assume that all bMSCs have the same set of instances and that messages
are used consistently throughout them. In addition, we assume the mapping
from hMSC nodes to bMSCs to be bijective. Thus, several nodes referring to the
same bMSC are represented with several copies of the same bMSC, and each
node referring to an individual copy. This allows us to simplify by referring to
bMSCs instead of the nodes that are mapped to them. All these assumptions do
not reduce the generality of our results and help to simplify our presentation.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
45
Fig. 4. Weak sequential composition of bMSCs Analysis and Register.
Definition 6 (Positive Message Sequence Chart Specifications). A positive
message sequence chart (MSC) specification is a structure PSpec = (B, H, f )
where B is a set of bMSCs, H = (N , A, s0 ) is a hMSC, and f : N → B is
a bijective function that maps hMSC nodes to bMSCs. We use α(PSpec) =
{l | ∃b ∈ B. l ∈ α(b)} to denote the alphabet of the specification.
The semantics of a positive MSC specification is given, as for bMSCs, by a
set of traces. The hMSC together with the mapping of nodes to bMSCs shows
how the system can evolve from one scenario to another. There are two possible
interpretations of this evolution. The first is to assume that all components wait
until all events of a bMSC have occurred before moving on to the next bMSC.
This implies that there is some form of implicit synchronization that components use in order to know when a scenario has been completed. As MSCs are
a notation for making explicit how components interact to provide system level
functionality, we take the position that assuming implicit synchronization is
not appropriate. We adopt the second and more accepted approach to hMSC
semantics in which components move into subsequent scenarios in an unsynchronized fashion. This interpretation is referred to as using weak sequential
composition, and is the one adopted by the ITU [1996], among others. Note
that weak sequential composition is not a cause for implied scenarios. Strong
sequential composition could also be adopted and both the concept of implied
scenarios and the elaboration process would still hold. See Section 8.1 for more
details.
Definition 7 (Weak Sequential Composition of bMSCs). The weak sequential composition of two bMSCs b = (E, L, I, M , instance, label, order) and
b0 = (E 0 , L0 , I 0 , M 0 , instance 0 , label 0 , order 0 ) with disjoint sets of events is denoted (b• b0 ) and is defined by the bMSC (E ⊕ E 0 , L ∪ L0 , I ∪ I 0 , M ∪ M 0 , instance
∪ instance0 , label ∪ label0 , order• ), where ⊕ is disjoin union, and order• is the
set of total orders ≤•i such that e ≤•i e0 if and only if e ≤i e0 or e ≤0i e0 or (e ∈ i(E)
and e0 ∈ i(E 0 )).
For example, the bMSCs Analysis • Register (see Figure 4) determines two
possible traces: <query, data, command, pressure> and <query, data, pressure,
command>. Note that, in the latter, even though pressure is from the second
bMSC of the sequential composition, it occurs before command, which is from
the first bMSC of the sequential composition. This occurs because message
pressure is independent of command, that is, there is no causal relation between
the send events of these messages in (Analysis • Register). This is not surprising
as the messages involve different components, and as there are no explicit
synchronization mechanisms to enforce a particular ordering of these messages,
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
46
•
S. Uchitel et al.
any interleaving can occur. If strong sequential composition semantics were
used, command would be forced to occur before pressure. As explained before,
we believe this interpretation would be counterproductive, as it would assume
an implicit synchronization between components.
The traces determined by a positive MSC specification are those of any sequential composition of bMSCs according to a maximal path in the specification’s hMSC.
Definition 8 (Maximal bMSCs). Let PSpec = (B, H, f ) be a positive MSC
specification. We say that b is a maximal bMSC in PSpec if there is a maximal
path n1 , n2 , . . . in H such that b = f (n1 ) • f (n2 ) • · · · .
Definition 9 (Positive MSC Specification Semantics). Let PSpec be a positive MSC specification with a set of instances I . We define the behavior or
language of PSpec as a set L(PSpec) of traces, where L(PSpec) = {w ∈ L(b) | b
is a maximal bMSC of PSpec}.
Note that the semantics we use is trace-based. This differs from many other
approaches that use state-machine-based semantics (e.g., the ITU approach
[ITU 1996]). We discuss the significance of this difference at the end of this
article.
In summary, this section has defined a scenario-based language using MSC
syntax. This language has a trace-based semantics and can be used to (possibly
partially) describe the intended behavior of a system. In later sections of this
article, we extend the MSC notation to include negative scenarios for describing
behavior that a system is expected to prohibit. In terms of the process overview
depicted in Figure 2, we have so far presented the elements PSpec and L(PSpec)
at the top left corner.
3. ARCHITECTURE MODELS
3.1 Definitions
A MSC specification not only determines a set of acceptable system traces, it
also defines the intended architecture of the system. By architecture, we refer
to the components that implement system functionality and their interfaces,
that is, the messages they can send to and receive from other components. The
architectural description can be found in bMSCs, where instances model the
system components and the messages each instance sends and receives define
the component’s interface.
Definition 10 (Interfaces and Alphabets). Let PSpec = (B, H, f ) be a positive MSC specification with instances I , and let i ∈ I be an instance. The
interface of i is the set of message labels α(i) = {l | ∃b = (E, L, I, M , instance,
label, order) ∈ B and ∃e ∈ E such that label(e) = l and instance(e) = i}. We also
refer to the interface of i as its alphabet.
The construction of a model that complies with the architecture defined by a
positive MSC specification and that provides the behavior specified by the same
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
47
specification is a relevant issue. In this section, we show how this can be done
and explain to what degree these models comply with the original specification.
Labeled transitions systems (LTS) [Keller 1976] provide a suitable formalism
to model both the components and the systems described by MSC specifications.
Specifically, transitions are labeled with bMSC message labels, LTS processes
model system components and parallel composition of LTSs (based on the k composition operator used in CSP [Hoare 1985]) is used to define a system resulting
from several interacting components. The intuition behind parallel composition
of LTSs is that it defines a system that results from composing components such
that they execute asynchronously but synchronize on all shared message labels.
The formal definitions we now present have been adapted from Cheung [1994]
and Giannakopoulou [1999].
Definition 11 (Labeled Transition Systems). Let States be the universal set
of states where state π is the error state. Let Labels be the universal set of
message labels and Labelsτ = Labels ∪ {τ } where τ denotes an internal component action that is unobservable to other components. A LTS P is a structure (S, L, 1, q) where S ⊆ States is a finite set of states, L = α(P ) ∪ {τ },
α(P ) ⊆ Labels is a set of labels that denotes the communicating alphabet of
P, 1 ⊆ (S\{π } × L × S) defines the labeled transitions between states, and
l
q ∈ S is the initial state. We use s −→ s0 to denote (s, l , s0 ) ∈ 1. In addition, we
l
l
say that a LTS P is deterministic if s −→ s1 and s −→ s2 implies s1 = s2 .
Definition 12 (Parallel Composition of LTS). Let P1 and P2 be LTSs where
Pi = (Si , Li , 1i , qi ). Their parallel composition is denoted P1 kP2 and is an LTS
(S, L, 1, q) where S = S1 × S2 ∪ {π, ε}, L = L1 ∪ L2 , q = (q1 , q2 ), and 1 is the
smallest relation in (S\{π}) × L × S that satisfies the following rules where
a
x −→i y denotes (x, a, y) ∈ 1i :
a
a
s −→1 t
a
(s, s0 ) −→ (t, s0 )
a
(a ∈
/ α(L2 ))
s −→2 t
a
(s0 , s) −→ (s0 , t)
(a ∈
/ α(L1 ))
a
s −→1 ts0 −→2 t 0
a
(s, s0 ) −→ (t, t 0 )
(a ∈ (α(L1 ) ∩ α(L2 ))\{τ }).
The only exceptions to these rules are that we use state π instead of states
(x, π) and (π, x) for all x ∈ States. These exceptions mean that the composite LTS
reaches an error state if any of the composed LTSs do so. Note that the definition
of LTS includes a special message label τ . This label models an internal action
that is not observable to other LTSs. This is why the parallel composition does
not force synchronization on transitions labeled with τ . In addition, note that
parallel composition is both commutative and associative. Consequently, we
note parallel composition of multiple LTSs as follows: P1 k · · · kPn .
Given a LTS, we wish to compare the behavior it models with the behavior
of a positive MSC specification. Thus, we introduce the notion of maximal trace
for LTSs:
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
48
•
S. Uchitel et al.
Definition 13 (Executions). Let P = (S, L, 1, q) be a LTS. An execution of
P is a sequence w = q0l 0 q1l 1 · · · of states qi and labels l i ∈ L such that q0 = q
li
and qi −→ qi+1 for all 0 ≤ i < |w/2|. An execution is maximal if it cannot be
extended to still be an execution of the LTS. We also define ex(P ) = {w | w is an
execution of P }.
Definition 14 (Projection). Let w be a word w0 w1 w2 w3 · · · and A an alphabet. The projection of w onto A, which we denote w| A , is the result of eliminating
from the word w all elements wi in A.
Definition 15 (Traces and Maximal Traces). Let P be a LTS. A word w over
the alphabet α(P ) is a (maximal) trace of P if there is an (maximal) execution e ∈
ex(P ) such that w = e|α(P ) . We use tr(e) to denote the projection of an execution
on the alphabet of a LTS. We also define tr(P ) = {w | w is a trace of P } and
L(P ) = {w | w is a maximal trace of P }.
We now introduce the notion of architecture model. As commented before,
we wish to build a model that complies with the description given by a positive
MSC specification. This means building a model that takes into account both
the architecture and the behavior described by the MSC specification. Thus,
the model should be the parallel composition of a collection of LTSs, where
each LTS models a component in the MSC specification. Furthermore, the LTS
modeling a component of the MSC specification should have its corresponding
interface, which means that the alphabet of the LTS should coincide with that
of the component it models. Finally, the composite system model should be able
to exhibit all the traces described in the MSC specification. LTS models that
preserve the component structure and component interfaces while exhibiting
all specified traces are called architecture models.
Definition 16 (Architecture Models). Let PSpec = (B, H, f ) be a positive
MSC specification with instances I , and let Ai with i ∈ I be LTSs. We say that an
LTS A is an architecture model of PSpec only if A = (A1 k · · · kAn ), α(Ai ) = α(i),
and L(PSpec) ⊆ L(A).
For the Boiler Control system of Figure 4, an architecture model is one
which is the result of composing in parallel four LTSs: One with alphabet with
{pressure, on, off} modeling the Sensor component, another with alphabet {data,
query, pressure} modeling the Database component, a third modeling the Control component with alphabet {on, off, query, data, command} and a fourth
model for the Actuator component with alphabet {command}. In addition, all
traces defined by the semantics of the MSC specification must be maximal
traces of the composition of these four LTSs.
This notion of an architecture model is weak in that it permits additional
unspecified behavior. The interpretation is consistent with the fact that scenario specifications are partial descriptions, where typically only a subset of
significant system traces has been explicitly specified. In addition, as we see
later, strengthening the condition L(PSpec) ⊆ L(A) to L(PSpec) = L(A) would
result in MSC specifications with no architecture models.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
49
Fig. 5. Behavior of Control component in bMSC Analysis.
Fig. 6. Composition of Control’s behavior in all bMSCs.
3.2 Synthesis
We now discuss how architecture models are built from MSC specifications. In
particular, we describe the algorithm for building component models, that is, a
LTS for a component specified in a positive MSC specification. If all component
models are built using this algorithm, their parallel composition can be shown
to be an architecture model of the MSC specification.
The algorithm works by translating an MSC specification into a behavior
model specification in the form of Finite Sequential Processes (FSP) [Magee and
Kramer 1999]. FSP semantics is given in terms of LTSs. In order to simplify
this presentation, rather than describing the algorithm in terms of the FSP
it builds, we describe the LTSs determined by the FSP that is synthesized.
The algorithm synthesizes one component model at a time. We illustrate it by
explaining how it builds the LTS for the Control component of Figure 3.
Given a positive MSC specification and a component to be synthesized, the
algorithm constructs a deterministic LTS that has the same traces as the projection of the MSC behavior on the alphabet of the component. First, the algorithm
builds one LTS for each bMSC in the specification. Each of these LTSs exhibits
the same behavior as exhibited by the component in the bMSC. For instance,
the algorithm builds the LTS of Figure 5 to model the behavior of the Control component in bMSC Analysis. The numbers depicted in the states have no
particular meaning; they are simply references that permit reference to states,
facilitating explanations involving the LTS.
As one LTS for each bMSC is built, the algorithm must combine all these
processes to model the behavior of the component as it traverses the hMSC.
Thus, the second step of the algorithm is to link the LTSs according to the hMSC.
LTSs are linked by adding transitions labeled with intAction. For instance, the
last state of the LTS that corresponds to bMSC Analysis is linked to the first
state of the LTS modeling the Register bMSC. The LTS resulting from linking
the LTSs for all bMSCs in which Control participates is shown in Figure 6.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
50
•
S. Uchitel et al.
Fig. 7. Component model for Control.
Fig. 8. Component model for Database.
Fig. 9. Architecture model of the Boiler Control system.
The third is to make intAction unobservable and to minimize. Making
intAction unobservable involves replacing all its appearances with the internal action τ . This is called hiding and is denoted P \A where P is a LTS and A
is the set of actions being hidden (i.e., replaced by τ ).
The last step is to make the resulting LTS deterministic and minimize it
while preserving the maximal traces that it specifies. For the Control component, the final LTS is depicted in Figure 7.
Note that the synthesis algorithm described above behaves slightly differently when processing a specification with bMSCs that have no adjacent nodes
in the hMSC. In these cases, we use the auxiliary transition label endAction
to prevent the minimization algorithm from losing maximal traces. Hence, the
final step in building the component model is to hide the label endAction.
The algorithm described above must be applied to all components appearing in the MSC specification (see another example in Figure 8). Once in LTS
for each component has been synthesized, the complete system is their parallel composition. In the case of the Boiler Control system, the final architecture model is the parallel composition of component LTSs corresponding
to Control, Sensor, Database, and Actuator The composite LTS is depicted in
Figure 9.
From the following two lemmas, it is straightforward to show that the model
synthesized from a positive MSC specification using the algorithm presented
above is an architecture model of the input specification. A detailed proof can
be found in Uchitel [2003].
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
51
LEMMA 1. Let PSpec be a positive MSC specification. If A = (A1 k · · · kAn ) is
the synthesized architecture model of PSpec, then L(PSpec)|α(i) = L(Ai ).
LEMMA 2. If P1 · · · Pn are LTSs and w|α(i) ∈ L(Pi ) for all 1 ≤ i ≤ n, then
w ∈ L(P1 k · · · kPn ).
THEOREM 1. If A is the model resulting from applying the architecture model
synthesis procedure to a positive MSC specification PSpec, then A is an architecture model of PSpec.
Furthermore, we can also show that the synthesized architecture model is
minimal with respect to trace inclusion (refer to Uchitel [2003] for proofs).
Property 1. If A is the synthesized architecture model of positive MSC specification PSpec, then for any architecture model A0 , we have tr(A) ⊆ tr(A0 ).
In summary, with reference to the process overview in Figure 2, we have
now described its top portion: the positive scenario specification PSpec, the set
of traces defined by its semantics (L(PSpec)) and the architecture it defines.
We have shown how the architecture model synthesis algorithm builds a model
A = (A1 k · · · kAn ) such that L(PSpec) ⊆ L(A) and that it is minimal with respect
to trace inclusion.
4. IMPLIED SCENARIOS
In the previous section, we introduced the notion of an architecture model. Instead of requiring architecture models to provide the traces described in the
MSC specification exactly, we required only trace inclusion (L(PSpec) ⊆ L(A)).
As mentioned before, this is a reasonable notion considering that scenario specifications are inherently partial descriptions.
It is interesting to study how close an architecture model can be to the behavior explicitly described in a positive MSC specification. Is it possible to construct
an architecture model that captures exactly the specified behavior? It turns out
that, in some cases, this is not possible; that, for some MSC specifications,
all architecture models of the specification exhibit traces that have not been
specified in the MSC specification. Moreover, as we shall see, these traces are
particularly interesting as they uncover important gaps of the partial system
description that should be elaborated. In this section, we explain why these
situations occur and define the notion of an implied scenario. Subsequently, we
show how implied scenarios can be detected.
Applying the synthesis algorithm presented above, we can construct a FSP
model for the MSC specification of Figure 3. Once the FSP specification is fed
into the LTSA tool, we can animate our model to see how it behaves. In Figure 10,
we show a trace (using the bMSC syntax for clarity), which can be executed in
our system model. The trace shows how the Control component is accessing the
Database and receiving information from a previous activation of the Sensor.
This is clearly not specified behavior; there is no trace in the language defined
by of our MSC specification that has a prefix as shown in Figure 10. The MSC
specification states that, after initializing Sensor, there must be some data
registered into the Database before any queries can be done. Note that as the
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
52
•
S. Uchitel et al.
Fig. 10. First implied scenario of the Boiler Control system.
pressure message and the query message involve the Database, the trace of
Figure 10 cannot be a result of the interleaving of messages in some maximal
bMSC determined by the high-level MSC of Figure 3.
This means that our architecture model is introducing nonspecified system
behavior. We could try to build another architecture model that does not include
this trace. However, we have shown that the synthesized model is minimal
with respect to trace inclusion. Thus, we must conclude that the unspecified
trace of Figure 10 appears in all architecture models of the MSC specification.
How is this possible? This clearly concerns the requirement that architecture
models preserve the system’s component structure and component interfaces.
If we analyze the MSC specification from an architectural point of view, we
can see that what is happening is reasonable: the Control component cannot
observe when the Sensor has registered data in the Database; thus, if it is to
query the Database after data has been registered at least once, it must rely
on the Database to enable and disable queries when appropriate. However, as
the Database cannot tell when the Sensor has been turned on or off, it cannot
distinguish a first registration of data from others. Thus, it cannot enable and
disable queries appropriately. Succinctly, components do not have enough local
information to prevent the system execution shown in Figure 10. Note that each
component is behaving correctly from its local point of view, that is, it is behaving in accordance with some valid sequence of bMSCs. The problem is that each
component is following a different sequence of bMSCs! The Sensor, Control and
Actuator are going through scenarios Initialize, Register, Terminate, Initialize,
Analysis, and Register. However, the Database is performing Initialize, Register, Analysis, and Register. We use the term implied scenario (taken from Alur
et al. [2000], see section on related work) to refer to system executions such
as the one shown in Figure 10. In the definition below, we use “*” to denote the
operation that given a set of symbols produces the set of all strings over that
set.
Definition 17 (Implied Scenarios). Given a positive MSC specification
PSpec, a trace w ∈
/ L(PSpec) is an implied scenario of Spec if for all trace y
and for all architecture model A of Pspec, w. y ∈ L(A) implies w. y ∈
/ L(PSpec).
Property 2 (Implied Scenarios). If PSpec is a positive MSC specification
and a A is a minimal architecture model of PSpec, then PSpec has implied
scenarios if and only if L(A) 6⊂ L(PSpec).
In addition, we say that MSC specification is realizable (also taken from Alur
et al. [2000]) if the specification has no implied scenarios, or in other words, that
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
53
there is an architecture model that exhibits exactly the traces defined by the
MSC.
Definition 18 (Realizability). Let PSpec be a positive MSC specification,
and A an architecture behavior model of PSpec. A is a realization of PSpec if
L(PSpec) = L(A). We say that a PSpec is realizable if there is a realization of
PSpec.
An important observation on implied scenarios is that they are not an artifact of a particular language or semantics. For instance, implied scenarios can
occur when using strong sequential composition for MSC semantics. Implied
scenarios are the result of specifying the behavior of a system from a global
perspective that is to be provided by independent, interacting components that
have restricted local views. If the system architecture does not provide components with enough local information, they may not be able to avoid unspecified
system behavior, even if the are behaving correctly in terms of local behavior.
Note that weak sequential composition of bMSCs is not a cause for implied
scenarios. We discuss the nature of implied scenarios more extensively in the
Discussion and Related Work (Section 8).
Implied scenarios are not necessarily unwanted situations. They can simply
be acceptable scenarios that have been overlooked by stakeholders. This is not
surprising as scenario-based specifications are inherently partial. It is reasonable to assume that stakeholders do not provide a complete set of examples of
how the system is expected to behave. In this case, the implied scenario should
be added to the specification in order to extend it covering a case that had not
been explicitly described in the original system description. It is also possible,
however, that the implied scenario does represent unwanted system behavior.
In this case, careful documentation is needed so as to ensure that design decisions are taken at some point to prevent the scenario from happening. We
return to this in subsequent sections.
Consequently, implied scenarios should be taken to stakeholders for validation. By doing so, the MSC specification can be iteratively elaborated. An important comment is that implied scenarios expose subtle mismatches between
the architecture and behavior. Even in a toy example such as the Boiler Control system, the implied scenario we have discussed cannot be detected trivially
by observing the specification. Thus, there is great value in automatically detecting and validating implied scenarios as they force stakeholders to address
subtle yet crucial points regarding the concurrent nature of the system they
are specifying.
This section has defined implied scenarios. In terms of the overview depicted
in Figure 2, we have introduced the arrow on the bottom right corner. However,
we have yet to discuss implied scenarios in the context of negative scenarios.
5. IMPLIED SCENARIO DETECTION
We have shown how an architecture model can be constructed from a positive
MSC specification. We have also shown that it is possible for this model to
exhibit implied scenarios, and commented on how these can help elaborate
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
54
•
S. Uchitel et al.
MSC specifications if detected and validated with stakeholders. Consequently,
detecting implied scenarios is an important issue.
Our approach to implied scenario detection is conceptually very simple. We
know how to construct an architecture model and that this model includes all
specified traces and is minimal with respect to trace inclusion. If we build a
model that captures exactly the set of traces defined by the MSC semantics—
the trace model—we could compare its traces with those of the minimal architecture model. Any trace in the latter that is not a trace of the new model would
then correspond to an implied scenario. Of course, to build a precise model of the
specified traces we would have to ignore the architectural requirements specified in the scenario. In addition, such a (finite) model would only be possible
if the MSC behavior corresponds to a regular language [Ullman and Hopcroft
1979], which is not always the case.
Definition 19 (Regular MSC Specifications). A MSC specification Spec is
said to be regular if L(Spec) is a regular language. Otherwise, Spec is said
to be nonregular.
Nonregular MSCs are not realizable: there is no finite LTS that can model
the language, thus, there can be no set of finite LTS such that their composition
models it either. Fortunately, there are decision procedures that can be used
to check if a MSC specification as defined in previous sections determines a
regular language. It can be shown that the languages determined by our MSC
specifications are finitely generated MSC languages [Henriksen et al. 2000].
Thus, from Lemma 4.2 and 4.3 of Henriksen et al. [2000], the problem of checking if our MSC specification is regular is equivalent to checking that the MSC is
bounded. The notion of bounded MSCs was introduced in Alur and Yannakakis
[1999] which is defined in terms of the communication graph of a set of bMSCs.
In our setting, a communication graph for a set of bMSCs would have a node
for each component; the set of arcs would be the transitive closure of the set of
arcs defined by the fact that two components communicate over a message in
some bMSC of the set. The boundedness condition states that for any cycle in
the hMSC, the communication graph for the bMSCs in that cycle determines
one nonempty set of fully connected components. For an example of unbounded
hMSC, see Uchitel [2003]. In the rest of this article, we assume bounded MSC
specifications. We now explain how we build a model of the intended system
behavior from such positive MSC specifications.
5.1 Trace Models
One of the difficulties of building a LTS model that captures the specified traces
of a positive MSC specification is that such model cannot be constructed compositionally from the bMSCs appearing in the MSC specification. This is because
of the weak sequential composition used in hMSC semantics. Components may
move asynchronously from one bMSC to another, thus a message from a bMSC
that appears before another bMSC in a maximal path of the hMSC is not guaranteed to occur before the messages of the latter bMSC.
Our approach is to build a set of component LTS models that extend (in
terms of architectural capabilities) those described in the MSC specification.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
55
The extension is that components must request permission to a Coordinator
component before moving from one bMSC to another. In addition, we build
a Coordinator that enables and disables component entry requests to bMSCs
guaranteeing that components do not follow different sequences of bMSCs.
It is important to note that, in this section, we define a model that is not an architecture model. First, we have added a component into the system that has not
been specified in the MSC specification: the Coordinator. Second, the LTS models for components appearing in MSC specifications have an extended alphabet
that includes labels that do not appear in the MSC specification. Note that it is
not our intention to propose a refined architecture or design solution that avoids
implied scenarios. This would be incorrect, as it would be assume that implied
scenarios are unwanted system traces. This is not necessarily so. Our intention
is to build an artifact that allows us to detect implied scenarios by comparing
its traces against those of a minimal architecture model.
The reason we choose the Coordinator approach is that it is possible to show
that all implied scenarios exhibited by an architecture model are the result of
components exhibiting behaviors described by different paths in the hMSC. In
other words, the behavior of each component is correct with respect to its local
view of what is occurring in the system.
PROPOSITION 1. If w is an implied scenario of MSC PSpec, then, for each
instance i, there is a maximal bMSC bi such that w|α(i) ∈ L(bi )|α(i) .
If w is an implied scenario of PSpec, and A = A1 k · · · kAn is an architecture
model for PSpec, then w ∈ L(A). From Lemma 1, we have L(PSpec)|α(i) = L(Ai )
for each instance i. This means that there must be a maximal bMSC bi such
that w|α(i) ∈ L(bi )|α(i) . However, because w is an implied scenario of PSpec, there
can be no maximal bMSC b such that w ∈ L(b). Hence, the following holds
w|α(i) ∈ L(bi )|α(i) for each instance i, but there are at least two maximal bMSCs
bi and bi’ that are different maximal bMSCs. In summary, the implied scenario
is the result of at least two different instances following different maximal
bMSCs.
Consequently, if we build components and coordinate them in such a way that
they all go through the same hMSC path, implied scenarios will be avoided. We
now show how this can be done.
In the previous section we presented a synthesis algorithm that builds LTS
models for each component appearing in a positive MSC specification. The LTS
models we now build are an extension of those; we call them extended component models. Instead of using an internal action for linking component behaviors corresponding to each bMSC, we use a coordination action. Coordination
actions are labeled with a component name and a bMSC name, and model the
request of the component to enter the bMSC. For component Control the coordination actions that we use are Control.Initialise, Control.Register,
Control.Analysis, Control.Terminate. Figure 11 depicts the final behavior
of the extended Control component.
It is clear that that the behavior resulting from hiding coordination actions
in an extended component Ei is trace equivalent to that of the component model
synthesized for the architecture model. Thus, the above proposition motivates
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
56
•
S. Uchitel et al.
Fig. 11. Extended Control with coordination actions.
construction of a Coordinator component Coord that synchronizes on component coordination actions and forces components to follow the same maximal
bMSC. The resulting system, (E1 k · · · kEn kCoord), restricted to the MSC alphabet does not exhibit any implied scenarios; it is an exact model of the specified
MSC traces. In summary, we use a Coordinator component that keeps track
of the path (maximal bMSC) being taken by the leading component and that
forces all other components lagging behind to follow the same path. We now
define such a Coordinator.
Intuitively, the Coordinator state space consists of states that model a path
in the hMSC and the position of each component in that path. However, there
is no need to keep track of the whole path followed by components (which is
fortunate, as the path is potentially infinite). It suffices to record the bMSCs the
leading component has gone through and which the components further behind
have not yet reached. The sequence can be thought as the destiny of the component that is furthest behind and that is being decided by the component that is
furthest in front. For example, the state (2, 2, 3, 1, Initialize.Register.Analysis)
corresponds to the Boiler Control System state where components Sensor,
Database are in bMSC Register, Control is in bMSC Analysis while Actuator
is in bMSC Initialize and has not requested the Coordinator for permission to
move into Register. In this state, the action s Sensor Register that models the
Sensor component requesting permission to enter bMSC Register would not be
enabled as Sensor must follow the leading component into bMSC Analysis. We
do not provide the formal definitions of the Coordinator or its finite version. For
a detailed discussion, refer to Uchitel [2003].
Given an MSC specification, we can construct extended components and a
finite coordinator from it, and compose them in parallel. We can then hide the
coordination actions in the composite model and obtain a model with the same
alphabet as the original MSC specification. We call this model the trace model.
Definition 20 (Trace Models). Let PSpec be a positive MSC specification,
E 1 , . . . , En the set of synthesized extended components from PSpec and H
is the set of all coordination actions. We define the trace model of PSpec as
(E1 k · · · kEn kCoordf )\H.
From the definition of extended components and that of the finite coordinator,
it can be shown that the trace model of a MSC specification has the same traces
as those defined by the MSC specification. For a proof of this result, refer to
Uchitel [2003]. In Figure 12, we depict the trace model of for the Boiler Control
system.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
57
Fig. 12. Trace model for the Boiler Control system.
Fig. 13. Implied Scenario detected by LTSA.
THEOREM 2. Let PSpec be a positive MSC specification, E1 , . . . , En the
set of synthesized extended components from PSpec and H is the set of
all coordination actions. If Coordf is a finite Coordinator of PSpec, then
L((E1 k · · · kEn kCoordf )\H) = L(PSpec).
5.2 Implied Scenario Detection Using LTSA
As discussed previously, to detect implied scenarios, we now need to check
L(A) ⊆ L((E1 k · · · kEn kCoordf )\H). We know how to build an FSP representation of both the trace model and the minimal architecture model; thus, we
can use LTSA to check trace inclusion. To do this, we declare the trace model
as a safety property and perform a safety check on the architecture model to
see if it satisfies the property. Safety properties, in LTSA, are created using
the property keyword. This extends a LTS with an error state e, and for every
state s and every label l , adds a transition labeled l from s to e if l was not
enabled in s. The safety property must then be composed in parallel with the
model to be checked. The error state is reachable from the initial state if and
only if the safety property is violated. Note that the safety check verifies that
tr(A) ⊆ tr((E 1 k · · · kEn kCoordf )\H). In addition, it is straightforward to prove
that if the model has no deadlocks, then we also have L(A) ⊆ L((E1 k · · · kEn k
Coordf )\H).
When performing a safety check, LTSA checks if the error state is reachable and also if there are deadlocks. Thus, a safety check on ImpliedScenario
Property either confirms that there are no implied scenarios or produces an
implied scenario. Furthermore, in the case of a safety violation, as opposed to
deadlock detection, the last message label of the implied scenario is the first
message that corresponds to unspecified behavior. This point in the implied
scenario is where the architecture model deviates from specified behavior.
In the Boiler Control System, the LTSA output indicating that an implied
scenario exists is shown in Figure 13. It corresponds to the implied scenario we
have been discussing in previous sections (see Figure 10).
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
58
•
S. Uchitel et al.
5.3 Coordinator State Space Reduction
In Section 5.1, we discussed how to build a model of the MSC behavior using
a Coordinator. Although the state space of the Coordinator we have defined is
finite, it can be extremely large. The size of the state space is in the order of
(CB)C where B is the number of basic MSC and C the number of components.
The size of the state space can be explained as follows: the equivalence relation
allows the elimination of a loop from the sequence of bMSCs in a state if there
is no component currently in the loop. The worst case is that the bMSCs form
one big loop of length B and components are positioned in such a way that every
component is in a different iteration of the loop. As there are C components, the
maximum length of the sequence of bMSCs is in the order of CB. In addition,
each component can be in a different position in the sequence of bMSC, thus
the resulting state space is of size (CB)C .
The size of the Coordinator state space is large, in part, due to the fact that
we are constructing the Coordinator taking into account very little information
from bMSCs. In other words, our Coordinator accepts combinations of requests
to enter bMSCs that never occur. This is because the interactions between
components in order to complete bMSCs and move on prevent certain sequences
of coordination actions from occurring. Consequently, it is possible to trim the
size of the Coordinator considerably introducing some heuristics that take into
account the dependencies between components in bMSCs.
In this article, we are concerned with showing how implied scenarios can be
used to evolve scenario-based specifications and behavior models. We therefore
do not discuss the issue of coordinator state space size and heuristics to reduce
it. The interested reader can refer to Uchitel et al. [2002b] where we present a
series of heuristics that, for some examples, can achieve up to 90% reduction
in the reachable coordinator state space.
In summary, in terms of Figure 2, we have now described the middle section
by showing how from a positive scenario specification (PSpec), using the traces
it defines (L(PSpec)), a trace model can be built (T = (E1 k · · · kE1 kCoordf )\H)
such that it describes exactly the specified traces (L(T ) = L(PSpec)). We have
also shown how to detect implied scenarios by model checking (L(A) ⊆ L(T )).
We now go on to talk about negative scenarios, constraint models and how
we can continue to validate implied scenarios in the presence of negative
scenarios.
6. NEGATIVE SCENARIOS
In this section, we create the need for documenting implied scenarios that are
deemed unacceptable system behavior by stakeholders. We introduce a negative
scenario as a notation for documenting these rejections and discuss how implied
scenarios can be detected in the presence of negative scenarios. In fact, we
provide three kinds of negative scenario. The first is a very simple notation
that allows stakeholders to rapidly reject implied scenarios, in a push button
style, and to continue checking for more implied scenarios. The other two are
more expressive notations that are needed to take the MSC specification to a
state where all implied scenarios have been validated.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
59
Fig. 14. A basic negative scenario.
6.1 Basic Negative Scenarios
Let us suppose that the implied scenario of Figure 10 is taken back to stakeholders for validation. In addition, suppose that stakeholders understand that
a query is retrieving old information from the Database because the last pressure reading is from a previous Sensor session. Consequently, they decide that
the implied scenario is unacceptable system behavior.
A first reaction could be to require stakeholders to review the MSC specification they have provided and to correct it so as to avoid the mismatch that
gives rise to the implied scenario. However, the only way to avoid the implied
scenario is through design. Stakeholders would have to contrive mechanisms,
such as additional synchronization messages and/or new components, to prevent the implied scenario from occurring. This approach is unsatisfactory for
a number of reasons. Stakeholders may lack the technical skills to make such
design decisions; taking such design decisions at an early requirement stage
may be undesirable; and finally, having to stop the process of model elaboration
to solve design issues may be inopportune.
We believe that documenting rejected implied scenarios and then producing
more feedback in terms of implied scenarios can make the elaboration process
more dynamic. In addition, it would allow explicit documentation of undesired
situations as opposed to doing so implicitly by providing a design solution.
Thus, we extend the notions discussed in previous sections to include negative
scenarios, a notation for documenting behavior that the system is expected to
prohibit. We now define a simple form of negative scenario and explain how to
detect implied scenarios when this form of negative scenarios is used.
We depict basic negative scenarios as bMSCs with three additional characteristics. The first is that the last message is crossed out; the second is that the
last message is separated from previous messages by a dashed line; the third
is the arrow on the top part of the scenario. Figure 14 shows an example of a
basic negative scenario. The part of the bMSC that is above the dashed line is
called its precondition; the message that is crossed out is called the proscribed
message. Intuitively, the meaning of basic negative scenarios is that once a
trace described by the precondition has occurred, the next message should not
be the proscribed message. The dotted line is to convey that the precondition
must occur completely before the crossed out message is proscribed (i.e., partial
orderings between the proscribed message and messages in the precondition
are not considered). Note that the precondition describes system behavior from
its initial state. To emphasize this, we have added the black dot and arrow
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
60
•
S. Uchitel et al.
(as used to indicate the initial hMSC node) above the negative scenario. The
scenario in Figure 14 specifies that the system may not exhibit traces with the
following prefix: on, pressure, off, on, query.
Definition 21 (Basic Negative Scenarios). A negative scenario n is a pair
( p, l ) where p is a bMSC, and l is a message label. We use α(n) to denote
α( p) ∪ {l }.
Formally, a basic negative scenario can be defined as a pair ( p, l ) where p
is a bMSC modeling the negative scenarios precondition, and l is the label of
the proscribed message. In terms of expressiveness, basic negative scenarios
are very limited. This is deliberate as we wish to keep this notation as simple
as possible. Our intention is to use basic negative scenarios to reject implied
scenarios in a very simple, push-button way. It is clear that moving from the
implied scenario to the negative scenario notation is trivial for whoever decides
on rejection. This is our intention. Simplicity in rejecting implied scenarios is
crucial if we are to have a dynamic elaboration process.
In the remainder of this article, given an implied scenario w = w1 lw2 , where
l is the point where the w deviates from specified behavior, we say that a negative scenario results from rejecting w if it has been constructed with a bMSC
that models w1 and proscribes message l . In practical terms, this is equivalent
to using the LTSA output to trivially build Neg1. Consequently, the negative
scenario of Figure 14 results from rejecting the implied scenario of Figure 10.
We must now define what basic negative scenarios mean in the context of
MSC specifications. We need to consider that MSC specifications comprise both
a positive and a negative part. The positive part consists of a high-level MSC
and its corresponding basic MSCs; this corresponds to our previous definition of
positive MSC specifications. The negative part consists of a set of basic negative
scenarios. Additionally, we require labels to denote messages consistently in
both positive and negative parts of a MSC specification.
Definition 22 (MSC Specifications). A MSC specification is a structure
Spec = (PSpec, NSpec) where PSpec a positive MSC specification as described
in Section 2 and NSpec is a set of negative scenarios. We use α(Spec) to denote
the union of the alphabets of the scenarios in PSpec and NSpec.
Definition 23 (Basic Negative Scenario Semantics). Let Spec = (PSpec,
NSpec) be a MSC specification, and n = ( p, l ) a basic negative scenario in
NSpec. The set of traces proscribed by n is L(n) = {w.l.w0 ∈ α(Spec)* | w ∈ L( p)}.
We also define L(NSpec) as the union of the all L(n) with n ∈ N .
An initial approach to the semantics of a MSC specification could be to consider it as the set of traces specified by the positive part that do not have a
prefix specified by the negative part of the specification. However, we actually
expect no such trace. This would signify an inconsistency in the specification as
the trace would be both described as acceptable and unacceptable. We therefore
introduce the notion of inconsistency:
Definition 24 (Inconsistent MSC Specifications). Given a MSC specification Spec = (PSpec, NSpec). The specification is said to be inconsistent if
L(PSpec) ∩ L(NSpec) 6= ®.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
61
The addition of a basic negative scenario to a MSC specification does not
always result in an inconsistency. In particular, this is the case if the basic
negative scenario is the result of rejecting an implied scenario. By definition,
an implied scenario is not part of the specified behavior, thus a basic negative
scenario resulting from it does not subtract traces from the positive part of
a MSC specification. In the Boiler Control system example, the behavior in
Figure 10 describes an implied scenario because no specified behavior can have
the prefix: on, pressure, off, on, query. It follows that the negative scenario of
Figure 14 does not subtract any traces from those specified in Figure 3. Thus,
we have the following property:
Property 3. Let Spec = (PSpec, NSpec) be a consistent MSC specification.
Let w be an implied scenario of PSpec and n the basic negative scenario resulting
from rejecting w. Adding n to NSpec results in a consistent MSC specification.
Note that, in this article, we are interested in using negative scenarios to document rejected implied scenarios, thus we assume consistent MSC
specifications.
Although negative scenarios do not alter the traces specified by the positive
part of a specification, they do provide useful information. Negative scenarios
can be thought of as properties that the behavior model for the system to be
developed must satisfy. In our example, we expect the behavior model for the
Boiler Control system to prohibit the following initial behavior: on, pressure,
off, on, query.
In addition, negative scenarios provide information as to whether a certain
implied scenario has already been validated and rejected. Thus, we need to
reformulate the definition of implied scenarios in the context of MSC specifications that have negative scenarios. We are now interested in detecting implied scenarios that have not been explicitly proscribed by the negative part
of the MSC specification. In other words, instead of checking L(A) ⊆ L(PSpec)
with A the minimal architecture model of the positive scenarios PSpec, we
now need to check L(A)\L(NSpec) ⊆ L(PSpec). Thus, we need to build a model
Constrained(A) such that L(Constrained(A)) = L(A)\L(NSpec).
In essence, what we do is for each basic negative scenario n = ( p, l ) we build
a deterministic LTS c such that L(Akc) = L(A)\L(n). We rely on parallel composition to do the actual constraining as it forces both LTSs to synchronise on
shared labels. Thus, we build c in such a way that it keeps track of the negative
scenario’s precondition p, if p occurs then it does not allow l from occurring
immediately; otherwise, all message labels of n are allowed. In other words, we
build c to model all traces on the alphabet α(Spec) that are not proscribed by
n. Formally, we build c such that tr(c) = α(Spec)* \L(n) and c is deterministic.
Details for building such a LTS can be found in Uchitel [2003]. The constraint
LTS for the negative scenario in Figure 14 is depicted in Figure 15.
We now have a deterministic LTS c built from a negative scenario n = ( p, l )
such that tr(c) = α(Spec)∗ \L(n). In addition, we know that the architecture
model of Spec is deterministic as it is the parallel composition of deterministic components. Thus, it follows that L(Akc) = L(A)\L(n). Furthermore, this
result can be extended to a set of basic negative scenarios. Thus if we have a
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
62
•
S. Uchitel et al.
Fig. 15. LTS of basic negative scenario of Figure 14.
Fig. 16. Second implied scenario of the Boiler Control system.
specification Spec = (PSpec, NSpec) with NSpec = {n1 , . . . , nm }, and we build a
constraint ci for each ni then L(AkC) = L(A)/L(NSpec) where C = (c1 k · · · kcn ).
Consequently, we can compare the traces of the constrained architecture
model AkC against those of the Trace model T to detect implied scenarios that
have not been validated. This amounts to checking L(AkC) ⊆ L(T ). In our
example, if we compose the minimal architecture model of the Boiler Control
system (see Figure 9) with the LTS constraint shown in Figure 15, and then
check for trace inclusion against the trace model of Figure 12 we obtain the
LTSA output of Figure 16.
The newly detected implied scenario reveals another consequence of the
mismatch between the specified behavior and architecture: the Control component can terminate the Sensor session immediately after having queried the
Database. This is not a specified behavior as the hMSC in Figure 3 states that
after an Analysis bMSC a Register bMSC must occur. As in the previous implied scenario, the causes lie in the components’ lack local information on what
is occurring at system level. The Control component cannot see when new information has been stored in the Database so it cannot tell when it is allowed
to turn the Sensor off. The Sensor is not aware of queries to the Database and
hence has insufficient information to disallow being turned off by Control.
As before, this new implied scenario may or may not be acceptable system
behavior. Consequently, it must be validated with stakeholders; and according
to the response, a negative or positive scenario would be added to the MSC
specification.
6.2 Abstract Negative Scenarios
Let us assume that the stakeholders deem that the new implied scenario mentioned above represents an undesired behavior. Thus, we obtain a new negative scenario (Figure 17) from which a new constraint can be built to check for
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
63
Fig. 17. Basic negative scenario resulting from Figure 16.
further implied scenarios. By repeating the process of detecting and validating
implied scenarios, one would expect to eventually reach a specification such
that its architecture model, restricted by all negative scenarios, does not exhibit more implied scenarios. However, with the notation presented above, this
is rarely the case.
Consider the MSC specification of the Boiler Control system of Figure 3
together with negative scenarios of Figure 14 and Figure 17. If we check for
further implied scenarios, we obtain the following trace <on, pressure, pressure,
off, on, query>. The implied scenario is a variation of the first implied scenario
we encountered (Figure 10). The difference is that two pressure messages are
occurring in this scenario. Clearly, if we add another negative scenario for this
case, we will then find a similar implied scenario with three pressure messages.
Consequently, this process does not converge to a specification where all implied
scenarios have been validated.
Stakeholders may add several basic negative scenarios rejecting examples
with increasing number of pressure messages. However, at some point, a more
abstract explanation is needed indicating what these negative scenarios have
in common that makes them unwanted behavior. The fact is that the number
of pressure messages is irrelevant. The reason why these implied scenarios are
unwanted behavior is that query should never occur immediately after on. A
more expressive negative scenario notation is needed.
Basic negative scenarios are inadequate because they only specify prefixes of
the traces to be prohibited. In the above case, we need to prohibit traces with a
particular subtrace that does not necessarily have to occur at the beginning of
the trace. These more expressive negative scenarios consist of a precondition p,
a proscribed message l and do not have a black dot and arrow on the top. This
is to indicate that the negative scenario does not specify prefixes. An additional
feature is that the alphabet of the precondition can be explicitly extended with
a set of labels. The text “Alphabet Extension: ALL” on the top right corner of
the scenario in Figure 18 extends the alphabet of the precondition to have all
the message labels of the scenario specification. In Figure 19, the precondition’s
alphabet is extended with {r} making the preconditions extended alphabet the
following { p, q, r}.
The alphabet of preconditions impacts the traces that abstract negative scenarios proscribe. The fact that a message label is not in the precondition’s alphabet means that the occurrence of such message labels is irrelevant with
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
64
•
S. Uchitel et al.
Fig. 18. An extended negative scenario.
Fig. 19. An extended negative scenario.
respect to the satisfaction of the precondition. Consider Figure 19, similarly to
the semantics of basic negative scenarios, this negative scenario is considered
to proscribe the sequence of the form · · · p, q, m · · · . However, it is also considered to proscribe traces of the following form · · · p, s, q, m · · · . This is because
the precondition does not predicate on the occurrence of message labels that do
not belong to its alphabet (in this case s). The extension of the precondition’s
alphabet in Figure 19 means that the negative scenario also proscribed traces
with the following sequence: · · · p, r, q, m · · · .
In short, preconditions specify subtraces with respect to their own alphabet.
This means that negative scenarios can abstract away certain message labels
used in the MSC specification. This capability is an important difference with
respect to the negative scenarios defined previously. Note that the negative
scenario of Figure 18 does not abstract away any message labels as the precondition’s alphabet has been extended with the keyword “All”. We now define
abstract negative scenarios and their semantics formally.
Definition 25 (Abstract Negative Scenarios). A negative scenario n is a pair
( p, E, l ) where p is a bMSC, E is a set of message labels and l is a message
label. We use α(n) to denote α( p) ∪ E ∪ {l }.
Definition 26 (Abstract Negative Scenario Semantics). Let Spec = (PSpec,
NSpec) be a MSC specification, and n = ( p, E, l ) an extended negative scenario
in NSpec. The set of proscribed traces by n is L(n) = {x.y.l.z ∈ α(Spec)* | y| A ∈
L( p)} where A = α( p) ∪ E.
As before, we need to extend the definition of MSC specifications to allow
abstract negative scenarios. In addition, we continue to assume that MSC specifications are consistent. However, we no longer have any guarantees that all
negative scenarios will not introduce inconsistency, as was the case with basic negative scenarios resulting from rejecting implied scenarios. However, the
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
65
Fig. 20. Constraint LTS for Figure 18.
Fig. 21. Constraint LTS for Figure 19.
Fig. 22. Fourth implied scenarios of the Boiler Control system.
LTS constraints described below can be used to detect inconsistencies between
positive and negative parts of a MSC specification.
The criterion for detecting implied scenarios is as was introduced basic negative scenarios. We need to constrain the architecture model in such a way that
it does not exhibit traces that have been proscribed by an extended negative
scenario. As before, we build a LTS c such that tr(c) = α(n) ∗ \(L(n)|α(n) ). Note
that we now use α(n) and L(n)|α(n) instead of α(Spec) and L(n). This is because
of the abstraction capability of these negative scenarios. A formal definition
of such LTS can be found in Uchitel [2003]. The LTS depicted in Figure 20
and Figure 21 that corresponds to the negative scenarios in Figure 18 and
Figure 19.
We now have a deterministic LTS c built from a negative scenario n such
that tr(c) = α(n) ∗ \(L(n)|α(n) ) and consequently that L(Akc) = L(A)\L(n).
If we return to our Boiler Control system, we can constrain the architecture
model with the LTS that in Figure 20 and check for further implied scenarios.
The LTSA output is shown in Figure 22.
6.3 After/Until Negative Scenarios
The implied scenario shown in Figure 22 is similar to the second implied scenario we detected, that of Figure 17. As before, the difference is that now two
pressure messages are occurring instead of one. The real problem is that the
Sensor is being turned off immediately after an Analysis scenario. Although
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
66
•
S. Uchitel et al.
Fig. 23. After/Until negative scenario.
in this particular case, we could produce an abstract negative scenario that
prohibits this negative scenario and others with different number of pressure
messages, in many cases the expressiveness of abstract negative scenarios is
not sufficient. For this reason we introduce after/until negative scenarios.
The essence of why the implied scenario shown in Figure 22 is not acceptable behavior is that after a query the Sensor should not be turned off until
more pressure information has been saved in the Database. From our experience with implied scenarios, we have found that the after/until structure for
expressing negative scenarios is convenient and appears frequently when rejecting implied scenarios. In addition, independently of expressiveness issues,
after/until negative scenarios can help capture a more abstract explanation of
the scenarios that are to be proscribed. These more abstract negative scenarios can be thought of (and actually used as) safety properties that the system
should satisfy.
We now define after/until negative scenarios, which essentially allow us to
prohibit the occurrence of a message within a scope. These scenarios have three
sections called after, not and until. Sections after and until are bMSCs that
determine the scope in which the message in the not section should not occur.
In Figure 23, we depict an after/until negative scenario for the Boiler Control
system example; it states that after query has occurred, off is not allowed until
pressure occurs. Both after and until sections are interpreted relative to their
alphabets (as with abstract negative scenarios). Thus, we allow extension of
the alphabets of both sections independently.
We now define negative scenarios and their semantics formally. We use w[i, j ]
to note the subtrace of w that starts on the ith message and ends on the j th
message of w.
Definition 27 (After/Until Negative Scenarios). An after/until negative
scenario is a structure n = (a, Ea , l , u, Eu ) where a and u are bMSCs modeling the after and until sections of n, l is the proscribed message label and Ea
and Eu are sets of message labels that extend the alphabets of the after and
until sections. In addition, we require l ∈
/ α(u) ∪ Eu . We refer to the alphabet of
n as α(n) = α(a) ∪ Ea ∪ α(u)∪Eu ∪ {l }.
Definition 28 (After/Until Negative Scenario Semantics). Let Spec =
(PSpec, NSpec) be a MSC specification, and n = (a, Ea , l , u, Eu ) an after/until
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
67
Fig. 24. Constraint for negative scenario in Figure 23.
negative scenario in NSpec. The set of proscribed traces by n is L(n) =
{w ∈ α(Spec)* |∃ijk: i < j < k, w[i, j ] is a minimal substring of w such that
/ L(u)}
w[i, j ]|A ∈ L(a), wk = l , and for all substring w0 of w[ j + 1, k − 1], w0 |U ∈
where A = α(a) ∪ Ea and U = α(u) ∪ Eu .
As before, we no longer have any guarantee that certain after/until negative scenarios will not introduce inconsistency. However, the LTS constraints
described below can be used to detect inconsistencies between positive and negative parts of a MSC specification.
The criterion for detecting implied scenarios is exactly the same as before.
We build a LTS c such that tr(c) = α(n) ∗ \L(n)|α(n) . The formal definition of
such LTS is given in Uchitel [2003]. Figure 24 depicts the constraint LTS for
the negative scenario in Figure 23.
We now have a LTS c built from a negative scenario n such that tr(c) =
α(n)∗\L(n)|α(n) , and thus L(Akc) = L(A)\L(n). Consequently, if we return to our
Boiler Control system example, we can constrain the architecture model with
the LTS that corresponds to the negative scenario shown in Figure 23, and check
for further implied scenarios. Now, LTSA reports no safety errors; thus, we can
conclude that we have a MSC specification for which all implied scenarios have
been validated. We say these specifications are stable with respect to implied
scenarios. When a specification reaches such a state, the elaboration process
based on detecting and validating implied scenarios cannot continue. The logical step is then to elaborate the system architecture on which we comment on
in Section 8, but is out of the scope of this article.
In terms of Figure 2, we have now described its lower section, showing how
from the negative part of a MSC specification (NSpec) negative specifications,
using the traces it defines (L(NSpec)), a constraint model can be built (C) such
that it constrains the minimal architecture model A from exhibiting the proscribed traces (L(AkC) = L(A)\L(NSpec)). We have also shown how to detect
nonproscribed implied scenarios by model checking (L(AkC) ⊆ L(T )).
7. CASE STUDY
Previous sections have presented the different parts of the process we propose
for elaboration of behavior models in conjunction with scenario-based specifications. We now show how the elaboration process works on a case study.
We present a case study on a transportation system. We describe in detail the
implied scenario detection-validation cycle and show how the initial MSC specification is gradually completed while at the same time the behavior models
are extended. We also discuss the system requirements that may be elicited
through this process.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
68
•
S. Uchitel et al.
Fig. 25. Initial version of the PTS specification.
The case study is presented from the stakeholders’ point of view, with implied
scenarios that must be accepted or rejected. We play the stakeholders role in
taking these decisions. Obviously, for each implied scenario, there are many
different responses that a stakeholder could give. This is particularly so when
rejecting an implied scenario: a stakeholder could come up with a number of
different negative scenarios ranging from the basic negative scenario that only
avoids the rejected implied scenario, to complex abstract negative scenarios
that could take the specification to a state with no further implied scenarios.
We have tried to keep the “foresight” of the stakeholder feedback to a minimum.
This has the risk of producing a long (and perhaps tedious) case study but avoids
“magic” steps and serves to show how the elaboration process can work even
with only minimal effort and insight from stakeholders.
Throughout the case study, we do not explain why implied scenarios are
present or discuss the behavior models. The emphasis is how implied scenarios
drive the elaboration process from the stakeholders’ point of view.
The setting is that of the development of a transport system. Initially, we
know only that it consists of high-speed vehicles that transport one person
at a time. Passengers can only embark at terminals where they select the
destination terminal. In addition, let us suppose that stakeholders have initially provided only the two scenarios depicted in Figure 25. The scenarios include two passengers, two terminals, one vehicle and a control center. Note that
by starting this case study from such a partial specification we wish to show
that the approach can work even in the presence of very little initial scenario
information.
A stakeholder’s explanation of the scenarios could be as follows: “In the first
scenario, a passenger arrives at Terminal 2 and buys a ticket to a different
terminal. As the transport is at the terminal, the departure gate of the requested
vehicle is announced. The passenger enters the transport and the terminal
initiates the departure procedure by setting the vehicle’s destination. departReq
and departAck are part of the departure procedure. The vehicle starts moving
towards its destination, and when it is 100 meters away from Terminal 1 it sends
an alert. This is part of the arrival procedure which continues with arriveReq,
arriveAck and arrived. Finally, the passenger exits the transport.”
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
69
Fig. 26. PTS implied scenario (Iteration 1).
“The second scenario shows what happens when a passenger arrives at a
terminal where there are no transport vehicles. In this case the terminal, after
selling the passenger a ticket, requests a vehicle to the control center. The center relays the request to the other terminal, where there is a vehicle waiting.
Terminal 2 initiates the departure procedure (as in the previous scenario) and
the transport departs. The arrival procedure is similar to the one described
before. Once the vehicle has arrived, the Terminal informs the waiting passenger of the departure gate and the scenario is similar fashion to the previous
one.”
The two bMSCs are consistently linked in the hMSC in Figure 25 as continuations of the initial node. This is to simplify the diagram; formally, an empty
bMSC that can continue with either of the nodes of Figure 25 would be needed
as an initial node. Consequently, the initial node models the system state in
which the only vehicle is situated at Terminal 2.
Given this partial specification, we can now start checking for implied scenarios. This should raise questions in the stakeholders’ minds and prompt them
to add further information relevant to the system requirements. At worst, it
should force stakeholders to complete the scenario specification by simply accepting or rejecting implied scenarios in an almost mechanical way. In either
case, the result is a richer set of scenarios that expose many of the policies
that the stakeholders have in mind. In the following, we tend to assume that
stakeholders adopt the latter mechanical approach.
The first check for an implied scenario results in a very short scenario (see
Figure 26). If this simple trace is shown to stakeholders for validation, it is
likely to raise some of the following questions: what happens if two requests
for transportation occur at the same time? Is this possible? Or should there
be some kind of mechanism that avoids such a situation? Should the system
implement a first-come-first-serve policy? Or does the passenger at Terminal 2
get priority since the vehicle is already there?
These questions can lead to new scenarios that provide a more complete
description of the system behavior. However, regardless of the questions that
stakeholders ask themselves due to this implied scenario, they must decide if
the feedback they have received is a prefix of some acceptable system behavior
or if the system should not exhibit traces with such prefix.
Let us assume that it is decided that the implied scenario represents acceptable system behavior, and that passengers may arrive and request transportation at any time. Consequently, stakeholders complete their specification with
the scenario of Figure 27 and include it in the hMSC.
The scenario shows how the vehicle that travels from Terminal 1 to Terminal 2 services both the request of Passenger 2 and also answers the call from
Terminal 1 for a vehicle to service Passenger 1. Once the vehicle is at Terminal 1
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
70
•
S. Uchitel et al.
Fig. 27. Amendments to PTS specification (Iteration 1).
Fig. 28. Refactored version of the PTS specification (Iteration 1).
and Passenger 2 has got off, the scenario evolves as “Vehicle at Terminal 1”. In
fact, to stress this, the specification could be refactored as in Figure 28.
Figure 29 is the result of a new check for implied scenarios. As before, this
may raise new questions, such as: can a terminal set a destination to a vehicle
before its passenger has got on, even when the vehicle is not needed at another
terminal? If so, would this trigger the departure of the vehicle? What happens
if a passenger misses his transport? Assuming that stakeholders reject the
implied scenario, then the decision is documented with the following negative
scenario (Figure 30). Note that as this is the straightforward rejection of an
implied scenario, it is not possible for the negative scenario to contradict the
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
71
Fig. 29. PTS Implied Scenario (Iteration 2).
Fig. 30. Amendment to PTS specification (Iteration 2).
Fig. 31. PTS Implied Scenario (Iteration 3).
Fig. 32. PTS specification amendment (Iteration 3).
positive scenarios that have been provided previously. Thus, there is no need for
a consistency check. Examples of negative scenarios that require consistency
checking will be discussed later.
The next implied scenario is, in some respects, similar to the previous one
(Figure 31). Again, it seems that Terminal 2 is setting the destination before
Passenger 2 is in and before a request from Terminal 1 is relayed to it due to the
fact that Passenger 1 needs a vehicle. Let us assume that the implied scenario
is rejected. At this stage, the stakeholders could produce an abstract negative
scenario that rejects both this implied scenario and the previous one, and could
also make the reason explicit as to why these represent unacceptable system
behavior. However, for simplicity, let us assume that this third implied scenario
is simply rejected as is, resulting in the scenario of Figure 32.
The next implied scenario (Figure 33) raises some interesting issues. It
differs from the initial section of bMSC “Simultaneous Requests” in that Terminal 2 dispatches its passenger before getting any notice of passengers waiting
at the other terminal. Should Terminal 1 and the Control Center behave as
specified in “Simultaneous Requests”? As before, even if stakeholders do not ask
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
72
•
S. Uchitel et al.
Fig. 33. PTS implied scenario (Iteration 4).
Fig. 34. Amendment to PTS specification (Iteration 4).
Fig. 35. PTS implied scenario (Iteration 5).
themselves these questions explicitly, completing the implied scenario and placing it in context with other scenarios helps to answer these questions implicitly.
Let us assume the MSC specification is completed as shown in Figure 34. This
new scenario shows a Control Center unaware of the fact that the vehicle
that it is ordering is no longer at Terminal 2, which answers the orderVehicle
message with the same acknowledgment even though it has already sent the
vehicle.
Up to this point, we have not had to discuss the consistency of the MSC
specification as we have introduced basic negative scenarios derived directly
from implied scenarios. However, now that we have introduced a new positive
scenario, we must check that it does not contradict existing negative scenarios.
In the case of the new scenario in Figure 34, LTSA reports no inconsistencies.
From now on, we discuss consistency only if a new negative or positive scenario
introduces an inconsistency.
The next implied scenario (Figure 35) is another case of a vehicle being dispatched for no reason. As the third implied scenario referring to the same kind
of unwanted behavior, it likely that a stakeholder would try to formulate a more
abstract negative scenario that states when vehicles should not be dispatched.
However, to emphasise the point that simple acceptance or rejection of implied
scenarios can still drive the elaboration process forward, we assume that the
implied scenario is simply rejected as is (not depicted).
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
73
Fig. 36. PTS Implied Scenario (Iteration 6).
Fig. 37. Amendments to PTS specification (Iteration 6).
We now have a specification consisting of three negative scenarios and five
bMSCs. A new check produces the implied scenario depicted in Figure 36. It
describes a new situation: a passenger at Terminal 2 has requested a transport and been shown the departure gate; however, before boarding, the vehicle
is dispatched in response to an order from Control Center. This raises the obvious question as to whether a Terminal can dispatch a vehicle without its
passenger? If so, should the passenger request another transport or does the
Terminal register that the vehicle has departed without its passenger? The
simple scenario produced in response to the implied scenario shows that a
vehicle can depart without its passenger (Figure 37); however, it does not clarify what happens with the passenger left behind; this emerges in following
iterations.
In Uchitel [2003], we extend the specification to model a system that is in continuous operation. This results in new implied scenarios and more iterations.
For example, on the eleventh iteration, the implied scenario produced raises
an issue that was not resolved on iteration 6: what happens when passengers
miss their transport. At this point, stakeholders could reject this scenario with
a more abstract explanation of why this scenario (and others encountered previously) should be rejected. In other words, an abstract explanation of when
passengers are not allowed to enter vehicles (see Figure 38). Note that as this
scenario is not a basic negative scenario, it may conflict with the positive scenarios and inconsistencies may be introduced. In Uchitel [2003], we present a
case study that has examples of inconsistencies.
After 12 iterations, the MSC specification has no more implied scenarios to
be validated. Starting from two very simple scenarios, by detecting implied
scenarios we have extended the specification to a total of seven bMSCs and
eight negative scenarios, five of which are basic negative scenarios, one is an
abstract negative scenario and two are After/Until negative scenarios.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
74
•
S. Uchitel et al.
Fig. 38. Amendment to PTS specification (Iteration 11).
However, more importantly, we have elicited several aspects of the system
that were not expressed in the first version of the MSC specification:
—Passengers can arrive concurrently at different terminals (iteration 1).
—Vehicles being sent to terminals to pick up passengers may piggyback passengers going to that terminal (iteration 2).
—A terminal may not dispatch a vehicle until either a passenger has boarded
it or the terminal has been requested to send the vehicle to another terminal
(iterations 2, 3, and 5).
—Terminals do not reveal to the control center the fact that a requested vehicle by the control center has already been sent to the required destination
(iteration 4).
—Terminals may not wait for passengers to board a vehicle if an order by the
Control Center is received (iteration 6).
—The Control Center reacts to requestVehicle messages significantly faster
than the time it takes a transport to travel from one terminal to another
(iteration 7 in Uchitel [2003]).
—Passengers that miss their transport must repay their ticket to board the
vehicle (iteration 11).
An important comment is that the issues described above have been introduced into the MSC specification through very basic acceptance and rejection
of implied scenarios. Up to the tenth implied scenario, no abstract or after/until
scenarios are used. Clearly, a limitation of the approach is that the issues
pointed out above, have been implicitly introduced in the specification. However,
by proposing hypothetical situations, the process can provoke stakeholders to
consider more abstract system requirements. The two after/until negative scenarios and the abstract negative scenario do capture more abstract properties
of the system that are related to the last two items of the above list.
Finally, MSC specification for the Passenger Transport system is undoubtedly still partial in many respects. Implied scenarios cannot be the only driver
for elaboration of scenario-based specifications. Stakeholder intervention is always crucial and other techniques for driving the elaboration process are needed
to complement our approach.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
75
8. DISCUSSION AND RELATED WORK
8.1 Implied Scenarios
A first and natural reaction to implied scenarios may be that some peculiarity
of the proposed MSC notation or semantics is producing, as a side effect, these
unexpected traces. This is not the case, as the concept of implied scenarios is
independent of the notation used to specify system behavior. In particular, the
use of weak sequential composition in the semantics of hMSCs is not the cause
for implied scenarios. It is perfectly possible to have implied scenarios using
strong sequential composition. Using the latter, the initial version of the TPS
specification (Figure 25) would still produce the implied scenario of Figure 26.
Implied scenarios can also arise if the set of system traces is defined by extension
or using regular expressions as in Chu and Liu [1988] instead of using MSCs.
Implied scenarios are the result of specifying the global behavior of a system that is implemented component-wise. They signal a mismatch between the
required behavior and the required architecture of a system. It is not always
possible to provide an arbitrary set of traces with a fixed system architecture.
If the system architecture does not provide components with enough local information, they may not be able to avoid unspecified system behavior, even if
the are behaving correctly in terms of local behavior. The underlying problem is
similar to that studied by the protocol synthesis community (e.g., Saleh [1996]).
However, the underlying assumptions are quite different. Given a service specification (in our setting, a MSC specification), the goal of protocol synthesis is to
automatically construct a distributed implementation according to an architectural specification such that the implementation provides exactly the specified
service. The assumption is that both service and architecture specifications are
complete, thus the problem is to refine the architecture to avoid unspecified
traces (implied scenarios). However, in the context of scenario-based specifications, the completeness assumption does not hold, thus implied scenarios must
be detected and validated and can be used to drive the elaboration of the specification. Another important difference with protocol synthesis is that service
specifications are given using regular expressions or process algebra with no
synchronization operators. Using either of these, instead of the partial orderings defined by bMSCs weak sequential composition semantics, considerably
simplifies the task of detecting implied scenarios.
The term implied scenario was first used by Alur et al. [2000]. They defined
the notion of implied scenario and realizability for specifications containing
a finite set of bMSCs. They also presented an algorithm for implied scenario
detection. However, due to the restricted scenario language, the issue of constructing an architecture model and detecting implied scenarios is limited to a
finite set of finite executions. In Uchitel et al. [2001], we extended their work to
include high-level MSCs allowing specification of an infinite number of (possibly
infinite) systems traces but restricting our approach to synchronous component
communication. Using asynchronous communication makes many of the issues
discussed in this article undecidable. However, our setting can be extended to
allow for bounded asynchronous communication by using buffer abstractions.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
76
•
S. Uchitel et al.
Alur et al. [2001] have extended their initial work to include hMSCs. Our work
differs from theirs [Alur et al. 2000, 2001] in several ways. First, we do not
interpret implied scenarios as being indicative of bugs, rather as indicative of
under-specification. Second, because implied scenarios must be validated and
can be rejected, our approach detects implied scenarios in the presence of negative scenarios. Muccini [2001] has developed an implied scenario detection
algorithm that supports hMSCs and synchronous communication. The algorithm performs an efficient syntactic analysis of the scenario specification at
the expense of failing to detect all implied scenarios.
Ben-Abdhallah and Leue [1997] have studied a related problem called nonlocal choice. In this case, the authors are interested in checking when components
can choose different scenarios in a scenario graph. We are interested in observable behavior; thus, the notion of implied scenarios is defined more abstractly,
in terms of traces of observable events and not on the MSC syntax. Although, to
some degree, the intent of nonlocal choice is similar to that of implied scenarios,
they are not semantically equivalent. Nonlocal choices are implied scenarios;
nevertheless, the converse is not the case. See Uchitel [2003] for an example.
8.2 MSCs: Syntax, Semantics, and Analysis
The notation we use to describe the positive part of MSC specifications is a
syntactic subset of that of the International Telecommunication Union standard
Z.120 for MSCs [ITU 1996]. However, in terms of the semantics, there is a
significant difference. The ITU standard adopts a state-based semantics, where
every MSC specification is considered to determine a state machine. In contrast,
we adopt a trace-based semantics; meaning that the hMSC together with its
bMSCs determine a set of system traces for which many state machines could
be built. This difference is significant as the concept of implied scenario, and
thus an elaboration process based on them, is not applicable in the context
of a state-based semantics. Nonetheless, once the benefits of elaboration using
implied scenarios have been realized, a more design oriented view of MSCs such
as the ITU’s (or a more expressive notation such as LSCs [Harel and Damm
1999]) is possible and potentially beneficial.
Contrary to the ITU interpretation of messages, where asynchronous communication is assumed, we consider messages to be synchronous, that is, message send and receive events are blocking. Note that the introduction of bounded
asynchronous communication could be modeled by introducing buffer abstractions to decouple the message passing. However, implied scenario detection
techniques may need to be revised. We do coincide with the ITU and others
(e.g., Rudolph et al. [1996]) in the use of weak sequential composition.
In addition to the ITU, many authors consider scenario-based specifications
from a state-based semantic perspective (e.g., Reniers [1999] and Rudolph et al.
[1996]). The rationale is that scenario-based specifications can be used to describe the high-level design of system components, that they are design documents in their own right. This design-oriented or late-requirements perspective
tends to support the transition from scenario-based notations to traditional design notations and techniques more easily. This design oriented perspective is
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
77
also taken by approaches that use synthesis as the primary source of describing scenario semantics (e.g., Koskimies et al. [1998], Krüger et al. [1999], Somé
et al. [1995], and Whittle and Schumann [2000]. In contrast, we believe that
scenario-based specifications are particularly well suited for providing partial
descriptions of the intended system behavior. Consequently, we interpret scenario specifications as describing system functionality, not design. However, we
do also study the implications of trying to build state-based models that provide
the set of specified traces. Many informal approaches to scenarios (e.g., Carrol
[1995]) also consider scenarios to be examples of system behavior rather than
design documents. They envisage the use of scenarios very early in the requirements process. This is also true for other approaches based on trace semantics
such as Alur et al. [2000], Ben-Abdhallah and Leue [1997], and Katoen and
Lambert [1998].
Harel and Damm [1999] have worked extensively on an extension to MSCs
called Live Sequence Charts (LSCs). These sequence charts can distinguish
mandatory-universal behavior from provisional-existential behavior. Universal behavior is related to the notion of liveness, while existential behavior is
related to the more common approach to scenarios, that of examples of system
behavior. We interpret the positive part of MSCs in the existential sense. The
distinction between universal and existential behavior is an important one, and
should be made at some point in the development process. Our work focuses
on elaborating partial system descriptions to capture significant aspects of the
potential system behavior. Liveness can also play a role in driving the elaboration of scenario-based specifications and behavior models, and we plan to
investigate this aspect in the future. Harel et al. [2002] have also worked on
the execution of LSCs and also the use of mock user interfaces as a means for
playing in scenarios into a LSC interpreter called the Play engine [Harel and
Marelly 2003]. State-based behavior models can also be synthesized from LSCs
[Harel and Kugler 2000]. The synthesis produces a global automata which is
essentially what we call the trace model. Distribution of the global automata
according to the system decomposition and component interfaces, and the implied scenarios that arise when doing so, is not addressed. Finally, an important
difference with LSCs is that these depart from the idea of a scenario as a simple
intuitive notation that can be (and is) easily adopted by a wide range of stakeholder. We believe that much benefit can and should be gained from the kind of
simple scenario languages being used today, and prefer to exploit the simpler
approaches to scenarios. Our work is complementary to that of Harel et al.,
focusing on distribution aspects of scenario-based specifications and on how to
support the elicitation of existential system behavior and negative behavior.
Our inclusion of negative scenarios as first class entities in MSC specifications is, to the best of our knowledge, novel. The ITU standard [ITU 1996] and
LSCs [Harel and Damm 1999] provide mechanisms for modeling forbidden behavior. For example, LSCs can by means of hot conditions model behaviors that
are forbidden. A “negative LSC” could be expressed with a prechart and only a
hot condition in the main chart. But hot conditions could also be used in a main
chart with messages. In these cases, the LSCs combine positive and negative information about the systems behavior. There are no positive and negative LSCs;
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
78
•
S. Uchitel et al.
however, they can describe (even in one chart) positive and negative behavior.
LSC are more expressive than the standard MSCs and also more expressive
than our negative scenarios. As explained previously, the motivation for the
negative scenario notation is not a general “negative scenario” language but a
notation for rejecting implied scenarios. Nonetheless, our use of preconditions
in basic and abstract negative scenarios is similar to the use of precharts in
LSCs [Harel and Damm 1999].
The After/Until notation for negative scenarios is inspired by work on property specification patterns [Smith et al. 2002]; however, we have used MSC
syntax to facilitate the adoption of negative scenarios by scenario users. Other
possibilities for specifying negative scenarios include temporal logic and regular expressions. Temporal logic requires considerable expertise and is not well
suited for describing sequences of events. Regular expressions can be cumbersome for describing partial ordering of events [Holzmann 1990]. Although, in
our experience, the After/Until notation has been adequate for expressing negative scenarios, further research is needed. Additional constructs for negative
scenarios could be taken from Smith et al. [2002].
In our approach, the set of positive traces are not expected to overlap with the
set of negative traces; in other words, we assume positive and negative parts
of MSC specifications to be consistent. Allowing and managing inconsistency
in requirement specifications may deliver benefit (e.g., Hunter and Nuseibeh
[1998]). Although we do not focus on this issue, it may provide another source
for driving the elaboration of scenario-based specification.
Another line of research is the development of methods and tools for analysis and verification of scenario-based specifications. There are a number of
efforts in this direction focusing on verification of specific system properties
such as process divergence [Ben-Abdhallah and Leue 1997], timing conditions
[Alur et al. 1996], system performance [Andolfi et al. 2000], and more general
properties based on recognizing patterns of communication [Muscholl et al.
1998]. Our work focuses on a different property, realizability. The existence of
implied scenarios indicates that the MSC specification is not realizable. This
is complementary to other efforts in analysis and verification of scenario-based
specifications.
There is a significant amount of work on specifying systems using behavior
models, such as LTS. Such models can be rigorously analyzed using model checking to verify system properties and to provide feedback on potential problems of
the specification. These approaches require the system properties to be explicitly modeled by someone with considerable expertise. In addition, they require
a comprehensive description of the system model in order to provide relevant
feedback. In contrast, the concept of implied scenarios is domain independent.
Thus, stakeholder intervention is not needed to produce the property that is
model checked. We have shown how to mechanically build this property using
the specified system behavior model. In addition, implied scenarios can be detected and provide relevant feedback even in the presence of incomplete system
models. The process we present complements model checking approaches as it
can help to build more elaborate behavior models in which domain dependent
system properties can also be included and model checked.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
79
Deadlocks can be seen as particular cases of implied scenarios. In Uchitel
[2003], we discuss this in more detail and show how by detecting implied
scenarios it is possible to obtain more diagnostic information on the cause of
deadlocks.
8.3 Elaboration of Scenario-Based Specifications and Behavior Models
Iteratively detecting and validating implied scenarios facilitates the elaboration of scenario-based specifications and behavior models. This elaboration is
not merely a classification of existing implied scenarios into acceptable or unacceptable behavior (i.e., partitioning L(A) into two sets L(PSpec) and L(NSpec)).
It can lead to the discovery (from the developer’s perspective) of new functionality that did not appear nor was implied in the original specification (i.e.,
L(A) ⊂ L(A0 ) and L(PSpec) ⊂ L(PSpec0 )) with PSpec0 and corresponding to
a subsequent iteration than A0 and PSpec0 ). When confronted with the prefix
of an implied scenario, if stakeholders consider it correct behavior, they may
complete the scenario by adding messages to the end of it. They must at least
link it into the hMSC. This process extends the behavior specified by the MSC
specification (L(PSpec) ⊂ L(PSpec0 )) and may extend the resulting architecture
model (L(A) ⊂ L(A0 )). The latter occurs if the implied scenario is extended and
inserted into the MSC specification in such a way that the original architecture
model cannot imitate. Thus, accepting an implied scenario may give rise to a
specification that has more (or different) implied scenarios than the previous
one (L(A)/L(PSpec) 6⊂ L(A0 )/L(PSpec0 )). When new scenarios introduce new
message labels, this is even more so. An example of an accepted implied scenario that extends the underlying architecture model is the acceptance of the
first implied scenario of the case study (Figure 27).
From our experience, the iterative process of rejecting and accepting implied
scenarios generally follows two approximate phases. The first consists predominantly of acceptances, when new functionality is brought into the specification. The second consists predominantly of rejections and is when the number of nonvalidated implied scenarios starts to reduce until there are finally
none.
In principle, the elaboration process based on iteratively detecting and validating implied scenarios is possible but cannot be guaranteed to converge to a
stable specification where there are no more implied scenarios. This is reasonable as, on each acceptance of an implied scenario, stakeholders could keep on
introducing new functionality in the form of traces that the underlying architecture model could not perform, including the addition of new message labels
or even components. However, supposing that, at some point, all the positive
behavior of the system has been captured, it is possible to converge to a stable specification by rejecting the rest of the implied scenarios. We have shown
previously that this may not be possible with the expressive power of the basic
negative scenario notation. The extended negative scenario notation seems to
be sufficient to guarantee that the process converges. However, this remains
an open question that we intend to investigate in future work. Note that, even
if the iterative process is cut off before reaching a stable specification, it still
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
80
•
S. Uchitel et al.
allows the elaboration of the initial MSC specification into a more complete
system description, and produces three behavior models that help developers
reason about the design of the system.
In Uchitel [2003], we show how the architecture model provides a basis for
modeling and reasoning about system design by providing an elaboration of
the Boiler Control system where the Control and Database components are extended to avoid the lack of coordination that leads to rejected implied scenarios.
The work of Systä et al. (e.g., Koskimies et al. [1998] and Mäkinen and
Systä [2001]) also supports incremental elaboration of scenario-based specifications and behavior models. Their work focuses on a component level, presenting stakeholders with component behavior that may be the result of overgeneralization introduced by their learning algorithm. Our work is on a system
level, presenting stakeholders with system behavior resulting from a behaviorarchitecture mismatch.
An important observation is that, in certain cases, it may not be practical to
attempt to provide a complete coverage of system behavior using scenarios. This
does not invalidate our approach. As explained before, cutting short the iterative process still produces behavior models that could be extended to provide the
entire system behavior. In addition, independently of the level of coverage that
the scenario specification has, the validation of implied scenarios can facilitate
the elicitation of behavior and possibly the elaboration of requirements.
Note that our approach addresses only one aspect of model elaboration, that
of elaborating system behavior. We do not address elaboration of the system
architecture as in Feather [1987]. As discussed in Section 5, although this is
an important aspect of elaboration, at initial development stages it may be
undesirable to require stakeholders to review and correct the architecture outlined in their MSC specification. Stakeholders may lack the technical skills to
make such design decisions. Besides, taking such design decisions at an early
requirement stage may be undesirable and having to stop the process of model
elaboration to solve design issues may be inopportune. Elaboration of the system architecture is important in latter development stages.
Finally, we only focus on one potential driver for elaboration, that of implied
scenarios. Other potential drivers are compliance to safety and liveness properties. In addition, we do not address the issue that scenario-based specifications
are given at an instance level rather than at a class level. For example, in the
case study, there are two terminals that are instances of the same component
class. The behavior models are typically given at class level. There would be one
behavior model for terminals, which would be instantiated (possibly using renaming) into several terminal instances. Introducing the distinction between
component classes and instances at the MSC and the synthesis level would
clearly be beneficial. However, it also introduces issues such as how should
the behaviors of different instances of the same class be merged, how to detect
potential inconsistencies between the instances, and how should the notion of
implied scenario be revised. We are currently looking into these issues and have
some preliminary results that exploit architectural descriptions, which we hope
to report on in the near future.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
81
8.4 Requirements Elaboration
The framework we have presented includes validation of implied scenarios.
This means that within the cycle, stakeholders, users and domain experts must
answer questions on the acceptability of hypothetical situations. Thus, there
is an opportunity for eliciting and elaborating requirements. We have tried to
enhance this by providing two main negative scenario notations. Our intention
is to facilitate the leap from rejecting individual traces to the elaboration of
abstract safety properties.
van Lamsweerde and Willemet [1998] also aim to support the elaboration of
requirements from scenarios. They propose a technique for inferring declarative
requirements in the form of temporal logic from MSCs. The temporal formulas can be fed into the KAOS approach (e.g., Van Lamsweerde et al. [1995])
linking operational descriptions with goal-based specifications. This addresses
one of the important limitations of scenario-based specifications as tools for
requirement elicitation. Scenarios address operational characteristics of the
system rather than high level-goals that explain the reasons (why) for such
operationalisation.
However, there are significant differences with Van Lamsweerde and
Willemet [1998]. First, their use of negative scenarios and exclusion rules is to
avoid overgeneralization resulting from the inference rules applied to positive
behaviors. This is different from our use of negative scenarios that are used to
document mismatches (not overgeneralizations) between positive behavior and
architecture. In addition, we integrate negative scenarios (once they have been
specified) into the behavior models with no stakeholder intervention. However,
exclusion rules may require weakening through human intervention to avoid inconsistencies. Moreover, this weakening must be done at the logic level instead
of the scenario level. Finally, the more complex a scenario is, the more candidate
goal specifications generated are likely to be irrelevant to some specific concern.
Thus, several rules (that must be applied by stakeholders) are provided to help
clean up scenarios. Implied scenarios result from the concurrent nature of the
system being (partially) specified and in the case of rejections, relevant system
properties are elicited. We believe that Van Lamsweerde’s approach is complementary to ours. While we focus on elaboration of partial operational scenario
descriptions, and the construction of models to enable reasoning on design, Van
Lamsweerde et al. focus on the elaboration of declarative requirements and
reasoning about goals.
8.5 The Authors’ Previous Related Work
The work presented in this article extends our previous work on implied scenarios [Uchitel et al. [2001, 2002a, 2002b]. In this article, we show how some of the
ideas we have developed can be used to drive the elaboration of scenario-based
specifications and behavior models. We have also introduced some changes in
terminology; the most important being that we refer to an architecture model
what we had previously called an implementation because the latter caused
some confusion.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
82
•
S. Uchitel et al.
In addition, there is a significant difference in terms of implied scenario
detection. The method discussed in Uchitel et al. [2001] differs significantly
from the one presented in this article. A discussion of the differences can be
found in Uchitel [2003].
In Uchitel and Kramer [2001], we pursued a different line of work. We studied
scenario-based specifications from a more design-oriented perspective using
state machine-based semantics. The algorithm presented in this article is a
simplified version of the one presented there. The main difference is that in
this setting we do not have to deal with state labels. Although the version in
Uchitel and Kramer [2001] can be used in the current approach, the algorithm
presented here produces clearer FSP code.
In Uchitel [2003], we report on an additional case study: a medium-sized
industrial project involving the behavior specification of instances of a software
architectural style being developed at Philips. The architectural style involves
a horizontal communication protocol that supports the building of product families of television sets.
We have developed a tool that implements the different aspects of our approach. It has been essential for conducting our case studies. The tool provides
a graphical user interface for editing MSC specifications and is integrated into
the Labeled Transition System Analyser (LTSA) that supports the model checking for implied scenario detection for a report on the MSC-LTSA tool refer to
Uchitel et al. [2003] to download the tool visit http://www.doc.ic.ac.uk/ltsa/.
9. CONCLUSION AND FUTURE WORK
We have presented a process for elaborating scenario-based specifications and
behavior models by detecting and validating implied scenarios. The process
facilitates the evolution of a MSC specification to cover behavioral aspects of
the concurrent nature of the system being described and potentially to include
functional aspects of the system that had not appeared in the initial version.
It also facilitates the construction of behavior models that can then be used to
elaborate and rigorously reason about the system design.
More specifically, we have shown how to build minimal architecture models
from positive MSC specifications, how to detect the implied scenarios, and how
to document rejected implied scenarios with an extended MSC specification
that includes negative scenarios. By providing two negative scenario notations,
we have, on the one hand, allowed for a push-button approach to iterative
implied scenario detection-validation, and on the other hand, have facilitated
the elaboration of more abstract system properties. Finally, we have shown the
utility of our approach in a detailed case study.
In the near future, we intend to look into other aspects of scenario-based specifications that can help to drive the elaboration of behavior models. In addition,
we wish to extend the approach to support elaboration of system architecture.
REFERENCES
ALUR, R., HOLZMANN, G. J., AND PELED, D. 1996. An analyser for message sequence charts. In
Proceedings of the 2nd International Conference on Tools and Algorithms for the Construction
and Analysis of Systems (TACAS’96) (Passau). Springer, New York, 35–48.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
83
ALUR, R. AND YANNAKAKIS, M. 1999. Model checking of message sequence charts. In Proceedings of
the 10th International Conference on Concurrency Theory (CONCUR’99) (Eidenhoven). Springer,
New York, 114–129.
ALUR, R., ETESSAMI, K., AND YANNAKAKIS, M. 2000. Inference of message sequence charts. In Proceedings of the 22nd IEEE International Conference on Software Engineering (ICSE’00) (Limerick). 304–313.
ALUR, R., ETESSAMI, K., AND YANNAKAKIS, M. 2001. Realizability and verification of MSC graphs. In
Proceedings of the 28th International Colloquium on Automata, Languages, and Programming
(ICALP’01) (Crete). Springer, New York, 797–808.
ANDOLFI, F., AQUILANI, F., BALSAMO, S., AND INVERARDI, P. 2000. Deriving QNM from MSCs for performance evaluation of software architectures. In Proceedings of the 2nd International Workshop
on Software and Performance (WOSP’00). Ottawa, ACM, New York, 47–57.
BEN-ABDHALLAH, H. AND LEUE, S. 1997. Syntactic detection of process divergence and non-local
choice in message sequence charts. In Proceedings of the 3rd International Conference on Tools
and Algorithms for the Construction and Analysis of Systems (TACAS’97). Springer, New York,
259–274.
BEN-ABDHALLAH, H. AND LEUE, S. 1998. MESA: Support for scenario-based design of concurrent
systems. In Proceedings of the 4th International Conference on Tools and Algorithms for the
Construction and Analysis of Systems (TACAS’98) (Lisbon). Springer, New York, 118–135.
CARROL, J. M., Ed. 1995. Scenario-Based Design: Envisioning Work and Technology in System
Development. Wiley, New York.
CHEUNG, J. C. 1994. Tractable and compositional techniques for behaviour analysis of concurrent systems, Department of Computing. Imperial College of Science, Technology and Medicine,
London, England.
CHU, P. M. AND LIU, M. T. 1988. Protocol synthesis in a state transition model. In Proceedings of the
IEEE International Computer Software and Applications Conference (COMPSAC’88) (Chicago).
IEEE Computer Society Press, Los Alamitos, Calif., 505–512.
CLARKE, E. M. AND WING, J. M. 1996. Formal methods: State of the art and future directions. ACM
Computing Surv., 28, 4, 626–643.
CLEAVELAND, R. AND SMOLKA, S. A. 1996. Strategic directions in concurrency research. ACM Computing Surv., 28, 4, 607–625.
FEATHER, M. S. 1987. Language support for the specification and development of composite systems. ACM Trans. Prog. Lang. Syst. 9, 2, 198–234.
GIANNAKOPOULOU, D. 1999. Model checking for concurrent software architectures department of
computing, Imperial College of Science, Technology and Medicine, London, England.
HAREL, D. AND DAMM, W. 1999. LSCs: Breathing life into message sequence charts. In Proceedings
of the 3rd IFIP International Conference on Formal Methods for Open Object-Based Distributed
Systems (New York). Kluwer Academic, 293–312.
HAREL, D. AND KUGLER, H. 2000. Synthesizing state-based object systems from LSC specifications. In Proceedings of the 5th International Conference on Implementation and Application of
Automata (CIAA’2000). Springer, New York.
HAREL, D., KUGLER, H., MARELLY, R., AND PNUELI, A. 2002. Smart play-out of behavioural requirements. In Proceedings of the 4th International Conference on Formal Methods in Computer Aided
Design. 378–398.
HAREL, D. AND MARELLY, R. 2003. Come, Let’s Play: Scenario-Based Programming Using LSCs
and the Play-Engine. Springer-Verlag, New York.
HARMON, P. AND WATSON, M. 1998. Understanding UML: The Developers Guide. MorganKaufmann, San Fransisco, Calif.
HENRIKSEN, J. G., MUKUND, M., KUMAR, K. N., AND THIAGARAJAN, P. S. 2000. On message sequence
graphs and finitely generated regular MSC languages. In Proceedings of the 27th International
Colloquium on Automata, Languages and Programming (ICALP’00) (Geneva), Springer, New
York, 675–686.
HEYMER, S. 2000. A semantics for MSCs based on Petri net components. In Proceedings of the
2nd Workshop on SDL and MSC (SAM’00) (Grenoble).
HOARE, C. A. R. 1985. Communicating Sequential Processes. Prentice-Hall, Englewood Cliffs,
N.J.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
84
•
S. Uchitel et al.
HOLZMANN, G. J. 1990. Protocol synthesis (Chapter 10). In Design and Validation of Computer
Protocols. Prentice-Hall. Englewood Cliff, N.J.
HOLZMANN, G. J., PELED, D., AND REDBERG, M. H. 1997. Design tools for requirement engineering.
Bell Labs Tech. J., 2, 1, 86–95.
HUNTER, A. AND NUSEIBEH, B. 1998. Managing inconsistent specifications: Reasoning, analysis
and action. ACM Trans. Softw. Eng. Meth. 7, 4, 335–367.
ITU. 1996. Message Sequence Charts, International Telecommunications Union. Telecommunication Standardisation Sector.
JACOBSON, I., RUMBAUGH, J., AND BOOCH, G. 1999. The Unified Software Development Process.
(Harlow). Addison-Wesley, Reading, Mass.
KATOEN, J.-P. AND LAMBERT, L. 1998. Pomsets for message sequence charts. In Proceedings of the
1st Workshop on SDL and MSC (SAM’98) (Berlin). Shaker, 197–208.
KELLER, R. 1976. Formal verification of parallel programs. Commun. ACM, 19, 7, 371–384.
KOSKIMIES, K., MÄNNISTÖ, T., SYSTÄ, T., AND TUONMI, J. 1998. Automated support for modeling OO
software. IEEE Softw. 15, 1, 87–94.
KRÜGER, I., GROSU, R., SCHOLZ, P., AND BROY, M. 1999. From MSCs to statecharts. In Distributed
and Parallel Embedded Systems, Rammig, F. J., Ed. Kluwer Academic Publishers, 61–71.
MAGEE, J. AND KRAMER, J. 1999. Concurrency: State Models and Java Programs. Wiley, New York.
MÄKINEN, E. AND SYSTÄ, T. 2001. MAS—An interactive synthesizer to support behavioral modeling
in UML. In Proceedings of the 23rd IEEE International Conference on Software Engineering
(ICSE ’01) (Toronto). IEEE Computer Society Press, Los Alamitos, Calif., 15–24.
MUCCINI, H. 2001. Implied scenario detection. In Proceedings of the Workshop on Scenarios and
State Machines at the International Conference of Software Engineering (ICSE’01) (Orlando).
IEEE Press.
MUSCHOLL, A., PELED, D., AND SU, Z. 1998. Deciding properties of message sequence charts. In
Proceedings of the 1st International Conference on the Foundations of Software Science and Computation Structure (FOSSACS’98) (Lisbon). Springer, New York, 226–242.
OMG 2002. Unified Modelling Language, Object Management Group.
RATIONAL 2002. Rational Rose.
RENIERS, M. A. 1999. Message sequence chart. Syntax and semantics, Eindhoven University of
Technology, Eindhoven.
RUDOLPH, E., GRAUBMANN, P., AND GRABOWSKI, J. 1996. Tutorial on message sequence charts ’96. In
Proceedings of the IFIP TC6 WG6.1 International Conference on Formal Description Techniques
(FORTE’96) (Kaiserslautern). Kluwer, 1629–1641.
SALEH, K. 1996. Synthesis of communication protocols. Computer Commun. Rev. 26, 5, 40–59.
SMITH, R. L., AVRUNIN, G. S., CLARKE, L. A., AND OSTERWEIL, L. J. 2002. Propel: An approach supporting property elucidation. In Proceedings of the IEEE International Conference on Software
Engineering (ICSE’02) (Orlando). IEEE Computer Society Press, Los Alamitos, Calif.
SOMÉ, S., DSSOULI, R., AND VAUCHER, J. 1995. From scenarios to timed automata: Building specifications from user requirements. In Proceedings of the Asia Pacific Software Engineering Conference
(APSEC’95). 48–57.
UCHITEL, S. AND KRAMER, J. 2001. A workbench for synthesising behaviour models from scenarios.
In Proceedings of the International Conference on Software Engineering (ICSE’01) (Toronto).
IEEE Computer Society Press, Los Alamitos, Calif., 188–197.
UCHITEL, S., KRAMER, J., AND MAGEE, J. 2001. Detecting implied scenarios in message sequence
chart specifications. In Proceedings of the Joint 8th European Software Engineering Conference
(ESEC’01) and 9th ACM SIGSOFT Symposium on the Foundations of Software Engineering
(FSE’01) (Vienna), ACM Press, New York, 74–82.
UCHITEL, S., KRAMER, J., AND MAGEE, J. 2002a. Detecting implied scenarios in the presence of
behaviour constraints. In Proceedings of the International Workshop on Validation and Implementation of Scenario-based Specifications (VISS’02) a satellite workshop of the 5th European
Joint Conferences on Theory and Practice of Software (ETAPS’02), Grenoble, Electronic Notes in
Theoretical Computer Science.
UCHITEL, S., KRAMER, J., AND MAGEE, J. 2002b. Negative scenarios for implied scenario elicitation.
In Proceedings of the 10th ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE’02) (Charleston). ACM, New York.
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.
Scenario-Based Specifications and Behavior Models
•
85
UCHITEL, S. 2003. Elaboration of behaviour models and scenario based specifications using implied scenarios, Department of Computing, Imperial College, London, England.
UCHITEL, S., CHATLEY, R., KRAMER, J., AND MAGEE, J. 2003. LTSA-MSC: Tool support for behaviour
model elaboration using implied scenarios. In Proceedings of the Ninth International Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS) (Warsaw).
Springer Verlag, New York, 597–602.
ULLMAN, J. D. AND HOPCROFT, J. E. 1979. Introduction to Automata Theory, Languages, and Computation. Addison-Wesley, Reading, Mass.
VAN LAMSWEERDE, A., DARIMONT, R., AND MASSONET, P, 1995.
Goal-directed elaboration of requirements for a meeting schedular: Problems and lessons learnt. In Proceedings of the 2nd IEEE
International Symposium on Requirements Engineering (York). IEEE CS Press, 194–203.
VAN LAMSWEERDE AND WILLEMET, L. 1998.
Inferring declarative requirements specifications from
operational scenarios. IEEE Trans. Softw. Eng. 24, 12, 1089–1114.
WAKAHARA, Y., KAYUDA, Y., ITO, A., AND UTSUNOMIYA, E. 1989. ESCORT: An environment for specifying communication requirements. IEEE Softw. 6, 2, 38–43.
WHITTLE, J. AND SCHUMANN, J. 2000. Generating statechart designs from scenarios. In Proceedings
of the 22nd International Conference on Software Engineering (ICSE’00) (Limerick, Ireland).
314–323.
Received October 2002; revised September 2003; accepted January 2004
ACM Transactions on Software Engineering and Methodology, Vol. 13, No. 1, January 2004.