Models: Execution or More

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:

• Model-Driven: An Essential Requirement Come from Customers
• A Roadmap of Research for Enterprise Applications (a simplified version)

—-

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).”