A Semantic Framework for DSLs

1. This work funded in part by NSFCAREER award CCF-0643725. A Semantic Framework for DSLs ZekaiDemirezen Advisor: Dr. Jeff Gray Doctoral Symposium OOPSLA 2009 Software Composition and Modeling Lab

2. 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

3. Metamodel DEFINE Model Meta-Level Translation INTERPRET Interpreter 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 Model Interpreters Models Metamodel Definition Model Interpretation DSL Platforms and Semantics: GME Example Metamodeling Interface Application Domain Application Evolution Environment Evolution App 1 App 2 App 3 The semantics of a DSL is hard-coded into the model interpreter Modeling Environment Model Builder

4. Robot DSL 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) GRAMMAR P  Program CCommand P ::= begin C end C ::= left | right | up | down | C1C2

5. DSL Platforms and Semantics:GEMS Example Robot Semantics Robot Metamodel 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);

6. DSL Platforms and Semantics:Kermeta Example Robot Semantics Robot Metamodel 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)

7. DSL Platforms and Semantics: Atom3 Graph Rewriting Left Action Semantics Robot Metamodel LHS RHS = Pos_x Pos_y Pos_x-- Pos_y

8. 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

9. What is the Problem? • 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 Formal Notations π-calculus, Temporal Logic etc. MDE Tools, Programming Style activities Or, just skip semantics definitions…

10. 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

11. 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

12. Proposed Solution

13. Case Study: Maze Game Maze Game Instance with 3 Rooms, 6 Doors, 2 Weapons, and 1 Monster Maze Game Metamodel

14. The Behavioral Semantics of a User Move Activity User User * * - - roomIn roomIn * * Room Room 1 1 Door Door - - number number : . = : . = Door Door # # 1 1

15. The Behavioral Semantics of a User Move Activity User * - roomIn * Room 1 Door - number : . = Door # 1

16. Verifying Properties of a DSL 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 that follow from the facts. A counterexample is generated by the Alloy analyzer when an assertion does not hold

17. Mapping a DSL Model to an Alloy Model • 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 Signatures Predicates Asserts

18. Mapping Metamodel Elements to Alloy Abstract Signatures Maze Game Metamodel Maze Game Alloy Abstract Signatures

19. Mapping Model Elements to Alloy Concrete Predicates Maze Game Instance with 3 Rooms, 6 Doors, 2 Weapon, and 1 Monster Maze Game Alloy Concrete Signatures and InitGame Predicate

20. Transformation Rules to Alloy Predicates

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

22. Mapping Verification Tasks to Alloy Asserts • 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

23. 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 MoDeVVa2009 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

24. 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)

25. 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

26. 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

27. This work funded in part by NSFCAREER award CCF-0643725. Thank You & Questions ? zekzek@uab.edu www.cis.uab.edu/zekzek Software Composition and Modeling Lab