Sharing habits

Over the last few weeks I’ve been trying to help two different teams of modellers get organised to that they can share their models better- in one case, within a team, in the other, with other teams.

I’ve been concentrating initially on what I call the ‘mechanical’ aspects of the models: what classes & stereotypes, which connectors, which attributes and tagged values, all using our new Model Expert tool.

This gives some really useful insights as to where people are modelling differently, but mechanical differences are only the start of the story. For sharing and re-using models, conforming to the same mechanical (meta-model) standards is necessary, but nowhere near sufficient. For that, we need to look more at the general style of a model, beyond just the simple mechanics.

Style is everything

This is hard problem. Each of us modellers use our own style. Occasionally, we meet other modellers who have different styles, and this can be an interesting experience, when we become aware of all those little habits we have picked-up over the years. These might not be deeply technical.

For example, I always draw Use Case diagrams with a boundary box (The System), user actors on the outside (left hand side) and any system actors right hand side. Oh, and I make the arrows go from the initiating actors to the use case. And I never use ‘extends’ because I can never explain it to novice users.

So quite a few little quirks.

And these work beautifully in most situations, producing simple, easy-to-read diagrams. Or at least, that’s what I think. Well, I would, wouldn’t I.

Over the last few weeks however, I’ve come across LOTS of examples of other ways to do this, which make perfect sense to their authors, and perfect sense to me. For example, what about when you have a Use Case diagram where a single actor does lots of use cases?

Using my way of doing things, I get an untidy diagram, which is hard to read.

..whereas my customer drew this below:

Which if you absolutely MUST draw a diagram to show these relationships, seems much clearer than mine, albeit with a little less information.

This is just an example of my style of modelling vs. theirs. We both had mechanically identical models: we both used the correct types and stereotypes, and both use the same connectors. But we produced models which felt and looked very different.

 

Examples, good and bad

The only solution to this seems to be to have lots and lots of examples for new modellers to look at: both good examples and bad, so they can work out how they should model their particular bit of the problem. Oh, and tell people the example exist. Then tell them again, email them a link to them, and talk about them in your next team meeting. (getting the theme here yet?) And show everyone that you’re keeping the examples up-to-date with everyone’s  latest thinking – not just yours. These examples are a shared piece of knowledge.

This seems dull, but really is the only way which seems to work. In one case, the team have done a wonderful job of creating a intranet site, which hits and tips, examples, all kinds of great stuff, alongside other essential project information – so its get viewed a lot.

The other team have some examples, but they are currently buried in a separate model, away form the main shared model, and they have so far been created by a single individual, albeit a very skilled modeller.

I know which solution i’d bet on to deliver a consistent modelling style