Posts Tagged ‘AndroMDA’

Things have been a little quiet lately in blog-world as I have been incubating an open source model driven project – watch this space. This has been motivated after taking a look at AndroMDA. Although AndroMDA is excellent I have a number of quibbles. Some of these aren’t unique just to AndroMDA.

  1. Lack of ‘eating your own dog food’. If an MDA tool is worth its salt, surely it must be capable of being used to generate itself from a model. None of the tools that I have seen contain a UML model that describes the software that can be used to generate itself. Obviously there needs to be a bootstrapping process, but once the kernel of the tool is written it can be used to further refine and develop the tool.

    It would be a pretty good acid test, since it would prove that the tool is sophisticated and pragmatic enough to develop a moderately complex application. It addition it would be put through its paces as the model for the application would go through multiple edit, generate and test cycles. (Oh did I mention Agile-MDA? MDA doesn’t preclude being used within an agile development project. I’ll expand upon Agile-MDA in a future blog entry if there is interest.).

  2. AndroMDA makes use of stereotypes to help drive the code generation process. For example the classes within a model being used to represent entities, those classes that are to be made persistent, are flagged with the «entity» stereotype. This helps direct the code generator to create the appropriate persistent code. To this end, the model must include the AndroMDA profile containing the valid AndroMDA stereotypes.

    Although the use of stereotypes provides expressiveness, it does mean that there is a deviation between the classes represented in the model and classes that get generated as code. The MDA purists would argue that this level of abstraction and transformation is acceptable.

    I personally prefer adopted a WYSIWIG (what you see is what you get) approach, where the model is a pretty faithful representation of the classes that will be generated. For example it is possible to model the frameworks and APIs that will be exploited by the implementation model. I argue that by modelling the frameworks and APIs you get a better insight into the structure of that which is being extended and used. In this way you can see clearly the relationship between the classes in your model and those of the frameworks that you’ll exploit.

  3. I’m not a fan of using inheritance to separate generated code and developer written code. We all realise that to be pragmatic, that developers will need to write code in addition to that which is generated. UML (+OCL) isn’t practical for detailed program description.
    Tools like AndroMDA allow developer written code to be contained in an ‘implementation’ class that inherits from a generated class. The generated class can be changed and regenerated, without loosing the developer written code in the inherited implementations class.

    Simple Inheritance
    However this creates an artificial separation between the generated and user written code. If I wish to sub-class the generated class, I can, but I will loose the extensions in the developer written implementation class. There are techniques for getting around this, but this is an extra burden which most developers cannot be bothered with.

    The answer I feel is not to use sub-classing, but to allow developer written code and generated code to be contained within the same class. The tool should be able to merge user written code with generated code so that no developer written code is lost. This is also in line with my previous point, that the model represents more closely what is being generated.

  4. Support of OO concepts. Most tools like AndorMDA can generate simple attributes and accessors (getters/setters). For example if I have a Customer class and an attribute called ‘id’ of type long, this will be faithfully generated. However when we start to use more complex modelling constructs such as a 1 to many association between classes or qualified associations these tools do not provide much assistance.

    Customer and Product
    For instance if the afore mentioned Customer class is associated with a Product class via a 1 to many association as shown, most tools will for create something like the following when generating code for Java,

    public Vector products = new Vector();

    Sometimes it may be declared private and a pair of accessors to the products variable will be provided. However in both cases, the implementation generated does not enforce encapsulation, something as all good OO practitioners we know is a good thing and would want.

    What would be better, would be for the collection to be encapsulated and for the following kind of interface with corresponding implementation to be generated,

    public void addProduct( Product aProduct );
    public void removeProduct( Product aProduct );
    public Iterator getProductsIterator();

    And perhaps optionally,

    public int getProductsSize();
    public Product getProductAt( int index );

    Notice that we don’t break encapsulation. We can add and remove Products to the Customer, and we also provide mechanisms for iterating over the Products associated with the Customer.

    In an ideal world we would also like qualified UML associations to also be supported. These are very useful for representing key, value pairs between classes.

    With this, a lot of boilerplate code can be generated removing the burden from the developer and enabling then to concentrate on creating the unique business logic.

Read Full Post »


AndroMDA is an open source model driven architecture project, which is both surprisingly sophisticated and mature.  It allows, for instance, complete J2EE applications to be created from UML models.  The user-interface, business logic and persistence tiers can all be generated.  It supports both BPM4Struts and JSF UI frameworks, Spring, EJBs and Hibernate.  It even has the ability to generate .NET code.  Given its sophistication, I am surprised it isn’t more extensively used.

In summary AndroMDA is a transformation engine, taking as input a UML model in XMI format containing the UML 1.4 metamodel, and a set of pluggable cartridges.  Each cartridge uniquely transformations the model into output code.  There are separate cartridges for example for jBPM, Hibernate, Spring and EJBs.

Version 3.3 of AndroMDA provides full Maven integration, so the configuration and operation of the tool is very much simplified.  The Maven automation allows new AndroMDA projects to be created, for these to be developed and subsequently deploy.

Virtually any UML tool can be used.  I have been using AndroMDA quite happily with MagicDraw 16.0 CE.  The AndroMDA site includes a UML tool support matrix, however this seems a little out of date.

Installing AndroMDA
The installation of AndroMDA in a Windows environment can be found at the AndroMDA site.  I have successfully installed and operated AndroMDA on my Mac under Mac OS X 10.5 (Leopard).  It works surprisingly well.  Below are outlined the installation steps for AndroMDA 3.3 on a Mac which mirror those for Windows.

To set up the AndroMDA development environment you will need to install:

  • Maven
  • AndroMDA itself
  • A UML Tool such as MagicDraw
  • An IDE such as Eclipse

For the run-time environment you’ll need:

  • A J2EE Application Service such as JBoss
  • A database, MySQL on the Mac works excellently

Maven Installation

  1. Download Maven from here, http://maven.apache.org/download.html.  I installed and been using version 2.0.9.
  2. Unzip the contents and place it in a folder such as /Users/peterlong/usr/Java.
  3. Create a, or edit your existing, .bash_profile in your home directory (~) so that it includes the following

  4. export M2_HOME=/Users/peterlong/usr/Java/apache-maven-2.0.9
    export M2=$M2_HOME/bin
    export M2_REPO=/Users/.m2/repository
    export MAVEN_OPTS=’-XX:MaxPermSize=128m -Xmx512m’
    export JAVA_HOME=/Library/Java/Home/
    export JBOSS_HOME=/Applications/jboss-4.2.3.GA
    export PATH=$PATH:$M2

Seeing Hidden Files within the Mac Finder

By default on a Mac the Finder does not show hidden files and directories that are prefixed with a dot/period (‘.’).  Within a Terminal window use the following so that hidden files can be seen.

defaults write com.apple.finder AppleShowAllFiles TRUE
killall Finder

To disable the display of these hidden files perform the following.

defaults write com.apple.finder AppleShowAllFiles FALSE
killall Finder

Testing the Maven Installation

  1. Open a Terminal window.
  2. Create a temporary project directory, say ~/usr/java/test
  3. cd to the directory and test execution of the maven command with
    mvn –version
    Something similar to the following should have been produced.
    Maven version: 2.0.9
    Java version: 1.5.0_16
    OS name: “mac os x” version: “10.5.6” arch: “i386” Family: “unix”
  4. If this is successful, test the creation of a temporary project, by issuing the following
    mvn archetype:create -DgroupId=testapp -DartifactId=testapp
    After a minute or so you should see
    [INFO] ———————————————————–
    [INFO] Using following parameters for creating OldArchetype: maven-archetype-quickstart:RELEASE
    [INFO] ———————————————————–
    [INFO] Parameter: groupId, Value: testapp
    [INFO] Parameter: packageName, Value: testapp
    [INFO] Parameter: basedir, Value: /Users/peterlong/usr/java/test
    [INFO] Parameter: package, Value: testapp
    [INFO] Parameter: version, Value: 1.0-SNAPSHOT
    [INFO] Parameter: artifactId, Value: testapp
    [INFO] ********************* End of debug info from resources from generated POM ***********************
    [INFO] OldArchetype created in dir: /Users/peterlong/usr/java/test/testapp
    [INFO] ———————————————————–
    [INFO] ———————————————————–
    [INFO] Total time: 1 minute 6 seconds
    [INFO] Finished at: Wed Jan 28 16:47:17 GMT 2009
    [INFO] Final Memory: 7M/14M
    [INFO] ———————————————————–
  5. Check that you got BUILD SUCCESSFUL and that a testapp directory was set up containing the corresponding project files.
  6. Delete the test directory when you are finished as you have successfully set up the Maven environment.

Install the AndroMDA application plugin

  1. Download the AndroMDA Maven plug-in from here.
  2. Unzip the contents and place the org folder into the Maven repository, in my case /Users/peterlong/usr/Java/repo.
    Now we need to build our plugin.
  3. Create temporary directory for building andromda, say ~/Java/andromda
  4. Create the following pom.xml file in this newly created directory

    <name>AndroMDA Repository</name>
    <name>AndroMDA Repository</name>
  5. Run Maven, by just issuing the mvn command in that directory.
    You should get BUILD SUCCESSFUL as before,
    [INFO] [compiler:compile]
    [INFO] No sources to compile
    [INFO] ————————————————————–
    [INFO] ————————————————————–
    [INFO] Total time: 26 seconds
    [INFO] Finished at: Wed Jan 28 17:23:23 GMT 2009
    [INFO] Final Memory: 4M/8M
    [INFO] ————————————————————–
  6. Delete the temporary directory when you have finished.

Install a UML tool
I have installed MagicDraw on my Mac, it works surprisingly well (it is a Java app after all).  I am using MagicDraw 16.0 community edition.

Note that the projects generated by AndroMDA have a dependency on a number of AndroMDA profiles.  MagicDraw expects to find these in the Maven Repository.  For some reason although the directory structure was there, the required xml.zip files were missing.  I manually copied these from the AndroMDA installation profiles directory to the .m2 repository.

I had to copy the following files:

Installing Eclipse
Download and install Eclipse for Mac OS X from http://www.eclipse.org/downloads/.
Installing JBoss on Mac
This is really straight forward.

  1. Download JBoss from http://www.jboss.org/jbossas/downloads/.  I have successfully deployed and used 4.2.3 GA.
  2. Unzip the file and move the contents to your chosen installation directory.  I put mine in /Applications.
  3. Edit .bash_profile so that JBOSS_HOME is defined, for example include the following:
    export JBOSS_HOME=/Applications/jboss-4.2.3.GA

Installing MySQL

  1. Download the latest community edition of MySQL from http://www.mysql.com/.  At the time of writing this is 5.1.31.  Download the version for Mac OS X 10.5 i86.   I elected to use the package installer version rather than tar.
  2. Once downloaded, open the disk image.  The readme file tells you what to do.  Basically double click on the mysql-5.1.31-osx10.5-x86.pkg.  This is an option for installing the auto-start by clicking on the MySQLStartupItem.pkg.  We’ll skip this for now.
  3. Once installed, you can start MySQL using the following (if auto start hasn’t been used).
    cd /usr/local/mysql
    sudo ./bin/mysqld_safe
  4. Modify your ~/.bash_profile with the following
    export MYSQL=/usr/local/mysql/bin
    export PATH=$PATH:$MYSQL
  5. This will enable the mysql and mysqladmin commands to be used directly without having to specify the full path.
  6. Download the MySQL GUI Tools from http://dev.mysql.com/downloads/gui-tools/5.0.html.  Again I elected to choose the Mac OS X version.
  7. Open the Disk Image and drag the MySQL Tools folder into Applications.
  8. Download the MySQL Connector/J from http://www.mysql.com/products/connector/j/.  I chose the latest 5.1.7.zip.
  9. Unzip the file and copy the mysql-connector-java-5.1.7-bin.jar file to your JBoss Server installation into server/default/lib.  In my case I am using JBoss 4.2.3.  In the process I changed the file name so that it didn’t contain ‘-bin’.

Testing your AndroMDA environment
The AndroMDA site includes a comprehensive tutorial for the creation of a complete J2EE application which includes a Web UI and MySQL backend database, called TimeTracker.  Follow the steps outlined in the TimeTracker tutorial to verify your installation.  Note that you won’t need to installation the MySQL driver if you have followed the steps above.

Read Full Post »

In this and subsequent posts I will expand of upon the themes of putting the engineering back into software development.  Along the way I’ll introduce you to some practical tools and techniques.

I passionately believe that Model Driven Development (MDD) and Model Driven Architecture (MDA) represent one viable approach.  This belief is born from practical experience and success in delivering software using such techniques.  Kalido’s Business Information Modeler, a .NET application was built using MDD.

There is a wealth of material already written on MDA especially by the Object Management Group (OMG).  However it is written in a pretty dry, formal way that is often impenetrable to the casual reader.  In summary MDA is all about driving the generation of software from models, models that are pictures, models that represent the blueprint for the software.  That’s it, the ability to produce software using a higher level abstraction other than just the code.

MDA and MDD have many benefits including:

  • It enables rapid prototyping.  I can sketch a model and produce working software quickly.
  • It enables iterative development.  I can tweak my model and regenerate my application frequently.
  • It breaks the disconnection between design and implementation.  No longer will I have design diagrams that are out of date once the code is written.  I can see a picture, the blueprint, of the software that is actually executing.
  • It increases productivity and quality.  Changes to the model will cause amendments to be made to the code systematically, without error prone manual intervention.

The models in MDA can come in any form, however the use of UML, a modelling notation, is a good popular approach.  UML models can be drawn by hand or more practically using a tool.  I can highly recommend MagicDraw as a UML tool, which I have successfully used for a number of years.  You can download the community edition for free and it even works on my Mac.

Now creating pictures of software can be a pretty fruitless activity.  In the past developers had to translate these diagrams manually into code.  This was a labour intensive activity and often only preformed once as it was so laborious.  It was next to impossible to ensure that subsequent changes to models could be reliably reflected in the software.  The majority of engineers soon abandoned the use of UML and went to straight coding.

There are many tools that can be used for translating models into code.  In the next post I will examine one of these in more detail, the open source software AndroMDA.

Read Full Post »