Preparing for MDD

Replies to This Discussion

Permalink Reply by Rafael Chaves on February 18, 2010 at 2:01am

Paulo, why would you model if you don't plan to generate running code from it?

Even if you want to start only experimenting with MDD, you should go all the way, from model to runnable code. You manage risk by starting with the smallest subsystem that is a good candidate for construction with MDD, and building a MDD-produced version in parallel, until you are confident you can replace the legacy code. Suggested steps:

1) find a small subsystem in your system that is a good candidate for MDD

2) create a template that would allow you to generate one kind of artifact (for example, Hibernate mapping files)

3) create a model with as much detail as required to generate the artifacts using the template created in #2

4) ensure the generated artifact can indeed replace the manually created one (by comparing the artifacts and ensuring correctness by running them - automated tests help a lot here, after all, this is really a refactor)

5) repeat 3-4 so you can generate all instances of that kind of artifact in that subsystem

6) repeat 2-5 so you have templates and models that allow you to generate all artifacts that are prone to automation in that subsystem.

6.a) If you feel confident and have support to do so, delete the manually written artifacts (they are object code now), and change your build process to have a code generation step.

7) amaze the rest of the team/company with your achievement, and get buy-in to adopt MDD in other subsystems. Hopefully they will share some architectural architectural traits with the first subsystem you tackled, so you can reuse the templates, you just need create new models.

There are plenty of tools, openArchitectureWare and Acceleo jump to mind as good open source options that have good Eclipse integration.

Good luck,

Rafael
http://abstratt.com/blog

• ▶ Reply

Permalink Reply by Paulo Cesar Mattos Ferreira on February 18, 2010 at 11:20pm

Thanks Rafael,
I would model without generate code in order to keep the intelligence (or part of it) out of the code. I believe it adresses issues like:
-the turn over of IT staff - it simpliflies the understant of the business for a new programmer/analyst for example
-its a way of the stakeholders keep some kind of domain of the systems (in terms of rules, etc)
-In a situation where the client/customer need to change its IT(software developer) supplier , it would be good to have some models.
-It prepares for a mdd initiative in future.

But I agree with your suggestions ...

The cenario I described may be real. I have a client who could be interested in mdd , but they (or I) will depend on budget to spend enough time in mdd efforts. So , just model could (or not) be a start. This (no so new) technology must be sold very carefully to them. If I do that like a new trend ou fashion , I could get the wrong result. Try it in a small subsystem , as you told , its certainly a way - and using free tools.

-I will check out openArchitectureWare and Acceleo . if anybody remembers other good one tools - please reply.

Thanks again.

• ▶ Reply

Permalink Reply by Rafael Chaves on February 19, 2010 at 4:08am

Paulo,

Please take no offense, but I think of the approach you describe as 'mindless modeling'. I think that building models that don't lead to running code a disservice to any software organization, and actually that instead of laying the ground for model-driven development, I think it hampers your chances of getting buy-in for MDD.

But that is just my opinion, I am certain others here will disagree.

Cheers,

Rafael

• ▶ Reply

Permalink Reply by Rui Curado on February 19, 2010 at 9:41am

I agree with Rafael. People who have only modeled (UML comes to mind) have failed.

It's better to go all the way in MDD, from model to code.

If you have time constraints, model just a part of the running system, but show how powerful and dynamic the MDD approach can be by generating running code from a model, and better still, show how easy it is to re-generate when a change in the model occurs.

At the end, prepare some metrics to show the differences between the conventional and the MDD approach. Keep in mind that the first projects developed through MDD can take more time than the traditional approach, as there is usually no reuse opportunity.

• ▶ Reply

Permalink Reply by Paulo Cesar Mattos Ferreira on February 19, 2010 at 10:27am

Thanks Rafael and Rui for express freely your ideas. That's how a forum should be.
I'm glad to have become member of this network.
Of course , only to model takes a lot o risk - that's why I (in that case) wouldn't put much detail on them. I believe models (even don't generating code) have value to the client.
Sucess!

• ▶ Reply

Permalink Reply by Xavier Seignard on February 27, 2010 at 11:34am

Agree with Rafael and Rui. Take a representative small subsystem, (retro)model it, generate it as a proof of concept.
Don't forget that the real stake won't be the proof of how powerful MDD is. IMHO, it will be how you integrate MDD in an industrial process, so don't forget about creating MDD factory with models repository, automated building, automated documentation, and so on.

The crowning touch could be a nice retro-modelisation in order to modernize existing code.

About the tools, I would say MagicDraw(great open api! TeamWork plugin) + Mia-Generation or Acceleo for code generation purposes.

MagicDraw and Mia are not open source, but damn good!

For modernization purposes, I would say Mia-Modernization.

Regards,

Xavier
http://mdwhatever.free.fr

• ▶ Reply