you're reading...

The Model Muddle on Computing

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.”[1] 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.” [2] 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.

[1] M. W. Wartofsky, “The model muddle: Proposals for an immodest realism (1966),” in Models: Representation and the scientific understanding, Dordrecht: D. Reidel, 1979.
[2] 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”.

About TY

interested in models & modeling, software, information systems, applications & engineering for enterprises


5 thoughts on “The Model Muddle on Computing

  1. Ty, speaking of perceptions, I would like share my understanding of Udi Dahan’s blog. I believe that in his post Udi Dahan talks that a physical entity may have different perceptions by different stakeholders or at different times. In my experience these perceptions are roles of an entity depending on its direct relations to the context. (conceptual roles are a core of Object Relationship Modeling method and also can be found in the least explored corners of UML.) If this interpretation is correct, then these roles are typically occur in conceptual space. What do you think of this understanding?

    Posted by Andriy Levytskyy | March 9, 2012, 04:51
    • Hi Andriy,

      “I believe that in his post Udi Dahan talks that a physical entity may have different perceptions by different stakeholders or at different times”
      — totally agree, but I didn’t think that is the main issue. Just as you said, these are roles (e.g. customers, products, and it’s some relevant to the ‘model as use’) in certain context for an application. but I think, the certain context for an application including *both* the roles (i.e. the entities) in conceptual space (my specified in the specification of requirements) and computational space, for business, e.g. the Figure 1,2 would be regarding as a part of the context to an app. and in addition, for some app such as auto-control, it would be different and it is an important difference, I think.

      BTW, I’m very interested in the ORM but didn’t hear about it for a long time :-) Once I asked for this on a forum which had some talking on modeling, and be kicked out, because they couldn’t tolerate such a naive question: didn’t know what the Object Relationship Mapping was, their God. :-D

      Posted by TY | March 9, 2012, 14:18
  2. Ty, believe that roles are typically used within the same abstraction/modeling space. E.g. a glass can be a product, a liability and a container. Within a modeling space, roles capture some “differentiating” knowledge about a system under study. It is also possible to use roles across modeling spaces, but in this case their roles are pretty “generic” (e.g. an instance and a type for relationship instance-of between real customers and concept of customers), and thus are often used implicitly. If I am not mistaken, you focus an entity, its different manifestations in modeling spaces and relationships among those manifestations.

    BTW, I made a mistake about ORM (should not post late at night) – I meant ORM as in Object Role Modeling (http://www.orm.net/). Sorry for the confusion :)

    Posted by Andriy Levytskyy | March 9, 2012, 15:32
    • This is very subtle. (I increasingly feel that my English as a barrier though I’m learning.) It may need to take more thinking carefully to your comment.

      I’m just aware of some subtle difference in my position while doing some conversation about such the topics.
      My concern is firstly focus on the software at runtime: its relationship with the outside world, as well as the runtime mechanism of the software (e.g. the model driven mechanism). so I’ve been always stressed that the software >has< the model of the external thing.

      P.S. There was not misunderstanding to the ORM you mentioned, I like Object Role Modeling. What I said above was a past story of me about that one day I misunderstood the ORM as Object Role Modeling but they were talking about Object Relation Mapping…

      Posted by TY | March 9, 2012, 16:28
    • Andriy,

      Basically, I would rather don’t use the word ‘manifestations’ here. It seems some of problems may come from me: some words seems not clear (or some mistakes), such “including *both* the roles (i.e. the entities)”, “my specified in the specification of requirements” (it should be “may specified …”)

      I meant that, when an application is running in an actual context of business, both the entities (conceptual and computational, as well as physical) are existing at the same time. For example (shown in Figure 1 and 2):

          – A real person TY is a physical entity in physical space, who is (may be) played as a role in the business (the context of application);
          – A role customers defined by such the business staff, is a conceptual entity in conceptual space. The concept customers is indeed an entity in human brain, or some business documents (i.e. some parts of conceptual space);
          – Further, there is a class (or type) in the application system (may be a class ‘Customers’ in an OO style system, or an entity type as a definition of a table ‘Customers’ in a database) which is corresponding to the role customers in the business;
          – Some data may be added into the app system, which is of the customer TY, this will build an computational entity in the computational space: as an object (a instance of the class ‘Customers’), or as a record in the table ‘Customers’). Notice that, this is the model of a physical entity (the person TY).

      (the usage of ‘entities’ as well as ‘object’, see this post)

      In the Udi’s post, he point out that (in my understanding) some thing such ‘customers’ in an app, was not a “real” word (physical) thing but a role interpreted by some humans, so we ought to model the perceptions. But, at least, it seems not very clear to state that how (whether) model (or don’t model) the physical thing. So, I tried to illustrate that — based on the three spaces — how to model both the perceptions (conceptual entities) and the physical objects (physical entities), as well as the computational entities (the models), and their relationships.

      Posted by TY | March 11, 2012, 00:48

Leave a Reply

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

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s



Subscribe notifications of new posts by email.

Join 62 other followers

%d bloggers like this: