We have a, hopefully, fairly rigorous model in our repository. The model, we hope, accurately reflects the real world such that we are able to make useful analyses and recommendations. We'll call this the rigorous model.
However, rigour often gets in the way of simplicity and communication. Simplicity is necessary for communication with others via presentations. We have to keep it simple, without making it simplistic! We can make use of derived relationships in the rigorous model to create diagrams which have a simplified view of items and their interrelationships.
However, the objects in the rigorous model are very rich and surface many properties. The diagrams look cluttered and busy also, the restrictions on things like line width pose problems. We initially thought that we'd just create more complex shapescripts that would allow us to "simplify" the items, but eventually, we realised that we really needed a separate "presentation" model and diagrams.
Typically, presentation models and diagrams are used to achieve a decision (particularly at an executive level). As I have said in the past, "When you can see the problem, you can see the problem..." So, for a presentation diagram, we need to know the message being rendered (this is true for all diagrams, but particularly so for these diagrams).
The presentation model consists of special presentation items vertices which have special rendering properties (see below) to allow us to simulate (to an extent) the kind of varying shapes you see on presentation software diagrams - like PowerPoint etc. However, these vertices are linked to an item in the rigorous model by means of a special "View of" relationship (the presentation item is a view of the rigorous item). The rigorous model has a large number of metatypes (to give us the level of modelling we believe we need). We've tried to reduce the number of metatypes in the presentation model to less than a dozen - similar to a metaclass abstraction. We can, therefore, provide a mapping between the rigorous metatype and the presentation metatype (including the provision of a property indicating the subtype for the presentation metatype). An example might be Business Function {rigorous} => Activity (subtype Function) {presentation}.
We hope to be able to maintain this mapping over time. Since the "View of" relationship exists, we can track the changes required in the presentation model as the rigorous model evolves.
In the presentation software diagrams, the items can be of arbitrary shapes. So we determined that a boundary item can provide much of the shape management we think we need. This is particularly true of the boundary user-defined shapes (Orthogonal, Freeform), however, there are issues. One is that boundaries do not appear on the browser. In our case, this is alleviated by our separating items from the diagrams into defined locations - so any such presentation items would be moved to the appropriate folders - where you still can't see them! However, because we create Neighborhood diagrams for all our items, and ensure that the diagrams are always collocated with the item, the Neighborhood diagram acts as a suitable proxy for the item. So while the items aren't visible directly, their diagrams are. (We use the same technique for other items that aren't normally visible in the browser)
We have also investigated creating WIDE connectors to be more prominent. Again, while there are issues - they only seem to work well with certain line styles. They seem usable.
The reason for this email is to get any feedback before we embark on a serious attempt to create such presentation models and diagrams from our rigorous models.
Thoughts and suggestions welcome.
Paolo
