Up Previous Next Title Page Contents

3.5 The Watch Architecture Revisited

As the watch DSM environment was created purely as an example, it is clear that in its current form it does not form a perfect vehicle for a true real-life development project. The main problem comes from having to support different operating systems for the build scripts. This necessitates a property to select the build platform. Unfortunately, the property selection is saved along with other properties, and thus would not work well in a multi-user environment. As the property is changed by each user, on different platforms, that property becomes locked and other users cannot change it — and hence can only perform a build if they happen to be on the same platform.

A better solution, but one which would have been overkill for this example as a single-user tutorial, would be to have another kind of graph to specify build properties. The graph could consist of just properties, for instance a name ‘Linux watch build’, the Generation target platform selection ‘Linux’, and a property pointing to the previous top-level graph, 2008Models. There could be a number of such graphs for 2008Models, one for Linux, one for Windows etc.

Another possibility, allowing still better multi-user interaction, would be to make the build properties graph yet more generic by adding a property containing the name of the generator to run, and making the property data type of the graph reference be just Graph. This would allow each user to make their own project with such ‘build command’ graphs for a variety of uses.

Of course, the real situation in the organization should be the deciding factor in designing such solutions. A little creative thought about using generators, graphs and projects can often pay good dividends in terms of smooth co-operative development.

Up Previous Next Title Page Contents