James M. Bieman

Cohesion and reuse in an object-oriented system

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.

Rapid prototyping: lessons learned

Opinions on rapid prototyping as a practical development tool vary widely, with conventional wisdom seeing it more as a research topic than a workable method. The authors counter this notion with results from 39 case studies, most of which have used this approach successfully. >

Directives for composing aspect-oriented design class models

An aspect-oriented design model consists of a set of aspect models and a primary model. Each aspect model describes a feature that crosscuts elements in the primary model. Aspect and primary models are composed to obtain an integrated design view. In this paper we describe a composition approach that utilizes a merging algorithm and composition directives. Composition directives are used when the default merging algorithm is known or expected to yield incorrect models. Our prototype tool supports default class diagram composition.

The FreeBSD project: a replication case study of open source development

Case studies can help to validate claims that open source software development produces higher quality software at lower cost than traditional commercial development. One problem inherent in case studies are external validity - we do not know whether or not results from one case study apply to another development project. We gain or lose confidence in case study results when similar case studies are conducted on other projects. This case study of the FreeBSD project, a long-lived open source project, provides further understanding of open source development. The paper details a method for mining repositories and querying project participants to retrieve key process information. The FreeBSD development process is fairly well-defined with proscribed methods for determining developer responsibilities, dealing with enhancements and defects, and managing releases. Compared to the Apache project, FreeBSD uses 1) a smaller set of core developers - developers who control the code base - that implement a smaller percentage of the system, 2) a larger set of top developers to implement 80 percent of the system, and 3) a more well-defined testing process. FreeBSD and Apache have a similar ratio of core developers to people involved in adapting and debugging the system and people who report problems. Both systems have similar defect densities and the developers are also users in both systems.

Measuring design-level cohesion

Cohesion was first introduced as a software attribute that, when measured, could be used to predict properties of implementations that would be created from a given design. Unfortunately, cohesion, as originally defined, could not be objectively assessed, while more recently developed objective cohesion measures depend on code-level information. We show that association-based and slice-based approaches can be used to measure cohesion using only design-level information. An analytical and empirical analysis shows that the design-level measures correspond closely with code-level cohesion measures. They can be used as predictors of or surrogates for the code-level measures. The design-level cohesion measures are formally defined, have been implemented, and can support software design, maintenance and restructuring.

Design patterns and change proneness: an examination of five evolving systems

Design patterns are recognized, named solutions to common design problems. The use of the most commonly referenced design patterns should promote adaptable and reusable program code. When a system evolves, changes to code involving a design pattern should, in theory, consist of creating new concrete classes that are extensions or subclasses of previously existing classes. Changes should not, in theory, involve direct modifications to the classes in prior versions that play roles in a design patterns. We studied five systems, three proprietary systems and two open source systems, to identify the observable effects of the use of design patterns in early versions on changes that occur as the systems evolve. In four of the five systems, pattern classes are more rather than less change prone. Pattern classes in one of the systems were less change prone. These results held up after normalizing for the effect of class size - larger classes are more change prone in two of the five systems. These results provide insight into how design patterns are actually used, and should help us to learn to develop software designs that are more easily adapted.

A philosophy for software measurement

Abstract We as a group—called the Grubstake Group—are convinced that software measures are essential for “controlling” software. Thus, we are dedicated to producing an environment in which software measures can be confidently used by software managers and programmers. However, we are also convinced that such an environment can only be created if there exists a formal and rigorous foundation for software measurement. This foundation will not have to be understood by the users of the software measures, but it will have to be understood by those who define, validate, and provide tool support for the measures. It is this foundation that we are introducing in this article.

The relationship between test coverage and reliability

Models the relationship between testing effort, coverage and reliability, and presents a logarithmic model that relates testing effort to test coverage: statement (or block) coverage, branch (or decision) coverage, computation use (c-use) coverage, or predicate use (p-use) coverage. The model is based on the hypothesis that the enumerables (like branches or blocks) for any coverage measure have different detectability, just like the individual defects. This model allows us to relate a test coverage measure directly to the defect coverage. Data sets for programs with real defects are used to validate the model. The results are consistent with the known inclusion relationships among block, branch and p-use coverage measures. We show how the defect density controls the time-to-next-failure. The model can eliminate variables like the test application strategy from consideration. It is suitable for high-reliability applications where automatic (or manual) test generation is used to cover enemerables which have not yet been tested.<<ETX>>

Software architecture classification for estimating the cost of COTS integration

The use of commercial-off-the-shelf (COTS) products creates a software integration problem, whether a single COTS software component is being integrated into a software system, or the whole system is being built primarily from COTS products. This integration may require considerable effort and affect system quality. A good estimate of integration cost can help in the decision of whether or not to use a COTS solution, the selection of the best COTS products, and determine the amount and type of glueware that needs to be built, in this paper, we introduce a set of variables that have the potential to estimate the integration cost. We present a classification scheme of software architectures with respect to the integration of COTS products. The scheme is based on inter-component interactions within software architectures. The classification scheme allows the comparison of integration costs of different COTS products relative to different software architectures.

Understanding change-proneness in OO software through visualization

During software evolution, adaptive, and corrective maintenance are common reasons for changes. Often such changes cluster around key components. It is therefore important to analyze the frequency of changes to individual classes, but, more importantly, to also identify and show related changes in multiple classes. Frequent changes in clusters of classes may be due to their importance, due to the underlying architecture or due to chronic problems. Knowing where those change-prone clusters are can help focus attention, identify targets for re-engineering and thus provide product-based information to steer maintenance processes. This paper describes a method to identify and visualize classes and class interactions that are the most change-prone. The method was applied to a commercial embedded, real-time software system. It is object-oriented software that was developed using design patterns.