Story Driven Modeling

Story driven modeling (SDM, [Zün01]) is an approach for the object-oriented and model- driven software development. One essential part of SDM are story diagrams [FNTZ00, Zün01] that are used in the design phase for formally specifying operations of an object- oriented program. They combine an imperative control flow specification based on UML Activity Diagrams [Gro11c] with a formal, declarative specification of object manipulation based on typed attributed graph transformations, called story patterns. Story diagrams may also be used as an endogenous in-place model transformation language [CH06] and form the basis for defining reconfiguration operations in our approach as described in Section 3.3. In the following, we give a brief overview of story patterns (cf. Section 2.3.2.1) and story diagrams (cf. Section 2.3.2.2) based on the latest version by von Detten et al. [vDHP+12a].

2.3.2.1 Story Patterns

A story pattern consists of object variables and link variables that correspond to the nodes and edges of a typed attributed graph transformation rule. Object variables and link variables are typed over a metamodel [Küh06]. Story patterns use a concise notation of the typed attributed graph transformation rule that visualizes LHS, RHS, and NACs in a single graph. As an

example, consider the story pattern in Figure 2.9 that is equivalent to the typed attributed graph transformation rule in Figure 2.8.

rc2

convoySize := convoySize + 1

rc1

ts2 : TrackSection next ► ts1 : TrackSection

▼ on ▼ on

coordinator ►«create» ◄ member«create»

◄ member

r3 : RailCab ◄ coordinator

Figure 2.9: Story Pattern

Objects variables and link variables that shall be created by the story pattern are labelled with a«create»annotation such as the link variablescoordinatorandmemberin Figure 2.9. Object variables and link variables that shall be deleted are labeled with «destroy». All object variables and link variables not carrying an annotation are not changed by the graph rewriting.

Furthermore, object variables have a binding state. In particular, we distinguish between bound and unbound object variables. An unbound object variable needs to be matched by the graph matching when the story pattern is applied. A bound object variable has already been matched to an object of the host graph during the application of another story pattern. This matching is not changed while matching the unbound object variables of the story pattern. In our example, the object variablests1,ts2, andr3are unbound, whilerc1andrc2are bound. In the concrete syntax, unbound variables visualize both, their name and their type, whereas bound variables only visualize their name.

Story patterns that are embedded in a story diagram always need to have at least one bound object variable. In addition, any unbound object variable must be reachable from at least one bound object variable by traversing link variables. The objective of this restriction is to reduce the matching effort for story patterns compared to typed attributed graph transforma- tion rules. In general, deriving a matching for a typed attributed graph transformation rule is equivalent to the NP-complete subgraph isomorphism problem and, thus, requires expo- nential runtime. The bound object variables, however, provide starting points for the graph matcher and, in combination with the type graph, reduce the number of possible matchings and, thus, the runtime for deriving a valid matching significantly [SWZ95, Zün95, pp. 195ff.]. NACs are represented by so-called negative variables that are crossed out in the concrete syntax. In our example, the negative object variablerc3and the negative link variablecoor- dinatorbetweenrc2andrc3correspond to NAC1 in Figure 2.8. They denote thatrc2does not

have a coordinatorreference to anotherRailCab. The negative link variablememberfromrc1

torc2corresponds to NAC2and defines thatrc2must not already be amemberofrc1.

Object variables may contain conditions on and assignments to object attributes as in typed attributed graph transformation rules. In our example, the value of the attribute convoySize

ofrc1is set to one. As in typed attributed graph transformation rules, conditions on object attributes are part of the LHS, while assignments to attributed values are part of the RHS.

2.3.2.2 Story Diagrams

A story diagram consists of activity nodes and activity edges for specifying the control flow such as sequential and conditional execution as well as loops. As part of this thesis, we use different kinds of activity nodes and activity edges that we illustrate below.

The kinds of activity nodes that we consider are initial nodes, final nodes, story nodes, decision nodes, activity call nodes, and statement nodes. Each story diagram contains ex- actly one initial node that marks the starting point of its execution. In addition, each story diagram has at least one final node that marks the end of its execution. A story node con- tains a story pattern and, thus, defines a modification of an object structure. Decision nodes enable to define complex branch and merge structures for the control flow. An activity call node [BvDHR11] enables to invoke another story diagram. Finally, statement nodes contain source code and may be used, for example, to define local counter variables.

rc1 as Coordinator

[failure]

startConvoy(RailCab rc1,RailCab rc2) : Boolean result

rc2

convoySize := convoySize + 1

rc1

ts2 : TrackSection next ► ts1 : TrackSection

▼ on ▼ on

coordinator ►«create»

◄ member _{result := false}

[success] result := true «create» ◄ member r3 : RailCab ◄ coordinator Call rc1.enableCoordination(); [else] [rc1.convoySize == 1]

Figure 2.10: Story Diagram with Control Flow

As an example, consider the story diagram shown in Figure 2.10. The story diagram specifies the behavior of starting a convoy. It embeds the story pattern shown in Figure 2.9 in the story node namedrc1 as Coordinator. Ifrc2is the first member ofrc1as specified by the decision node below the story node, we additionally invokeenableCoordinationonrc1via the activity call node at the bottom of the figure.

Activity edges connect the activity nodes and define how the execution of the story diagram proceeds after executing an activity node. Story diagrams support different kinds of activity edges that are distinguished by their labels in the concrete syntax. The kind and number of outgoing activity edges depend on the kind of the source activity node.

Initial nodes and activity call nodes always have exactly one outgoing default activity edge but no other outgoing activity edges. A default activity edge has no label. Final nodes have no outgoing edges. A story node may either have one outgoing default activity edge or it may have one outgoing success activity edge, identified by the label[success], and one outgoing failure activity edge, identified by the label[failure]. The success activity edge is taken if the story pattern in the story node has been matched successfully. The failure activity edge is

taken if the story pattern could not be matched. Finally, a decision node may have either one outgoing default activity edge (merge node) or it has n outgoing activity edges where n ≥ 2 (branch node). In the latter case, n − 1 of the outgoing activity edges must carry a Boolean condition, while the remaining one is an else activity edge that has the label[else]. In this case, the activity edge with a satisfied condition is executed or, if none of the Boolean conditions is fulfilled, the else activity edge is executed.

In addition to defining the control flow, the activity edges define how matchings are prop- agated through a story diagram. An initial matching of a story diagram is provided by the input parameters. The story diagram in Figure 2.10 has two input parametersrc1andrc2of typeRailCab. This matching is propagated to the story node via the default activity edge. The story pattern, which is embedded in the story node, usesrc1andrc2as bound variables. If the story pattern can be applied successfully, the matching is extended by all matched and created variables. Destroyed object variables are removed from the matching. Then, the matching is propagated via the success activity edge to the subsequent node. If the story pattern cannot be matched, the matching is propagated unmodified via the failure activity edge. Decision nodes never change a matching. The Boolean conditions at the outgoing activity edges may refer to any object variables in the current matching and to their attributes. At a final node, object variables contained in the current matching can be assigned to the output parameters. In our example, however, we only assign the literalstrue andfalseto the output parameter

resultdepending on whether the creation of the convoy was successful.

Story diagrams may be defined as an implementation of an operation of a class of the metamodel. In this case, the story diagram may be invoked by calling the operation for an object of the corresponding type. In our example in Figure 2.10, the activity call node invokes the operationenableCoordination on the objectrc1of typeRailCab. In this case,rc1serves as an implicit parameter for the story diagram and may be used as a bound variable with the namethisin the embedded story patterns.

For defining loops, story nodes may be marked as for-each story nodes. A for-each story node is iteratively applied to any matching that may be obtained for the embedded story pattern in the host graph but guarantees that no matching is used twice. A for-each story node always has one outgoing end activity edge that is taken if no further matching may be obtained for the story pattern in the for-each story node (labeled with [end]). Optionally, a for-each story node may have an additional each time activity edge (labeled with[each time]) that is taken for each matching of the embedded story pattern.

Bind each Member...

[end]

RailCab::breakConvoy()

this

member : RailCab

▼ member

… and remove it! this convoySize := convoySize – 1 member ▼ member [each time] «destroy»

Figure 2.11 shows the story diagram breakConvoy. The story diagram may be invoked on an object of typeRailCab, represented by thethis variable, for dissolving a convoy. For theRailCabthe for-each story nodeBind each member..., which is visualized with a cascaded border line, matches any member of the RailCab. For each match, we exit the for-each story node via the each time activity edge. The second story node destroys the link to themember

and decreases theconvoySizeby 1.