Over the last few months, I’ve visited a couple of customers who were each having trouble with packages: one had lots of what they called Use Cases which were really Packages, and the other had lots of Packages which were really Processes.

Their reactions to finding out that maybe this wasn’t the best way to structure their models was also instructive, but more of this later. First the problems:

Elements which are Packages

First, the Use Cases which were packages. This is a fairly common beginners error, and usually means the modeller hasn’t quite understood what a Use Case really is: One Person, One Place, One Time. So their first model looked like this:

bad use cases

Ue-case experts will be shouting at their screens . ” How can  a Use Case be called ‘Customer Management’ – it doesn’t start with a active verb!”

So clearly these higher-level blue blobs aren’t Use Cases at all – they are groups of other use cases. But these were smart people, and they knew about functional decomposition, so this looked right to them. Then we talked about what a Use Case was, and we decided to change to something more normal:good use cases

Hopefully most people would agree that this looks more like a Use Case model should. The strange ‘use cases’ have become packages – just groups of other use cases.


Packages which are Elements

Now the opposite case. A process model, created by some very good BPMN process modellers, who somewhere took a wrong turn. bad processes
So here the problem was reversed. They had somehow decided that there was such a lot of ‘stuff’ under ‘Configure Widgets’ that it must be a Package. That made his documents look really neat as well.

But it’s not: Configure Widgets is a Process, and should be made into an Element (a lower-level ‘thing’ in most tools, which is a child of a Package). So again, we had a chat, and decided to change to something more ‘normal’.good processes
In both cases, I made the argument that it matters how models are structured. These will be viewed, used and changed (hopefully) by many people over many years, so making them conform to what most people will expect to see is really useful. In both cases, they could have happily continued modelling in their original style, and still satisfied their own projects’ needs. But future viewers would be confused.

Different Reactions

So far, this is a minor modelling point, and maybe not one which you care about too much. But what made these two events memorable was the differing reactions of the two teams.

One – the Use Cases team – was very reluctant to change their model. It had been produced by several people over many weeks, and had 100’s of use cases. Changing it would be hard (it wasn’t, as it happened – we wrote a little EA script to fix it).

The other team also had lots of processes, listened to the arguments, and immediately decided to change to a more ‘normal’ style.

Now I wish I had a neat theory as to why one team was reluctant to change, and the other not. The ‘process’ team had much more modelling experience than Use Case one, so maybe they felt they understood the argument better. The Process team had already been given lots of feedback on their model, so maybe they were happier to take external suggestions: the Use Case team were blazing a trail for model-based development, so hadn’t had much external feedback.

My learning points – which I’m going have to apply to my own models 🙁   are therefore:

  1. Don’t get too attached to your models. It’s just a way of writing stuff down, not a part of your soul. You’ll leave them behind anyway some day. It’s not personal.
  2. Get other people (who know something about modelling) to look at your stuff, as often as possible. They may know even less than you, but two pairs of eyes is always better than none. And the less they know, the more chance they will ask the ‘stupid question’ which turns out not to be.

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.


  1. How very recognizable. I’ve seen both situations and advised likewise. One thing we did different was to put each process in its own package because that was more convenient for locking. Apply user lock on a package will lock all owned elements of that package. Apply userlock on an element wil only lock that element, and in order to add or delete something you need a lock on the parent package anyway.

%d bloggers like this: