Section 21.5. CONCERN MODELING AS A FIRST-CLASS UNDERTAKING

21.5. CONCERN MODELING AS A FIRST-CLASS UNDERTAKING

To make concern modeling a first-class undertaking in software development (AOSD, OOSD, or otherwise), a schema for the modeling of concerns must be adopted, and the activity of concern modeling must be integrated into development processes. In this section, we consider requirements on a concern-modeling schema and discuss issues in integrating concern modeling into the software lifecycle.^[1]

^[1] Tooling and methods may also be necessary, but these depend in part on which AOSD technologies are adopted, and they are beyond the scope of this chapter.

21.5.1. Requirements for a Concern-Modeling Schema

Since a concern model is an information model, any language for modeling information or representing knowledge may have some applicability to concern modeling. The initial models we constructed when we began our investigations [33] were informal. Though informal models may be useful for ad hoc or experimental purposes, formal models are more powerful and offer a firmer foundation for an aspect-oriented software engineering discipline. However, different formal languages offer different advantages for different purposes. Thus, while some benefits may indeed be gained by applying existing formalisms to concern modeling, we believe that consideration should be given specifically to the requirements of modeling concerns.

We have identified desirable properties that are useful for a concern-modeling schema, including generality, independence, appropriateness, completeness, and ease of use.

• Generality is important for serving many purposes and allowing users to capture a variety of concerns.

• Independence is important for minimizing the effect of other choices of development methods, tools, and approaches on concern modeling.

• Appropriateness is important for facilitating expressing the kinds of concerns that users have and the kinds of information that they want to express about them.

• Completeness is important for allowing users to express all of the important aspects of a concern model.

• Ease of use is important for facilitating adoption and use.

These desired general characteristics can be addressed through a number of recommendations more specific to concern modeling.

For completeness, it is important to be able to model not only concerns but also relationships between concerns and consistency conditions on concerns. For generality, the schema should allow users to define arbitrary concerns, relationships, and conditions. For completeness and generality, it should be possible to view these relationships and constraints as concerns themselves. Since not all kinds of concerns and relationships can be anticipated, the formalism should include elements for allowing users to define their own kinds of concern. This also supports appropriateness since it would allow specific schemas to be tailored to specific projects. To facilitate ease of use, some specific but commonly useful types of concern and relationship should be included.

To support completeness, generality, and appropriateness, it should be possible to organize concerns in various ways, such as by classifications (including multiple classifications), aggregations, and other groupings.

For independence, a general-purpose concern-modeling schema should be independent from other modeling or implementation languages, artifact types, lifecycle stages, and development methods. For independence and generality, it should also be possible to capture concerns (or related data) that are not necessarily captured in other development formalisms.

In asserting that a concern-modeling schema should be independent, we do not mean to suggest that it cannot be based on or used closely with other languages. Rather, it should be possible for the concern-modeling schema to be meaningful and usable on its own. (For example, a concern-modeling schema may be relational, but it should not depend on the use of relational modeling in other parts of the development process.) Also, while we are advocating a general-purpose concern-modeling schema, it is possible to define more specialized approaches to be integrated with (and dependent on) particular development languages, artifact types, or methods. Within a specialized context, this may increase the appropriateness and ease of use of the formalism.

Finally, many of the potential applications of concern modeling depend on the ability to relate concerns to associated artifacts, that is, artifacts that may represent, define, implement, affect, or otherwise be of significance for the concerns. To some extent, this depends on the nature of the artifacts, such as the ability to reference and access the artifacts and their constituent parts. Where feasible, concerns should be related directly to artifacts, although it may be problematic to establish the reverse relationships, i.e., from artifacts to concerns (as the artifact representations may not accommodate these references). As an alternative, a model of the artifact space may be constructed, analogous to the domain models used in domain specific software architectures (DSSA) [39] (with the artifacts, in effect, as the domain). In this case, concerns are related to the artifact model, and relationships from the artifact model to the concern model can be easily represented. A similar approach is used in UML (v. 1.4 [29]), in which the physical elements of systems are represented by "nodes" and "artifacts," and design elements, such as "classes" and "components," are associated to them.

21.5.2. Process Considerations

In general, there are many ways to use concern modeling within a software development process, just as there are many ways to specify requirements or to model architecture. The role of concern modeling depends on the development method and the process objective. The following scenarios suggest the range of possibilities:

• In a process centered on using commercial, off-the-shelf software (COTS), a concern model of the system under development (SUD) may be constructed for evaluating the compatibility and potential contribution of candidate COTS products. These products can be characterized in terms of the concerns they address and evaluated against the concern framework of the SUD. The suitability of particular products can be determined based on the consistency or inconsistency of concerns, the range of concerns addressed, the need for tailoring to assure compatibility, and the concerns remaining to be addressed.

• In new development, a limited concern model can be elaborated at the start of development to represent the initial concerns that motivate or constrain the project. As development progresses through requirements, architectural design, detailed design, and so on, the concern model can be elaborated. Concerns can be related to the various work products in which they are defined, implemented, or otherwise addressed, and relationships between concerns can be drawn to capture semantic, operational, and other dependencies. The concern model can be analyzed to assess the consistency and coherence of the concerns associated to the project. As the life cycle iterates, changes made at various stages can be validated against the concern model, and the concern model can be used to help propagate updates through both the concern space and the artifact space.

• In the retroactive extension of a product line based on an existing product, concern modeling can be used to characterize the potential feature space and to characterize the product variants within that space. An initial concern model can be developed of the existing product. The product can be decomposed into units corresponding to specific concerns. Concerns representing additional features can be identified and related to the existing model, and additional work products can be developed to support implementation of the additional concerns. Variants within the product family can then be specified by selecting concerns of interest from within the product-family concern space. Compositional technologies may then be used to compose a product variant using implementations associated to the selected concerns. This sort of scenario is discussed in more detail in Section 21.7.

As these scenarios suggest, concern modeling may be done before initial development, during development, or as specific needs arise afterwards. It may be done independently of, or in close association with, other development activities. It may be done in one step or incrementally. It may be for particular work products or sets of concerns or comprehensively for a product or complete concern space. Finally, it may be done for general purposes or to address specific problems.