Section 3.6. CONCLUSIONS AND FUTURE WORK

3.6. CONCLUSIONS AND FUTURE WORK

A number of important problems in software engineering have resisted general solution, including problems related to software understanding, maintenance, evolution, and reuse. We believe that these problems share a common cause: failure of modern artifact formalisms to satisfy the separation of concerns requirement adequately. Numerous reasons exist to separate and integrate software artifacts, and these reasons may result in different artifact structures. Moreover, many concerns may be relevant simultaneously, and the entire set of concerns may evolve over time. Despite this observation, artifact formalisms include weak decomposition and composition mechanisms that permit only a small, "dominant" set of concerns to be separated. This leads directly to our inability to achieve many of the goals of software engineering as a discipline.

Our model of multi-dimensional software decomposition helps to overcome these limitations. It permits encapsulation of particular concerns in a software system, both within and across artifacts, and it allows kinds of separation of concerns that may not be separable in artifact formalisms, such as units of change, features, and overlapping concerns. This improves traceability across the lifecycle. The model also provides a powerful composition mechanism that facilitates integration, adaptation, and "plug-and-play." In so doing, it promotes reuse, improves comprehension, and eases maintenance and evolution. Thus, the approach addresses some fundamental limitations in software engineering. For these reasons, we believe that support for multi-dimensional decomposition and composition represents a key to advances along a broad front of software engineering challenges.

This work is clearly at an early stage, largely unproven yet. Still, a considerable body of experience and related research now exists to support the claim that multi-dimensional separation of concerns is one of the key software engineering issues today. The model presented is just a starting point. It must be refined, stretched, and modified, and it must be instantiated for a variety of formalisms to explore issues that arise for different methodologies and at different phases of the software lifecycle. These instantiations must be used for real development, to evaluate them and create new development methods that exploit their strengths; to explore issues in intra- and inter-artifact matching and reconciliations; and to explore the impact of multi-dimensional separation of concerns on areas like development methodology, software process, analysis, testing, reverse engineering, reengineering, and software architecture.