Having spent some time in the VS2005 environment, I can say the following about DSLs:

 

A domain-specific language (DSL) is a language designed to be useful for a specific task in a fixed problem domain, in contrast to a general-purpose language. DSLs are gaining popularity in the field of software engineering to enhance productivity, maintainability, and reusability of software artifacts, and enable expression and validation of concepts at the level of abstraction of the problem domain.

 

Using domain-specific languages, one can build customized modeling tools and essentially define a new modeling language and implement it very simply. For example, a specialized language may be used to describe a user interface, a business process, a database, or the flow of information, and then used to generate code from those descriptions.

 

I built a (small) DSL for modeling application integration scenarios, which is always an issue in the IT business world. First, I defined all of the specific domain model terms used in application integrations scenarios such as XML messages, source destination applications, XSL maps, business units, protocols, business rules, etc. Then I described the designer definitions that make up the visualization tool. Once the meta data was defined in a supplied Visual Studio template, you build the solution and another instance of Visual Studio fires up with your visual designer implemented.

 

You then use the visual designer you just created to draw/model the application integration scenario and when you run this solution, it code generates the solution.

 

Of course, I have left out a lot of detail and it was not easy the first couple of times. I have left out a set of code generators, which take a domain model definition and a designer definition as input, and produce code that implements both of the components as output. The code generators also validate the domain model and designer definition, and raise errors and warnings accordingly. But eventually, you get the hand of it.

 

Think of it this way, DSL is a tool for building tools For example, anyone that has used the Class Designer in Visual Studio is using a DSL outputted visual designer, specifically designed for building classes.

 

The process has been quite the learning experience for me and has proven to be very enlightening. I am an old guy, been writing code for 15 years. Quite frankly, I dont give a hoot about which programming language I use cause I see them all as being the same, some better than others, but still hand crafting code. I dont want to hand craft code anymore every time I get involved in a software development project I a) have done it before and b) oh man, this is going to take 6 months of grinding it out. In other words, its gonna hurt.

 

I see DSLs as a evolution in our software industry to use higher level abstractions in the way of visual designers to so that I can spend time designing the solution and have most of the infrastructure code generated for me, that I otherwise would have to grind it out.

 

If you are interested in more information about DSLs and dont mind reading it from Microsoft, download the DSL Toolkit and have a read of the documents at: Microsoft Domain-Specific Language (DSL) Tools

Jochen Seemann presented a session on Visual Studio for Software Architects Future Directions in Modeling Tools to about 2000 people at PDC today.  This presentation covered topics of Domain Specific Languages (DSL), Software Factories and Visual Languages.  All of which I am interested in for advancing the industrialization of software.

 

Jochen put into context what a DSL meant by comparing it to an electronics circuit diagram.  In the electronics domain, this circuit diagram has specific meaning, but outside of that domain, it has no meaning whatsoever.  Hence the term, domain specific.  Continuing with the circuit diagram analogy, the language that is used, such as resistors, capacitors, transistors, etc. is specific to that domain.  Hence the term DSL.

 

He also compared DSL to UML where his view was that UML is a broad language for Object Oriented software engineering.  Sure you can customize UML to a large degree, but the problem is trying to use UML to describe something specific enough for a particular domain.  For example, he used the analogy of using use cases (text based) to describe the layout of the auditorium we were in and giving a 50 page use case document to construction workers to build the auditorium.  Using natural language (i.e. English) has a major problem with semantics.  That is, every person could read the use cases, including the construction workers, to build the auditorium and come up with different meaning as to what the words meant and therefore a different auditorium build out.  Hence the problem of using a generalized (read: unified) tool to describe something very (domain) specific.  Of course, no construction worker is going to read a 50 page use case document, they are looking for a blueprint that visualizes specifically what the auditorium is going to look like as the building blueprint is really a domain specific language and is actually a visual language since the blueprint is likely a CAD drawing.

 

This is where DSL comes in. DSL is customizing modeling to the extreme.  Jochen walked through a demo of building a DSL Visual Designer in Visual Studio, which basically consist of three steps.  First you define the domain model, second you define the notation for that model and third map the visualization of the domain model via notation elements.  All of which goes into a large XML schema file.

 

It is an incredibly powerful construct as not only does Visual Studio come with a number of (DSL) modeling templates, but the ability to add third party partner ISV templates and your own templates that all run on the same platform. This makes the interchangeability and reusability with a library of visual designers a reality.  Something that the software industry has been waiting for a long time.

 

Further the ability to link different model aspects and viewpoints means that the ability to code generate complete solutions a reality.  If you are interested in advancing the industrialization of software, I can only suggest that you have a real close look at Microsofts modeling strategy and download the latest DSL tools with the new release available tomorrow. 

I am going to leave the sorry state of our software industry behind as I think it is fairly obvious by now that we are in need of some industrialization.  The type of industrialization I am talking about is similar to what happened to the engineering design and manufacturing world in 1982 when a company called Autodesk introduced a Computer Assisted Design (CAD) tool called AutoCAD.

 

AutoCAD revolutionized and industrialized the engineering design community, not only with its full-fidelity drawing tool, but also with its universal file format called Drawing eXchange Format (DXF).  This meant other drawing tools and devices like Computer Aided Manufacturing (CAM) machines could read the DXF and render itself on a computer screen or produce a physical part output.

 

AutoCADs revolution also came in the way of computer automation.  Look at what it did for building architects.  Aside from easily sharing blueprints electronically, it introduced standards in the way the blueprints were put together, in a fraction of the time it took to do it by hand.  Now they had reusable symbols and even room constructs where one room can be replicated 100s of times in the blueprint to produce a skyscraper in a matter of hours instead of months.  Revolutionary indeed!

 

What our software industry needs is a way of describing software size and complexity in the form of an architectural drawing or blueprint.  Lets take a traditional building blueprint for example.  Almost anyone, without any training, can differentiate between an architectural blueprint of their 3 bedroom bungalow compared to the Empire State Building. 

 

However, we as software developers have nothing like this or so it seems.  Some may say that this is what IBM/Rational Rose does with UML or Visual Studio.NET (2005) does with its Domain Specific Language.  However, it still requires highly skilled designers and programmers to work with these models and they seem to be quite far away from a full-fidelity modeling/drawing tool like AutoCAD.

 

In my next post, I will discuss a full-fidelity modeling tool called BRIDGEWERX in which a Business Analyst can use a drawing tool to completely describe application integration scenarios. Better yet, since it produces a full fidelity drawing, like AutoCAD for example, the XML output can be used to code generate the solution in minutes compared to months of manual labor programming time.