Section 21.10. CONCLUSION

21.10. CONCLUSION

The notion of concerns has long received attention in software development. However, until now, concerns have remained something of second-class citizens. Although existing software development activities address concerns in specific ways for specific purposes, there has been no effort to model concerns as such, in general and in the abstract.

The advent of aspect-oriented software development and new techniques for advanced separation of concerns have made plain the need to treat concerns as first-class entities and concern modeling as a first-class activity. There are many reasons to do this. They include the need to address concerns that occur across life-cycle stages and artifacts, the ability to enhance traditional development tasks with concern-based analyses and technologies, and the need to support aspect-oriented software development.

If concern modeling is to become a first-class undertaking in software development, then a formalism for the modeling of concerns must be adopted, and the activity of concern modeling must be integrated into development processes. At a high level, the requirements for a concern-modeling formalism are generality, independence, appropriateness, completeness, and utility. The integration of concern modeling into development processes may be done in many ways, but, in general, concern modeling may be done before, during, or after initial development, and it may be adopted comprehensively or incrementally.

Cosmos is a schema designed specifically for general-purpose concern-space modeling. Cosmos models concern spaces in terms of concerns in several categories, relationships of several types, and predicates. A notable example of the use of Cosmos (along with Hyper/J for Java composition) is in the reengineering of a monolithic, general-purpose software component. Decomposing the component according to concerns, we created a varied product line of specialized components tailored according to selected concerns of interest.

Concerns can be considered the essence of software. All software must address and embody concerns, and software development is fundamentally about identifying, realizing, and reconciling concerns. Aspect-oriented software development with concern modeling provides new tools and methods for developing software based on concerns. It allows for the separate, modular representation of information (such as requirements, designs, or code) that is associated with particular concerns, including concerns that might be scattered and tangled in conventional representations (such as object-oriented models or code). It also automates the weaving or composition of concern-specific units according to concern-based specifications, thereby controlling and systematizing the distribution of these units across differently organized application architectures. AOSD thus depends on understanding and leveraging concerns and their interrelationships and constraints. Concern modeling externalizes the abstractions of concerns and their interrelationships and constraints, and it allows them to be specified, analyzed, and understood as independent, first-class entities. Concern modeling is thus fundamental to aspect-oriented software development, and it holds the potential to enhance other approaches to software development as well.