This paper presents a method to view a system as a hierarchy of modules according to information hiding concepts and to identify architectural component candidates in this hierarchy. The result of the method eases the understanding of a system's underlying software architecture. A prototype tool implementing this method was applied to three systems written in C (each over 30 Kloc). For one of these systems, an author of the system created an architectural description. The components generated by our method correspond to those of this architectural description in almost all cases. For the other two systems, most of the components resulting from the method correspond to meaningful system abstractions. 1. Introduction It is well known that programmer efforts are mostly devoted to maintaining systems [Corb89, Somm92]. A large portion of that maintenance effort is spent in understanding the program and data [Yau80]. Within this context, helping maintainers to understand the legacy systems...

Code duplication, plausibly caused by copying source code and slightly modifying it, is often observed in large systems.

One of the factors that can make a program difficult to understand is that code responsible for accomplishing more than one purpose may be woven together in a single section. We call this interleaving, and it may arise either intentionally -- for example, in optimizing a program, a programmer may use some intermediate result for several purposes -- or unintentionally, due to patches, quick fixes, or other hasty maintenance practices. To understand this phenomenon, we have looked at a variety of interleaving instances in actual programs and have distilled characteristic features. If the characterization proves to be robust then it will enable the design of tools for detection of interleavings and the extraction of the individual strands of computation.

Program understanding is the process of making sense of a complex source code. This process has been considered as computationally difficult and conceptually complex. So far, no formal complexity results have been presented, and conceptual models differ from one researcher to the next. In this paper we formally prove that program understanding is NP-hard. Furthermore, we show that even a much simpler subproblem remains NP-hard. However, we do not despair by this result, but rather, offer an attractive problem-solving model for the program understanding problem. Our model is built on a framework for solving Constraint Satisfaction Problems, or CSPs, which are known to have interesting heuristic solutions. Specifically, we can represent and heuristically address previous and new heuristic approaches to the program understanding problem with both existing and specially designed constraint propagation and search algorithms. 1 Introduction An expert attempts to understand the source code ...

We generate a native pattern language from a context-free grammar. So if we have the underlying grammar of code that needs to be analyzed, or renovated the pattern language comes for free. We use native patterns for recognition and renovation of code. The pattern language is global in the sense that patterns can match entire programs. We illustrate native patterns by discussing a tool that remediates a notoriously difficult Year 2000 problem using native patterns. Categories and Subject Description: D.2.6 [Software Engineering ]: Programming Environments---Interactive; D.2.7 [Software Engineering]: Distribution and Maintenance--- Restructuring; D.3.4. [Processors]: Parsing. Additional Key Words and Phrases: Reengineering, System renovation, Patterns, Plans, Clich'es, Native pattern language, Year 2000 problem, Leap year problem. 1 Introduction One key task in reengineering software is the recognition of problematic code. For example, for Year 2000 related remediation, it is necessa...

When programmers perform maintenance tasks, program understanding is required. One of the first activities in understanding a software system is identifying its subsystems and their relations, i.e. its software architecture. Since a large part of the effort is spent in creating a mental model of the system under study, tools can help maintainers in managing the evolution of legacy systems, by showing them architectural information. In this paper, an environment for the architectural analysis of software systems is described. The environment is based on a hierarchical architectural model that drives the application of a set of recognizers, each producing a different architectural view of the system or of some of its parts. Recognizers embody knowledge about architectural clich'es and use flow analysis techniques to make their output more accurate. 1

The large size and high-percentage of domain-specific code in most legacy systems makes it unlikely that automated understanding tools will be able to completely understand them. Yet automated tools can clearly recognize portions of the design. That suggests exploring environments in which programmer and system work together to understand legacy software. This paper describes such an environment that supports programmer and system cooperating to extract an object-oriented design from legacy software systems. It combines an automated program understanding component that recognizes standard implementations of domain independent plans with with a structured notebook that the programmer uses to link object-oriented design primitives to arbitrary source code fragments. This jointly extracted information is used to support conceptual queries about the program's code and design. 1 Introduction The standard goal of most program understanding efforts is a tool that takes source code and extrac...

Code duplication, plausibly caused by copying source code and slightly modifying it, is often observed in large systems.

Complex programs often contain multiple, interwoven strands of computation, each responsible for accomplishing a distinct goal. The individual strands responsible for each goal are typically delocalized and overlap rather than being composed in a simple linear sequence. We refer to these code fragments as being interleaved. Interleaving may be intentional–for example, in optimizing a program, a programmer might use some intermediate result for several purposes–or it may creep into a program unintentionally, due to patches, quick fixes, or other hasty maintenance practices. To understand this phenomenon, we have looked at a variety of instances of interleaving in actual programs and have distilled characteristic features. This paper presents our characterization of interleaving and the implications it has for tools that detect certain classes of interleaving and extract the individual strands of computation. Our exploration of interleaving has been done in the context of a case study of a corpus of production mathematical software, written in Fortran from the Jet Propulsion Laboratory. This paper also describes our experiences in developing tools to detect specific classes of interleaving in this software, driven by the need to enhance a formal description of this software library’s components. The description, in turn aids in the automated component-based synthesis of software using the library.

Sentences of visual languages may often be regarded as assemblies of pictorial objects like "circles", "arrows" or "strings" with spatial relations like "above" or "contains" between them, i.e. their underlying structure is a kind of directed graph. Therefore, graph grammars are a natural means for defining the syntax of visual languages. Their main drawback until now is the lack of general enough and efficiently working parsing algorithms. All published graph grammar or ---more general--- visual language parsing algorithms are only able to deal with context-free graph grammars, where the left-hand side consists of a single nonterminal vertex only. This makes syntax definitions of visual languages hard to read, prohibits the use of complex pattern matching, and disallows graph-grammars which specify transformation processes. We have developed the first parsing algorithm for context-sensitive graph grammars which allows left- and right-sides of productions to be almost arbitrary graphs....