Shadow Models


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.

Shadow Models try to  sidetrack representations (Magritte)

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

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

A shadow model can be used as a litmus test 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.

Occam’s Razor will stamp out redundant thread descriptions

Further Reading

4 Responses to “Shadow Models”

  1. Will Says:

    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.

  2. caminao Says:

    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. Will Says:

    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.

  4. caminao Says:

    Indeed, one should be clear about what is represented by models, and that point has already been clarified by philosophers and mathematicians.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Your content with a new angle at

IT Modernization < V.Hanniet

About Information Systems transformation and Model Driven Engineering

IT Modernization < V. Hanniet

software model driven approaches

Caminao's Ways

Do systems know how symbolic they are ?


Get every new post delivered to your Inbox.

Join 411 other followers

%d bloggers like this: