TigerTeam TRIMM - Model Driven Generator just went Open Source

TigerTeam TRIMM – Model Driven Generator is just Open Sourced in July 2013. I myself never heard of this product before and found this product by coincidence as I tried to find a JPA 2 standalone cartridge / generator available in Internet. I know that AndroMDA has some cartridges to persist Java objects but as far as I know AndroMDA only support persistence in the context of EJB 3 not as standalone JPA.

After I found this product I began to analyze the code at Bitbucket.org and found out that the idea with the Events and Listeners as Extensions is a very good idea. TRIMM also uses Maven completely and does not have any dependencies to Eclipse plugins, so you are Eclipse independent. Special to this framework is that it uses its own metamodel and does not use UML2 metamodel for the generators. TRIMM should work for MagicDraw and Enterprise Architect and it can read the files directly from those UML tools. It also uses its own Java code generator which is basically based on String outputs. A very good thing is that TRIMM offers some ready to use cartridges like Java, JPA 2 and Webservice.

It seems that TRIMM does not suffer the problems I mentioned in my older Java article at Java Lobby post and uses almost the same approach of KissMDA. Following are the differences I can see in a glance:

(1) TRIMM is using its own Java generator which is basically based on String outputs and this is not the best way to generate Java codes. Using Eclipse JDT is a lot more easier and you always get syntactically correct Java codes which can be easily unit tested like this KissMDA example.

(2) Interesting to compare the transformers for Java code generation. In TRIMM you have the class JavaGenerator.java. In KissMDA you use the class SimpleJavaTransformer.java. They both are the main entering point for the generation of Java codes. Both classes look quite similar from the way of doing the works they need to do. Using DI framework like Guice in KissMDA makes the code more readable and easier to understand.

(3) Unit tests are crucial in KissMDA. The simple Java cartridge has in the mean time about 35 test cases. This is possible because we use Mockito extensively. TRIMM Java cartridge has also some unit tests which are not many in comparison with the available implementation classes.

I really like the idea of using Events and Listeners to plug the extensions. In this context I will try to write the next KissMDA cartridge which will be a JPA 2 cartridge using Events, Event Bus and Listeners. As a foundation I will use this easy and simple Event Binder framework: GWT Event Binder. In the mean time I found some Open Source Event Bus implementations like Guava and MBassador. This is a good blog which compares those Event Bus frameworks: Java Event Bus Library Comparison. My choice is MBassador because it supports Weak References in Event Bus.

Congratulation to the team of TRIMM and I  think, it is a very good move to Open Source TRIMM. I wish all the best for the future of TRIMM!

CDI vs. Spring Framework Core

Another question I got in my Spring Framework training is: is it worthwhile to switch from Spring Framework 3.x to CDI with JBoss Weld or Apache OpenWebBeans implementation?

After googling around I found some good articles and blogs about this topic. These two articles are the best in my opinion:

• Spring DI and CDI Comparative Study
• CDI 1.0 vs. Spring 3.1 feature comparsion: bean definition & dependency injection

Luckily I had a chance to take a CDI course intensively for two days to be able to see what we actually could do with CDI. After doing two days intensive course of CDI I can sum up this topic as following:

• CDI takes a lot of good idea of Spring Framework, this is for sure.
• Anything you can do with CDI (I used JBoss Weld in the course I followed) is not new and you can have those stuffs in Spring Framework as well.
• In CDI 1.0 (JEE 6) there is still a lot of things which is not supported natively such as "scanning of classes and packages" to turn on the dependency injection. Sure you can use CDI portable extensions to support such a functionality but the problem with those extensions is just like Eclipse plugins: you never know whether all of the plugins can work smoothly together if they are not written by one person or one vendor.

Additionally to the articles and blogs above I found following extensions for Spring Framework to support following CDI mechanism:

(1) Events with @Observes: take a look at this Open Source project which extends Spring capability: spring-event-annotations.

(2) Decorator with @Decorator and @Delegate: take a look at this blog and Open Source project: JSR-299 CDI Decorators for Spring beans.

(3) Interceptor with @Interceptor, @InterceptorBinding, @AroundInvoke and @Nonbinding: take a look at this article: JSR-299 CDI Interceptors for Spring Beans.

(4) Custom bean scope: take a look at this article: Custom scopes in CDI 1.0 and Spring 3.1.

(5) Type-safe injection: take a look at this blog: Type-safe dependency injection in Spring 3 IoC-Container.

At the end I have to admit that you won't miss anything if you are using Spring Framework. It is definitely more mature than any other Context and Dependency Injection containers available on the market. So if you ask me whether it is worthwhile to switch from Spring Framework Core to CDI implementation like JBoss Weld I would say: no.There is also no economically reasons to switch to CDI implementation if you are already use Spring Framework. Try explain to your management that you want to switch to CDI just because it is standard, no other advantages and also with less functionality and maturity. Surely you should use the standard Annotations within Spring Framework, so instead of @Autowired you should use @Inject for example. In some ways I see Spring Framework Core as "the" reference implementation of CDI specification.

Cheers,
Lofi.

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 DynamicObjectAspect {

    // This comes from the property file 

@Value("#{objects.object}")

private String object;

@Inject

private ApplicationContext applicationContext;

@Pointcut("execution(@your.package.InjectDynamicObject * *(..))")

public void beanAnnotatedWithInjectDynamicObject() {

}

@Around("beanAnnotatedWithInjectDynamicObject()")

public Object adviceBeanAnnotatedWithInjectDynamicObject(

ProceedingJoinPoint pjp) throws Throwable {

Object returnResult = pjp.proceed();

       // Create the bean or object depends on the property file

Object createdObject = applicationContext.getBean(object);

return createdObject;

}

}

...

4. Write your unit test to test the method:

...

    @Test

public void testCustomerOnlineOrOffline() {

// Dynamic object creation

System.out.println("DYNAMIC CUSTOMER: "

+ customerBo.getDynamicCustomer().getName());

}

...

OK, there is another easier way to do this ;-) Without Aspects and AspectJ, just pure Spring:

Just inject all your component implementations into a Map and get the correct implementation out of it. Just like what we have done in eXTra Client application. Please take a look at our implementation of PluginsLocatorManager as an example: http://goo.gl/itpcb. Spring injects the Map with Bean name as String and the Bean itself automagically. "... Even typed Maps can be autowired as long as the expected key type is String. The Map values will contain all beans of the expected type, and the keys will contain the corresponding bean names" (see Spring documentation for details).

...

@Named("customerBo")

public class CustomerBoImpl implements CustomerBo {

...
    // We inject the customer implementations into a Map
    @Inject
    private Map<String, Customer> customerDynamicMap;

    // This comes from the property file as a key for the Map

@Value("#{objects.object}")

private String object;

    
    @Override

  public Customer getDynamicCustomer() {

        return this.customerDynamicMap.get(object);

}

...

Have fun!

Lofi

Software Development Macro and Micro Process

If you think that in year 2012 all companies which produce software and IT divisions in our world have already their optimized software development process, you are wrong. It seems that we - software architects, software developers or whatever your title is - still need to optimize the software development process in many software companies and IT divisions.

So what do you do if you enter a software company or IT division and you see following things:

1. There is a perfect project management process to handle all those development of software but it is a pure project management without a context to software development. So basically you only take care of cost, time, budget and quality factors. In the software development you still use the old fashioned waterfall process.

2. From the tooling point of view: you have a project management planning and controlling tool but you are still in the beginning of Wiki (almost no collaboration tool) and you don't use issues tracking system to handle all the issues for the development of your software components and applications. You use Winword and Excel to define your requirements and you cannot transform them to your software products since you don't have any isssues tracking system. No chance to have traceability from your requirements down to your issues to be done in your software components and applications.

3. Maven is already used but with a lot customization and not intuitively used. The idea of using a concrete already released version of dependencies was not implemented. Instead you always open all the dependently projects in Eclipse. You can imagine how slow Eclipse works since you need to open a lot of projects at once although you only work for one project. Versioning in Maven is also not used correctly e.g.: no SNAPSHOT for development versions.

4. As you work with webapp you always need to redeploy to the application server. No possibility to hot deploy the webapp. Use ctrl-s, see your changes and continue to work without new deployment is just a dream and not available.

Luckily as an experienced software architect and developer we know that we can optimize the two main software development processes:

1. Software Development Macro Process (SDMaP): this is the overall software development lifecycle. In this process model we define our requirements, we execute analysis, design, implementation, test and we deploy the software into production. Waterfall process model and agile process model like RUP and Scrum are examples of SDMaP.

2. Software Development Micro Process (SDMiP): this is the daily work of a software developer. How a software developer works to develop the software. A software developer codes, refactors, compiles, tests, runs, debugs, packages and deploys the software.

More information on SDMaP and SDMiP:

• You can find the definition of SDMaP and SDMiP in the context of analysis and design in the book  Object-Oriented Analysis and Design with Applications from Grady Booch, et. al.
• Unifying Microprocess and Macroprocess Research 
• Effects of Architecture and Technical Development Process on Micro-Process

The picture below shows the SDMaP and SDMiP in combination. The macro (SDMaP) and micro (SDMiP) process meet at the implementation phase and activity. So changing and optimizing one has definitely side effects on the other one and vice versa.

At the example of organization mentioned above it is important that we optimize both processes since they work hand in hand. So how can the optimization for macro and micro process looks like?

1. SDMaP:

• Introduce Wiki for IT divisions and software companies. You can use WikIT42 to make the structure of your Wiki and use Confluence as your Wiki platform.
• Introduce Wiki with issue tracking like JIRA and combine both of them to track your requirements.
• Refine the requirements into issues (features, tasks, bugs, etc.) to the level of the software components and applications, because at the end you will implement all the requirements using your software components and applications.
• Introduce iterative software development lifecycle instead of waterfall process. This is a long way to go since you need to change the culture of the company and you need a full support from your management.

2. SDMiP

• Update the Maven projects to use the standard Maven mechanism and best practices with no exception. Transform the structure of the old Maven to the new standard Maven using frameworks like MoveToMaven. 
• Use Maven release plugin to standardize the release mechanism of all Maven projects.
• Use m2e Eclipse plugin to optimize your daily work as a software developer under Eclipse and Maven.
• Use Mylyn to integrate your issue tracking system like JIRA into your Eclipse IDE.
• Introduce JRebel to be able to hot deploy quickly your webapps into the application server.

Optimizing macro and micro process for software development is not an easy task. In the macro process you need to handle all those relationships with other divisions like Business Requirements, Quality Assurance and Project Management divisions. You need to convince them that your SDMaP optimization is the best way to go. This is more an organizational challenge and changes than the micro process optimization.

The micro process is also not easy to optimize, since you need to convince all developers that they can be more productive with the new way of working than before. You need to show them that it is a lot more faster if you don't open a lot of Java projects within your Eclipse workspace. Also using JRebel to deploy your webapp to your application server is the best way to go. Normally developers are technical oriented, so if you can show them the cool things to make, they will join your way.

New Article about MDA at heise.de

Checkout my newest article about Model Driven Software Development with UML and Java at heise.de (in German language): Modellgetriebene Softwareentwicklung mit UML und Java - Besser als der Ruf.

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.

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.

Open Data Initiative and Mashup

Just finishing playing with Open Data Initiative Berlin and Google Maps... Mashup with GWT using the newest Google Maps GWT (gwt-maps 3.8.0-pre1)... Very nice! All in all I used following technologies:

• Java (what else?)
• Maven 3
• GWT (Google Web Toolkit) with gwt-maps 3.8.0-pre1 for Google Maps V3
• GAE (Google App Engine)

Within this mashup I combined the Open Data from Berlin: 

1. Total population 2011 per area (Berlin Mitte, Berlin Spandau, etc.)
2. Result of Election 2011 per area

... and put them into Google Maps. You can find all the links in my WebApp: http://opendataberlin.appspot.com

I found out following things as I implemented the WebApp:

• Open Data Berlin needs to take care of their Open Data API. For the total population I need to get the Zip file, uncompress it and read the CSV file inside it, using Common Compress and OpenCSV Java Open Source library. For the result of election I have to work with Excel file using JExcel, also Open Source library. Amazing to see how complicated they did it! Please just use XML and JSON as the data format and define a usable REST API for this!
• Open Data Initiative itself does not make any sense for many of us. We need applications (WebApp and MobileApp) on the top! And this is where mashup helps a lot.

Check this out (in German language): http://opendataberlin.appspot.com