Section 20.2. CONCEPTS, NOTATION, AND THE MODELING LANGUAGE
20.2. CONCEPTS, NOTATION, AND THE MODELING LANGUAGE20.2.1. Aspect-Oriented ProgrammingAOP provides mechanisms for decomposing a problem into functional and aspectual components (aspects). Aspects are concerns that cut across the functional components. Examples of aspects include synchronization, scheduling, logging, security, and fault tolerance. AOP attempts to modularize aspects and uses a weaving mechanism to combine aspects with the main functional components. In Figure 20-1, we show the difference between OO technology and AO technology. Figure 20-1. OO versus AO structure. While aspects can be thought about and analyzed separately from the core functionality, at some point before or at runtime, they must be woven together. In this chapter, we use statecharts as the communication mechanism for the weaving process. 20.2.2. The Unified Modeling Language (UML)UML [14] is a graphical language for specifying, visualizing, constructing, and documenting the artifacts of software systems. UML is the standard modeling language for object-oriented systems endorsed by Object Management Group (OMG). UML provides several different views of the static and dynamic behavior of a software system. Table 20-1 classifies UML diagrams into inter-object behavior diagrams (use case diagram, class diagram, collaboration diagrams and sequence diagrams) or intra-object behavioral diagrams (statecharts).
20.2.2.1 Class DiagramsUML class diagrams are used to describe the structural (static) view of classes. In our methodology, both core concerns and aspects are represented as classes. Each core class/aspect class in the class diagram is associated with a statechart that describes its dynamic behavior. When describing the structural view of the system, one must define classes. Interfaces depict the role a class (core/aspect) might play. Association relationships between core classes and aspects classes enable them to communicate. These relationships specify how the different components of the system are statically weaved. When combined with statechart communication mechanisms, they lead to an implicit weaving of the aspectual behavior with other components of the system. 20.2.2.2 StatechartsUML adopted David Harel's statecharts [9] for intra-object behavior modeling. Statecharts are a behavioral language for the specification of real-time, event-driven, and reactive systems. States in a statechart are "conditions of existence" that "persist" for a significant period of time [6]. Events trigger transitions from one state to another. They maybe guarded by conditions, which must be true before transitioning to the next state. Actions can occur as the result of a state transition. Transitions are the means by which objects change states in response to events. They follow the following format: Event [Condition] / Action. Orthogonal regions, shown as dashed lines in statecharts, combine multiple simultaneous descriptions of the same object. Interactions between regions typically occur through shared variables, awareness of state changes in other regions, and message passing mechanisms such as broadcasting, propagating, and the IN operator (discussed later) [5]. We choose statecharts to model the behavior of objects and aspects because
The unified approach supports the verification and validation of crosscutting concerns at the same level of verifying and validating core concerns. To support aspect-oriented modeling within the scope of statecharts, we employ advanced statechart artifacts supported by UML. This allows the explicit representation of aspects within the system model and achieves inter-aspect/object communication within the constructed model. In the following sections, we show how to utilize the statecharts to describe the behavior of aspects and objects. 20.2.2.3 Modeling Orthogonal Concerns Using Orthogonal RegionsStatecharts support decomposition of states in an AND/OR fashion, combined with the communication mechanisms to allow communications between states. Broadcast, propagate, and the IN() operator are the main communication mechanisms [5]. Broadcast events are events communicated to more than one orthogonal component. Propagate events are events that are signaled as a result of a transition occurring in one component. The IN() operator returns true if another component is currently in a specific state. In statecharts, states can be broken down hierarchically into three kinds:
Each of the concurrent sub-states is called an orthogonal component. Statechart models govern orthogonal states whereby an object must be in exactly one state from each of the orthogonal regions. For example, in Figure 20-2 (adopted from [5]), the object behavior is divided into two orthogonal regions (S and T). Component S must be in state A or state B. Component T must be in one of states C, D, or E. Figure 20-2. Modeling concurrency in UML.
When an object receives an event, it is sent to all orthogonal regions (S, T), and each region responds to that event if the event impacts it (i.e., when a region has a transition labeled with the event name). For example, in Figure 20-2, when the object receives event T3, then in region S, the object transitions to state B (given that the object is in state A), and in region T, the object transitions to state D (given that the object is in state C). The object final state will be { A, D} . If the event does not impact a region, the object simply maintains its current state. In Figure 20-2, if the T2 event is triggered, then region S transits to state A (given that it is in state B), and Region T maintains its current state (as there is no transition that is triggered by T2 in the region). We achieve implicit weaving and maintain separation of core concerns and aspect concerns though the use of the AND mechanism of the statecharts. This allows us to align orthogonal behavior with orthogonal aspects. By doing so, we guarantee separation of concerns in the design as well as in the implementation. | ||||||||||||||||||
EAN: 2147483647
Pages: 307