: Bente Anda and Kai HansenVenue
: Proceedings of the 2006 ACM/IEEEInternational Symposium on Empirical Software Engineering,Date
Pages: 124 - 133
This paper was a case study on a software project at ABB -- a large global company with
more than 100,000 employees in over 100 countries. ABB decided to try and improve
their software projects through the use of UML. The took a project with 3-4 million
lines of C and C++ code and improve it using UML. There were 230 employees on the project,
100 of whom ended up using UML on the project. They were in two main groups: those
improving legacy code and those writing new code to be added to the code base. A questionnaire
was handed out to 55 of those 100 employees, 42 returned the questionnaire and 28 of
those were used in the study (the 14 others had worked on both legacy code and new code
so those doing the study left them out in order to compare the legacy code group with the
new code group).
Three types of UML diagrams were used (use case, sequence, and class diagrams). In all
cases, the legacy team had a harder time with the UML diagrams but they were still able
to get some benefit from it. Documenting actors in use cases and constructing sequence
diagrams were the only places where the new group found constructing the diagrams to be easy.
In all of the other cases, both groups found it to be difficult but the legacy group
generally found it to be more difficult. An interesting difference between the diagrams
in the two groups was that the legacy group tended to put a lot more detail in their
diagrams making them far less useful for presenting an overview of the system.
Interestingly enough, neither group felt that modelling use cases helped improve the design
of the system. However, both groups found them to be a great aid in the functional testing
of the software. Both groups felt that the sequence diagrams had a positive effect on the
code design -- though the legacy group experienced fewer benefits than the new group. Both
groups found the sequence groups to be of benefit in integration testing. The new group
felt that the class diagrams had a positive effect on the system design. The legacy group
felt the same, but far less strongly. Both groups found the class diagrams to be useful
in unit testing. Both groups found that using UML diagrams in discussions helped
in discussing the system design. One interesting thing to note is that both groups thought
that UML lacked expressive power with respect to such things as loops and guard conditions.
All in all, it was found that using UML diagrams in legacy code was particularly difficult
but that it does have some benefits -- particularly in testing. On the other hand, using UML
to write code from scratch tends to get much greater benefits from the UML diagrams.