A Semantic Framework for DSLs Zekai Demirezen Advisor: Dr. Jeff Gray Doctoral Symposium OOPSLA 2009 Software Composition and Modeling Lab This work funded in part by NSF CAREER award CCF

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

Model Interpretation Model Interpreters Models Modeling Environment Application Domain App 1 App 2 App 3 Application Evolution Environment Evolution Metamodeling Interface Metamodel Definition Meta-Level Translation Model Builder DSL Platforms and Semantics: GME Example MetamodelMetamodel ModelModel InterpreterInterpreter void CComponent::InvokeEx(CBuilder &buil der,CBuilderObject *focus, CBui lderObjectList &selected, long param) { CString DMSRoot = ""; DMSRoot = SelectFolder("Please Select DMS Root 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 DSL GRAMMAR P  Program C  Command P ::= begin C end C ::= left | right | up | down | C1C2 PROGRAM begin left up down up end DENOTATIONAL SEMANTICS P : Program → Int*Int P [[ 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 Metamodel Robot 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 Metamodel Robot 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: Atom 3 Graph Rewriting Pos_x Pos_y Pos_x-- Pos_y = LHSRHS Left Action Semantics Robot 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

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

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

 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 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 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) Mapping Sequence of Graph Transformations Rules to an Alloy Run Command

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 : 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 : Formal Definitions (Definition of Semantic Specification Language, Definitions of Transformation Steps, Definition of Optimization Steps) : Evaluation Spring 2012: Dissertation Defense

Thank You & Questions ? Software Composition and Modeling Lab This work funded in part by NSF CAREER award CCF