Section 3.1. INTRODUCTION

3.1. INTRODUCTION

The primary goals of software engineering are to improve software quality, to reduce the costs of software production, and to facilitate maintenance and evolution. In pursuit of these goals, software engineers constantly seek development technologies and methodologies that reduce software complexity, improve comprehensibility, promote reuse, and facilitate evolution. These properties, in turn, induce several specific requirements on the formalisms used to develop software artifacts. Reduced complexity and improved comprehensibility require decomposition mechanisms to carve software into meaningful and manageable pieces. They also require composition mechanisms to put pieces together usefully. Reuse requires the development of large-scale reusable components, low coupling, and powerful, non-invasive adaptation and customization capabilities. Ease of evolution depends on low coupling and also requires traceability across the software lifecycle, mechanisms for minimizing the impact of changes, and substitutability.

Despite much good research in the software engineering domain, many of the problems that complicate software engineering still remain. Software comprehensibility tends to degrade over time (if, indeed, it is present at all). Many common maintenance and evolution activities result in high-impact, invasive modifications. Artifacts are of limited reusability, or are reusable only with difficulty. Traceability across the various software artifacts is limited, which further complicates evolution.

These somewhat diverse problems are due, in large part, to limitations and unfulfilled requirements related to separation of concerns [19]. Our ability to achieve the goals of software engineering depends fundamentally on our ability to keep separate all concerns of importance in software systems. All modern software formalisms support separation of concerns to some extent, through mechanisms for decomposition and composition. However, existing formalisms at all lifecycle phases provide only small, restricted sets of decomposition and composition mechanisms, and these typically support only a single, "dominant" dimension of separation at a time. We call this the "tyranny of the dominant decomposition."

We believe that achieving the primary goals of software engineering requires support for simultaneous separation of overlapping concerns in multiple dimensions. We will illustrate how limitations on current mechanisms prevent this and thereby lead directly to the failure to achieve these goals. We propose a model of software artifacts, decomposition, and composition to overcome these limitations. This model allows for simultaneous, multi-dimensional decomposition and composition. It is not a "universal" artifact modeling formalism; rather, it complements existing formalisms, giving developers additional modularization flexibility while continuing to use the formalisms of their choice. Moreover, this model is not particular to any phase of the software lifecycle. The extra flexibility to represent alternative decompositions of artifacts within a development phase also enables us to relate artifacts in multiple ways across phases, and even to co-structure artifactspermit different artifacts, developed during different phases of the software lifecycle, to be structured in such a way that corresponding elements align clearly. We show how this increased flexibility can help to address the problems of software complexity and comprehensibility and difficulties with reuse, facilitate software evolution, and enhance traceability between artifacts, both within and across development phases.

The rest of this paper is organized as follows. Section 3.2 motivates the need for multiple dimensions of decomposition and rich mechanisms for composition. Section 3.3 describes our abstract model of software artifacts. It also shows how this model can address many of the issues raised in Section 3.2. Section 3.4 describes the issues involved in instantiating the model for particular artifact development formalisms, such as UML [21] or Java [6]. Section 3.5 describes related work and shows how our approach has been partially realized in some existing work. Finally, Section 3.6 presents some conclusions and future work.