• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Interacting Domain Specific Languages
 

Interacting Domain Specific Languages

on

  • 1,596 views

My final thesis presentation describing research on multiple interacting Domain Specific Languages.

My final thesis presentation describing research on multiple interacting Domain Specific Languages.

Statistics

Views

Total Views
1,596
Views on SlideShare
1,591
Embed Views
5

Actions

Likes
1
Downloads
37
Comments
0

2 Embeds 5

http://www.slideshare.net 3
http://www.linkedin.com 2

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Interacting Domain Specific Languages Interacting Domain Specific Languages Presentation Transcript

    • Developing Interacting Domain Specific Languages Developing Interacting Domain Specific Languages Master’s thesis Sander Mak Center for Software Technology, Universiteit Utrecht October 25, 2007 Supervisor : Doaitse Swierstra Daily supervision : Bastiaan Heeren Eelco Visser Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Introduction Outline Introduction 1 DomainModel 2 WebLayer 3 Interaction 4 Reflection 5 Conclusion 6 Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Introduction Domain Specific Language Increased productivity Increased quality Advantages: Clarity by abstraction Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Introduction Languages? Why the plural, i.e. DSLs Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Introduction Languages? Why the plural, i.e. DSLs One-size fits all, monolithic approaches generally not succesful (like 4GLs) Separation of concerns, and: reusability of DSL in other contexts Premise: Technical domains are a good unit of composition Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Introduction Languages? Why the plural, i.e. DSLs One-size fits all, monolithic approaches generally not succesful (like 4GLs) Separation of concerns, and: reusability of DSL in other contexts Premise: Technical domains are a good unit of composition Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Introduction Languages? Why the plural, i.e. DSLs One-size fits all, monolithic approaches generally not succesful (like 4GLs) Separation of concerns, and: reusability of DSL in other contexts Premise: Technical domains are a good unit of composition Research questions: Are multiple interacting DSLs feasible? 1 How should interaction be concretized and implemented? 2 Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Introduction The case study DomainModel Modeling domain data, generating JPA (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 Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Introduction Goals Why create DSLs for these domains: Increase productivity Abstract away from implementation details, focus on domain concepts (also gives more clarity) Java frameworks are (inherently?) verbose Increase quality Dynamic, interpreted mechanisms subvert static safety of Java code Report domain specific errors Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Introduction Goals Why create DSLs for these domains: Increase productivity Abstract away from implementation details, focus on domain concepts (also gives more clarity) Java frameworks are (inherently?) verbose Increase quality Dynamic, interpreted mechanisms subvert static safety of Java code Report domain specific errors What is explicitly not our goal: creation of production quality languages, unleashing every bit of power of target frameworks Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Introduction Goals Why create DSLs for these domains: Intended use Increase productivity To create data-intensive web-applications, focus on confines of within domain Abstract away from implementation details, company guidelines. gives more clarity) concepts (also Java frameworks are (inherently?) verbose Increase quality Dynamic, interpreted mechanisms subvert static safety of Java code ‘You can’t be everything to everyone, Report domain specific errors so be something for someone’ What is explicitly not our goal: creation of production quality languages, unleashing every bit of power of target frameworks Center for Software Technology Sander Mak
    • 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 Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String contents :: String (required) user -> User date :: Date (name) tags -> [Tag] replies <> [Reply] category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String contents :: String (required) user -> User date :: Date (name) tags -> [Tag] replies <> [Reply] category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } Types: Value, Extended (validated), Concept, List, Enumeration Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String contents :: String (required) user -> User date :: Date (name) tags -> [Tag] replies <> [Reply] category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } Types: Value, Extended (validated), Concept, List, Enumeration Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String contents :: String (required) user -> User date :: Date (name) tags -> [Tag] replies <> [Reply] category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } Types: Value, Extended (validated), Concept, List, Enumeration Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String contents :: String (required) user -> User date :: Date (name) tags -> [Tag] replies <> [Reply] category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } Types: Value, Extended (validated), Concept, List, Enumeration Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String contents :: String (required) user -> User date :: Date (name) tags -> [Tag] replies <> [Reply] category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } Types: Value, Extended (validated), Concept, List, Enumeration Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String contents :: String (required) user -> User date :: Date (name) tags -> [Tag] replies <> [Reply] category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } Associations: Value, Reference, Composite Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String contents :: String (required) user -> User date :: Date (name) tags -> [Tag] replies <> [Reply] category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } Associations: Value, Reference, Composite Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String contents :: String (required) user -> User date :: Date (name) tags -> [Tag] replies <> [Reply] category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } Associations: Value, Reference, Composite Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String contents :: String (required) user -> User date :: Date (name) tags -> [Tag] replies <> [Reply] category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } DomainModel annotations Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String contents :: String (required) user -> User date :: Date (name) tags -> [Tag] replies <> [Reply] category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } DomainModel annotations Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { title :: String (name, required) abstract :: String Compiling a DomainModel concept contents :: String (required) Definition -> User BlogEntry results in BlogEntry.java, a user persistable:: Date JPA entity: (name) date tags -> [Tag] replies <> [Reply] 268 LoC category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} trackback :: URL } DomainModel annotations Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > DomainModel Concept definition concept BlogEntry { Q: Isn’t DomainModel almost the same as UML Class diagrams? title :: String (name, required) A: Yes! abstract :: String contents :: String (required) userWe even ’borrowed’ some of the association symbols -> User date ’− :: Date >’ for references (name) ’<>’ for composites tags -> [Tag] replies way, prior UML knowledge helps when using <> [Reply] That category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH} DomainModel trackback :: URL UML class diagram could serve as input for Theoretically, a } the DomainModel compiler (if only we had a UML front-end) DomainModel annotations Center for Software Technology Sander Mak
    • 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 Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer WebLayer compiler Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer Page definition page ViewBlog(BlogEntry be, User u){ var Reply r header(be.title + quot; (written on quot; + be.date + quot;)quot;) text(be.contents) table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName } quot;Reply to this post:quot; form( input(r) action( quot;Add replyquot; , r.user = u; be.replies.add(r); be.save()) ) text(quot;Replies for post quot; + be.title + quot; :quot;) for Reply r in be.replies { show(r) } navigate(quot;Homequot;, Blog(u)) } Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer Page definition page ViewBlog(BlogEntry be, User u){ var Reply r header(be.title + quot; (written on quot; + be.date + quot;)quot;) text(be.contents) table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName } quot;Reply to this post:quot; form( input(r) action( quot;Add replyquot; , r.user = u; be.replies.add(r); be.save()) ) text(quot;Replies for post quot; + be.title + quot; :quot;) for Reply r in be.replies { show(r) } navigate(quot;Homequot;, Blog(u)) } Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer Page definition page ViewBlog(BlogEntry be, User u){ Multiple page definitions in one file, starting with a header: var Reply r weblayer blog header(be.title + quot; (written on quot; + be.date + quot;)quot;) text(be.contents) using domainmodel blog{ quot;Assigned tagsquot; -> t.tagName } table Tag t in be.tags quot;Reply to this post:quot; form( input(r) action( quot;Add replyquot; , r.user = u; be.replies.add(r); be.save()) ) text(quot;Replies for post quot; + be.title + quot; :quot;) for Reply r in be.replies { show(r) } navigate(quot;Homequot;, Blog(u)) } Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer Page definition page ViewBlog(BlogEntry be, User u){ var Reply r header(be.title + quot; (written on quot; + be.date + quot;)quot;) text(be.contents) table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName } quot;Reply to this post:quot; form( input(r) action( quot;Add replyquot; , r.user = u; be.replies.add(r); be.save()) ) text(quot;Replies for post quot; + be.title + quot; :quot;) for Reply r in be.replies { show(r) } navigate(quot;Homequot;, Blog(u)) } Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer Page definition page ViewBlog(BlogEntry be, User u){ var Reply r header(be.title + quot; (written on quot; + be.date + quot;)quot;) text(be.contents) table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName } quot;Reply to this post:quot; form( input(r) action( quot;Add replyquot; , r.user = u; be.replies.add(r); be.save()) ) text(quot;Replies for post quot; + be.title + quot; :quot;) for Reply r in be.replies { show(r) } navigate(quot;Homequot;, Blog(u)) } Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer Page definition page ViewBlog(BlogEntry be, User u){ var Reply r header(be.title + quot; (written on quot; + be.date + quot;)quot;) text(be.contents) table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName } quot;Reply to this post:quot; form( input(r) action( quot;Add replyquot; , r.user = u; be.replies.add(r); be.save()) ) text(quot;Replies for post quot; + be.title + quot; :quot;) for Reply r in be.replies { show(r) } navigate(quot;Homequot;, Blog(u)) } Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer Page definition page ViewBlog(BlogEntry be, User u){ var Reply r header(be.title + quot; (written on quot; + be.date + quot;)quot;) text(be.contents) table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName } quot;Reply to this post:quot; form( input(r) action( quot;Add replyquot; , r.user = u; be.replies.add(r); be.save()) ) text(quot;Replies for post quot; + be.title + quot; :quot;) for Reply r in be.replies { show(r) } navigate(quot;Homequot;, Blog(u)) } Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer Page definition page ViewBlog(BlogEntry be, User u){ var Reply r header(be.title + quot; (written on quot; + be.date + quot;)quot;) text(be.contents) table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName } quot;Reply to this post:quot; form( input(r) action( quot;Add replyquot; , r.user = u; be.replies.add(r); be.save()) ) text(quot;Replies for post quot; + be.title + quot; :quot;) for Reply r in be.replies { show(r) } navigate(quot;Homequot;, Blog(u)) } Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer Page definition page ViewBlog(BlogEntry be, User u){ var Reply r header(be.title + quot; (written on quot; + be.date + quot;)quot;) text(be.contents) table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName } quot;Reply to this post:quot; form( input(r) action( quot;Add replyquot; , r.user = u; be.replies.add(r); be.save()) ) text(quot;Replies for post quot; + be.title + quot; :quot;) for Reply r in be.replies { show(r) } navigate(quot;Homequot;, Blog(u)) } Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer Page definition page ViewBlog(BlogEntry be, User u){ var Reply r header(be.title + quot; (written on quot; + be.date + quot;)quot;) text(be.contents) Ideas for extension table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName } Query language quot;Reply to this page abstraction Partial post:quot; form( input(r) Parameterized, reusable actions action( quot;Add replyquot; ... , r.user = u; be.replies.add(r); be.save()) ) text(quot;Replies for post quot; + be.title + quot; :quot;) for Reply r in be.replies { show(r) } navigate(quot;Homequot;, Blog(u)) } Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > WebLayer Issues Layout is more or less fixed Example: every page element is placed beneath each other We don’t want to replicate all of HTML inside WebLayer Partial solution: embed generated page in freely editable template For the rest: make assumptions, although compiler becomes more specific Editing lists Our solution is specific and ad-hoc Action language Why not, for example, embed Java? Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Interaction DSL Interaction We can use DomainModel constructs within WebLayer, but how does this 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 Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Interaction DSL Interaction We can use DomainModel constructs within WebLayer, but how does this 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 essential information through interface files. Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Interaction DSL Interaction Separate compilation illustrated We can use DomainModel constructs within WebLayer, but how does this 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 essential information through interface files. Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Interaction Interface files DSL compiler emits interface file. We chose ATerms as generic representation format. Interface characteristics Aggregates information Contains disambiguated information Contains linking information (types, hooks) Written interface guarantees a consistent, checked module to be present Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Interaction Interface files DSL compiler emits interface file. We chose ATerms as generic representation format. Interface characteristics Aggregates information Contains disambiguated information Contains linking information (types, hooks) Written interface guarantees a consistent, checked module to be present One way to view interface file mechanism is as cache for compiler operations Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Interaction Interface files DSL compiler emits interface file. We chose ATerms as generic representation format. Interface characteristics Aggregates information Q: Why cache, are these operations so expensive? A: No, not at all. The information the importing compiler Contains disambiguated issue is that otherwise needs toinformation (types, hooks) Contains linking know how to perform these operations. We don’t want that, since it breaks our notion of modular interacting Written interface guarantees a consistent, checked module to be languages! present One way to view interface file mechanism is as cache for compiler operations Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Interaction Interface files DSL compiler emits interface file. We chose ATerms as generic representation format. Interface characteristics Aggregates information Contains disambiguated information Contains linking information (types, hooks) Written interface guarantees a consistent, checked module to be present One way to view interface file mechanism is as cache for compiler operations Issues: explicit vs. implicit interface, cyclic dependencies between DSLs Center for Software Technology Sander Mak
    • 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? Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Reflection Does this approach really work? Promises of model driven software development: Gain productivity Gain quality LoC metrics - Blog example ... so do we live up to this expectation? DSL Source Generated code DomainModel 45 Java 801 XML 22 WebLayer 110 Java 841 XML/Facelets 501 XML 48 ∼ ×14 Totals 155 2213 Center for Software Technology Sander Mak
    • 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 typical 2 DRY: refactoring in DSL code is much easier 3 Start-up costs manageable Center for Software Technology Sander Mak
    • 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 typical 2 DRY: refactoring in DSL code is much easier 3 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 pages 3 Concrete example: guaranteed prevention of cross-site scripting Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Reflection 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 and associated messages Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Reflection 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 and associated messages Module system must be written from scratch This might be solved generically (parameterizing over interface definitions), though we have not researched this Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Reflection 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 and associated messages Module system must be written from scratch This might be solved generically (parameterizing over interface definitions), though we have not researched this What are the semantics of our DSLs? Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Reflection Alternative approaches Embedded DSLs Asynchronous, runtime linking of generated code (independent code generation) Larger role for the IDE Long-term: active libraries and a universal language Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Reflection Alternative approaches Embedded DSLs Asynchronous, runtime linking of generated code (independent code generation) Larger role for the IDE Long-term: active libraries and a universal language Realistically, this probably never happens Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Conclusion Demonstration Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Conclusion Topics not discussed ... but interesting nevertheless Actual implementation details of compilers 1 Implemented using Stratego/XT toolkit BusinessRules interface definition 2 To overcome limitations of WebLayer action language in multiple DSL style Interaction with GPL code 3 Necessary for real-world adoptation, but how to implement it? Much more context and related work 4 ... my thesis will be available shortly Center for Software Technology Sander Mak
    • Developing Interacting Domain Specific Languages > Conclusion Concluding remarks Interacting DSLs indeed feasible Especially suited for layered architectures (like web-applications) DSLs encode principled usage of frameworks and framework interaction Interaction implemented through interface files Separate compilation allows for reuse of DSLs Implicit interface may be a limiting factor DSLs for technical domains are a serious option for a company to pursue, with demonstrated advantages, but also requiring considerable effort. Center for Software Technology Sander Mak