Post on 28-Mar-2015
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.