activity diagram tutorial part 3
DESCRIPTION
Activity diagram tutorial part 3 shows why you should ignore variable details such as data and business rules when modelling.TRANSCRIPT
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!