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

Principles 1-7
Principles 8-15
Modelling Patterns

Principles (continues)

#8. STP return types

The majority of the business rules will have the following return types:

bulletTRUE/FALSE for evaluating a condition or for testing successful execution (for doers), or validation (for validators)
bulletVOID where the outcome does not impact process control

This is consistent with the STP process, whose main objective is not to pass information around, but to drive the fairly atomic business rules through the process

#9. Navigation

In collaboration classes will access another classes responsibility via structural navigation (e.g. ClassA.ClassB.doSomething())

Three exceptions to this are:

(a)    The request class will be passed around in scope for many classes. This is to be expected as it is modelled as a boundary class

(b)   Iteration/Classes operations will pass the currentClass to the scope of the iterated class/concrete

(c)    STP manager will pass the exception handler the object that has failed.

In the above two cases the object will be present in the argument. For clarity this will be shown as aRequest or current<<X>>

#10. Atomic business rules

The purpose of this methodology is primarily to express business rules in a logical way - that promotes their accuracy and relevance to all stakeholders both technical and business. Although OO techniques are adopted, it prime purpose is NOT to produce OO design. It is foremost an analysis tool that happens to be adaptable to OO techniques. 

A good example of this principle in action is with bloated business rules. It can be tempting to treat a single operation on a class as doing for all processing and validation of that class - fine from an OO perspective if that class has the responsibility for doing these things. However from a business perspective each part of validation may be a discrete rule to them - and whilst the information is still there - some of the graphical impact has been lost.

This does not mean that there must be a 1-1 relation to the type of business rule found in an XL document and an operation e.g. if a validation check is to check both X and Y then OK to have both wrapped up in one operation.

For example if a valid short name must be unique and less than 21 characters it is probably enough to have a single rule for “validShortName” rather than “validShortNameLess21Char” and “validShortNameUnique” (unless there is a business expectation that these are separate).

Where it is not acceptable is say if one rule is covering both validation and mapping, or if both validation rules are quite different or for different purposes.

So each group of related business rules should have its own operation.

A rule should be cohesive - and consistent to its type governed by its naming convention - so a do<<X>> rule should not do validation (outside of what is considered a successful process- i.e. can return fail if it encounters validation issues, but should not do validation itself)

This also helps

(a)    business review since the operation is more in line with what a user would expect a rule to be.

(b)   It also makes pseudocode simpler with less nested ifs and complex logic.

(c)    makes changes more localised

...... even if not necessarily the best from a purist OO approach!

Atomic business rules worked example

Take the following rules

BRUL1: to validate A need to do X

BRUL2: to validate B need to do Y

BRUL3: a successful maintenance is to ensure A and B are valid

(a)    A specification with poor cohesion could be:


IF (

    // some validation of X

    // some validation of Y






(b)   A better specification would be:


// some validation of X



// some validation of Y



IF (

    validA() == TRUE

    validB() == TRUE







Why is the first case bad?

(a)    if the conditions are quite complex, it could be difficult to spot individual rules out of the pseudocode.

(b)   it is not cohesive - as well as processing there is validation

(c)    decoupling of validation rules promotes reuse - and isolates future changes

(d)   each operation is a discrete business rule - conforming to the principles of this methodology


#11. Control flow in the sequence models

Interaction can be shown as asynchronous (half arrow) or synchronous (full arrow). This means slightly different things in the analysis domain as it does in the physical domain - since the emphasis here is on process control.

Asynchronous in this context means that the flow of control can carry on - in practical terms this is used where a failure in one operation does not impact another, or if there is no implied order in which things are done.

For example setting shortname, longname and fullname are not dependent on one another. Failure in one does not prevent attempting the next one (but will still cause an exception). Therefore these operations can be asynchronous.

Conversely, if setters have the additional responsibility of ensuring what they set is valid (see protected vs. private pattern example) then whilst the setter is asynchronous, the validation cannot be - since the setting will not be complete unless validation is.

#12. Class operations

Class operations are performed on the class rather than on an object. This means that responsibilities can be invoked on an object that has not been created yet! This allows the useful technique of giving some classes the responsibility to know when they should be created.

#13. Business rule specification - pseudocode

Pseudocode is used to specify business rules. This can make things look "complex", so why is this a good thing?

(a)    If the analyst cannot express the rule's logic (or define the rule's "contract") in a structured way then this is probably not a rule - rather a fuzzy principle that needs some further thought.

(b)   By forcing a structured approach to the specification that is coherent (i.e.. uses and refers) with the model it exists in it makes both the model and rules more accurate - thus avoiding lazy modelling or rule specification.

(c)    Given the problem domain is for reference data the STP process will be mainly about data reference or data manipulation, specification of both of be useful require a high degree of precision

#14. Attribute stereotypes

Given that the classes themselves are not being persisted beyond the life of the STP transaction (including error handling), it is useful to identify what the attributes are for. This is shown by the following stereotypes:

<<RC>> Received from request for process control

<<RP>> Received from request. Attributed persisted to database

<<RA>> Received from request. Association persisted to database

<<DC>> Derived from database lookup for process control

<<DP>> Derived from database lookup. Attributed persisted to database

<<DA>> Derived from database lookup. Association persisted to database


bulletProcess control attributes are NOT persisted beyond the life of STP iteration (account)
bulletEnsure all persistence attributes are referenced in the mapToDatabase() operations


#15. Attribute values on boundary class

The boundary class in our example is the class Request. Given the role of the boundary class is to act as a bridge to the outside world, it’s job is not to validate what it gets, but rather to just accept as much as possible – i.e. it should not filter rubbish data.


Therefore attributes on these classes are typed to string, regardless of expected value since this can accept any value, both valid and invalid.

Back Next

© 2002-2007 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: