Reuse between software systems is often not optimal. An important reason is that while at the functional level well-known modularization principles are applied for structuring functionality in modules, this is not the case at the build level for structuring files in directories. This leads to a situation where files are entangled in directory hierarchies and build processes, making it hard to extract functionality and to make functionality suitable for reuse. Consequently, software may not come available for reuse at all, or only in rather large chunks of functionality, which may lead to extra software dependencies. In this paper, we propose to improve this situation by applying component-based software engineering (CBSE) principles to the build level. We discuss how existing software systems break CBSE principles, we introduce the notion of build-level components, and we define rules for developing such components. To make our techniques feasible, we define a reengineering process for semiautomatically transforming existing software systems into build-level components. Our techniques are demonstrated in two case studies where we decouple the source tree of Graphviz into 46 build-level components and analyze the source tree of Mozilla.

The deployment of software components frequently fails because dependencies on other components are not declared explicitly or are declared imprecisely. This results in an incomplete reproduction of the environment necessary for proper operation, or in interference between incompatible variants. In this paper, we show that these deployment hazards are similar to pointer hazards in memory models of programming languages and can be countered by imposing a memory management discipline on software deployment. Based on this analysis, we have developed a generic, platform and language independent, discipline for deployment that allows precise dependency verification; exact identification of component variants; computation of complete closures containing all components on which a component depends; maximal sharing of components between such closures; and concurrent installation of revisions and variants of components. We have implemented the approach in the Nix deployment system, and used it for the deployment of a large number of existing Linux packages. We compare its effectiveness to other deployment systems.

Automatic software reengineering changes or repairs existing software systems. They are usually tailor-made for a specific customer and language dependent. Maintaining similar reengineering for multiple customers and different language dialects may, therefore, soon become problematic unless advanced language technology is used. Generic pretty-printing is part of such technology and is the subject of this paper. We discuss specific pretty-print aspects of software reengineering such as fulfilling customer-specific format conventions, preserving existing layout, and producing multiple output formats. In addition, we describe pretty-print techniques that help to reduce maintenance effort of tailor-made reengineering supporting multiple language dialects. Applications such as COBOL reengineering and SDL documentation generation show that our techniques, implemented in the generic pretty-printer GPP, are feasible.

Maintenance of proprietary languages and corresponding tooling is expensive. Postponing maintenance to reduce these costs is an often applied, short-term solution which eventually may lead to an unoperational toolset. The paper describes a case study carried out in cooperation with Lucent Technologies where maintenance cost is decreased by simplifying the development process of languages and tools. The development process is simplified by using a language-centered software engineering approach which increases software reuse and language dependent code generation. The case study was concerned with Lucent's proprietary SDL dialect and involved the re-engineering of an SDL grammar and the construction of an SDL documentation generator.