Section 20.1. INTRODUCTION

20.1. INTRODUCTION

Aspect-oriented technology (AOT) is a maturing technology [7, 8, 13] that complements object-oriented technology. AOT is rooted in the idea of separately modularizing concerns, represented by work such as subject-oriented programming (SOP) [15]. In SOP, the different concerns of a software system can be designed and reasoned about in isolation from each other. Finding modular representations for these concerns and developing mechanisms for concern weaving are the main themes of aspect-oriented programming. Recent work in aspect-oriented design [1, 3, 8, 17] has demonstrated the value of deploying aspect technology early in the software life cycle. Crosscutting concerns cause many difficulties for software development. Since these difficulties are present throughout the design process, they must be addressed across its entirety [3]. Initial decomposition of a problem identifies software components and the corresponding concerns that crosscut these components. We want to be able to formally express and model this initial decomposition and carry this model through the software development lifecycle.

Object-oriented modeling is a standard practice in the early stages of software development. Object-oriented modeling has many advantages, frequently outlined in the literature. Similarly, UML [14] enjoys many benefits, including providing structure for problem solving, allowing exploration of a solution space, furnishing abstractions to manage complexity, reducing time-to-market, and managing the risk of mistakes. But what the object-oriented paradigm does not address is the modeling of different design concerns as separate submodels that are easy to maintain and comprehend. Traditional object-oriented modeling techniques usually produce one giant model at the end of the design phase, where multiple concerns have been intermixed. Identifying and modifying a single design concern in a giant model is difficult, impeding the evolution of the software system. Monolithic object-oriented models have motivated researchers in the aspect-oriented community to investigate alternatives. In [2], we demonstrated that when aspects are identified at an early stage of the development lifecycle, their design components become more reusable, and automatic code generation becomes possible. Suzuki and Yamamoto [17] assert that capturing aspects at the design phase streamlines the process of AO development, as it aids learning and documents aspects earlier in the design phase. Clarke and Walker [3] suggest that capturing aspects at the design phase makes round trip development of AO systems possible, helping maintain consistency of requirements, design, and implementation.

Aspect-oriented modeling (AO) ought to have the same relationship to aspect oriented programming as object-oriented (OO) modeling has to object oriented programming. Since UML is the "standard" modeling language for OO, it is natural to try to use it for AO. Most research on AO modeling has taken this approach. Composition Patterns [3] addresses crosscutting requirements in the design phase of the development lifecycle. That approach extends UML to model aspectual behavior, separating crosscutting requirements in design. This supports traceability for crosscutting behavior that is separated at the code level, aiding traceability throughout development lifecycle. Composition Patterns is based on combining ideas from subject-oriented modeling for composing separate designs with UML templates. In the Crichton approach [4], the authors provide a modeling technique to achieve separation of concerns using statecharts. That work differentiates between active objects and passive objects at the operation level. It associates a statechart for classes, and each operation within the class has a statechart describing its behavior. However, both the Composition Patterns and the Crichton approaches require extending UML and the associated CASE tools. In Composition Patterns, UML must be extended to support binding composition relationships and the UML template specifications. In Crichton, UML is extended to support associating operations to statecharts.

Our approach uses standard UML mechanisms. This enables off-the shelf CASE tools to be used with our methodology. The key idea of our work is to use advanced features of statecharts to describe crosscutting behavior and to achieve weaving. Combining behavioral-description UML class diagrams to describe structure and association relationships between objects leads to a complete description of the system model. This enables automatic code generation using existing UML CASE tools.

This chapter presents a design methodology and modeling technique for modeling aspect-oriented software systems using the standard object-oriented modeling language UML. The chapter is organized around the main design methodology components: concepts, notation, and the modeling language component, which are presented in Section 20.2. The process described by the design methodology is addressed in Section 20.3. Section 20.4 addresses the benefits of our methodology. We summarize in Section 20.5.