Interacting Domain Specific Languages

Developing Interacting Domain Specific Languages

Developing Interacting Domain Specific LanguagesMaster’s thesis

Sander Mak

Center for Software Technology, Universiteit Utrecht

October 25, 2007

Supervisor : Doaitse SwierstraDaily supervision : Bastiaan Heeren

Eelco Visser

Center for Software Technology Sander Mak

Developing Interacting Domain Specific Languages > Introduction

Outline

1 Introduction

2 DomainModel

3 WebLayer

4 Interaction

5 Reflection

6 Conclusion



Domain Specific Language

Advantages:

Increased productivity

Increased quality

Clarity by abstraction



Languages?

Why the plural, i.e. DSLs

One-size fits all, monolithicapproaches generally notsuccesful (like 4GLs)

Separation of concerns, and:reusability of DSL in othercontexts

Premise: Technical domains are agood unit of composition

Research questions:

1 Are multiple interacting DSLs feasible?

2 How should interaction be concretized and implemented?



Languages?





Research questions:





Languages?





Research questions:





Languages?





Research questions:





The case study

DomainModel Modeling domain data, generatingJPA (similar to Hibernate) implementation

WebLayer Modeling the view side of web-applications,generating Seam/JSF/Facelets

BusinessRules Modeling functionality specific to a domain

Different compilers, one goal: build a complete Java based web-app



Goals

Why create DSLs for these domains:

Increase productivityAbstract away from implementation details, focus on domainconcepts (also gives more clarity)Java frameworks are (inherently?) verbose

Increase qualityDynamic, interpreted mechanisms subvert static safety of Java codeReport domain specific errors

What is explicitly not our goal:

creation of production quality languages,unleashing every bit of power of target frameworks



Goals








Goals






Intended use

To create data-intensive web-applications, within confines ofcompany guidelines.

‘You can’t be everything to everyone,so be something for someone’


Developing Interacting Domain Specific Languages > DomainModel

DomainModel language

Language for defining persistent domain (or data) models

Essential features:

Concise definition of concepts (entities)

Generates JPA implementation (standardized library)

Encodes domain specific technical knowledge (e.g. object identity)

Allows for domain specific semantic checking

May be used in combination with different DSLs



Concept definition

concept BlogEntry {title :: String (name, required)abstract :: Stringcontents :: String (required)user -> Userdate :: Date (name)tags -> [Tag]replies <> [Reply]category :: {"Technical" : TECH, "Other" : NONTECH}trackback :: URL

}



Concept definition


}

Types: Value, Extended (validated), Concept, List, Enumeration



Concept definition


}




Concept definition


}




Concept definition


}




Concept definition


}




Concept definition


}

Associations: Value, Reference, Composite



Concept definition


}




Concept definition


}




Concept definition


}

DomainModel annotations



Concept definition


}




Concept definition


}


Compiling a DomainModel concept

Definition BlogEntry results in BlogEntry.java, apersistable JPA entity:

268 LoC



Concept definition


}


Q: Isn’t DomainModel almost the same as UML Class diagrams?

A: Yes!

We even ’borrowed’ some of the association symbols

’−>’ for references’<>’ for composites

That way, prior UML knowledge helps when usingDomainModel

Theoretically, a UML class diagram could serve as input forthe DomainModel compiler (if only we had a UMLfront-end)


Developing Interacting Domain Specific Languages > WebLayer

WebLayer language

Language for defining pages (views) in web-app

Essential features:

Works seamlessly with DomainModel definitions

Abstracts away from the Seam framework and Java intricacies

Strongly typed

Explicit, checked data-flow between pages

Generic constructs



WebLayer compiler



Page definition

page ViewBlog(BlogEntry be, User u){var Reply r

header(be.title + " (written on " + be.date + ")")text(be.contents)table Tag t in be.tags { "Assigned tags" -> t.tagName }

"Reply to this post:"form( input(r)

action( "Add reply", r.user = u; be.replies.add(r); be.save())

)

text("Replies for post " + be.title + " :")for Reply r in be.replies { show(r) }navigate("Home", Blog(u))

}Center for Software Technology Sander Mak


Page definition





)




Page definition





)


}

Multiple page definitions in one file, starting with a header:

weblayer blog

using domainmodel blog



Page definition





)




Page definition





)




Page definition





)




Page definition





)




Page definition





)




Page definition





)




Page definition





)


}

Ideas for extension

Query language

Partial page abstraction

Parameterized, reusable actions

...



Issues

Layout is more or less fixed

Example: every page element is placed beneath each otherWe don’t want to replicate all of HTML inside WebLayerPartial solution: embed generated page in freely editable templateFor the rest: make assumptions, although compiler becomes morespecific

Editing lists

Our solution is specific and ad-hoc

Action language

Why not, for example, embed Java?


Developing Interacting Domain Specific Languages > Interaction

DSL Interaction

We can use DomainModel constructs within WebLayer, but how doesthis interaction work?

Goals

Interaction must be intuitive to DSL user

Languages must be as separate as possible

For the sake of reusability

Generated code must statically link

Our solution

Separate compilation for each DSL, communicating essentialinformation through interface files.



DSL Interaction


Goals





Our solution




DSL Interaction


Goals





Our solution


Separate compilation illustrated



Interface files

DSL compiler emits interface file. We chose ATerms as genericrepresentation format.

Interface characteristics

Aggregates information

Contains disambiguated information

Contains linking information (types, hooks)

Written interface guarantees a consistent, checked module to bepresent

One way to view interface file mechanism is as cache for compileroperations

Issues: explicit vs. implicit interface, cyclic dependencies betweenDSLs



Interface files











Interface files









Q: Why cache, are these operations so expensive?

A: No, not at all. The issue is that the importing compilerotherwise needs to know how to perform these operations. Wedon’t want that, since it breaks our notion of modular interactinglanguages!



Interface files










Developing Interacting Domain Specific Languages > Reflection

Does this approach really work?

Promises of model driven software development:

Gain productivity

Gain quality

... so do we live up to this expectation?

Productivity:1 The factor ∼14 increase in LoC seems to be typical2 DRY: refactoring in DSL code is much easier3 Start-up costs manageable

Quality:1 DSL Type checker guarantees correctness of dynamic

constructions (and there’s much of that in Java web frameworks!)2 Typed, explicit dataflow between pages3 Concrete example: guaranteed prevention of cross-site scripting





Gain productivity

Gain quality

... so do we live up to this expectation?LoC metrics - Blog example

DSL Source Generated code

DomainModel 45Java 801XML 22

WebLayer 110Java 841

XML/Facelets 501XML 48

Totals 155 2213 ∼ ×14








Gain productivity

Gain quality









Gain productivity

Gain quality







Drawbacks of our approach

Every semantic check must be written from scratch

For each DSL

Type checking, resolving symbolic references, and so on

Fortunately, we can get very specific with our checks andassociated messages

Module system must be written from scratch

This might be solved generically (parameterizing over interfacedefinitions), though we have not researched this

What are the semantics of our DSLs?





For each DSL










For each DSL








Alternative approaches

Embedded DSLs

Asynchronous, runtime linking of generated code (independentcode generation)

Larger role for the IDE

Long-term: active libraries and a universal language

Realistically, this probably never happens



Alternative approaches

Embedded DSLs

Asynchronous, runtime linking of generated code (independentcode generation)

Larger role for the IDE

Long-term: active libraries and a universal language

Realistically, this probably never happens


Developing Interacting Domain Specific Languages > Conclusion

Demonstration



Topics not discussed... but interesting nevertheless

1 Actual implementation details of compilers

Implemented using Stratego/XT toolkit

2 BusinessRules interface definition

To overcome limitations of WebLayer action language in multipleDSL style

3 Interaction with GPL code

Necessary for real-world adoptation, but how to implement it?

4 Much more context and related work

... my thesis will be available shortly



Concluding remarks

Interacting DSLs indeed feasible

Especially suited for layered architectures (like web-applications)DSLs encode principled usage of frameworks and frameworkinteraction

Interaction implemented through interface files

Separate compilation allows for reuse of DSLsImplicit interface may be a limiting factor

DSLs for technical domains are a serious option for a company topursue, with demonstrated advantages, but also requiring considerableeffort.
