Confusions in the concepts of model execution and code generation.

There is quite a lot of  fuzziness and confusion in the general discussion around the concepts of model execution and code generation.

I try to straighten up these concepts and their relationships.

1)      Isomorphic mappings
First every programming language (with a working compiler) is a isomorphic mapping between syntactically correct piece of code and the corresponding compilation ( executable code). This means that for every compiler a reverse complier can be written and that compiler will produce a corresponding source code from an executable piece of code.

2)      Current (deterministic) computers cannot execute any kind fuzzy code.  This implies that the executing code has to be always at the lowest granularity and the whole execution flow is completely deterministic.

3)      Models by definition are abstractions. They drop detail to gain clarity in more important aspects of things. This way the initial models to serve their purpose must exclude details that the applications using the model finally must have. This implies that there cannot be any meaningful execution of a model as such.

I think that it is important to separate domain (business) model from the whole application. Of course it is technically possible to model the whole application in one model, but the increase of complexity is enormous. I don’t think that one needs any “application model” because applications are always very simple thing and they should be designed not modeled.

All this implies that model execution cannot be anything very productive. An totally other question is “graphical programming language”. This has been tried several times in the past and with very poor results. Here the amount of detail is in the key role again. It seems evident that we are able to handle very small amount of information in graphical form. The breakeven point is actually very low and after that the situation very quickly gets really bad. One very clear and also good attempt in this direction was IBM’s Visual Works for Java. It focused in graphical GUI programming. In demos it looked fabulous but everyone that really tried to do something real with it was quickly convinced that it will never work. Even a modest window with some functionality became a total mess.

This means that graphical presentations (at least for me) are vitally important thing. Class diagram in UML is quite sufficient. Collaboration diagrams theoretically are also good, but the current tools with these are very poor indeed. There should be powerful tools to produce collaboration diagrams and they should include a default option to present them as animations. Some time Rose had that but sadly that time passed long time ago.

Then the true key question is how to make the transition from graphics to textual programming sooth or almost invisible.

To concretizes all this let’s go through an example. Let’s start with a small model. Here is an abstract core model for a web- book store.

Here we have four classes: Person, Book, Walk and Purchase.  Objects in Person-class are the only entity type objects. Walk and Purchase classes are event type and Book classes is description type. Walk event is actually the person’s visit in the shop and the name of the class could also be visit. The association between walk and book represents the book that the walking person has picked up and as purchase candidates. When the walk ends it will create purchase event and transfers those books that the person finally is buying.  Here is the corresponding collaboration diagram:

The simple generation from class diagram includes following:

public class Person {
private String name;
private Date birthday;
private String creaditCard;
private List walks = new ArrayList();
private Long id;

public String getName() {
return name;

public void setName(String name) { = name;


public List getWalks() {
return walks;

public boolean addWalk(Walk walk) {
if (!this.walks.contains(walk)) {
if (walk.getPerson() != this) {
return true;
return false;
public boolean removeWalk(Walk walk) {
if (this.walks.remove(walk)) {
return true;
return false;
public Walk createWalk() {
Walk walk = new Walk();
return walk;

In a similar way the code for the Walk class can be generated. There for instance can be generated the pickUp() method as follows:

public boolean pickUp(Book book) { }

This signature can be generated but there is now way to conclude the method behavior even if for a human through the semantics of the method name this think could be quite evident:

public boolean pickUp(Book book) {



return true;


Finally there is now way to generate anything for the application. The application has to have at least one GUI window that enables management of persons and books and pane for a walk and purchases. To get a decent result the GUI and its functionality must be design and implemented by humans.


2 Responses

  1. Hi there,

    I guess we disagree in all points you made…

    1) Re: Isomorphic mappings – A transformation from model to concrete artifact in model-driven development often results in an artifact that is more concrete but that however omits things that were in the model but not relevant in the context of that artifact.. Except for the simple 1:1 model – artifact transformation, it cannot be reverse engineered in a practical way. Simple case: OO code does not represent relationships properly (unless you annotate it), a DDL script does not represent behavior. IOW, a MDD transformation is not really akin to your normal compilation. I wrote a post about this a while ago:

    2) the fact that models are incomplete does not mean they are fuzzy. Any of the missing information will be filled in by the code generator or by the model VM, and that is for a good reason (because it is not interesting, or because a generator can do a better job in the normal case). Example: SQL queries and their corresponding execution plans.

    3) models are more abstract than code, sure. Yet they can be executed (or transformed into executable code), see #2.

    4) “All this implies that model execution cannot be anything very productive”

    How come? Productivity is the key premise of model-driven development!

    5) “An totally other question is “graphical programming language””

    Granted, graphical notations make executable modeling hard/limited for the general case (for DSLs they can do the job). But model-driven development needs models, not dfiagrams.

    6) “This signature can be generated but there is now way to conclude the method behavior”

    Exactly, that is why you need to include the behavior in your model, or else it is not executable. See:



  2. Hi,

    generally speaking I agree with you but here I consider also “book” as being an object because both pre-exist and UML does not distinguish between Subject and Object while events (walk & purchase) are technically association between Person & Book.

    However, this topic can be heavily discussed too because if semantically Person is associated to Book; in practice a user represents the Person and in code it is the Form class.

    And I think that if you have a link between walk & purchase, semantically, it should also exist in the first model that will be then closer to the modelled universe semantic.

    Also, I don’t see what an object diagram adds to the corresponding class diagram. Walk does not necessarily needs to exist before a purchase in this case. Is it casual or structural? If casual, the model given can be dubiously interpreted, if structural a book category inheritance is needed.

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: