Defining a Factory Schema

So now you have an idea of what the factory schema is (‘What is a Factory Schema’), and hopefully we helped clear up some confusion you may have had there. We can now start looking at how these schemas are used by the factory.

By way of an example, I am going to describe a simple factory that automates the creation of: a ‘Service Contract’. (A common theme in the real-world factories we see today, and a key piece of the EFx factory)

OK, so you may imagine that to create this ‘Service Contract’ we would have to build a domain specific language (DSL) designer to model the service contract as a whole.  We would use simple shapes and connectors to draw ‘Service Interface’ shapes on the design surface and connect it up to other shapes (representing other concepts) and configure all these concepts on the diagram. The DSL abstracts the details of actually implementing a ‘Service Interface’ in source code and boils it all down to simply defining a very simple set of metadata for a ‘Service Interface’ and how it relates to other concepts including the service contract itself.

First off, all of the shapes on the diagram of our DSL are visual representations of an underlying ‘meta-model’ of the ‘Service Contract’.

The intention of this model is that at some point later, after configuring all the shapes on the diagram, we hit a big green button, and our factory generates out a bunch of source code, compiles it and we have our ‘Service Contract’ solution.

Now, I don’t really want to go into what source code is actually generated to implement our service contract but I think its suffice to say, at this point, that the factory will determine how to best write the code the in the most optimised way to describe our solution based upon the metadata (meta-model) you configure for it.

One of the things you should strive towards in your factory is that (a) it should try to provide an appropriate higher level abstraction of ‘something’, and (b) encapsulate the domain specific knowledge and experience of implementing that ‘something’ in the most optimal way depending on how that something is configured by the user. You can think of the outcome of these objectives in the same way as a source code complier generates machine code based upon how the developer wrote the source code. A compiler provides an abstraction of the machine code required to run through the CPU with a high level language (like C#), and generates optimal machine code based on what the developer is doing in their source code.

So, up till now we have only addressed and described a small part of the overall factory, but this should be sufficient to make the point.

How to Populate your Schema

The first thing we do to construct our factory schema is to identify the ‘Stakeholders’ (the users) of our factory - the ones who derive benefit from using it. Let’s just say for arguments sake, that the only user we expect to use this factory is a developer building a solution with it, so the stakeholder is the role of this user – ‘The Solution Developer’. We could have built a factory that addresses the needs of other stakeholders such as the Solution Architect, the Tester, the Project Manager, and the System Architect etc., but we are keeping it simple. The thing to avoid here is that this is not a time to brag about all the people your factory could possibly benefit in an attempt to provide the ultimate of ultimate in factories. If you don’t provide benefit explicitly to a stakeholder, leave them out of the schema.

Now you know those who are using the factory, we now look at what it is they are producing by using the factory - the ‘Work Products’. A WorkProduct is something the factory creates, an artefact or some kind (source file, schema, document, configuration file, diagram etc.) it could be almost anything. It may be a completed artefact or it may just be an edit or partial change to an artefact. In our case the main artefacts are a solution file, a DSL diagram (containing the model) and the source code generated by this model (containing the programming classes).

Now, for the tough part. We now need to identify a ‘ViewPoint’ or a ‘Concern’ that our stakeholder has/had, which resulted in the creation/change of these WorkProducts.

So let’s say for now that our ViewPoint is called ‘Service Interface Definition’.

At this stage we are working at quite a low level of description. These are the fine grained (low level) ViewPoints we are describing. At a later stage we would describe much (higher level) course grained ViewPoints that would nest inside them this ViewPoint - such as ‘Create Service Contract Specification’.

So, now that we have a name of our ‘ViewPoint’, we can start to flesh it out. A ViewPoint is enacted by a StakeHolder, and it is composed of one or more Activities. Each Activity may yield a WorkProduct and this WorkProduct is created by using an Asset. An Asset is usually a tool such as a source code editor, or designer or template etc. Each Activity maybe composed of nested child Activities. An Activity also has a state. That means that it has an initial state that the WorkProduct was in before the Activity was enacted, and a final state after the Activity was enacted. There will be a finite set of states it can be in. For example, the DSL diagram in question could be in one of the following states: Created, Configured, Validated and Completed. There is also an Operation associated to this Activity that describes how the WorkProduct is operated upon.

Let’s use a concrete example to clear this up:
Our ViewPoint is called ‘Service Interface Definition’, it may be composed of 2 Activities: (a) Add a Service Interface Shape to diagram, (b) Configure the metadata for the shape.

Now, if we consider the first Activity, we can say that the WorkProduct that is worked upon is the ‘Diagram’ (an instance of the designer). This activity starts in the ‘Created’ state and when the activity completes, the state will be ‘Configured’. Of course the Operation we performed would have been ‘Configured’, and the Asset used was the Designer.

So, we can do this for all the activities of the ViewPoint and we get something like this.

There is just one concept missing here in this definition – the concept of conditions.

The WorkProduct itself, as an output of this ViewPoint, can form the input to another ViewPoint (yet to be defined). In most cases, in order to qualify as an input to another dependent ViewPoint, it has to reach a certain state.

Once the WorkProduct has reached this required state, then the dependant Viewpoint can be activated and enacted. So what’s missing here is a statement of what other WorkProducts (and in which state) are valid for this ViewPoint to become active. These are called pre-conditions.

The other concept to grasp is that the output of this ViewPoint is a WorkProduct which may be an input to another ViewPoint. This is called a post-condition.

Therefore, we need to define the pre-conditions and post-conditions for this ViewPoint.

In our example above, in order to enact the ViewPoint ‘Create a Service Interface’ we need to have created the ‘Contract Specification Diagram’ which is a WorkProduct in the ‘Created’ or ‘Configured’ state from a previous ViewPoint (say ‘Create Service Contract’). The post-condition can easily be calculated from the expected state of the WorkProduct at the end of the last Activity for this ViewPoint. In this case, the ‘Contract Specification Diagram’ in the ‘Configured’ state.

So to describe this, let’s add these definitions to our viewpoint description.

At this stage we have a simplified set of information for our schema. In reality there are some other details we need in order for the schema to be useful to a machine, but for the purposes of this discussion we can make do with this information for now.

In order to complete the process of defining the schema we continue to define the ViewPoints at this level until we have all the WorkProducts covered. For example here is another ViewPoint.

Once you have that, then you start to group the ViewPoints with some higher level ViewPoints. What this means is that we start to look for more abstract ViewPoints that contain nested child ViewPoints. In our example here, the next level up would be the ViewPoint called ‘Service Specification’. This ViewPoint may not contain any Activities, but may well group together several nested child Viewpoints such as ‘Service Interface’ and ‘Service Contract Definition’.