Comments on: On code being model – maybe not what you think

By: Myths that give model-driven development a bad name | abstratt: news from the front

Sat, 06 Feb 2010 07:58:41 +0000

[...] the codebase is manually maintained (and thus inherently inconsistent/ill-formed). More on this on this older post, pay attention to the comments as [...]

By: rafael.chaves

rafael.chaves — Sun, 19 Jul 2009 18:14:47 +0000

Marc, that analogy is quite interesting, thanks a lot. I feel like writing a post about that…

By: Vladimir

Vladimir — Mon, 01 Jun 2009 21:06:10 +0000

“code is model” is really good mantra
Just consider all app code, like: java code, java annotations, configs, DDL, SQL, …
All of them are aspects of software. It should be enough to restore initial model. Different aspects can be expressed in the same model using different views of a model or by annotating model with appropriate profile (or equally DSL) definitions. If model can’t be restored from generated artifacts then it seems like it contains superfluous information.

For example I have UML domain model. It contains annotations for: DB schema (tables, columns), ORM code (Hibernate/JPA/Transactions), Web pages (UI artifacts customization). It can be used for generation of a Java code, DB schema, services code, Web pages. This code then can be reverse engineered back to the model (at least at DB/ORM level since its based on a strictly defined specifications)

By: Marc

Marc — Fri, 22 May 2009 18:29:17 +0000

“Round-trip engineering goes against the very essence of model-driven development, as source code often loses important information that can only exist in higher level models.”

An interesting statement; one could compare http://en.wikipedia.org/wiki/Central_dogma_of_molecular_biology .

The idea of RTE seems to be that models can be built inductively by looking at existing solutions as implemented, warts and all. The idea of code as a mere instance of an abstract model – another kind of view – is appealing, but it leads to a kind of Platonic ideal of the model. I want my models to be living things that benefit from the successes and failures of implementation – shaped by the metainformation of interaction with the real world. I do agree that one instance isn’t enough to build a high-resolution model, but I’m not sure that a lot can’t be learned by examining many instances as part of the processes you’re modelling.

You’re entirely correct that that’s not at all the same thing as equating model and code, of course.

Great point about the appropriate application of 3GLs btw.

By: Rodrigo Yoshima

Rodrigo Yoshima — Sat, 09 May 2009 05:12:57 +0000

Jack Reeves said a long ago “Your design is your code”.

http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

Maybe this concept bring us “code is model”. I agree that higher levels of abstraction could help us, but also agree that not for every aspect of the system being developed.

By: Ersin ER

Ersin ER — Tue, 05 May 2009 16:02:52 +0000

Generally “the code” is being created by developers’ mental work (and the motivations, reasons stay in those heads). The more frameworks or such reusable artifacts are used the more “model” we get and the system starts making more sense as it represents more abstract things than machine code. A software system should be developed using languages and environment which can express it and drive its realization in the most abstract form possible. So that we can close the gap filled by developers mental work generally. This does not mean that we should go crazy with defining models to cover every aspect of systems but it’s a matter of balance.

On the other hand a basic distinction between code and model for me is that latter is/should be a built in a more declarative manner than imperative.

By: Ed Merks

Ed Merks — Mon, 04 May 2009 14:33:57 +0000

This is a very interesting post. I completely agree.

By: rafael.chaves

rafael.chaves — Mon, 04 May 2009 07:33:42 +0000

Thanks for your comment, Peter.

I also think that the mantra “code is a model, too” does not help very much, because it makes people think that code and model are on the same level of abstraction.

I think what Harry really meant was that code at one level will be a model to a corresponding artifact in the next (lower) level.

Of course, there are situations in which code and model are on the same level. Just think of traditional UML modeling (a class diagram is just a different view of the code)

Well, even in the case of UML class diagrams, there is an increase in the level of abstraction. Think of things like associations (with shared/composite aggregation), multiplicities (with ordering/uniqueness), subsetting/redefinition of properties. None of those things can be represented in any of the OO languages I know of.

By: Peter Friese

Peter Friese — Mon, 04 May 2009 07:16:45 +0000

Hi Rafael,

I agree with your opinion that you just cannot use round-trip engineering in MDSD, as computers (still) are not able to abstract. Model driven software development is a forward-only process for this very reason. Fortunately, most people understand this point as soon as you tell them.

I also think that the mantra “code is a model, too” does not help very much, because it makes people think that code and model are on the same level of abstraction. Of course, there are situations in which code and model are on the same level. Just think of traditional UML modeling (a class diagram is just a different view of the code).

To me, modeling is a means to express concepts of the real world in a way that both a developer and a business person can understand it. It’s really a meet-in-the-middle approach. Domain Specific Languages (DSLs) can help to achieve just that. I am not convinced that UML can deliver on this, which is why I usually use Xtext (http://www.xtext.org) to achieve this.