Automated Techniques for Reconstructing and Assessing Correspondence between UML Designs and Implementations

Over the years software systems have grown larger and larger. This trend will continue in the future. For many of these systems, the development does not stop once the system passed the acceptance test. Often, new features are added to existing systems at a later stage. The developers that are responsible for the implementation of new features should understand the system before they are able to do their job. System understanding starts at a high level. It is very convenient if not inevitable to use architecture and design models for this. The implementation is far too detailed and voluminous for this purpose. Design models are only useful for understanding however, if the implementation corresponds to these artifacts. It is important for an implementation to correspond to its design. In practice many software systems deviate from their design. Not all deviations are problematic but many systems deviate too much. In this thesis we will present techniques to assess the correspondence between a design and its implementation. We will present a classification of the differences between design and implementation which we found in several case studies. We will give an indication of the severity of these differences. An object oriented software design consists of model elements. Model elements are for instance classes, operations or relations. The implementation also consists of model elements. These are small code fragments that represent the declaration of a class, the definition of an interface or the implementation of a method. Before we can determine how big the differences between design and implementation are, we need to recognize the design model elements in the implementation. To express the similarity between two model elements, we use similarity measures. Similarity values are real values between 0 and 1. Similarity values can be defined for different aspects of a model element. The similarity of a class can thus be measured in different ways. The similarity values that we will discuss are based on the names of the classifiers, the packages in which the classifiers are defined and other structural aspects. These can be the set of operations, the set of attributes and relations with other classes. We will discuss some techniques to establish a matching between design elements and implementation elements. We will find a matching at the level of classifiers. Using similarity values we can use a weighted bipartite matching algorithm for matching. It is also possible to use software metrics for matching. In this approach we try to find a combination of metrics such that each class in a model is distinctive from other classes in that model. This combination is called a metric profile. It can be seen as a fingerprint for a class. Metrics can be calculated for both design and implementation classes. Metrics in the profiles must be correlating. Given the metric profile of a design class it is then possible to predict the metric profile of the implementation class that would match best to the design class. This predicted profile is compared with the metric profiles of real implementation classes. The difference between the real profile of a class and the predicted profile, can be expressed by a