Distributing Refinements of a System-Level
Partial Behavior Model
Ivo Krka and Nenad Medvidovic
Computer Science Department
University of Southern California
Los Angeles, CA, USA
{krka,neno}@usc.edu
Abstract—Early in a system’s life cycle, a system’s behavior
is typically partially specified using scenarios, invariants, and
temporal properties. These specifications prohibit or require certain behaviors, while leaving other behaviors uncategorized into
either of those. Engineers refine the specification by eliciting
more requirements to finally arrive at a complete behavioral description. Partial-behavior models have been utilized as a formal
foundation for capturing partial system specifications. Mapping
the requirements to partial behavior models enables automated
analyses (e.g., requirements consistency checking) and helps to
elicit new requirements. Under the current practices, software
systems are reasoned about and their behavior specified exclusively at the system level, disregarding of the fact that a system
typically consists of interacting components. However, exclusively
refining a behavior specification at the system-level runs the risk
of arriving at an inconsistent specification, i.e. one that is not
realizable as a composition of the system’s components. To address
this problem, we propose a framework that provides the lacking
support: a newly specified requirement implicitly refines the system’s underlying partial behavior model; our framework maps the
new requirement to components by automatically distributing the
system model refinements to the components’ underlying models.
By doing so, our framework prevents requirements inconsistencies
and helps to identify further necessary requirements. We discuss
the framework’s soundness and correctness, and demonstrate its
features on a case study previously used in related literature.
I. I NTRODUCTION
One of the main goals of iterative software requirements
elicitation and preliminary design is to support incremental
discovery, specification, and refinement of the desired system
behavior. The specification notations used early in a system’s
life cycle, such as FLTL properties [8], triggered scenarios [20],
and event invariants [2], are intuitive and inherently partial, focusing on narrow aspects of the system’s behavior. For example,
a scenario describes a single required sequence of interactions
between the system’s components, whereas a safety property
proscribes some system behavior as illegal. Requirements elicitation iterations aim to gradually classify all of the relevant
system behaviors as either required or prohibited.
To avoid errors and to support requirements elicitation, the
above, inherently partial requirements should ideally be supported with techniques that help (1) to detect the inconsistencies between the individual requirements, (2) to validate and
verify the overall system behavior, and (3) to explore the currently underspecified behaviors. To this end, researchers have
c 2013 IEEE
978-1-4673-5765-4/13/$31.00 proposed synthesizing a system’s partial behavior model [6],
[7], [11], [12], [19], [20], [23], represented using an FSAbased formalism such as modal transition systems (MTS) [15],
from the system requirements. A synthesized MTS forms a
formal foundation for (semi-)automated analyses aimed at requirements inconsistency detection [6], [11], [18], validation
and verification [4], and elicitation of new, currently unspecified requirements [1], [20], [23]. An engineer can often use
these analysis capabilities even without an intimate familiarity
with the underlying formalism. Intuitively, in an MTS, which
distinguishes between required, maybe, and prohibited state
transitions, a scenario is captured using required transitions,
while MTS’s maybe transitions should not violate the safety
properties nor the invariants. In this context, addition of a newly
elicited requirement effectively refines the underlying MTS by
either upgrading some of the maybe behavior to required or
removing it from the synthesized model as prohibited.
Some of the major limitations of the current requirements
practices stem from the semantics of the popular requirements
notations. In particular, these notations treat a system as a
monolithic entity [2], [8], [10], [20], [23] whose behavior can
implicitly be represented with a single system-level MTS. By
contrast, software systems typically consist of independent, interacting components whose behavior should then be described
in separate component MTSs [11]. An undesired consequence
of such system-level requirements specification and interpretation is the risk of creating an inconsistent specification that cannot be realized as a composition of the system components [11],
[19], [21]. Discovering and fixing such inconsistencies late in
the process can incur significant costs due to the necessary
backtracking and redevelopment (e.g., rearchitecting the system
to prevent undesired implied scenarios [21]).
To deal with the above limitations, we previously proposed techniques to obtain component MTSs from the requirements [11], [13], while Sibay et al. [19] analyzed the feasibility
of extracting component MTSs from a system MTS. Despite
the positive experience, our prior techniques cannot be directly
used with many of the popular system-level notations because
the heuristic algorithm proposed in [11] applies to very specific
notations (event invariants and existential scenarios), while the
notational enhancement described in [13] is not yet widely
used. By contrast, Sibay et al. [19] explore a more general
72
RE 2013, Rio de Janeiro, Brasil
Research Track
solution by working directly on a synthesized system MTS
regardless of the requirements notation. Sibay shows that a
system MTS need not be distributable, i.e., transformed into
a set of component MTSs whose composition is exactly the
system MTS. Furthermore, Sibay identifies a set of conditions
for a system MTS to be distributable, and outlines a distribution
algorithm for such distributable MTSs. However, even if a
system MTS obtained at some point of the specification process
is distributable, any new requirement may change that. In turn,
this would force an engineer to either perform costly manual
changes to make the system MTS distributable or to keep working with a, potentially even costlier, inconsistent specification.
In this paper, we aim to support the interpretation and distribution of a new system-level requirement even if it at first
produces a non-distributable underlying MTS. Specifically, we
propose a framework that interprets the refinements performed
on a system model in response to a newly introduced requirement in terms of the refinements of the constituent components’
models. Our framework ensures the consistency of the system
model and the component models. In doing so, our framework
prevents the requirements inconsistencies that stem from the
monolithic viewpoint. The framework handles three different
types of system MTS refinements. We have defined these refinement types by studying how a new system-level requirement —
be it a scenario, a temporal property or an invariant— changes
a system MTS, thus striving for the framework’s wide applicability. For each refinement, our framework uses the mapping
between the states in the system model and the states in the
component models to identify the component states that need
to be refined in response to refining the system states. An
engineer using the framework does not need to be aware of the
underlying models’ refinements: the outcome of the refinement
process can be captured as a set of additional requirements that
ensure the overall consistency of the requirements specification.
We prove that the framework is sound, i.e., it produces a
system MTS that (1) is obtained through valid MTS refinements
and (2) is distributable. We also provide an argument for the
framework’s correctness with respect to the intent behind the
requirement driving the process. We have applied our framework on a case study found in related literature [20], [22]. The
case study results suggest that our framework helps to correctly
refine the MTSs, to avoid inconsistencies, and to analyze the
system’s behavior.
Section II provides the background for our approach. Section III introduces the running example. Section IV defines
the types of refinements incurred by the system requirements.
Section V defines the framework that handles such refinements.
Section VI discusses the conducted case study. Sections VII
discusses the related work. Section VIII concludes the paper.
II. BACKGROUND
Section II-A defines modal transition systems and relevant
MTS operators. The definitions we provide are intentionally
similar to and reused from the existing literature [15], [19], [23].
Section II-B describes the types of requirements we consider in
l
RT
mi −→r m j
l ∈A
/ N
l
(mi ,nk )−→r (m j ,nk )
l
l
mi −→m m j ∧nk −→r no
MR
MM
l
(mi ,nk )−→m (m j ,no )
l
l
mi −→m m j ∧nk −→m no
l
(mi ,nk )−→m (m j ,no )
l
MT
mi −→m m j
l
l ∈A
/ N
(mi ,nk )−→m (m j ,nk )
l
l
mi −→r m j ∧nk −→m no
RM
RR
l
(mi ,nk )−→m (m j ,no )
l
l
mi −→r m j ∧nk −→r no
l
(mi ,nk )−→r (m j ,no )
Fig. 1. The rules for the parallel composition operator.
this paper; we selected specifications that are commonly used
and can be mapped to MTS models.
A. Modal Transition Systems
A modal transition system (MTS) [15] generalizes labeled
transition system (LTS) with maybe transitions that are currently neither explicitly required nor prohibited, in addition to
the required transitions used to model the required behavior of
a software component in an LTS [16]. For example, the MTS
ChargingStation (Figure 2) has a maybe transition putCard?
from s1 to s2 . The union of the disjoint sets of required and
maybe transitions comprises the set of potential transitions.
Definition 1 (MTS). A modal transition system M is a tuple
(S, A, ∆r , ∆ p , s0 ), where S is the set of states, A is the event
alphabet, ∆r ⊆ S×A×S the set of required transitions, ∆ p ⊆
S×A×S the set of potential transitions, and s0 the initial state.
e
We use the notation s−→γ s′ to represent a transition from s to
′
s labeled with e, where γ ∈ {r, m, p} denotes required, maybe,
and potential transition, respectively. Any transition that is not
potential is considered prohibited.
An MTS N is a strong refinement of M (denoted M≺N) if N
has all of the required behavior of M, and no potential behavior
that is prohibited in M.
Definition 2 (Strong Refinement). For MTSs M and N, a strong
refinement relation is a binary relation R ⊆ SM × SN , (sM0 ,
sN0 ) ∈ R, such that for each (sM , sN ) ∈ R:
l
l
1.(∀l,s′M )(sM −→r s′M ⇒(∃s′N )(sN −→r s′N ∧(s′M ,s′N )∈R))
l
l
2.(∀l,s′N )(sN −→ p s′N ⇒(∃s′M )(sM −→ p s′M ∧(s′M ,s′N )∈R))
Specification refinement aims to arrive at a model that contains only required behavior, which is called an implementation.
The MTSs of the system components are composed into a
system MTS by synchronizing the component MTSs on shared
events, while independently progressing on non-shared events.
Definition 3 (Parallel Composition). Let M and N be MTSs,
p
p
M = (SM , AM , ∆rM , ∆M , m0 ), and N = (SN , AN , ∆rN , ∆N , n0 ).
Parallel composition (||) is a symmetric operator producing an
MTS M||N = (SM ×SN , AM ∪AN , ∆r , ∆ p , (m0 , n0 )), where ∆r and
∆ p are the smallest relations that satisfy the rules in Figure 1.
When two MTSs synchronize on a shared event, parallel
composition creates a required transition when both of the
synchronized transitions are required (rule RR in Figure 1),
and a maybe transition otherwise (rules MM, MR, and RM).
A component’s transition on a non-shared event is present in
the system model with the same modality (rules RT and MT).
Distribution of a system LTS tries to create a set of component LTSs whose composition is behaviorally equal (denoted
with ∼) to the system LTS; for a non-distributable LTS, the
73
composition of the component LTSs exhibits implied scenarios [21]. Distribution of a system MTS aims to obtain a set of
component MTSs such that the distributable implementations
of the system MTS can be composed from the implementations
of component MTSs.
Sibay et al. [19] have identified a necessary condition for an
MTS M to be distributable: the LTS I obtained by changing all
of M’s maybe transitions to required must be distributable. The
procedure to check whether an LTS is distributable is to project
the LTS to each component’s alphabet, compose the obtained
projections, and check whether this composition generates the
same language as the original LTS. For clarity, we omit the
formal definitions of distributable MTSs; the definitions can be
found in [19]. Similar to Sibay, in this paper we assume deterministic MTSs because handling non-deterministic transitions
on a single event incurs unnecessary technical complexity without a clear benefit: the MTSs synthesized from the requirements
specifications are typically deterministic.
B. Properties and Scenarios
Our work targets the widely used requirements notations:
temporal properties [8], event invariants [2] and triggered scenarios [20]. Requirements specified in these notations can be
mapped to an MTS that satisfies them [11], [20], [23].
A common way of restricting behaviors in particular system
states is by defining formal properties related to those system
states. We model properties using simple boolean propositions
called fluents [8]. Fluents are commonly used to define temporal
properties, invariants, and triggers related to event-intensive
specifications such as scenarios and MTSs [20], [23].
A fluent is defined with a set of initiating events, a set of
terminating events, and its initial value (true or false). The
value of a fluent Φ can be established at each point of system
execution based on the executed event sequence. A fluent holds
when it is initially true and never terminated or if it is initialized
at some point and not terminated since [8]. Propositional formulas on fluents are defined using standard boolean operators,
while temporal properties are specified using standard temporal
constructs (X – next, G – globally, U – strong until).
A system’s use-cases are often specified with sequence
charts. A basic sequence chart consists of vertical lifelines that
represent component instances, and labeled arrows between the
lifelines that represent interaction events (e.g., as in UML sequence diagrams [17]). An event is controlled by a component
if the event arrow is outgoing from the particular component’s
lifeline. The events on a single lifeline are totally ordered, while
the overall scenario sequence is partially ordered. To express
stronger requirements, such as the conditions for a sequence
to necessarily occur, several triggered scenario formalisms
have been proposed [10], [20]. We utilize Sibay’s existential
Triggered Scenarios (eTS) and universal Triggered Scenarios
(uTS) [20] due to their existing mapping to MTS models.
A Triggered Scenario consists of a prechart and a main chart.
A prechart specifies an event sequence whose execution triggers
the main chart; a prechart can also have a precondition defined
on fluents. A main chart captures an event sequence triggered
by the prechart. An eTS implies that a system should have
a behavioral branch that follows the main chart after each
execution of the prechart; an eTS also allows other behaviors
to follow the prechart instead. By contrast, a uTS implies the
stronger condition that each execution of the prechart must be
followed by the execution of the main chart. The concept of a
triggered scenario can be extended to negative scenarios, which
imply that an event must not happen after any execution of the
prechart. Each scenario has an associated alphabet, which is
equal to or a subset of the system’s event alphabet.
III. RUNNING E XAMPLE
The running example we use in this paper is CoffeeMachine,
a software system controlling a vending machine that makes
coffee and cappuccino, while accepting cash and credit cards
as a form of payment. CoffeeMachine needs to be built from
two components: ChargingStation that deals with the payment
and DrinkSelection that monitors beverage choice. Figure 2
depicts the CoffeeMachine MTS obtained from a preliminary
set of requirements (elided for brevity). The CoffeeMachine
MTS was detected as distributable and then decomposed using the algorithm from [19] into component MTSs of Figure 2. Each state in a system MTS corresponds to a combination of states in the component MTSs. For example,
the state CoffeeMachine.s6 corresponds to a combination of
ChargingStation.s2 and DrinkSelection.s3 . Hence, the transitions from CoffeeMachine.s6 are a result of synchronizing the
transitions from ChargingStation.s2 and DrinkSelection.s3 , as
defined by the parallel composition operator from Definition 3.
The maybe transitions (‘?’) of the CoffeeMachine MTS are
analyzed with a stakeholder, resulting in four new requirements
depicted in Figure 3. The first requirement is captured with two
event preconditions1 stating that “the system shall charge for
a particular drink only when that drink has been selected and
the payment has been submitted.” The second requirement is
an FLTL [8] property stating that “a payment can be submitted
only when a drink has been selected.” The third requirement
is a uTS [20] stating that “the system shall permit only cash
payments for coffee.” The final uTS states that “the system shall
dispense coffee once the coffee payment has been processed.”
The CoffeeMachine MTS from Figure 2 is refined according to the new requirements. The CoffeeMachineStep12 MTS
from Figure 4 is obtained by refining the CoffeeMachine MTS
based on the first two requirements from Figure 3; the dashed
lines denote transitions that were removed in the process. The
CoffeeMachineRefined MTS from Figure 4 is a refinement of
CoffeeMachineStep12 based on the scenarios from Figure 3.
Although
CoffeeMachineRefined
correctly
refines
CoffeeMachine per Definition 2, it is incorrect with respect to
the system’s decomposition into two interacting components.
Specifically, the second and third requirement conflict as
1 For CoffeeMachine, we define the following fluents: CoffeeSel initiated
by coffee and terminated by chargeCoff or chargeCapp; CappSel initiated by
cappuccino and terminated by chargeCoff or chargeCapp; Payment initiated by
putCash or putCard and terminated by chargeCoff or chargeCapp; DrinkSel
initiated by coffee or cappuccino and terminated by confirm.
74
Coffee
Machine
coffee?,
cappuccino?
S2
select
S1
putCard?,
putCash?
Charging
Station
putCard?,
putCash?
S3
putCard?,
putCash?
S6
coffee?,
cappuccino?
S4
S5
select
makeCoff?,
makeCapp?
putCard?
putCash?
S9
S1
S8
select
S2
confirm?
chargeCoff?,
coffee?,
S3
chargeCapp? S4
cappucino?
makeCoff?,
makeCapp?
makeCoff?, makeCapp?
chargeCoff?,
S2 chargeCapp? S3
confirm?
Drink
Selection
S7
chargeCoff?,
chargeCapp?
putCard?,
putCash?
S1
S5
confirm?
Fig. 2. The initial specification of the CoffeeMachine system.
Requirement 1: Charging
Preconditons
coffee
Requirement 4: DispenseScenario
Requirement 3: CoffeeScenario
chargeCoff: CoffeeSel ˄ Payment
chargeCapp: CappSel ˄ Payment
prechart
Charging
Station
Drink
Selection
User
select
chargeCoff
prechart
coffee
Requirement 2: EnabledPayment
Property
universal
G(Payment => DrinkSel)
Charging
Station
Drink
Selection
User
confirm
putCash
makeCoff
universal
Fig. 3. The requirements elicited for the CoffeeMachine system.
Coffee
Machine
Step 12
coffee?
S3'
putCard?,
putCash?
S6'
select
S2
S1
Coffee
Machine
Refined
chargeCoff?
putCard?,
putCash?
putCash
coffee?
S6''
putCard?,
putCash?
select
S1
S8
chargeCoff?
S6'
S3'
S7'
S7
chargeCapp?
putCard?
putCash?
confirm?
S8'
makeCoff
putCard?,
cappuccino?
S3'' putCash?
cappuccino?
S2
S3''
putCard?,
putCash?
S6''
S7''
chargeCapp?
confirm?
makeCoff?
makeCapp?
makeCoff?, makeCapp?
S8''
confirm?
Fig. 4. The refined MTSs of the CoffeeMachine system.
they relate to the same behavior of ChargingStation —
CoffeeMachine cannot prevent putCard nor putCash before a
drink is selected and simultaneously impose cash payments
for coffee because ChargingStation does not monitor the drink
selection. The existing algorithm for MTS decomposition [19]
can detect that CoffeeMachineRefined is not a distributable
MTS, but does not suggest how to make it distributable nor
which requirements caused the inconsistency. By contrast, in
this work we aim to continuously keep the system MTS and
component MTSs “in sync” as new requirements are added,
thus immediately detecting any inconsistencies.
IV. R EFINEMENT T YPES
The idea behind our framework is to correctly incorporate
a new requirement into a system MTS by explicitly handling
the different types of refinements mandated by the requirement.
To reason about these requirement-driven refinements, it is
necessary to first understand the structure of an MTS obtained
from a requirement. The existing synthesis procedures [11],
[20], [23] produce MTSs in which each state can be uniquely
characterized by (1) the evaluation of the currently specified
fluents, and (2) the scenario step tracked in the particular state.
For example, the state CoffeeMachineRefined.s′3 (Figure 2) has
the CoffeeSel fluent set to true and tracks that the execution of
CoffeeScenario from Figure 2 has reached its third step. Addi-
tion of a new requirement may refine an MTS (1) to distinguish
between states with alternative (true and false) fluent evaluations, or, in the case of a scenario, to track the scenario steps,
and (2) to prohibit or require some of the previously maybe
behaviors. We capture these different refinement notions with
three atomic refinement types: transition refinement, executiontracking state refinement, and fluent-based state cloning. For
clarity, we omit the full formal definitions of these refinement
types; these definitions can be found in a technical report [14].
Transition refinement is performed when all of the fluents
and scenario steps are tracked in a system MTS and it is only
necessary to (1) require a maybe transition according to a scenario or (2) remove a maybe transition that violates a property,
an invariant, or a universal scenario. For example, as part of the
refinement of CoffeeMachineStep12 to CoffeeMachineRefined
based on CoffeeScenario from Figure 3, the transition
putCash
CoffeeMachineRefined.s′3 −→r CoffeeMachineRefined.s′6 is
required due to CoffeeScenario’s universal event putCash.
Definition 4 (Transition Refinement). For MTS M = (S, A, ∆r ,
l
∆ p , s0 ), refining a transition M.s−→m M.s′ produces an MTS
l
N = (S, A, ∆r′ , ∆ p′ , s0 ), where ∆r′ = ∆r ∪{N.s−→r N.s′ } when
l
a transition is refined to required or ∆ p′ =∆ p \{N.s−→ p N.s′ }
when a transition is prohibited.
Refining an MTS according to a scenario splits some of the
75
MTS states to distinguish between the executions that follow
the scenario and other possible executions. Consequently, it
is possible to require or prohibit events from a scenario’s
main chart explicitly for those executions that follow the scenario. For example, DispenseScenario from Figure 2 refines
CoffeeMachineStep12 to CoffeeMachineRefined by refining the
states s7 and s8 to track DispenseScenario’s execution. These
state refinements make it possible to require makeCoff and
to prohibit makeCapp exclusively following the execution of
DispenseScenario’s prechart. Execution-tracking state refinement refines an MTS state s to distinguish (1) transitions incoming to s that follow the scenario sequence, and (2) transitions
incoming to s that follow other possible execution sequences.
Definition 5 (Execution-Tracking State Refinement). Refinement of a state s in an MTS M = (S, A, ∆r , ∆ p , s0 ) to track exe
ecution of (p−→γ s) produces an MTS M ′ = ((S\{s})∪{s′ , s′′ },
A, ∆r′ , ∆ p′ , s0 ), where ∆r′ and ∆ p′ satisfy a set of rules described
next. The formal specification of the rules is provided in [14].
A state refinement redistributes the incoming transitions of
the original state across the new states: one state s′ has the
incoming transition corresponding to the scenario execution,
while the other state s′′ has all other incoming transitions of
the original state. The execution-tracking state s′ satisfies the
refinement relation from Definition 2, but may also require or
prohibit some of the originally maybe transitions, as required
by the scenario. An execution-tracking state refinement does
not modify the transitions between other MTS states.
Fluent-based state cloning is required whenever a requirement references a new fluent. The cloning splits the states of an
MTS so that every state has a unique fluent evaluation. This enables subsequent refinements explicitly for states with a specific
evaluation of the new fluent. For example, the preconditions in
Figure 3 introduce two new fluents CoffeeSel and CappSel. The
states s3 and s6 of the CoffeeMachine MTS (Figure 2) are then
split in the refined CoffeeMachine12 MTS to track the value of
CoffeeSel and CappSel. By doing so, it is possible to prohibit
the transition on chargeCapp only from the state in which
CoffeeSel evaluates to true (state CoffeeMachineRefined.s′6 ) in
order to satisfy chargeCoff ’s precondition. At the same time,
chargeCapp remains allowed in the states for which CoffeeSel
is false (state CoffeeMachineRefined.s′′6 ).
Definition 6 (Fluent-Based State Cloning). For MTS M = (S,
A, ∆r , ∆ p , s0 ), cloning states based on a fluent Φ = (IΦ , TΦ ,
InΦ ) produces an MTS N = (S′ , A, ∆r′ , ∆ p′ , s0 InΦ ), where S′ =
Strue ∪ S f alse , while ∆r′ and ∆ p′ satisfy a set of rules described
next informally (the formal specification is provided in [14]).
Intuitively, the cloning duplicates each MTS state s into state
strue with the fluent’s evaluation true and state sfalse with the
fluent’s evaluation false. A transition from a state with a fluent’s
evaluation true goes to a state with the fluent’s evaluation false
only for a fluent-terminating event. The converse case requires
a fluent-initiating event. All other transitions do not change the
fluent evaluation.
V. D ISTRIBUTING S YSTEM R EFINEMENTS
Our framework handles a system’s MTS refinement by performing refinements at the component level that follow the system refinement, while preserving the consistency between the
system MTS and the component MTSs. The framework takes
a system-level refinement and identifies the component-level
refinements of a similar type that realize the system refinement.
For example, to handle a system-level transition refinement,
our framework detects the necessary component-level transition
refinements. Similarly, our framework enacts a system’s fluentbased state cloning by detecting the components whose states
need to be cloned. Conceptually, this refinement process transforms the system-level requirements to requirements for each
individual component (e.g., refining component states equates
to tracking component-specific scenarios).
Reasoning about the component states and transitions affected by a system-level refinement is based on the mapping
between the system states and the components’ states. This
mapping stems from the parallel composition operator (Definition 3), which represents each system state as a tuple of
component states. We use M.sMi = Mi .p to denote the mapping
from a system state M.s to a component Mi ’s state Mi .p.
Similarly, Mi .pM = {M.s|M.sMi = Mi .p} denotes the reverse
mapping from a component state to a set of system states.
Sections V.A-V.C describe our solutions for handling systemlevel transition refinement, execution-tracking state refinement,
and fluent-based state cloning, respectively. We have proven
that our solutions are sound, i.e., that they produce a final
system MTS which is (1) a proper refinement of the initial
system MTS and (2) distributable, i.e., a composition of the
component MTSs. For length reasons, we omit the full formal
proofs and provide informal descriptions of the proofs instead.
We also analyze the correctness of our solutions, i.e., whether
the obtained final system MTS properly captures the intent of a
system refinement and, in turn, of the system requirement.
A. Transition Refinement
Each transition in a system MTS relates to a transition in
one or more component MTSs, depending on whether the event
is shared by multiple components. Requiring or prohibiting a
transition in a system MTS should be reflected by requiring
or prohibiting transitions in certain component MTSs. Without doing so, costly inconsistencies may arise. In Section III,
we described one such inconsistency that arised during the
refinement of the CoffeeMachine MTS (Figure 2) into the
CoffeeMachineRefined MTS (Figure 4). To reiterate, the performed transition refinements (1) prohibited cash as a method
of payment in the initial system state s1 , and (2) required
cash payments for coffee. However, these refinements overlook
the fact that ChargingStation cannot observe drink selection:
prohibiting a pushCash transition from the initial system state
should effectively prohibit cash as a method of payment altogether in ChargingStation and, in turn, CoffeeMachine.
Refining a maybe transition to required in a system model
implies refining all of the related component maybe transitions
to required. This stems from the parallel composition rules,
76
l
l
1 refine M.s−→m M.s′ to M.s −→r M.s′
2 for each MTS Mi ∈ M.comp
3
4
Drink
Selection
User
l
R E F I N E T O R E Q U I R E D (tr M.s−→m M.s′ )
Charging
Station
select
coffee
l
if (M.sMi = Mi .p) ∧ (M.s′Mi = Mi .p′ ) ∧ (∃ Mi .p−→m Mi .p′ )
l
neg
l
refine Mi .p −→m Mi .p′ to Mi .p −→r Mi .p′
l
5
for each M.q ∈ Mi .pM , M.q ∈ Mi .p′M s.t.∃(M.q−→m M.q′ )
l
6
if ¬∃M j s.t. (M.qM j −→m M.q′M j )
l
l
7
refine M.q−→m M.q′ to M.q−→r M.q′
l
R E M O V E F R O M C O M P O S I T E (tr M.s−→m M.s′ )
l
1 remove M.s−→m M.s′
putCash
′
2 for each MTS Mi ∈ M.comp
3
4
l
if (M.sMi = Mi .p) ∧ (M.s′Mi = Mi .p′ ) ∧ (∃ Mi .p−→m Mi .p′ )
l
′
add(candidateRef , Mi .p−→m Mi .p )
l
5 for each tr Mi .p−→m Mi .p′ ∈ candidateRef
6 if size(candidateRef ) = 1 or controls(Mi ,l)
l
7
remove Mi .p−→m Mi .p′
8
for each M.q ∈ Mi .pM , M.q′ ∈ Mi .p′M s.t.∃(M.q−→m M.q′ )
9
l
l
remove M.q−→m M.q
′
Fig. 5. Handling a transition refinement in a system MTS.
which produce a required system transition only when the
synchronized component transitions are required (Figure 1).
In turn, each transition refinement to required in a component
MTS may trigger the parallel composition rule RR (Figure 1)
for some of the system MTS transitions. Therefore, once a
transition refinement is propagated to the components, the
resulting refinements are propagated back to the system MTS.
Algorithm R EFINE T O R EQUIRED in Figure 5 outlines our
solution to requiring a transition in a system MTS M. Let
l
t = M.s −→m M.s′ be a transition that is being refined; initially,
t is modified to required (line 1 in R EFINE T O R EQUIRED). In
the subsequent steps, R EFINE T O R EQUIRED iterates through
the component MTSs (lines 2-7) to find the transitions that
produce t (condition in line 3). All such transitions must become required (line 4). After a transition in a component MTS
is refined, we explore whether additional maybe transitions in
the system model should become required (lines 5-7).
Prohibiting a system’s maybe transition is realized by prohibiting a maybe transition in a component model. The algorithm R EMOVE F ROM C OMPOSITE outlines this procedure with
conceptual similarities to R EFINE T O R EQUIRED. R EMOVE F ROM C OMPOSITE first detects the components whose transition may be affected by the refinement (lines 2–4). If only one
component with a maybe transition to be refined is identified
(the first condition in line 6), that maybe transition is prohibited.
Otherwise, based on the notion that each component is responsible for certain events, our solution prohibits a transition in the
component that controls the event of the removed transition (the
second condition in line 6 of R EMOVE F ROM C OMPOSITE).
As an example of applying our solution, consider prohibiting
putCash
CoffeeMachine’s transition s1 −→m s4 . R EMOVE F ROM C OM POSITE propagates the refinement to ChargingStation, which,
in turn, incurs additional modifications to the behavior of
CoffeeMachine. One of these modifications is depicted as a
negative scenario discarding cash as a method of payment
for coffee (Figure 6). Importantly, by propagating the refinement to the component level, our framework prevents the
Fig. 6. A negative scenario incurred by refining CoffeeMachine.
otherwise possible incorrect refinement of CoffeeMachine to
CoffeeMachineRefined described above.
Soundness. Our algorithms in Figure 5 modify a system
MTS M into M ′ . To prove that our algorithms perform legal
refinement, i.e., M≺M ′ , it is sufficient to show that they modify
only the previously maybe transitions (lines 4 and 7 of R EFINE T O R EQUIRED and lines 7 and 9 of R EMOVE F ROM C OMPOS ITE ). We also prove that M ′ is the composition of the refined
component MTSs because (1) lines 5–7 of R EFINE T O R E QUIRED correctly update the applied parallel composition rule
when, following a component refinement, the system transition
should become required; (2) lines 8–9 of R EMOVE F ROM C OM POSITE correctly remove those system transitions for which
their underlying component transitions were prohibited; and (3)
other transitions are correctly left unmodified.
Correctness. The intent behind refining a system transition
l
M.s−→m M.s′ is to have some system components that respectively require or prohibit that system behavior, while not doing
so trivially by prohibiting the system to ever reach M.s. Given
this intent, we show that our algorithms perform necessary
transition refinements at the component level. Consider an event
sequence ω that transitions to M.s from the initial MTS state
M.s0 with ωMi as the projection of ω to a component Mi ’s
alphabet. For a component Mi that shares the event l of the
refined transition, ωMi transitions to state M.sMi from Mi ’s
initial state. Hence, the transition refinements necessary to still
l
allow ω while requiring a system transition M.s−→m M.s′ are
the transition refinements performed in line 4 of R EFINE T O R E QUIRED . Similarly, the transition refinement required to support
l
ω while prohibiting a system transition M.s−→m M.s′ is the
removal of the matching transition in at least one component
state M.sMi as done in line 7 of R EMOVE F ROM C OMPOSITE.
B. Execution-Tracking State Refinement
Refining a state in a system model implies that some states in
the component models should consequently be refined. Without
performing the matching refinements at the component level,
it would remain unclear whether the requirement is realizable
as specified, and costly inconsistencies may be introduced
subsequently. Our solution identifies the component states to
be refined, and performs additional transition refinements to
require or prohibit behaviors as defined in the scenario. In
our solution, the candidate components that may be affected
by the system refinement are automatically identified based
on the event whose execution is being tracked. For example,
the state CoffeeMachineStep12.s7 from Figure 4 is refined
chargeCoff
to track the execution of CoffeeMachineStep12.s′6 −→m
CoffeeMachineStep12.s7 according to the DispenseScenario
77
curr.name
R E F I N E S Y S S T A T E (MTS M,tr M.q −→γ M.s,set changes,ts Scen,ev curr)
1 for each MTS Mi in curr.components
2 if not lastEvent(Mi , Scen, curr)
3
add(toRefine, Mi )
4 for each MTS Mi in toRefine
5 Mi .p = M.sMi , Mi .n = M.qMi
curr.name
6 refine Mi .p to track (M.n −→γ M.p) into M.p′ , M.p′′
curr.name
7 for each (M.r ∈ Mi .p.sys, M.r′ ∈ Mi .nM ) s.t.∃(M.r′ −→m M.r)
′ curr.name
8
refine M.r to track (M.r −→γ M.r) into M.r′ , M.r′′
9 for each change ch in changes
10 if ch.type = require then R E F I N E T O R E Q U I R E D (ch.tran)
11 else if ch.type = remove then R E M O V E F R O M C O M P O S I T E (ch.tran)
Fig. 7. Handling execution-tracking state refinement in a system MTS.
uTS from Figure 3. Our solution identifies that this refinement should be reflected in both component state
DrinkSelection.s4 and component state ChargingStation.s3 .
Analyzing an execution-tracking state refinement in isolation
suggests that the refinement should be propagated to all of
the components that share the tracked event. However, as we
discuss next, this is not true in general.
Refining a component’s state to track a scenario step depends on the whether that component participates in the remainder of the scenario. In particular, a component’s state
need not be refined when that component’s role in the scenario ends with the current scenario step. This occurs when
refining CoffeeMachineStep12.s8 to CoffeeMachineRefined.s′8
and CoffeeMachineRefined.s′′8 to track the execution of confirm
from CoffeeMachineRefined.s′7 . In this case, ChargingStation’s
state is not refined to track the execution of confirm because
confirm is ChargingStation’s final event in DispenseScenario
from Figure 3. By contrast, an execution-tracking state refinement is performed at the component level for those component that participate in the subsequent steps of the scenario.
For this reason, the refinement of CoffeeMachineStep12.s8
to track DispenseScenario’s event confirm is propagated to
DrinkSelection. Once the identified component states are refined, our framework refines the transitions outgoing from the
execution-tracking system state using the solution from Section
V.A. Such a refinement is performed to require makeCoff from
the refined state CoffeeMachineRefined.s′8 .
The algorithm R EFINE S YS S TATE, depicted in Figure 7,
details our solution. Initially, R EFINE S YS S TATE determines
the components to be refined (lines 1–3). R EFINE S YS S TATE
subsequently propagates the desired system state refinement
to the component level by performing component-level state
refinements (lines 5–6). These component-level refinements
split the component state to track the current scenario event
curr. The component state refinement is propagated back to the
system model by refining the related system states (lines 7–8).
Finally, R EFINE S YS S TATE performs the transition refinements
(lines 9–11) as implied by the scenario.
Soundness. The algorithm R EFINE S YS S TATE refines the
system MTS M into an MTS M ′ by (1) splitting the system
states of M, and (2) refining its transitions. In Section V.A, we
demonstrated the soundness of the second step. To prove the
soundness of the first step, we note that the state refinement
in lines 7–8 of R EFINE S YS S TATE only redistributes a state’s
incoming transitions, while leaving the outgoing behaviors un-
highFunds,
lowLevel
S1
highFunds,
highFunds,
lowLevel
putCard?,
lowLevel
putCash?
S5' highFunds,
select
S2
lowLevel
putCard?,
putCash?
S4'
select
S8'
makeCoff?, makeCapp?
Fig. 8. Part of the Transaction-tracking refined CoffeeMachine.
modified. Hence, MTS M ′ is a legal refinement of M. To prove
that M ′ is the composition of the refined component MTSs,
we note that lines 7–8 revise the system states to reflect the
refinement of the component state Mi .p into Mi .p′ and Mi .p′′ .
Correctness. An execution-tracking refinement of a system
state M.s aims to create a component composition in which the
components will require or prohibit behaviors according to a
scenario and its current event e. Requiring or prohibiting events
after e is executed should not be satisfied (1) by preventing
the system from ever reaching M.s via e, or (2) by requiring
or prohibiting those events for any execution that reaches M.s.
Given this intent, we illustrate that our algorithm performs
the appropriate state refinements and transition refinements at
the component level. Let Ω be the set of event sequences
that reach M.s from the initial state M.s0 such that e is the
last event for every ω ∈ Ω. R EFINE S YS S TATE performs an
execution-tracking state refinement in a component Mi only in
cases when Mi shares e (i.e., ωMi , Mi ’s projection of ω, ends
with e). By doing so, it is possible to subsequently require or
prohibit Mi ’s events solely for those executions that reached
M.s through e. For the converse case, when Mi does not share e,
transition refinements are appropriate for the component state
M.sMi because, for each ω, either (1) the different ωMi have
the same final event that is already tracked in M.sMi , or (2) the
different ωMi have different final events, in which case requiring
or prohibiting behaviors must be done for all the different ways
of transitioning to M.sMi .
To validate the system’s behavior after the introduction of
a new scenario, an engineer should analyze either the MTSs
produced using R EFINE S YS S TATE or the emergent positive
or negative scenarios. The purpose of this validation is not to
ensure that the scenario was properly mapped to the component
level, but to analyze whether the requirement was appropriate.
This risk is particularly prominent for universal scenarios [20],
which prohibit every alternative to the main chart once the
prechart occurs. In certain instances, such a strong requirement
results in deadlocked components, in order to prevent any
scenario-violating event. Once such undesired emergent restrictions are detected using the system MTS or the component
MTSs, the original requirement should be revised or discarded.
C. Fluent-Based State Cloning
Cloning the system MTS states to track a newly specified fluent should intuitively be reflected in cloning the states of some
component MTSs to track the component-level “versions” of
the fluent. If a component shares all of the fluent’s initiating
and terminating events, the component’s states can be directly
78
cloned to track the fluent. By contrast, if no component shares
all of the fluent’s initiating and terminating events, it may be
impossible to require or prohibit behaviors exclusively for a
selected —true or false— fluent evaluation. This, however,
contradicts the purpose of specifying the fluent. Below, we
illustrate this issue and further characterize such “unenforceable” fluents. As a consequnce, our framework permits only
fluents whose initiating and terminating events belong to one
component. To revise a system fluent Φ that cannot be mapped
appropriately to the component MTSs, our framework suggests
potential new fluents, initiated and terminated by a single
component’s events, to replace Φ based on a set of heuristics.
As an example, consider an extension of CoffeeMachine
from Figure 2 that reports to a central server, via
ChargingStation’s new highFunds event, that the cash container should be emptied. The new event is added to the
CoffeeMachine’s MTS as a self-transition on highFunds in
every state. Additionally, a new fluent Transaction, initiated by
putCash or putCard and terminated by makeCoff or makeCapp,
is specified and used to prohibit highFunds during ongoing
transactions. A portion of the system MTS, obtained via state
cloning and transition refinements of CoffeeMachine according
to the new requirement, is depicted in Figure 8. The dashed
lines denote the prohibited transitions and the gray states denote
that Transaction = true in those state. While the MTS refinement is valid at the system level, it is inconsistent with respect
to the system components. In particular, ChargingStation cannot support highFunds in CoffeeMachine.s1 and, at the same
time, prohibit highFunds in CoffeeMachine.s′8 . This is because
ChargingStation cannot track the current value of the fluent:
despite being able to observe Transaction-initiating events
putCash or putCard, it cannot observe Transaction-terminating
events makeCoff and makeCapp.
More generally, we consider a fluent all of whose initiating
and terminating events are not included in any one component’s
alphabet to be unenforceable. This stems from the notion that,
in such a case, no one component’s event can be required or
prohibited exclusively for a selected fluent evaluation: the fluent
evaluation can change by the fluent’s initiating and terminating
events that are not a part of a component’s alphabet. Hence,
an unenforceable fluent cannot be used to specify accurate restrictions on the system behaviors, while the component models
cannot be refined to track the different fluent evaluations. For
these reasons, our framework does not permit unenforceable
fluents, and instead suggests candidate fluents to replace it.
To propose candidate new fluents, our framework utilizes the
notion that an event that affect’s the fluent’s value but is not in
a component’s alphabet, is often followed by or preceded by
an event that initiates or terminates the implicit, unspecified
“local” fluent of that component. If a component Mi shares
an unenforceable fluent’s terminating events, the framework
proposes a new fluent local to that component. The terminating
events of this new fluent are the same as those of the original
fluent. The initiating events, however, need to be selected by
an engineer from the following heuristically identified events:
(1) Mi ’s events that follow the initiating event of the original
Basic Tune
User
Tuner1
Nested Tune
Switch
Video
User
Tuner1
T1_Active
prechart
existential
(T1_Tuning) and
(T1_Active)
t1.tune
t1.newVal
prechart
t1.dropReq
t1.tune
blank
t1.dropAck
t1.restore
existential
unblank
t1.newVal
Fig. 9. The scenarios from the Philips TV case study [20].
fluent in some scenario and (2) Mi ’s events that follow the
initiating event of the original fluent in the system MTS. Our
framework similarly proposes a new fluent for each component
Mi that shares an unenforceable fluent’s initiating events. The
distinction compared to the above case is that, in this case,
it is necessary to identify the candidate terminating events.
Therefore, our framework proposes the following events: (1)
Mi ’s events that precede the terminating event of the original
fluent in some scenario and (2) Mi ’s events that precede the
terminating event of the original fluent in the system MTS.
To illustrate how our framework handles unenforceable fluents, consider the Transaction fluent that could not be tracked
by ChargingStation because makeCoff and makeCapp are not
in ChargingStation’s alphabet. Both makeCoff and makeCapp
are preceded by confirm in the CoffeeMachine MTS from
Figure 2, and confirm precedes makeCoff in DispenseScenario
from Figure 3. Our framework proposes a revised fluent
TransactionChargingStation that has putCash and putCard as its
initiating events and confirm as its candidate terminating event,
as identified by the above heuristics. The revised fluent is then
used to refine the ChargingStation MTS appropriately. Note
that an engineer need not accept the proposed fluents — the proposed fluents can be discarded or modified based on the system
semantics. For example, chargeCoff and chargeCapp would be
specified as the terminating events for TransactionChargingStation
if the stakeholders consider transaction to be complete once the
charge for a beverage is committed.
Soundness. Fluent-based cloning of states in an MTS M
does not require or prohibit existing behaviors, nor does it introduce new, previously prohibited behaviors. Hence, the resulting
MTS M ′ , despite a larger number of states, is behaviorally equal
to M. Furthermore, the same set of fluents is used to clone the
states in the system MTS and the component MTSs. Therefore,
the composition of the component MTSs is equal to the finally
obtained system MTS.
Correctness. The intent behind specifying a new fluent is to
be able to restrict behaviors for a particular fluent evaluation.
The correctness of our solution stems from two factors: (1)
our framework allows only fluents that can be mapped to
components in order to be able to restrict system behaviors in a
desired manner, and (2) any revisions to a fluent are validated
and approved by an engineer using the framework.
VI. C ASE S TUDY
In this section, we discuss our experience with applying our
refinement framework to an industrial protocol from the Philips
79
TV product line [20], [22], [24]. We primarily focus on the
benefits that our framework provides in contrast to the existing,
purely system-level, approaches.
The product instantiation we studied consists of two tuning components (Tuner1 and Tuner2), a Switch, and a Video
component. The two tuners are connected to the screen (i.e.,
Video) via the Switch. Only one tuner is active (i.e., its picture displayed) at a time. A user can (1) change the tuners’
frequency and (2) switch between tuners. For our case study, we
replicate the case study conducted by Sibay et al. [20] in which
they incrementally specify scenarios and event invariants for a
protocol that keeps the screen blank to avoid flicker while the
tuner’s frequency is being changed. As part of the replicated
case study, we were able to identify several inconsistencies
(described below) that were overlooked in the original case,
which was conducted exclusively at the system level.
The original case study consisted of several iterations. Each
iteration involved either specifying a new requirement, or revising a requirement based on the validation results for a
synthesized MTS. The case study starts by describing the
main protocol sequence (the BasicTune eTS from Figure 9).
In BasicTune, Tuner1 stores a new frequency value, and asks
Switch to blank the screen while the frequency is changing.
Once the frequency is set (t1.restore), the screen displays the
picture again (unblank). The validation of the synthesized MTS
discovered that the tuning protocol will restart instead of continuing where it stopped if another tuning request is made during
the execution of BasicTune. Therefore, a new fluent T1 Tuning
was defined to capture an ongoing protocol, and the clause
¬T1 Tuning included in BasicTune’s precondition to prevent
this protocol restart. In the following iteration, the NestedTune
eTS, depicted in Figure 9, is specified to capture how a new
frequency is immediately stored (t1.newVal) for a nested tuning
request. The NestedTune’s precondition is then found overly
permissive and revised with a clause that references two new
fluents. The next two iterations specify a precondition and a
scenario that describe when a user’s request (t1.tune) is allowed
and when it is prohibited. Finally, two new eTSs are specified to
capture the continuation of the protocol a nested tuning request.
We applied our framework to the above iterations, while
revising the requirements only if necessary. For each iteration,
we first tried adding the requirement as specified in [20]. In case
a requirement caused a subsequent inconsistency in the original
case study, we revised it in a way that avoids the inconsistency.
We then validated the system MTS and component MTSs to
determine whether they can be used to detect problems with the
requirements or additional behaviors of interest as discussed
in [20]. Next, we discuss how our framework helped to avoid
inconsistencies and facilitated behavior validation.
Fluent-based state cloning. From the four originally specified fluents, our framework directly performed fluent-based
state cloning at the component level for three fluents, while
correctly suggesting a revision of T1 Tuning. T1 Tuning, initiated by Tuner1’s event t1.tune and terminated by Switch’s
events unblank, setActiveT1, and setActiveT2, caused inconsistencies that were not detected in the original case study. For
example, the final MTS from [20] prohibits a tuning request
before blank and unblank in those executions that follow the
BasicTune eTS from Figure 9, but allows them immediately
after those events. However, Tuner1 cannot enforce these restrictions because blank and unblank are not Tuner1’s events.
To fix the inconsistencies, we made t1.restore the terminating
event for T1 Tuning, as suggested by our framework based on
the BasicTune eTS in which t1.restore precedes unblank.
Transition refinement and execution-tracking state refinement. Our framework successfully handled the transition
refinements and execution-tracking state refinements for the
case study requirements. Notably, none of the requirements
were conflicting once we revised the fluent T1 Tuning as
described above. This result was expected since the scenarios were specified as semantically weak existential scenarios:
Existential scenarios only require the transitions related to the
behaviors captured in the scenarios, while allowing all other
behaviors as maybe transitions. Hence, at the end of the original
case study, the synthesized MTS contained a number of unexplored maybe transitions. To further explore our framework’s
ability to refine the remaining maybe behaviors while preventing inconsistencies, we tried to strengthen the NestedTune eTS
into a uTS. Validation of the resulting model uncovered that
the uTS was overly restrictive for some of Switch’s events:
t1.dropAck was prohibited from Tuner1’s model although it was
simultaneously required by Switch, while prohibiting blank was
not possible as it was already required. This prompted us to
revise the scenario by excluding the events controlled by Switch
from the scenario’s alphabet. These inconsistencies would not
have been detected with the purely system-level approaches.
Behavior discovery. While the synthesized MTSs can be
used to discover similar behaviors to those discussed in [20], the
propagation of the component refinements back to the system
MTS helped to identify the otherwise overlooked implications
of having a system composed of components. For example, our
MTSs capture that Tuner1 tries to follow the same protocol
regardless of whether it is active or inactive. This discovery,
in turn, raised the question of how Switch should respond
to an inactive Tuner1. By contrast, the system MTS in [20]
fails to capture this behavior of Tuner1, and the reported case
study does not resolve the question. A separate treatment of
the Philips TV system [22] does confirm the relevance of the
identified behavior and defines additional requirements related
to Switch’s communication with an inactive Tuner1. In addition
to identifying the implications of the components’ behaviors
better, our framework also improved the scalability of behavior
validation: since a system MTS can become very large, existing
behaviors of interest can be validated and new behaviors identified in a smaller component MTS. The full system MTS can
then be used to “replay” the analyzed component behaviors.
In summary, the conducted case study confirmed that our
framework helps (1) to specify requirements more accurately,
(2) to avoid potential inconsistencies, (3) to identify and validate the behaviors of interest.
80
VII. R ELATED W ORK
In this section, we overview the techniques for systemlevel model decomposition, describe the applications of partial
behavior models early in a system’s life cycle, and discuss
techniques that maintain the consistency of design models.
Model decomposition. The idea of creating componentlevel behavioral models from system-level models has been
explored in different settings [3], [9], [19], [21]. Bianculli et
al. [3] propose a Web service-oriented technique that creates
a set of component models such that their composite behaviors are a strict subset of the initially specified system-level
behaviors. Halle and Bultan [9] proposed a technique that
determines whether a system-level LTS can be decomposed in
a way that preserves all of the desired system-level behaviors.
Uchitel et al. [21] devise a set of component-level models such
that their composition may provide more behaviors than the
initial system-level specification. Contrary to our work, these
existing techniques do not deal with partial behavior models.
To our knowledge, the only other technique that tries to devise
component MTSs from a system MTS was proposed by Sibay
et al. [19]. As we discussed earlier, Sibay presents an algorithm
that creates correct and complete component MTSs from a distributable system MTS. However, contrary to our technique, for
a non-distributable initial system MTS their algorithm creates a
final MTS that does not refine the initial MTS, and potentially
introduces previously prohibited system behaviors.
Synthesis of partial behavior models. MTSs have been
used to capture, in a single model, the declarative specification
of the legal behaviors (i.e., properties) and examples of positive
behavior instances (i.e., scenarios). Uchitel et al. [20], [23]
synthesize a system MTS from a set of scenarios and a set of
safety properties; the technique works by generating a separate
MTS for each scenario and property, and then merging them [6],
[7]. In our previous work, we proposed an algorithm that
generates component-level MTSs from system scenarios and
operational requirements [11]–[13]. As described in Section VI,
the framework proposed in this paper augments the existing
approaches that synthesize a system MTS by propagating the
refinements of the system MTS onto the component models.
Design model consistency. Our work relates to the research
on model traceability and inconsistency management [25].
Egyed [5] and Xiong et al. [26] create consistency rules between different types of UML models. The rules, built-into
a tool [5] or specified by an engineer [26], are checked and
propagated (semi-)automatically when a model is modified. In
our framework, we maintain behavioral consistency between
models of the same type, but of different scopes. We also
automatically propagate transition and state refinements, while
involving an engineer when revising a problematic fluent.
VIII. C ONCLUSIONS
In this paper we have provided a framework for reasoning
about refinements of composite system models. We defined
three types of atomic refinements, and built our framework
around them. The framework handles a refinement of a system
model by propagating the changes to component models in
order to maintain consistency. We believe that this framework
presents a step forward in formally supporting the early stages
of the iterative and incremental development practices when
requirements may refer to different parts of a system. Our
evaluations have demonstrated the framework’s ability not only
to maintain model consistency, but also to discover relevant new
requirements and identify defective requirements.
ACKNOWLEDGMENTS
This work has been supported by the U.S. National Science Foundation under award numbers 0905665, 1117593,
and 1218115. The work has also been supported by Infosys
Technologies, Ltd.
R EFERENCES
[1] D. Alrajeh et al. Learning from vacuously satisfiable scenario-based
specifications. In Proc. of FASE, 2012.
[2] D. Alrajeh et al. Elaborating requirements using model checking and
inductive learning. IEEE TSE, In Press.
[3] D. Bianculli et al. Interface Decomposition for Service Compositions. In
Proc. of ICSE, 2011.
[4] N. D’Ippolito et al. MTSA: The Modal Transition System Analyser. In
Proc. of ASE, 2008.
[5] A. Egyed. Automatically Detecting and Tracking Inconsistencies in
Software Design Models. IEEE TSE, 37(2), 2011.
[6] D. Fischbein et al. Weak Alphabet Merging of Partial Behavior Models.
ACM TOSEM, 21(2), 2012.
[7] D. Fischbein and S. Uchitel. On correct and complete strong merging of
partial behaviour models. In Proc. of FSE, 2008.
[8] D. Giannakopoulou and J. Magee. Fluent model checking for event-based
systems. In Proc. of ESEC/FSE, 2003.
[9] S. Hallé and T. Bultan. Realizability Analysis for Message-Based
Interactions Using Shared-State Projections. In Proc. of FSE, 2010.
[10] D. Harel and R. Marelly. Come, let’s play: scenario-based programming
using LSCs and the play-engine. Springer, 2003.
[11] I. Krka, Y. Brun, G. Edwards, and N. Medvidovic. Synthesizing Partial
Component-Level Behavior Models from System Specifications. In Proc.
of ESEC/FSE, 2009.
[12] I. Krka, G. Edwards, Y. Brun, and N. Medvidovic. From system
specification to component behavioral models. In Proc. of ICSE NIER,
2009.
[13] I. Krka and N. Medvidovic. Component-aware triggered scenarios.
Technical report, University of Southern California, 2013.
[14] I. Krka and N. Medvidovic. Distributing refinements of a systemlevel partial behavior model. Technical report, University of Southern
California, 2013.
[15] K. Larsen and B. Thomsen. A modal process logic. In Proc. of LICS,
1988.
[16] J. Magee and J. Kramer. Concurrency. John Wiley & Sons, 2006.
[17] OMG. UML 2.2 specification. http://www.omg.org/spec/UML/2.2/,
2009.
[18] M. Sassolas et al. Exploring inconsistencies between modal transition
systems. SoSyM, 2010.
[19] G. Sibay et al. Distribution of modal transition systems. In Proc. of FM.
Springer, 2012.
[20] G. Sibay et al. Synthesising modal transition systems from triggered
scenarios. IEEE TSE, In Press.
[21] S. Uchitel et al. Incremental elaboration of scenario-based specifications
and behavior models using implied scenarios. ACM TOSEM, 13(1), 2004.
[22] S. Uchitel et al. System architecture: the context for scenario-based model
synthesis. In Proc. of FSE, 2004.
[23] S. Uchitel et al. Synthesis of Partial Behavior Models from Properties and
Scenarios. IEEE TSE, 35(3), 2009.
[24] R. Van Ommering et al. The koala component model for consumer
electronics software. Computer, 33(3), 2002.
[25] S. Winkler and J. von Pilgrim. A survey of traceability in requirements
engineering and model-driven development. SoSyM, 9(4), 2010.
[26] Y. Xiong, Z. Hu, H. Zhao, H. Song, M. Takeichi, and H. Mei. Supporting
automatic model inconsistency fixing. In Proc. of ESEC/FSE, 2009.
81