Feeds:
Posts
Comments

Archive for May, 2009

In this entry I wanted to share my thoughts on how Agile MDA can be used for the 99% of projects that don’t have the luxury of being new Greenfield Blue Sky developments.

The Reality of the Real World

I am sure we have all experienced joining a new company or transferring to a new team and being assigned to a project that has an existing code base.  Usually the code base, often your company’s flagship product, has been careful crafted, lovingly maintained and nurtured over a number of years.

Being a top-down kind of person, one of the first questions I ask is ‘can you show me the architecture’? This is met with varying reactions ranging from embarrassed laughter to frenzied scribbling on a whiteboard.  It is very unlikely, in fact I have never encountered, that a set of up to date UML diagrams representing the current state of the application will be produced.  In more mature organizations, if we are lucky, we may be pointed at a file directory containing the detailed design documentation for the various components that have been implemented over the years.  Naturally these are never maintained, as there isn’t time.

So as a new team member you are usually left to familiarize yourself with the code under the careful guidance of a developer who is experienced with the code base of the application.  As familiarity builds you may fix a few simple bugs and after a few weeks or months enough confidence may be established to implement some functional enhancement or even new components.  Most of these changes are made directly to the code without a formal design and review process being followed.

The above is an illustration of the reality for the majority of us.  We are rarely in the position to be starting from scratch.  So how can we start picking ourselves up by the bootstraps to improve our productivity?  In this type of environment it appears to be next to impossible to introduce improved productivity techniques such as Agile MDA.

Architecture Modernization, Software Archaeology and Surveying

Many people assume that MDA is only suitable for brand new implementations where code is generated fresh from a model. If your recall a tool like Bluprint allows existing code to be merged with the engineering model describing the software.  In order to perform code merging, Bluprint internally constructs a model representing the existing code.  The model of the existing code is then merged from with the engineering model.  It is from the merged model that the new code is then generated.

Now imagine the situation where we do not have an engineering model, e.g. an existing code base without a description of its design – much like the scenario we described earlier.  You can see that Bluprint would still work in this case as Bluprint would create a model of the existing code that when merged with an empty or nil engineering model would remain the same.  If we could preserve the resulting model, we would have uncovered the original blueprint for the code.

This is incredibly useful because now we have bootstrapped ourselves by creating a description of the application code in the form a model.  We can then proceed to maintain the application by making changes to our newly recovered model.  At this point it would be as if we had been using Agile MDA all along.

The process of model recovery is sometimes called Software Archaeology, but often I like to think of it as more like software surveying as it is consistent with the metaphor of a model blueprint.  The Object Management Group (OMG) has a task force looking specifically at evolving software assets using model driven approaches.  It operates under the rather grand title of Architecture-Driven Modernization (ADM).

Some pragmatics

Part of the value of adopting MDA is to have a diagrammatic representation of the application.  When recovering a model from its code, there is no diagrammatic representation for it.  As a consequence any recovery tool will need to automatically generate this.  This presents a few challenged, as what is the best approach generating the model diagram?  Many software products, especially UML modelling tools, incorporate function to automatically layout a model diagram.  However no matter how sophisticated they are, they can never perform this in a satisfactory manner. It will always require manual tweaking afterwards.  From practical experience, it is better for the tool to create an initial layout of the model in diagrammatic form, but to realise that this will then be subsequently rearranged.

If we were creating a UML model from a code base, such as Java, we would create a class diagram for each package.  On each class diagram the classes that inherit from each other would be arranged in balanced class hierarchy trees.  Classes from other packages would also be included on the diagram if there are direct associations from the classes within the package represented by the diagram.  Theses external classes would be placed at the periphery of the diagram.

The layout of associations is a complex problem to solve and this is where most tools flounder.  If is difficult to design an algorithm that ensures the lines representing associations avoid crossing over or under other classes and that also minimise the number of times these lines cross.  In practice it is better to include all associations as straight lines, creating a tangled web of lines and to assume that an engineer will manually rearrange these in their modelling tool.  This usually only takes a few minutes to perform.  Once an engineer has rearranged a diagram its layout can be saved and preserved.  By rearranging the diagram, engineers also start to familiarize themselves with the structure of the application.

Enabling Bluprint for ADM

Currently Bluprint contains most of the components needed for deployment within existing software implementations.  As described previously it currently constructs internally a model of the existing code when it is creating code from a model.  However it does not contain the components for generating the diagrammatic representation of the constructed model or for a means of persisting it.  These changes are currently in the works and I will keep you abreast of developments.

Read Full Post »