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.

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

Software Inspection is a technique for detecting flaws in software before deployment. It was introduced by Fagan in 1976 [12], and since then its use has spread widely. Despite the widespread adoption and success of software

The increased popularity of the object-oriented paradigm has also increased the interest in object-oriented reengineering. First of all, object-oriented software systems suffer from similar maintainability problems as traditional procedural systems, displaying the need for reengineering techniques tailored to deal with ob- ject-oriented code. Secondly, the increased importance of iterative development processes make reengi- neering techniques valuable in forward engineering, and thus for all paradigms that software is developed in. Reengineering requires tool support to deal with the large amounts of information and the wide variety of tasks to be performed. An important consideration in building tool environments for reengineering is what information must be provided and how this information is modelled. Design choices have a consider- able impact not only on the ability to support reengineering tasks, but also on issues such as scalability and tool interoperability. Several metamodels exist that model software for the purposes of reengineering. How- ever, they generally lack a discussion of the relevance of information for reengineering and the trade-offs of modeling alternatives. This thesis presents FAMIX, a language-independent metamodel for modelling object-oriented soft- ware for reengineering purposes. We discuss the exact contents of the metamodel, including its relevance for reengineering and how the metamodel supports the different object-oriented languages through its lan- guage-independent core. We also discuss the infrastructural design decisions of FAMIX by placing it into a design space for infrastructural aspects of reengineering repositories and metamodels. The design space presents multiple interdependent aspects, their design alternatives and how these impact issues such as scal- ability, extensibility and information exchange. We validate the ability of FAMIX to support reengineering on a language-independent level in two ways. First, we present Moose, a reengineering tool environment with a repository based on FAMIX. Moose serves as a foundation for multiple reengineering tools and has been applied to reverse engineer several large industrial case studies. Secondly, we define a set of fifteen low-level refactorings in terms of the infor- mation available in FAMIX. Refactoring requires sufficient, complete and 100% correct information as well as a clear interpretation of the supported languages in the language-independent core of the metamod- el, in order to correctly perform transformations on the language-specific code level. As such the refactor- ings provide an in-depth validation of the language independence of FAMIX.

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

Abstract not found

By the early 1990s the need for reengineering legacy systems was already acute, but recently the demand has increased significantly with the shift toward web-based user interfaces. The demand by all business sectors to adapt their information systems to the Web has created a tremendous need for methods, tools, and infrastructures to evolve and exploit existing applications efficiently and cost-effectively. Reverse engineering has been heralded as one of the most promising technologies to combat this legacy systems problem. This paper

Software architecture visualization tools tend to support browsing, that is, exploration by following concepts. If architectural diagrams are to be used during daily software maintenance tasks, these tools also need to support specific fact-finding through searching. Searching is essential to program comprehension and hypothesis testing. Furthermore, searching allows users to reverse the abstractions in architectural diagrams and access facts in the underlying program code. In this paper, we consider the problem of searching and browsing software architectures using perspectives from information retrieval and program comprehension. After analyzing our own user studies and results from the literature, we propose a solution: the Searchable Bookshelf, an architecture visualization tool that supports both navigation styles. We also present a prototype of our tool which is an extension of an existing architecture visualization tool.

Recent research suggests that large software systems should have a documented system architecture. One form of documentation that may help describe the structure of software systems is the organization of the developers that designed and implemented the software system. We suggest