Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn. 3. Code Generation

Transcription

1 3.

2 Motivation So far: Techniques for the design phase But: Implementation needed Implementation is Time consuming Error prone Necessary for each target language if done by hand Programmers make errors nondeterministicly analysis coarse design detailed design use cases test cases test cases implementation test cases modul test integration test [Broehl1993] system test acceptance test 2

3 Motivation Thus: Automatically generated code Reduced implementation effort Fewer implementation errors Errors are made deterministically and can thus be corrected systematically V-Model becomes Y-Model 3

4 V-Model vs. Y-Model V-Model Manual implementation Takes longer Phase Y-Model Use Time for implementation tends to 0 Phase analysis coarse design detailed design use cases test cases test cases implementation test cases modul test integration test acceptance test system test time analysis coarse design detailed design use cases test cases test cases code generation integration test acceptance test system test time 4

5 Motivation More advantages: (mainly) working on design level (with models) Reduced complexity Models can be verified (see chapter 5) Improved maintainability and readability of generated code Reason: sometimes code has to be reviewed or adapted manually Integration with frameworks, platforms, etc. Manual code optimization (e.g. for efficiency) No differences in code style Code can be generated for multiple target languages Important for embedded systems 5

6 General Procedure 6

7 Overview 1. for structural elements 1. Classes 2. Inheritance 3. Associations 2. for behavioral elements 1. Activity Diagrams 2. Story Diagrams 3. State Machines 7

8 1.1 Classes, Attributes and Methods Design Level Class Diagram Code Level Class Diagram Generated Source Code class Shuttle { Shuttle + speed: float + name: String + calculatedistance(loc: Location) : float Standard constructors and access methods are omitted at design level Public attributes are replaced by private fields and public access methods (information hiding principle) attribute types should be primitive (int, float, ) or immutable (String, Date, ) otherwise use an association Shuttle - speed: float - name: String + getspeed() : float + setspeed(speed: float) : void + getname() : String + setname(name: String) : void + calculatedistance(loc: Location) : float public Shuttle() { private float speed; public float getspeed() { return this.speed; public void setspeed(float speed) { this.speed = speed; private String name; public String getname() { return this.name; public void setname(string name) { this.name = name; public float calculatedistance(location loc) { 8

9 1.2 Inheritance and Templates Inheritance (in Java) Vehicle Single Inheritance only Multiple Interfaces Use composition instead of multiple inheritance Mechatronic System «interface» Autonomous Shuttle «interface» Selfoptimizing Templates / Generics Use type parameters Set + contains(element: T) : boolean + add(element: T) : void + remove(element: T) : void Code generation T class Shuttle extends MechatronicSystem implements Autonomous, Selfoptimizing{ private ShuttleDrive drive; public Shuttle(){ super(); drive = new ShuttleDrive(); Vehicle ShuttleDrive 1 drive Mechatronic System «interface» Autonomous Shuttle class Set<T> { public boolean contains(t element){ public void add(t element){ public void remove(t element){ «interface» Selfoptimizing 9

10 1.3 Bidirectional Associations Remember 2 nd lecture Registrar registrar 0..1 shuttles * Shuttle public class Registrar { private HashSet shuttles; public boolean addtoshuttles(shuttle value) { value.setregistrar(this); public boolean removefromshuttles(shuttle value) { boolean changed = false; if ((this.shuttles!= null) && (value!= null)) { changed = this.shuttles.remove (value); if (changed) { value.setregistrar (null); return changed; Consistency has to be ensured public class Shuttle { private Registrar registrar; public boolean setregistrar(registrar value) { boolean changed = false; if (this.registrar!= value) { if (this.registrar!= null) { Registrar oldvalue = this.registrar; this.registrar = null; oldvalue.removefromshuttles(this); this.registrar = value; if (value!= null) { value.addtoshuttles(this); changed = true; return changed; 10

11 1.3 Composition and Aggregation 1 ShuttleFrame class Shuttle { Shuttle Composition (black diamond) Existence dependency ( consists of ) Create parts in constructor Delete parts when whole is deleted Private set-, add-, and remove-methods (or none) Aggregation (white diamond) Close relationship Not necessarily reflected in code (only a comment at design level) * Wheel public Shuttle() { setframe(new Frame()); addtowheels(new Wheel()); addtowheels(new Wheel()); public Frame getframe() { private void setframe(frame frame) { public void addtowheels(wheel w) { public void removefromwheels(wheel w) { public removeyou() { frame.removeyou(); setframe(null); for(wheel w : wheels) { removefromwheels(w); 11

12 1.3 Ordered and qualified Associations Ordered Association Shuttle Implemented as list Alternative: {sorted, implemented as tree set Qualified Association Shuttle Destination Implemented as hash map id : int {ordered * 0..1 Component class Shuttle { private LinkedList destinations = new LinkedList(); public Destination getfirstfromdestinations() { public void addtodestinations(int position, Destination dest) { class Shuttle { private HashMap components = new HashMap(); public Component getfromcomponents(int id) { public void addtocomponents(int id, Component comp) { 12

13 2.1 Activity Diagrams Activity Diagram specifies single method (Well-formed) Control flow maps to (Java) control structures Actions / guards translate directly to code (makes diagrams language dependent) Shuttle::goto(destination : Track) Track currenttrack = this.gettrack(); [currenttrack == destination] [else] currenttrack = currenttrack.getneighbortowards(destination); this.settrack(currenttrack); class Shuttle { public void goto(track destination) { Track currenttrack = this.gettrack(); while(!currenttrack == destination){ currenttrack = currenttrack. getneighbortowards(destination); this.settrack(currenttrack); 13

14 2.1 Well-formed control flow Most well-formed activity diagrams can be generated by the following graph grammar Maps directly to Java control structures Start Graph a1 a2 Sequence ::= a1 a3 a2 Inserts an activity between two others a1 a2 Branch ::= a1 a2 Adds another transition between two activities See: A. Zündorf, Rigorous Object Oriented Software Development, Habilitation Thesis, 2001 a1 Loop ::= a1 Adds a self-transition to an activity In more detail: T. Klein, Rekonstruktion von UML-Aktivitäts- und Kollaborationsdiagrammen aus Java-Quelltexten, Diploma Thesis,

15 2.1 Non-well-formed control flow If control flow cannot be mapped to nested control structures Reduce to well-formed control flow or Number activities and simulate with while and switch constructs [cond1] [cond2] a1 a2 a3 a4 Class1::m1() [else] [else] class Class1 { public void m1 () { step = 1; while (step!= 5) { switch (step) { case 1: a1; step = 2; break; case 2: a2; step = 3; break; case 3: a3; if (cond1) step = 4; else step = 1; break; case 4: a4; if (cond2) step = 5; else step = 2; break; 15

16 2.2 Story Diagrams Story Diagram in Fujaba4Eclipse 16

17 2.2 Code translation strategy for story diagrams 1. Declare local variables 2. Identify participants 1. via to-one links (using get-methods or special collection accesses) 2. via to-many links (using nested while(!found) loops) 3. check constraints 3. Execute object modifications 1. Deletions 2. Creations 3. Attribute assignments 4. Translate collaboration statements according to sequence numbers See: A. Zündorf, Graph Pattern Matching in PROGRES, Springer, 1996 T. Fischer, J. Niere, L. Torunski, A.Zündorf, Story Diagrams: A new Graph Rewrite Language based on the Unified Modeling Language, Springer,

18 2.2 Generated Java code for story diagrams public class Shuttle { JavaSDM.ensure( ) throws a JavaSDM- Exception if the given expression is not true public void goto(track destination) { boolean fujaba Success = false; Track currenttrack = null; try { fujaba Success = false; // check object destination is really bound JavaSDM.ensure(destination!= null); // bind currenttrack: Track currenttrack = this.gettarget(); JavaSDM.ensure(currentTrack!= null); // check isomorphic binding JavaSDM.ensure(!(destination.equals(currentTrack))); // delete link this.settarget(null); // create link this.settarget(destination); fujaba Success = true ; catch(javasdmexception fujaba InternalException) { fujaba Success = false ; 18

19 Activity Diagrams vs. State Machines Activity Diagrams No concurrency (except for local concurrency) Concrete behavior expressed by story patterns or program code Sequential control flow (usually for a single method) State Machines React to events from other processes/threads Hierarchical Memory: history states Control flow usually for whole classes/components 19

20 2.3 State Machines Example: Shuttle behavior specified by a state machine Waiting assign(source, target) Active reactivate Halted emergencystop H* GoToSource destinationreached Fetch fetched GoToTarget destinationreached Deliver delivered assign(source, target) How could the corresponding (generated) code look like? 20

21 Strategy 1: Switch-Statements Halted Waiting reactivate emergencystop Implement one method for each event Redundant state checks in each method Code duplication maintenance problems assign(source, target) H* Active GoToSource Fetch GoToTarget Deliver destinationreached fetched destinationreached delivered assign(source, target) class Shuttle { public void assign (Track source, Track target) { switch(currentstate) { case WAITING: setsource(source); settarget(target); currentstate = GOTOSOURCE; gototrack(source); break; case GOTOSOURCE: setsource(source); settarget(target); currentstate = GOTOSOURCE; gototrack(source); break; case FETCH: setsource(source); settarget(target); currentstate = GOTOSOURCE; gototrack(source); break; case HALTED: /* ignore call */ break; 21

22 Strategy 2: State Design Pattern Shuttle + assign(track source, Track target) : Void + emergencystop() : Void + reactivate() : Void + setsource(track source) : Void + settarget(track target) : Void + gototrack(track track) : Void shuttle 0..1 shuttle 0..1 currentstate 1 historyofactive 1 ShuttleState + assign(track source, Track target) : Void + emergencystop() : Void + reactivate() : Void Waiting Active Halted Halted Waiting reactivate emergencystop assign(source, target) H* Active GoToSource Fetch GoToTarget Deliver destinationreached fetched destinationreached delivered + assign(track source, Track target) : Void assign(source, target) GoToSource + destinationreached() + assign(track source, Track target) : Void + emergencystop() : Void Fetch + fetched() + reactivate() One class for each state Events represented by methods Each class implements only methods for events it reacts to Nested states realized through inheritance Cmp. [Gamma et al.: Design Patterns, 1995] 22

23 Strategy 2: State Design Pattern Modeling behavior with story diagrams Shuttle class delegates the event handling to the current state Shuttle + assign(track source, Track target) : Void + emergencystop() : Void + reactivate() : Void + setsource(track source) : Void + settarget(track target) : Void + gototrack(track track) : Void shuttle 0..1 shuttle 0..1 currentstate 1 historyofactive 1 ShuttleState + assign(track source, Track target) : Void + emergencystop() : Void + reactivate() : Void Shuttle::assign (source : Track, target : Track) this currentstate 1 : assign(source, target) state : ShuttleState Waiting + assign(track source, Track target) : Void GoToSource + destinationreached() Active + assign(track source, Track target) : Void + emergencystop() : Void Fetch + fetched() Halted + reactivate() 23

24 Strategy 2: State Design Pattern Modeling behavior with story diagrams (continued) Abstract ShuttleState class contains an empty assign method (default implementation) The concrete state classes implement the state changes, e.g. Waiting class switches to state GoToSource Corresponding actions for the state are modelled by method calls, e.g. gototrack Waiting::assign (source : Track, target : Track) 1 : gototrack(source) ShuttleState::assign (source : Track, target : Track) <<create>> source source s : Shuttle <<create>> target currentstate <<create>> target currentstate <<delete>> this : GoToSource 24

25 Strategy 2: State Design Pattern Summary Object-oriented replacement of switch statements Class structure reflects the state machine s structure + Maintainability increased (compared to switch statements) + Elegant handling of nested states - Many quite small classes (one for each state) - State machine adaption requires re-implementation of state classes 25

26 Strategy 3: State Table Idea Shuttle Originally: use a table with all possible transitions for the current state Separate the state machine execution from a state machine s behavior Use a framework implementation to load arbitrary state machine models and execute them ReactiveSystem + initstatemachine : Void + run() : Void + handleevent() : Void + invoke(method m, Object[] args) : Object currentstate 1 State - name : String - entryaction : Method - exitaction : Method + gettransition(event : Event) : Transition + enter(event : Event) : Void + leave(event : Event) : Void e : Event target source transitions - name : String - action : Method - event : Event Transition + fire(event : Event) : Void receiver queue 1 {ordered n substates n initial 1 parent Event - name : String - args : Object[] ComplexState 26

27 Strategy 3: State Table Approach Shuttle Use a state machine meta-model implementation Create a (partial) state machine model (object structure at runtime) with all transitions for the current state execute a state machine using a generic event handling algorithm based on the state machine model ReactiveSystem + initstatemachine : Void + run() : Void + handleevent() : Void + invoke(method m, Object[] args) : Object currentstate 1 State - name : String - entryaction : Method - exitaction : Method + gettransition(event : Event) : Transition + enter(event : Event) : Void + leave(event : Event) : Void e : Event target source transitions - name : String - action : Method - event : Event Transition + fire(event : Event) : Void receiver queue 1 {ordered n substates n initial 1 parent Event - name : String - args : Object[] ComplexState 27

28 Strategy 3: State Table - Example initial master : ComplexState substates substates waiting : State substates t2 : Transition event = reactivate transitions [ reactive ] halted : State currentstate s : Shuttle transitions[ assign ] target target t1 : Transition event = assign target substates active : ComplexState initial substates gotosource : State transitions [ assign ] t4 : Transition event = assign target transitions[ emergencystop ] transitions[ emergencystop ] Concrete state machine 1:1 represented by object structure (based on meta model from previous slide) t3 : Transition event = emergencystop Halted Waiting reactivate emergencystop assign(source, target) H* Active GoToSource Fetch GoToTarget Deliver destinationreached fetched destinationreached delivered assign(source, target) 28

29 Strategy 3: State Table (Simplified) algorithm for event handling class ReactiveSystem { public void handleevent() { Event e = getfirstfromeventqueue(); if(e!= null) { State currentstate = getcurrentstate(); Transition transition = currentstate. gettransition(e); State nextstate = transition.gettarget(); currentstate.leave(e); transition.fire(e); nextstate.enter(e); Generic implementation: no specific state classes Allows flexible adaption at runtime Lower performance than state pattern implementation transitions[ assign ] waiting : State t1 : Transition event = assign initial substates target substates master : ComplexState substates active : ComplexState initial gotosource : State Halted substates target Waiting reactivate emergencystop t2 : Transition event = reactivate transitions [ assign ] t4 : Transition event = assign target transitions[ emergencystop ] assign(source, target) H* substates transitions[ emergencystop ] transitions [ reactive ] Active GoToSource Fetch GoToTarget Deliver halted : State target destinationreached fetched t3 : Transition event = emergencystop destinationreached delivered currentstate s : Shuttle assign(source, target) 29

30 Summary Code generation for Structural diagrams (Class diagrams) Inheritance Associations Behavioral diagrams which refine class diagrams Activity diagrams (usually for control flow of methods) Story diagrams (refine activity diagrams) State machines (usually for behavior of reactive components, i.e. whole classes instead of single methods) 30