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.


Diagram Overloading

Consider a really simple UML Use Case diagram:

Simple use casesIt has a small number of ideas:

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. use cases (2)

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:

use cases (4)

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:issues only

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.

Simple BPMN processWhat we;re trying to says is:

  1. The order processing department (Lane) Process Orders (Activity), when they Receive an order (event).
  2. The QA department (Lane) then check the order (Activity) and if its ok (Decision) then the order is complete (End type Event)
  3. 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:

BPMN Activity Types

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:

manual 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.

About the Author Ian Mitchell

Ian Mitchell is a business analyst and software developer. He's been using UML since before it was UML, and has managed teams of BAs all over the place. He also teaches UML and BPMN, and writes the eaDocX document generator for the Sparx EA tool.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s