2.4 Graph Grammars Part 2

Transcription

1 2.4 Graph Grammars Part 2

2 Studentische Hilfskraft (m/w) MBSE mit UML/SysML Themengebiet: Model-Based Systems Engineering Die Entwicklung mechatronischer Systeme erfordert das Zusammenarbeiten verschiedenster Fachdisziplinen. Wir arbeiten daran, diese Zusammenarbeit mit Hilfe von Modellen zu verbessen Deine Aufgaben Weiterentwicklung Eclipse-basierter Werkzeuge zur Systemmodellierung Umgang mit UML/SysML Modellen und Umsetzung in EMF Voraussetzungen Erfahrungen in Java-Programmierung und Eclipse Gute Deutsch- und Englischkenntnisse Bewerbung an: Fraunhofer IPT / Heinz Nixdorf Institut Folie 2

3 SHK-Stelle bei Fraunhofer Entwicklungsmethoden für sichere Automobilsoftware Entwicklung von Eclipse-Plugins mit Java, XML, EMF, Xtext, UML/SysML, Mitarbeit in Kundenprojekten mit Automobilzulieferern Bachelor-/Masterarbeit im gleichen Themengebiet möglich Bewerbung an: Markus Fockel Raum ZM Fraunhofer IPT / Heinz Nixdorf Institut Folie 3

4 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) move :Shuttle <<delete>> next <<create>> 4

5 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 5

6 Example: Order of operations Requirement: Before passing a switch it has to be set correctly. Goal: turn left switch state Concrete syntax: Abstract syntax: :Shuttle headleft = true next turnnext :Switch turnleft = false next 6

7 Example: Order of operations Requirement: Before passing a switch it has to be set correctly. :Shuttle Abstract syntax: headleft = true turnnext Transformation rule: next :Switch turnleft = false next setswitchandmoveonswitch s: Shuttle <<create>> <<delete>> next :Switch turnleft := s.headleft assignment 7

8 Example Sequence of Operations Alternative solution idea: two rules, which are applied in a determined order Modeling rule application sequences required setswitch moveonswitch s: Shuttle next :Switch turnleft := s.headleft next :Shuttle <<delete>> next <<create>> :Switch 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. 8

9 Example: Conditional followup 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) next move :Shuttle :Switch turnleft = true move to turnnext next 9

10 Example: Alternative Operations Modeling rule application alternatives required leaveswitchontheright :Shuttle <<create>> checkswitch :Shuttle :Switch turnleft = true <<delete>> :Switch next leaveswitchontheleft :Shuttle <<create>> <<delete>> :Switch turnnext 10

11 Graph Grammars Example Describing program states as graphs Describing program behavior through graph transformations Models and graphs Graph grammars Story diagrams 11

12 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 the Unified Modeling Language, in Proc. of the 6 th International TAGT Workshop, LNCS 1764, pp , Springer Verlag,

13 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 previously introduced syntax: move :Shuttle <<create>> <<delete>> next Story Pattern syntax: :Shuttle «delete» «create» next 13

14 Control Flow in Story Diagrams Combine UML activity diagrams and graph grammar rules: Control flow: Graph transformation: [condition] activity3 activity1 activity2 [else] Sequences, loops, conditions and alternatives :Shuttle «delete» next «create» object structure modification, attribute value changes, attribute conditions 14

15 Example: Control Flow Modeling our sequence example with Story Diagrams setswitch s: Shuttle moveonswitch :Shuttle <<create>> next <<delete>> next :Switch next :Switch Story Diagram: s: Shuttle t: Track turnleft := s.headleft setswitch sw: Switch next turnleft := s.headleft moveonswitch s «delete» «create» t sw 15

16 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. findshuttleonswitch shuttle: Shuttle switch: Switch [success] checkswitch switch turnleft = true [failure] [failure] [success] shuttle switch shuttle switch leaveswitchontheright «delete» leaveswitchontheleft «delete» next turnnext right: Track left: Track «create» «create» 16

17 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. :Shuttle «delete» move next «create» 17

18 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 composition sd1 sd2 18

19 Sequential Composition Formally Let s 1 and s 2 be story diagrams with only one end state each, then the sequential composition seq(s 1,s 2 ) is a story diagram with the semantics app seq(s1,s 2 ) := {(G 1, G 3 ) G 2 : (G 1, G 2 ) app s1 (G 2, G 3 ) app s2 } seq(s 1,s 2 ) is applicable s 2 is applicable application of s 1 application of s 2 19

20 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 composition [success] sd2 sd1 [failure] sd3 [success] sd2 sd1 [failure] sd3 20

21 If-Composition Formally Let s 1, s 2, s 3 be story diagrams with only one end state each, then the if-else-composition if_else(s 1,s 2,s 3 ) is a story diagram with the semantics app seq(s1,s 2 ) if s 1 is applicable app if_else(s1,s 2,s 3 ) := app seq(s1,s 3 ) else if_else(s 1,s 2,s 3 ) is applicable (s 1 is applicable s 2 is applicable) (s 1 is not applicable s 3 is applicable) 21

22 While-Composition While-Composition Given two story diagrams sd1 and sd2, then the while-composition of sd1 and sd2 is a story diagram, too. sd1 sd2 composition [failure] sd1 [success] sd2 22

23 While-Composition Formally Let s 1, s 2 be story diagrams with only one end state each, then the while-composition while(s 1,s 2 ) is a story diagram with the semantics app s1 if s 1 is not applicable app while(s1,s 2 ) := app seq (seq(s 1,s 2 ),while(s 1,s 2 )) while(s 1,s 2 ) is never applicable else 23

24 Control Flow in Story Diagrams Guards summary activity [boolean expression] [else]... no guards... activity [success] [failure] pattern applicability as a guard... iterated activity [end] boolean expression as a guard [each time] activity guards determining iterated pattern applications 24

25 Control Flow in Story Diagrams Other compositions [boolean expression] [else] [bool. expr.1] [bool. expr.2] [bool. expr.3] [else] sd1 sd2 sd1 sd2 sd3... sdn [else] [boolean expression] sd1 25

26 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 Example: Each story diagram specifies a method has a signature and return variables comparable to methods ParentType::operation(parameter1: ParameterType): ResultType signature dosomething... result variable name 26

27 Story Pattern Syntax Summary Object variables (object nodes) normal negative optional set (of objects) Links normal negative optional name name: Type name: Type name: Type names: Type link link link :Type bound (node is already mapped to an object) un-bound Modifier (for nodes and links) «create» «delete» 27

28 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 28

29 Story Pattern Syntax - Summary Collaborations (method calls) Consecutive operation numbers determine collaborations execution order operation number variable name arrow pointing to an object variable Reference to the object executing the story pattern (or story diagram) 1: methodname(argument) name object variable representing the object that the method is called on this 29

30 Story Patterns vs. Communication Diagrams Passenger::leave() : void «create» atstation this «delete» destination leave Shuttle «delete» passengers shuttle: Shuttle A Story Diagram using a Story Pattern targetstation: Station belongsto position: Track A Communication Diagram expressing the same operation 1: targetstation := getdestination() 2: shuttle := getshuttle() 5: setdestination(null) 7: setatstation(targetstation) 4: getison().equals(position)) 6: removefrompassengers(this) this targetstation: Station 3: position := gettrack() 5.1: removefromcomingpassengers(this) 7.1: addtopresentpassengers(this) 5.1.1: remove(this) 7.1.1: add(this) comingpassengers: HashSet presentpassengers: HashSet passengers: HashSet shuttle: Shuttle position: Track 6.1: remove(this) 30

31 Control Structures in Henshin Source: