In my previous post on "Modeling Illusions" I distinguished between the illusion, manifested by a domain model, and the model that does the trick, the realization model. The interesting question is: How do these two models relate to each other?
If I managed to explain things well, you should have understood that both models implement the same interface and that they behave exactly the same for an external observer. Otherwise, it would be useless to talk about an "illusion". From the outside, there is no way to tell which model is actually operating "behind the wall". From this viewpoint, both models are interchangeable.
Note that this statement highlights a very crucial point. If you cannot say what's behind the wall, you experience and develop a consistent mental model of the interface and it's behavior from the outside. We call this mental model the user model of the interface.
So we are having three models: From an external viewpoint, we have a user model a user associates with the interface; it is the user's perception of the illusion. Behind the wall, from an inner perspective, the interface is either implemented by a domain model, describing the illusion from an inner perspective, or by a realization model, an alternative description for the illusion.
The relation between the models is as follows: In terms of size, better: information content, the following formula holds:
user model <= domain model < realization model
Ideally, the user model and the domain model match. However, the realization model must be "bigger" than the domain model. Both, the domain model and the realization model, must have the capability to generate the same external user experience. But there must be more to the realization model. Otherwise why should you call it a realization? You could also say that the realization has more information content than the domain model by definition.
From a software engineering standpoint, the realization model should be developed in such a way that it can be easily verified against the domain model(!). It should be easy to show that the state model the realization model implements includes the state model of the domain model. Alas, this is not standard practice. Only very few software engineers know and understand the cascade of these three models: user model (external interface experience), domain model and realization model (alternative interface implementations). To distinguish and actually use domain and realization models is a very powerful technique to manage complexity. This technique is, however, of limited use, when there is no way to show that the realization model actually realizes the domain model.
There are some techniques around to keep the realization and the domain model "in sync". One is to use generative techniques to generate the realization model out of the domain model (catchword "Domain Specific Modeling"). Another is to use Aspect-Orientation, which enables a designer to add realization aspects to an domain model. Formal methods may help prove that the realization model is consistent with the domain model. So there are some important tools around in the toolbox of a software engineer.
By the way: User models are crucial in (User) Interface Design!
If I managed to explain things well, you should have understood that both models implement the same interface and that they behave exactly the same for an external observer. Otherwise, it would be useless to talk about an "illusion". From the outside, there is no way to tell which model is actually operating "behind the wall". From this viewpoint, both models are interchangeable.
Note that this statement highlights a very crucial point. If you cannot say what's behind the wall, you experience and develop a consistent mental model of the interface and it's behavior from the outside. We call this mental model the user model of the interface.
So we are having three models: From an external viewpoint, we have a user model a user associates with the interface; it is the user's perception of the illusion. Behind the wall, from an inner perspective, the interface is either implemented by a domain model, describing the illusion from an inner perspective, or by a realization model, an alternative description for the illusion.
The relation between the models is as follows: In terms of size, better: information content, the following formula holds:
user model <= domain model < realization model
Ideally, the user model and the domain model match. However, the realization model must be "bigger" than the domain model. Both, the domain model and the realization model, must have the capability to generate the same external user experience. But there must be more to the realization model. Otherwise why should you call it a realization? You could also say that the realization has more information content than the domain model by definition.
From a software engineering standpoint, the realization model should be developed in such a way that it can be easily verified against the domain model(!). It should be easy to show that the state model the realization model implements includes the state model of the domain model. Alas, this is not standard practice. Only very few software engineers know and understand the cascade of these three models: user model (external interface experience), domain model and realization model (alternative interface implementations). To distinguish and actually use domain and realization models is a very powerful technique to manage complexity. This technique is, however, of limited use, when there is no way to show that the realization model actually realizes the domain model.
There are some techniques around to keep the realization and the domain model "in sync". One is to use generative techniques to generate the realization model out of the domain model (catchword "Domain Specific Modeling"). Another is to use Aspect-Orientation, which enables a designer to add realization aspects to an domain model. Formal methods may help prove that the realization model is consistent with the domain model. So there are some important tools around in the toolbox of a software engineer.
By the way: User models are crucial in (User) Interface Design!