Order-Dependency Between Use Cases

Source: otug@rational.com
Date: 10-Jan-99

Related Sites


o-< Per-Olof Strand asked:

[...] we have some use cases that need to be done in a specific order, i.e. use case A has to be done before use case B. How is this expressed in UML?


o-< Huseyin Angay replied:

If there are ordering dependencies between use cases, it is better to show these within one use case that <<includes>> or <<uses>> (whatever) these use cases. Call this a sequencer use case, if you want.

[...] if you have use cases following each other, you have actually broken down a single use case in the DFD fashion.

And why is this not good?

It is not good because it gives you stove-pipe use cases. Each use case relies on something else happening before it. You cannot introduce anything into the middle without disturbing the sequence, whereas having separate use cases makes it look like they are independent and leaves you open to that sort of error.

The sequencer use case solution solves this by centralizing the control of the sequence. The use cases that are being sequenced can now be used in other contexts -- something you could not have done with nose-to-tail use cases.


You might have four use cases called:

Issuing purchase order
Receiving the goods
Receiving invoice
Printing cheque
Now, I assume that the system has a hand in this sequence, say, because it is a robot that receives goods! [...] I also assume that having those use cases on their own also makes sense, maybe in the context of a manual process where the operator takes care of the sequence and uses the system at appropriate moments.

Anyway, my sequencer use case might look like this.

Chasing order:
System issues a purchase order. {Issuing purchase order}
When system receives the goods, it handles it as in {Receiving the goods}.
When system receives the invoice for the goods, it handles it as in {Receiving invoice}.
The use case ends when system prints and sends a cheque for the invoice amount. {Printing cheque}
Apart from the name Sequencer Use Case, there is no rocket science involved, really.



o-< More Info:

Alistair Cockburn, Structuring Use Cases with Goals

Alistair Cockburn, Writing Effective Use Cases

Geri Schneider, Jason P. Winters and Ivar Jacobson, Applying Use Cases: A Practical Guide