Approach - Enterprise elaboration
The main purpose of elaboration, is to build on the
framework set up in the planning phase.
There is a decision to make as to how the model is
How responsibilities are assigned (at the analysis class or
component level) and what is done with them.
How is the enterprise to be treated – black box or system of
Whilst this decision should be made on project
initiation, its effects are mainly felt in the following elaboration phase.
These approaches are described in turn, firstly
taking a pure component view, followed by a analysis class centric view, and
finally a hybrid approach that leverages benefits from both.
Regardless as to the decision the methodology can
bring real benefits, but with a slight different approach for some artefacts.
This is summarised, outlining the pros and cons of each method, and when each
should be considered.
Refine responsibilities – Component level approach
To first understand how a component view is taken
is to understand that a responsibility on a component can be described as a use
case where the system boundary is set at the component level. An initial
component level use case model is relatively straightforward to produce, and has
the advantage of being coherent to the end-to-end scenario.
Prototype use case model
Compare this model with figure 8. Since this is the
inception phase it is enough to treat these as initial use cases – that is a use
case model (with component scope) and brief description of the goal of the use
case is enough. Where it is difficult to define its goal, the chances are that
the responsibility is incorrect or too detailed.
The challenge is for the “extending phase” type
projects, since there may well be a use case model already defined. In such
cases this will form the baseline for the following analysis activities
(assuming it is accurate – not always the case). If these use cases have a
reference number, it is recommended that the responsibilities are traced to
these rather than reverting back to the original name since this may not be
verbose enough for our purposes. The mapping should be one-to-one, if it isn’t
then the original use case model may be not as goal driven as was hoped!
Note that the use case names do not have to be the
same – they are often more process orientate and thus less verbose.
Figure 14: End to end scenarios with
use case references
Note that even for changed use cases, adopting some
of the conventions of the initial use case may still be of benefit to show the
potential impact of change.
The initial responsibility specification can then
easily be converted to an initial use case description, applying any use case
mappings as appropriate in the inception phase. Such specifications will then be
extended in this phase.
Figure 15: “Initial” component use case
[Changed: UC244] Apply
validation rules for new products
The goal of this use
case is to select and apply the appropriate validation regime to apply for
the new equity products
Goal: Increase number
of trades that can be accepted
It is important to understand that whenever use
cases are used at the component level, they individually lose some of the
end-to-end nature, so it should be demonstrated that they map to an overall
end-to-end scenario. If the are self contained specification then build teams
have lassitude in finding the correct design and implementation for them, they
should not take a lead in their definition as the likely consequence will be use
cases that do not interrelate.
Detailed component level use case descriptions – some pitfalls
In the elaboration phase these initial use case
descriptions can be extended to become a full use case narrative, using any use
case description template (your organisation is likely to have one)
Before considering writing component level (or
white box) use cases at this level a number of potential pitfalls with them
should be considered before deciding if it is the right approach to elaborating
Firstly they can be hard to write without straying
into detailed design, and their narrow scope makes them difficult to review (see
separate paper on this as to how to avoid some of these issues.)
However most importantly, it is hard to produce an
analysis class model to support use cases at this level. In the following
neither component has a full view of trade, lets say A references it and B
persists it. Trade would have to appear in both analysis class models but with
different responsibilities. By fragmenting the analysis class model at a
component level difficulties are introduced (again this is best at enterprise
Figure 16: Issues with component level
Agile component level use case descriptions
If the issues described in the above section are
likely to be a problem, then instead of using the standard use case description
template, use cases can be described in a more logical manner.
Once the responsibilities have undergone peer
review, as an optional exercise these can be enriched with additional
information. Whilst such activity can be time consuming it can force a level
discussion on what such responsibility actually will entail, and whether it is
the appropriate place to do it.
Take for example the Trade Management
responsibility from our example “Accept Trade ( )”. In order to fulfil this ask
what information Trade Management requires knowledge of and posses in its own
right. Something along the lines of “Swap Trade Details” would suffice. This
leads to the following benefits:
|Correlates to business domain model. |
|Boon for testers in preparation of test data from end to end
|Helps component use cases elaboration since this is either a
business rule or a supplementary requirement|
Trade Management in our scenario does not contain
the validation rules, since the architects deemed these best managed centrally.
So it does not have knowledge of these – hence the subsequent collaboration with
Reference Data Repository. Our specification now becomes:
Reference Data Repository::Provision of new product structures and new
instrument types(Equity Trade Details) = Valid Equity
So what is being said here, is as long as reference
data repository is given the trade details, it can use its knowledge of the
validation structure and return equity validation structure. This process can
become very powerful, and can be an alternative to component level use cases
(and still avoids being design) – but on the downside it does require a degree
of modelling competence.
[Changed: UC244] Apply
validation rules for new products
Validated Trade Details
Repository::Provision of new product structures and new instrument
types(Trade Details) == Valid Equity
Analyse component responsibility cohesion
Of course in this contrived example it is
suggesting that Trade Management is not actually having the responsibility of
actually doing the validation, rather reacting to the results given to it (i.e.
perhaps it Reference Data Repository should return the Trade Structures and
Trade Management decide whether it is valid or not). We are having a very
precise definition of responsibility that cannot easily be misunderstood,
something that could happen if responsibilities were just defined on the basis
of name. This is highlighted in the following two figures:
Figure 17: Poor
Figure 18: Better
This is exactly the sort of discussion that should
occur early in the process since errors here can have profound and costly
consequences later on.
Static model (component knowledge model)
Following the analysis described above can lead to
a clear picture of what each component needs to “know”. This can be shown
diagrammatically in the following figure.
Component knowledge model
This static view is easily created from the models
we have already – in fact it can be considered a “free” by-product of them. It
gives a useful in the following ways:
Gives a complete picture of scope to the component teams
Something that will be very helpful for determining test data and
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: firstname.lastname@example.org