Preface. To distinguish conceptual object from physical object on the three spaces
These days, Udi Dahan spoke on his blog post that “Don’t try to model the real world, it doesn’t exist.” so, “Model the perceptions – at least you can have first hand experience of those.” I agree the speech about such the customer or product were not the “real” world things (or clearer, not physical objects) but perceptions, even there were different interpretations by different stockholders.
This issue involved indeed in to some of quite common confusions. This is why I emphasize the Three Spaces: Conceptual Space, Computational Space and Physical Space, and sorted the entities and their models (which are also some entities in the three spaces) into the three group (see the figures): such as, for a model in the computational space (a computational model), its object (the entity it modeled) may be an entity in the physical space and may also be in the conceptual space; for an entity in the physical space, it may be modeled in any of the three spaces as a conceptual model, a computational model or a physical model.
I’m not sure this is quite consistent with Udi’s ideas but I think it will be clearer to analyze modeling on the three spaces, I illustrated the example on the three spaces in Figure 1.
To an application for business that supporting the human work/transactions, almost all the objects it deals with are the entities (concepts) in the conceptual space but not the physical entities. In other words, the meaning/rules to the objects are dependent on humans (the stockholders). For computational models, there are typically two of the situations as shown on the Figure 1. One, the Class-of-Customers in comp-space is a model of the Concept-of-Customers in conceptual space; the real customers in physical space are the instances of the Class-of-Customers and the Concept-of-Customers. Two, the digital orders may have never with a physical one, is the instance of the Class-of-Orders in the same space, the computational space, and is also the instance of the Concept-of-Orders. This is my version that “model the perceptions”, that is, model the entity in conceptual space: the concepts.
But the physical object can not be ignored, too
Nevertheless, it is not ignored that the objects in physical space. As appeared in the Figure 1, a conceptual entity may also (in fact, usually) have the corresponding physical objects. But, indeed, the relationship between them — such as the Class-of-Customers and the Concept-of-Customers with the real customers — is not a model-of relationship but both instance-of. That is, such as the class of customers, indeed, not be modeled on the physical objects, even some ones have no corresponding physical objects.
Being the case, what is the relationship to the physical objects, in our context? For example, typically, see Figure 2. The data e.g. (35629, ‘TY’, ‘China’) conform to the Class-of-Customers e.g. (ID, DisplayName, Country) is the model of the real customer; a program may deal with such the situation: one can hard code the rule that shift to display in zhCN if the Country = ‘China’ (of course it may be a poor cording but a good example).
On the other hand, software may also be working with a model of some physical objects alone. For example, consider an auto-pilot system for interplanetary rocket, it would be had the built-in models of some galaxies and physical theorems, and has nothing to that whether the models was constructed by human or Martian while it is working. The interpretation of the models is dependent on the correspondence to physical space but not the modeler or user.
There are the model muddles for computing
It seems that Udi’s post has attracted quite a few of eyeballs. I think one of the reasons may be that it touched some fundamental question in the mind of many people. It may be called model muddle. The phrase ‘model muddle’ was introduced by Marx W. Wartofsky, for some issues about the concept of model in science. I think it is also a very relevant and interesting topic in the context of software or systems engineering and applications, or say, in computing. Wartofsky attributed the model muddle to “an ontological muddle — regarding on the one hand the status of the entities we call models, and on the other, the status of what it is they are models of.” I think, the question such as “does model the ‘real’ world things / physical objects or the ‘perceptions’?” is involved in to the status of what it is they are models of, and the question such as “are programs models?” may be involved in to the status of the entities we call models.
There is an another case on the objects/models in OOA and OOD/P. the question such as, is an object or a class in OOA or OOD/P a model? if so, what is the object (entity) it is model of? and, what is the same and difference between the a class (such as the Class-of-Customer) in OOA and in OOD? In my observation, it may often be seen that some developers done a discussion or argument about the related topics, e.g., on the phrases such as ‘problem domain’, ‘solution domain’, ‘domain models’ or ‘business objects’ and so on, in the contexts such as DDD, MDSD, but had always been ignoring the existence of these fundamental problems.
In Kaindl (1999), he firstly defined the deference between OOA model and OOD model, and argued that “an OOA model cannot simply become an OOD model.” The difficulty is “caused by the fact that OOA and OOD objects represent inherently different things.”  I suspect that if it got enough attention to such the early work? Moreover, recently read on the Caminao’s Way, it stated for UML that “Yet, from inception, the semantics of objects were not clearly defined, when not explicitly confused under the label ‘Object Oriented Analysis and Design’ (OOA/D). In other words, the mapping of business contexts to system objects, a critical modeling step if there is any, has been swept under the carpet.” The similar issues, can also be found on some discussions about the concept of abstraction, such as the confusion to that “software is abstraction of the real world vs. software has abstraction of the real world”.
In my opinion, from the fundamental questions such as “what is a model?” or “how does a model work?“, we still have a lot of work to do; have a lot of “simple” problems can be solve in practice, and it will able to derive great benefits.
 M. W. Wartofsky, “The model muddle: Proposals for an immodest realism (1966),” in Models: Representation and the scientific understanding, Dordrecht: D. Reidel, 1979.
 H. Kaindl, “Difficulties in the transition from OO analysis to design,” Software, IEEE, vol. 16, no. 5, pp. 94-102, Sep. 1999.
Updated on 09 Mach 2012
– Changed the title from “The Model Muddle for Computing” to “The Model Muddle on Computing”.