Skip to main content

Reuse or Rewrite AndroMDA Cartridges?

Someone asked me what is the best way to work with AndroMDA in case that the architecture (structure, naming, process, etc.) is different than the AndroMDA's one. Reuse all the cartridges as far as possible and extend them or rewrite them from scratch?

My opinions are as follow:
  • Think of a framework everytime you use AndroMDA. This includes the cartridges AndroMDA offers. When you are using frameworks you mostly don't want to rewrite them. You want to reuse and extend them. So, reuse and extend already available AndroMDA cartridges is the way to go.
  • If your team is only a small team never think of building your own architecture, thus you don't need to rewrite the cartridges. By building your own architecture (e.g. using your own directory structure, using your own naming convention, etc.) you mostly need to write your own cartridges which is costly. Remember that the developers of AndroMDA and AndroMDA cartridges are not beginners. They had many thoughts poured into the cartridges and most of them are experienced architects and developers. So you can be sure that the architecture of applications generated by AndroMDA cartridges are a stable architecture and has a good thought.
  • Never forget that AndroMDA is an Open Source project. If you think you have better ideas just join them and give them some inputs to make the available cartridges much more better!
So, when should we write our own cartridges?
  • In case that you are doing a re-engeneering project which means that you have all those source codes and you want to integrate AndroMDA cartridges slowly into the whole application development process you need to write your own cartridges. In this situation you can slowly "generate" some of the repeating codes by using your own cartridges. Already available AndroMDA cartridges will mostly miss this purpose. But again, if you write a new application reuse and extend available AndroMDA cartridges as far as you can.
  • Only build your own architecture and thus create your own cartridges if you and your team have the capacity and resources to do this.
Happy modeling,
Lofi.

Comments

Hi Lofi,

It's a great comment. Thx for your response to my email.

I still have some thought may be i need more time to explore about AndroMDA.
Anyway my biggest problem is we already have our own standard that different to AndroMDA cartridges.
Hope i will find a better way to our team.

Yesterday, i have try to make a small project using AndroMDA, looks like it helps a lot to our team and hope it can really increase our performance in development :)

Thx you have introduce me to MDA :)

Tjiputra
lofi said…
Hi Tjiputra,

nice to hear that AndroMDA helps you and your team to be more productive...

I hope that after using AndroMDA you will have a lot more free time (== computer free timezone ;-))!

Cheers,
Lofi.

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;
...
@Retention(RetentionPolicy.RUNTIME)
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…

Smart Home Sweet Home with Gigaset Elements?

Introduction
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…

GWT Training for Java Developers with GWT Boot

I'm always a fan of "one language solution with Java to rule them all", here are sofar my opinions about Polyglot Programming:
Why "Polyglot Programming" or "Do It Yourself Programming Languages" or "Language Oriented Programming" sucks?Warum Polyglot Programming nicht praxistauglich istJava als universelle Programmiersprache Until today nobody can excite me about Polyglot Programming. My points are getting another big support after I read the "Rise of Polyglot at Netflix" presentation which says that Polyglot is expensive, also for company in the category of Netflix. At the end of the day we need to be productive. Our applications should have a high quality standard and the total costs (TCO) of our software development should be manageable and low. To be able to reach this goal we have Java with Spring Boot or JakartaEE on the server-side which offers REST interfaces. So logically for user interface development on the client-side I…