Recovering UML class models from C++: A detailed explanation

Abstract

An approach to recovering design-level UML class models from C++ source code to support program comprehension is presented. A set of mappings are given that focus on accurately identifying such elements as relationship types, multiplicities, and aggregation semantics. These mappings are based on domain knowledge of the C++ language and common programming conventions and idioms. Additionally, formal concept analysis is used to detect design-level attributes of UML classes. An application implementing these mappings is used to reverse engineer a moderately sized, open-source application and the resultant class model is compared against those produced by other UML reverse engineering tools. This comparison shows that the presented mapping rules effectively produce meaningful and semantically accurate UML models.

Introduction

The software industry has widely accepted and often uses UML (Unified Modeling Language) [12] tools in forward engineering, but these tools are used less frequently during software maintenance and evolution. This is due to a number of reasons; foremost among these is that the manual recovery and maintenance of UML models is time-consuming and costly. As such, UML models become stale while the source code continues to evolve. Although many UML modeling tools allow us to reverse engineer UML models from source code, they often perform poorly at this task. A case study of reverse engineering tools [22] finds that many of these tools, despite advances in the research literature, continue to focus on producing the core elements of UML (i.e., simple class diagrams), but often fail to adequately represent design abstractions. This is problematic when recovered software models fail to accurately represent the abstract program semantics required for high-level program comprehension. This problem can be exacerbated by the fact that end users are typically unaware of the internal processes for producing the UML models. This is to say that these tools do not disclose their mechanisms for reverse engineering, which can lead to results that do not meet the end-user’s expectations.

Although this study [22] concludes that these tools provide reliable functionality, the resulting models are anything but consistent. For example, Microsoft Visio is incapable of reverse engineering associations, Visual Paradigm creates dependencies when associations are appropriate, and Rational Rose C++ Modeler creates only aggregate associations (open diamonds in UML). The primary reason for these inconsistencies is the sizeable semantic gap between UML and C++. Although this gap is quite wide, it is by no means unbridgeable. Unfortunately, commonly used reverse engineering tools are closed source systems and provide little information about how UML models are created from C++. This leaves developers to speculate about rationale for the application’s logic. As such, there is no standard “bridge” between C++ and UML, and all reverse engineering tools tend to build their own.

We address this problem by defining a set of mappings for the reverse engineering of UML class models from C++ source code [37], [38]. These mappings employ a combination of C++ syntactic and semantic information along with domain knowledge of programming conventions, idioms, and reuse libraries to produce semantically accurate UML class models. Many of these mappings extend and integrate techniques presented in the literature on this topic. As part of these mappings, a sophisticated information analysis technique (formal concept analysis) is applied to the UML model to recover design-level attributes of classes rather than re-document member variables.

These mappings are implemented in a reverse engineering tool, pilfer, which is used to evaluate the relevance of the defined mappings by reverse engineering a moderately-sized C++ application. The model produced by pilfer is compared against those produced by other tools in order to validate the accuracy and completeness of the defined mappings. Because performance is an important aspect of reverse engineering tools, we also compare pilfer’s run time performance against these tools.

This paper is organized as follows. Section 2 provides a more detailed context of the problem being addressed. Section 3 describes rationale and tradeoffs for each mapping. Section 4 describes the implementation of pilfer. In Section 5, we present a comparison of models generated by pilfer and other reverse engineering tools. Section 6 describes work related to this topic and Section 7 presents our conclusions and future work.