An Infrastructure to Support Interoperability in Reverse Engineering

An infrastructure that supports interoperability among reverse engineering tools and other software tools is described. The three major components of the infrastructure are: (1) a hierarchy of schemas for low- and middle-level program representation graphs, (2) g4re, a tool chain for reverse engineering C++ programs, and (3) a repository of reverse engineering artifacts, including the previous two components, a test suite, and tools, GXL instances, and XSLT transformations for graphs at each level of the hierarchy. The results of two case studies that investigated the space and time costs incurred by the infrastructure are provided. The results of two empirical evaluations that were performed using the api module of g4re, and were focused on computation of object-oriented metrics and three-dimensional visualization of class template diagrams, respectively, are also provided

Bridging Technical Spaces: Model Translation from TA to XMI and Back Again

There are many different techniques and notations for extracting architecturally interesting information from the source code of existing software systems. This process is known as reverse engineering. One current problem with reverse engineering techniques is that models of software systems cannot easily be transferred from one notation and storage format to another. We refer to this as the problem of bridging technical spaces. In this work, we approach the issue of bridging between the SWAG technical space and the UML technical space. The SWAG technical space, named after the Software Architecture Group at the University of Waterloo, consists of fact extractors, fact manipulators, schemas, and a fact storage language - the Tuple-Attribute language (TA). The UML technical space consists of the UML metamodel, the XML Metadata Interchange (XMI) format for encoding UML models, and various UML modeling tools. We have designed and implemented a plugin for MagicDraw UML, which will import, export, and merge between XMI-encoded UML models and TA-encoded Function-Level Schema models. We document evidence of what is referred to as a Bridge Domain - a technical space which exists between two encodable spaces. The metamodels of the two notation languages that we have focused on are very rich and flexible, but neither technical space is capable of fully expressing an accurate architectural model of any given software system; however, each technical space is capable of maintaining certain semantic information relevant to that technical space through multiple merge operations

ProMeTA: A taxonomy for program metamodels in program reverse engineering

ABSTRACT: To support program comprehension, maintenance, and evolution, metamodels are frequently used during program reverse engineering activities to describe and analyze constituents of a program and their relations. Reverse engineering tools often define their own metamodels according to the intended purposes and features. Although each metamodel has its own advantages, its limitations may be addressed by other metamodels. Existing works have evaluated and compared metamodels and tools, but none have considered all the possible characteristics and limitations to provide a comprehensive guideline for classifying, comparing, reusing, and extending program metamodels. To aid practitioners and researchers in classifying, comparing, reusing, and extending program metamodels and their corresponding reverse engineering tools according to the intended goals, we establish a conceptual framework with definitions of program metamodels and related concepts. We confirmed that any reverse engineering activity can be clearly described as a pattern based on the framework from the viewpoint of program metamodels. Then the framework is used to provide a comprehensive taxonomy, named Program Metamodel TAxonomy (ProMeTA), which incorporates newly identified characteristics into those stated in previous works, which were identified via a systematic literature review (SLR) on program metamodels, while keeping the orthogonality of the entire taxonomy. Additionally, we validate the taxonomy in terms of its orthogonality and usefulness through the classification of popular metamodels

Towards multilingual programming environments

Software projects consist of different kinds of artifacts: build files, configuration files, markup files, source code in different software languages, and so on. At the same time, however, most integrated development environments (IDEs) are focused on a single (programming) language. Even if a programming environment supports multiple languages (e.g., Eclipse), IDE features such as cross-referencing, refactoring, or debugging, do not often cross language boundaries. What would it mean for programming environment to be truly multilingual? In this short paper we sketch a vision of a system that integrates IDE support across language boundaries. We propose to build this system on a foundation of unified source code models and metaprogramming. Nevertheless, a number of important and hard research questions still need to be addressed

Towards Multilingual Programming Environments

Software projects consist of different kinds of artifacts: build files, configuration files, markup files, source code in different software languages, and so on. At the same time, however, most integrated development environments (IDEs) are focused on a single (programming) language. Even if a programming environment supports multiple languages (e.g., Eclipse), IDE features such as cross-referencing, refactoring, or debugging, do not often cross language boundaries. What would it mean for programming environment to be truly multilingual? In this short paper we sketch a vision of a system that integrates IDE support across language boundaries. We propose to build this system on a foundation of unified source code models and metaprogramming. Nevertheless, a number of important and hard research questions still need to be addressed