Verification of DSMLs Using Graph Transformation: A Case Study with Alloy

1. Verification of DSMLs Using Graph Transformation:A Case Study with Alloy This work funded in part by NSFCAREER award CCF-0643725. Zekai Demirezen1, Marjan Mernik1,2, Jeff Gray1, Barrett Bryant1 1Department of Computer and Information Sciences, University of Alabama at Birmingham {zekzek, gray, bryant}@cis.uab.edu 2 University of Maribor, Slovenia marjan.mernik@uni-mb.si

2. Overview Verification of DSML Models DSML Specifications Motivation Alloy Background Specifying DSML Semantics Mapping a DSML Model to an Alloy Model Goals Case Study

3. Specification of DSMLs • Abstract Syntax: Concepts, Relationships, Domain Metamodels • Concrete Syntax: Textual or Graphical Representations • Well-formedness rules and Static Semantics: Model Instance Consistency • Behavioral Semantics: Operational Semantics of the Domain Elements

4. Specifying Dynamic Semantics using Graph Grammars • Behavioral semantics of a DSML can be represented by a sequence of Graph Transition Rules • This approach divides all semantic concerns into discrete states and transition relations as in-place model transformations • An in-place model transformation rule is defined as: • L: [NAC]*LHS->RHS • Sequence definitions based on Activity Diagrams can be used to control what state transition is to be fired, in what order

5. Motivation • Domain-Specific Modeling Languages (DSMLs) enable domain experts to specify models using domain concepts • However, there remain several challenges, such as how to use a model defined in a DSML to support simulation, code generation, model checking • Formal verification tools are often required to detect design errors, which are difficult to recognize by checking manually • The low-level details of verification tools make them challenging to use by end-users • One solution to overcome this situation is the use of automated transformations that map a designer’s high level definitions into the representation used by a model checker

6. An Outline of Our Approach

7. Verifying Properties of a DSML using Alloy • Alloy is a structural language based on first-order logic, which provides effective techniques for model checking • Signatures represent the concepts of the domain • Relations are Signature fields that show relations between domain concepts • Facts are constraints about the Signatures and the Relations, which always hold for all the instances of the model • Predicates: are like facts, only represent temporary constraints and checked when needed • Asserts are constraints follows from the facts. A counterexample is generated by the Alloy analyzer when an assertion does not hold

8. Mapping a DSML Model to an Alloy Model • Automated model checking of a DSML requires interoperation of existing model checking tools with the syntax and semantics of a DSML. • mapping metamodel elements to Alloy abstract signatures • mapping model elements to Alloy concrete signatures • mapping graph transformation rules to Alloy predicates • mapping verification tasks to Alloy asserts

9. Case Study: The Maze Game Maze Game Instance with 3 Rooms, 6 Doors, 2 Weapons, and 1 Monster Maze Game Metamodel

10. User User * * - - roomIn roomIn * * Room Room 1 1 Door Door - - number number : . = : . = Door Door # # 1 1 The Behavioral Semantics of a User Move Activity

11. User * - roomIn * Room 1 Door - number : . = Door # 1 The Behavioral Semantics of a User Move Activity

12. Step-1: Mapping Metamodel Elements to Alloy Abstract Signatures Maze Game Metamodel Maze Game Alloy Abstract Signatures

13. Step-2: Mapping Model Elements to Alloy Concrete Signatures Maze Game Instance with 3 Rooms, 6 Doors, 2 Weapon, and 1 Monster Maze Game Alloy Concrete Signatures and InitGame Predicate

14. Step-3:Mapping Graph Transformation Rules to Alloy Predicates

15. Step-4: Mapping Sequence of Graph Transformation Rules to an Alloy Run Command run{ one init:Game | one g1:Game | one g2:Game | one g3:Game | one g4:Game | initGame[init] && ( !checkMove[init,#] && IllegalMove[init,g1]) || checkMove[init,#]&& changeRoom[init,g1,#] && !checkMonsterPower[g1] && dead[g1,g2] || checkMove[init,#]&& changeRoom[init,g1,#] && checkMonsterPower[g1] && subtractMonsterPower[g1,g2] && collectWeapon[g2,g3] && succesfulMove(g3,g4)

16. Step-5: Mapping Verification Tasks to Alloy Asserts • The verification task checks whether the given configuration is reachable from the initial graph • In the maze game, the designer defines one task to check the status of the user when he/she runs out of weapon power

17. Limitations & Future Work • Formal Definitions of the mappings • Graph Transformations Steps • Imperative to Declarative Mapping • Tool Support • Enable to define dynamic semantics visually • Enable to map DSML specifications to verification tools automatically • Optimization techniques during mapping steps to reduce state explosion • Conflict and Dependency Analysis

18. Conclusion • A simple case study for the verification of simple models using Alloy • Demonstration of how DSML designers can define semantic and verification specifications using visual models

19. This work funded in part by NSFCAREER award CCF-0643725. Question? Comments? zekzek@uab.edu www.cis.uab.edu/zekzek