Option C: Initial Analysis Class Model (ACM) - aka “robustness
modelling”
Purpose: To ensure that any information
relating to static elements is specified within Rose, using the analysis
class stereotypes, described directly against the use case (in the tree
view). Soda can present these ACMs as part of the Use Case document.
The prime purpose of this model is validate
the flow, and to provide an alternative graphical representation of both
the dynamic (the relations between the classes) and static (the analysis
classes) nature of the flow. Where used for this purpose the ACM does not
have a life beyond a cycle and is imbedded in the use cases (i.e. classes
not reused beyond scope of individual Use Cases).
If option A or B is not used, then the
description part of the analysis class is to be used.
Although the term “throwaway” may suggest a
poor return on investment, it acknowledges the fact that in reality even
formal ACMs “evolve” into design as the cycle matures, losing its original
analysis semantics.
5: Extending the previous example
The model should only describe things that
only appear in the flow, with active terms (such as rules and other
business logic) described controllers, and structural terms as entities –
but using the same terminology as used in the flow.
Conversely, the contrivance of controllers
such as describing things as “XYZ Manager” (as in the following example)
is not acceptable if it does not accurately depict what the flow of the
use case is doing, as this exercise should describe the “real world”
domain rather than along the path of a proto-design system domain.
Therefore if controllers are to be introduced they should avoid ambiguous
terms such as “Manager”; “Processor” or “Administrator”.
: Example of ACM contrivance
The interactions between the entities can
also be named to build an active narrative.
If it appears that the ACM cannot be written
without adding additional classes, then the flow must be updated
accordingly. If a whole new “branch” is identified in the ACM then this
would typically necessitate an alternative flow.
: Example of identifying
alternative flows
Advantages
 |
Simple to produce – does not require
stable baseline |
|
Provides a visual way of validating use
cases |
|
Genuine analysis activity – describing a
flow using non-word format prevents laziness in describing flow of
events |
|
No danger of ACM “evolving” into design
model |
|
No maintenance issues |
|
Good at spotting genuine alternatives: for
example the above example demonstrates that failures in authentication
have not yet been considered by flow. |
Disadvantages
|
Throwaway nature hard to justify |
© 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
