Section 21.4. WHY DO WE NEED CONCERN MODELING?

21.4. WHY DO WE NEED CONCERN MODELING?

Most, if not all, of software development can be viewed as modeling related to concerns. We don't call the various activities involved "concern-modeling," though, because their primary focus is on other things: requirements, architecture, design, implementation, and so on. The modeling approaches currently used in software development enable the modeling of many kinds of concerns in many forms. However, none of them models concerns in general or in the abstract. For example, none of them allows us to say simply that performance is a concern, although they enable us to say that achieving high performance is a goal or to select an architectural style based on performance properties. In this section, we justify modeling concerns explicitly as first-class entities.

21.4.1. Specification and Analysis of Concerns Across the Development Lifecycle and Artifacts

Concerns, collectively and individually, occur across the development lifecycle and development artifacts. Therefore, we need to be able to specify and analyze concerns across the development lifecycle and artifacts. Concerns exist ab initio with respect to the lifetime of a system. Although concerns arise throughout system evolution, the system itself arises from some concerns that preceded it, and these concerns exist before and apart from any representation they may have in the system or associated work products. Concerns also span multiple representations in particular artifacts and formalisms, and the relevance of particular concerns crosses development methods, processes, and stages. We can see examples of this with specific concerns such as performance.

21.4.2. Enhancement of Traditional Development Tasks

Concern models have many potential applications that complement or supplement traditional development tasks. One area of application is based on the analysis and understanding of concerns themselves. Individual concerns may be defined, have associated attributes (e.g., related to ownership, priority, or process stage), be related to other concerns (e.g., to show refinement, motivation, dependence), and be individually or collectively constrained (e.g., to be used exclusively or in combination). Formal representations of concerns would enable analysis for their completeness, correctness, and consistency. In turn, the analysis of concerns can help in assessing the completeness, correctness, and consistency of software artifacts in which concerns are represented.

Another area of application for concern modeling arises from the relationship of concerns to particular work products. Concerns in a first-class model can be associated to particular requirements statements, design elements, code units, and so on. These may be artifacts from which the concerns are derived, in which they are implemented, through which they are affected, and so on. An independent concern model, with meaningful links into an artifact set, can be viewed as a kind of semantic hyper-index to the artifacts (comparable to a topic map [18]). Such a model has many possible uses, including

• Organizing and associating product elements according to the concerns to which they are related (the refinements of [4] would be an extended case).

• Tracing concerns across artifacts and indirectly across associated formalisms, development stages, processes, and organizational units.

• Supporting impact analysis by enabling the determination of concerns affected when artifacts are changed and of artifacts affected when concerns are changed.

• Facilitating the propagation of changes to artifacts linked by shared concerns.

• Supporting rationale capture and analysis by linking artifacts to the concerns that they implement or influence and by semantically linking those concerns to other concerns that may provide motivation for them or receive contributions from them.

• Contributing to reuse by providing a semantic context in which artifacts (or elements of them) can be considered or presented for reuse.

• Enabling additional analyses for completeness, consistency, and correctness of an artifact base with respect to a given concern space.

These applications do not depend on the use of other AOSD technologies or methods. Concern modeling can be used, for example, to facilitate traceability between development stages [26], to analyze a system in preparation for evolution, or to evaluate a candidate component for reuse, all within the context of traditional development methods.

21.4.3. Support of AOSD

Finally, if we are to develop a discipline of aspect-oriented software development based on advanced separation of concerns, it seems appropriate to consider concerns, in general and in the abstract, as first-class entities in their own right. Additionally, concern modeling lends support to specific AOSD approaches. For example, in aspect weaving such as with AspectJ [22], code units that represent a particular aspect such as logging are integrated or "woven" into a base program. However, the base program certainly represents a combination of concerns, and the aspect code, although it typically emphasizes a particular concern, will inevitably involve multiple concerns. For example, logging affects performance and recoverability, and it may serve purposes such as auditing and analysis. Effective aspect weaving thus depends on the compatibility of concerns in the base model and the aspect.

For code composition with Hyper/J [16], Java classes are organized into a multidimensional concern space. Units are related to specific concerns in specific dimensions, and composition is specified in terms of the dimensions and concerns to be integrated. Modeling of concerns is thus a part of the Hyper/J method. An example of the use of Cosmos with Hyper/J, which motivates the integration of concern modeling with other aspect-oriented tools, is given in Section 21.7.

In general, if the goal of AOSD is to enable us to specify the composition and decomposition of systems in terms of concerns, then the specification, analysis, and interrelation of concerns should be a fundamental part of any fully developed AOSD lifecycle. The modeling of concerns, including capturing how they relate to each other and how they are either individually or collectively constrained, is key to allowing a more systematic and therefore manageable use of AOSD techniques. It is a fundamental element to enable AOSD approaches to scale to address composition (and decomposition) of "enterprise" systems (e.g., systems where the relevant level of abstraction is not code units but systems that are very complex because of richness of aspects).