The Model Driven Software Network
Raise your level of abstraction
Is regeneration from the model every time the only realistic way to get major benefits of MDD ?
I was reading the Jon Hurwitz post this morning saying "I think regeneration from the model every time is the only realistic way to get the major benefits of MDD"
I must admit that I agree with him based on our AndroMDA return of experience and also I don' fully agree because of new agile methodologies.
It is common to say as explained by Karsten that "the truth is in the code" therefore if the model is not synchronized with the code, the model would not be the truth anymore.
This is the reason why I have influenced Omondo to create the agile project iteration feature http://www.forum-omondo.com/documentation_eclipseuml_2008/reverse/r...
On the other hand using MDD with AndroMDA for example allows to create all needed layers. In our 2007 example available at: http://www.ejb3.org/model_spring_hibernate_struts.doc we used the following layers:
• Spring for services
• Hibernate for persistence
• Struts technology presentation
The problem we faced was that the complexity of the AndroMDA model validation and that whatever we did at model level we have not been able to create a full running application if no customization at code level. btw, we can certainly save over 50% compare to manually typing code and also have a robust and intelligent architecture in which all generated layers codes are generated separately respecting MDD spirit. It is therefore recommended to use MDD but should it be regeneration every time from the model ?
The today's question is therefore: Is regeneration from the model every time the only realistic way to get major benefits of MDD ?
I must admit that I agree with him based on our AndroMDA return of experience and also I don' fully agree because of new agile methodologies.
It is common to say as explained by Karsten that "the truth is in the code" therefore if the model is not synchronized with the code, the model would not be the truth anymore.
This is the reason why I have influenced Omondo to create the agile project iteration feature http://www.forum-omondo.com/documentation_eclipseuml_2008/reverse/r...
On the other hand using MDD with AndroMDA for example allows to create all needed layers. In our 2007 example available at: http://www.ejb3.org/model_spring_hibernate_struts.doc we used the following layers:
• Spring for services
• Hibernate for persistence
• Struts technology presentation
The problem we faced was that the complexity of the AndroMDA model validation and that whatever we did at model level we have not been able to create a full running application if no customization at code level. btw, we can certainly save over 50% compare to manually typing code and also have a robust and intelligent architecture in which all generated layers codes are generated separately respecting MDD spirit. It is therefore recommended to use MDD but should it be regeneration every time from the model ?
The today's question is therefore: Is regeneration from the model every time the only realistic way to get major benefits of MDD ?
Replies to This Discussion
-
Permalink Reply by Michael Osmond on -
If what you want to achive is an on-going reliance on MDD as the main way that you are going to develop and deliver software, then I would agree you have to keep regenerating code, which means you have to fix problems, make changes and enhancements at the source - that is in the templates and transformations, in the models. Not in the code.
We actually made quite a mess of a software upgrade when we forgot this and hand built the database updates, instead of maintaining the model and working out how to generate database upgrades. The quality payoff comes from working on the model and generation, not the code.
That said there are certain realities that need to be taken into account.
1. Some code will be manually maintained. We generate about 96% of our source.
2. There are times when what is generated is wrong, but it is not feasible to fix the generation (this is usually for late fixes before a release that require intrusive changes to the models or templates etc.)
One of the (many) things I have learnt is that the process must be flexible enough for people to get the work done without high cost. Full generation runs can take time so you have to give people effective ways of making small changes quickly, but without compromising the reliability of the process.
So I think the build process - the process of building a deployable piece of software needs to take into account:
1. A full regeneration cycle.
2. Some sort of selected update only - where you can generate parts of the application.
3. A way to change just the hand managed code, but rebuild the system.
4. The ability to override generated code with hand code - the hard lesson to learn is to almost never use this. And if you do fix it up as soon as possible.
To me it makes sense to regenerate from models, regularly (at least nightly). It makes sense that this is off loaded to a build server, and only that code can be deployed to test. Think of it as the MDD equivilent of continuous integration.
Michael
-
Permalink Reply by Rui Curado on -
I agree with you on everything except at point 4. It's as if you were the law maker and you say "This is Law Nb.4. You can break it this way, but please don't do it.".
It's better to create ways to reliably change hand code. As I said in a previous post, use a meta metamodel (if the tool allows it) or just a metamodel that allows you to add (and therefore change) manually added code. So that when you need to edit code, you can still do it at the model.
Anyway thank you for your view of an "ideal" MDD approach. It will help me further develop my ABSE approach.
-
Permalink Reply by Michael Osmond on
-
Rui,
I agree its sounds or is inconsistent. However, in defence of the approach. In this case we are not changing our hand writen code, we are actually replacing generated code files with an alternate file. So it is not about reliability of handling manual code.
Our experience is that there are times in the project cycle where overriding generate code is expeditious. This may be because of time pressures. It may be because the change in generation to fix one project conflicts with the requirements in another project, or again to model out how to handle this difference is not something that can be undertaken at that moment.
Our second experience is that when we use this facility, it works in the short term, and causes problems in the long term. The problems come when we leave an override in place, but make other changes that do not get reflected through to the as built system.
You could think of this override as a flag that something needs to be refactored, just not now.
Michael
-
Permalink Reply by Jon Hurwitz on -
What Michael does sounds similar to what we do, about 95 - 98% generation, but with some differences. When developing I will often regenerate 10 times a day from the model and we wouldn't normally bother to split the model down. We might merge changes to the model made by multiple modellers, but we all use the whole thing (even if it gets a bit out of step between merges). We work in small teams. There aren't normally that many changes to the model after the first few weeks, unless we are adding in a new phase. By the time we hit system test we'll regenerate far less frequently.
We never override the generated code and either stick to Michael's type 3 hand coding or add special generation code. I'd like to think that whether you use generated code or hand code for any particular method is a choice of expedience or policy rather than forced by the technology. Typically it takes me about two and a half to three times as long to meta-code to generate a file than simply code it as a one off and that's my main trade off. I'm not the fastest programmer in the world. :-( Testing also takes longer. Is that what others find?
The time constraint for a full regeneration that Michael mentions isn't much of a problem for us. That might be because we do smaller projects or because we have a faster generator, I don't know.
-
Permalink Reply by Rui Curado on
-
I don't know AndroMDA, but if you can't generate a complete application from an AndroMDA model, then it's metamodel is not good enough. If you can't add custom code directly on the model then dump AndroMDA.
In my developed approach (ABSE) you can create complete applications because its meta metamodel contemplates the integration of custom code. Full regeneration from the model is required though.
-
Permalink Reply by Jorge Ubeda on -
I agree with Rui; the first difference between MDD and any other approach, is code generation from model. Observing comments from members confronting with different issues, it´s possible to assert that as soon a model requires hand made code completion, it weakens the process, and decreases the productivity of modeling. If there are holes, it must be solved, but tending to full generation (and regeneration) from models
-
Permalink Reply by Andrew Shapton on -
I also agree with the assertion that hand-coding weakens the modelling process. We use a model-based-development tool called CA-Gen. It allows multiple developers to make changes to the central model by checking out subsets. The deployment code is 100% generated from the model (we generate C code for deployment). OK - there are some things that we can't code in the toolset, so we use raw C code for that - however, the tooling is aware that some parts of the system are already compiled and need to be re-linked only. CA-Gen allows us to have maximum productivity, since we only ever make changes to the model and NEVER the generated code - this is true for changes to the data model and changes to the model itself (based around the data model).
About
Badge
© 2010 Created by Mark Dalgarno on Ning. Create a Ning Network!
