This paper describes ongoing work toward the development of a standard software exchange format (SEF), for exchanging information among tools that analyze computer programs. A particular exchange format called GXL (Graph Exchange Language) is proposed. GXL can be viewed as a merger of well known formats (e. g. GraX, PROGRES, RPA, RSF, and TA) for exchanging typed, attributed, directed graphs. By using XML as notation, GXL offers a scaleable and adaptable means to facilitate interoperability of reengineering tools.

Software inspection is a known technique for improving software quality. It involves carefully examining the code, the design, and the documentation of software and checking these for aspects that are known to be potentially problematic based on past experience. Code smells are a metaphor to describe patterns that are generally associated with bad design and bad programming practices. Originally, code smells are used to find the places in software that could benefit from refactoring. In this paper, we investigate how the quality of code can be automatically assessed by checking for the presence of code smells and how this approach can contribute to automatic code inspection. We present an approach for the automatic detection and visualization of code smells and discuss how this approach can be used in the design of a software inspection tool. We illustrate the feasibility of our approach with the development of jCOSMO, a prototype code smell browser that detects and visualizes code smells in JAVA source code. Finally, we show how this tool was applied in a case study. Keywords: software inspection, quality assurance, Java, refactoring, code smells.

Many software systems do not have a documented system architecture. These are often large, complex systems that are difficult to understand and maintain. One approach to recov-ering the understanding of a system is to extract architectural documentation from the system implementation. To evaluate the effectiveness of this approach, we extracted architectural documentation from the LinuxTM kernel. The Linux kernel is a good candidate for a case study because it is a large (800 KLOC) system that is in widespread use and it is represen-tative of many existing systems. Our study resulted in docu-mentation that is useful for understanding the Linux system structure. Also, we learned several useful lessons about ex-tracting a system’s architecture. Keywords Software architecture, architecture recovery, redocumenta-tion 1

Abstract—In systems developed without aspect-oriented programming, code implementing a crosscutting concern may be spread over many different parts of a system. Identifying such code automatically could be of great help during maintenance of the system. First of all, it allows a developer to more easily find the places in the code that must be changed when the concern changes and, thus, makes such changes less time consuming and less prone to errors. Second, it allows the code to be refactored to an aspect-oriented solution, thereby improving its modularity. In this paper, we evaluate the suitability of clone detection as a technique for the identification of crosscutting concerns. To that end, we manually identify five specific crosscutting concerns in an industrial C system and analyze to what extent clone detection is capable of finding them. We consider our results as a stepping stone toward an automated “aspect miner ” based on clone detection. Index Terms—Clone detection, reverse engineering, aspect-oriented programming, crosscutting concerns, aspect mining. 1

Authentic descriptions of a software architecture are required as a reliable foundation for any but trivial changes to a system. Far too often, architecture descriptions of existing systems are out of sync with the implementation. If they are, they must be reconstructed. There are many existing techniques for reconstructing individual architecture views, but no information about how to select views for reconstruction, or about process aspects of architecture reconstruction in general. In this paper we describe view-driven process for reconstructing software architecture that fills this gap. To describe Symphony, we present and compare different case studies, thus serving a secondary goal of sharing real-life reconstruction experience. The Symphony process incorporates the state of the practice, where reconstruction is problemdriven and uses a rich set of architecture views. Symphony provides a common framework for reporting reconstruction experiences and for comparing reconstruction approaches. Finally, it is a vehicle for exposing and demarcating research problems in software architecture reconstruction.

Web applications are the legacy software of the future. Developed under tight schedules, with high employee turn over, and in a rapidly evolving environment, these systems are often poorly structured and poorly documented. Maintaining such systems is problematic. This paper presents an approach to recover the architecture of such systems, in order to make maintenance more manageable. Our lightweight approach is flexible and retargetable to the various technologies that are used in developing web applications. The approach extracts the structure of dynamic web applications and shows the interaction between their various components such as databases, distributed objects, and web pages. The recovery process uses a set of specialized extractors to analyze the source code and binaries of web applications. The extracted data is manipulated to reduce the complexity of the architectural diagrams. Developers can use the extracted architecture to gain a better understanding of web applications and to assist in their maintenance. Keywords Web Applications, Software Architecture, Reverse Engineering, Architecture Recovery, Re-documentation. 1

A number of standalone tools are designed to help developers understand software systems. These tools operate at different levels of abstraction, from low level source code to software architectures. Although recent proposals have suggested how code-level frameworks can share information, little attention has been given to the problem of connecting software architecture level frameworks. In this paper, we describe the TAXForm exchange format for frameworks at the software architecture level. By defining mappings between TAXForm and formats that are used within existing frameworks, we show how TAXForm can be used as a "binding glue" to achieve interoperability between these frameworks without having to modify their internal structure.

Many analyses of software systems can be formalized as relational queries, for example the detection of design patterns, of patterns of problematic design, of code clones, of dead code, and of differences between the as-built and the as-designed architecture. This paper describes the concepts of CrocoPat, a tool for querying and manipulating relations. CrocoPat is easy to use, because of its simple query and manipulation language based on predicate calculus, and its simple file format for relations. CrocoPat is efficient, because it internally represents relations as binary decision diagrams, a data structure that is well-known as a compact representation of large relations in computer-aided verification. CrocoPat is general, because it manipulates not only graphs (i.e. binary relations), but n-ary relations.

This paper presents a technique for recovering the high level design of legacy software systems according to user defined architectural plans. Architectural plans are represented using a description language and specify system components and their interfaces. Such descriptions are viewed as queries that are applied on a large data base which stores information extracted from the source code of the subject legacy system. Data mining techniques and a modified branch and bound search algorithm are used to control the matching process, by which the query is satisfied and query variables are instantiated. The matching process allows the alternative results to be ranked according to data mining associations and clustering techniques and, finally, be presented to the user. 1 Introduction Software maintenance constitutes a major part of the software life-cycle. Most maintenance tasks require a decomposition of the legacy system into modules and functional units. One approach to architectura...

In order to understand, analyze and possibly modify software, we commonly examine and manipulate its architecture. For example, we may want to examine the architecture at different levels of abstraction or repair the architecture if it has deviated from our mental model of the software. We can view such manipulations as architectural transformations, and more specifically, as graph transformations. In this paper, we use graph rewriting to specify these transformations so that we can work towards automating them. Specifically, we use the PROGRES tool to formulate executable graph-rewriting specifications for various architectural transformations in order to demonstrate the strengths of using graph rewriting. We have applied our executable specifications to small graphs and our results confirm the following: Graph rewriting offers a high-level, visual notation that can be used to neatly specify graph modifications as well as support prototype implementation. It also provides a convenient...