Activity Diagram tutorial part 3

Using Activity Diagrams toModel Use Cases Visually

Part 3: Ignoring the Variable Detailsby Declan Chellar

Our activity diagrams model the Actor/System

interactions within a Software Use Case.

In this example, “Add Address”, we model only the logical interactions between

the Actor and the System

There may be variations in the kind of data that makes up an address, for example,

addresses in different countries…

…but those details are documented as part of the data requirements for the

relevant step.

And they should not distract from the logic of the

process itself by appearing in the activity diagram.

The same is true for any business rules which might affect the flow.

Or any messages that the System might need to display to the Actor.

This activity diagram tells us the essential nature of the

process without clogging it up with data options, business rules, button clicks and on-

screen messages.

Any of those things can change in the future without the proces s

itself changing.

But analysts who lack experience in drawing activity diagrams often treat

every possible data and screen option as if it were an alternate path

through the use case.

Imagine we could capture two types of address in our use

case: An Irish address, which does not use post codes, and

a UK address, which does.

Modelling those data differences as alternate paths results in a much more complicated activity diagram, which is

harder to follow without really providing any extra information.

Very inexperienced analysts sometimes even try to model the capture of every item of data as a

separate step in the process!

If we modelled our activity diagram like this, look what

would happen if we had to add a third address type…

By the way, if your activity diagram contains alternate flows hanging off alternate

flows, it’s a sign that something may be wrong.

Another mistake is to try to model each data/business rule/screen variance as a

different use case.

This adds effort to the modelling task without adding

clarity. Indeed, it reduces clarity and increases maintenance and

development effort.

When you model it this way, it doesn’t matter how many different address types get added to the data model, or whether

the definition of “Valid” changes or whether the on-screen messages change.

One thing needs to remain absolutely clear…

This is not an alternative way of

modelling a use case…

It is plain wrong!

This is not an alternative way of

modelling a use case…

It is plain wrong!