Verification of DSMLs Using Graph Transformation:

A Case Study with Alloy

Zekai Demirezen1, Marjan Mernik1,2, Jeff Gray1, Barrett Bryant1

1 Department of Computer and Information Sciences, University of Alabama at Birmingham

{zekzek, gray, bryant}@cis.uab.edu2 University of Maribor, Slovenia

marjan.mernik@uni-mb.siSoftware Composition and Modeling Laboratory

Department of Computer and Information SciencesUniversity of Alabama at Birmingham

S o f t C o mThis work funded in part by NSFCAREER award CCF-0643725.

Overview

Motivation

BackgroundSpecifying DSML Semantics

Case Study

Verification of DSML Models

Goals

Mapping a DSML Model to an Alloy

Model

DSML Specifications

MetaElem1 MetaElem2

MetaElem4

-End1

1

-End2

*

MetaElem3

-End3

*

-End4*

MetaElem5

MetaElem6

-End51

-End6

*

{OCL}

End1End2

MetaElem2

MetaElem5

{OCL}

End1End2

Abstract Syntax& Static Semantics

Model Verification Tools

Dynamic Semantics Verification Properties

ActionState1

ActionState3 ActionState4

ActionState5

NAC LHS RHS

MetaElem1 Meta2 Meta3-End7

1

-End8

*

Meta2 Meta3

Meta4 -End91

-End10

*

Alloy

ChangeRoom

SubtractMonsterPower

CollectWeapon

Move Door#

LegalMove

IlegalMove

MonsterPowerful

UserPowerful

Successful Move

(Check Move)

(Check Power)

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

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

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

An Outline of Our Approach

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

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

Case Study: The Maze Game

Maze Game Metamodel

Maze Game Instance with 3 Rooms, 6 Doors, 2 Weapons,

and 1 Monster

Game

-power : Integer

Weapon-power : Integer

Monster

-number : Integer

Door

-number : Integer

Room

-power : Integer-status : Integer

User

1

*

1 1

1

*

1

0..11

0..1

1

-openTo 1

1

-roomIn

1

- : Weapon = 4

Room1

- : Monster = 10

Room2

- : Weapon = 11

Room3

Door1 Door3

Door4

Door6

Door2

Door5

The Behavioral Semantics of a

User Move ActivityMove Door# Check Move

LHS RHS

TRUE

User

Room

Door

- number : . = Door#

* -roomIn*

1

1

ChangeRoom

SubtractMonsterPower

CollectWeapon

Move Door#

LegalMove

IllegalMove

MonsterPowerful

UserPowerful

Successful Move

Dead

(Check Move)

(Check Power)

ChangeRoom

SubtractMonsterPower

CollectWeapon

Move Door#

LegalMove

IllegalMove

MonsterPowerful

UserPowerful

Successful Move

Dead

(Check Move)

(Check Power)

Check Move

LHS RHS

TRUE

User

Room

Door

- number : . = Door #

*-roomIn*

1

1

The Behavioral Semantics of a

User Move ActivityMove Door# Check Move

LHS RHS

TRUE

User

Room

Door

- number : . = Door#

* -roomIn*

1

1

Change Room

LHS RHS

User

-number : . = X

Room

-number : . = Door#

Door

*-roomIn*

1

1

-number : . = Y

Room

1-openTo1

User

-number : . = Y

Room

*

-roomIn

*

-number : . = X

Room

-number : . = Door#

Door

1

1

1

-openTo1

ChangeRoom

SubtractMonsterPower

CollectWeapon

Move Door#

LegalMove

IllegalMove

MonsterPowerful

UserPowerful

Successful Move

Dead

(Check Move)

(Check Power)

Change Room

LHS RHS

User

-number : . = X

Room

-number : . = Door#

Door

*-roomIn*

1

1

-number : . = Y

Room

1-openTo1

User

-number : . = Y

Room

*

-roomIn

*

-number : . = X

Room

-number : . = Door#

Door

1

1

1

-openTo1

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

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

Step-3:Mapping Graph Transformation Rules to Alloy

PredicatesChange Room

LHS RHSUser

-number : . = X

Room

-number : . = Door#

Door

*

-roomIn*

1

1

-number : . = Y

Room

1-openTo1

User

-number : . = Y

Room

*

-roomIn

*

-number : . = X

Room

-number : . = Door#

Door

1

1

1

-openTo1

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)

}

LHSUser

-number : . = X

Room

-number : . = Door#

Door

*

-roomIn*

1

1

-number : . = Y

Room

1-openTo1

RHSUser

-number : . = Y

Room

*

-roomIn

*

-number : . = X

Room

-number : . = Door#

Door

1

1

1

-openTo1

Step-4: Mapping Sequence of Graph Transformation Rules to an Alloy Run

CommandMove 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)

ChangeRoom

SubtractMonsterPower

CollectWeapon

Move Door#

LegalMove

IllegalMove

MonsterPowerful

UserPowerful

Successful Move

Dead

(Check Move)

(Check Power)

Step-5: Mapping Verification Tasks to Alloy

Asserts

-power : = <0-status : = 1

User assert UserStatus(g:Game){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

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

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

Question? Comments?

zekzek@uab.edu

www.cis.uab.edu/zekzek

Software Composition and Modeling Laboratory

Department of Computer and Information SciencesUniversity of Alabama at Birmingham

S o f t C o mThis work funded in part by NSFCAREER award CCF-0643725.