Whatever the correctness and consistency of transformation rules, the quality of outcomes will nonetheless be set by the quality of the models used as inputs, namely requirements. In other words, no significant advance can be achieved without system artifacts being checked against their business counterparts.
As it happens, the layered approach can be 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.
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 a program, one considers a business context as defined by requirements.
As established with the layered approach of modelling, requirements can replace programs if they are restricted to actual objects and processes. Roles and partitions should be used to lay the ground for abstractions, but descriptions without extensions (aka abstract), 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 a common identification mechanism. 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 documental 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 identities, that’s not the case for roles and features whose elements and semantics may differ with concerns change with business opportunities.
External consistency should therefore distinguish between identities and aspects:
- Identities 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 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).