Automatic generation of behavioral code - too ambitious or even unwanted?

Size: px

Start display at page:

Download "Automatic generation of behavioral code - too ambitious or even unwanted?"

Myrtle Hubbard
6 years ago
Views:

1 Automatic generation of behavioral - too ambitious or even unwanted? Gregor Engels University of Twente, The Netherlands 23 June 2009 Professional Activities Gregor Engels University of Paderborn Head of Board s-lab (Software Quality Lab) Member Board International Graduate School (IGS) Scientific Director Capgemini sd&m Research, Munich International Member Founding Board Informatics Europe ( Steering Committee MODELS Conference, Visual Languages and Human-Centric Computing (VLHCC), International Conference on Graph Transformations (ICGT) Gregor Engels, BM-MDA

2 Software is everywhere! Gregor Engels, BM-MDA Software is everywhere! Objectives of modern software development efficient development process software of high quality correct adaptable reusable Solution / Dream (?) Model-driven Development (MDD) Model-driven Architecture (MDA) Service-oriented Architecture (SOA) Gregor Engels, BM-MDA

3 Model-driven Software Development (MDD) designer Automatic generation needs complete s semantics-preserving s Can we achieve this in general? (specification) Visual s UML s correctness guaranteed! executable Gregor Engels, BM-MDA Traditional Manual Software Development restricted or no textual s UML class diagrams? correctness mer executable Gregor Engels, BM-MDA

4 The Dream The Reality MDD designer (specification) restricted or no mer executable executable Gregor Engels, BM-MDA The Dream Objectives MDD designer (specification) objectives: acceptable s semantics-preserving s restricted or no mer executable executable Gregor Engels, BM-MDA

5 Only a Dream? No! Database Design! MDD Model-driven Database Design designer (specification) designer semantics-preserving lossless join dependency-preserving Entity- Relationship Diagram Relational DB Schema language/tool support 4th GL executable executable Gregor Engels, BM-MDA Only a Dream? No!? Fujaba MDD MDD (specification) Story-driven Modelling designer designer Java Code executable executable Gregor Engels, BM-MDA

6 The Fujaba Approach Fujaba - From UML to Java and Back Again Open Source UML CASE Tool Project started in 1997 at the University of Paderborn Wilhelm Schäfer (University of Paderborn) Albert Zündorf (University of Kassel) Holger Giese (HPI Potsdam) Gregor Engels, BM-MDA Fujaba main features based on UML extended by Story Driven Modeling (SDM) deploys graph platform combines UML class diagrams and UML behavior diagrams (Story Diagrams) to a powerful, easy to use, yet formal system design and specification language generation of Java source out of the whole design which results in an executable prototype re-engineering so that Java source can be parsed and represented within UML Gregor Engels, BM-MDA 2009 Provided by: Software Engineering Group, Prof. Dr. Wilhelm Schäfer 12 6

Behavior ing with Fujaba object diagrams are used as typed graphs are the base to define graph rules control flow described by UML activity diagrams object behavior described by graph rules Running

7 Behavior ing with Fujaba object diagrams are used as typed graphs are the base to define graph rules control flow described by UML activity diagrams object behavior described by graph rules Running example: autonomous shuttles Gregor Engels, BM-MDA 2009 Provided by: Software Engineering Group, Prof. Dr. Wilhelm Schäfer 13 Object diagrams as typed graphs Class Diagram: Shuttle ison 1 1 Track next 1 turnnext Type Graph Switch Object graph: :Shuttle ison Typed Graph (edges are typed, too) :Track next :Track next :Switch :Shuttle turnnext :Track :Track next ison Gregor Engels, BM-MDA 2009 Provided by: Software Engineering Group, Prof. Dr. Wilhelm Schäfer 14 7

8 Story Diagrams combine: UML Activity diagrams specify control flow Story patterns specify graph tranformation rules specify (more complex) operations on object structures have formally defined semantics Control flow: - sequences - loops - conditions - alternatives Graph : - object structure modification - attribute value changes - attribute conditions 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, 1998 Gregor Engels, BM-MDA 2009 Provided by: Software Engineering Group, Prof. Dr. Wilhelm Schäfer 15 Story Diagrams - Control Flow Example Modeling alternatives with Story Diagrams findshuttleonswitch shuttle: Shuttle ison switch: Switch [success] checkswitch switch turnleft = true [failure] [failure] [success] shuttle switch leaveswitchontheleft shuttle switch leaveswitchontheright «delete» ison «delete» ison turnnext right: Track left: Track «create» ison Guards success and failure: Success: Transition fires iff previous activity has been executed successfully, i.e. pattern completely matched and all conditions satisfied. next «create» ison Gregor Engels, BM-MDA 2009 Provided by: Software Engineering Group, Prof. Dr. Wilhelm Schäfer 16 8

9 Motivation for generation -based software engineering (mainly) working on design level (with s) reduces complexity automatically generate reduces implementation effort reduces implementation errors maintainability and readability of generated reason: sometimes has to be reviewed or adapted manually integration with frameworks, platforms, etc. manual optimization (e.g. for efficiency) Gregor Engels, BM-MDA 2009 Provided by: Software Engineering Group, Prof. Dr. Wilhelm Schäfer 17 Code Generation with Fujaba 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) Gregor Engels, BM-MDA 2009 Provided by: Software Engineering Group, Prof. Dr. Wilhelm Schäfer 18 9

10 Code generation of structural information Design Level Class Diagram Code Level Class Diagram Generated Source Code class Shuttle { public Shuttle() {} Shuttle + speed: float + name: String + calculatedistance(loc: Location) : float Shuttle - speed: float - name: String + getspeed() : float + setspeed(speed: float) : void + getname() : String + setname(name: String) : void + calculatedistance(loc: Location) : float Code generation defined for: inheritance bidirectional associations composition and aggregation 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) {... } } Gregor Engels, BM-MDA 2009 Provided by: Software Engineering Group, Prof. Dr. Wilhelm Schäfer 19 Code generation of activity diagrams Activity Diagram specifies single method (well-formed) control flow maps to (Java) control structures actions / guards translate directly to (makes diagrams language dependent) Gregor Engels, BM-MDA 2009 Provided by: Software Engineering Group, Prof. Dr. Wilhelm Schäfer 20 10

Generated Java for story diagrams JavaSDM.

expression is not true Gregor Engels, BM-MDA 2009

Wilhelm Schäfer 21 Summary of Fujaba Approach

object diagrams control flow definition is ming

and its behavior into structural skeleton syntax

mapped to ming language instructions Gregor Engels,

11 Generated Java for story diagrams JavaSDM.ensure( ) throws a JavaSDM- Exception if the given expression is not true Gregor Engels, BM-MDA 2009 Provided by: Software Engineering Group, Prof. Dr. Wilhelm Schäfer 21 Summary of Fujaba Approach complete structure needs to be led to provide object diagrams control flow definition is ming language dependent generation must embed methods and its behavior into structural skeleton syntax and semantics definition of story diagrams is mapped to ming language instructions Gregor Engels, BM-MDA 2009 Provided by: Software Engineering Group, Prof. Dr. Wilhelm Schäfer 22 11

12 Evaluation of Fujaba acceptable? detailed, fine-grained specification ming-language dependent objectives: acceptable s semantics-preserving s Story-driven Modelling semantics-preserving? -based semantics of Fujaba as semantics definition mer Java Not a semantics-preserving! executable Gregor Engels, BM-MDA Semantics-preserving MDD designer ML meta source language <<instance of>> specification executed by target language PL meta <<instance of>> input engine output executable Gregor Engels, BM-MDA

13 What does semantics-preserving mean? Analysis PIM PSM Code holds holds holds requirement property property property Payment System login... check login addinfo... check login(); addinfo(); If()... check(); The function Check Account must be available for a user AG(login => AF(check)) CTL : AG Always Globally on each path AF Always in the Future AG((login)=>AF(check)) reachability Semantics preserving means that the resulting / still conforms to the initial requirements Correctness of in the sense of semantics preserving Gregor Engels, BM-MDA What is needed for a proof? formal semantics of behavioral s formalized properties formal Gregor Engels, BM-MDA

14 Semantics-preserving property A holds PIM PSM holds property A semantics SM semantics TM CTL formula Transition System SM Transition System TM CTL formula semantics-preserving means that all properties of the source hold for the target, too Gregor Engels, BM-MDA The way to show semantics-preservation Source Meta Target Meta properties instance of instance of holds holds Source Model Target Model properties semantics SM semantics TM Transition System SM equivalence Transition System TM Transition systems are equivalent All properties that hold on a source also hold on a target Gregor Engels, BM-MDA

15 Why is it difficult to prove this? languages are different not every element has a counterpart in the other language. Example: UML Activity Diagram several tokens may traverse through a diagram Textual Language (e.g., Java) only one counter login check login(); check(); How to map the semantics in this case? Gregor Engels, BM-MDA Proof of bisimulation Source Model Transformation Target Model Transition System SM execute( ) Transition System TM execute( ) Goal: to show that transition system (TS) of each source is bisimular to the TS of target received as result of Gregor Engels, BM-MDA

16 Double Check Approach Joint Project: University of Paderborn: G. Engels, M. Semenyak, Chr. Soltenborn, H. Wehrheim TU Twente: A. Rensink (Groove approach) UML Meta- Graph Transformation specification TAAL Meta- instance of Formal semantics (DMM) UML Transition System UML input Transformation Engine for Graph Transformation TAAL instance of Formal semantics (TAAL-semantics) Transition System TAAL Bisimilar relation between Transition Systems Systems behave in the same way in the sense that one system simulates the other and vice-versa G. Engels, A. Kleppe, A. Rensink, M. Semenyak, Chr. Soltenborn, H. Wehrheim: From UML Activities to TAAL - Towards Behaviour-Preserving Model Transformations. Proceedings of ECMDA 2008, LNCS 5095, pp , Springer-Verlag 2008 Gregor Engels, BM-MDA output Evaluation acceptable? detailed, fine-grained specification ming-language dependent objectives: acceptable s semantics-preserving s Model semantics-preserving? hard to prove needs semantics definition of languages mer executable Gregor Engels, BM-MDA

17 Title of the Talk: Automatic generation of behavioral too ambitious or even unwanted? acceptable? detailed, fine-grained specification ming-language dependent objectives: acceptable s semantics-preserving s Model semantics-preserving? hard to prove needs semantics definition of languages mer Are there alternatives?? executable Gregor Engels, BM-MDA Alternative Approaches Use of partial s visual contracts Model-driven Monitoring (MdM) Model-based Testing (MbT) Gregor Engels, BM-MDA

18 Alternative Approaches Use of partial s visual contracts Model-driven Monitoring (MdM) Model-based Testing (MbT) Gregor Engels, BM-MDA Graph-Transformation-Based Modeling Modelling Alternatives DPO: double pushout complete control of change no context change in addition to rule SPO: single pushout complete control of change deletion of dangling edges no context change in addition to rule ZPO: zero pushout complete control of change context change with embedding descriptions DPO SPO ZPO DPB complete control of change deterministic (strict) non-deterministic (loose) NO control of change DPB: double pullback partial control of change uncontrolled context deletion uncontrolled context extension Gregor Engels, BM-MDA

19 Reuse of an old idea: Design by Contract (Eiffel) Model (Specification) Contract: A formal agreement between an operation and its clients textual logical expressions allows partial description of behavior specification (assertions) Contract Properties that must hold before execution of operation Pre-condition operation Post-condition Properties that must hold after execution of the operation Gregor Engels, BM-MDA Reuse of an old idea: Design by Contract (Eiffel) Model (Specification) system state s operation call 1. test pre-condition 2. execute operation 3. test post-condition system state s* specification (assertions) Compiler executable with run-time assertions Gregor Engels, BM-MDA Contract Pre-condition operation Post-condition Concepts of Design by Contract: Describe behavior of operations partially with contract. Monitor implementation (correctness) at runtime 19

20 Visual Contract Example Behavioral Aspects: Visual Contract cartadd(asin, cid, x) pr:product pr:product Visual Contracts: define minimal requirements semantic concept of loose graph transitions formalized by double-pullback ASIN = asin self:shop c:cart cartid = cid Pre-condition ASIN = asin self:shop c:cart cartid = cid ci:cartitem ASIN = asin quantity = x Post-condition Static Aspects: Class Diagram typed Shop 0..* Product cartadd(string, String, Integer) ASIN : String 1 0..* CartItem Cart 0..* ASIN : String cartid : String 1 quantity : Integer 0..* Gregor Engels, BM-MDA typed Alternative Approaches Use of partial s visual contracts Model-driven Monitoring (MdM) Model-based Testing (MbT) Gregor Engels, BM-MDA

21 Model-Driven Monitoring Use visual contracts on level designer mer executable Monitor manual implementation against Gregor Engels, BM-MDA Visual Contracts designer Class Diagram Model Visual Contracts loose semantics double-pullback mer How to monitor manual implementation against? executable Gregor Engels, BM-MDA

22 Model-Driven Monitoring Model Designer Programmer Class Diagrams Class Skeletons Visual Contracts completes executable - Implementation Assertions executable with run-time assertions Gregor Engels, BM-MDA Transformation into Java and JML Class diagrams Java Class Skeletons typed use Visual Contracts JML Assertions JML (Java Modeling Language) Design by Contract Extension for Java JML Assertions are based on Java expressions Pre-condition Post-condition /*@ public requires (\exists Product && (\exists Cart @ ensures (\exists Product && (\exists Cart && (\exists CartItem && citem.getquantity() == public String cartadd (String asin, String cid, int x); Gregor Engels, BM-MDA

23 Transformation into Java and JML Class diagrams Java Class Skeletons typed use Visual Contracts JML Assertions JML (Java Modeling Language) Design by Contract Extension for Java JML Assertions are based on Java expressions Pre-condition public requires (\exists Product && (\exists Cart @ ensures (\exists Product pr.getasin().equals(asin) && (\exists ASIN Cart = c; c.getcartid().equals(cid) && (\exists CartItem c.getcartitems().values().contains(citem); item.getasin().equals(asin) cartid = && citem.getquantity() == Pre-condition public String cartadd (String asin, String cid, int x); Gregor Engels, BM-MDA Transformation into Java and JML Class diagrams Java Class Skeletons typed use Visual Contracts JML Assertions JML (Java Modeling Language) Design by Contract Extension for Java JML Assertions are based on Java expressions Post-condition pr:product /*@ public requires ASIN = (\exists asin Product pr; getproducts().values().contains(pr); pr.getasin().equals(asin) = && (\exists Cart c; quantity = x cartid c.getcartid().equals(cid)))); ensures (\exists Product && (\exists Cart && (\exists CartItem && citem.getquantity() == public String cartadd (String asin, String cid, int x); Gregor Engels, BM-MDA

Compiler executable Java with run-time assertions Gregor Engels, BM-MDA 2009 47 Visual Contract Workbench Visual Contract Workbench is

24 Model-Driven Monitoring: Tool Support Visual Contract Workbench Model (Specification) Designer Class Diagrams Visual Contracts Programmer Java Class Skeletons Class Skeletons completes executable - Java- Implementation JML Assertions Assertions Compiler JML Compiler executable Java with run-time assertions Gregor Engels, BM-MDA Visual Contract Workbench Visual Contract Workbench is implemented as Eclipse plug-in allows for ing of class diagrams and visual contracts complemented by generation facilities Gregor Engels, BM-MDA

25 Alternative Approaches Use of partial s visual contracts Model-driven Monitoring (MdM) Model-based Testing (MbT) Quality check by accident!! Gregor Engels, BM-MDA Alternative Approaches Use of partial s visual contracts Model-driven Monitoring (MdM) Model-based Testing (MbT) Quality check by accident!! Planned quality check!! Gregor Engels, BM-MDA

26 Traditional Manual Software Testing restricted or no restricted or no test tester mer test execution test? adequate (comprehensive, relevant) Gregor Engels, BM-MDA Model-based Testing (MbT): Scenario 1 (specification) test test designer test execution test BUT! complete test generation needs complete / low level test s (expensive) needs flexible (difficult) thus, not realistic in general Gregor Engels, BM-MDA

27 Model-based Testing (MbT): Scenario 2 (specification) extraction test test designer test execution test BUT! extraction must be specified few/no redundancy between and test test it against it thus, not effective in general Gregor Engels, BM-MDA Model-based Testing (MbT): Scenario 3 (specification) extraction test manual implementation test execution test extraction must be specified automated test design automated test execution Gregor Engels, BM-MDA

28 Model-based Testing (MbT): Our combined Approach Model Designer Class Diagrams Visual Contracts test s Programmer Class Skeletons completes executable - Implementation JML Assertions JMLUnit test Pass/ No pass report executable with run-time assertions Testing 55 input Test cases Gregor Engels, BM-MDA Unit Testing: Test Case Generation Test case inputs: call parameters + system state 1. Generation of call parameters P = {cid= abc, prno= def, num=1} «entity» /pr : Product «key» productno = prno title Well-known techniques: Boundary analysis, Equivalence classes, Random 2. Generation of system state s input = «control» /self : OnlineShop «entity» /c : Cart «key» cartid = cid 3. Setting system state Simulate Naturally generate Gregor Engels, BM-MDA

29 Unit Testing: Test case generation Test case inputs: call parameters + system state 1. Generation of call parameters P = {cid= abc, prno= def, num=1} Well-known techniques: Boundary analysis, Equivalence classes, Random 2. Generation of system state s input = e.g. using mock objects or stubs e.g. using checking «entity» /pr : Product «key» productno = prno title «control» /self : OnlineShop «entity» /c : Cart «key» cartid = cid 3.Setting system state s s input simulate system state call other class operations until desired system state is reached naturally Gregor Engels, BM-MDA Unit Testing: Simulating Test Cases VC::Checkout cart : Cart : Customer name = x address = y : CreditCard account nr = n institute = i : : CartItem CartItem count count = t_1 : Product : Product titel titel = z price price = p_1 : Order delivery add. = y : Customer name = x address = y : CreditCard account nr = n institute = i b = SUMM(t_x * p_x) : Receipt amount = b : : Product Product titel titel = z price price = p_1 Gregor Engels, BM-MDA

$Unit Testing: JUnit Test Script cartadd(product product, int quantity, String cid) Test input quantity= 1 cid = xyz public void testcartadd_0() { Product product = new Product(); product.$ addcart(c); self.addproduct(product); self.cartadd(product, quantity, cid); } further Objects Object variables Object relations Invoke method Model-driven Monitoring used to check correctness!

addcart(c); self.addproduct(product); self.cartadd(product, quantity, cid); } further Objects Object variables Object relations Invoke method Model-driven Monitoring used to check correctness!

30 Unit Testing: JUnit Test Script cartadd(product product, int quantity, String cid) Test input quantity= 1 cid = xyz public void testcartadd_0() { Product product = new Product(); product.settitle("abc"); product.setasin("def"); int quantity = 1; String cid = "xyz"; Call parameters generate OnlineShop self = new OnlineShop(); Cart c = new Cart(); c.setcartid("xyz"); self.addcart(c); self.addproduct(product); self.cartadd(product, quantity, cid); } further Objects Object variables Object relations Invoke method Model-driven Monitoring used to check correctness! Gregor Engels, BM-MDA Unit Testing: Test case generation Test case inputs: call parameters + system state 1. Generation of call parameters P = {cid= abc, prno= def, num=1} Well-known techniques: Boundary analysis, Equivalence classes, Random 2. Generation of system state s input = e.g. using mock objects or stubs e.g. using checking «entity» /pr : Product «key» productno = prno title «control» /self : OnlineShop «entity» /c : Cart «key» cartid = cid 3.Setting system state s s input simulate system state call other class operations until desired system state is reached naturally Gregor Engels, BM-MDA

31 Unit Testing: Setting System State Naturally controls 1 «control» OnlineShop productno controls cartid cartcreate() : : Cart cartadd(zoll cartadd(cartid cartid : String, : String, productno Zoll ASIN : String, : String, quantity Zoll quantity : Integer) : Integer) : String: String 1 0..* * «entity» Cart «key» cartid : String 1 +cartitem «entity» CartItem «key» cartitemid : String productno : String quantity : Integer +product +cartitem 1 «entity» Product «key» productno : String title : String 0..* 0..* Gregor Engels, BM-MDA Unit Testing: Setting System State 3. Generation of system setting sequence s 0 s t cartcreate s 1 s 2 operation n su Model checking techniques for computation of the system setting sequence: cartcreate,, operation n s v s v s input Gregor Engels, BM-MDA

32 Title of the Talk: Summary Automatic generation of behavioral too ambitious or even unwanted? The Dream Our Proposal: MdM + MbT MDD MdM + MbT designer (specification) designer manual implementation (specification) Code (with assertions) partial mer executable executable with test data Gregor Engels, BM-MDA Acknowledgments Thanks to the PhD students who helped me in preparing this talk: Baris Güldali Maria Semenyak Michael Spijkermann Gregor Engels, BM-MDA

33 References Model-based Testing G. Engels, B. Güldali, C. Soltenborn, H. Wehrheim: Assuring Consistency of Business Process Models and Web Services using Visual Contracts. In A. Schürr/ M. Nagl/ A. Zündorf (Eds.): Proc. 3rd Intl. Workshop on Applications of Graph Transformation with Industrial Relevance (AGTIVE'07), LNCS 5088, pp , Springer G. Engels, B. Güldali, M. Lohmann Towards Model-Driven Unit Testing In T. Kühne (ed.), Satellite Events at the MoDELS 2006 Conference, Genua, Italy, October 1-6, 2006, Revised Selected Papers, LNCS 4364, pp , Springer 2007 B. Güldali, M. Mlynarski, A. Wübbeke, G. Engels: Model-Based System Testing Using Visual Contracts. In Proceedings of Euromicro SEAA Conference 2009, Special Session on Model Driven Engineering. IEEE, to be published. Gregor Engels, BM-MDA References Model-driven Monitoring G. Engels, M. Lohmann, S. Sauer, R. Heckel: Model-Driven Monitoring: An Application of Graph Transformation for Design by Contract In A. Corradini, H. Ehrig, U. Montanari, L. Ribeiro, G. Rozenberg (Eds.): Proc. Third International Conference on Graph Transformations (ICGT 2006), LNCS 4178, pp , Springer M. Lohmann, S. Sauer, G. Engels: Executable Visual Contracts 2005 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC'05), pp , Gregor Engels, BM-MDA

34 References Semantics G. Engels, A. Kleppe, A. Rensink, M. Semenyak, Chr. Soltenborn, H. Wehrheim From UML Activities to TAAL - Towards Behaviour-Preserving Model Transformations Proc. of ECMDA 2008, LNCS 5095, pp , Springer G. Engels, C. Soltenborn, H. Wehrheim: Analysis of UML Activities Using Dynamic Meta Modeling In M. M. Bosangue, E. Broch Johnsen (Eds.): FMOODS 2007, LNCS 4468, pp , Springer G. Engels, J. H. Hausmann, R. Heckel, S. Sauer Dynamic Meta-Modeling: A Graphical Approach to the Operational Semantics of Behavioral Diagrams in UML In A. Evans, S. Kent, B. Selic (eds.): UML The Unified Modeling Language, Third International Conference, October 2000, York, UK, LNCS 1939, pp Springer Gregor Engels, BM-MDA The End engels@upb.de Gregor Engels, BM-MDA

Towards Model-Driven Unit Testing

Towards Model-Driven Unit Testing Gregor Engels 1,2, Baris Güldali 1, and Marc Lohmann 2 1 Software Quality Lab 2 Department of Computer Science University of Paderborn, Warburgerstr. 100, 33098 Paderborn,