Section 19.8. RELATED WORK

19.8. RELATED WORK

Conceptually, the Theme/UML model has evolved from the work on subject-oriented programming [10, 18], as is also the case with the work on multi-dimensional separation of concerns [24]. Different themes may be designed (or programmed) to support separate requirements, be they functional (and conceptually overlapping) or crosscutting requirements. Subsequent composition of separated themes is specified with composition relationships (or defined by composition rules in subject-oriented programming). Theme/UML is part of an approach to aspect-oriented analysis and design called Theme. Theme has two parts: Theme/Doc is a set of heuristics and tools for visualisation and analysis of software requirements documentation for the purposes of finding the themes to be designed. Theme/UML is the second part, which is a way to design aspects based on the UML [1]. From the perspective of crosscutting requirements, this chapter has illustrated how the Theme/UML model for crosscutting themes also closely relates to the aspect-oriented programming model [15] as embodied in the AspectJ programming language [14].

In this section, we examine approaches to extending UML, specifically with the AspectJ approach to aspect-oriented programming in mind. We also discuss some other approaches to flexible separation of concerns at the design stage. While there are many approaches to flexible separation of concerns at the programming level, we do not consider these here.

First, there are some interesting approaches that start with the AspectJ mindset and attempt to directly apply its concepts as extensions to UML. Two general approaches to this are evolving. On the one hand, there have been approaches to extending UML with stereotypes specific to particular aspects (e.g., synchronization [11] or command pattern [13]). In such approaches, the constructs required by each particular aspect are stereotyped so that a weaver (like a composer) can determine which elements match the appropriate aspect construct. In both these examples, many of the behavioral details of synchronization and of the command pattern are not explicitly designed in UMLthe onus appears to be on the weaver to provide the aspect behavior. The authors of [13] have since further refined their model by building a tool to support building the required application-specific weavers [12]. Other approaches attempt to provide a more generalized way to support aspect-oriented programming in UML. For example, in [22] a new meta-construct called Aspect is created, and stereotypes are defined for advice behavior. Operations requiring advice behavior are constrained by the advice stereotypes. Stereotypes for different aspect-oriented constructs similar to those in AspectJ are also the basis for the approach taken in [21]. The Theme/UML model distinguishes itself from these general approaches with its generic approach to designing reusable crosscutting behavior in a manner that is independent of a particular programming environment.

Two approaches that emphasize a more flexible separation of concerns than exists in standard object-oriented design are OORam [19] and Catalysis [7]. In role modelling in OORam, large systems are described with multiple different role models that may be synthesized to create derived models. This is similar to merge integration in theme design. Catalysis also supports the decomposition of software designs along "vertical" and "horizontal" lines, providing the ability to separate both functional and technical kinds of concerns. While both approaches provide advances in the separation capabilities in object-oriented design, neither addresses the specification and composition of patterns of crosscutting behavior.

A focus of work in the field of collaboration-based design is on separation of each of the roles classes may play in different collaborations into different modules. For example, modularization of roles within collaborations is supported by mixins in the work described in [25], utilizing a C++ template class for each role in each collaboration; complete classes are "composed" by placing these mixins in a hierarchy. This work is extended in [20] to overcome problems of scalability by grouping sets of roles within each collaboration. Relative to the Theme/UML model, there are two main drawbacks to these approaches. First, while classes can be mixed together simply by adding mixins to a class hierarchy, individual methods cannot; this is part of the reason tool support is needed in subject-oriented and aspect-oriented programming. Second, whenever the mixins are interdependent, one needs to tangle the dependencies between them by embedding details of the dependencies within each mixin, typically via explicit calls to super-methods and other constraint information. In any situation where prior knowledge of future changes is unknown, such dependencies would require error-prone modifications to pre-existing mixins. As a result, each mixin cannot be designed cleanly and independently as Theme/UML allows.

The need for aspect-orientation across the development lifecycle is described in [9], motivated by agent-based product-line development for e-commerce. A development process is proposed that draws together high-level analysis and design separation techniques and corresponding, supporting implementation techniques. Theme/UML provides a solution to designing crosscutting features in a reusable way that could be considered for inclusion in this development process.