The difficult concept of MODEL

The concept of model has become very popular and thus the meaning of the term has be contaminated or at least watered down. The more general and fuzzy meanings are associated with a term the less that terms really  communicates anything. (see wiki:

A Oxford dictionary entry of the term model:

  • a simplified description, especially a mathematical one , of a system or process, to assist calculations and predictions:

So (at least for me) a model is a simplification of some part of reality. In this way there is some kind of mapping from reality into the model. This contains model “semantic” or “meaning”. So formally

For all x from {SubReality} is f: f(x)-> m from {Model} ; where f is a homomorphism but not isomorphism onto Model.

If the mapping is allowed to be isomorphic then the model is without simplification (1:1). This could theoretically be possible but gives no real value as model.

Thus this axiom implies disappearance of detail. This way we lose the part of semantic information that we have. The amount of the lost information is controlled by the level of abstraction of the model. The whole point of modeling is this reduction of detail. This is done to understand the structure and the behavior of a complex target domain. In this is vitally crucial to destroy part of the detail to reduce the complexity of the essential things.

A user has to understand the relationship between application window and reality. This is exactly the domain model. When I am making a flight reservation I must understand the correspondence between an airplane leaving from Helsinki airport to London and the following text:
AY5905 HEL 07:50 LHR 09:00
This means that I have to have the model in my head.
Now from a model like this about 50% of the middle tier implementation can be generated. The reason is most simple: because that is all the information that this model has! The entire application tier have to be understood, design and implemented. Here the model has nothing to offer.


16 Responses

  1. I think that a scientific version is more this one

    reality –> model –> application

    I suppose there is only one reality but many representations of it (models) and from a model it is possible to produce many applications; a model being indeed an abstraction of the application.

    It is curious to remark that the 2 extrema are looking more to real things than models, and thus that a model is closer of reality than a real thing constituted by an application.
    But is software real?
    for me, yes but we have to confess that it is a rather dematerialized reality.
    However, energy is also a form of dematerialized matter. And processes can only be represented by some kind of description:
    I call this phenomenon: objectification of event or action (or process,…). A phenomenon appearing too in OO.

  2. And a paradox is that a model can be seen at the same time as an abstraction of the application and of the reality.

    Then an application is a real thing partially implemented a part of the reality while being part of the reality.

    Then the relationship are: reality –> (Model, Application) and Model –> Application.

    These 2 comments don’t allow to understand more closely what reality really is. It is the human tragedy.
    Reason why I believe more and more that intelligence is also a part of the reality, allowing to give us some understanding and control on a deeper and deeper abstraction of reality.

  3. A model doesn’t necessarily imply loss of detail. It’s not a model of reality, but a model of a system or process (taking the dictionary definition). Who’s to say how much detail there actually is in a system? If the model is used to fully implement the system, e.g. via a code generator, then there is no lossiness. If the model is just used to plan, think about, or waffle about the system, it probably is lossy.

    Any model only carries information content if we know the language it is written in. A language has a concrete syntax and semantics (and normally for ease of understanding, an abstract syntax). For languages used to implement systems, the semantics is normally operational semantics, e.g. in the form of a code generator (plus the underlying framework, language and platform that the generated code runs on).

    A system description is thus composed of a model plus its language. We can choose how to divide up the necessary information between the model and the language. Building a Domain-Specific Modeling language allows you to make a given system or set of systems most efficiently, by moving the optimum amount of information from the models (of which there are many) to the language (of which there is just one).

    By the way, “Gödel, Escher, Bach” is recommended reading for anyone wanting to think about the differences between models, systems, languages and reality (whether or not connected with SW development).

    • Your comment:
      “A model doesn’t necessarily imply loss of detail. It’s not a model of reality, but a model of a system or process (taking the dictionary definition). Who’s to say how much detail there actually is in a system? If the model is used to fully implement the system, e.g. via a code generator, then there is no lossiness. “

      My whole point (see my ADDD in nutshell) is that the model to be worth of something must be a model of reality NOT of the system. By the model we understand the reality. As the model it is and OO-model it can be more or less directly implemented (the things that are in the model).

      • At the start of the day, the system doesn’t exist – i.e. it’s not part of reality. The purpose of the model is to (help) bring the desired system into the surrounding reality. Therefore the models are models of the system; of course once the system is finished, it also has a reality, and the models describe it. But at least for MDD, as Ed’s excellent article points out, when we make the models we’re making them as specifications, not as descriptions.

        Just to avoid any misunderstanding: I think the language of the models should be the language of the problem domain (e.g. forms, fields, rules), not the language of the solution domain (e.g. classes, attributes, operations, methods, SQL tables). So when I talk about modeling the system, I don’t mean modeling its implementation, but rather modeling its desired behaviour.

      • I seem to completely disagree with you.

        “Just to avoid any misunderstanding: I think the language of the models should be the language of the problem domain “

        I 100 % agree.
        you continue:
        “(e.g. forms, fields, rules),”

        Rules form and fields could not be further away from the domain!

        “ not the language of the solution domain (e.g. classes, attributes, operations, methods, SQL tables).”

        Here you seem to confuse totally metamodel (classes, attributes, operations, methods, SQL tables) and the model. For instance in airline model the model entities are for example the classes like Airport, Flight, Participation, Airplane, Version etc. and departure time, arrival time, seat number and behaviour like addPassanger(), reserver(), toGate() and so forth. (see my example Airline model: )
        And by the way SQL is needed for nothing at all.

        “So when I talk about modeling the system, I don’t mean modeling its implementation, but rather modeling its desired behaviour.”

        I think that your sayings and doings are in vast contradiction.

        I understand the world as follows:
        1. We analyze reality and it brings about a model of realty , which of course is abstract by definition.
        2. Then we design new reality called Application. This is blueprint of the implementation.
        3. Then we implement the design. These steps 2 & 3 are so complex that they cannot (be humans) be done one after another (called waterfall) but incrementally & iteratively

      • It’s fine to disagree! I imagine it’s more because of different experience, and the difficulty of talking about this just in text, than because we both know the same things but come to different conclusions.

        You say I’m “totally confused” about the difference between metamodels and models. I find that unlikely. Similarly, a “vast contradiction” between my “sayings and doings” isn’t something I get accused of in this space. More likely is that we’re not quite understanding each other, perhaps?

        Rather than responding in kind with loaded words like “totally” and “vast”, I’d prefer it if we could just leave this conversation as it is. Hopefully we’ll get a chance to meet up at some point and build up a better shared understanding.

        All the best,

      • I share you point of view. It is VERY difficult in general to achieve any substantial progress in trying to bridge wide conceptual gaps by sending emails! It would definitely require a face-to-face communication! I agree it is not fruitful to continue this way. I do appreciate your comments and even as we did not agree upon anything I think it still gave other readers wider perspective into this matter.

        I just MUST touch one thing before ending. It is this question of metamodel and model. I think this is in the deepest core of this modeling. My point was that as classes, attributes, etc. gives the form for my model when we do modeling with business people we are ONLY concerned of the domain concepts like i mentioned: Airport, Flight, Participation, Airplane, Version etc. and departure time, arrival time, seat number and behaviour like addPassanger(), reserver(), toGate() and I will take care that those consept and their relationships get the form of OO-model. Then I teach my business people to read the OO-form enough to tell me if the model is wrong (in contradiction with reality)at some places.

        (I have studied formal mathematics at Turku University for 5 years ages ago and it helps me)

        Best regards
        -jukka t

  4. The idea that a model is a simplified description of reality is basically right as the term is often used. But there are some important differences between how the term is technically used in the engineering, scientific and mathematical communities.

    I wrote an IEEE Software article on this a few years ago called “What Models Mean”, (There is a free version available at

  5. In system theory the definition of a model is: “A model is an abstraction of reality for a particular purpose.” If the model can describe reality with sufficient accuracy to answer the question asked about reality, then the model meets all the requirements for that purpose. Adding more details to such a model would generally have a negative impact on this analysis.
    If on the other hand we press the abstraction of a problem into a particular form of an existing model (we may have an existing solution for such types of models) and make the necessary abstractions purely that it fits this model form, experience has shown you will not make any progress in this field (we find a few thousand papers of this type in the literature every year).
    Model based development has been used for a few thousand years and developed from model e.g. of ships, houses, … to mathematical functional models, to functional computational models.
    Computer based model based development started with Conrad Zuse’s development of computers to automate execution of models in aircraft aerodynamics and structures in 1936 (good displayed at Aerospace Museum at Washington D.C.)
    With introduction of digital electronics in aircraft in the 1980th like F-16CD, model based SW development, including formal methods for testing, was introduced.
    With the introduction of networked systems with more than 100 electronic control units (ECUs), like in the B777 in 1990…, in addition to the functional behavior, the performance behavior became critical elements. Performance level executable models of the overall system, driven by realistic usage/traffic models became the key element to solve integration problems already in the specification and design stage and to avoid expensive redesigns during integration.
    The key for risk and cost reduction is to validate as early as possible in your design with executable models. Some DoD projects require this nowadays already during the proposal phase -esp. for network integration. If you do not do this your proposal is considered to be toooo risky.

    • Very good comment !

      My experience of building application over 30 strongly supports the idea NOT analyzing old existing application. In most cases those contains so much “noise” that it is counter productive to do it.

  6. […] article exposes the difficulties to understand the concept of model. It is a very interesting article […]

  7. I agree with Horst Salzwedel but would take it a stage further “A model is an abstraction for a particular purpose”. I think making statement contain ‘of reality’ is limiting and poses the philosophical question of what reality is. Purpose is paramount. There is a great danger in using a model created for one purpose for a different purpose. e.g A map of the London Underground System is a model which is designed to allow one to navigate the underground. However it one tried to use it to measure the distance between various stations the model would fail, since it is not to scale but diagramatic.

    • Hi Phil

      I agree with you and your example about the tube is very good. The purpose of the model is important but I would like to be more precise in wording and call it viewpoint or direction of abstraction. The abstraction it pure simplification and then it is utterly important to know the aspect of the usage of the model but tis is slightly more general than the purpose.

      I still want to clarify my term “reality” or “world”. I have been studying theoretical philosophy at Turku University ages ago. And I 100% agree with young Ludwig Wittgenstein when he describes philosophy 99% as conceptual misunderstanding meaning most of it is just plain bullshit.

      My “reality” of “the world” tries to make a separation between the “objective” structure and behavior of the reality and organisation “subjective” usage of this all of which is behavior in the “application tier”. For instance all reporting and finding information is not part of world and thus is not present in the abstract model. So when a person is making a flight reservation with a reservation application he will first find departure airport and airline company and the he will proceed to the date and the result in the flight candidates for his reservation. This all is outside of my “world”. The he steps into “the world” by asking the real event objects of the world – namely the flight objects do they still have free seats. If the answer is positive from some then he can ask this particular flight object to create a participation event connected to that flight for him and to provide him a seat number as a side effect as well.

  8. From a systems point of view I agree completely with your analysis of the reservation system . However the objects in your world have attributes which are predicated by their purpose. e.g I may in one system have an object called a Car. If I am the DVLA I will need attributes such as owner, colour, Registration etc.

    If I define a Car in a car manufacturing system (e.g for Ford) I will need completely different set of attributes.

    Thus the purpose of the Model for Car Licensing or Car Manufacture determines what is needed in the model i.e. the purpose of the model determines what is in the model.

    One can of course have different views ( models) of the same object. (e.g a house). Depending on the purpose (e.g. To sell it to you a Salesman will present you will a magnificent picture, and possibly floor plans showing the dimensions). All of this to encourage you to put a deposit on the superb dwelling. 😉 – his purpose.

    At this stage you could easily ask for a door to be moved to another location. If the salesman wishes to sell you the house badly enough, it can easily be changed on the plans. Heaven help you, if after it has been built, you want to change the location of door – this will cost you an arm and a leg.

    The same is true of Computer systems. This is why we need to draw the plans, using models first, and get them agreed. At that stage changes are relatively easy.

    However the same house may have a wiring diagram for the electrician. Since the purpose of the plan is different then the plan will differ in many respects. There will be some ‘interfaces’ with the Salesman’s floor plan i.e the dimension of the rooms etc. The purpose of the plan determines what is in it.

    Any thoughts?

    • Well it is a fact that the modeling needs simplification. My experience of more than a hundred cases indicates that we can easily reach a model with considerably small amount of attributes during the analysis phase. As we proceed to implementing the full blown application the number of the attributes in classes increases average perhaps from double to ten times. This is why I promote an iterative approach were in analysis phase only those most important attributes are included.

      Of course the thing that you describe happens if we add point of views in single model. My practical experience show that one can “overload” a model with several viewpoints, but that will evidently lower the level of abstraction and increase amount of detail. In most businesses how ever the fact is that the number of radically different viewpoints are really rear. This meas that in average the businesses that people really do are very simple and I have not yet got this kind of a challenge in real modeling situation. I’ll hope I’ll will if there exists one out there!

      Is this an answer?

      -jukka t

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

%d bloggers like this: