Benefits of using UML models in software maintenance?

Question

What are the key benefits of using UML models in software maintenance? I came across only few handful of papers regarding costs and benefits of UML models in software maintenance.

Answer 1

Imagine this:

Intro

you are a programmer assigned to do a maintenance of large legacy code base (thousands of files, damn many lines of code, written during several past years by several different people who had already go away, coding conventions and class libraries had changed several times during the original development)

Nobody likes that work, it is boring and repetitive so people are trying to get away as soon as they can and do some fresh and shiny development in some hype cool language. You are a 'junior maintainer' and so are most of your co-workers, so you have no wizard to ask and get magic fast and correct answers to your newbie questions.

The code is structured into many different files, many different classes (e.g. in Java to read the code of 20 classes you have to open 20 different files. In C in order to read the code you always have to read 2 files at the same time *.h and *.c, etc.)

Now you have to troubleshoot some problem. You are able to reproduce it in the test lab so you pick a debugger and start hunting the problem, where does the control and data flow and where is the hidden failure (may be some assert will fail or may be you'll spot something 'oh what a stupid bug' with your hawk eye).

Nightmare

No assert failed and you did not spot anything because it is C++ code and saying "hello" in C++ takes about 10 crypto graphy sentences where the "hello" is just in the middle. Most of the code is not written in the language you know but in a language of macros you have never heard about and calls to methods of classes you have never heard about.

Moreover you find out there are several code flows (threads) running at the same time and the data packet you are trying to track gets somewhere marshaled and queued for another thread to process and the debugger stopped at a waiting lock.

You're trying to picture what is going on using the debugger, patiently stepping into the unknown and taking notes on what the different words mean.

After several days of debugging, pulling your hair, cursing all the developers before you, seriously thinking about quitting this job

Relieve

you find some documentation. Someone wrote it using human words, designed for humans to read, explaining the basic concepts, giving links to places in code and other explaining documents and there are even some pictures in the docs.

And you look at the picture (UML diagram or some other pre-UML diagram) and now you can see where does the data flow, what are some of the classes you have already met supposed to do and where are the places you should look.

And you find that the UML diagrams saved you both many dead neurons but also countless hours of reading the code. As instead of reading and understanding thousands of lines of code you can just read hundreds of lines of explaining documents or read just several explaining pictures.

Conclusion

Powered by that new 'I see' knowledge you put breakpoints at several key places, inspect the variable values and you find that at this place X should not be 1. Because the docs said ... and you already know what are the dependencies of the X variable. So you put several other conditional breakpoints around and you finally find a bug in the logic as now the code flows through some combination of conditions that was not foreseen.

So you change few letters in one line of code, the bug is fixed, you have deserved your salary. The maintenance job is not such a nightmare anymore (though you still think about quitting the job) and the UML pictures helped.

So you draw some more UML-style diagrams explaining various inter dependencies (that you have learned the hard way) first using paper and pencil as small documentation one day is better than no documentation ever http://agilemodeling.com/essays/documentLate.htm

---

I know the conclusion is partially a sci-fi. As no maintainer will actually go and start creating missing documentation for a system that is going to be replaced in several years by newer and shinier. (s)he will just auto-create some UML diagrams by reverse engineering the code, throw them away after use and quit the job as soon as possible

But you get the picture of benefits of using UML models in software maintenance regarding costs?

Answer 2

UML can ALWAYS be usefull in software related activity, but you must know what you are doing rather than using it because "my boss says UML is cool!".

Benefits of UML can depend on many factors. In some situations it is likely to be more beneficial. I try to mention some of them.

Likely to be more beneficial:

• Larger and complexer is your subject, more benefit you can expect. Especialy when they are relationship between different aspects
• If this SW maintenance means some extra development/extension, it could be very useful to use UML to clarify it. You can show existing system and the way it should be extended. You can of course always show the nre reqs.
• if your system is already modelled in UML, you can use it to locate the problem and plan further enhancements
• if both modeller and model reader know OO and have some experience in UML, they will almost always make it beneficial.
• if you want to generate some code further more
• if you need to support a system with no documentation, it could be usefull to document it first (use reverse engineering to import the code and organize it in UML)
• if you plan to mainain this system for a long time and with lots of people

Maybe not so beneficial:

• if the maintenance does not involve intensive extension/programming
• if the subject under maintenance is too small - it can be more efficient to use natural languege or even spoken word
• if either the person who models or who uses the diagram later is not skilled in OO and UML. If none of them is, forget about using UML and start learning it :)
• if you already have some other kind of documentation