Section 21.9. ADDITIONAL DISCUSSION


21.9. ADDITIONAL DISCUSSION

In this section, we address two fundamental questions: Can we achieve a useful degree of formalization for such a general notion as "concern," and what is the nature of the contribution that concern modeling may make to AOSD?

21.9.1. Formalization of the Notion of "Concern"

We have purposely adopted a notion of concern that is general and intuitive. It is therefore reasonable to wonder in what ways and to what extent this notion can be formalized.

We note first that our interest has been primarily with representing concern spaces rather than individual concerns. That is, we have focused on categories of concern and on organizational and semantic relationships among concerns rather than on how best to represent the details of particular concerns. The latter does deserve attention, but we expect that different domains of concerns will have different, specialized languages for description. For example, distinct formalisms may be used to describe concerns relating to functionality (perhaps algebraic specifications), performance (perhaps numerical models), and consistency (perhaps Object Constraint Language (OCL) assertions [29]). Moreover, it should be kept in mind that the description of a concern in a concern-modeling schema such as Cosmos is not intended to replace the representation of that concern in other software artifacts. In Cosmos, a concern represents a subject of interest, the details of which should be found mainly in the associated artifacts, such as requirements, architecture, designs, and code, through which system-specific details are defined and implemented.

With regard to the representation of concern spaces, it is possible to introduce a level of formality that is comparable to that found in other sorts of information modeling used in software development, including domain modeling [20, 39], semantic dependency modeling [7, 42], or design modeling [29]. These kinds of modeling typically entail some representation of entities, kinds of entities, properties of entities, and various sorts of semantic or structural relationships among entities. With Cosmos, we have demonstrated that this sort of modeling is possible with concerns.

The level of formality (or formalizability) in the Cosmos schema is sufficient to have allowed us to construct object-oriented models of the schema in UML [29]. In this model, for example, LogicalInstance is defined as an extension of LogicalConcern, which is defined as an extension of Concern, which is defined as an extension of ConcernModelElement; operations on instances of the schema (that is, on specific concern models) can take place at any of these levels of abstraction. Given a Cosmos model, it is possible to algorithmically define many sorts of analyses. Questions about a Cosmos model that can be answered by analysis include

  • Are there cycles in the concern-class structure?

  • Are there classes without instances or instances without classes?

  • Does every concern have a motivation or make a contribution?

Additionally, it is possible to define consistency conditions for a concern model. For example, no logical class should contain both logical instances and physical instances, and for any two concerns X and Y, if X motivates Y, then Y should contribute to X. For a UML model of the Cosmo schema, we have defined such constraints using OCL [29].

Thus, it appears possible to formalize modeling concern spaces. As with other sorts of information modeling in software development (and elsewhere), the purpose of such formalization is to take notions that are intuitive and informal and render them precisely. Formalization allows using information not just in one specific tool but in a variety of ways.

21.9.2. Nature of the Contribution to AOSD

AOSD provides new tools and methods for developing software based on concerns. It uses advanced techniques for separation of concerns, with an emphasis on separating and composing crosscutting concerns. In general, AOSD allows for the separate modular representation of information associated with specific concerns. Examples of such information include requirements, designs, and code. In particular, AOSD seeks the modular representation of concerns that might be scattered across conventional representations, such as object-oriented models or code, in which a particular decomposition predominates. AOSD also automates the weaving or composition of concern-specific units according to explicit specifications. In this way, it controls and systematizes the distribution of concern-specific elements across differently organized application architectures. AOSD thus depends on an understanding of concerns and their interrelationships.

Concern modeling allows us to directly represent and reason about concerns and their interrelationships, thereby creating an externalized abstraction for organizing, analyzing, managing, and composing artifacts according to concerns. This affords several advantages with respect to aspect-orientation. It reveals crosscutting relationships among concerns (as when one concern is defined with respect to another). It provides a reference model of concerns that may be organized and distributed in different ways in different artifacts (for example, as when requirements are organized by functional decomposition but designs are organized by object decomposition). Finally, for software rich in aspectual properties, it helps with managing complexity, such as when multiple concerns are tangled within a single artifact, or when individual concerns are scattered across multiple artifacts. All these contributions are important for helping AOSD to scale from individual components and applications to product families and enterprise-level systems.



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net