Introducing Domain Specific Languages

One of today’s new buzzwords in IT is Software Factories. This Microsoft initiative is likely to change the way that developers build software in the near future. The Software Factories initiative and vision doesn’t stand on its own, however. It’s initially supported by a set of new tools like Visual Studio 2005 Team System, the Guidance Automation Toolkit, and the DSL Tools. In this article, we will discuss Domain Specific Languages as they are one of the pillars of Software Factories. What is their role in Software Factories? How can they help you develop software? Is this just more hype or will Domain Specific Languages really change the way we build software in the not too far future? Let’s find out on the next pages.

This article will start with a brief discussion of the Microsoft Software Factories initiative together with the first wave of accompanying products. We will discuss the role that these individual products play in the Software Factories initiative and show you how they relate to each other. We will use this knowledge as a context for positioning Domain Specific Languages and the Microsoft DSL Tools. We will guide you through this new technology by using a real-life example of a Domain Specific Language that we can use to model services contracts in a service-oriented world when building distributed solutions.

Software Factories

When we have a close and objective look at the industry we are working in, we cannot but conclude that our software industry doesn’t do a very good job compared to most other industries-especially those with a long history of engineering.

Overview

The way we are building software today often leads to projects running out of budget, shipping products of poor quality and therefore leads to overall unsatisfied consumers. So, it could be argued that its time for the software industry to grow up. This is exactly where the Microsoft Software Factories initiative comes in.

The theory behind Software Factories is discussed in the book called Software Factories [1]. It describes how the software industry can change the way we are working, how to build software by assembling reusable components, how to move from craftsmanship to industrialization and therefore how to increase the capacity and performance of the software industry as a whole. All of this sounds great but what does this mean for us as architects and developers?

Let’s have a look how we can translate the theory behind Software Factories to a real life scenario. The basic idea is that the “general purpose” development environment (in the .NET world this usually is Visual Studio) will be customized by the architects and developers in a company. This environment will gradually be tuned for their specific business. The development environment (Visual Studio) provides the mechanism to facilitate the customization. The development team provides the effort that is necessary to customize it. Over time, developers will find it easier to do their development tasks because more of it becomes automated. In the end, it’s the optimized development environment that we call a Software Factory.

Normally, the Software Factory is optimized for a specific type of software. This means the development environment provides developers with components, patterns, architectural rules, and semi-finished products that they can use to compose software. All of them are valid within their own specific domain. Think of a Software Factory as a product line in a real factory that is tailored for assembling a specific type of product, like a car.

Keep in mind that the Software Factory will not deliver all pieces of the puzzle-custom code is still needed-but it is the intention that Software Factories speed up development and hopefully improves long-term quality dramatically.

Before we can optimize the environment we are working in we need to have a good understanding of the type of software we are building. That means we have to identify the so-called artifacts that our software can be composed off. Think of artifacts as individual parts in our software that can be various items in the range of configuration files, source code, and even frameworks. This list of artifacts is like a recipe for a meal and is called the Software Factory Schema. This Software Factory Schema also describes the relations between the different products in the list so we know how to use them together to actually cook the meal. The Software Factory Schema only sums up and describes the artifacts; the real implementations of the products, mentioned in the Software Factory Schema, form the Software Factory Template. Think of this as a set of patterns, frameworks, templates, guidelines, etc. In the end, it’s the Software Factory Template that we use to configure a tool like Visual Studio 2005 Team System to transform it into an optimized environment for building a specific product family.

At this moment we are just in the very early stages of Software Factories. Very slowly, some early examples ([2], [3]) become available. We have to see how they evolve and if Software Factories will meet the expectations of the future.

Accompanying Tools

Now that you know that the Visual Studio environment acts as the placeholder for all Software Factory components, let’s look at some other complementary products to complete the big picture. Remember, Visual Studio provides the customization mechanism that will be used by the tools we will discuss now.

Another totally new tool is the Guidance Automation Toolkit (GAT, [4]). You can use this toolkit create guidance packages that you can load into Visual Studio. A guidance package is an integrated set of reusable scripts, patterns, and code snippets that you can use in Visual Studio 2005. By using GAT we can automate repetitive and often boring activities. We can deliver things like wizards, artifact generation and context-aware guidance that help developers work in the Software Factory. The ultimate goal of GAT is to increase the productivity of our software development process and eliminate the rote and menial tasks as much as possible by making guidance and automation available in Visual Studio.

The last piece in the Software Factory tools puzzle is the Microsoft DSL Tools. This toolkit makes it possible to create Domain Specific Languages that we can use in our Software Factory. As you will see in the remainder of this article, Domain Specific Languages and the DSL Tools are yet another way to automate and improve the software development process for certain aspects of a system.

Software Factories Ecosystem

Before we continue with Domain Specific Languages in some more detail, let’s summarize the Software Factories ecosystem. Figure 1 displays the individual tools and concepts grouped together that we call the Software Factories ecosystem. The Software Factory Schema describes the artifacts that are relevant for a specific problem domain. These artifacts, in turn, are implemented as frameworks, source code, configuration files, and Domain Specific Languages. The frameworks, code, and configuration files are used in the Guidance Automation Toolkit to create a guidance package; the Domain Specific Languages are implemented with the DSL Tools. It’s the guidance package and the Domain Specific Language together and loaded in the Visual Studio Team System environment that form the actual Software Factory. Of course this is today’s state and the entire story about tooling may change with upcoming releases of Visual Studio.

By: Christian Weyer

Christian Weyer is co-founder of thinktecture (http://www.thinktecture.com/), a company that helps software architects and developers to build projects with .NET and distributed applications technologies. He is a recognized XML, Web services, and service-orientation expert. As a Microsoft MVP for Solution Architecture and one of the few independent Microsoft Regional Directors, he has made a name for himself in the developers and architects community. He has worked for many years with Microsoft technologies like COM/DCOM, COM+ and .NET. Christian has spoken at many well-known developer conferences and forums worldwide and is a published author, editor, and writer of numerous articles for various German and international technical magazines. Visit his Weblog at http://weblogs.asp.net/cweyer/ to find out more about Web services and service-oriented integration and programming, not just on the .NET platform.

Website: http://www.thinktecture.com/

Weblog: http://weblogs.asp.net/cweyer/

christian.weyer@thinktecture.com

By: Edward Bakker

Edward is working as a software architect for LogicaCMG, a major international force in IT services and wireless telecoms. You can contact him by sending a mail to Edward.Bakker@logicacmg.com or visit his weblog at http://www.edwardbakker.nl.

Edward.Bakker@logicacmg.com