Refine responsibilities – Analysis class level approach
Class level responsibilities
The classic OO approach to defining
responsibilities is first to create an analysis class model (ACM) from each use
case, by identifying conceptual entities from the flow of the use case and any
supporting business rules.
The description of how this is done is outside the
scope of this paper, but an example of inspecting the following line:
ABC generic back
office system calculates the
risk both from the companies and the counterparties perspective.
By analysing our example use case this could give
the following model:
Figure 20: Example
of Static Model (Analysis Class Model)
That is, from the brief description above, it is
clear that there could be a Trade and Counterparty class, with the former having
the responsibility (“operation”) to determine limits breaks at a trade level,
the latter at a counterparty level.
The only use cases written using this approach are those defined at the
enterprise level – i.e. treating the system as a single black-box. Since use
cases lend themselves more to a black-box approach, this is arguably a more
suitable use for them.
Some pitfalls with this approach
Unfortunately what this does not give us is a
component view, and as stated earlier, in an enterprise, delivery will be
usually be through components.
The typical approach of assigning these analysis
classes to separate packages and then identifying interfaces is substandard here
since this can not occur in this stage of the project lifecycle.
In the analysis class only approach, the
“enterprise” is treated as a single building block which makes this approach
very suited to traditional use case modelling, where the system is treated as a
black-box, and the only actors are those who sit outside of the system. However
the issue with this approach is that it is too blunt a tool for architects and
planners. To ignore component responsibility this at the early stage is a loss
of opportunity to explore the early integration and validity of an prototype
|Responsibilities given to the wrong component causing poor
cohesion (sledgehammer packaging at class level is very ambiguous with this
|Responsibilities just don’t join up with the components suggested
by architecture. This is a very bad situation since components can have separate
management structures associated with their build and can be outsourced. A very
costly error to fix.|
|Components may not completely “own” an analysis class (since these
are more akin to conceptual/domain level – i.e. not fine grained). Therefore
usage of operations may be split over several components.|
There may also be cases where it is undesirable to
treat use cases as black-box, in cases where there clearly isn’t a single
system. In such cases some form of component based consideration is unavoidable.
If it is an objective of looking at the integration of two
separate initiatives serving two clearly different parts of the business – but
nonetheless need to work together and integrate in order to be successful. Such
an system cannot be treated as a single enterprise because it isn’t – it has
separate accountability and budgets, and likely analysis teams. This would be a
good case for modelling each as a system with there own system level use cases.
An integration between financial control and product control (two discrete
departments with a fair degree of dependency) or a merger are some good examples
If the organisation structure forces a non centralised analysis
team. For example if TM and RM both have own analysis team (perhaps there is a
good reason if the expertise that not that transferable), then this would likely
be carried forward to the build of the components to support these functions.
However it is always best to avoid this where possible.
Importance of enterprise view
Focussing only on analysis classes will mean that
there is no enterprise view of the problem domain. The purpose of enterprise
modelling is to have some understanding of the suitability of the architecture
to support the problem domain. This is not possible without the component
A component view is important as it shows
architectural impact – and allows in planning phase to elicit architecturally
significant use cases in a way better than guesswork.
Just using the black-box end-to-end use cases is
difficult to plan an iteration, since an iteration should be based around
component delivery. Since in an e2e use case different parts of the use case
will be realised by different components it is in itself an unsatisfactory way
of planning an iteration. In elaboration there must be some way of mapping this
to components and used this as a basis of the iteration plan.
The following section describes a combined approach
that takes the best features of OO modelling and combines them with the
innovative component modelling that forms the backbone of the methodology.
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