Package design is concerned with the determining the best way to partition the classes in a system into subsystems. A poor package design can adversely affect the quality of a software system. In this paper we present a new metric, Class Reachability Set Size (CRSS), the distribution of which can be used to determine if the relationships between the classes in a system preclude it from a good package design. We compute CRSS distributions for programs in a software corpus in order to show that some real programs are precluded in this way. Also we show how the CRSS metric can be used to identify candidates for refactoring so that the potential package structure of a system can be improved. 1.

Abstract. L.L.Bean is a large retail organization whose development processes must be agile in order to allow rapid enhancement and maintenance of its technology infrastructure. Over the past decade L.L.Bean’s software code-base had become brittle and difficult to evolve. An effort was launched to identify and develop new approaches to software development that would enable ongoing agility to support the ever-increasing demands of a successful business. This paper recounts L.L.Bean’s effort in restructuring its code-base and adoption of process improvements that support an architecture-based agile approach to development, governance, and maintenance. Unlike traditional refactoring, this effort was guided by an architectural blueprint that was created in a Dependency Structure Matrix where the refactoring was first prototyped before being applied to the actual code base.

Object-oriented languages such as Java, Smalltalk, and C++ structure their programs using packages, allowing classes to be organized into named abstractions. Maintainers of large applications need to understand how packages are structured and how they relate to each other, but this task is very complex because packages often have multiple clients and different roles (class container, code ownership...). Cohesion and coupling are still among the most used metrics, because they help identify candidate packages for restructuring; however, they do not help maintainers understand the structure and interrelationships between packages. In this paper, we present the package fingerprint, a 2D visualization of the references made to and from a package. The proposed visualization offers a semantically rich, but compact and zoomable visualization centered on packages. We focus on two views (incoming and outgoing references) that help users understand how the package under analysis is used by the system and how it uses the system. We applied these views on three large case studies: JBoss, Azureus, and ArgoUML. This paper uses colors in the figures. Please read a colored printout of this paper. Index Terms Software packages, Visualization. 1

Abstract. Open Source Software (OSS) communities have not yet taken full advantage of reuse mechanisms. Typically many OSS projects which share the same application domain and topic, duplicate effort and code, without fully leveraging the vast amounts of available code. This study proposes the empirical evaluation of source code folders of OSS projects in order to determine their actual internal reuse and their potential as shareable, fine-grained and externally reusable software components by future projects. This paper empirically analyses four OSS systems, identifies which components (in the form of folders) are currently being reused internally and studies their coupling characteristics. Stable components (i.e., those which act as service providers rather than service consumers) are shown to be more likely to be reusable. As a means of supporting replication of these successful instances of OSS reuse, source folders with similar patterns are extracted from the studied systems, and identified as externally reusable components. The intended users are members of the OSS development community. Based on the empirical study of the OSS systems and observations made during the study, four practical courses of action are recommended in order to enhance the reusability of current folders that have not been identified as potentially reusable, both from an internal and external standpoint. 1