The Model Driven Software Network

Raise your level of abstraction

A few days ago, I left a comment on Vincent’s blog, with his essay What is the focus of analysis: problem or solution? I said:

I always had some doubt to so-called ‘Executable Model’, although it seems an inevitable result in the logic of MDA, but it also like a trap: if the models are fully executable or transformable, what are the difference with programs? Why we must say they’re models but not programs? To rise the abstract level is necessary and useful but not need to rename programming to modeling… From programming to visual programming, to modeling (visually), to modeling (textually and to be executable), it seems somehow return to the origin, isn’t it?

I would have more discussion on the related issues.

Inevitability of executable models

Why I think executable model somewhat an inevitable result in the logic of MDA? Simply put, precision and formalization of system (software). In MDA Guide V1.0.1 (OMG, 2003), defined

A model of a system is a description or specification of that system and its environment for some certain purpose. A model is often presented as a combination of drawings and text. The text may be in a modeling language or in a natural language.

Notice that the description, drawings and natural language implying that imprecise or uncertain. Naturally, this seems quite closed to the strategy that partially automated code generation from models. However, I think, most people who use the models to design/implement the system directly would not be satisfied with some imprecise models which are put a great deal of effort – if so, what the essential difference with well-prepared written document?

Consequently, precision will be necessary and essential to the modeling and the models, and the exact expressions would naturally be in some formalized way, that is, programmable. Thus, the models will be able to processed by computer automatically, thereby, the first thought would be generating code form the models of the system, directly and automatically. Further, if we are able to program to generating all the executable code from the models, why we can’t construct a virtual machine to run the models directly?

Moreover, “The three primary goals of MDA are portability, interoperability and reusability through architectural separation of concerns.”(MDA Guide V1.0.1) This goals are somehow fixed on the final code, so, the modeling of software system seems have almost only one end: to make models to be executable.

If models are executable, what is the difference with programs?

My whole understanding for MDA early, was from David S. Frankel’s book Applying MDA to Enterprise Computing. He stated that:

“MDA is about using modeling languages as programming languages rather than merely as design languages. ”

I had to admit, this words left me a deep impression. Recently, in a discussion on Vincent’s blog, Ed Seidewitz emphasized that

“all programs are models. They are models of a desired computation that are detailed enough that computation may be mechanically executed.”

Of course, this is fully in compliance with his definition (2003)

“A model is a set of statements about some system under study.”

Such and such, aren’t the concept of models here very closed to programs? Furthermore, let us do some review on Fourth-Generation Programming Language (4GL), there were some key words such as higher abstraction, problem-oriented, non-procedural, declarative, defines what but not how and so on, yet, I see, almost all of the key words can also be used on the topic without any change.

I think, CASE, 4GL, and perhaps DSL, declarative programming, and so on, are all related some common points and purposes, but seems lacked certain breakthrough, all along. It seems too many concepts have the similar essentials but might have no satisfactory results. So, for the executable models, I have also some concern that whether it somehow returns to the origin, or in other words, how much surprise will it bring us? I know, there is a basic answer, that is, it isn’t go back to the origin, but to a higher abstraction level and covered more details of implementation and so on, but I want to say, maybe, perhaps, we can still go forward along the track the programming evolution, like as on 4GL and/or DSL? Meanwhile, anyway, mix up programs and models, would probably lead us miss the concerns on other important or valuable possibility.

Gain more benefits from models and modeling

In the discussion mentioned above, Ed told about another aspect of models yet, He said

“I would certainly say that there are still models that are of great interest that are not programs and may not be executable. I may have requirements models, business process models, enterprise architecture models, conceptual models, and so forth. Some of these may be ‘executable’ in the sense of simulation or enactment, but I don’t think I would consider any of them programs. ”

Such a business (process) model, or more general and clear, the models of an applied domain what the software system will work in, as a role or part — this is what my mostly interested in — to bridge applied domain with software design on models and modeling. This is a long story but first, it must be separated clearly (models of domain and of software), then, to find the exact way of them interrelated. And further, there is no simple mapping between the domain models and the software system (or its models). For this, there is a little discussion on the Vincent’s essay above mentioned firstly. Vincent use ‘weaving’ to refers the connection between them. I think it’s better then ‘mapping’, however, I think it is the nature of design of applications (software), and “as a whole, it had to be done by human-beings, unless the computer has reached a human like intelligence.”

Furthermore, These is a very different way to bring models into software applications world. The models – of applied domain – will be able to working at run-time of the software applications, while keeping the capacity that can be change (I called this model evolvability). I called this way the models work, as model-driven mechanism(MDM), the system with MDM, as model-driven systems(MDS), the applications as model-driven applications*. Compare with the model-execution, both them are use models at run-time, but the mechanism is completely different. In an earlier talk with a senior architect of software, I have distinguished as ‘execute/run models’ vs. ‘driven with models’. This is not only a theory, there are many instances in practice. Today, in this context, the best example is, the BPMS. Other classical example is the DBMS (and some sort of applications on DBMS). For the BPMS, the model is, as Ed’s comment mentioned, the business process models. And for DBMS, it is more complicated – for a clear description, it needs to define models in a more sophisticated way.


[*] I got this idea from 1999 (such the first publish and the roadmap in Chinese), yet some introduction about the issue on this English blog:


Updated on Aug 15, 2011

1) For emphasis, Marked the two paragraphs with bold font style.

2) The original sentence "there is no simple mapping on the correspondence between the domain models and the software system (or its models)." is probably not exact or clear. It has changed as "there is no simple mapping between the domain models and the software system (or its models)."


from my blog, August 8, 2011, 


Views: 561

Add a Comment

You need to be a member of The Model Driven Software Network to add comments!

Join The Model Driven Software Network

Comment by Mountriver TY Yu on September 28, 2011 at 4:01

Hi! Andriy,

I'm very sorry to reply for this so late, it almost be missed by me.


First, allow me to reiterate my basic view point. I'm not against that, based on some general understandings of the term 'model', programs are models. This reflects the same aspect between models (in a broad sense) and programs but, in my thoughts, the distinction may bring us more useful matters.


Look at the earlier discussion -

My question: “If models are executable, what is the difference with programs?”

Your answer: “The main difference is the level of abstraction.”

Let's talk from here again.

On the one hand, if we are adopting the ‘model’ in the broad sense, then, there is no question. However, to “mix up programs and models, would probably lead us miss the concerns on other important or valuable possibility.”

On the other hand, if we are agreed that there is certain difference, that is, we are using a relative narrow concept of model (hence we' ll need a narrow definition of 'model' but what it is?). As you answer, one of the way to shrinking the range of 'model' may be by abstract level. I think, however, it may be not a good choice.

I opine that it needs to be firstly clarified the source (origin) or the object of models or abstractions (instead of abstract level). As my stated in the post: “first, it must be separated clearly (models of domain and of software), then, to find the exact way of them interrelated. And further, there is no simple mapping between the domain models and the software system (or its models).” I believe, this is a certain way to gain more benefits from models and modeling. Even if to the model of an application system, the first concern may also be the distinction of black-box/white-box but not the abstract level from computer, see my recent essay Modeling on Black/White-boxes, and Abstract Level.

The recent discussion on this site here, is also involved into this issue from the concept of abstractions.


Have a nice day!



Comment by Andriy Levytskyy on August 23, 2011 at 14:34


> About the models in computer vs. in paper-document, I emphasizing that the former must be precise, the latter usually imprecise.


I think there is bias towards execution/machine interpreters. (BTW I agree with Andreas that we should not forget that humans with semantics in their heads are interpreters and simulators as well). I think you are saying that models in computer are processable by computer and paper models are not. In the engineering context, it is (eventually) a required but not sufficient property. The purpose of a model is to capture/communicate knowledge that is *right* for objectives of model writer/consumer. 


Both processable (models in computers) and non-processable (e.g. "paper" models) artifacts can be models for humans, given they capture/communicate the right knowledge. Preciseness and completeness is not what differentiates programs and executable models (they all can share these properties).


The primary difference is abstraction, or more accurately - a system of abstractions (paradigms) that users use to communicate knowledge. Incidentally, these paradigms can be non-procedural, declarative, OO, etc.. I will rephrase the above: the primary difference is that models and programs are intended for different writer/consumers with different objectives. 


Another angle to explain this is that models are considered by humans *the* single source of knowledge (due to economical reasons). (Note in general, a complex system may need multiple models both at the same level of abstraction and at different points of abstraction). Today programs are often derived either manually or automatically from other sources of knowledge (e.g. non-procesable models at more appropriate levels of abstraction). Hence programs are not "considered" models anymore by stakeholders upstream a development process, yet there are situations when programs are models.


TY, what is it in the "abstraction" answer that leaves you unsatisfied? I've read your recent blog, and do not see contradictions to this answer.

Comment by Andriy Levytskyy on August 23, 2011 at 13:18


You say "Criteria for *deciding* what gets added is still trivial". I agree with your points in some specific cases, but not generally.


Wether criteria is trivial, depends on how common and general the required knowledge is. In this case, conceptual->implementation mappings can be reused (and if needed parametrized for extra flexibility). This is certainly true for many enterprise problems that MDE is applied to. Here the focus is on business flexibility, and as you say, applying that mapping, no matter the size of the application, is always cheap. However, this is one extremity.


Another extremity is enterprises where the core business (also) lies in technological implementation of the a product. Good enterprise thereof are enterprises with significant research and development activities. Here the focus is on decisions in solution space. Such decisions are not trivial, and can be huge resource sinks. Once decisions are made, mappings can be re-used.

Comment by Mountriver TY Yu on August 18, 2011 at 7:43


Since it is borrowed, I am particularly concerned about what is the same or the difference.

For the second part, I'm not very understood your meaning... I think, there are some isomorphic mapping between the model of a system and the model of the domain it appied in, not wholly but partially.

Comment by Andreas Leue on August 15, 2011 at 17:14

> some of the term we commonly used for models and modeling, such as execution, interpretation, ad so on, are borrowed from traditional programming/coding centric software engineering.


They are; I wanted to point out that these terms have been previously borrowed from the everyday-domain, so in a certain sense it's now "back to the roots" (e.g.: me, as a human being, can very well execute a plan (model) which is incomplete, informal, imprecise etc.)


> models of ... system, and ... domain ... might be very different...


The isomorphism-tendency between these models is not an immediate structural necessity, but a consequence of our wish to handle the respecitve systems economically (so if we add ourselves to the models and consider the resulting whole process/enterprise as an autopoietic system, the isomorphism-tendency might be considered as a survival strategy of the system).

Comment by Mountriver TY Yu on August 14, 2011 at 11:43

I think the correspondence between a model of app system and its app domain model is not mapping, while use 'mapping' as a relatively rigorous sense. This does not mean it is always complicated, or can not be clarified.

About the models in computer vs. in paper-document, I emphasizing that the former must be precise, the latter usually imprecise. A complex but not complete and accurate model may not be as practical as a hand-drawn graph.

“models can have multiple semantics, not just one executable” - Yes! My recent essays are related to this meaning – and more – some other model-working mechanisms without those conventional way, as well as the articles on your blog. :-)



I think, some of the term we commonly used for models and modeling, such as execution, interpretation, ad so on, are borrowed from traditional programming/coding centric software engineering. These might hide/bring somewhat potential problems...

The models of an application system, and of the business (of the domain, e. g. business processes), might be very different, this is the emphasis my concerned.

This post is preliminary, see more in a new essay Some Classification of Models for Software Applications. And I don't know, if this is somewhat related with your discussion about Andreas' comparison of model driven technologies? :-)

Comment by Rafael Chaves on August 12, 2011 at 16:49



I prefer to use "source" to characterize the representation a software developer used to actually define/write the artifact, be it assembly, C++, or a UML model. Follows from that that "generate source code" should be an oxymoron.



I think no matter how much stuff gets added when mapping a conceptual solution to the actual implementation, the criteria for *deciding* what gets added is still trivial. So even though I agree with you that how much building a mapping will cost depends on the technical requirements, applying that mapping, no matter the size of the application, is always cheap. Considering the fact that technology stacks are often standardized (JEE, RoR, GAE etc), I believe the mappings can be quite reusable, at a minimum across applications, but likely organizations and industries, so the cost of building that mapping can become quite minimal as well (due to economies of scale).

Comment by Andreas Leue on August 12, 2011 at 15:49

I agree much that there is no difference in principle between model, program, code etc., but with regard to usage and degree of certain properties.


Abstraction level is probably most eye catching, other such properties are preciseness and completeness. Both depend on a potential interpreter of the model: a statement, which is precise enough for a human being to execute it, might be completely inprecise for a computer.


The other side of the "incompleteness coin" might also be an important and much desired property of high level models: the degree of freedom they leave with respect to implementation variants.


All these terms - program, code, interpreter, execution - have got a connotation of technicality (strictness, preciseness, completeness) over time. We should keep in mind that this is only due to the fact that the associated interpreter of a computer program is, well, a computer. Keeping that in mind, even a buiness process model can be executable - by humans (which does not (!) imply a tayloristic mindset).


How does an interpreter for a high level abstracted, business oriented, ontological model look like? As long as we think this is more or less the same as an interpreter for a 3GL, then in fact there is no difference between a computer program and an executable model.


With regard to basic structural features and basic formulars present models are fairly ok. Specifically in the  area of interaction (UI, transactions, workflow etc) and content/spatial organisation innovations are rewarding. :)

Comment by Mountriver TY Yu on August 12, 2011 at 15:42

Good example. In fact, the executable models are using a modeling language as an interpretative language not merely a programming language – this reminds me of another question, about some discussion for model-execution and model-interpretation. At least, as a common terms, it sounds easy to make up some confusion.

However, I still emphasize that using models as programs or recognizing programs are models might narrowing the significances of models, though they may be meaningful, too. See my new essay “Some Classification of Models for Software Applications”.



About the difference between executable models and programs, the current standard answer, as you given (and I've mentioned in the essay), gives me no satisfaction, this is one of the reason why I wrote this essay, and more, see new post on my blog.

Temporarily, write to here... I will answer your all comments later...

(Please forgive me, I'm writing too slowly:p)


Comment by Andriy Levytskyy on August 12, 2011 at 14:24

Just a few quick comments on many questions posed by TY Yu..


If models are executable, what is the difference with programs?

The main difference is the level of abstraction. Programs are models, even if nobody calls them models nowadays. Both models and programs can be executable either via translation (compilation/transformation) or interpretation. Different names is just practical shortcut to distinguish languages belonging to different abstraction levels.


there is no simple mapping on the correspondence between the domain models and the software system

In my opinion, the answer is it depends.. If an end user has no other demands from (software) system other than that it needs to support the domain model/ontology and domain behavior (basic functional requirement), THEN the mapping can be pretty simple (see an example here). The more requirements and the harder are those requirements, the more optimizations and choices need to be done in system development. In extreme case, the application models (what) are not crucial, but how those are translated to executable artifacts is what distinguishes this system from other similar ones. Such mapping are very non-trivial.

Naturally a generic methodology like UML/MDA should leave as many design choices open as possible and be as application domain independent as possible, which results in a very complex correspondence between the domain models and the software system.


if so, what the essential difference with well-prepared written document?

Models, even those that are not executable in the common sense, can be processable in multiple ways that are meaningful for a modeler. Examples are visualization of hard to see properties, analysis, simulation, reports to answer domain questions (e.g. what is MTBF, cost, etc.?), maintained consistency and integrity. In contrary, documents, while carrying the same informal knowledge are formal only in the domain of word processing. The only meaningful operations are on words: word count, estimated time to read, spell-checker, etc.. I think benefits are clear, even assuming that knowledge is optimally captured in both the model and document (in practice, most documents written badly). In my recent blog I demonstrated an extreme case of models being very useful even without executable semantics (the benefits even stronger).


I also would like to point that models can have multiple semantics, not just one executable, leading to system enactment.




© 2019   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service