Option D: Formal ACM
Purpose: To ensure that any information
relating to static elements is specified within Rose, using the analysis
class stereotypes, described centrally in Rose. Soda can present these
ACMs as part of the Use Case document.
In semantics this approach is no different
to the previous option. What differs though, is the ACM becomes a
deliverable in its own right, and is centrally maintained in Rose. As new
terms are identified in a use case flow, they must be first evaluated
against what is already present in the model.
In addition, attributes are added to
entities, to describe in logical terms the information needs of these.
Example of
enriched formal ACM
The ACM offers the designers at the end of
elaboration an enterprise view of architecturally significant terms,
derived directly from the use cases. This should provide sufficient
context in which the designers can define their separate design model.
Another purpose of a formal analysis model
is to close the gap between any underlying reference data and the business
understanding of it, and then to tie this with the use case deliverable -
i.e. creating an abstract description of this data for mapping and
validation purposes.
The importance of this point could tip the
balance between the informal approach above (which does not support this)
and the approach described here.
Advantages
 |
Enterprise view of architecturally significant terms that
cuts across Use Cases
|
|
Moving away from reliance of just “word” artefacts to define
scope of analysis promotes a higher quality, more robust deliverable to
design team.
|
|
An ACM without design terms should prove a cycle independent
deliverable as it is not tied to the implementation or solution.
|
|
Will act as reviewable bridge to implementation persistence
model.
|
Disadvantages
|
Formal ACMs inevitably evolve into design as the cycle
matures (without appropriate checks and balances), and as they a slightly
further removed from the Use Cases, such trends become harder to resist.
|
|
Producing the “perfect” ACM becomes an disproportionate
activity of the analysis team (becomes introspective)
|
|
Even where separately defined design model is enforced, in
practice it is hard to validate the trace from design and analysis views,
with the consequence that the ACM becomes sidelined.
|
|
Version control
|
|
To mitigate the above requires greater maintenance and
control – possible a full time role.
|
Option E:
Sequence
model
Purpose: To ensure that
terms described in the ACM have their responsibilities defined by using at
least one sequence model per Use Case.
This extends the formal ACM. For each use
case, ACM terms impacted by it are shown in one or more sequence models
(depending on complexity this could be one per flow – although for simpler
use cases these could be combined).
: Example of
sequence model
Advantages
|
Description of responsibility as well as association and
attributes makes the ACM “complete”
|
|
Very useful for testing purposes
|
|
Restores coupling between Use Case and terms described in a
formalised ACM.
|
Disadvantages
|
The structure of this artefact means that slipping into
design mode is very difficult to resist (for example in the above example
contextual information must be shown to come from somewhere to make the
model complete. However the decision to make the log-on screen the
boundary for this is a design decision)
|
|
Can be expensive to produce as at the very least it will
require one model per Use Case
|
©
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
