Section 17.3. DESIGN


17.3. DESIGN

A number of approaches have been proposed to provide support for crosscutting concerns at the design level. Most of these approaches have been developed to augment object-oriented design techniques and UML with facilities for modularization of crosscutting concerns. Some of the key approaches at the design level include Composition Patterns [21, 22] and their successor Theme/UML [7, 22], aspect-oriented component engineering (AOCE) [34, 35, 36], hyperspaces [42, 62, 79], architectural views of aspects [46], and an approach proposed by Suzuki and Yamamoto [77, 78]. Although several other approaches have been proposed (e.g., [39, 41]), they suggest the introduction of specialized UML stereotypes for each particular crosscutting concern. These approaches have been left out of the discussion in favor of the more general approach by Suzuki and Yamamoto [77].

The Composition Patterns approach is based on a combination of the subject-oriented design model [20] for composing separate overlapping designs and UML templates. It is based on the observation that patterns of crosscutting behavior exist with respect to the base designs they cut across. This behavior holds irrespective of the subjects crosscut by the concern. Thus, reusable subjects and concerns can be designed independently of each other. Composition rules are then used to compose these designs together. Presently, the work on Composition Patterns in its entirety and with no significant changes is incorporated into Theme/UML [22], part of the Theme approach [7].

AOCE, at the design level, refines the previously identified aspect-oriented component requirements (from AORE) into design-level aspects. As mentioned in Section 17.1, AOCE is based on the idea that each component in a component-based system uses/provides services from/to other components. A set of UML metamodel extensions and visual notations is employed to make the provided and required aspect details explicit. The crosscutting concerns thus separated are used to categorize components in accordance with their contribution towards the overall system properties and reason about the inter-component services.

The hyperspaces approach proposes using hyperslices to encapsulate sets of modules that address concerns in dimensions other than the one used for the dominant formalism. Hyperslices can overlap; that is, a given unit in a hyperslice can appear, possibly in a different form, in other hyperslices. At the composition stage, issues such as overlapping are resolved via composition rules. The model can be instantiated in any formalism, at which time choices may be made as to the mapping between notational constructs and units/modules and as to how hyperslices are represented. Consequently, there are no standard design notations for this model. However, it has been instantiated for the object-oriented formalism [42].

In Architectural View of Aspects [46], aspects are represented as stereotyped packages containing a variety of UML designs pertaining to a certain concern. The elements within each diagram can have certain relations (e.g., uses, defines), while elements that can be bound to other elements in different aspects are color-marked. The notion of a concern diagram is introduced, which allows viewing of overlapping concerns in the system being designed. The composition employs the superimposition principle discussed in [74]. Essentially, this design approach is very close to another UML interpretation of the hyperspaces model, augmented with some visual cues (such as concern diagrams) and composition mechanisms (such as superimposition).

Suzuki and Yamamoto propose UML extensions to model aspects and UXF/a, an XML-based aspect description language to provide interchangeability of aspect-oriented models between various development tools (e.g., CASE tools, aspect weavers, etc.). An aspect is depicted as a class rectangle with attributes, operations, and relationships. The attributes are used by the set of operations, which are the weave definitions for the aspect. The signature of these definitions reflects the elements affected by the given aspect.

Like their conventional counterparts, "good" aspect-oriented design techniques should provide a set of notations for encapsulating holistic crosscutting requirements, facilitate understanding of complex systems, and promote reuse and evolution. The resulting designs should exhibit a high degree of traceability, change propagation, reusability, comprehensibility, flexibility, parallel development, and ease of learning and use [19]. Table 17-3 demonstrates the extent to which designs produced with each of the four design approaches discussed previously satisfy these qualities.

Table 17-3. Evaluation of Selected AO Design Approaches

Design Tech. Design Quality

Traceability

Change Propagation

Reusability

Comprehensibility

Flexibility

Ease of Learning/Use

Parallel Development

Composition Patterns [21, 22]

Good

Average

Good

Good

Good

Poor

Good

AOCE [34, 35, 36]

Very Good

Poor

Good

Average

Good

Good

Good

Hyperspaces [42, 62, 79]

Good

Average

Good

Good

Good

Poor

Good

Architectural Views [46]

Good

Average

Good

Average

Good

Poor

Good

Suzuki & Yamamoto's Model [77, 78]

Average

Average

Average

Average

Poor

Poor

Average


In AOCE, designs do not need to be merged but stay intact and are, therefore, easily traceable across the whole lifecycle. In both the Composition Patterns approach and hyperspaces, crosscutting requirements are clearly traceable to composition patterns and hyperslices respectively but are tangled as designs are merged. Architectural views facilitate traceability through concern diagrams, which show the coarse-level overlapping areas at a glance. They also support designing each crosscutting requirement as a separate aspect and annotate the composed designs with the source. The composed designs are, however, somewhat overcrowded. Suzuki and Yamamoto's model only provides partial support for traceability. Crosscutting requirements are traceable to aspects, which in turn reference affected object elements.

Composition Patterns and hyperspaces support non-invasive changeability, but composition rules need to be reviewed after a change. In AOCE, change is monitored but not effectively propagated. Architectural views refer to superimposition composition rules, which need to be checked for each composition. Suzuki and Yamamoto's model only provides partial support for changeability. UXF/a, however, supports efficient change propagation.

All approaches, apart from Suzuki and Yamamoto's model, support production of highly reusable designs that can be realized using different implementation techniques (high degree of flexibility). Suzuki and Yamamoto, on the other hand, support interchangeability of aspect descriptions between UXF/a compatible tools.

Individual designs involving Composition Patterns and hyperspaces are highly comprehensible, but integrated designs are less so. In AOCE, aspects assist in understanding the relationships between components, but the designs become cluttered due to the high degree of cross-referencing. Similarly, in architectural views, the composed designs could get cluttered with cross-referencing annotations, and while aspects are separated in Suzuki and Yamamoto's model, they still reference base object elements, which reduces comprehensibility.

Ease of using AOCE is impeded by the extra design effort needed but supported by additional run-time reconfigurability and dynamicity. Learning Composition Patterns and hyperspaces is complicated by the need to learn subject-oriented design and associated composition semantics. Architectural views require understanding of using single and composed views and superimposition. It is a similar case for Suzuki and Yamamoto's model, as its heavy reliance on the AspectJ implementation model requires an understanding of AspectJ.

Parallel development is supported by AOCE, Composition Patterns, architectural views, and hyperspaces. Crosscutting concerns and base designs can be developed simultaneously and independently of one another. Suzuki and Yamamoto's model only provides partial support for the purpose because, while designing crosscutting concerns, the designer needs to refer to the objects they cut across.

The decision on which approach to use should be made in accordance with the priorities of the previously mentioned design qualities for a given project on a case-by-case basis.



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