Scope
Rules can appear everywhere, under any guise, targeting anything. In other words one have to be prepared for the worst before expecting a nice and clean formulation. If such ubiquity and diversity is to be dealt with, it is necessary to circumscribe rules footprint on models and organize them depending on their impact on functional architecture.
Objectives
Whereas business rules can come in manifold configurations, it may be helpful to identify patterns and redefine rules accordingly. As already mentioned, rules can target activities and/or symbolic representations, and be applied backward as constraints or conditions, or forward, as alternatives or triggers.
However tangled and poorly formulated, rules make the fabric of requirements, but once reset within analysis and design models, they are often melted with connectors (references, flows, or transitions), or encapsulated as methods within objects. Finally they may even reappear under their native guise when implemented with rule engines. This ubiquity can be very challenging for system analysts and designers. Hence the importance of characterizing rules depending on their possible impact upon system architecture.
As far as architecture constraints are concerned, local rules could be ignored since they can be implemented (and hidden) by object structures and should not affect system architecture. Representation patterns should therefore distinguish between rules bound to persistency or execution units, and those scoping units features.
Regarding modus operandi, rules can be grouped into three categories:
- Computation rules, for rules dealing with the neutral processing of symbolic representations; they leave them unchanged and don’t affect the state of agents expectations.
- Backward (aka pull) rules are constraints on the consistency of symbolic representations or on the execution of activities. Impact on system behavior, and derived architectural constraints, can be precisely demarcated beforehand.
- Forward (aka push) rules are conditions on when and how activities are to be performed. In that case possible rule impact, and derived architectural constraints, cannot be fully ascertained before the rule is applied.
Regarding targets, whereas conditions can be attached to any elements, the objective is to distinguish between symbolic and actual footprints:
- Rules conditioned on actual objects cannot be managed directly since actual states can only be known through events (forward mo) or polling (backward mo).
- Conditions on symbolic representations may be used for integrity and execution constraints (backward) or cascading updates (forward).
- Conditions on interactions deal with access management (backward) and dialogs (forward).
- Depending on the nature of change signaled by events, conditions are to be evaluated instantly (forward), or checked when required (backward).
- Conditions on the results of symbolic computations provide the building blocs of algorithms (forward), but may also appear as preconditions (backward).
- Conditions on the state actual processes are used to control execution paths (forward) but may also be used as preconditions..
The objective is to define rules based on representation patterns in order to identify their impact on system functional architecture.
Rules Representation
First of all, rules must be set within the model driven development framework, i.e their specification is to be blended with diagram constructs. Whereas tools like Object Constraint language (OCL) may be useful, they only support a shallow integration with models and don’t deal with rules semantics. In order to achieve deep integration, rules specification must be anchored to architectures and model artifacts, i.e their composition should be organized along basic architectural tiers and models artifacts: local object, connectors, containers, power-types.
- Local rules are concerned with individual features. They can be enforced by objects, persistent or transient, independently of architecture mechanisms.
- Cross objects rules involve several objects and must therefore be associated with collections or connectors. Their management may have to be supported by architecture mechanisms.
- Domain rules are set by business units. They potentially apply to all types of objects falling under such authority and cannot be attached to specific collections or connectors. When possible they should be associated with symbolic partitions (power-types).
- System rules are set at corporate level and cannot be attached to specific domains or business units. When possible they should be associated with symbolic partitions (power-types).
Backward rules: Constraints on Persistency
Constraints on persistent representations are not necessarily limited to persistency units and may also be associated with events, roles, or activities. When the semantics of targeted artifacts are local, reference constraints can be described by composition at structure level; otherwise, i.e when constraints are set across domains, they must be described by partial or join identification along connectors.
- Integrity constraints: invoices are identified by customer and repairs, themselves identified by vehicles. Operations are local to repairs and associated rules have no impact on architecture.
- Operational constraints deal with the symbolic representation of business processes e.g, interim repairs status cannot be recorded with some ongoing operation.
- External constraints specify the state of physical objects being represented. e.g vehicles must be checked out with full petrol tanks.
- Derivation constraints target feature dependencies. e.g repairs using imported parts must be invoiced with currency rates of the day before.
- Access rights to persistency units. eg customer accounts.
- Event constraints set how external events are to be registered, e.g check-ins must record date, time, and staff identity.
Functional dependencies are best expressed using relationships, while multiplicity and standard constructs may be used to express set-based constraints.
Backward rules: Constraints on Functional Units
The same principles apply to constraints on activities which can be associated to other activities as well as events, roles, or persistency units:
- Preconditions of activities with regard of the state of persistency units. e.g, invoicing cannot begin until repairs are fully documented.
- Operational constraints are preconditions of activities with regard of the state of execution units, i.e synchronization between activities. e.g, invoices cannot be processed with some ongoing operation.
- Functional constraints are preconditions of activities with regard of the results of execution units. e.g when repairs used imported parts, invoicing must refer to current currency rates.
- External constraints specify the state of
physical objects. e.g vehicles must be checked out with full petrol tanks. - Access rights to operations. e.g rebates.
- Backward rules about event deal with constraints about pending events.
Constraints on functional units can be refined when sequence and state diagrams are introduced. If representation patterns are used it should be possible to trace business rules from requirements to analysis and identify more precisely their architectural footprint.
Forward Rules: Computations and Derived data
Derived objects, links, and features are derived from symbolic representations. Depending on their footprint and their use, their management may induce significant constraints upon architectures, which may call for some arbitrage between stored results and renewed computation. For that purpose those rules should be organized along their architectural footprint:
- Computations performed at object level should have no impact on functional architectures.
- Computations performed on collections should be identified as such since implementation architectures usually provide for native constructs and mechanisms.
- Computations performed by activities are not meant to directly access persistency units, instead they should target transient contexts owned by activities.
- Computation rules for derived objects and features entail coupling constraints across domains. When possible, standard constructs associated with connectors should be used to convey unambiguous semantics to system analysts and designers.
For instance:
- Draft invoices are derived objects computed from repairs. Actual invoices can be established directly or from drafts.
- Links from invoices to vehicles are derived through repairs.
- The subset of customers with late payments is computed using invoices due dates.
- “Selection” is a subset of vehicles computed by a relational join from repairs (caused by accident) and customers (aged less than 25).
Forward Rules: Control of execution units
Control rules can be triggered by symbolic or actual changes or by symbolic or actual events:
- Choices made through interactions are symbolic events whose origin and semantics are set within specific activities (a). External events originate from actual objects and their semantics must be interpreted before associated rules can be applied(d).
- Changes in symbolic objects can be instantly interpreted and cascading rules applied (f). That is not the case for changes to actual objects which can only be known through polling (b), or external events (d).
- Computation rules apply to symbolic flows (e). Actual rules take into account the actual system behavior (c).
Control rules can be triggered by symbolic or actual changes or by symbolic or actual events.
For instance:
- When a customer asks for his chariot the staff looks for it (a).
- If the platform is not positioned on the floor it must be moved to it (b).
- When the platform arrive to the floor it is halted (c).
- After the customer leaves a message is sent to update the register (d).
- The registrar reads the message and perform the update (e).
- Changes to parking lots status trigger an update of vacancies (f).
Time Related Rules
Time related rules can be applied to actual contexts or symbolic representations, or both. Backward rules set conditions on execution status, forward ones are triggered by events.
It must be reminded that rules seldom appear upfront as adequate and well formed; alternative expressions are usually possible depending on functional architecture and organizational contexts. In particular, changes in process states (activity-driven control) can always be expressed through events (event-driven control).
Rules and Power-types
Since power-types describe variants of objects or activities they are prime candidates when complex rules are to be defined, for instance for construction rules and constraints.
Rules applied at corporate level, i.e across business domains and processes, should also benefit from power-types, access rights being a good example:
- Categories of users may be associated with access rights on categories of data or types of operations.
- Access rights may also be set for specific operations targeting specific data.
Similarly, control tables may be associated to power-types defined as transient objects.