Model Driven Software Development with UML - Back to the Root (or how KissMDA saves our Agile Development with Java...)
After working since 2004 with MDA (Model Driven Architecture) / MDSD (Model Driven Software Development) technologies like AndroMDA, oAW, etc. always in context of Java technology and UML (Unified Modelling Language) I feel like that we need just another MDA tool. Why?
Past
The first experience with AndroMDA in the year of 2004 was great! At the end you don't need to code those boiler plate codes in EJB 2.x. AndroMDA generates everything for you. You also have the documentation of your application always up to date. This is a very important thing, since if you have more than one hundred entities you definitely need that actual documentation to be able to extend the application. AndroMDA offers a lot of mature cartridges like EJB 2.x, SpringFramework, Struts, Hibernate, JSF. The idea with cartridges is just gorgeous. IMHO it is possible to have a general application architecture for most business applications. So if you are using SpringFramework and Hibernate you can reuse the already written cartridge and you don't need to write your own cartridge. I see no case for your own "architecture" and your own cartridge especially in the area of business applications. This is one of the best thing AndroMDA did for us.
oAW has a different story. There is no reusable cartridges because every persons and companies should build their own architecture and cartridges. This is not a good idea. This is just like when you say that you need your own database system for your "simple" business application.
In year 2006 - high noon of Model Driven Software Development with UML - I thought that we are going into the next level of component reuse in the software development: UML model reuse! Just like what openCRX (Open Source CRM application) has done with their own model driven development tool. But this dream is still a dream until today.
Present
1. I still like AndroMDA, yes the project is very much alive and it has already proven itself to be a strong Open Source project, since AndroMDA has survived the come and go of its comitters. AndroMDA is IMHO the best project in MDA / MDSD area sofar. One problem I see is the complexity of the project. Yes, you need to model the cartridge to build your own cartridge. In the beginning this looks like "eat your own dog food" but at the end it makes the things much more complex to build. Just take a look how you can build your own cartrige in AndroMDA. You also need to use a lot of XML files and elements to configure your cartridge. As an application developer you need all those XML elements to be able configure AndroMDA which makes AndroMDA a configuration monster.
2. oAW has a different story. Until the version 4.3 it seems everything looks very smooth. After the project went to Eclipse it seems that the project has no activity anymore. No news anymore from oAW 5 release. It's really a pitty. The big problem of oAW is also its Domain Specific Language (DSL) Xtend und Xpand (remember: Polyglot Programming sucks!). Since they depend on their own editor capabilities in Eclipse and because the project seems to be dead, you will definitely stuck with Eclipse 3.4! No development anymore in the future.
3. Acceleo is new kids on the block and looks pretty nice. The project is active and alive. The main problem is that it uses a DSL called MOFM2T (MTL) to generate artifacts. You can read the getting started document of Acceleo to understand how Acceleo generator works. Additionally everything in Acceleo is quite Eclipse centered. So you need the MTL editor from Eclipse, imagine if something happens just like oAW. You will stuck with an old Eclipse version!
There are some other MDA / MDSD tools available outside: Taylor, Topcased, openMDX, etc. But all of them suffer the problems I mentioned above.
Experiences and Advantages
In my career as a software developer I see real values using MDSD / MDA. Here are my important experiences:
1. If you are following the best practices in model driven software development with UML your application will have a very good blueprint. This is comparable with the blueprint of your house (application architecture). You still don't get any blueprint for your city planning (enterprise architecture) but this is a good way to begin with. So if you have a lot of houses, you will have a very good documentation of each houses but still you don't have any overview about the city where your houses are built on. In a situation where external developers come and go it is very useful to have a very good documentation of your application architecture.
2. The documentation of your application architecture I mentioned above is always up-to-date. Can you imagine to have 200 entities (database tables) in your application and you don't have any UML class diagram for them? Surely you can say, hey we can generate the UML class diagram from the Java classes. The problem with this approach is that you cannot talked with your business people or your stakeholders until you implement the classes and as you know if you already implement those classes you tend to defend your design. Instead of saying "ohh no problem at all I can just change the name of that class" you will say "ahh c'mon you know what I mean right?". It is a lot of work if you have to change the name of your class especially if it has an impact to your persistence layer (JPA, database tables). Let's imagine if you can just change the name of your class in the UML class model and you can generate your persistence layer. You will still have a lot of work refactoring the rest of your codes but it is less work than without using model driven development.
3. The architecture of your applications is always the same. This is important if you have a lot of applications to be managed. Frameworks like Spring and JPA with Hibernate still give you too much freedom. You can implement your applications in different styles like using XML or only annotations. This will be a problem later as you have to maintain your applications.
4. It is faster to introduce your application structure to external developers and consultants. They learn how to model the entities and services or the domains with UML and generate the skeletons of the codes which they need to implement. In many cases you can generate the persistence layer completely.
From all the points above I can tell you that Model Driven Software Development with UML helps you a lot not only in the beginning as you can start your application development faster but also afterwards in the maintenance phase of your application development.
Best Practices
After a long journey in Model Driven Software Development with UML I can summarize following points to be the best practices (also note this presentation: MDD: the Good, the Bad and the Ugly):
1. Always top-down, never bottom-up, never both directions: you describe your application (entities, services or domains) first with UML. From this you will generate the artifacts (Java, XML, whatsoever). In many cases you will have to extend or implement the generated artifacts.
2. Never edit the generated artifacts, never check-in the generated artifacts into versioning system: you will need different places for your generated and non-generated artifacts. In Maven you have target/generated-sources/java for generated Java artifacts and you can use the Maven phase generate-sources. Never use protected regions, this makes your code unmanageable.
3. UML models are first class citizens in MDSD with UML: you have to handle them with care and you also need an excellent tool for them. Not less than Eclipse or IntelliJ as for Java codes! You need to partition your UML models just like your Java projects so that they won't be too big. Generally I use this practice: one UML model per Java project.
4. Separation of cartridge and application development: a cartridge is just a framework and you will use that framework in your application development. It is clear that you should separate their lifecycle (versioning) correctly. Never mix them! The application just uses that cartridge in a specific version.
5. You introduce MDSD with UML in many small steps, never in big bang: you first introduce UML models in the your smallest and less important Maven projects.
Problems
Still we have some problems in MDSD with UML:
1. For me who's not doing UML daily it is still hard to get into the UML metamodel! BTW. never use the word "metamodel" if you are trying to explain the advantages of MDSD with UML to your management team. As an application developer you actually have less interaction with the UML metamodel. For cartridge developers the UML metamodel with Eclipse UML2 library is a very important thing. Without this you won't be able to generate something useful.
2. There are still less mature cartridges available on the market. AndroMDA has done here a very good job because they have them.
In the meantime I have the feeling that less developers want to use MDSD with UML because they think that MDSD with UML is heavyweight and complex, also code generation is heavyweight and complex. It only has disadvantages. They often forget that someone needs to maintain those applications somehow. Without up-to-date visual documentation of those applications you will definitely have difficulties to be able to maintain your applications reasonably. And if you need to change something quick, since the requirements of your business are also changing fast, you will need those up-to-date documentations. Not mentioning that you are not the one and only person who should be able to extend those applications. Maybe there are some external developers or consultants who should support you? This is where Model Driven Software Development with UML plays its important role.
Back to the problem I found in MDSD tools in the beginning of this article and as a Java's lover (and Polyglot hater), we (Ingo, Markus and I) are proud to be able to release the first version of Open Source MDSD tool KissMDA (Keep It Simple Stupid, MDA!). We hope to introduce the next generation tool of MDSD with UML which is easy, quick, clean to use and 100% Java. Join us to bring MDSD with UML to the next level!
BTW. do you want to try application development with KissMDA in quick and clean way, just in three minutes? Check out this Intro: Introduction for Application Developers: Quick and Clean in Three Minutes.
Discuss with us at Google+ for the first release of KissMDA 1.0.0!
Have a lot of fun!
Lofi.
Past
The first experience with AndroMDA in the year of 2004 was great! At the end you don't need to code those boiler plate codes in EJB 2.x. AndroMDA generates everything for you. You also have the documentation of your application always up to date. This is a very important thing, since if you have more than one hundred entities you definitely need that actual documentation to be able to extend the application. AndroMDA offers a lot of mature cartridges like EJB 2.x, SpringFramework, Struts, Hibernate, JSF. The idea with cartridges is just gorgeous. IMHO it is possible to have a general application architecture for most business applications. So if you are using SpringFramework and Hibernate you can reuse the already written cartridge and you don't need to write your own cartridge. I see no case for your own "architecture" and your own cartridge especially in the area of business applications. This is one of the best thing AndroMDA did for us.
oAW has a different story. There is no reusable cartridges because every persons and companies should build their own architecture and cartridges. This is not a good idea. This is just like when you say that you need your own database system for your "simple" business application.
In year 2006 - high noon of Model Driven Software Development with UML - I thought that we are going into the next level of component reuse in the software development: UML model reuse! Just like what openCRX (Open Source CRM application) has done with their own model driven development tool. But this dream is still a dream until today.
Present
1. I still like AndroMDA, yes the project is very much alive and it has already proven itself to be a strong Open Source project, since AndroMDA has survived the come and go of its comitters. AndroMDA is IMHO the best project in MDA / MDSD area sofar. One problem I see is the complexity of the project. Yes, you need to model the cartridge to build your own cartridge. In the beginning this looks like "eat your own dog food" but at the end it makes the things much more complex to build. Just take a look how you can build your own cartrige in AndroMDA. You also need to use a lot of XML files and elements to configure your cartridge. As an application developer you need all those XML elements to be able configure AndroMDA which makes AndroMDA a configuration monster.
2. oAW has a different story. Until the version 4.3 it seems everything looks very smooth. After the project went to Eclipse it seems that the project has no activity anymore. No news anymore from oAW 5 release. It's really a pitty. The big problem of oAW is also its Domain Specific Language (DSL) Xtend und Xpand (remember: Polyglot Programming sucks!). Since they depend on their own editor capabilities in Eclipse and because the project seems to be dead, you will definitely stuck with Eclipse 3.4! No development anymore in the future.
3. Acceleo is new kids on the block and looks pretty nice. The project is active and alive. The main problem is that it uses a DSL called MOFM2T (MTL) to generate artifacts. You can read the getting started document of Acceleo to understand how Acceleo generator works. Additionally everything in Acceleo is quite Eclipse centered. So you need the MTL editor from Eclipse, imagine if something happens just like oAW. You will stuck with an old Eclipse version!
There are some other MDA / MDSD tools available outside: Taylor, Topcased, openMDX, etc. But all of them suffer the problems I mentioned above.
Experiences and Advantages
In my career as a software developer I see real values using MDSD / MDA. Here are my important experiences:
1. If you are following the best practices in model driven software development with UML your application will have a very good blueprint. This is comparable with the blueprint of your house (application architecture). You still don't get any blueprint for your city planning (enterprise architecture) but this is a good way to begin with. So if you have a lot of houses, you will have a very good documentation of each houses but still you don't have any overview about the city where your houses are built on. In a situation where external developers come and go it is very useful to have a very good documentation of your application architecture.
2. The documentation of your application architecture I mentioned above is always up-to-date. Can you imagine to have 200 entities (database tables) in your application and you don't have any UML class diagram for them? Surely you can say, hey we can generate the UML class diagram from the Java classes. The problem with this approach is that you cannot talked with your business people or your stakeholders until you implement the classes and as you know if you already implement those classes you tend to defend your design. Instead of saying "ohh no problem at all I can just change the name of that class" you will say "ahh c'mon you know what I mean right?". It is a lot of work if you have to change the name of your class especially if it has an impact to your persistence layer (JPA, database tables). Let's imagine if you can just change the name of your class in the UML class model and you can generate your persistence layer. You will still have a lot of work refactoring the rest of your codes but it is less work than without using model driven development.
3. The architecture of your applications is always the same. This is important if you have a lot of applications to be managed. Frameworks like Spring and JPA with Hibernate still give you too much freedom. You can implement your applications in different styles like using XML or only annotations. This will be a problem later as you have to maintain your applications.
4. It is faster to introduce your application structure to external developers and consultants. They learn how to model the entities and services or the domains with UML and generate the skeletons of the codes which they need to implement. In many cases you can generate the persistence layer completely.
From all the points above I can tell you that Model Driven Software Development with UML helps you a lot not only in the beginning as you can start your application development faster but also afterwards in the maintenance phase of your application development.
Best Practices
After a long journey in Model Driven Software Development with UML I can summarize following points to be the best practices (also note this presentation: MDD: the Good, the Bad and the Ugly):
1. Always top-down, never bottom-up, never both directions: you describe your application (entities, services or domains) first with UML. From this you will generate the artifacts (Java, XML, whatsoever). In many cases you will have to extend or implement the generated artifacts.
2. Never edit the generated artifacts, never check-in the generated artifacts into versioning system: you will need different places for your generated and non-generated artifacts. In Maven you have target/generated-sources/java for generated Java artifacts and you can use the Maven phase generate-sources. Never use protected regions, this makes your code unmanageable.
3. UML models are first class citizens in MDSD with UML: you have to handle them with care and you also need an excellent tool for them. Not less than Eclipse or IntelliJ as for Java codes! You need to partition your UML models just like your Java projects so that they won't be too big. Generally I use this practice: one UML model per Java project.
4. Separation of cartridge and application development: a cartridge is just a framework and you will use that framework in your application development. It is clear that you should separate their lifecycle (versioning) correctly. Never mix them! The application just uses that cartridge in a specific version.
5. You introduce MDSD with UML in many small steps, never in big bang: you first introduce UML models in the your smallest and less important Maven projects.
Still we have some problems in MDSD with UML:
1. For me who's not doing UML daily it is still hard to get into the UML metamodel! BTW. never use the word "metamodel" if you are trying to explain the advantages of MDSD with UML to your management team. As an application developer you actually have less interaction with the UML metamodel. For cartridge developers the UML metamodel with Eclipse UML2 library is a very important thing. Without this you won't be able to generate something useful.
2. There are still less mature cartridges available on the market. AndroMDA has done here a very good job because they have them.
3. Tooling's problem. Still there is no very good Open Source UML tool. You have Eclipse Papyrus but still not comparable with the commercial offers. In commercial area you have definitely MagicDraw which is IMO a very good one! If Google just would take care of this problem... ;-)
Conclusion and Future
In the meantime I have the feeling that less developers want to use MDSD with UML because they think that MDSD with UML is heavyweight and complex, also code generation is heavyweight and complex. It only has disadvantages. They often forget that someone needs to maintain those applications somehow. Without up-to-date visual documentation of those applications you will definitely have difficulties to be able to maintain your applications reasonably. And if you need to change something quick, since the requirements of your business are also changing fast, you will need those up-to-date documentations. Not mentioning that you are not the one and only person who should be able to extend those applications. Maybe there are some external developers or consultants who should support you? This is where Model Driven Software Development with UML plays its important role.
Back to the problem I found in MDSD tools in the beginning of this article and as a Java's lover (and Polyglot hater), we (Ingo, Markus and I) are proud to be able to release the first version of Open Source MDSD tool KissMDA (Keep It Simple Stupid, MDA!). We hope to introduce the next generation tool of MDSD with UML which is easy, quick, clean to use and 100% Java. Join us to bring MDSD with UML to the next level!
BTW. do you want to try application development with KissMDA in quick and clean way, just in three minutes? Check out this Intro: Introduction for Application Developers: Quick and Clean in Three Minutes.
Discuss with us at Google+ for the first release of KissMDA 1.0.0!
Have a lot of fun!
Lofi.
Comments