MicroFocus Together: Version Control System Integration

In my experience some of the most valuable object and service-oriented models have been those built collaboratively. There is so much information in the process of building a model that is lost in the end result, the discussions, assumptions, reasons why things are as they are, and so on. Also an object model built collaboratively means more emotional ownership and 'buy-in' from the wider team instead of being restricted to one or two elite model builders or 'architects'.

However, having a team work on the same model concurrently raises challenges for many modelling tools where single user operation has been assumed and multi-user support has, at best, been bolted on as an after thought if at all. One approach is to go low-tech, drawing diagrams on flip charts in model-building workshops and nominating one person to update the model in the chosen UML modelling tool at the end of the session. This is appropriate for significant modelling activities but far less appropriate for day to day refinement of a model when different people or sub-teams are making frequent, small updates as their work progresses. Here concurrent access to different parts of the model is needed and some control on who is changing what when is needed to stop people overwriting other's updates and the model becoming inconsistent or even corrupted.

In any model-driven or model-centric approach, an object or service-oriented model is a living thing, continuously being developed, refined, and amended. The history of the changes being made becomes important, as does the ability to baseline models at certain points, revert back to a particular version of part of a model, release part of a model to another team or sub-team, and so on.

Some modelling tools use a purpose built repository. With the exception of the new Domain Specific Language (DSL) models in Together 2007, Together stores each of its diagrams in a separate XML file and either stores the model elements of each package in a separate XML file or each package-level element (ie. not those nested inside another element) in a separate XML file. UML packages are represented as file-system directories (folders) in Together. This granular use of directories and files means Together models can be stored easily in an industrial strength version control system or configuration management repository like CVS, Subversion, Perforce, ClearCase, or MicroFocus StarTeam (see figure 1)..

Integrating with an industrial strength version control system or configuration management repository has a number of advantages over a proprietary model repository:

1. the model can be stored alongside all the other project artifacts including source code, requirements documents, screen mock-ups, etc, and the whole can be baselined, labeled, take part in release workflows, and be linked to process items such as change requests, etc. The model is not an 'odd man out' sat in some other server.
2. industrial strength version control systems or configuration management repositories are proven to scale to handle large, long-running projects and programmes of projects.
3. administration skills for popular version control systems or configuration management repositories are readily available and if there is a standard in an organisation the skills will already be in place.
4. Most popular version control systems or configuration management repositories have plug-in clients for the Eclipse platform and, therefore, play very nicely with Together (assuming, of course, they are both support the same version of Eclipse).

There are a couple of disadvantages to be aware of in not using a purpose-built model repository:

1. Searching across multiple or large models can be harder as the vcs or cm repository has no special knowledge of files that form a model.
2. Care needs to be taken if, as Together does, unique identification numbers (UIN's) are used to identify model elements, that files are not copied outside of Together's control in such a way that multiple elements with the same UIN are created. This can be achieved accidentally by renaming a file locally and adding it again to the vcs or cm repository instead of renaming original in the server. In practice if people are made aware of this possibility, it rarely causes any problems.

On the whole, however, the advantages of an industrial strength version control system or configuration management repository tend to outweigh the disadvantages.

Figure 1: Together with MicroFocus StarTeam vcs - click for bigger image