Refine responsibilities – Combined approach
If there is a desire for a strongly defined
enterprise component level view, but without losing the OO nature of a
enterprise analysis class model, then a hybrid approach can be used that
satisfies both these issues.
Objectives of a combined methodology
Is it appropriate to do design in the inception
phase? The short answer to this is no – unless it is to prove an architecturally
significant (and limited) area. Early design, when it gets ahead of requirements
nearly always causes problems, since it prejudges what the requirements are, and
can cause unnecessary constraints.
Given this argument, is therefore enterprise
analysis design and therefore inappropriate? The answer to this is no – there is
no technology dependency – the only dependency are the architectural building
blocks (“components”) which may be as equally led by commercial and legacy
reasons as by technology.
An issue with component level use cases is that is
hard to write these without entering into some form of design mode, whereas with
a Analysis Class Model (ACM) approach all issues of design are avoided. However the ACM approach has
been shown to promote lazy architectural decisions and has difficulty in
integrating and adapting to the architectural vision.
The answer to this is that both of the above
approaches are correct, but from different perspectives. The challenge therefore
with a model-led approach is not to have two separate visions, but one single
vision that is satisfactory from both perspectives.
How use case realisations are refined in a combined approach
With the combined approach, the ACM to used to
identify domain classes and their responsibilities in the standard OO manner.
These are then assigned to the component
responsibilities identified in the end-to-end scenarios as an alternative to
describing these as component level use cases. This is shown in the following
two figures.
Figure 21: Example
of Static Model as from Analysis Class Model approach
These responsibilities (i.e. class operations) are
then assigned to the components using the className::operationName notation, as
shown in the following example:
Figure 22:
Assigning analysis class operations to components from end-to-end scenario
By forcing a mapping of how components are using
these responsibilities in joined up way forces the enterprise analyst to
challenge both the prototype architecture and the completeness of
the responsibilities themselves. If the responsibilities cannot interact with
one another in by the components offered then either the choice of components
are wrong or the ACM is wrong.
This works best where the operations on the ACM are
described in a verbose manner. Readability is enhanced if these interactions are
aligned to the same (enterprise) use case narrative defined earlier.
It will be also easier to derive interfaces at an
early stage be using the dependency model, and to show which classes and
operations these support.
Figure 23: Showing
analysis model responsibilities on component interfaces
So in conclusion, in the inception phase start off
with a set of interactions that make sense from the description of the use case
(since at this stage you are unlikely to have the ACM and its responsibilities
set up at this stage). These are kept at a high level as described in section 3.
Then as part of the elaboration phase these are “turned” into interactions as
shown here, with the high level verbose named moved to documentation of the
operation in the analysis class model.
These operations can then be specified using pseudo
code in the construction phases. Some examples of how pseudocode is used is
shown in the Codel Service’s Rules Based 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: info@codel-services.com
