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:

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

@Column
public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

and

@OneToMany
public List getWalks() {
return walks;
}

public boolean addWalk(Walk walk) {
if (!this.walks.contains(walk)) {
this.walks.add(walk);
if (walk.getPerson() != this) {
walk.setPerson(this);
}
return true;
}
return false;
}
public boolean removeWalk(Walk walk) {
if (this.walks.remove(walk)) {
walk.setPerson(null);
return true;
}
return false;
}
public Walk createWalk() {
Walk walk = new Walk();
addWalk(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) {

this.myHand.add(book);

book.pickedUp();

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.

Advertisements

New summary page for ADDD

Hi

I added here a page: ADDD in nutshell. This page summarizes the most important viewpoints that I have been writing here. It collects the pieces together and tries to assembly a holistic picture with the most important aspect. This also describes the necessary minim set of elements that gives the simplest way  to manage an operation management application family of one business function. This of course implies two implications: 1) this is the most effective application creation and maintenance method over the whole application family lifecycle, 2) The quality of the resulting application family is likely to be the highest reachable.