Systematically Combining Specifications of Internal and External System

Behavior Using Statecharts

Martin Glinz
Department of Informatics, University of Zurich
Winterthurerstrasse 190
CH-8057 Zurich, Switzerland
[email protected]

Abstract with state machines. However, UML does not care about
the methodological aspects of using these models. For
In contemporary model-based specifications, we typi- example, the state machine of Fig. 1 can be interpreted as
cally find a naive combination of models of the externally a use case, i.e. an external view of the system, as well as a
visible behavior of a system (typically expressed as sce- specification of the system’s internal behavior.
narios or use cases) and of the internal system behavior
(partially represented in explicit state models and par-
tially expressed as data). However, a systematic combi-
nation and integration of the two behavior aspects has not ready
yet been investigated.
In this paper, I sketch a systematic approach for mod- selection key pressed selection key pressed
eling both external and internal behavior of a system with register selection register selection
statecharts in an integrated, non-redundant way. The
main idea is to start with statecharts that model external selection
behavior in the form of use cases or type scenarios and
then add statecharts that model internal behavior only coin inserted
where the scenario/use case statecharts do not suffice for take coin
canceled
expressing the behavior of the system. initialize coin inserted
payment take coin
1. Introduction
canceled requested sum paid
It is well known that state machines can be used both give money back; print ticket
for modeling system behavior (typically internal behavior initialize
of the components of a system) and for modeling interac- delivery
tion between actors and a system (the externally visible ticket taken
initialize
behavior or short the external behavior of a system).
In internal behavior modeling, a state represents a Figure 1. Model of a simple ticket vending machine
situation where the system reacts to those events that trig-
ger one of the state’s outgoing state transitions, while the In situations where the system behavior is more com-
actions specified for the state transitions describe what the plex than in the example given in Fig. 1, a pure external
system does when a state transition occurs. behavior specification typically fails, because there is
When modeling actor-system interaction, every state externally visible behavior which depends on results of
transition specifies a stimulus coming from an actor and a previous interactions. In this situation, behavior must
response by the system. States typically model a time either be specified by interaction traces (which is not
interval where the system waits for the next stimulus from practically feasible in most cases) or a model of internal
an actor. system states is required.
Modeling languages such as UML [11], [12] allow On the other hand, a purely internal behavior model
both interaction modeling and internal behavior modeling also fails because it ignores the interaction of the external

Proceedings of the 3rd ICSE International Workshop on Scenarios and State Machines: Models, Algorithms and Tools, Edinburgh, May 2004
actors with the system. Hence, most contemporary speci- This means that external system behavior is modeled
fications combine a model of external behavior (typically first. Internal behavior models are systematically added in
in the form of use cases) with a model of internal behavior all situations where the external behavior models do not
(both implicitly given by data and explicitly in state ma- suffice, thus leading to a specification where the two be-
chines attached to objects). However, today we do this havior aspects are modeled complementary and non-
combination in a naive way, not caring about the relation- redundantly. In the integrated model, it shall still be
ships and interdependencies between the two kinds of clearly visible which state machines model externally
behavior models. visible behavior and which ones represent internal be-
A similar problem arises when modeling components havior. We achieve this by stereotyping the state ma-
in UML 2.0 [12]. On the one hand, a component in UML chines.
2.0 has interfaces which require a specification of the Giving preference to external behavior modeling
externally visible behavior of the component. On the other makes sense because
hand, we also have to model the internal behavior of the • in requirements models this is what people are inter-
component, in particular the interaction between its con- ested in,
stituent objects and/or inner components. • in design models, external behavior modeling supports
If we use statecharts both for external and internal be- information hiding and component building.
havior modeling, so that formal integration of the two
behavior aspects is possible, we come across some ques-
2.2 Using the tools and materials metaphor
tions that—to the best of my knowledge—have not been
investigated yet: The tools and materials metaphor [14] is used for pro-
• How shall the models be combined so that integration viding guidance which components of a system need
makes sense and has useful semantics? which kind of behavior model. This metaphor classifies
• Does the combination yield redundant models? If yes, the components2 of a system into three categories:
is this redundancy useful (for example, for validation • ‘Tools’ assist external actors in doing the actors’ tasks:
purposes) or is it an unwanted source of potential in- they receive stimuli from them and produce appropri-
consistencies? ate responses. In order to do their job, ‘tools’ process
• If we do not want redundant models, how can we ‘materials’.
achieve that? • ‘Materials’ represent artifacts (or containers storing
In this paper, I sketch a systematic approach for mod- artifacts) that are being processed (created, modified,
eling both user-system interaction and system-internal queried,...) by ‘tools’ or ‘automata’. ‘Materials’ are
behavior with statecharts [6] in an integrated, non-redun- passive.
dant way. The main idea is to start with statecharts that • ‘Automata’ work without being triggered by an exter-
model type scenarios1 (or use cases in UML terminology) nal event. They either run continuously or are trig-
and then add statecharts that model internal behavior only gered internally. Automata are active, processing ‘ma-
where the interaction statecharts do not suffice for ex- terials’ or using ‘tools’.
pressing the behavior of the system. It turns out that external actors interact with ‘tools’ in
The rest of the paper is organized as follows: Section this metaphor. ‘Automata’ act on their own, while ‘mate-
two gives an overview of the approach and illustrates it rials’ are used by ‘tools’ and/or ‘automata’. Hence, any
with an example. In Section three, the integration problem component being classified as a ‘tool’ in the metaphor
is discussed. Section four gives some conclusions, surveys needs a specification of its external behavior. This specifi-
related work and provides directions of further research. cation must be augmented by internal behavior models for
all ‘materials’ that exhibit state-dependent behavior. Fi-
nally, all components being classified as ‘automata’ need
2. The approach a specification of their behavior. As they are parts of the
system, we also need an internal behavior model for them.
2.1 Basic ideas
The basic idea, which is laid out in this paper, is to
2.3 An example
have an integrated, non-redundant state machine model of
both external and internal behavior of a system, using the As an example, we use a ticket vending system which
external behavior model as the lead model. is more sophisticated than the machine given in Figure 1.

2 In requirements specifications, components are identifiable, separable

1 A type scenario is an ordered set of interactions between partners that subproblems of the given problem, whereas in design specifications
represents a set of possible interaction steps. A use case is a type components represent design items with high cohesion and low
scenario. coupling.
 Let us assume that the system consists of four parts: narios (in UML terminology: the use cases) are identified.
• Vending is responsible for vending tickets. It is similar Every type scenario is modeled as a statechart.
to the system specified in Figure 1, but has an addi- Every state transition represents a step in a type sce-
tional timeout feature. nario, where the triggering event represents the stimulus
• Supervisor supervises the condition of mechanical coming from an external actor, while the triggered actions
components such as the coin vault, ticket printer, ticket represent the response by the system. Responses can be
paper roll, etc. (1) messages to an external actor or device, (2) actions
• Logging logs all vending transactions and all events that change the state of the system, or both.
detected by Supervisor or caused by aborted transac- In order to simplify integration, all statecharts are
tions. modeled so that they are compositional [5].
• Maintenance handles offline parametrization and serv-
icing of the machine. Vending
A model of the behavior of this system will be devel-
oped in the subsections below.
ready

re-select ticket select ticket

2.4 The four modeling steps register selection;
register selection;
display amount display amount
The proposed modeling method proceeds in four steps:
(1) Classify the components of the system according to the cancel OR timeout selection
clear display
tools and materials metaphor [14],
(2) Model the external behavior of the ‘tool’ components,
cancel OR timeout insert coin AND
(3) Model the internal behavior of the ‘materials’ and give money back; coin < amount
insert coin AND
‘automata’ components, clear display take coin; coin ≥ amount
display new
(4) Integrate the resulting statecharts. amount
take coin;
insert coin AND clear display;
The steps are not a strict, waterfall-like sequence, coin < amount print ticket;
where a step must be completed before the next one can take coin; payment return change
display new
start. Rather they are meant as a sequence of thinking amount insert coin AND
about models: for any piece of model development, mod- coin ≥ amount
take coin;
eling external behavior comes first, then internal behavior clear display;
is considered and the two behavior specifications are print ticket;
return change
integrated.
take ticket and change
delivery OR timeout
2.5 The classification step log sale

In the first step, the problem is split into parts and the
parts are classified into ‘tools’, ‘materials’ and ‘automata’. Timeout
The ‘tool’ parts interact with external actors or devices
and thus exhibit externally visible behavior. The ‘materi- idle 45 s after
als’ and ‘automata’ parts have system-internal interaction entering
user action running
only and, hence, their behavior is internal. timeout
Example. In our example introduced in 2.4 above,
Vending and Timeout are classified as ‘tools’, because they user action running
assist the user in accomplishing her/his task, viz. buying
tickets. Supervisor is classified as an ‘automaton’ because
user action := select ticket OR re-select ticket OR insert coin OR
it is triggered cyclically by an internal clock. Logging is take ticket and change OR cancel
classified as a ‘material’, because it mainly represents an
artifact, viz. the log of transactions and events. Mainte- Figure 2. The external behavior of the Vending and
nance again is classified as a ‘tool’, because it assists the Timeout components modeled with scenario state-
operator in accomplishing her/his task. charts (scenario statecharts are denoted by a
double-arrow symbol)
2.6 The external behavior modeling step
Example. For our example, the behavior models of
This step is comparable to classic use case modeling. Vending and Timeout are given in Figure 2. The double
For every ‘tool’ component of the system, the type sce- arrow symbol in the upper left edge of the statecharts is a
stereotype, marking these statecharts as being type sce- 2.8 The model integration step
narios. The behavior model for Maintenance is omitted
here. In the final step, the statecharts that were modeled in
the two previous steps are integrated into a single state-
chart which then is a non-redundant model of the com-
2.7 The internal behavior modeling step plete behavior of the system. Obviously, this statechart
In this step, the internal behavior of the ‘automata’ and contains the constituent statecharts from steps 2 and 3 as
‘materials’ components is modeled. This step is compara- sub-statecharts.
ble to classic system behavior modeling with state ma- During the integration process, inconsistencies be-
chines. tween the parts to be integrated must be detected and re-
The ‘automata’ components are active. Their state solved. Equally, missing information must be identified
transitions are typically triggered by internal events and in and added. Hence, the integration process cannot be
turn trigger actions and other internal events. automated. It is a manual, method-guided process.
The ‘materials’ components, on the other hand, are In order to describe this process, some general discus-
passive. Their statechart is a classic class or object be- sion of integration and inconsistency problems is needed
havior description, specifying the sequences of operations first. Therefore, integration is presented in a section of its
that are allowed on an object. Hence, the events triggering own below.
the state transitions are method invocations and there are
no explicit actions for these transitions. 3. Integration issues
Example. Figure 3 gives the models of Supervisor and
Logging in our example. The square symbol in the upper 3.1 Kinds of integration
left edge of the statecharts is a stereotype, marking these
statecharts as being internal behavior specifications. There is a lot of work dealing with integration and
synthesis of models, e.g. [2], [8], [9], [13]. In order to
Supervise
characterize my approach, I give a short classification of
the kinds of integration that are typically being used.
a. Stakeholder viewpoint integration. A given prob-
idle
lem is modeled from the viewpoints of different
60 s after
entering idle scan stakeholders. The integration problem is to build a single
complete model from these viewpoint models [9].
scan devices
b. Instance model integration. A set of models cov-
scanning reset
ers various instances of a given problem. The integrated
problem detected model abstracts the instances into a type model. Typical
log event; representatives of this kind of integration are state ma-
go offline
chine synthesis approaches where a set of instance sce-
problem narios, each one describing a single behavioral thread, is
integrated into a state machine model which represents all
possible behaviors [8], [13].
c. Intra-aspect model integration. Some aspect of a
Logging
system is modeled by a set of non-overlapping partial
models. These models are integrated into a single model
logging off
download log of the given aspect. The integration approach in [2], where
start logging a set of different, but related type scenarios (i.e. use cases)
stop logging is integrated into a common model, is a typical example of
this kind of integration.
logging on d. Cross-aspect model integration. Different aspects
log of a system are modeled separately. The integration prob-
transaction log
event lem is to bring these aspect models together. This is the
principal integration problem when modeling with UML.
Another example for this kind of integration is the
Figure 3. The internal behavior of Supervisor (an lightweight integration of use cases and class models
‘automaton’) and Logging (a ‘material’) modeled with presented in [3].
internal statecharts (internal statecharts are denoted In the approach described in this paper, only aspectual
by a square box symbol) model integration (cases c. and d. above) is considered.
 Instance model integration (case b.) is no issue here, major activities: syntactic integration and detection and
because all partial behavior models are statechart models, resolution of inconsistencies.
i.e. they already represent classes of behavior, not in- Note that inconsistencies are resolved during integra-
stances. Stakeholder viewpoint integration is also not tion; the approach does not aim at tolerating inconsisten-
treated. It is assumed here that viewpoint integration takes cies [1], [10].
place when creating the statecharts that model the behav-
ior of the system components. a. Syntactic integration. Syntactic integration is done
according to the method given in [2]. We construct a
statechart hierarchy having the constituent statecharts as
3.2 Dealing with inconsistency
its leafs. Statecharts being independent of each other be-
A major problem of any integration approach is deal- come refinements of parallel states in this hierarchy.
ing with inconsistencies between the models that are to be Statecharts with a sequential dependency become refine-
integrated. ments of two sequential states, those which mutually ex-
We distinguish inconsistencies in syntax, naming, in- clude each other become refinements of alternative states,
formation flow and semantics. etc.
Syntactic inconsistencies occur when the same concept Example. Figure 4 shows the high-level statechart
is represented with different syntax in two constituent which integrates the previously developed element state-
models. As an example, assume a model where there are charts. Vending and Timeout are independent, so they be-
two outgoing flows f and g, while in another model, we come parallel statecharts. Both Vending and Timeout have a
have an incoming compound flow consisting of f and g. sequential dependency on Maintenance (and vice versa).
Naming inconsistencies occur when the same concept Hence, state transitions from Maintenance to Online and
is given different names in two constituent models. The vice versa are introduced. Supervise and Logging are inde-
principal means for avoiding naming inconsistencies is pendent of the Maintenance/Online cluster, hence we do a
using and maintaining a glossary. parallel composition here.
Information flow inconsistencies occur when a com-
ponent B requires information from another component A Ticket vending machine
which is not produced by A. Another, milder form of
information flow inconsistency occurs when a component Maintenance go offline Supervise
produces an information which is not needed anywhere
go online
else. reset;
Semantic inconsistencies occur when two constituent log event

models have a different understanding of the underlying Online

problem. For example, consider a seat reservation system Logging
and let the model of the external behavior have a waiting Vending Timeout
list option for the case where no seats are available. On
the other hand, assume that in the model of internal be-
havior, there is no concept of maintaining a waiting list. In
such a situation, we have a semantic inconsistency. Figure 4. The composite statechart representing the
In the approach described in this paper, models with integrated behavior (both external and internal) of
semantic inconsistencies cannot be integrated as they are. the system
In order to make integration possible, semantic inconsis-
tencies must be resolved by modifying the statecharts b. Detection and resolution of inconsistencies. In or-
involved. Nevertheless, the approach also has benefits der to detect and resolve inconsistencies, all state transi-
with respect to semantic inconsistencies: it helps detecting tions are inspected, one by one.
them systematically. We start with the statecharts modeling behavior of
‘tools’ and ‘automata’ components. Recall that for all
state transitions of these statecharts, the triggered actions
3.3 The integration process
are responses (to an external actor or device) or internal
As already mentioned, statechart integration as de- actions that cause a change in the state of the system3.
scribed in this paper is a manual, method-guided process. Now every such transition is inspected by answering two
Hence, the person doing the integration needs knowledge questions: (1) Which actions must be taken by the system
about the system to be modeled or easy access to the per-
sons having this knowledge. The process consists of two 3 For the sake of simplicity, we regard events that are produced by a
state transition also to be (primitive) actions.
to produce the required response? (2) Which actions must component Vending (Fig. 2), we find that a logging action
be taken by the system to change its state properly? must be performed. We easily identify the Logging com-
Next, the statecharts modeling the behavior of ‘materi- ponent as being responsible for that action. In this compo-
als’ components are inspected. Here, the question for nent, there is an action log transaction. However, in the
every transition is: (3) Is the triggering event produced Vending statechart, the action is named log sale. Thus, we
where it should in the statecharts of the ‘tools’ and/or have a naming inconsistency which is resolved by re-
‘automata’ components? naming the event in the Vending statechart (Figure 5).
When inspecting the Logging component, we find a re-
Answering question (1). Let ti be the transition cur- quirement that aborted transactions are events which must
rently under inspection. For every action A that must be be logged (see Section 2.3). We have an action log event,
performed by the system to produce a response, identify but it is not triggered in every transition where it should
the component of the system which performs this action be: in the Vending statechart, we find two transitions where
and produces the proper response. There are three cases to a transaction is aborted, but no logging takes place.
consider: (a) the action is local, i.e. the component con- Hence, we have an information flow inconsistency: log
taining t i also performs the action, (b) there exists another event must be added to these transitions (Figure 5).
component X performing the requested action, and (c)
there is no such action. In case (a) there is nothing to inte- Vending
grate concerning action A. In case (c) we have a semantic
inconsistency which must be resolved by modifying the
inconsistent statecharts (see 3.2 above). In case (b), iden- ready
tify the state transition tx in the statechart of component X re-select ticket select ticket
that triggers action A. Check whether this statechart is register selection; register selection;
display amount display amount
currently in a state where transition t x is enabled. If not,
we again have a semantic inconsistency. If yes, check cancel OR timeout selection
clear display ;
whether the triggering event of tx is produced by ti . If this log event
is true, action A is integrated properly. If not, check
cancel OR timeout insert coin AND
whether there is a syntactic or naming inconsistency. If give money back; coin < amount insert coin AND
yes, resolve the inconsistency by restructuring or renam- clear display ; take coin; coin ≥ amount
log event display new
ing. Otherwise we have an information flow inconsis- amount
take coin;
insert coin AND clear display;
tency: The required action and its triggering internal tran- coin < amount print ticket;
sition t x exist, but ti does not produce an event that triggers take coin; payment return change
display new
it. This inconsistency is resolved by adding the missing amount insert coin AND
event to the list of events produced by ti . coin ≥ amount
Answering question (2). The process is more or less take coin;
clear display;
the same as for answering question (1). The difference is print ticket;
return change
that we do not check for responses, but for proper state
changes, i.e. the state changes must be so that scenarios
take ticket and change
being executed later behave as expected. delivery OR timeout
Answering question (3). Recall that we now inspect log transaction
the transitions of the statecharts modeling the behavior of
‘materials’ components. Let C be the component and ti the
transition currently under inspection. Look at the re- Figure 5. Additions and corrections to the Vending
quirements for C. Identify all transitions t1,...,tn in other statechart for resolving inconsistencies detected
statecharts which must trigger ti in order to satisfy the during integration (modified elements in boldface)
requirements for C. In case of perfect match (t1,...,tn all
produce an event that triggers ti ), we are done. Otherwise,
4. Conclusions
look for syntax and naming inconsistencies and resolve
them. The remaining cases are information flow incon- In this paper I have sketched an idea how to systemati-
sistencies: an event triggering ti should be produced by cally combine specifications of external and internal sys-
another transition t j , but it is not. This inconsistency is tem behavior on the basis of statechart models.
resolved by adding the missing event. To the best of my knowledge, there is no previous
Example. In our example, the integration process de- work on this kind of behavior integration. Existing work
tects and resolves the following inconsistencies. When on state machine generation/composition from scenarios
inspecting the transition from state delivery to state ready in [8], [13] focuses on transforming a requirements model of
external behavior (typically given by message sequence [4] Glinz, M., S. Berner, S. Joos (2002). Object-oriented mod-
charts) into state machines, which are typically attached to eling with ADORA. Information Systems 27, 6. 425-444.
classes in an architectural model. Viewpoint integration [5] Glinz, M. (2002). Statecharts for Requirements Specifica-
[9] is another type of integration which is not considered tion – As Simple as Possible, as Rich as Needed. 1st ICSE
here. International Workshop on Scenarios and State Machines:
SCR [7] uses an integrated behavior model, but in a Models, Algorithms and Tools, Orlando.
very specific context: SCR is based on the idea of con- [6] Harel, D. (1987). Statecharts: A Visual Formalism for
tinuously observing a set of external items (monitored Complex Systems. Science of Computer Programming 8
variables) and producing values for another set of external (1987). 231-274.
variables (controlled variables). The interaction between [7] Heitmeyer, C. (2002). Software Cost Reduction. In John J.
the environment and the system is standardized: the sys- Marciniak (ed.): Encyclopedia of Software Engineering,
tem cyclically goes through the monitored variables and 2nd edition. New York: John Wiley.
produces values for all the controlled variables according [8] Mäkinen, E., T. Systä (2001). MAS – An Interactive Syn-
to the system behavior model. thesizer to Support Behavioral Modeling in UML. Pro-
The approach described in this paper is not meant as a ceedings 23th International Conference on Software Engi-
final solution, but as a starting point for discussion and neering. 15-24.
investigation. In particular, the feasibility and usefulness [9] Nuseibeh, B., J. Kramer, A. Finkelstein (1994). A Frame-
of this approach have to be validated with real world ex- work for Expressing the Relationships Between Multiple
amples. The problem of incremental specifications has to Views in Requirements Specification. IEEE Transactions
be addressed. The combination of a behavior model as on Software Engineering 20, 10. 760-773.
described in this paper with a model of objects and object [10] Nuseibeh, B., S. Easterbrook, A. Russo (2000). Leveraging
structure should be explored. Some work has already been Inconsistency in Software Development. IEEE Computer
done in my research group [3], [4]. Currently, we are also 33, 4. 24-29.
investigating the impact of such integrated models on [11] OMG Unified Modeling Language Specification
executing behavioral system models. http://www.omg.org
[12] OMG (2003). UML 2.0 Superstructure Specification. OMG
References Final Adopted Specification, document ptc/03-08-02.
http://www.omg.org/cgi-bin/doc?ptc/2003-08-02
[1] Balzer, R. (1991). Tolerating Inconsistency. Proceedings
13th International Conference on Software Engineering. [13] Whittle, J., J. Schumann (2000). Generating Statechart
158 - 165. Designs from Scenarios. Proceedings 22th International
Conference on Software Engineering. 314-323.
[2] Glinz, M. (1995). An Integrated Formal Model of Scenar-
ios Based on Statecharts. In W. Schäfer and P. Botella [14] Züllighoven, H. (1998). Das objektorientierte Konstruk-
(eds.): Software Engineering – ESEC’95. Berlin: Springer. tionshandbuch (in German). Heidelberg: dpunkt Verlag
254-271. [English version: Object-Oriented Construction Handbook.
Morgan Kaufmann, 2004].
[3] Glinz, M. (2000). A Lightweight Approach to Consistency
of Scenarios and Class Models. Proceedings 4th IEEE In-
ternational Conference on Requirements Engineering.
Schaumburg, Ill. 49-58.