Monday, June 11, 2007

MDSD/MDA Frameworks: AndroMDA Cartridges vs. Sculptor

It's quite amazing to see the same things happen again and again... Reinventing the wheel seems is the way in computer science to make things better ;-)

To begin this blog with, which is a comment of the discussion in TSS about Sculptor: The idea of Sculptor is not new, also ArchitectureWare is not new... MDA/MDSD is not new as well...

Here are my opinions about Sculptor and AndoMDA and general about MDSD/MDA:

(1) I'm a very satisfied user of AndroMDA. AndroMDA is a very good framework for MDSD/MDA and is just comparable with ArchitectureWare. The latter is the framework in which Sculptor is written.

(2) Sculptor is comparable with AndroMDA Cartridges, which allow you to generate codes for its reference architecture. AndroMDA offers a lot of production-ready cartridges like:
  • Java (general purpose)
  • EJB, Spring, jBPM (business layer)
  • Struts, JSF (presentation layer)
  • ...
  • And also for .NET!
All these cartridges are already available since more than 3 years! So they are quite mature.

Here is a very good description of the reference architecture in AndroMDA Cartridges for Java and here is for .NET reference architecture. And here are two articles about why using AndroMDA is the way to go.

(3) The difference between AndroMDA Cartridges and Sculptor is that AndroMDA Cartridges use UML as its DSL. Sculptor seems to invent its own text-based DSL. This would be a very interesting point to discuss. My questions here is: why using a new text-based DSL for implementing business applications? For this purpose UML is the way to go. Why? Because:
  • We have a lot of good UML tools.
  • A lot of people (also business people) understand UML (or a part of UML). If you are using a text-oriented DSL you will loose the capability to talk with the business people.
  • How is the quality of the editor for Sculptor DSL? I see a lot of good DSL but almost all of them have a poor editor support. See my blog about Groovy and unit testing.
  • In my experience with DSL using ANTLR it is not easy to design a clean DSL. It is very difficult to draw the line where you should stop putting more elements in your DSL. Typical problem: should I put String operations in my DSL? In the long term you will mimic the "lower" language.
  • Using UML and its extension mechanism (stereotype, tagged values, etc.) are mostly enough to handle all your requirements in business application development.
(4) The quality of the generated codes is the important part of choosing such a framework like AndroMDA Cartridges or Sculptor, since it will determine the quality of your application architecture:
  • How many developers have used and reviewed the cartridges and the generated codes?
  • How is the generality of the architecture? Will it fit for your needs?
  • Do I need to extend, change or rewrite the cartridges?
One thing for sure, you HAVE TO REUSE the cartridges to become productive. Changing or rewritting them make NO SENSE for a small team! I have experienced this again and again... Check out my older blog about this phenomenon. So you have to be able to add your requirements to the development of the cartridges and this means that the development team in the cartridge project should not consist a single developer!

In my experience I can say that AndroMDA has a very good support. A LOT of developers have tried and used their cartridges. The development of AndroMDA cartridges is a real Open Source development and those AndroMDA developers are very active!

Cheers,
Lofi.

2 comments:

Patrik Nordwall said...

I think there are plenty of room for different tools and alternative solutions.

I have only browsed some documentation and I haven’t used AndroMDA so I can't really compare them, but I can give you my view of textual DSLs and Sculptor. I don’t expect that we will agree on anything but it might be interesting for the discussion.

Sculptor uses openArchitectureWare (oAW) XText to define the grammar of the textual DSL. It is very easy to use. The Eclipse editor for the DSL is generated by oAW and it is good, but not perfect. I’m sure the oAW team will improve the editor.

I don’t think UML is the perfect language to describe everything in the problem domain we are focusing on. I feel more productive in a textual notation than in UML, but that is a matter of taste. We have ideas of new features, especially in the presentation layer, that we think are better expressed in a textual DSL than in UML.

Textual DSLs have all the benefits of ordinary text source code, such as searching, copy-paste, merging and so on. Additionally the roundtrip is shorter and you get immediate feedback of model constraint checking directly when you edit the DSL text.

I think it is described nicely in XText documentation:


Does this sound familiar to you?
Oh, I need to rename this misspelled property within our domainmodel. Ok, so let's startup this big UML monster... and by the way let's get a new cup of coffee. Cool, it has been started up already.
Grabbing the mouse, clicking through the different diagrams and graph visualizations... Ahhh, there is the name of the property right down there in the properties view. Let's change it, export it to XMI (...drinking coffee), starting the oAW generator (in a jiffy ;-)). Oh, it's not allowed for the property to be named that way, a constraint says that properties names should start with a lower case letter. Ok, let's change that and again reexport...
Some moments later, everything seems to works (tests are green). Ok let's check it in! Oh someoneelse has also modified the model! Aaarrrgggh....
Think of this:
Want to change a properties name? Ok, open the respective text file, rename the properties name and save it. The editor complains about a violated constraint. Ok fix the issue, save again and generate. Check the changes into SVN (CVS). Oh there is a conflict, ok, let's simply merge it using Diff.
And now? Let's have a cup of coffee :-)


AndroMDA team has also realized that UML is not good for everything and one of the main goals with version 4 is to support non UML meta models, i.e. non UML DSLs.

Yes, the quality of the generated code is important.

Sculptor captures a lot of the concepts/patterns from Domain-Driven Design, e.g. Repository instead of DAO, Entities and ValueObjects as core elements in the domain model (AndroMDA Spring cartridge also has ValueObjects, but that is not the same, it is DTOs, which is a rather unpopular pattern nowadays).

Sculptor provides a small but important runtime framework (which you can replace). It is important to not generate more than necessary. I'm not sure if the AndroMDA cartridges use that approach? It is better to place generic stuff in a framework and only generate what is really needed. E.g. generation of generic CRUD operations for DAOs, as is done in AndroMDA Spring/Hibernate cartridge is not the way Sculptor has solved it.

ThorQue said...

It's a pity that the discussion is about AndroMDA vs. openArchitectureWare. The article by Patrik offers something more. He has implemented a powerful framework? enables you to develop very quick a software product.
But about this aspects of Sculptor you don't write any word :(