Shadow Models

Peter-Kilchmann-Zilla-Leutenegger-Sunset-Neighborhood-2009
Shadow vs Ghosts (Peter Kilchmann)

Preamble

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. Taking for granted that valid models consistently represent all individuals pertaining to observers’ concerns, that would leave room for alternatives or shadow representations.

The rationale behind the proposed validation procedure is that, while the absence of a shadow is not enough to disprove a model, it can be used to decide between two options, one with a shadow the other without.

Truth in Models

Spotting Misrepresentations

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.

MD_ShadowParties
Substitution Principle illustrated with Shadow Models

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>.

MD_Withdraw MoneyUC0
A shadow model can be used as a litmus test to decide when may be used instead of .

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: Representations & Complexity

Applied to system modeling, 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.

MD_AggegCompo
Occam’s Razor will stamp out redundant thread descriptions

Further Reading

4 thoughts on “Shadow Models”

  1. Hi Caminao,
    Continuing in the spirit of exploring intuitions I think this discussion is going to hinge on exactly what we mean by a model. What we are concerned about is that, given we have a consistent model, is the model adequate for a particular use i.e. can we express all the properties of concern of our instance domain in the model. But given any model (and this is where what we mean by a model becomes crucial), adequate or not, I should be able to construct an isomorphic model by change of data representations and claim that this constitutes a shadow model of the original. And if this is the case then shadows models always exist.

    Somehow I feel I am still not getting it.

  2. Hi Will,
    Don’t be sorry because my objective here is to test an intuition and I’m looking for help. The reasoning goes like that:
    a. A model is supposed to represent a set of instances.
    b. One may assume that, for a given set of instances, there is more than a unique apparently valid representation.
    c. If two representations are valid, there must be some equivalence to be find between them because they both refer to the same situation.
    d. Hence, given a model, the existence of an alternative (shadow) will prove nothing (false representations also have shadows), but if no alternative can be found chances are that the model doesn’t represent the targeted instances.

  3. I am sorry but I simple do not understand this. Specifically I do not understand what you mean by “a shadow” and why an invalid model cannot have a shadow.

Leave a Reply