For my current assignment, which is related to integrating existing and developing new Software Factories in our software development process, I decided to have a look at project GlidePath. According to the GlidePath website this project will deliver guidance on how to build software for Vista.  It delivers a web based repository of software factories that can loaded into the Visual Studio environment.  One of the very interesting features of GlidePath is the possibility to update the Software Factories over an RSS feed. It’s actually this feature that made me investigate GlidePath to see if we can use this or a similar approach in our own development process.

Once installed, you can use the Glidepath guidance package to create a Visual Studio solution structure. Instead of generating a full blown solution structure, like for example Service Factory does, Glidepath provides you with a rather empty solution.  At that moment the solution doesn’t reflect the actual product at all but rather provides you with the possibility to decide what factory to use in this solution structure (and thus what product to build?).  In this release of Glidepath you can only select one factory (MicrosISV factory) but I assume this will change in the future. Once I had added the MicroISV factory to my Glidepath solution I was surprised to see a lot of viewpoints popup in my solution structure (at this moment represented as .txt files).  From what I understood from Glidepath the idea behind these viewpoints is that you can select and configure them to specify how to build your product in the factory.  Glidepath will create new projects or enable packages (factories) in your current solution based on the viewpoints you configure for your product. Currently, Glidepath populates the MicroISV factory with viewpoints like “DataAccess”, “Deployment “, “Blogging”, “Legal”, etc.

Figure 1. Glidepath solution structure

After playing with Glidepath for a while I suddenly realized that I didn’t had a clue what kind of product I was actually building in my factory. I could see that my solution was populated with a project for “blogging” and project for “CSharp-WinForms-UX” because I selected these viewpoints for this solution.  However, from looking at the solution structure I wasn’t able to tell whether I was building a “blogging service”, a “blogging site” a “windows client for my blogging service” or whatever. Of course I understand this is related to this very early release of Glidepath and therefore lack of implemented packages, but I realized this was caused by the fact that the Glidepath factory doesn’t  have any notice (yet) about the product itself and therefore couldn’t tell me either what product I was building.

I was interested by this and tried to understand what this would mean for me if I had to implement (build a guidance package) one of the viewpoints for MicroISV. How would I know about the underlying product my viewpoint will be used on? Is it even necessary to have knowledge about that or can we generalize viewpoint implementations so they can be used on all products we are building? To be honest, I don’t have the answers for that at this moment.  My current thinking is that it would be helpful to have a formal description of the product I am implementing my viewpoint for but as said, I don’t have the answers yet.

A related question that interests me is: “what comes first?” Let’s say I was asked to build a factory for product X. Would I start with defining the viewpoints for my factory (security, deployment, etc.) or would I start by describing the basics of product X first? Or would I do this simultaneously?

Logically I would say, I first need a full picture of the product (product X) I am building the factory for.  Ideally, I would describe this product at a conceptual level (product model) in a way that makes this knowledge easily accessible and understandable for other people.  Once I know what I am talking about, and thus have understanding of the problem domain, I can decide what viewpoints are important, how to provide automated guidance for that, etc.

If we have captured the knowledge about the product we cannot only use this to author the factory but also to guide the factory user through the product at runtime. The factory can use the product model to communicate with the factory user in terms that make sense to the factory user and are related to the problem domain he is developing software for.

Currently Jezz and I are working on an experimental software factory authoring approach using a tool called the Factory Product Model (FPM).  I will not explain this approach or tool in detail in this post but if you are interested in more details you can read this, this, this and this post.

In this experiment, we are trying to validate whether a formal description (model) of the product the factory is building is a valid starting point for defining the factory and what it builds.

As far as I understand now, viewpoints will definitely play an important part in factory authoring and usage but what I am trying to find out is what impact they have and how they possibly relate to something like FPM.

I think specifying viewpoints is all about (some of) the requirements of the product we are building in the factory and therefore impact the type of guidance that is needed in the factory.

After all a viewpoint is what you get when you associate a work product, to an assets and a set of activities. Therefore viewpoints and work products are tightly related. It is just a question of which one do you define first?

I would be very interested in any ideas about this topic. What do you think? Do we need a product first approach (an FPM)? How does this relate to the Glidepath viewpoints approach I described? Do we need both? Do we need them in a specific order?

Let me know!

Two days ago, my colleague Rene and I gave a presentation on an internal (Dutch) LogicaCMG event for developers about Software Factories. In this session we first covered some general Software Factory stuff and after that focused on Service Factory to demonstrate the power of this, what I call, first wave of software factories from Microsoft P&P.

In our timeslot we had to compete with three other sessions but we managed to get 160 developers/architects to attend our session. It turned out that, at least on paper; we had the most popular session! I am still not sure about the reason for that. Hopefully this is because the Software Factory topic is hot. Another possible reason for this is that we might have fooled people with the title of our presentation. We choose “Software Factories, how to get a SOA in one hour” as the title for our presentation. In Dutch SOA means “Sexueel Overdraagbare Aandoening” which corresponds to “Sexual Transmitted Disease” in English. (However, I can’t believe that people really think you need an hour to get yourself a “SOA”.)

Besides a little typo in the demo (which of course caused a compile error) the presentation went quite well. Luckily, we had a complete (working) solution prepared so we didn’t have to spend anytime during the presentation on trying to find the typo.

During our presentation we demonstrated how to write a service from scratch (within one hour) by using Service Factory. In our demo we also showed how to use this domain specific language integrated with Service Factory to overcome some of the “limitations” of the wizard based approach in Service Factory.

Based on the feedback I got after the presentation it turns out that people are really enthusiastic about Software Factories, Service Factory and the accompanying Microsoft tooling (GAT and DSL Tools). Hopefully, we managed to get people interested enough in this technology to make them download Service Factory today!

Below some pictures. As you can see we were wearing our cool "P&P shirts Don gave us at the last Service Factory workshop  

In a previous post I explained that Jezz and I are working together to prototype a different “approach” for authoring software factories.

In this experiment we are trying to validate this new approach based upon design ideas refined in the implementation of the EFX factory, and verifying that against the publicly available release of p&p Service Factory.

Basically, we think that we need to be able to let the factory author describe the ‘Product’ that is built by their factory at a higher abstraction level than we do now. We suspect that this approach will greatly help in improving the factory authoring experience and the factory user experience, which therefore simplifies software development as a whole.

Part of this experimental approach is describing the important concepts of the factory product in a so called “Factory Product Model (FPM)”. Below you can see a first attempt to model the Service Factory ‘Product’ in an experimental version of the FPM designer.

To make the example a little more realistic we introduced a few new concepts and made some assumptions.

For example we assumed it is possible to develop different type of services (entity services and process services) in Service Factory (there could well be others too). We did this to illustrate the concept of ‘Product Variants’. Which are basically one type of product the factory creates. Since a factory can create several variants of the product in its product line.

[Think of a ‘Product Variant’ as a very similar product but different in architectural definition, rather than something different in instance values of the concepts.]

Another assumption we made was that the difference between these services only reflects in the “service implementation” part. This is probably not completely true but we are only using these assumptions to simulate the situation where the factory enables us to build different family members of the service product line.

Figure 1. Factory Product Model for Service Factory 

The picture of the FPM for Service Factory shows us that we identified a “Product Variant” for each service type that is supported in (our imaginary) Service Factory. Also we identified the “System” product variant that makes it possible to group together any number of these services. We could have gone with one product variant for all types of services, but we wanted to define some that are different to validate the approach.

You can imagine then, that each product variant would be represented to the factory user as a separate solution template offered to them when they create a new solution using this factory. (In this case we would have 3 solution templates: ‘Entity Service’, ‘Process Service’ and ‘System’.

Looking at the concepts in the model, one interesting thing is the “Service Contract” concept; the (green) concept we are using, reflects that we will be using a custom Domain Specific Language for modelling Service Contracts in our factory. This custom DSL for modelling service contracts is responsible for modelling all the concepts that are defined within the “Service Contract” shape in the Service Factory FPM. This kind of model is called a Work Product Model (WPM), since it defines work products of the FPM. The child concepts of the ‘Service Contract’ concept will be refined in this WPM, and are represented here for logical structure.

The other concepts in the Service Factory FPM reflect common terms used in the Service domain that are therefore part of Service Factory. The concepts in this FPM will be represented to the factory user as a mechanism to “drive’” the factory. This view provides the user with a higher level abstraction than the current “Solution Explorer” view that is used in today’s factories. So instead of being confronted with all the technical details he can develop his services by using concepts that make sense to the service domain.

Figure 2. Example of the Service Factory Product Explorer

To make all of this happen, the next step would be mapping each concept in the FPM to physical solution structure, projects, and project items of Service Factory. Once that is complete, we define the assets (recipes, templates, designers, etc.) that will be used to create and configure these physical artefacts. Once configured correctly, the FPM is then used as a starting point for populating the factory schema for this factory. It already contains the definitions of all the work products, their assets.

Another idea we would like to validate in this experiment is the speculation that we can use the concepts modelled in the FPM to use as reusable parts in other factories. It would be great if we could find a way to just “query” this FPM (and/or factory schema) of a factory, and select the available concepts that we want to use to compose other factories from. You could imagine in this case that the ‘ServiceContract’ concept is self-contained enough to be reused in another factory (complete with DSL model and definitions).

Interested in Software Factories and trying to understand the common terms uses in this pace? Have a look at this Software Factory ABC at Jezz's blog. Please leave a comment if you have anything to add/change and we will be happy to update the list!

In an earlier post I promised to share some more details about integrating DSL Tools with GAT. I am using some of the “techniques” in this post to experiment with integrating our Service Description Language with Service Factory.

As far as I know there are two possible approaches for integrating DSL Tools with GAT. In the first approach we simply execute GAT recipes from with the DSL Tools and pass the necessary arguments (we collect from the DSL model) to the recipe in the “execute call”. In the second approach we create “value providers” that are able to read the DSL model (selected shape, model root, etc.) and can be used directly in the recipe definition (“ValueProvider” tag) in GAT. It’s obvious that the second approach offers a more solid solution. For my experiment I tried both approaches. To be honest I don’t expect that I need my “experimental code” for too long. I can’t believe that Microsoft isn’t going to make something available to support this “out of the box”. This post of Mauro indicates that I might be rightJ.

Let’s have a look at the first approach and execute the “GenerateASMXDataContractFromSchemas” recipe from the “ASMXGuidancePackage” from the DSL message shape to generate the datatypes for all DataContracts modelled in the message shape of the DSL. The screenshot from this example can be found in this post.

Experimental hive

Before we start we have to make sure that the DSL isn’t using the “Exp hive”. GAT is registered in the “main hive” so we have to use the same hive both the DSL Tools and GAT for our integration experiment.

I did this by changing the .csproj files for the “DSL” project and the “DSLPackage” project.

In the “Dsl.csproj” file I deleted the “/rootsuffix Exp” from the <StartArguments> tag

                <StartArguments>/rootsuffix Exp /DesignTimeRun "..\..\..\Debugging\Debugging.sln"</StartArguments>

In the “DslPackage.csproj” I did the same action and also deleted “Exp” from the “<TargetRegistryRoot>”

         <TargetRegistryRoot>Software\Microsoft\VisualStudio\8.0Exp</TargetRegistryRoot>

Service Factory Guidance Packages

Of course we need to debug the new code for calling recipes in our DSL. To make sure the GAT packages are enabled for the “DSL debugging solution” I created a new solution based on the “ASMX Service” template of the “Web Service Software Factory” package. After that I changed the “debugging solution” for the DSL by replacing “Debugging\Debugging.sln” in the “<StartArguments>” tag in both project files with the correct path and name of the new solution based on the “ASMX Service” template.

After making the above described changes, the newly created Service Factory solution opens up as the debugging solution (in a new VS2005 instance) for our DSL. So, now we are ready to write some code to actually call the GAT recipes from the DSL.

Reference RecipeFramework dll’s

To make the code compile we need to reference the “Microsoft.Practices.RecipeFramework.dll” and the “Microsoft.Practices.RecipeFramework.Extension.dll” from the DslPackage project. The “Extension” dll is part of Service Factory and doesn’t have a strong name. To solve this issue we can open the “ASMX Guidance Package.sln” located in “C:\Program Files\Microsoft Service Factory” (default location), sign the extension project and compile it.

Code

To make the code work we need the following using statements:

using Microsoft.Practices.RecipeFramework.Services;

using Microsoft.Practices.RecipeFramework.Extensions.CommonHelpers;

I assume the code stated below is coded in the “OnMenu…” method for a custom command for one of the shapes in the DSL. Please not that the code example is just demo code!

In this first code snippet we can see that get a reference to the Visual Studio infrastructure. After that we get a reference to the “RecipeManager”. We will use this reference to instantiate the Service Factory Guidance Package. On my machine this is called “CustomASMXGuidancePackage”. This is because I already made some other modifications in the package.

The recipe that I am using in this example needs a reference to the Service Factory “DataType” project to execute correctly. We can use the “DteHelperEx” class located in “Microsoft.Practices.RecipeFramework.Extension.dll” to help with that. Unfortunately I wasn’t able to get a reference to this “DataType” project directly. This is probably because the project is located under the “Service” solution folder in the Service Factory solution structure. I didn’t take the time to investigate this any further so I took another approach for this demo code.

First I get a reference to the “Service” Solution folder which of type EnvDTE.Project. After that, I iterate over the ProjectItems in the “Service” solution folder to get a reference to the “DataTypes” project.

// Add DSL DataContract's to Service Factory DataType Project

Message message = ((MessageShape)this.SingleSelection).ModelElement as Message;

 

if (message != null)

{

    foreach (DataContract dataContract in message.DataContracts)

    {

        if (DteHelperEx.FindItemByName(dataTypeProject.ProjectItems, Path.GetFileName(dataContract.SchemaLocation), true) == null)

        {

            dataTypeProject.ProjectItems.AddFromFileCopy(dataContract.SchemaLocation);

        }

    }

 

}

                      

arguments.Add("DataContractsProject", dataTypeProject);

 

serviceFactory.Execute("GenerateASMXDataContractFromSchemas", arguments);

 

In the second code snippet we can see that we get a reference to the selected message shape in the model, iterate over all the data contracts in the message to add the XSD files that describe the datacontract to the “DataType” project (if not already added). The XSD files are referenced in a “SchemaLocation” property for the DataContract in the DSL.

After that we add the reference to the “DataType” project, needed as an argument for the recipe, to the Hashtable named “arguments”. You can find the necessary arguments for the recipe in the xml file that the recipe is defined in. In this case “GenerateASMXDataContractFromSchemas.xml” (located in “C:\Program Files\Microsoft Service Factory\Guidance Packages\ASMX Guidance Package\ASMX Guidance Package\Recipes\ASMX”). The last line of the code snippet finally executes the recipes on the instance of the guidance package.

Of course in this very simple example we are only sending one argument to a recipe that doesn’t have a “wizard form” attached to collect the values for the arguments. But the same approach can be used for recipes that do include wizard forms. However in that case it might not make sense to just display the values that are passed from the DSL to the recipe wizard form and ask the user to press the “Next” button on the wizard form.

For that situation it might be better to modify the recipe and/or write a value provider that can be used to read the DSL model values directly from the recipe. In a next post we will have a look how we can change a Service Factory recipe to make use of a custom build value provider that reads the DSL model.

[Update: added missing link]

In a previous post about “the next generation software factories” I wrote about the factory meta model and it’s role in providing a better user experience for the factory user. A more detailed explanation of the factory Meta model, or better, Factory Product Model (FPM) can be found in this post on Jezz’s blog. We can even see an experimental version of an authoring tool for the FPM in this post.

All of the above mentioned posts are using screenshots of the EFx Factory as an attempt to explain the Factory Product Model concept and it’s potential. However, because EFx isn’t publicly available at this moment we reckon that missing knowledge of EFx and its underlying domain might be debit to understanding the ideas behind the FPM.

So, to solve this issue we decided to take the first official drop of Service Factory from p&p and use that as a test case for discussing the Factory Product Model and possible future authoring tooling. Most people interested in software factories should at least be familiar with Service Factory as an early example so we think we can use this factory and the problem domain it is solving as a good example.

In the next couple of posts we will define the FPM for Service Factory by first using an experimental version of an FPM authoring tool. Along the way we will describe the important concepts of the FPM and demonstrate what Service Factory could have looked like if it leveraged a FPM. We will also describe the relationship of the Service Factory FPM to its underlying physical solution structure and how all of this related to a fictional Factory Schema for this factory.

We will not only use this series of posts to share information to help peoples understanding of these concepts, but also to validate and refine our current thinking in this space so any feedback is highly appreciated!

Let’s start. The first thing to do when authoring a factory is to make sure we fully understand the problem domain the factory is supposed to solve. For the Service Factory, this domain is already well defined and is reflected in the Service Factory solution structure. We will use the following concepts from Service Factory in our discussions:

• Service Contract
• Service Interface
• Service Operation
• Message Type
• Data Type
• Service Implementation
• Business Entities
• Business Logic
• Data Access Logic

Some of the above Service Factory concepts are directly realised in the Visual Studio solution structure. Others, for example Service Operations, are “hidden” somewhere in a C# code file and can only be viewed by opening the physical file.

We will use the above list of concepts together with their physical representation (projects, source files) in Service Factory to model a FPM for Service Factory. We will then use this higher level abstraction of the Service Factory to see if we can further improve the factory user experience by driving Service Factory from this abstraction.

Stay tuned…

Service Description Language meets Service Factory

I have been working for quite some time now with the DSL Tools and spend the last couple of months on Service Factory and related to that a little bit on the Guidance Automation Toolkit. Now, I decided to integrate the two and see how easy it is to make customizations in Service Factory and call GAT recipes from the DSL Tools.

Both our DSL (Service Description Language) and Service Factory cover the same problem domain of “designing services” so this seems to be a perfect fit ;)

I decide to start simple and added two new custom commands to the message shape in our DSL. As you can see below we now have the opportunity to call the “Generate DataTypes” and “Generate MessageType” recipe from the message shape.

My first concern was to just make it work so I didn’t spend any time yet on optimizing the Service Factory recipes to make them match better the DSL. I reckon this is necessary to make the user experience of the DSL integrated in Service Factory better.

If we have a look at (some of) the properties of the DataContract (picture below) that is modelled in the message, we can see that the DataContract is defined in the “RestaurantData.Xsd”.

After selecting the “Service Factory: Generate DataType” command on the message shape we can see that the XSD that describes the DataContract is added to the Service Factory “datatypes” project and that a datatype class is generated out of the XSD file.

Another thing we can do now is generate a Message Type for the message that is modelled. In the picture below we can see that we can execute the “Service Factory: Generate Message Type” command and that we can send the necessary data from the message in the model to the recipe in the Service Factory package.

As said, the Service Factory recipes and wizard need some changes to make them fit better with the DSL. For example in this case we don’t need the “Response Class Name” textbox on the wizard because we are starting the recipe from one message in the model. To solve this we can of course execute this recipe from the Service Operation in our DSL or customize the Service Factory recipes.

In a future post I will share some more technical details on how to call GAT recipes from a DSL, how share data between the DSL and GAT, etc.

For me it was good to see that it is possible to combine DSL Tools and GAT and that is relatively easy to make changes in the Service Factory package (not shown yet).

To be continued...

In the last couple of months I have seen the enormous power of these first examples of software factories but also saw some of pain points exhibited by them. I decided to write some them down also describe some of the (possible) features of the next generation software factories. At some points I am using the EFx factory and my discussions with Jezz as a reference for this post.

Where are we today

After the introduction of the Software Factories initiative and the publication of the “Software Factories” book it took quite some time before the first examples of Software Factories became available. Apparently the Software Factories concept was so totally new that people needed this time to get familiar to the concept and possible advantages.

Even now, when looking at the first examples of Software Factories, we can see that most of these examples are in their infancy. One of the reasons for this is the fact that not all Software Factories concepts, like for example Software Factory Schema and Software Factory Template, are not as well defined and understood as we would like them to be. As a result, there is very limited tool support for authoring factories.

Tools like the Guidance Automation Toolkit (GAT) and Domain Specific Languages Toolkit (DSL) have proven to be successful in these early examples of factories but their learning curve is steep and these assets only offer authoring of some of the work products which make up a factory, they offer not support of the factory overall as a cohesive development environment.

Early examples

When we have a close look at some of the characteristics of the first wave of factories from the patterns & practices team, for example ‘The Service Factory’, we can see that they are primarily based upon GAT recipes only. These ‘super’ guidance packages make extensive use of related recipes to create source artefacts in a solution. The factories are technically driven to automate the common tasks of architects and developers that would normally have to be hand crafted.

Whilst the recipes of these factories encapsulate valuable knowledge and experience of the solution domain, they act only as a means to write source code which has to then be subsequently tailored towards a specific solution. These factories make little or no use of modelling to describe the problem domain and offer little abstraction. Hence these factories still require expert knowledge of the solution domain in order to exercise them effectively.

As a result, the factory addresses a problem domain from a technical, Visual Studio related point of view instead of a more conceptual perspective that simplifies the problem domain itself.

Because of this tight coupling of these factories with the physical artefacts of a solution we cannot easily differentiate in views between the various types of factory users. This means all users experience the Factory in exactly the same way.

Another issue in the current wave of Software Factories is a missing, formalized way of describing software factories. An often heard concept in this space is ‘Software Factory Schema’ but till now nobody seems to know exactly how this is implemented. As a consequence the Software Factory Schema isn’t supported or integrated in any form of tooling in these early factories, and consequently we are still faced with a solution structure based approach in the early examples of these factories.

Software Factory User Experience

As stated previously, the user experience of today’s software factories is governed by the view of a solution in terms of its physical artefacts and therefore has a rather technical solution based focus. Let’s have a look at the two views that currently represent the factory in today’s examples.

Solution Structure view

The first view that can be identified is the “Solution Structure” view. This is a view we are all familiar with and has been around for a long time (as seen in the Solution Explorer tool window). It provides an overview of the Visual Studio solution structure and shows us all the different artefacts, like projects and source files that our software solution is composed of. Developers and architects familiar with Visual Studio know how to use this view and nobody really complains about it. Simply because it just represents the way we are developing software today.

Besides an overview of the solution file, project files, assembly references and code files it also reflects the architectural layering of the software component. It even provides us with build information, the naming of the individual components and the way the software will most likely be deployed. Basically, this view tells us a lot more about the physical infrastructure of the solution, the .NET framework and the build engine than it tells us about the purpose and concepts of the software we are developing.

In actual fact, the solution structure is often tailored by developers to describe the physical deployment view of a solution and the logical structure view of it at the same time. Often the result is a compromise of both these views, neither fully satisfying either, and hence every development team has opposing opinions on a best representation of these views.

This view is always the same for all project members. We have no way to filter the content of this view. The architect, the developer and the tester are all faced with the same view of all artefacts to represent their different concerns. Most of the time this isn’t necessary at all and it even makes software development more complex than needed.

Guidance Navigator view

The second, so called, “Guidance Navigator” view, is a new view driven by necessity by the Software Factory initiative. A first example of this view is available in the factory examples from the Microsoft patterns & practises team. This “Navigator” view provides us with a clear overview of all the activities (recipes) that can be executed in the solution.

Although we can also start these activities from the context menus on the individual items in the solution view it’s the “Guidance Navigator view” that summarises all the recipes and makes them easier to discover in one place. Another benefit of the “Guidance Navigator” view is that actions are tagged with additional help and background information to improve first time factory users understanding and improve the user experience. This is one example of the support for the “guidance in context” pillar of software factories.

However, an important aspect that is missing in this current implementation of the “Guidance Navigator view” is the lack of support for pre- and post conditions for activities. We need these conditions to control when activities become valid next steps for the factory user who is navigating the factory. Without this capability the user is still required to know which recipes to run in which order and with no way of telling the state of a completed activity as a whole. This view also currently lacks the capability to filter activities based upon the role of the factory user.

What we can learn from this “Guidance Navigator view” is that we can dramatically improve the usability of our software factory by just representing the same information in a different way. The “Navigator view” is a good start and it does provide us with a much better view on the factory activities but, we are not there yet! It still doesn’t provide us with a conceptual view on the underlying problem domain of the factory and thus the software we are developing. 

Software Factory Schema

One of the things we are currently missing a way to describe our software factory in an understandable and predictable way. The suggested means for this is the ‘Factory Schema’. This schema is often referred to as the “recipe” for the software component we are developing in the factory. It lists all the ingredients like, source files, models, frameworks and describes how to combine them to build the software component. It also describes the different views we have of the individual parts and the factory as a whole.

Although this description is quite clear it isn’t so clear what pieces of information should actually be part of the software factory schema. Even if we are able to identify all individual parts of the software factory schema most of us don’t know in what form we have to describe this to make it usable. Till now there is no formal, publicly available specification of the software factory schema that we can use to write our own schema. One of the things we do know is that a well described and implemented software factory schema might be the key to success for future software factory development and usage. The Software Factory Schema offers very important benefits for the software factory user.  

Let’s have a closer look at the software factory schema and try to describe the most important parts of it. The first concept in the schema is the “viewpoint”. Basically a viewpoint is a related set of activities, artefacts (work products), etc. that have a relationship. We can use the viewpoint to specify what elements of the software factory will be valuable and thus visible for a specific type of software factory user (stakeholder). It’s the viewpoint concept that gives us the opportunity to specify how different types of factory users will experience the factory. This might be based on the role of the factory user which makes role another concept in the software factory schema. Viewpoints can be related to each other by creating mappings between viewpoints.

Now we know viewpoints contain a set of activities we also know that activity is another important concept within the software factory schema.

An activity can be defined as a set of actions that we have execute in order to produce a work product or artefacts. Activities can be grouped together in a set of related activities.

A third concept in the Software Factory Schema is the workproduct. A workproduct can be best described as “anything” the software factory produces. It can be anything from one single xml file to a combination of code files or models of part thereof. Workproducts can be hierarchical grouped together. By grouping together workproducts we can define additional abstraction levels on top of the low level workproducts like for example source files. We will later see how we can use these abstractions to boost the usability of software factories. Activities use assets on their turn to produce workproducts. Think of assets as code generators, frameworks, domain specific languages, etc. that are used to create the workproducts. Workproducts have state that will change over time from, for example, created, partially ready to finished, by executing one or more activities.

(Have a look at this post from Jezz for more detailed information about the Software Factory Schema.)

Software Factory MetaModel

Another important concept in the Software Factories area is the Software Factory MetaModel. The Software Factory meta model helps us describe the software factory at a higher abstraction level. As we have seen earlier, today’s factories are mostly described and exposed by using the capabilities and terms available in the Visual Studio.NET infrastructure (Solutions, projects and files). Important concepts in our factory currently are reflected only in project names, names of source files, and layout of the projects and solutions etc. A concept that the factory defines which may include several source files cannot be easily represented in physical solution structure, and also many of the physical source artefacts created by Visual Studio tools have little meaning in the schema of the factory.

Therefore we need a Software Factory meta model – a model of the concepts of the factory that the user understands in terms of the problem domain. We can use this meta model to define abstractions that exist in the problem domain that the software factory deals with. In other words the meta model provides us with a mechanism we can use to describe our factory at a more conceptual level. We can define the so called software factory concepts in this meta model and relate them to each other. To make this concept a little more clear let’s have a look at the following example.

Think about a software factory for developing services. Thinking about the “service domain” we might identify concepts like “Service Interface”, “Service Operation” and “Message Contract”. When building a software factory for this domain by using the current tooling we will see that these concepts only reflect in documentation, project names and files names. The factory is driven by executing recipes that eventually add source files to solutions structures. There is no way to navigate through the factory by, for example, iterate through all the “Service Operations” that are available in the solution that is built with the factory. Simply because for the factory itself and Visual Studio.NET this concept doesn’t exist.

All that the first wave of factories have knowledge about at this moment is a set of files grouped together in a Visual Studio solution together with a set of recipes.

Figure 1 shows us how a service, built the Microsoft Service Factory, is represented to the factory user. Later on, we will see how we can change this representation by leveraging the factory meta model.

Figure 1. Representation of a service built in Service Factory.

The presence of a Software Factory meta model would enable us to describe the concepts that exist within the problem domain and thus are valid for the software factory. A populated meta model for the above described factory would provide us with a capability to navigate through the factory by using concepts like “Service Interface” and “Service Operations” instead of navigating through the projects and underlying files in the Visual Studio solution.

To demonstrate the power of the software factory meta model we will use EFx factory which is the first factory that leverages a factory meta model. EFx is an architectural guidance factory that is an offering of Microsoft Services. We will use EFx factory to introduce the “software factory view” that is built on top of the factory meta model.

Software factory view

The software factory view is the third view we can identify in the software factory area. In this view, we are displaying the factory concepts, defined in the factory meta model, to the factory user. The factory user isn’t confronted with physical artefacts like solution, projects and source files. The result is a view that allows the user to construct the products of the factory in terms of the problem domain. As we can see in figure 2 which represents the software factory view for EFx factory we are now dealing with concepts like Applications, Subsystems, Business Entities, etc.

Figure 2. Software factory view in on top of the EFx factory meta model.

The hierarchy in this view doesn’t reflect the underlying file system or solution explorer structure at all. Instead, we are looking at the conceptual structure of the software we are writing. We can execute our recipes on these concepts, and have them relate to one or more physical artefacts in the solution such as source files, diagrams and other models that extend the factory schema.

The advantages of this view are numerous. First of all, this view simplifies the problem we are dealing with during our development activities. Developers don’t need knowledge of all the underlying details like project structures, files, deployment scenarios anymore. All they are faced with are the conceptual pieces of the software they are developing together with the activities, implemented as recipes that are related to the concepts. They can execute activities to produce the associated workproducts without worrying where to put it in the Visual Studio solution structure or store it on the file system. With this software factory view in place we can even change the complete underlying Visual Studio solution structure, to for example meet specific architectural requirements and deployment scenarios, without developers even knowing about it.

Another advantage of this view is that we can leverage the viewpoints we defined in our software factory schema to hide specific concepts from different types of software factory users. This means we can target the factory user experience based on their role to better meet the requirements of the different types of users. We can even define a viewpoint that only displays the concepts that make sense to business analysts or end users so we can discuss the software development process with them.

A view like this requires that the factory maintain the state of the Meta Model, rather than creating physical artefacts using recipes. Instead recipes are used to configure the meta model, and physical artefacts are then generated at a later stage from the meta model.

Summarized we can say that we can use the software factory view to represent the factory concepts described in the meta model to improve the user experience of the factory.

In some future posts I will elaborate a little more about some of the above described concepts. In the meantime check out Jezz blog for a lot more interesting information on software factories and EFx factories in particular.

It’s been a long time since I wrote about the never ending story of the small demo Domain Specific Language we are building. In the meantime I received a few mails asking me for the status and Steven Kelly even mentions in this post that I probably gave up on the DSL Tools.

Well…, as we wrote in our recently published article (still only available for subscribers) we have plans to make it downloadable as soon as the V1 of the Microsoft DSL Tools hits the streets. To prepare a little for that I decided it was about time to install the latest June CTP of the DSL Tools and try if I was able to get this DSL working in the new DSL Tools.

I used the migration tool that comes with the June CTP to migrate my old domain model and designer definitions into the completely new format. Although this migration went quite smooth, I decided to start from scratch again, just to get familiar with this new release of the DSL Tools.

To be honest, that took some time. I considered myself an “experienced” DSL Tools user so decided it wasn’t necessary to read the (limited) documentation. I was wrong! Because of that I noticed far too late that there is a “DSL Details” window that helps you set some (important) properties for the domain model and designer. This was one of the reasons I didn’t get things working. Once I found the DSL Details window (View/Other Windows from the menu) things became much easier.

Another issue that took some time was that during debugging my DSL the shapes didn’t appear after dropping them on the design surface. They were added to the underlying model and did appear in the “Explorer” window. After some time I found out that I had to add my domain classes as “Element Merge Directives” of the root (in my DSL “Service”).

The good thing about the new DSL Tools is that you (almost) don’t need to manually edit the underlying XML anymore. I only needed that to make my compartment shapes work. Once you understand the concepts, the “DSL Explorer” makes it relatively easy to build a domain model and designer and it looks *nice*!

As far as I am concerned, the new June CTP is a very nice upgrade of the DSL Tools.

Now I only have to migrate all my custom code (if still needed), add some validations and include the WSDL generation code and I am done J.

Hopefully there will be no breaking changes for V1!

Great news! The July drop of Service Factory is available for download from the public workspace. This drop includes the ASMX package for Service Factory together with a totally new Data Access package. No need for me to go into any details because Tom already did a great job explaining the features of this July drop. One of the great features is the new "Navigator". This really improves the user experience of Service Factory!

Go download it, have fun and let us know what you think about it in the message board!