Skip to main content

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!



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 :(

Popular posts from this blog

Creating Spring Bean dynamically in the Runtime

In my training someone asked me whether it is possible to create an object (a Spring Bean) dynamically so you can choose which implementation you want to have in the runtime. So at the compile time you don't know what object actually should be created yet. The application should decide what object to be created based on a property file.

1. We create an annotation so we can mark the method which should be able to create the object dynamically:

package your.package;
public @interface InjectDynamicObject {
2. Use the new created annotation in your method which should be able to create the object dynamically:
... @Named("customerBo") public class CustomerBoImpl implements CustomerBo { ...     @Override @InjectDynamicObject public Customer getDynamicCustomer() {         return this.dynamicCustomer; } ...
3. Write an aspect with Pointcut and Advise which change the object returned by the method in the step 2:
... @Named @Aspect public class Dyn…

Enterprise Applications Customization with Microservice

Introduction Today in highly paced enterprise environment you, as the leader of enterprise IT division, need to be fast. Simplicity is the key for the speed. What are the key factors to simplify your IT? Three different areas are very important to take care of: Technology, Organisation and Environment(TOE Framework: Here are some detail points for technology and organisation:

1. Technology: in most enterprises there are already one or more ERP and CRM solutions the so called Enterprise Applications. We need to manage them carefully as they support the business processes. In context of the core compentencies most enterprises customize the enterprise applications to fit their needs. We need to manage the customizations in detail as they represent the core competencies and at the same time the differentiation of our enterprise to other competitors. 2. Organisation: working in a small team with different roles and functions is already proved as the best …

Smart Home Sweet Home with Gigaset Elements?

Last week I had a chance to try the Smart Home solution from Gigaset Elements. I read some articles about this product which said how easy to install this product for dummy users. Those articles woke my interest and I began to google products for Smart Home solutions.

In this article (German language) you will find a nice overview about some products for Smart Home, which can be bought in Germany. The Nest product from Google is still not available in Germany. Although it seems that RWE will offer Nest products in Germany in couple of months.

The installation of Gigaset Elements was really easy. The problem I encountered was to add the sirensensor. I had to push hard the button on the siren sensor at the same time with the button on the base, so that they can communicate with each other. After about one hour I managed to install everything properly.

Points to mention
Generally the idea is very nice. Gigaset Elements try to push KISS (Keep it Simple Stupid) principle. Howev…