Turning Collaboration Diagram Strips into Storycharts
Ira Diethelm
[email protected]
Leif Geiger
[email protected]
Thomas Maier
[email protected]
Albert Zündorf
[email protected]
Dept. of Mathematics and Computer Science
University of Braunschweig, Post box 3329, 38023 Braunschweig, Germany
material
robot
assembly robot
gate
shuttle
track
Figure 1. Components of the material flow system example
1.
Introduction
Our approach assumes that system development starts
with requirements elicitation creating some textual usecase descriptions. In the analysis phase, use-cases are
refined using sequences of collaboration diagrams
illustrating the use-case execution step by step. These
collaboration diagram strips outline basic conceptual
ideas about the object structures employed by the desired
application and how these object structures are used to
achieve the desired behavior. In the design phase, these
sample scenarios are analyzed and detailed behavior
specifications of the participating active objects are
created. In our approach we use statecharts to specify the
behavior of active objects and so-called story patterns to
model do actions that perform complex modifications of
the employed object structure. The resulting
combinations of statecharts and story patterns are called
storycharts.
In the implementation phase, such storycharts need to be
implemented. In our approach, we employ the Fujaba
CASE tool to generate Java implementations from
storycharts, automatically, cf. [KNNZ00]. To realize the
reactive behavior of a storychart, Fujaba generates a
table driven implementation. For story patterns like the
one shown in state 2 of Figure 3 Fujaba generates
standard Java code. This standard Java code employs
operations like t1=this.getAt () or t2=t1.getNext() in order
to fill the story pattern variables with appropriate values.
Operations like this.setAt(null) and this.setAt(t2) are used
to destroy or create links, respectively.
Thus, in our approach, the derivation of storycharts from
strips of collaboration diagrams is the central realization
activity. To facilitate this realization step, this paper
proposes a systematic approach how to turn strips of
collaboration diagrams into storycharts. So far, this
technique is employed manually. However, we discuss a
tool based approach that assists the developer within the
storychart derivation process and we will identify steps
that are easily automated and steps that are not easily
automated. The implementation of the described tool
support is current work.
To illustrate our approach, we use the simulation of a
material flow system, that has served as a CASE study
for the ISILEIT project at University of Paderborn. This
material flow system employs autonomous shuttles that
travel on a system of tracks. These shuttles represent
production agents that have the task to collect material
and to visit assembly robots that perform certain
production steps and finally to deliver the produced
goods. Figure 1 shows a schematic view of such a
production site.
In our example, we model shuttles and assembly robots
as active objects that are controlled by Statecharts. Our
task is now to create these Statecharts.
2.
Collaboration Diagram Strips
During the analysis phase the developer revisits the
textual scenario descriptions of the requirements phase
and creates (series of) collaboration diagrams (or
sequence diagrams).
Figure 2 shows a strip of collaboration diagrams that
outline use case assign duties for our material flow system
example. Note, we embed the collaboration diagrams of
a single scenario into a simple activity diagram. This
allows to arrange the different collaboration diagrams
more flexibly. The first activity/collaboration diagram of
Figure 2 outlines an initial object structure that
represents the topology of our production site. This
initial object structure employs a circular list of Track
objects and three Robot objects and one Shuttle object
located at certain tracks.
Step 1 of our scenario shows how some dispatcher sends
an assign message to shuttle s1. This has the effect, that
the message parameter “key” is stored within the task
attribute of shuttle s1. Step 2 shows, how the shuttle
moves from (its current location at) track t1 to track t2.
This is achieved by removing the at link between shuttle
s1 and track t1 and by creating a new at link between the
shuttle and track t2. This is repeated within step 3.
Now our shuttle has reached track t3. Track t3 hosts
assembly robot r1 with task attribute “loader”. This
enables our shuttle to send a fetch message to this robot,
cf. step 4. In response, assembly robot r1 creates a good
object g1 with the kind attribute set to “steel”. This new
good object is connected to shuttle s1 via a carries link.
Finally, robot r1 acknowledges the received messages by
sending a goOn message back to shuttle s1. In step 5,
shuttle s1 moves again. The next steps are omitted since
they are similar to the preceding step.
In step 8, shuttle s1 has reached track t6 where assembly
robot r2 is located. Our shuttle sends a produce message
to the “produce” robot, passing the desired good kind
“key” as parameter. This forces robot r2 to destroy the
carries link between s1 and g1 and to create a holds link
between the good and itself and to return a goOn
message to shuttle s1. In subsequent (omitted) steps the
assembly robot turns the “steel” material into a “key”
good. This key is loaded on the shuttle and the shuttle
travels to robot r3, where the manufactured key is stored.
Note, our approach employs a large number of relatively
small collaboration diagrams. Any time, a collaboration
message is shown, we assume, that the receiving object
becomes active and that the subsequent effects describe
the reaction of the receiving object. Such effects are
changes of attribute values, creation and removal of
objects and links, and additional collaboration messages.
However, we assume that the effects of such subsequent
messages are not shown within the same collaboration
diagram. Actually, this restricts subsequent messages to a
simple return as used e.g. in step 4 and 8. The reaction of
shuttle s1 to this return are shown in the subsequent
step(s). This restriction allows us to compute the actions
of the message receiver, easily. However, it forces the
developer to split complex collaborations employing
multiple messages into sequences of collaboration
diagrams, roughly one per message. This restriction is
discussed at the end of our paper.
If a collaboration diagram contains no collaboration
message, we assume, that the active object of the
preceding step is still active and the depicted object
structure changes are part of its ongoing activities. Thus,
in our example the assign message in step 1 turns shuttle
s1 into the active object. Shuttle s1 remains active during
steps 2 and 3. In step 4, shuttle s1 sends a fetch message
to robot r1. Thus the object structure changes and the
subsequent goOn message shown in step 4 are executed
by robot r1. However, the final goOn message of step 4
returns the execution control to shuttle s1 and thus step 5
is executed by our shuttle.
scenario assign duties
init:
at
r1 :Robot
next >
t3 :Track
next >
t4 :Track
^ next
task == "loader"
next v
t2 :Track
t6 :Track
s1 :Shuttle
^ next
at
r2 :Robot
task == "producer"
next v
at
t1 :Track
r3 :Robot
t5 :Track
t7 :Track
^ next
at
task == "storage"
t10 :Track
< next
t9 :Track
< next
step 1:
t8 :Track
step 2:
t2 :Track
s1 :Shuttle
assign ("key")
task := "key"
^ next
d1 : Dispatcher
t1 :Track
step 4:
at
«create»
«destroy»
at
s1 :Shuttle
fetch ("steel")
step 3:
s1 :Shuttle
r1 :Robot
at
«create»
t3 :Track
^ next
t3 :Track
kind := "steel"
step 8:
next >
«destroy»
g1 :Good
carries
«create»
«create»
at
g1 :Good
step 5:
t3 :Track
at
task == "loader"
s1 :Shuttle
«destroy»
at
t2 :Track
1: goOn ()
at
carries
produce ("key")
t4 :Track
at
«create»
...
at
carries
s1 :Shuttle
...
1: goOn ()
s1 :Shuttle
t6 :Track
r1 :Robot
at
task == "producer"
holds
«destroy»
g1 :Good
«create»
Figure 2. Collaboration Diagram Strip for Use-Case assign
3.
Deriving Storycharts
As discussed, our approach employs fairly simple
collaboration diagrams that show (at most) one
collaboration messages and the response of the message
receiver to this message. This enables us to compute the
response to the reception of a collaboration message
easily. In addition, our collaboration diagrams are
embedded into an activity diagram modeling the overall
control flow. These properties allow us to employ
techniques similar to the algorithm of the SCED system
[KMST94] for the derivation of a statechart specification
from several sample scenarios.
Basically, we assume, that initially all active objects are
in some waiting state. A collaboration message within a
collaboration diagram cd1 is turned into a statechart
transition T labeled with the corresponding message
name. This transition leaves the “current” state of the
corresponding object and reaches some new state ns. The
do action of this new state is composed from the effects
that are shown in the collaboration diagram cd1. If the
statechart already contains a state os with a “similar”
do action, then we do not create a new state but transtion
T is connected to the already existing state os. In some
cases this reuse of old states may result in conflicts
where one state gets multiple outgoing transitions with
the same label (or without a label) but different target
states. In such cases we need either some guard condition
that allows to distinguish between the alternatives or the
corresponding reuse of an old state during transition
creation was erroneous. In the later case, we use
backtracking to correct this mistake. Instead of reusing
an existing state we create a new state.
In our approach, we use so-called story patterns to model
the do actions of statecharts. Story patterns are a special
kind of collaboration diagrams. However, while a
collaboration diagram describes a certain sample
scenario, a story pattern specifies an executable program
operation. Boxes within a story pattern correspond to
variables employed in the corresponding program
fragment. To avoid confusion, a box employed within a
story pattern is called a story variable. Links within a
story pattern define constraints on the values of the
corresponding story variables. In our approach, story
patterns may be embedded into statechart states as
specifications of do actions.
Figure 3 and 4 show two storycharts for the classes
Shuttle and Robot , respectively. These storycharts are
systematically derived from the scenario description of
Figure 2. We hope that we will be able to automate most
parts of this derivation process. However, for some steps
we do not yet know, how this can be achieved, if at all.
In the following, we outline our current ideas for a
derivation process for storycharts. We will indicate steps
that may be difficult to automate as steps that may
require human assistance.
At the start of the derivation process, we create one
statechart for each message receiving object employed in
our example scenario. For Figure 1 we thus create one
statechart sc1 for shuttle s1 and a second statechart sc2
for robot r1 and a third statechart sc3 for robot r2. All
storycharts get an initial waiting state. Then, we walk
through our sample scenario(s). In step 1 of Figure 2
some dispatcher sends an assign message to shuttle s1.
Thus, in statechart sc1 we create an assign transition
leaving the waiting state. As shown in step 1 of Figure 2,
shuttle s1 reacts to the reception of the assign message
by storing the message parameter in its task attribute.
This may be programmed using a story pattern consisting
just of story variable this (denoting the executing object
itself) and an appropriate assignment within the attribute
compartment of story variable this , cf. state 1 of Figure 3.
Note, the identification of message parameter value “key”
and assignment value “key” may require human
assistance.
Next we consider step 2 of Figure 2. Step 2 does not
contain a collaboration message. Thus, it still describes
reactions to the assign message. This case is handled by
creating a triggerless transition leaving the current state
(state 1) of the object in charge (shuttle s1). The story
pattern of the new state 2,3 is derived from the
collaboration diagram of step 2 by turning the shuttle
object into story variable this and all other objects into
story variables of the corresponding type. Note, we
replace the object identifiers t1 and t2 with some
artificial story variable names tx and ty in order to
emphasize the difference. The links shown in the
collaboration diagram are just transferred to the
corresponding story variables.
Let us now consider step 3 of Figure 2. Again, step 3
contains no collaboration message and thus we create a
triggerless transition tlt2 leaving state 2,3. The story
pattern that is derived from step 3 looks very similar to
the one employed in state 2,3. Actually, steps 2 and 3
employ isomorphic object structures and thus the
resulting story patterns are isomorphic, too. This means,
the story patterns may only differ in the artificial names
that are introduced. If we detect the similarity between
these two story patterns, we direct the new triggerless
transition tlt2 to the already existing state 2,3, cf. the
crossed out transition on top of state 2,3. (This transition
is crossed out, because it will be cancelled in a later
step.)
Note, in principle it is possible to identify an
isomorphism
between
two
object
structures,
automatically. Although this is an NP problem, the
object structures are usually pretty small and in our case
Statechart for class Shuttle
state 1:
this
assign (param)
waiting
task := param
...
goOn ()
state 2,3:
state 8a:
at
ty :Track
^ next
tx :Track
this
at
t :Track
this
«destroy»
at
1: produce (this.task)
[failure]
state 5,...:
1: fetch ("steel")
tx :Track
goOn ()
r :Robot
task == "loader"
r :Robot
task == "producer"
«create»
[failure]
state 4a:
at
at
at
this
next >
at
«destroy»
t :Track
g :Good
carries
ty :Track
at
«create»
this
Figure 3. Derived Storychart for Class Shuttle
this seems to be one of these “harmless” NP problems.
However, in practical examples the considered
collaboration diagrams or story patterns are very likely
not fully isomorphic but they may show some
differences. One collaboration diagram may employ an
additional link or attribute that is not used within the
other although both describe the “same” operation. Thus,
this step may require human assistance.
Step 4 of Figure 2 shows a new collaboration message
send to robot r1. Thus, we look up storychart sc2 for the
first time. We create a fetch transition and derive state 4b
in Figure 4 as discussed. However, shuttle s1 has to send
the fetch message to robot r1, first. Thus, we need a
corresponding do action within an additional state 4a of
statechart sc1 of our shuttle s1, cf. Figure 3. To send a
message to some other object, this other object must be
known by the sender. To ensure this, we copy the
collaboration diagram of step 4 without the effects of the
message into state 4a . This means, we omit all destroy
operations and all created elements and all subsequent
message invocations. State 4a is a successor step of state
2,3 . Thus we create a triggerless transition from state 2,3
to state 4a .
The transition from state 2,3 to state 4a creates a new
problem. State 2,3 has now two outgoing triggerless
transitions with different targets (the transition from state
2,3 to itself and the transition to state 4a ). The SCED
algorithm would resolve this conflict using backtracking.
It would split state 2,3 into a sequence of two different
states with similar story patterns and the second of these
states would get a single outgoing transition to state 4a .
We think that this is a weakness of the SCED algorithm
that is caused by unsuccessful testing steps that are
omitted in the provided scenario until the desired
situation is reached. If we assume, that after any move
from some track tx to the next track ty , the shuttle tries to
find a “loader” robot at the reached track, then state 2,3 is
always followed by step 4a. And in case of failure we go
back to state 2,3. According to these assumptions the
self-transition on state 2,3 is crossed out. Instead, we
Statechart for class Robot
fetch (param1)
state 4b:
task == "loader"
at
1: goOn ()
s1 :Shuttle
at
t :Track
produce (param2)
state 8b:
1: goOn ()
this
waiting
carries
«create»
«create»
s1 :Shuttle
carries
at
t :Track
this
at
task == "producer"
holds
«destroy»
g1 :Good
g1 :Good
«create»
kind := param1
...
Figure 4. Derived Storychart for Class Robot
create a [failure] transition from state 4a to state 2,3.
Note, these rearrangements of transitions may require
human assistance.
If the do action of State 4a is successful, it sends a fetch
message to robot r. As shown in state 4b of Figure 4 and
in step 4 of Figure 2, the robot will return a goOn
message. In Figure 3 this goOn message creates a goOn
transition leaving state 4a . Step 5 of Figure 2 differs
from step 2 and 3 in the additional Good object. Thus,
the goOn transition leaving state 4a may not target state
2,3 but a new state 5,… is derived from step 5.
Step 8 is handled similarly to step 4. This creates state 8a
in Figure 3 and state 8b in Figure 4. Actually, state 4b is
added to statechart sc2 of robot r1 and state 8b is added
to statechart sc3 of robot r2. The statechart shown in
Figure 4 results from a merge of statecharts sc2 and sc3.
This merging of statecharts may again cause problems
that need human assistance.
4.
Conclusions
This paper describes a systematic approach for the
derivation of storycharts from sample scenarios that are
described by strips of collaboration diagrams. We
employ a basic technique that is inspired by algorithms
that turn sequence diagrams or message sequence charts
into statecharts, e.g. [KMST94, MS01]. These
approaches identify scenario steps with similar actions
and map them into common statechart states. Our
approach employs these ideas by identifying
collaboration diagrams with similar / isomorphic
structures. Similar collaboration diagrams are mapped
...
into the story pattern of a common storychart state. The
story patterns are derived from the scenario collaboration
diagrams by requiring that the collaboration diagram
contains only one message and by assuming that all
shown effects are the response to this message.
Tool support for this mechanism is current work. The
SCED like parts are already realized. The difficult steps
identified in this paper will need further research.
However, we hope that the resulting tool support
provides valuable assistance for the central activity of
deriving behavior specifications from sample scenarios
within our approach.
References
[KMST94] K. Koskimies, T. Männistö, T. Systä, J. Tuomi:
SCED - An environment for dynamic modeling in objectoriented software construction; Proc. Nordic Workshop on
Programming Environment Research '94 (NWPER '94),
Lund, Department of Computer Science, Lund University,
pp. 217-230, June 1994.
[KNNZ00] H.-J. Köhler, U. Nickel, J. Niere, A. Zündorf:
Integrating UML Diagrams for Production Control
Systems; Proc. 22nd International Conference on Software
Engineering (ICSE 2000), Limerick, Ireland, pp. 241-251,
acm press, 2000.
[MS01] E. Mäkinen, T. Systä: MAS – An Interactive
Synthesizer to Support Behavioral Modeling in UML; Proc.
23rd International Conference on Software Engineering
(ICSE 2001), Toronto, Canada, acm press, 2001.