Upload
eugene-garrett
View
220
Download
0
Embed Size (px)
Citation preview
A Semantic Framework for DSLs
Zekai DemirezenAdvisor: Dr. Jeff Gray
Doctoral SymposiumOOPSLA 2009
S o f t C o m
Software Composition and Modeling Lab
This work funded in part by NSFCAREER award CCF-0643725.
DSL and Semantics
Domain-Specific Languages (DSLs) enable end-users to specify their own programs using domain concepts in the problem space, rather than programming language concepts in the technical solution space
DSLs, like any other language, consist of definitions that specify the abstract syntax, concrete syntax, static semantics and dynamic semantics of the language
A primary shortcoming that can be found in many domain-specific modeling approaches and tools is the lack of formal semantics to define the meaning of a modeling abstraction
ModelInterpretati
on
Model Interpreters
Models
Modeling Environment
ApplicationDomain
App1
App2
App3
Application Evolution
Environment Evolution
MetamodelingInterface
Metamodel Definition
Meta-Level
Translation
Model Builder
DSL Platforms and Semantics: GME Example
Metamodel
Model
Interpreter
void CComponent::InvokeEx(CBuilder &builder,CBuilderObject *focus, CBuilderObjectList &selected, long param) {CString DMSRoot = "";DMSRoot = SelectFolder("Please Select DMSRoot Folder:");if (DMSRoot != "") {DMSRulePath = DMSRoot + RULESPATH + "Rules\\";MSRuleApplierPath = DMSRoot + RULESPATH + "RuleApplier\\";AfxMessageBox("DMSRulePath = " + DMSRulePath , MB_OK);CString OEPRoot = "";OEPRoot = SelectFolder("Please Selec
DEFINE
INTERPRET
The semantics of a DSL is hard-coded into the model interpreter
Robot DSLGRAMMAR
P ProgramC CommandP ::= begin C endC ::= left | right | up | down | C1C2
PROGRAMbegin left up down upend
DENOTATIONAL SEMANTICS
P : Program → Int*IntP [[ begin C end ]] = C [[ C ]] (0,0) C :: Command → Int*Int → Int*Int
C [[ left ]] (x,y) = (x+Δx,y+Δy) where Δx=-1 and Δy=0
C [[ right ]] (x,y) = (x+Δx,y+Δy) where Δx=+1 and Δy=0
C [[ down ]] (x,y) = (x+Δx,y+Δy) where Δx=0 and Δy=-1
C [[ up ]] (x,y) = (x+Δx,y+Δy) where Δx=0 and Δy=+1
C [[ C1 C2 ]] (x,y) = let (x+Δx1, y+Δy1) = C [[ C1]] (x,y) in let (x+Δx1+Δx2, y+Δy1+Δy2) = C [[ C2]] (x+Δx1, y+Δy1) in (x+Δx1+Δx2, y+Δy1+Δy2)
DSL Platforms and Semantics:GEMS Example
Robot MetamodelRobot Metamodel Robot SemanticsRobot Semantics
public class RobotInterpreter extends AbstractInterpreter{
public void visitLeft(Left tovisit) {
}public void visitRight(Right tovisit) {…}public void visitUp(Up tovisit) {…}public void visitDown(Down tovisit) {…}
int temp_x = Integer.parseInt((String)(tovisit. getParent().getAttribute("Pos_x"))); int temp_y = Integer.parseInt((String)(tovisit. getParent().getAttribute("Pos_y"))); MakeAction((Robot)(tovisit.getParent()), tovisit, temp_x, temp_y); displayRobotPosition(tovisit);visitContainer(tovisit);
int temp_x=Integer.parseInt((String)(toVisit.getParent().getAttribute("Pos_x"))); int temp_y=Integer.parseInt((String)(toVisit.getParent().getAttribute("Pos_y"))); MakeAction((Robot)(toVisit.getParent()),toVisit, temp_x,temp_y); displayRobotPosition(tovisit);visitContainer(tovisit);
DSL Platforms and Semantics:Kermeta Example
Robot MetamodelRobot Metamodel Robot SemanticsRobot Semantics
class Robot { attribute pos_x:int; attribute pos_y:int; reference actionList:Action[0..1]; operation run():int is do actionList.move(this); end}class Action{ operation move(r:Robot ):int is do end}
class Left{
operation move(r:Robot):int{ r.pos_x:=r.pos_x-1; } }
Run()
Move(Robot r)
DSL Platforms and Semantics: Atom3 Graph Rewriting
Pos_x
Pos_y
Pos_x--
Pos_y
=
LHS RHS
Left Action SemanticsLeft Action SemanticsRobot MetamodelRobot Metamodel
Other Semantics Definition Techniques
Agrawal et al (2003) and Chen et al (2005) utilize what they call a semantic anchoring technique to map abstract syntax models to existing ASM semantic domains in the GME platform
Ruscio et al (2006) propose a similar technique, except the ASM mapping is integrated within the AMMA platform
Knapp (1999) uses temporal logic Overgaard (2000) advocates the π-calculus to
define semantics Eichler et al (2006) utilize action semantics to
model behavior Hahn (2008) captures semantic information as
Object-Z specifications
Although the formal structures of these related works are suitable for usage with model verification and simulation tools, the specific approaches require expertise in notations and formalisms that are not generally within the skillsets of most designers
What is the Problem?
MDE Tools, Programming Style activities
Formal Notationsπ-calculus, Temporal Logic etc.
Or, just skip semantics definitions…
Problems Related with Limitations of DSL Semantics
Lack of semantic reasoning, which is needed for proofs
Lack of formal proof of the optimization Hard to comprehend semantics Hard to generate model interpreters
automatically Limitations in proving properties of domain
concepts
Proposed Solution
A semantic framework that can be used by DSL designers in a visual manner, yet has a formal foundation that will permit Code Generation Model Verification Simulation
Proposed Solution
Case Study: 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 Activity
Move 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 Activity
Move 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
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 that follow from the facts. A counterexample is generated by the Alloy analyzer when an assertion does not hold
Verifying Properties of a DSL using Alloy
Automated model checking of a DSL requires interoperation of existing model checking tools with the syntax and semantics of a DSL 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
Mapping a DSL Model to an Alloy Model
Predicates
Asserts
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
Mapping Metamodel Elements to Alloy Abstract 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
Mapping Model Elements to Alloy Concrete Predicates
Change 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
Transformation Rules to Alloy Predicates
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)
ChangeRoom
SubtractMonsterPower
CollectWeapon
Move Door#
LegalMove
IllegalMove
MonsterPowerful
UserPowerful
Successful Move
Dead
(Check Move)
(Check Power)
Mapping Sequence of Graph Transformations Rules to an Alloy Run
Command
-power : = <0-status : = 1
User assert UserStatus(g:Game){g.user.power<0 && g.user.status=1}
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
Mapping Verification Tasks to Alloy Asserts
Current Status
This presentation demonstrates how DSL designers can define semantic and verification specifications using visual models
It is a preliminary study that was presented at the MoDeVVa 2009 workshop.
Formal definitions of the mappings and tool support are not completed yet
Further need for additional experimentation in other domains with different validation tasks
Expected Contributions
Functionalities to enable DSL designers to define semantic specifications using visual models
Model verification and model analysis within domain boundaries
Optimization techniques during mapping steps to reduce state explosion. (Such as conflict and dependency analysis between translation rules)
Plan for Evaluation
Control whether semantic specification can be defined visually by DSL designers with model concepts, and whether model verification tools can be instantly executed within domain boundaries
Use several unique domains (e.g., real-time, financial) that each have a representative DSL
Check specification complexities of state transition, sequence of transitions, and verification task definitions
Compare the proposed semantic framework with other semantics techniques
Evaluation Criteria: Comprehensibility, ease of use, amount of time to design a new DSL, and compatibility with verification tools
Milestones Toward Dissertation Defense
Summer 2010: Dissertation Proposal 2009-2010: Software Prototype and Proof of
Concepts Modeling Editor which integrates Graph
Transformation and Activity Diagram and captures semantics specifications
Mapping Software to transform semantics specifications into models for verification tools
2010-2011: Formal Definitions (Definition of Semantic Specification Language, Definitions of Transformation Steps, Definition of Optimization Steps)
2011-2012: Evaluation Spring 2012: Dissertation Defense
www.cis.uab.edu/zekzek
Thank You & Questions ?
S o f t C o m
Software Composition and Modeling Lab
This work funded in part by NSFCAREER award CCF-0643725.