1. Verification of DSMLs Using Graph Transformation: A Case Study with Alloy Zekai Demirezen 1, Marjan Mernik 1,2, Jeff Gray 1, Barrett Bryant 1 1 Department 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 This work funded in part by NSF CAREER award CCF-0643725.

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

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 designers 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 Metamodel Maze Game Instance with 3 Rooms, 6 Doors, 2 Weapons, and 1 Monster

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

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

12. Step-1: Mapping Metamodel Elements to Alloy Abstract Signatures Maze Game Metamodel abstract sig Game{ rooms:set Room, user: one User } abstract sig Room{ number:one Int, doors:set Door, monster:one Monster, weapon:one Weapon } abstract sig Door{ number:one Int, openTo:one Room } abstract sig User{ power:one Int, roomIn:one Int, status:one Int } abstract sig Weapon{ power:one Int } abstract sig Monster{ power:one Int } 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 one sig R1,R2,R3 extends Room{} one sig D1,D2,D3,D4,D5,D6 extends Door{} one sig M1 extends Monster{} one sig G1,G2 extends Weapon{} one sig U1 extends User{} pred initGame(g:Game){ } Maze Game Alloy Concrete Signatures and InitGame Predicate pred initGame(g:Game){ D1.number=1 && D2.number=2 && D3.number=3 && D4.number=4 && D5.number=5 && D6.number=6 && D1.openTo=R2 && D2.openTo=R3 && D3.openTo=R1 && D4.openTo=R3 && D5.openTo=R1 && D6.openTo=R2 && g.rooms=R1+R2+R3 && R1.number=1 && R2.number=2 && R3.number=3 && M1.power=10 && G1.power=4 && G2.power=11 && g.user=U1 && R1.weapon=G1 && R1.doors=D1+D2 && U1.power=9 && U1.status=0 && R2.monster=M1 && R2.doors=D3+D4 && R3.weapon=G2 && R3.doors=D5+D6 && U1.roomIn=1

14. Step-3:Mapping Graph Transformation Rules to Alloy Predicates Change Room LHSRHS pred changeRoom(g:Game, g:Game, rNo:Int) { one room: g.rooms | one door:room.doors | one nextRoom: door.openTo | g.user.roomIn=room.number && nextRoom.number=rNo && g.user.roomIn!=g.user.roomIn && g.rooms=g.rooms && g.user.power=g.user.power && g.user.roomIn=rNo) } LHS RHS

15. Step-4: Mapping Sequence of Graph Transformation Rules to an Alloy Run Command Move Door# 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 assert UserStatus(g:Ga me){ g.user.power<0 && g.user.status=1 (Dead) } 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. Question ? Comments ? zekzek@uab.edu www.cis.uab.edu/zekzek This work funded in part by NSF CAREER award CCF-0643725.