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:
CLASS::maintainZ()
IF (
// some validation of X
// some validation of Y
)
ELSE
RETURN FALSE
ENDIF
(b)
A better specification would be:
CLASS::validA()
// some validation of X
CLASS::validB()
// some validation of Y
CLASS::doZmaintenance()
IF (
validA() == TRUE
validB() == TRUE
)
RETURN TRUE
ELSE
RETURN FALSE
ENDIF
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
Note
