We define and apply two new measures of object-oriented class cohesion to a reasonably large C++ system. We find that most of the classes are quite cohesive, but that the classes that are reused more frequently via inheritance exhibit clearly lower cohesion. 1 Introduction Software developers aim for systems with high cohesion and low coupling. The value of these goals has not been validated empirically [6]. Rather, they have been justified on the basis of intuition. The amount of reuse --- the number of times that a component is reused --- is an indicator of reusability. Of course, other factors such as the usefulness of a component are also components of reusability. Cohesion refers to the "relatedness" of module components. A highly cohesive component is one with one basic function. It should be difficult to split a cohesive component. Cohesion can be classified using an ordinal scale that ranges from the least desirable category--- coincidental cohesion---to the most desirable--...

We present an approach for the generation of components for a software renovation factory. These components are generated from a context-free grammar definition that recognizes the code that has to be renovated. We generate analysis and transformation components that can be instantiated with a specific transformation or analysis task. We apply our approach to COBOL and we discuss the construction of realistic software renovation components using our approach.

Many reverse-engineering tools have been developed to derive abstract representations from source code. Yet, most of these tools completely ignore recovery of the all-important rationale behind the design decisions that have led to its physical shape. Design patterns capture the rationale behind proven design solutions and discuss the trade-offs among their alternatives. We argue that it is these patterns of thought that are at the root of many of the key elements of large-scale software systems, and that, in order to comprehend these systems, we need to recover and understand the patterns on which they were built. In this paper, we present our environment for the reverse engineering of design components based on the structural descriptions of design patterns. We give an overview of the environment, explain three case studies, and discuss how pattern-based reverse-engineering helped gain insight into the design rationale of some of the pieces of three large-scale C++ software systems. Keywords Reverse-engineering, design recovery, design component,

Software engineers maintaining an existing software system often depend on the mechanized extraction of information from system artifacts. Some useful kinds of information—source models—are well known: call graphs, file dependences, etc. Predicting every kind of source model that a software engineer may need is impossible. We have developed a lightweight approach for generating flexible and tolerant source model extractors from lexical specifications. The approach is lightweight in that the specifications are relatively small and easy to write. It is flexible in that there are few constraints on the kinds of artifacts from which source models are extracted (e.g., we can extract from source code, structured data files, documentation, etc.). It is tolerant in that there are few constraints on the condition of the artifacts. For example, we can extract from source that cannot necessarily be compiled. Our approach extends the kinds of source models that can be easily produced from lexical information while avoiding the constraints and brittleness of most parser-based approaches. We have developed tools to support this approach and applied the tools to the extraction of a number of different source models (file dependences, event interactions, call graphs) from a variety of system artifacts (C, C��, CLOS, Eiffel, TCL, structured data). We discuss our approach and describe

Component-based software development has proven effective for systems implementation in well-understood application domains, but is still insufficient for the creation of reusable and changeable software architectures. Design patterns address these shortcomings by capturing the expertise that is necessary for reusable design solutions. However, there is so far no methodical approach to providing these conceptual design building blocks in a tangible and composable form. To address this limitation, we introduce the notion of design components, reified design patterns fit for software composition. In this paper, we define design components and explain their constituents and services. Furthermore, we detail the activities of design composition and illustrate them as a process within a four-dimensional design space. Moreover, we describe a prototype of a design composition environment. A case study helps illustrating our approach.

C++ is an expressive language, but it does not allow software developers to say all the things about their systems that they need to be able to say. In particular, C++ offers no way to express many important constraints on a system's design, implementation, and presentation. In this paper, we describe CCEL, a metalanguage for C++ that allows software developers to express constraints on C++ designs and implementations, and we describe Clean++, a system that checks C++ code for violations of CCEL constraints. CCEL is designed for practical, real-world use, and the examples in this paper demonstrate its power and flexibility.

Reverse engineers depend on the automatic extraction of information from source code. Some useful kinds of information---source models---are wellknown: call graphs, file dependences, etc. Predicting every kind of source model that a reverse engineer may need is impossible. We have developed a lightweight approach for generating flexible and tolerant source model extractors from lexical specifications. The approach is lightweight in that the specifications are relatively small and easy to write. It is flexible in that there are few constraints on the information in the source that can be extracted (e.g., we can extract from macros, comments, etc.). It is tolerant in that information can be extracted from source that cannot necessarily be compiled or linked. In essence, we scan for source constructs that contribute to the specified source model while ignoring constructs that do not contribute to that source model. We have developed tools to support this approach and applied the tools to ...

Security vulnerabilities often result from buffer overflows. A testing technique that instruments programs with code that keeps track of memory buffers, and checks arguments to functions to determine if they satisfy certain conditions, warns when a buffer overflow may occur. It does so when executed with ”normal ” test data as opposed to test data designed to trigger buffer overflows. A tool using this method was developed and evaluated by testing three widely used, open source software packages. This evaluation shows that the tool is useful for finding buffer overflow flaws, that it has a low false positive rate, and compares well with other techniques. 1

Abstract not found

To effectively perform a change to an existing software system, a software engineer needs to have some understanding of the structure of the system. All too often, though, an engineer must proceed to change a system without sufficient structural information because existing software understanding techniques are unable to help the engineer acquire the desired knowledge within the time and cost constraints specified for the task. The thesis of this research is that an approach based on summarization can overcome the limitations associated with existing approaches, enabling an engineer to assess, plan, and execute changes to a software system more effectively. Summarization involves the production of overviews of vast amounts of user-selected information in a timely manner. I describe two tech...