Contents
Introduction
Software Factories in Visual Studio 2005 promise to significantly raise the level of abstraction by which a developer, a team, a department and even an enterprise can conduct the act of building custom software (or even a commercial software), something the studies (see the Standish Group’s Work) show to be a complete disaster since the inception of the very concept. I believe this raising in abstraction is as significant an advance in software engineering as ‘object-oriented’ practices which were available in development environments well over a decade ago.
The specific means by which this is accomplished includes a Domain Model Wizard, a Graphical Designer for refinements, XML Metadata, Code Generation, and a framework for defining template-based artifacts (to name a few items). This article is not a tutorial on Microsoft’s tools related to software factories, it simply illustrates the transition from ‘Factory’ or Domain Specific Language(DSL), to a version of that DSL to a running instance which is then customized slightly.
Time will tell if this will catch on at the level I predict, but we now have the released version of Visual Studio 2005 and also (just recently) have CTP versions of the Software Factory core components (the DSL designer and the Guidance Automation Toolkit) available for use that function with the RTM of Visual Studio 2005(we had to wait a bit from the RTM to receive this as version that only worked with beta 2 were all we had due to dependencies on other technologies not yet ready and not in the RTM of VS 2005).
In this article I will discuss the importance of software factories, a proposal for a development process (Agile) that fits like a glove with factories, and examples of people who have simulated some of what factories will buy us today, especially tools like Iron Speed Designer.
Top 
Software Factories
Figure 1: A high level process overview for creating factories (from Microsoft’s Walkthrough 1 in the DSL Tools November CTP)
The above graphic shows a high level overview of the process by which factories are now being constructed (note: This is all subject to change as none of the Software Factory items I will mention have been officially released except in their CTP version. For the latest browse to: http://msdn.microsoft.com/vstudio/teamsystem/workshop/sf/default.aspx [^] . At the time of this writing the latest edition of the DSL tools was the ‘Nov 2005 CTP Release for Visual Studio 2005’ This article will not discuss other factory related technologies such as the Guidance Automation Toolkit(GAT), although the GAT is critical as a compliment to the Software Factory vision.
One of the main points I’d like to make is that many vendors today provide services that approximate the vision of Software Factories. The goal is to minimize tedious and repetitive (and therefore error prone) aspects of the software development process. I will use the tool ‘Iron Speed’ as my example as their goal is the same as what I just described, and they are a very mature product that is in production now. The vision of software factories will not be realized for another six to twelve months (author’s opinion). Using tools like Iron Speed’s designer will give you a fantastic glimpse into much of what factories aim to achieve with one very important difference: Iron Speed is a ‘horizontal’ application, with applicability across almost any domain, where Factories aim to provide very Domain Specific abstraction, even to a department level. This means that the developers working with a Domain Specific Language will be abstracted from the burden of coding what is perhaps the very essence of a Domain defines itself (often built into Frameworks today), where users of Iron Speed, while greatly enhanced in their speed to code, will need to add manually all Domain Specific behaviors.
A good example would be the Insurance industry. Let’s assume that Insurance Company A has a large set of rules related to their policies. These policies must only be issues to US Citizens with no Felony convictions, and a long list of conditions that would make them ineligible for a policy. In a factory this may be represented by a simple rectangle called ‘PolicyHolder’ (much like a UML Class however far more powerful in its abilities, as a UML Class is concerned mostly with the semantics of the object-oriented domain. A PolicyHolder in a Factory when participating in a design model, can immediately recognize if it is involved in a semantically invalid (at the Domain level) relationship where a UML Class would have no way (other then some vendors who have implemented extensibility mechanisms and the ambitious efforts of the Object Management Group (OMG)’s MDA initiative. It is this author (and Microsoft’s) opinion that rather then trying to ‘make the UML shoe fit’ it was better to start with a clean slate and create an optimized environment for defining these Domain specific elements in a new notational framework (there is much debate about this that still rages strong today with powerful industry luminaries such as Grady Booch coming out against this decision). I believe time will show this to be the right move as I am unaware of any vendor that is close to challenging Microsoft’s approach using a UML based Domain Specific Language approach with the OMG MDA. If you are please contact me and provide me the vendor’s contact information if possible.
In this article we will leverage an existing software factory from Microsoft’s ‘End to End’ solution (recently released) and also build the equivalent in Iron Speed to compare the two approaches not to show that one is better then the other but to illustrate how they serve very different purposes. Software Factories are not the same as Application Generators, Frameworks, Code Generators, and the like. Instead they require a new way of thinking about software and the applicability of the ‘right tool for the right job’ and indeed can benefit from the inclusion and leveraging of existing work that has been done as this example will show.
Let’s take an example of a situation where you are constantly creating wizards. You may create an internal framework to create wizards which would be a logical progression compared to what typically starts as everyone doing whatever they like. We often see, as an ideas mature in an organization, the same patterns emerge (this holds for sub-components and even entire systems). Here is a well establish framework for the evolution of software:
1) Chaos: All developers are free to do whatever they like to implement a solutions and there is wide inconsistency in how the same solution is solved, and there is a rampant lack of code reuse. This is unfortunately far more prevalent today then it should be.
2) Patterns: Patterns emerge and we expect developers to ‘do the right thing’ and follow those patterns (which may be documented in a ‘standards document’ but no usable code is available).
3) Frameworks: In the steps above, lots of repetition occurs and there is the change a developer could unwittingly introduce change into a process you are trying to standardize. Therefore a Framework can be built (as we have seen in the ASP.NET 2.0 environment where a ‘Wizard’ component now exists and is part of ASP.NET 2.0). This includes actual code, screens, metadata and potentially lots of additional elements which developers can call upon when creating Wizards (for example). Time is saved, quality improves, etc. as the Framework code is heavily tested and a bug fix can impact all that have used it when they install the new version. This is very useful when we get to the next level.
4) Languages: The last stage of evolution is where the idea is so entrenched that it becomes a language of its own. Imagine if we had the power to create our own languages that we could use to extend C# or other .NET languages. That is exactly what we are doing when we create a DSL model. We are create a ‘Domain Specific Language’ in this example, the language us the Wizard capability. What’s more, instead of being limited to describing a Framework API, we can now use on the computer a visual notation to represent the elements of our language. We can also leverage the work we did in creating a framework when creating our language.
Here is what a DSL ‘Factory’ model looks like (this is for ‘Wizards’):
Figure 2: Microsoft’s ‘End to End’ example DSL using Wizards as the Domain
You will notice this is an incredibly abstract or ‘meta’ way to describe the problem of creating a Wizard, but it does so effectively. You can also notice that we are leveraging the Framework efforts that were created to help our organization previously. This is contained in the Fabrikam.Frameworks.UIProcess section of the solution. You will see how this manifests itself in the following section.
Now I would like to show you how this appears when executed. Simply running this DSL will launch another instance of Visual Studio and allows the ‘Domain Specific Language’ user to use the model above and also to write code as necessary. Here is the view when I run this solution:
NOTE: I have extended this from what ships from Microsoft by adding a new form called the ‘FailureToAcceptTerms’ page. Also the green arrows are manually set as the ‘’True’ or ‘Success’ paths in the workflow. It would be fairly easy to create in our factory the concept of a ‘success’ flow from a decision and automatically set these color properties. However for this example it is done manually as a simply convention.
To create this customization was fairly easy. I created a WizardPage from the left toolbar (and you can see how our DSL model elements are translated to toolbar elements for the consumer using the DSL and the Visual nature of this particular example) and I also added a Condition element, as well as the transitions. I wanted the code to allow someone to continue if they did not hit the ‘Accept Terms’ checkbox and see an error message instead of nothing happening when they hit ‘Next’ (the default behavior). This was a problem for my extension. There was custom code written that would not allow someone to continue if that checkbox was not accepted. My first step was to comment that out. Here is the original code:
using System;
using System.Collections.Generic;
using System.Text;
using System.ComponentModel;
/*
* The code in this file is not generated from the model.
* If you change the model, you must keep this file up to date.
*
* Each partial class initialises one or more delegates, implementing custom behavior.
*
*/
namespace Fabrikam.DSL.WizardUIP.UIPSample
{
///
/// Customization to prevent progress to Next page until Customer Accepts Terms.
///
public partial class FoundRoom
{
public override void InitializeDelegates()
{
base.InitializeDelegates();
//Prevent Next transition until Customer Accepts Terms is checked.
this.BeforeNextTransition = delegate(object o, CancelEventArgs e) {
// Disable the check for thi as now it is a wizard Step
if (!(bool)this.GetFieldValue("AcceptTerms")) e.Cancel = true;
};
}
}
}
This code is located in the ‘FoundRoom’ section in the Custom directory as shown below:
I’m getting a little ahead of myself. Let’s show what this code does by default when I run it:
The first page of the DSL driven Wizard.
Page 2 of the Wizard Example (notice I added ‘Test by Damon Carr’ to the bottom right. I did this in the DSL not in this Wizard Example’s use of the DSL by modifying the Framework. We will modify this further shortly.
Page 3 of the Wizard Example – Here I had a problem as the code previously shown was stopping my newly added additions from being added. Clicking next simply had no effect. To get to my new screen I needed to eliminate that code.
Here is the code I simply commented out and rebuilt the solution:
//Prevent Next transition until Customer Accepts Terms is checked.
//this.BeforeNextTransition = delegate(object o, CancelEventArgs e) {
// Disable the check for thi as now it is a wizard Step
//if (!(bool)this.GetFieldValue("AcceptTerms")) e.Cancel = true;
//};
This is also a good example of how Factories do not eliminate code, they simply minimize repetitive code and focus it on elements where the DSL does not automate an item (the factory designers could have created a concept called ‘MandatoryBooleanForNext’ but they didn’t. If they had I could of selected that from my control drop down instead of just ‘Boolean’ which would of eliminated the need for the code above at all (it would be automatically generated for me). Keep in mind I have not written one line of code so far.
This is one dilemma of a Language designer. Where do you stop as there are typically many concepts (many more then you may have time to address) that can be added.
Shown below is the screen with the property definition for the ‘Customer Accepts Terms’. A better solution then the one I suggested (MandatoryBooleanForNext) would be to add a property on all fields called ‘Required’ and if empty, we would not be able to ‘move next’.
So now that the code has been commented out we can test the additions I made to the manifestation of a Wizard Microsoft created in their example and I modified. Here is the last screen we were on where I could not move forward:
Sure enough commenting out that code did the trick. When I click the next button here is what I see:
Upon investigation here is what the definition of the field that is shown looks like:
Notice that the text shown above (‘Terms Accept Failure’) on the screen above is not present on this property sheet. The language designers did not provide me with the ability to set a value in the property attributes (note: I challenge all readers to make all the changes I am describing in this article and email me the finished product).
So where did that come from? Easy. I just copied the pattern used to create the previously described custom rule. First I created the new code:
Note the ‘FailureToAcceptTerms.cs’ class. I added that manually and then included the following code:
using System;
using System.Collections.Generic;
using System.Text;
using System.ComponentModel;
/*
* The code in this file is not generated from the model.
* If you change the model, you must keep this file up to date.
*
* Each partial class initialises one or more delegates, implementing custom behavior.
*
*/
namespace Fabrikam.DSL.WizardUIP.UIPSample
{
///
/// Customization to prevent progress to Next page until Customer Accepts Terms.
///
public partial class FalureToAcceptTerms
{
public override void InitializeDelegates()
{
base.InitializeDelegates();
this.SetFieldValue("FailureAcceptTerms", "Terms Accept Failure");
}
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
System.Windows.Forms.MessageBox.Show("User cannot continue as you did not accept terms",
"Failure to Accept Terms");
}
}
}
I also added code so I could show a MessageBox about the reason the user could not continue. This was achieved by overriding the OnLoad event and ensuring I called the base.OnLoad event.
The name must be FalureToAcceptTerms or this code will not work as this is how is ‘hooks it up’ with the screen.
Quite simple.. But that field should really be a ‘Read Only’ field so I will modify it based on something we do have access to:
Note that ‘ReadOnly’ is now set to True (I could of also done this in code above when I set the value, but I prefer a declarative model. Also I should probably add the string into a resource file so this is all localizable.
Indeed now (after I run the ‘Transform All Templates’ command) it looks as I wanted. Here is the rest of the flow assume I HAD chosen that I accept all terms:
When I end the application I receive this popup:
Had I not selected Credit Card I would of seen just the ‘Thank you for your order’ which is consistent with the visualization of this Wizard.
So although this is not the sexiest example it shows a manifestation of how a Language (Visual and Non-Visual) can be created to go to the next level beyond a Framework and then to use that Language.
Let’s make some ‘tweaks’ to the screen, giving it a more modern appearance. I can do this in the original DSL designer. I close the ‘Sample’ DSL usage project.
Here is the original form:
I’d like to make the maximize button go away, and change the color to a white background. In addition I’d like to modernize the interface as much as possible.
I can simply select this and make the property changes so I see the following:
Not the most earth shattering changes but by manipulating these items in the Views section shown below, I was able to make these changes:
It would preferable to expose all of these items to the Language users so they could make similar changes without having to modify the actual language.
It should now be clear how a DSL can be used by a ‘Factory Consumer’ to create a higher level of abstraction then a Framework, while not giving up any capabilities in the process with the ability to ‘go to code’ as required.
Here is another view of the process and components, expanded to include additional elements:
Top
What’s Next for Software Factories and the DSL?
What’s next for the DSL Tools after what we covered here in the November CTP Release? From Stuart Kent’s BLOG (paraphrased by the author) http://blogs.msdn.com/stuart_kent/archive/2005/12/13/503090.aspx [^] we can hope for the following:
1) More documentation should be available
2) The DSL Tools will be integrated with the Visual Studio SDK (a major step)
3) A Replacent of the .dsldmd and .dsldd files with a single .dsl format (very nice!), with it's own editor
4) Hand Editing dsldd files will become a thing of the past!
5) Microsoft will likely also be supporting two more pieces of new notation:
a. Port shapes
b. Swimlanes
6) In addition they will hopefully be able to provide richer and more flexible support for persisting models in XML files.
7) He finishes by saying “Our goal is a release candidate at the end of March”
It’s interesting to me that the current ‘templates’ that the DSLs are driven from are UML driven. When you start a new DSL you choose what template to base the DSL on. Here are the current choices:
I suppose the thought is people are familiar with these types of Diagrams and can then extend them with the rich Factory enhancements that go so far beyond what a standard UML tool can do. So you start in many ways from where a UML tool ends.
For example, if I select ‘Class Diagram’ this is what I see:
Here are the toolbar elements I have:
And here is what the DSL looks like:
This is close to a visualization of the UIML Semantic metamodel (as I suppose we should of anticipated). Running this with no modification should provide us with a UML Class Designer. Let’s see.
Indeed after hitting F5 we see what looks like a typical UML Class Designer (an example was loaded):
However now we can introduce new semantic concepts into our ‘class diagram’ in the DSL designer. For example, if we wanted to create a model element for a Microsoft.NET ‘attribute’ such as ‘Serializable’ and have that be a first class citizen along with properties and methods we could easily do so with the following modification:
As you can see I have added the item DotNetAttribute with a property of ‘Constructor Literals’ which could be a series of parameters for the attribute. In order for this to work I still must hand-edit today (something which is going away) the XML as such:
This is added to the Shape for ModelClass (note: This hand-editing should become a thing of the past once the technology matures a few cycles more. Stuart Kent mentions this above in his BLOG entry on the future of this technology.
<COMPARTMENTMAP>
<COMPARTMENT>
CompanyName.ProjectName.ClassTest.Designer.UMLClassTestDiagram/Shapes/ClassShape/Compartments/DotNetAttributesCompartment
</COMPARTMENT>
<MELCOLLECTIONEXPRESSION>
<ROLEEXPRESSION>
<ROLE>CompanyName.ProjectName.ClassTest.DomainModel.UMLClassTest/ModelClass/DotNetAttributes</ROLE>
</ROLEEXPRESSION>
</MELCOLLECTIONEXPRESSION>
<VALUEEXPRESSION>
<VALUEPROPERTYEXPRESSION>
<VALUEPROPERTY>
CompanyName.ProjectName.ClassTest.DomainModel.UMLClassTest/DotNetAttribute/ConstructorLiteral
</VALUEPROPERTY>
</VALUEPROPERTYEXPRESSION>
</VALUEEXPRESSION>
</COMPARTMENTMAP>
And to have this show up as a first class citizen with Operations and Attributes I had to add this:
<LISTCOMPARTMENT name="DotNetAttributesCompartment" captionId="DotNetAttributesCaption">
<COMPARTMENTFILLCOLOR variability="Fixed" color="white" />
<TITLEFILLCOLOR variability="Fixed" color="lightgray" />
</LISTCOMPARTMENT>
Now when I run the tool I see:
I can design my own UML in essence, just as I can design any semantic foundation I wish. The next step would be to define how this Attribute is rendered when code is generated and to make the caption say ‘DotNetAttributes’ instead of ‘DotNetAttributesCaption’. I will leave that to the reader.
Top