Flow Proliferation
It is common to use alternative flows to describe all
logical outcomes of a step in a use case.
example of alternative flow proliferation
| |
Main flow –
User authorised
4.
System retrieves Profile for the supplied Electronic
Identity.
(Alternatives: User provides incorrect
identity less than the maximum limit; User provides fails to log on
exceeding suspicious threshold limit; Secondary profile; Cannot
retrieve profile; User moves organisation) |
|
Whilst this is semantically correct this can lead to
a proliferation of one-line alternative flows. Also each of these flows
are relatively simple, and all are saying the same thing that validation
failed. Since the interaction is not different in such cases is better to
wrap these up as one use case, and to describe the logic around this as a
single or rationalised set of business rules. This way the dynamic nature
of the use case is much more apparent, and therefore easier to review.
rationalised example
| |
Main flow –
User authorised
4.
System retrieves and validates Profile for the supplied
Electronic Identity.
(Business
RuleXYZ. Authentication Count Rules)
(Business
RuleXYZ. Authentication Validation)
5.
The system establishes the entry is correct.
(Alternative: Failed Authentication) |
|
As a guideline do not use alternative flows if both:
 |
The interactions are identical |
 |
The same actor is involved |
For example with a trade management use case involved
in trade acceptance the first step should mention that an Actor – business
portal – sends a message to the system. An alternative flow for manual,
automated and contingency files are not necessary since for trade
management’s purposes the interactions will be different (a different
story in the case of business portal), and the actor is the same. However
it would be acceptable in the triggers section of the use case to mention
that this could be triggered in the case of manual, automated and
contingency files.


Although in the case of security these goals can often be the mitigation
of key, named risks.
©
2002-2005 Codel Services Ltd
This paper has been prepared
by Codel Services Ltd to illustrate how structured business
modelling can help your organisation. Codel Services Ltd is an IT
Consultancy specialising in business modelling. If you would like further
information, please contact us at: Deryck Brailsford, Codel Services Ltd,
Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom.
Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: info@codel-services.com