Extracting UML from Legacy Applications - James Taylor's Decision Management

« What characterises a good decision service? | Main | Business rules and the application knowledge deficit »

March 30, 2007
Extracting UML from Legacy Applications

I saw this nicely written article - Extracting UML from Legacy Applications by Richard Soley and Mike Oara over on SOA Magazine. While they do a nice job explaining how you can use legacy modernization tools and UML to modernize applications, especially in terms of what you can and cannot automate, the lack of rules in UML is a real limiting factor. Without a way to represent business rules clearly in the UML diagrams you extract, I think one of the key drivers of the code you have (your business rules) will be hard to extract. For instance, Richard and Mike say of requirements:

While the current system may implement business requirements, they may not appear explicitly in the code, but rather in the form of fulfilled requirements

This is even more true of business rules. The rules are most unlikely to be explicit in your code - that's one of the reasons I recommend the use of a business rules management system for implementing business rules - they are also not requirements and should not be managed as such. For instance, use cases should refer to business rules and not embed them so that the rules can be managed, updated and reused across use cases (see this book for more on this).

I also have to take issue with something the authors say about completeness. They say:

As a legacy application is modified and enhanced over the years users often lose a complete understanding of how the application functions. For example, in a pension system the rules for computing the pension can be spread through numerous government and corporate policy documents. This knowledge is already in the code, which is more complete, precise, and concise than what would come from user interviews.

Here I disagree. In general, relying on code to accurately represent policies and regulations is a poor alternative, just like interviews. The actual regulations and policies are the place to go. The code is useful for telling you what is currently being enforced (or not) but it is often over-used as a source of business rules. Barb von Halle provoked a fairly spirited discussion this on my other blog if you want a variety of opinions.

This is why I chair an OMG standards group and why I am working with other vendors (including ILOG, Corticon, Tibco and IBM) to develop a production rule standard (known as the Production Rule Representation) for business rules. Then legacy modernization to UML could include building the production rules you have in your system and managing them properly.

Technorati Tags: BRMS, business rules, legacy modernization, requirements, UML