Few tools exist to address the post-development activities of con guring, releasing, installing, updating, reconfiguring, and even de-installing a software system. Certainly there is no unified approach for all of these activities, and none that can take full advantage of a wide-area network. The Software Dock represents an architecture for supporting post-development activities in such a setting. It is designed as a system of loosely-coupled, cooperating, distributed components that are bound together by a wide-area messaging and event system. In this paper we describe the Software Dock architecture and discuss the use of a prototype in deploying a complex system.

Dividing software systems in components improves software reusability as well as software maintainability. Components live at several levels, we concentrate on the implementation level where components are formed by source files, divided over directory structures. Such source code components are usually strongly coupled in the directory structure of a software system. Their compilation is usually controlled by a single global build process. This entangling of source trees and build processes often makes reuse of source code components in different software systems difficult. It also makes software systems inflexible because integration of additional source code components in source trees and build processes is difficult. This paper's subject is to increase software reuse by decreasing coupling of source code components. It is achieved by automized assembly of software systems from reusable source code components and involves integration of source trees, build processes, and configuration processes. Application domains include generative programming, product-line architectures, and commercial off-the-shelf (COTS) software engineering.

This dissertation presents an architectural model and a reference implementation for push systems. Push systems reverse the pull-based communication paradigm on the world-wide web and in most other distributed systems to support easier information dissemination and discovery for users. The pull model requires the user to issue a request whenever information is needed, whereas push systems support asynchronous information distribution: Whenever information of the user's choice becomes available, it gets distributed. In the push communication model, an information producer announces the availability of certain types of information, an interested consumer subscribes to this information, and the producer periodically publishes the information (pushes it to the consumer). This simplifies the discovery of information and provides timely information dissemination but introduces complex problems that challenge the widespread deployment of push systems: scalability to large numbers of users in terms of network bandwidth, timely notification of information availability, authenticity and integrity of information, and support for payment methods and business models. Current systems fall short in addressing these issues. Most available push systems actually use a pull-based distribution approach where clients check for new information at configurable intervals; frequently scalability is limited, many systems lack services to provide information authenticity and integrity, and moreover, the important issue of payment models is not adequately addressed by any existing system.

An understanding of how software is employed in the field can yield many opportunities for quality improvements. Profiling released software can provide such an understanding. However, profiling released software is di#cult due to the potentially large number of deployed sites that must be profiled, the extreme transparency expectations, and the remote data collection and deployment management process. Researchers have recently proposed various approaches to tap into the opportunities and overcome those challenges. Initial studies have illustrated the application of these approaches and have shown their feasibility. Still, the promising proposed approaches, and the tradeo#s between overhead, accuracy, and potential benefits for the testing activity have been barely quantified. This paper aims to overcome those limitations. Our analysis of 1200 user sessions on a 155 KLOC system substantiates the ability of field data to support test suite improvements, quantifies di#erent approaches previously introduced in isolation, and assesses the e#ciency of profiling techniques for released software and the e#ectiveness of their associated testing e#orts.

Software release management is the process through which software is made available to and obtained by its users. Until now, this process has been relatively straightforward. However, the emergence of component-based software is complicating software release management. Increasingly, software is constructed via the assembly of pre-existing, independently produced, and independently released components. Both developers and users of such software are affected by these complications. Developers need to accurately document the complex and changing dependencies among the components constituting the software. Users must be involved in locating, retrieving, and assembling components in order to appropriately bring the software into their particular environment. In this paper, we introduce the problem of release management for component-based software and discuss SRM, a prototype software release management tool we have developed that supports both developers and users in the software release management process.

Few tools exist to address the post-development activities of configuring, releasing, installing, updating, reconfiguring, and even de-installing a software system. Certainly there isnouniedapproach for all of these activities, and none that can take full advantage of a wide-area network. The Software Dock represents an architecture for supporting post-development activities in such a setting. It is designed asasystemof loosely-coupled, cooperating, distributed components that are bound together by a widearea messaging and event system. The components include eld docks for maintaining site-specific configuration information by consumers, release docks for managing the configuration and release of software systems by producers, and a variety of agents for automating the activities. Its mechanisms of consistent access to a site's configuration information and resources, standardized methods for making software releases available and visible, and a global event system give software producers and consumers new leverage in managing complex software systems. In this paper we describe the Software Dock architecture and discuss the use of a prototype implementation of that architecture in deploying a complex system.

In the last decade, software product management has received much practical attention, though research in this area is still scattered. In this paper, we give a status overview of the current software product management domain by performing a literature study and field studies with product managers. The results are used to develop a reference framework for software product management, in which the key process areas, stakeholders and their relations are modeled. To validate the reference framework, we perform a case study in which we analyze the stakeholder communication concerning the conception, development and launching of a new product at a major software vendor. Finally, we propose the Software Product Management Workbench for

Component-based software development is revolutionizing the software industry by promoting a view of software development in which applications are composed out of reusable, relatively large-grained, and mostly pre-existing components. Adoption of component-based software development leads to an important distinction in roles between those that develop and make available individual components and those that compose applications out of available components. As a result, application composition is no longer a matter of writing and combining source code, but instead of composing deployable components---components that are pre-packaged, independently distributed, easily installed and uninstalled, and self-descriptive.

The ability to construct a software system from separate pieces while the system is being used is a feature which has become more prevalent and important in recent years; in fact, the ability to dynamically compose a system has existed in various programming languages and computing systems for some time. We use the term dynamically composed systems to refer to systems with this property. In general, dynamically composed systems suffer a number of problems, not the least of which is the difficulty in ascertaining what pieces comprise a system. Furthermore, the definition of how particular pieces are selected, what a consistent collection of pieces is, and how multiple versions of the same piece are handled when composing a system dynamically is typically ambiguous, and feedback to users or maintainers of the system with respect to these issues is often non-existent or too late. Traditional configuration management tools address such system composition and evolution issues, but only in a s...

Based on a vision that, in the future, applications will be flexibly built out of small-grained components, we argue that current technologies do not adequately support component deployment in such a setting. Specifically, current technologies realize deployment processes where most decisions are made by the application manufacturer. When using small-grained components, however, the component user needs to have more control over the deployment process; user-centric deployment is needed. In this paper, we describe our initial efforts at providing user-centric deployment. We present JPloy, a prototypical tool that gives a user more control about the configuration of installed Java components. JPloy extends the Java class loader so that custom configurations can be applied to existing components, without having to modify the components themselves. For example, name space or versioning conflicts among components can be elegantly resolved in this way. We demonstrate JPloy by applying it to an example application.