oftware Factories are one of today's new buzzwords in IT. 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 including Visual Studio 2005 Team System, the Guidance Automation Toolkit, and the DSL Tools. This article discusses domain-specific languages, one of the pillars of Software Factories. We'll try to answer such questions as: 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?
This article starts 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, guiding you through this new technology using a real-life example of a domain-specific language that models service contracts in a service-oriented world to aid in building distributed solutions.
When we take a close and objective look at the industry we are working in, we cannot help but conclude that our software industry doesn't do a very good job compared to most other industriesespecially those with a long history of engineering.
The way we are building software today often leads to projects running over budget, shipping products of poor quality, and overall to unsatisfied consumers. So, it could be argued that it's 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, which 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 it becomes increasingly 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 these are valid within their own specific domain. Think of a Software Factory as a product line in a real factory tailored to assemble a specific type of product, such as a car.
Keep in mind that the Software Factory will not deliver all pieces of the puzzleyou'll still need custom codebut the intention is that Software Factories will both speed up development and improve long-term quality dramatically.
Before we can optimize our working environment 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 of. Think of artifacts as individual parts in our software, such as items in 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, such as A Software Factory Approach to HL7 Version 3 Solutions, or Web service Software Factory have become available. We have to see how they evolve to know whether Software Factories will meet the expectations of the future.
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). You can use this toolkit to create guidance packages that you can load into Visual Studio. A guidance package in Visual Studio 2005 is an integrated set of reusable scripts, patterns, and code snippets. GATs automate repetitive and often boring activities, delivering features such as wizards, artifact generation, and context-aware guidance that help developers work in the Software Factory. The ultimate goal of the GAT is to increase software development process productivity and eliminate rote and menial tasks as much as possible by making guidance and automation available in Visual Studio.
|Figure 1. The Software Factories Ecosystem. The figure shows tools and concepts grouped to form a Software Factories ecosystem.|
The last piece in the Software Factory tools puzzle is Microsoft's 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 artifacts 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. Together the guidance package and the domain-specific language are loaded into the Visual Studio Team System environment, forming the actual Software Factory. Of course this is today's state and the entire tooling story may change with upcoming releases of Visual Studio.
We will focus on domain-specific languages for the rest of this article.