Symposium on Software Reusability 

About: Symposium on Software Reusability is an academic conference. The conference publishes majorly in the area(s): Reuse & Component-based software engineering. Over the lifetime, 109 publications have been published by the conference receiving 3829 citations.

Cohesion and reuse in an object-oriented system

Abstract: 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.

PuLSE: a methodology to develop software product lines

Abstract: Software product lines have recently been introduced as one of the most promising advances for efficient software development. Yet upon close examination, there are few guidelines or methodologies available to develop and deploy product lines beyond existing domain engineering approaches. The latter have had mixed success within commercial enterprises because of their deployment complexity, lack of customizability, and especially their misplaced focus, that is on domains as opposed to products. To tackle these problems we developed the PuLSETM (Product Line Software Engineering) methodology for the purpose of enabling the conception and deployment of software product lines within a large variety of enterprise contexts. This is achieved via product-centric focus throughout the phases of PuLSETM, customizability of its components, incremental introduction capability, maturity scale for structured evolution, and adaptations to a few main product development situations. PuLSETM is the result of a bottom-up effort: the methodology captures and leverages the results (the lessons learned) from our technology transfer activities with our industrial customers. We present in this paper the main ideas behind PuLSETM and illustrate the methodology with a running example taken from our transfer experience.

Implementing product line variabilities

Abstract: Software product lines have numerous members. Thus, a product line infrastructure must cover various systems. This is the significant difference to usual software systems and the reason for additional requirements on the various assets present during software product line engineering. It is imperative that they support the description of the product line as a whole, as well as its instantiation for the derivation of individual products.Literature has already addressed how to create and instantiate generic product line assets, such as domain models and architectures to generate instance specific ones [1, 2, 3], yet little attention has been given on how to actually deal with this genericity at the code level.This paper addresses the issue of handling product line variability at the code level. To this end various implementation approaches are examined with respect to their use in a product line context.

Measuring experimental error in microprocessor simulation

Abstract: We measure the experimental error that arises from the use of non-validated simulators in computer architecture research, with the goal of increasing the rigor of simulation-based studies. We describe the methodology that we used to validate a microprocessor simulator against a Compaq DS-10L workstation, which contains an Alpha 21264 processor. Our evaluation suite consists of a set of 21 microbenchmarks that stress different aspects of the 21264 microarchitecture. Using the microbenchmark suite as the set of workloads, we describe how we reduced our simulator error to an arithmetic mean of 2%, and include details about the specific aspects of the pipeline that required extra care to reduce the error. We show how these low-level optimizations reduce average error from 40% to less than 20% on macrobenchmarks drawn from the SPEC2000 suite. Finally, we examine the degree to which performance optimizations are stable across different simulators, showing that researchers would draw different conclusions, in some cases, if using validated simulators.

Managing variability in software architectures

Abstract: This paper presents experience with explicitly managing variability within a software architecture. Software architects normally plan for change and put mechanisms in the architecture to support those changes. Understanding the situations where change has been planned for and recording the options possible within particular situations is usually not done explicitly. This becomes important if the architecture is used for many product versions over a long period or in a product line context where the architecture is used to build a variety of different products. That is, it is important to explicitly represent variation and indicate within the architecture locations for which change has been allowed.We will describe how the management of variations in an architecture can be made more explicit and how the use of variation points connected to the choices a customer has when ordering a product can help to navigate to the appropriate places in the architecture.