A common theme to the examples in the Reading Diagrams posting was that great diagrams have a small numbers of abstractions. Indeed, they are made great often by what bits of the real-world they choose to miss-out.
I’m going to refer to these not as ‘abstractions’ – it makes them sound, well, abstract, but as “Ideas”, because then I get to define what I mean.
Consider a really simple UML Use Case diagram:
There are Actors and Use Cases, and Actors can use Use Cases. I make this a single idea, because it includes notions of what an Actor and a Use case are, and what the link between them means.
There’s a second idea, buts its such a small and simple one, that I don’t think this is a 2-idea diagram. The Use Cases are contained inside a box, which represents the software system we’re thinking about. So maybe this is a 1.5 idea model.
But there’s more we want to say in our modelling work.
We’ve decided to store the Issues which exist for our project in the model as well. That way, they can be linked-up to the relevant Use Cases or Actors.
Which is fine, until we add them to the diagram:
The diagram is now definitely > 2 ideas.
But now we’ve got started, we can tell ourselves that we need to create a one-stop diagram, which will really help people to understand these Use Cases in their wider context. So we add some more stuff:
We can add information about which stakeholders represent which actors, and which people in the project team ‘own’ which of the issues.
We’re now well over the line in to a 4 or 5-idea model.
Sure, it’s a one-stop diagram, but we’re asking a lot of our readers here.
Perhaps we might keep this as a diagram just for private use, and instead create several smaller diagrams which have a smaller number of ideas:
- The original diagram: Use Case & Actors and the system boundary
- One which shows who represents which actors
- One showing the Issues, and their related model ‘thing’ and who owns them:
With this diagram, our layout is totally different.
We are focused on a single idea: the Issue. Issues are owned by people, and they relate to some aspect of the main model. So this is still a 1-idea model.
Idea-heavy Modelling Languages
The example above is an easy one to fix, because we took the UML-defined idea of a Use case diagram, and added our own bits to it. So we can just as easily remove those bits to get back to a 1-idea diagram.
But what if the language we are using is idea-heavy? A modelling language which fits this description is BPMN.
This is a OMG way of describing business processes, and it’s an accurate way of saying almost all we need to say about processes. But that accuracy comes at a price. Lots of ideas.
Here’s a typical BPMN process.
What we;re trying to says is:
- The order processing department (Lane) Process Orders (Activity), when they Receive an order (event).
- The QA department (Lane) then check the order (Activity) and if its ok (Decision) then the order is complete (End type Event)
- If its not OK, then they send an order rejection (‘send’ type Activity) to the Customer (Black Box Pool) via a Message (Message connector) and throw a Bad Order Created event (‘error’ type End Event)
And this is a really simple diagram. We have not said what types of Activities they are – BPMN has 8 types. Nor have we specified the data objects which are passed between the Activities, and this is a really useful aspect of BPMN.
So the very richness of the language creates its own challenges for the modeller: how to keep the number of ideas as small as possible to help the reader. (there’s an example of simplifying a giant-sized BPMN diagram in fixing a look-at-me diagram/)
Something else which I first saw in the BPMN notation was the idea of adding lots of types to ideas, and making that part of the visual representation. For example, BPMN has 8 types of Activity:
This is the precision of BPMN at work. Each of these different types of Activity means something slightly different. ‘Send’ Activities should have a Message connector going from them, and will only go onto the next Activity once that message has been sent. So they are useful but they contribute to the basic complexity of the language, and therefore to the number of ideas which appear in any given diagram.
As a rule, I tend to avoid using ANY of these types on ANY diagram: I’d much rather use a note linked to a ‘normal’ (BPMN “abstract”) Activity:
I’m making a deliberate decision here to exchange accuracy for readability. The readers of my process diagrams night not know that the little person in the top-left of an Activity box means ‘Manual Activity’, but the little note makes it obvious.