2.5 Graph Grammars - uni-paderborn.de
30
© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 2.5 Graph Grammars Part 2
Transcript of 2.5 Graph Grammars - uni-paderborn.de
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
2.5 Graph Grammars
Part 2
© P
rof.
Dr.
rer.
nat. W
. S
chäfe
r, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
PPT_Mastervorlage_Softwaretechnik_D.ppt/KS/ 12. Januar 2010 2
Übergang in die Fachdisziplinen
Implementierung einer Entwurfsumgebung
für das Systems EngineeringStudentische Hilfskraft
Voraussetzungen
■ Erfahrung in Eclipse, EMF, Modelltransformationen
■ Kenntnisse in Modellierungssprachen wie UML/SysML
■ Verschiedene Fachdisziplinen am Entwurf intelligenter technischer Systeme beteiligt
■ Verschiedene fachdisziplinspezifische Werkzeuge im Entwicklungsprozess
■ Ziel: Werkzeugkopplung über u.a. Modelltransformationen auf Basis eines abstrakten
Systemmodells
Fachdisziplinübergreifender
Systementwurf
Mechatronic Modeller,
Enterprise Architect,
Papyrus
Modelltrans-
formationen,
Austauschformate
Softwaretechnik
Regelungstechnik
Projektgruppe
Entwurfstechnik Mechatronik Jörg Holtmann
© P
rof.
Dr.
rer.
nat. W
. S
chäfe
r, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
PPT_Mastervorlage_Softwaretechnik_D.ppt/KS/ 12. Januar 2010 3
Weiterentwicklung ScenarioToolsStudentische Hilfskraft
Voraussetzungen
■ Erfahrung in Java, Eclipse, EMF, Modelltransformationen
■ Kenntnisse in Modellierungssprachen wie UML/SysML
■ Anforderungsanalyse für (Software-)Produkte, erste und kritischste Phase im
Entwicklungsprozess
■ Formale Anforderungsmodelle helfen, automatisch Fehler in Anforderungen aufzudecken
■ Ziel: Weiterentwicklung des Werkzeugs ScenarioTools zur Modellierung und Analyse von
szenariobasierten Anforderungsmodellen (ähnlich UML Sequenzdiagrammen)
Projektgruppe
Entwurfstechnik Mechatronik Jörg Holtmann
msd RemoteLockDoors
rs:
RadioSensor
bcm: Body
ControlModule
dl_driver:
DoorLock
lock
SignalSent
lock
dl_passenger:
PassDoorLock
lock
c = 0
c ≤ 100
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
4Graph Grammars - Part 2
Summary
Graph transformation rules allow us:
To describe the behavior of systems (e.g. RailCab) in an
abstract, formal way
• To model and analyze them
To describe the semantics of OO-programs
• To validate or verify them
• To model the program behavior visually (executable code
can be generated from them)
:Shuttle
:Track :Tracknext
isOnisOn
move
<<delete>>
<<create>>
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
5Graph Grammars - Part 2
Dealing with Non-Determinism
Rule application order may be non-deterministic, but…
…sometimes we need to model
Sequences of operations
Conditions and alternative operations
Iterated operations (loops)
…
Two alternative solutions:
Adapt the rules such that at any time only one of the rules is applicable (e.g. using additional conditions)
Extend the graph grammars and add control flow
Note: order of operations in one rule (e.g. created objects) remains non-deterministic
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
6Graph Grammars - Part 2
Example: Order of operations
Requirement:
Before passing a switch it has to be set correctly.
:Shuttle
:Track :Switch
:Track
:Tracknext
next
turnNext
Concrete syntax:
Abstract syntax:isOn
turnLeft = false
headLeft = true
switch state
Goal: turn left
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
7Graph Grammars - Part 2
Example: Order of operations
Requirement:
Before passing a switch it has to be set correctly.
:Shuttle
:Track :Switch
:Track
:Tracknext
next
turnNextAbstract syntax:isOn
turnLeft = false
headLeft = true
Transformation rule:
s: Shuttle
:Track :Switchnext
isOnisOn
setSwitchAndMoveOnSwitch
<<delete>>
<<create>>
turnLeft := s.headLeft
assignment
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
8Graph Grammars - Part 2
Example – Sequence of
Operations
Alternative solution idea: two rules, which are applied in a determined order
Modeling rule application sequences required
s: Shuttle
:Track :Switchnext
setSwitch
turnLeft := s.headLeft
isOn
:Shuttle
:Track :Switchnext
isOnisOn
moveOnSwitch
<<delete>>
<<create>>
next
Important: We need to re-use the previous matching to apply the move
rule. Otherwise we could move another shuttle, because of the second
rule‘s new matching.
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
9Graph Grammars - Part 2
Example: Conditional follow-
up operation
Requirement:
Depending on the switch state a shuttle has to move to the
correct outgoing track
Operations to apply depend
on a condition!
(state of the object graph)move
move to
:Shuttle
:Track :Switch
:Track
:Tracknext
next
turnNextisOn
turnLeft = true
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
10Graph Grammars - Part 2
Example: Alternative
Operations
Modeling rule application alternatives required
:TrackturnNext
:Shuttle
:Switch
isOn
isOn
leaveSwitchOnTheLeft
<<delete>>
<<create>>
:Shuttle
:Switch :Tracknext
isOnisOn
leaveSwitchOnTheRight
<<delete>>
<<create>>
:Shuttle
:Switch
checkSwitch
turnLeft = true
isOn
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
11Graph Grammars - Part 2
Graph Grammars
Example
Describing program states as graphs
Describing program behavior through graph transformations
Models and graphs
Graph grammars
Story diagrams
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
12Graph Grammars - Part 2
Story Diagrams
are a modeling language based on UML activity diagrams and so called story patterns
Activity diagrams specify control flow
Story patterns specify graph grammar rules
specify (more complex) operations on object structures
have formally defined semantics
enable code generation and verification
References:
Albert Zündorf: “Rigorous Object Oriented Software Development“, Habilitation draft,
2001
T. Fischer et al.: “Story Diagrams: A new Graph Rewrite Language based on theUnified Modeling Language“, in Proc. of the 6th International TAGT Workshop,LNCS 1764, pp. 296-309, Springer Verlag, 1998
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
13Graph Grammars - Part 2
Story Patterns
are a modeling language based on graph grammars and
UML communication diagrams
specify operations on object structures
have formally defined semantics
enable code generation and verification
:Shuttle
:Track :Tracknext
isOnisOn
move
<<delete>>
<<create>> :Shuttle
:Track :Tracknext
isOn isOn
«create»«delete»
previously introduced syntax: Story Pattern syntax:
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
14Graph Grammars - Part 2
Control Flow in Story
Diagrams
Combine UML activity diagrams and graph grammar rules:
:Shuttle
:Track :Tracknext
isOn isOn
«create»«delete»
Control flow: Graph transformation:
Sequences, loops, conditions and
alternatives
object structure modification,
attribute value changes, attribute
conditions
activity1
activity2
activity3
[condition]
[else]
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
15Graph Grammars - Part 2
Example: Control Flow
Modeling our sequence example with Story Diagrams
Story Diagram:
s: Shuttle
t: Track
sw: Switchnext
isOn
turnLeft := s.headLeft
setSwitchmoveOnSwitch
s
t sw
isOn isOn
«create»«delete»
s: Shuttle
:Track :Switchnext
setSwitch
turnLeft := s.headLeft
isOn
:Shuttle
:Track :Switchnext
isOnisOn
moveOnSwitch
<<delete>>
<<create>>
next
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
16Graph Grammars - Part 2
Example: Alternatives
Modeling alternatives with Story Diagrams
Guards success and failure:
Success: Transition fires iff previous activity has been executed successfully,
i.e. pattern completely matched and all conditions were satisfied.
shuttle: Shuttle
switch: Switch
findShuttleOnSwitch
isOn
leaveSwitchOnTheLeft
shuttle
switch left: TrackturnNext
isOn isOn
«create»«delete»
shuttle
switch right: Tracknext
isOn isOn
«create»«delete»
leaveSwitchOnTheRight
[success]
[failure]
switch
turnLeft = true
checkSwitch
[success]
[failure]
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
17Graph Grammars - Part 2
Control Flow in Story
Diagrams
Control flow in story diagrams is defined by composition
rules.
A very simple story diagram includes only one pattern,
e.g.:
Each extended (by start and end activities) Story Pattern is
a Story Diagram.
Given two or more story diagrams, they can be combined to
build a new (more complex) story diagram.
move
:Shuttle
:Track :Tracknext
isOn isOn
«create»«delete»
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
18Graph Grammars - Part 2
Sequential Composition
Sequential Composition Given two story diagrams sd1 and sd2,
then the sequential composition of sd1 and sd2 is a story
diagram, too.
sd1 sd2
sd1
sd2
composition
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
19Graph Grammars - Part 2
Sequential Composition –
Formally
Let s1 and s2 be story diagrams with only one end state
each, then the sequential composition seq(s1,s2) is a story
diagram with the semantics
appseq(s1,s2) := {(G1, G3) | G2 : (G1, G2) apps1
(G2, G3) apps2}
seq(s1,s2) is applicable s2 is applicable
application of s1
application of s2
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
20Graph Grammars - Part 2
If-Composition
If-Composition Given three story diagrams sd1, sd2, and sd3,
then the if-composition of sd1, sd2, and sd3 is a story
diagram, too.
sd1 sd2 sd3
sd1
sd2 sd3
[success] [failure]
sd1
sd2 sd3
[success] [failure]
composition
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
21Graph Grammars - Part 2
If-Composition – Formally
Let s1, s2, s3 be story diagrams with only one end state each, then the if-else-composition if_else(s1,s2,s3) is a story diagram with the semantics
appif_else(s1,s2,s3) :=
if_else(s1,s2,s3) is applicable (s1 is applicable s2 is applicable) (s1 is not applicable s3 is applicable)
appseq(s1,s2) if s1 is applicable
appseq(s1,s3) else
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
22Graph Grammars - Part 2
While-Composition
While-Composition Given three story diagrams sd1 and sd2,
then the while-composition of sd1 and sd2 is a story diagram,
too.
sd1 sd2 sd1
sd2
[success][failure]
composition
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
23Graph Grammars - Part 2
While-Composition – Formally
Let s1, s2 be story diagrams with only one end state each,
then the while-composition while(s1,s2) is a story diagram
with the semantics
appwhile(s1,s2) :=
while(s1,s2) is never applicable
apps1if s1 is not applicable
appseq(seq(s1,s2),while(s1,s2)) else
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
24Graph Grammars - Part 2
Control Flow in Story
Diagrams
Guards summary
activity
...
...
...
... ...
[success] [failure]
activity
...
... ...
[boolean expression] [else]
iterated
activity
...
...
[end]
[each time]
activity
no guardsboolean expression as a guard
pattern applicability as a guardguards determining iterated
pattern applications
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
25Graph Grammars - Part 2
Control Flow in Story
Diagrams
Other compositions
sd1 sd2
[else][boolean expression]
sd1 sd2
[else][bool. expr.1]
sd3 sdn...
[bool. expr.2] [bool. expr.3]
sd1
[else] [boolean expression]
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
26Graph Grammars - Part 2
Story Diagrams and OO
Goal: analogously to OO programming languages we want
to
Parameterize operations (method parameters)
Re-use existing operations (method calls)
Return operation results (return statements)
Refer to the context object (this-reference in Java)
Story Diagrams support all these features
Each story diagram specifies a method
has a signature and return variables comparable to methods
doSomething...
ParentType::operation(parameter1: ParameterType): ResultType
result
signature
variable name
Example:
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
27Graph Grammars - Part 2
Story Pattern Syntax –
Summary
Object variables (object nodes)
Links
name: Type
name
name: Type
name: Type
names: Type
link
link
link
«create»
«delete»
:Type bound (node is
already mapped
to an object)
un-bound
• normal
• negative
• optional
• set
(of objects)
• normal
• negative
• optional
Modifier(for nodes and links)
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
28Graph Grammars - Part 2
Story Pattern Syntax –
Summary
Attribute conditions
only objects satisfying the
condition(s) are mapped to the node
provided operators:
Attribute assignments
Constraints
Additional constraint(s) for pattern application
specified in the target programming language,
e.g. Java
name: Type
attributeName = value
name: Type
attributeName := value
{ obj.getName().equals(“Text“) }
,,,,
variable name
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
29Graph Grammars - Part 2
Story Pattern Syntax -
Summary
Collaborations (method calls)
Consecutive operation numbers determine collaborations‘
execution order
Reference to the object executing
the story pattern (or story diagram)
operation number
name
1: methodName(argument)
variable name
object variable representing
the object that the method
is called on
arrow pointing to
an object variable
this
© F
achgebie
t S
oft
ware
technik
, H
ein
z N
ixdorf
Institu
t, U
niv
ers
ität P
aderb
orn
30Graph Grammars - Part 2
Story Patterns vs.
Communication Diagrams
leave Shuttle
this
targetStation: Station position: TrackbelongsTo
atStation«create»
Passenger::leave() : void
shuttle: Shuttle
isOn
passengers
destination«delete»
«delete» A Story Diagram using
a Story Pattern
A Communication
Diagram expressing
the same operation
this
targetStation: Station position: Track
shuttle: Shuttle
1: targetStation := getDestination()
2: shuttle := getShuttle()
5: setDestination(null)
7: setAtStation(targetStation)
3: position := getTrack()
5.1: removeFromComingPassengers(this)
7.1: addToPresentPassengers(this)
4: getIsOn().equals(position))
6: removeFromPassengers(this)
passengers: HashSet
comingPassengers: HashSet presentPassengers: HashSet
5.1.1: remove(this) 7.1.1: add(this)
6.1: remove(this)
