Udostępnij za pośrednictwem

Domain specific languages express software refinements

  • Artykuł

Simon Johnston of IBM has written a note about DSLs (domain specific languages) compared with UML.

One of the excellent points he makes is that very few tools support refinement properly -- that is, the layering of a design from abstract requirements to detailed implementation, with the layers connected by abstraction relations. One of the things I did before joining Microsoft was to develop a UML-based method, Catalysis, that was strong on refinement, so I support this wholeheartedly.

But it's also one of the biggest reasons I like the idea of DSLs. Designing and keeping track of the refinements -- especially when one of the layers changes -- is tedious and time-consuming, and doesn't ever get done properly.

With DSLs, there is (in a sense) less need for refinement. Your domain-specific language expresses the concepts of your domain. When I write in SQL, for example, I don't need to understand how a database works, I just need to understand what a query is. When I design a web page with a WYSIWYG tool, I don't need to know HTML, or how a web browser works: I just need to know what I want the page to look like.

The implementation of the DSL captures the refinements -- that is, the architecture and patterns that are appropriate for this domain. So, yes, the refinements are there; but we've separated them out.

So if my next project is to design a big financial trading system, I'll start by designing a language that is good for expressing financial trading systems and which helps you see immediately the differences between one such system and another, and doesn't say anything about what they all have in common. Then I'll set to work to design a platform that implements that language. And the benefit is that the high-level design -- about what this particular system is currently required to do -- will be decoupled from the implementation of the language, and can be responsive to changes. And my refinement -- the mapping of high-level concepts to detailed design --- is captured as the design of the language; and I don't have to update it every time I change the high-level design.

In summary, a DSL represents a class of refinements; so you don't need to redefine the refinement every time you change the top level.

Comments

  • Anonymous
    June 10, 2004
    Not that I disagree with the intent of the following:

    "When I write in SQL, for example, I don't need to understand how a database works"

    but I think you over-simplified it a LOT!

    An SQL user/programmer most certainly DOES need to understand set algebra and how the database makes use of it in respect to how data is stored (in tables, versus trees for instance) and the relational methods and metadata (foreign keys). Else, how would one understand how to write any joins in a query properly? (E.g., pick the right type of join.) There is no way to explain how joins work without visualizing an example of several input tables and a results table from a join-query...and that is certainly the operational/implementation aspects lurking underneath a DSL like SQL.

    I guess what I disagree with is the implication that programming in a DSL somehow alleviates the user from understanding a certain amount of "plumbing" underneath the language. Granted, programming in a DSL helps to raise the level of abstraction, which makes programming a lot easier. But, this in no way means the user can be ignorant of a minimal amount of domain expertise in order to use the DSL.

    I've created many DSLs throughout my career, and almost every single time some manager or project manager gets the wrong idea that the DSL has somehow simplified the act of programming to the point where burger flippers can be hired who are totally ignorant of the domain. This is one of the disadvantages of DSLs. (They view DSLs as an "expense reduction", usually following by out-sourcing and off-shoring...) This always blows up in their face when said burger flippers require too much hand-holding of their DSL "programs" and schedules slip.

    Other than that one quibble, fine article! (And certainly look forward to Whitehorse and other design tools!)
  • Anonymous
    June 11, 2004
    The comment has been removed
  • Anonymous
    June 11, 2004
    Something nice, that I had been doing for last years. Easiest way to implement domain specific language is to use XML as syntatctic base, and build construction over it. When building XML based language you still have to care how easy text can be written by hand and read, as not allways there are stylesheet ready for problem at hand, and users should look at problem description XML as something they understand.
  • Anonymous
    June 11, 2004
    Good idea.

    Going further than that, I find it useful in many cases to make a graphical syntax that works as a front end --- stops you having to see all the gory XML. So you provide your users (users of the DSL, that is) with a graphical tool that spits out the XML at the back.


    Of course, it helps if you have a tool that is good for constructing the graphical syntax and generating the tools that manipulate it.
  • Anonymous
    May 26, 2009
    PingBack from http://castironbakeware.info/story.php?title=alan-cameron-wills-domain-specific-languages-domain-specific