Defining and testing migration rules

Well, it's not too late yet so: Happy New Year!

Today I want to tell you about migration rules and how to automate them.
When dealing with migration projects, we apply a process determined to best suit its context.
Though each project is particular, some things never change. For example, we define migration rules, and this is actually an important part of every automated migration project.

What is a migration rule?
It's the specification of what one wants to get in the target architecture from a given concept present in the original architecture.
In migration project, such rules are automated whenever it makes sense, assuming that it is feasible (actually, determining what is feasible is a whole subject in itself, but that's another story).
As any artifact in a development process, a migration rule must be:

• specified
• tested (which assumes it must be testable)
• implemented

Moreover, non-regression testing is extremely important in this kind of project. Migration rules have a nasty way of interacting with each others, and it's utterly important to be able to check that the modification of a rule does not impact another. We want to make sure we have the whole migration process under control.

Finally, reporting is important as well. You want to know which rules have been applied, how many times, and where: such a feedback is precious once again to make sure the process is under control.

So? So, we're currently developing some tooling to help us achieve this. In a few words, we're (partly) automating the process we used to apply manually until now.

This tooling will allow us to specify, implement, test, ensure non-regression, and report about the execution of the rules developed in a migration project.

More details and screenshots soon!

Acceleo 3 and properties

Since I'm often brought to develop acceleo generators, I often had to design my templates so that they can be easily parameterized by users.
This is important since by doing so, acceleo modules are flexible enough to fit my users needs and (hopefully) I don't have to update modules too often.
Of course, you need to carefully design your templates to achieve this modularity. But for simple needs, simple solutions are the best.
Acceleo natively supports the use of properties files which is an efficient and simple way to parameterize generation module: Properties are generally simple to understand and users can use them easily.
Well, Acceleo 3 is out, and of course properties are still supported. I just wanted to point out something I stumble upon just recently: Properties files are now accessed via the java ResourceBundle mechanism. And consequently, they need to be in the classpath in order to be accessed at runtime.
So, as a module developer, you'll place your default properties files (those you provide with your modules in order to have a sensible default behavior) in a package of your module project.
Well, don't forget to check that this package is exported at runtime, otherwise your properties won't be accessible when you run your generations!


You probably already know how to do it but just in case: open the META-INF/MANIFEST.MF file, and in the Runtime tab just add the package(s) that contain your properties files.
And since you need to do this also for your entry point templates, it may be a good idea to place default properties files in the same package as the entry point template files?

Eclipse foundation launches SOA working group

The eclipse foundation just officially announced a new working group on SOA. At this occasion, a new release of the eclipse SOA platform is available.

The official annoucement can be read here:
http://www.prweb.com/releases/2010/04/prweb3901804.htm
http://www.eclipse.org/org/press-release/20100421_soaiwg.php

I am thrilled by this initiative because I foresee it will, in a near future, help to modernize information systems, in an appropriate and perennial way. We at Obeo will certainly work in that direction!

What is a legacy software?

Of course, it's not a new question.
Wikipedia tells us the following:

A legacy system is an old method, technology, computer system, or application program that continues to be used, typically because it still functions for the users' needs, even though newer technology or more efficient methods of performing a task are now available.

Since I'm a software engineer I'm not really concerned about legacy systems in general, just about legacy software.
Joel SPOLSKY gives another definition of the term "legacy" in the preface to the book "Micro-ISV: From Vision to Reality" by Bob WALSH, which can be read online (the preface, not the book) at this page of Joel's famous blog.

It’s like that other term, legacy, that Microsoft uses to refer to all non-Microsoft software. So when they refer to Google, say, as a “legacy search engine” they are trying to imply that Google is merely “an old, crappy search engine that you’re still using by historical accident, until you bow to the inevitable and switch to MSN.” Whatever.

What I like in this definition (beyond the humourous content) is that it clearly states a feeling which is strongly associated to the term "legacy" in the software industry: old and crappy.
Here we are.
How come software systems that are the result of years of hard work look like they're old, crappy, in short, boring?

Another commonly accepted definition is:

Software we don't know what to do with, but it's still performing a useful job (Faisal BIN BASHIR, 1998)

Well, this definition is not quite right: legacy software generally performs not just a useful but an indispensable job. And we know what to do with them, just let them run!
What we don't know is let newer software communicate with them. Such as, integrate them in this brand new portal of ours. Or offer some behavior as services...
Well, nothing new, really.
Nevertheless, I'll continue investigating here why the subject of software modernization keeps comings back as a pain in the... er... as a painful subject, even though the software industry keeps gaining experience and maturity.
Why is there no solution (isn't there, really?), and what could be done about it?
Because in my humble opinion, "legacy" is just the future of any valuable software...
By the way, why am I talking about this?
Well, my present position at Obeo consists in developing the software modernization activity at Obeo.
So I thought it might be interesting to talk about how we work on this problematics, the tools we use (among which Acceleo is of course our favorite code generator), and the methods we put in place.