RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Introducing Domain-specific Languages : Page 2

Microsoft Software Factories, part of Visual Studio 2005 Team System, is a set of tools, models, software development methods, and practices that will help you use the VSTS environment to develop domain-specific languages (DSLs).

Domain-specific Languages
A domain-specific language is a custom language that targets a small problem domain. It describes the problem at a higher abstraction level than general-purpose languages do, providing another view of the same problem.

That's it, nothing more, nothing less. Let us explain a little why we think this is a proper definition of a Domain-specific Language. First of all, a domain-specific language can only be used to describe a specific problem. That's a big difference compared to a general purpose language such as C#, which can describe all sorts of problems. It is the limited focus of a domain-specific language that makes it possible to describe the problem in abstractions that make sense to the problem. Because of these abstractions, the problem is easier to understand for a larger group of people. The underlying problem, however, remains just the same.

But wait, we haven't heard the words "Microsoft" or "DSL Tools" in this definition, right? That's correct. Domain-specific languages don't depend on any Microsoft tooling. In fact, domain-specific languages have existed for quite some time now and aren't valid only in the Software Factories context. Technologies such as SQL, XSD, and even Windows Forms provide a range of examples of domain-specific languages with which most of us are quite familiar. With that said, note that DSLs aren't always graphical (see Martin Fowler's article, Language Workbenches: The Killer-App for Domain-specific Languages?).

But the availability of the DSL Tools makes ot relatively easy for a developer or architect to build a domain-specific language. DSL Tools also provide a way to add a graphical representation and an appropriate designer to your domain-specific language. All of this is great—but those aren't the core features of a domain-specific language; however, they are the features that will probably increase the adoption of domain-specific languages and give it a boost. The presence of the DSL Tools and the primary role that domain-specific languages play in the Microsoft Software Factories initiative makes domain-specific languages something new to hype.

With this understanding of the concept of domain-specific languages, let's look at some of their obvious advantages. In other words, why should we as a developer or architect use DSLs for design and development?

First of all, a domain-specific language provides a clear view of the problem domain for which we are writing software (or parts of software). Using a DSL—and especially one that comes with a graphical designer—forces us to focus our attention on the important concepts in the domain. Only the concepts that exist within the domain-specific language are valid candidates for discussion during the design phase of our software. This doesn't necessarily mean you'd use only one domain-specific language to build a software component. It's possible to use several domain-specific languages that together cover the whole problem domain. Also, a domain-specific language helps us create valid relations between concepts. Relations between concepts that don't make sense are simply not allowed in the language and/or designer. This limited set of concepts and possible relations stimulates standardization in software component design.

Another related advantage of a domain-specific language lies in the higher level of abstraction. Design sessions often end up in long discussions about nitty gritty details that are definitely not important in the design phase of the project, at least not at early stages. A domain-specific language not only helps us focus on a limited set of concepts, the concepts are also described at a higher abstraction level. As you will see later in this article, it is much easier to talk about service contracts in terms of ServiceInterface and ServiceOperations than to use the WSDL specification for this same discussion. In addition, it is much easier to share software component designs crafted in a domain-specific language designer between team members than to share pictures you took of a design you created on a whiteboard.

Last but not least, fully adopting domain-specific languages in our development process will increases productivity considerably, not only because of design-time savings, but also because of the time we can save by generating artifacts such as C# source code. A very interesting side effect of code generation is that it provides a quality boost and increase in standardization. This, of course should result in fewer bugs, code that is easier to maintain. Developers no longer have to code the boring stuff but can concentrate on the much more interesting parts. Be honest—isn't that what we want?

All that Glistens Is Not Gold
Because domain-specific languages related to .NET and Visual Studio are in their infancy, it is likely that the majority of us don't have any experience with building and using domain-specific languages.

The Microsoft DSL Tools are very new and therefore probably immature. They might miss some important features; therefore, to be successful in this domain-specific language area it's not enough to just install the tools and go for it. We have to think about consequences and issues very carefully and make sure we fully integrate Domain-specific Languages into our development process.

Pending Discrepancies
Assume we build a complete Domain-specific Language with the Microsoft DSL Tools. The architect and developers use the domain-specific language to create fabulous models within Visual Studio 2005 and they can even generate some useful artifacts to speed up the development. Now what? How do we treat the model compared to the generated artifacts? Which one is leading? How do we keep them in sync? These are all valid questions that need to be answered.

First of all, which one is leading: the model or the artifacts that get generated? This one is easy—we would argue the model. But why? The primary task of the domain-specific language is to describe the problem domain in a higher level of abstraction. A domain-specific language helps people better understand the concepts and the possible relations between them that exists in a specific problem domain. The model is the end result and acts as the input for the artifact generation. Although it might be tempting, we would not recommend manipulating the generated artifacts by hand without changing the model first.

Now that we are dealing with a domain-specific language—and thus with a higher level of abstraction—we must learn to treat the model and not the code as the primary source. This might be a mental switch, especially for developers, and therefore we must try to keep the relation between the model and generated artifacts as tight as possible.

Seeking Cadence
This leads us to another important issue: how do we keep the model and artifacts in sync? One of the simplest approaches would be to periodically regenerate the artifacts. You could even use an automatic build procedure. All manual changes that might have been made in the artifacts simply get overridden. Although this is effective, it's definitely not the most elegant solution. First, this approach might not work for all types of artifacts. In the case of a C# file generated from the domain-specific language, we can use the partial class technique to separate the generated code from any custom code we want to add later during development. By doing this we can make changes in the model and still regenerate the artifacts without losing any manual changes. It becomes a little more difficult when we are dealing with a Word document that is one of the domain-specific language artifacts.

Another and maybe better approach is to implement round-tripping for a domain-specific language. This assures a tight coupling between the models we create and the artifacts that are generated out of the model. This approach solves the possibility of the models and artifacts getting out of sync. Round-tripping isn't supported out of the box in the initial release of the DSL Tools; however, you can (probably) implement it by writing custom code. Features such as round-tripping are tempting and many developers will start building these kinds of features into their domain-specific language right away. However, we think it is better not to focus too much on technical features and/or limitations of the current release of the DSL Tools. The DSL Tools will evolve over time; therefore we think it is more important to focus on understanding domain-specific languages integrating them in your development process.

To summarize, we believe that domain-specific languages and the models based on them must become a first class citizen in your design and development process. At the end of the day, you want to make sure that the models still reflect the actual software. You don't want your model to be outdated documentation for your sources. If that is what you want, you can stick with UML, frankly. The model should lead; you don't want to make manual changes in the generated code if round-tripping is not supported so you must put the models under source control just like the rest of your code. All these procedures and guidelines can, of course, be part of your overall Software Factory.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date