Design Principles
Home Business Change Analysis & Design Agile Testing Templates About us

Design Principles
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:

bulletpre/post conditions (i.e. a contract)
bullet 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?

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....." 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:

bulletController - 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).
bulletEntity - Main purpose is to persisted what it owns - controllers delegate persistence to its constituent parts, which are set as entities
bulletBoundary - 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: