Graph Transformation for Modelling, Testing and Analysis of Software Systems

1. Graph Transformation for Modelling, Testing and Analysis of Software Systems Reiko Heckel University of Leicester, UK LSGT 2018, Royal Holloway, UK1 July, 2018

2. Software Engineering ActivitiesConstruction and Analysis • Requirements • Aspects and views, dependencies and conflicts • Design • Stochastic Analysis of Peer-to-Peer Architectures • Service specification and matching • Implementation • Testing and Monitoring • Reverse Engineering

3. Detecting Conflicting Requirements in a Use Case-Driven Approach Jan Hendrik Hausmann, Reiko Heckel, Gabriele Taentzer:Detection of conflicting functional requirements in a use case-driven approach: a static analysis technique based on graph transformation.ICSE 2002: 105-115

4. Model A Model B capture ensureconsistency integrate & transform System Make sure there is an implementation satisfying all requirements ! Motivation: Software Development as Integration of Views Req. A Req. B User View B User View A • Aspects of requirements models • Conflicts between functional requirements • Theory and tool support

5. Model A Model B Aspects of Requirements Models • Static domain model: Agree on vocabulary first ! • class and object diagrams • Business process model: Which actions are performed in which order ? • use case description in natural language, activity or sequence diagrams, etc.

6. formal, e.g., attributed graphs at the type and instance level established techniques for view integration :Bill total = 40 :Customer cash = 50 1 0..1 1 Bill total Shop Customer cash 0..1 1 1 owns 0..1 0..1 :Item value = 30 :Item value = 10 :Cart 0..1 owns 1 0..1 CashBox amount Cart Rack Item value 0..1 0..1 owns owns :Cash Box amount = 1000 :Shop typing Structure: Class and Object Diagrams

7. based on vocabulary of integrated domain model no way to tell if views are consistent Shop buy items sell items Clerk Customer <<refine>> • take shopping cart • select items from rack • take items out of cart • pay required amount • collect items • create empty bill for new customer • take items out of customer’s cart • add them to the bill • collect payment • pack and give items to customer Behaviour: Use Case Description by Structured Text

8. Model A Model B Aspects of Requirements Models • Static domain model: Agree on vocabulary first ! • class and object diagrams • Business process model: Which actions are performed in which order ? • use case description in natural language, activity or sequence diagrams, etc. • Functional model: What happens if an action is performed ? • pre-/post conditions as logic constraints • transformation rules on object diagrams (Fusion, Catalysis, Fujaba, formally: graph transformations)

9. :Customer cash=y-x :Customer cash=y :Bill total=x :Bill total=x Customer::pay bill owns :Cart :Cart :Item :Item owns :Shop :Shop conflicting actions :CashBox amount = y :CashBox amount = y+x :Shop :Shop Clerk::close bill :Item :Item owns :Bill total = x :Bill total = x Function:Transformation Rules on Object Diagrams

10. :Bill total = 10 :Customer cash = 50 Customer Clerk :Cart :Item value = 10 customerupdatescash owns :Cash Box amount = 1000 both delete owns link :Shop pay bill close bill clerk updatesamount :Customer cash = 40 :Bill total = 10 :Bill total = 10 :Customer cash = 50 owns owns :Item value = 10 :Cart :Item value = 10 :Cart :Cash Box amount = 1000 :Cash Box amount = 1010 :Shop :Shop Conflicts Between Functional Requirements

11. Alternative steps are parallel independent if they do not disable each other. Otherwise they are in conflict. Consecutivesteps are sequentially independent if they may be swapped without affecting the result.Otherwise they arecausallydependent. Idea: Find potential conflicts and causal dependencies between rules by critical pair analysis Characterization [EPS73]:Two (alternative or consecutive) steps areindependentiff all commonly accessed items are in read-access only. p2 p1 X Theory: Independence, Causality and Conflicts in Graph Transformation G p1 p2 H1 H2

12. Tool Support: Critical Pair Analysis with AGG

13. 1. 2. <<disables>> 3. Modeller 5. 4. Usage Scenario • input model to CASE tool • import model by analysis tool • analyze model for conflicts • back annotate models with conflicts • interprete and improve models UMLCASE Tool Analysis Tool Shop Domain expert: “buy items and sell items should not be in conflict” Modeller: “inconsistency between views” buy items sell items Clerk Customer

14. Stochastic Analysis of Peer-to-Peer Architectures Reiko Heckel: Stochastic Analysis of Graph Transformation Systems: A Case Study in P2P Networks.ICTAC 2005: 53-69 Paolo Torrini, Reiko Heckel, István Ráth:Stochastic Simulation of Graph Transformation Systems.FASE 2010: 154-157

15. p3 p5 Case Study p1 Problem: • no central infrastructure • unreliable components • removing nodes may disconnect network Idea: introduce redundancy! Question: Which links should be added to guarantee a certain level of reliability ? • at random, up to a limit of n links • so that deletion of node does not increase distance p2 p4

16. l Modelling Change in the Network: A Graph Transformation System new l p:P p1:P p:P kill p:P l l p1:P p3:P p1:P p3:P shortcut l l l p2:P p2:P

17. :P :P l :P :P Which shortcuts? a) At random (limit here: n = 3 links) l l p1:P p3:P p1:P p3:P random l l l p2:P p2:P

18. l l :P l Which shortcuts? b) So that deletion of node does not increase distance l l p1:P p3:P p1:P p3:P smart l l l p2:P p2:P L. Mariani. Fault-tolerant routing for p2p systems with unstructured topology. Proc. International Symposium on Applications and the Internet (SAINT 2005), Trento, Italy.

19. Modelling Time:Stochastic Graph Transformation • associate rate (p) with every rule p • 1/(p) average delay of p, once enables SGrandom, x SGsmart, x x times as fast as new or kill

20. Tools for Querying the Model new l p:P p:P p1:P kill p:P l l p1:P p3:P p1:P p3:P shortcut l l l l p2:P p2:P CTMC

21. 0 1 2 3 4

22. Service Specification and Matching Jan Hendrik Hausmann, Reiko Heckel, Marc Lohmann: Model-Based Development of Web Services Descriptions Enabling a Precise Matching Concept.Int. J. Web Service Res. 2(2): 67-84(2005) Muhammad Naeem, Reiko Heckel, Fernando Orejas, Frank Hermann:Incremental Service Composition Based on Partial Matching of Visual Contracts.FASE 2010: 123-138

23. Consistency in Service-oriented Architectures Requirements Description • External:between required and provided interface specifications • Internal:between interface specification and implementation • Structural consistency: ontologies • Behavioral consistency: contracts Requestor Provider

24. Matching requirements to descriptions requires a common understanding of underlying concepts: Requestor’s requirement:“I need an online book shop that accepts payment by bank transfer.” Provider’s service description:“We sell all kinds of media. You may pay via credit cardor bank account.” Media Book CD DVD PaymentMethod BankTransfer CreditCard CashOnDelivery Ontology:Domain-oriented industry standards

25. Design by Contract (Bertrand Meyer, 1988) • component interface = contract between requestor and provider • both expect benefits and accept obligations • possible contract languages: transformation rules, state diagrams, logic, or just text

26. Requestor guaranteespreR  Provider assumespreP Provider guaranteeseffectP  Requestor assumeseffectR Matching Requestor with Provider Requestor preR effectR 1. call 2. return preP effectP Provider

27. Ontology Client name 1 pays from Bill total status credit 1 Transfer amount for AccountData number Acknowledgement to debit 1 provides 1 contains Bank code Product prizedescr

28. Requestor‘s service requirement: An inquiry for a contract „I want to pay via bank account!“ :AccountData Pre: I provideaccount data(remains unchanged) provides :Bank Effect:I expect that the Bill will change status to „payed“ (a transformation) :Bill status=open :Bill status=payed

29. Provider‘s service description: A contract offer „You may pay via bank transfer!“ :AccountData :AccountData Pre: You provide account data of the client who pays. provides :Bank owns Effect:I guarantee that the Bill will change to “payed”, you will get an ack, and I store your data. :Acknowledgement :Client for pays :Bill status=open :Bill status=payed

30. Pre: I provideaccount data Pre: You provide account data of the client who pays Post: I expect that the Bill will change status to „payed“. Post: I guarantee that the Bill will change to “payed”, you will get an ack, and I store your data. no match implied not implied Matching Inquiry and Offer Requestor Provider

31. implies Inquiry and Offer: Preconditions PreReqimpliesPreProiffPreProsubgraphofPreReq „everythingassumedbyproviderisguaranteedbyrequestor“ :AccountData :AccountData provides provides :Bank :Bank owns :Client pays :Bill status=open :Bill status=open

32. Requestor‘s service requirement: An inquiry with extended precondition „I want to pay via bank transfer!“ :AccountData Pre: I provide account data of the client who pays. provides :Bank owns :Client payBill Post:I expect that the Bill will change status to „payed“ pays :Bill status=open :Bill status=payed

33. Pre: I providemy account data Pre: You provide YOUR account data Post: I expect that the Bill will I expect that the Bill will change status to „payed“. Post: I guarantee that the Bill will will change to “payed”, and you will get an ack. Matching Inquiry and Offer Requestor implied match! implied Provider

34. Software Engineering ActivitiesConstruction and Analysis • Requirements • Aspects and views, dependencies and conflicts • Design • Stochastic Analysis of Peer-to-Peer Architectures • Service specification and matching • Implementation • Testing & Monitoring, Reverse Engineering

35. Consistency in Service-oriented Systems Requirements Description • External:between requested and provided interface specifications • Internal:between interface specification and implementation Requestor Provider

36. Graph Transformation-based Testing Tamim Ahmed Khan, Olga Runge, Reiko Heckel:Testing against Visual Contracts: Model-Based Coverage.ICGT 2012: 279-293 Tamim Ahmed Khan, Reiko Heckel:On Model-Based Regression Testing of Web-Services Using Dependency Analysis of Visual Contracts.FASE 2011: 341-355

37. generate JML Assertions :CreditCard :CreditCard :Order :Bill :Book :DeliveryAddress :Book :DeliveryAddress Internal Consistency: Testing & Monitoring Service Description: Class diagram Operation signatures Operation contracts models business modeller Test Cases knows Test Driver implements method programmer Implementation test

38. Inferring Visual Contracts from Java Programs Abdullah M. Alshanqiti, Reiko Heckel:Extracting Visual Contracts from Java Programs (T).ASE 2015: 104-114 Abdullah M. Alshanqiti, Reiko Heckel, Timo Kehrer:Visual contract extractor: a tool for reverse engineering visual contracts using dynamic analysis.ASE 2016: 816-821 http://vce.alshanqiti.org

39. infer Execution Traces :CreditCard :CreditCard :Order :Bill :Book :DeliveryAddress :Book :DeliveryAddress Internal Consistency: Reverse Engineering Service Description: Class diagram Operation signatures Operation contracts validates business modeller reviews Henshin implements method programmer simulation, verification analyses Implementation https://prezi.com/eqwd9wyesdzy/extracting-visual-contracts-from-java-programs/

40. Questions reiko@mcs.le.ac.uk

41. Book Project: Graph Transformation for Software Engineers With Gabi Taentzer and ArendRensink Looking for volunteers to read, comment, critique …

42. Part I: Graph Transformation Concepts, Techniques and Tools • Graphs for Modeling and Specification • Graph Transformation Concepts • Usage Scenarios and Control Structures • Analysis and Improvement of Graph Transformation Systems

43. Part II: Applying Graph Transformation to Software Engineering • Detecting Conflicting Functional Requirements • Stochastic Analysis of Peer-to-Peer Architectures • Service Specification and Matching • Graph Transformation-based Testing • Inferring Visual Contracts from Java Programs • Integrating Metamodeling with Graph Transformationfor Advanced Modeling Language Definition • Improving Models and Understanding Model Changes