Reverse engineering of the UML class diagram from c++ code in presence of weakly typed containers

Abstract

UML diagrams, and in particular the most frequently used one, the class diagram, represent a valuable source of information even after the delivery of the system, when it enters the maintenance phase. Several tools provide a reverse engineering engine to recover it from the code.In this paper, an algorithm is proposed for the improvement of the accuracy of the UML class diagram extracted from the code. Specifically, important information about inter-class relations may be missed in a reverse engineered class diagram, when weakly typed containers, i.e., containers collecting objects whose type is the top of the inheritance hierarchy, are employed. In fact, the class of the contained objects is not directly known, and therefore no relation with it is apparent from the container declaration.The proposed approach was applied to several software components developed at CERN. Experimental results highlight that a substantial improvement is achieved when the container type information is refined with the inferred data. The number of relations otherwise missed is relevant and the connectivity of the associated class diagrams is radically different when containers are considered.

A review approach to detecting structural consistency violations in programs

“…When a static view and a dynamic view are derived from a program, an abstraction method integrating the techniques in [2] is applied in order to obtain the comparability with the corresponding views of its specification, which includes the following steps: (1) Reuse the specification views as the templates for the program views. For each component (e.g., type, class, process, control structure, data store, data flow) in a specification view, say x, a pair (void, x) is assigned to its corresponding component in the program view; (2) If the reviewer identifies that a component y in the program P is the refinement of the component x in the specification S, change its pair (void, x) to (y, x); (3) If a component y is newly introduced to P , add it to the program view and assign it with the pair (y, void); (4) Determine the directions of relations or data flows in the program views; (5) Remove those components whose pairs have the forms similar to (void, x).…”

Static and dynamic C++ code analysis for the recovery of the object diagram

“…While in the original formulation of the analysis, sets of types are attached to variables, and are updated according to the statements encountered in a flow insensitive visit of the program, in our approach, variables are associated to the objects they reference, and such information is propagated inside the object flow graph, a novel program representation designed specifically for the static analysis we propose. In a previous paper [8], a similar flow analysis algorithm was proposed for the recovery of the class diagram in presence of weakly typed containers, which make the field types unusable for reverse engineering, when fields are containers.…”

Reverse engineering of the interaction diagrams from C++ code

“…Moreover, if the excluded code introduces data flows that alter the OFG, it is necessary to take them into account, in order for the result to be still conservative. An example of this situation is the presence of external container classes [14]. A* indicates that no allocation point for the given object is in the code.…”

“…left hand side, by adopting an approach to container analysis similar to that described in [14]. The edge between Rental-38.…”