Preamble
Guises may differ but software apart, there is no serious engineering without comprehensive and consistent modeling; nowadays leading engineering firms are even able to subject symbolic artifacts to actual tests. The main reason for software engineering lagging the pack is models’ unreliability.
Given that, whatever the correctness and consistency of engineering processes, the quality of outcomes is to be set by the quality of inputs, the use of models (if any) is generally limited to downstream software design. Upstream, the integration of software engineering processes depends on the ability of analysis models to consistently capture the business objects and activities that would be represented as system surrogates.
That can be achieved if the layered approach is used to extend the scope of the Liskov substitution principle, already the cornerstone of model internal consistency. Those principles can be put in action using shadow models.
Sub-type Semantics
According to the substitution principle, the semantics of a description must remain the same at any level of abstraction it appears. Applied to software artifacts it means that if S is a sub-type of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.
The same reasoning can be used for the modeling of business objects and activities if, instead of instances of programs, one considers instances of business objects and activities as defined by requirements.
As formally defined by modeling linguistic foundations, objects and activities specified by requirements can be mapped to running of programs. Roles and partitions should be used to lay the ground for abstractions, but as far as requirement are concerned they should be understood as leaves which means that descriptions without extensions (aka abstract tree nodes), are useless and to be avoided.
As a matter of fact, abstract descriptions in requirements may well introduce flaws into analysis models, since their sub-types will lack the common identification mechanism needed to anchor business contexts to system representations. For instance, if standard and scythed chariots are sub-types of some abstract chariot, a versatile chariot will have to change its identity when fitted with scythes, even if the representation of the same chariot at root level will use only one identity.
That is only to remind two basic principles regarding system modelling:
- Sub-typing can only be applied to symbolic objects: it is meaningless for concrete ones, for which one can only use subsets or partitions.
- By definition, abstract descriptions cannot be mapped to identified business objects.
Those principles can be used to check the consistency of analysis abstractions compared to variants in objects and activities as described by requirements.
Identities vs Aspects
Physical or symbolic, objects and activities are set by concerns. Some may be local to enterprises, some defined by common business activities, and some set along a broader social perspective. While the continuity of business objects and processes has to be supported by consistent and comprehensive identification mechanisms, that’s not the case for roles and features whose elements and semantics may differ with concerns and be adjusted to changes in business opportunities.
External consistency should therefore distinguish between identities and aspects:
- Identity (aka structural) consistency is managed by domains in charge of objects life-cycles (create and delete operations) and identification mechanisms (fetch operations). That would target objects, agents, events and processes identified by business processes independently of supporting systems (a).
- Aspects (aka functional) consistency is managed by domains in charge of aspects (read and update operations). Roles and features semantics defined by use cases (b) will have to be rooted to (aka identified by) primary objects or processes.
That distinction can be used to unify external and internal consistency providing a distinction is made between structural inheritance (d) and functional inheritance (c).