Establishing external and internal consistency is necessary but not sufficient for models validation. The former deals with the mapping of actual objects and processes into symbolic representations, the latter with the consistency of symbolic descriptions in terms of references and compatibility across structures and stereotypes. Yet, the semantics of modeling languages usually make room for different understandings, including mistaken ones.
The rationale behind the proposed validation procedure is that flawed models have no proper shadow, in other words there is no valid alternative. Clearly, the procedure cannot be used to establish the validity of a model since that would assume that true solutions always have shadows. But it may provides a litmus test to decide between two options if a shadow exists for one of them and not for the other.
Spotting false representations
Given a set of actual objects and behaviors, modeling languages, like any languages, usually make room for different formulations. Whereas the validity of the syntax can be established, that’s not the case for the semantic contents. Yet, if truth cannot be demonstrated, falsehood can, and one way to do that is to look for shadows.
Commonalities and variants can usually be represented differently, as illustrated by <include>, <extend> and inheritance connectors between use cases. Given the variety of interpretations, some alternative representations should help to eliminate misunderstandings. That is essentially the principle behind the substitution (aka Liskov) principle applied to the modeling of objects.
According to this principle, a given set of instances described at a specialized level should be described equivalently by any level above. For instance, a set of customers and suppliers can be described as such or lumped together as business partners.
If identified independently, instances of customers and suppliers can be represented indifferently as an aggregate of parties or as two specific sets (a). But if a base class is introduced the number of instances will be different if the subsets overlap (b). The same test will fail for opposing reason when describing persons and organizations by subclasses of a concrete Party base; in that case there can be no overlapping but Party should be abstract because one may assume that there can be no party without the prior existence of a person or organization (c).
The same principle may be applied to behavior, as illustrated by the modeling of use cases variants. Assuming a preference for <include> and <extend> connectors over inheritance, one may use inheritance as a shadow option to decide when <extend> may be used instead of <include>.
It must be reminded that shadow models can only eliminate wrong options, it cannot not tell the right ones. One way in that direction is to distinguish between objects and aspects and apply inheritance selectively to objects’ intrinsic features on one hand, aspects on the other hand.
Occam’s Razor: Spotting inefficient representations
Applied to system modelling, Occam’s razor principle is to select the competing construct that use the fewest number of artifacts and constraints when the constructs are equally correct in describing the set of objects and behaviors under consideration.
Taking example from internet forums, groups may host discussions, each discussion being assigned to one and only one section with the possibility to be moved. Introducing specific classes for each section is not necessary as there will be only and only one instance of each for a given group. Moreover, it will be necessary to introduce an additional constraint for the mandatory link from discussion to section.