Straight-through-processing, by its very nature a more technology
focussed activity than is typically found in analysis domain (such as when
writing use cases). The analyst should be prepared that their role
involves a substantial design element. However there are many pitfalls
associated with early design, primarily that of losing sight of what the
real requirements are.
It is therefore important to provide a set of design ground-rules to
ensure that this does not happen, and that any design performed is
suitable for the analysis domain. If the following principles are adopted,
you will have a model that is extremely powerful at presenting design to
end-users.
Design Principle: Business rules as operations
Is what is shown in the model a business rule or an operation? It is
actually both, allowing the benefits of UML to help add structure,
precision and versatility as to how business rules are specified.
Actually since we are in the analysis domain, it may be more helpful of
understanding operations as responsibilities.
So what is so similar between business rules and operations? They both
have:
 | logic |
| pre/post conditions (i.e. a contract) |
| arguments |
| reference
to other conceptual entities and/or collaboration. This is usually
implicitly inferred in a model – but why not make explicit - since this
makes the model tighter? |
| hierarchies/inheritance/polymorphism |
Treating them as operations also them be shown in sequence models to
show collaboration. This also emphasises encapsulation as well, where
collaborators need only know what their friend class is doing - but not
how it is doing (i.e. whether that class can expedite its responsibility
on its own or requires further collaboration)
Effectively such sequence models are a visual way of describing the
traditional “CRC card” (Class responsibility collaboration) scenario!
Design Principle: Rule Inheritance and Polymorphism
Business rules often have an
implicitly polymorphic nature - i.e.
"validating a bond is a bit like the generic debt
validation rule except....."
.....is probably the most compelling
reason for modelling business rules as operations, since this structure
can be modelled very well using inheritance. These sets of rules actually
start to look like the traditional rule set approach (except our approach
is easier to review of course !)
Design Principle: Stereotypes of Analysis Class
To help developers understand what the main purpose of class is, and
also to help promote good class cohesion, the standard robustness
modelling stereotypes are used:
| Controller - Main purpose of the class is process control. A good
example would be a class where the majority of its
responsibilities (thus business rules) are around control (confirmed by
the prevalence of "do" operations on the class). |
| Entity - Main purpose is to persisted what it owns - controllers
delegate persistence to its constituent parts, which are set as entities |
| Boundary - Main purposes is to sit
on the fence between system and outside world - although this must be
taken in conceptual terms, and should not be treated as an interface. A
good example is a class that must both understand the
the language of the request (e.g. XML) and the outermost working of the STP framework. |
Ó
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
