I have heard that people think that Domain Specific Languages (DSL) is a very abstract concept. Because of the abstraction, a lot of people are nervous about domian specific languages. I can see how people get that impression. In order to have a DSL, someone uses abstract concepts to design the language. The goal of a DSL is actually quite the opposite. The goal of domain languages is to move away from the solution domain details and embrace the problem domain. What I mean is that instead of talking in abstract concepts like Classes and Components, we start using the domain concepts (Car, Truck, Node, Project, etc) when developing software. Describing aspects of a system in concrete terms makes it easier to understand the system.

By no means is this concept new. If you look at the history of software engineering you will see steady progress of moving away from the abstract concepts to a more logical concept. First, we started with machine code. I would argue that the machine language is a very abstract language to a human, while the most concrete language to a computer. We then move to assembly language. Assembly language made developing a little more concrete to us humans by representing op codes (numbers) as names, but assembly was not understandable to a computer. Therefore, the assembly language program had to be assembled to machine language so that the computer could understand. The assembled program became the artifact. Next came structured language and functional languages. At first people said that these languages could never produce code as well as programs written by hand in assembly. Over time, this statement was proven to be incorrect, and the object code became the artifact. Next came concepts like object oriented programming and aspect programming. Over and over the process repeats. We move to a logical reprsentation of the machine code. Each iteration makes that programming language more abstract to the computer but easier to understand for us humans. Domain specific languages simply repeat the cycle. Trying to make it easier to understand the concepts needed to develop software.

The previous statements are all fine and good, but is there any practical use? Yes, there are a number of examples of domain languages out in the world. If you look at NetBeans you will see a number of examples. The one that everyone will be most familar with is the form editor. It is a language that is designed specifically for designing user interfaces. As such, it is very intuitive to use and very powerful. The reason it is very intuitive is because it uses the concepts of a user interface to describe the user interface. It does not use general programming concepts of classes and components to describe a user interface. The form editor uses buttons, panels, labels, and a host of user interface controls to describe a user interface. To build the same user interface in code is very possible, but it is a lot of work. It takes a lot of work to get the control in the correct locations, not to mention how to handle resizing windows. However, when you use the form editor, this becomes a farily trivial task. Especially a form editor like Matisse. Note that in the form editor a lot of code still needs to be written. It is still up to the developer to write the user interface logic. The fact that the form editor leave a lot of code to be written by hand is a very improtant thing to note. A domain specific language does not mean that there will no longer be a need for a good source code editor. The goal of a domain specific language is to start generating more code not to do away with writing code.

Another example is the orchrastration editor. The orchrastration editor is a graphical editor that is designed to write BPEL documents. The orchrastration editor is an example of a domain specific language that represents not structural information but instead behavioral information. Even thougth the orchrastration editor represents behavioral information, it is still easy to use. It is easy to use because it uses the concepts of the BPEL domain to describe the behavior that is to be executed.

In my previous examples of domain specific languages, I have used graphical languages. Domain specifc languages are not limited to graphical languages. Indeed, there are may example of textual domain specfic languages. BPEL is a good example of a domain specific language that is a text based language instead of being a graphical language.

I can already hear the arguments that BPEL documents can easily be represented in a general purpose language like UML. That is a very true statement. The UML Activity diagram would be a very good fit to represent BPEL documents. As a matter of fact, I have made that argument myself many times. Also, a page flow diagram can easily be represented as by a state diagram. The point is that the higher the level of the language, the more intuitive the language. Now, I am not saying that there is no need for general pupose modeling languages. I believe that general pupose modeling languages like UML can be used to represent domain specific langauges, but that is a topic for latter discussion.

So, where does that leave us? Are domian specific languages by its nature abstract? Well, the designer of a domain specific language has to think about how to design the language. Usally the designing of a language will take you into abstraction. I would argue that the level of abstraction required to design a language is no more than it would take to build the concepts into a modern object oriented application. For example, to write an accounting applicaiton you would still have to develop the concepts of the accounting domain into your system. You would instead use the accounting terminology as an abstract concept, and the object oriented concepts as the concrete concepts. With domain specific languages, the domain concepts become the concrete concepts. Therefore, putting the focus on the problem domain insteading of focusing on the domian of the programming language.

I believe that UML is a low level modeling language. UML is great for describing the structure of an application. The sequence diagram and collaboration diagram is also very good at describing interactions between objects. However, in order for the development industry to meet the growing demands for our services, we need to describe applications using higher constructs than classes, interfaces and objects. For example, we need modeling languages that have constructs that describe a web service and an EJB. Once we have the higher constructs defined, the developer can drop a web service onto the diagram, plug in a few ports and BANG the web service has been created.

The previous paragraph sounds a lot like the Software Factories approach. The Software Factories approach creates a new language for each domain. The new domain specific language (DSL) is then used to describe an application. The advantage of the domain specific language approach is that you are no longer using classes, interfaces and objects to describe applications, you are now manipulating constructs that are custom fit for the specific domain that is being developed. As you have probably guessed the software factories approach will require the birth of a number of new languages. Each company that employs developers will also have to employ language specialists to develop and maintain languages needed for their specific domain.

In my opinion, I believe that the Software Factories approach has a lot of good points and a lot of bad points. One area that I disagree with is the break away from UML. I think that the higher constructs can be accomplished by either extending the UML meta model or by using the profile extension mechanism. In order to add the higher level constructs, the profile mechanism will need to be extended. One of the extensions that needs to be made to the profile mechanism is to allow a profile author to specify an alternative representation for a model element. Once "webservice" stereotype is applied to a component, the user will not see a component notation that has the stereotype of a "webservice." The model element instead will be represented as a web service. This concept is not to far fetched. Many UML tools already support the Robustness diagram notation. The Robustness model elements are UML classes that have a stereotype of "boundary," "controller," or "entity." The trick is that the representation of classes with the Robustness stereotypes is not the same as the representation of a class without the stereotype.

The way I see it, most users of modeling tools do not care about how the model element is represented internally. All they care about is how clear the information is represented, and how quickly they can get their work done. By still using an extension mechanism, the burden is moved from the language designers to the tool providers. The stereotypes that have their own representations can be added to a palette. A tool that adds the stereotypes to their palette can also allow the user to quickly drop model elements with the stereotype. The code generation mechanism (or model transformations mechanism) can handle the issues of transforming the classes with the stereotype to source code. Tools can do what ever it takes to limit the reasons why the user has to physically apply stereotypes to a model element.

Lets say that we have written DSLs for the EJB and web service domains. Now we need an EJB that is also a web service. With the DSL approach, we have to create a new language that merges the two languages which means the developer now has to wait until the language expert can create the new language. I would rather have the ability to overlay the concept of a web service onto my EJB object or vise versa. That way the developer would not have to wait for a new language to be created. Then, I could also view my object as a web service or an EJB depending on what the diagram is trying to communicate.

A domain specific language is extremely effectively for its designed use. However, as soon as you start to go beyond the bounds of the languages concepts the language starts to slow you down. Because of the limitations of the language, the developer will either fight the language, switch languages, or again go back to the language developer. In any case, the rate of development will be drastically hindered.

I believe that a shift in our thinking needs to be made. It is time for modeling languages to advance from low level languages to more abstract modeling languages. UML should become to modeling languages what assembly language became to modern programming languages. When it became too complex and too painful to develop using assembly languages, the industry started to develop more advanced languages. The higher level language would still compile down to the assembly language. For a long time the higher languages allowed developers to embed assembly language instructions into an application. More recently, programming languages such as Java and C# no longer allow the developers to embed assembly language instructions, and they no longer compile down to assembly language. The same pattern has to occur in the modeling world as well.

We need to build on top of UML to produce higher level modeling languages. We still need to be able to embed some UML constructs into the higher level modeling languages. The meta data of the higher level languages need to be built on top of the UML meta model, but few users of the modeling tools will know or care about how model information is stored. Just like few developers care what assembly instructions are generated when they compile their source files.

There are two reason why we should build on top of UML. First, UML is already accepted as the modeling standard. Second, UML already has the a powerful extension mechanism. The extension mechanism needs to be enhanced, but is still a very good mechanism.

There has been a dialog between Grady Booch and Alan Cameron Wills on the differences between using UML and DSL's (Domain Specific Langauge). After reading the two blogs, I had a lot of thoughts about the conversation, so I thought that I would share some of them here.

Alan asserts that with DSL you have a model that is designed around the domain that you are designing. In the example given by Alan, he states that when you retrieve the type from a DSL model, you will get the domain specific type name. In UML when you retrieve the type you get the abstract model element type, for example an UML Class. Grady counters the argument by stating that you get is a stereotype of with the domain specific type.

Both arguments are correct. When you read a UML model and you ask a model element for its type, you do receive a UML Class. Then you are able to receive the domain specific type by querying for its stereotypes. Now that I have stated how each argument is correct, I do not understand the point that Alan is trying to make with his argument. In both cases the model element information will have to be translated into some other form to actually produce source code. Whether or not the translation tool has to check for a stereotype or not, does not affect the user of the tool. Alan can be trying to make the argument that it is bad to require the user to add the stereotype to the class in the first place. I see this also as a tool issue. UML does not restrict tool venders from creating new representations for the UML model elements. An example is the Robustness diagram.

Most UML tools have some way to support the Robustness diagram. The model elements on the robustness diagram are specializations of a UML class. Since most UML tools provide special visualizations for Robustness diagram, the user is not required to add the Robustness stereotypes to the UML class.

While on the topic of stereotypes, Alan also states that "You have to understand all of UML (stereotypes,etc) before you can create your language on top of it". I personally can not imagine a way that you could possibly not have a complete understanding of a domain when you go to write a language. Even if you are wanting to write a new DSL you would have to be very knowledgeable about modeling languages. Basically this is not an area for the novice, even if you are writing a domain specific language. So, basically the choice is whether or not to build upon a system that has been used by a number of people, or whether you want to start from scratch.

Alan also makes a point that UML may not be the best choice to represents all domains, such as a visual GUI editor. I tend to agree with him on this point. However, I would also state that I think that the authors of MDA would also agree. OMG has spent a lot of effort designing modeling languages for other domains like data warehouse applications. In the book MDA Explained: The Model Driven Architecture -- Practice and Promise the authors talk about other model types. The sample application that is discussed in the book uses ER diagrams. I am not saying that I do not have any problems or concerns with MDA, for example in MDA Explained the ER diagrams are generated from a Class diagram which I do not see as a realistic approach.  In reality the developer will most likely be given the ER diagram from a database management group.  It will be the developers job to retrieve the information from an existing database instead of designing a database.