Section 20.4. REALIZING THE BENEFITS OF OUR METHODOLOGY


20.4. REALIZING THE BENEFITS OF OUR METHODOLOGY

In this section, we outline the benefits that are realized using this design methodology: implicit weaving, loose coupling, adaptability, traceability, and CASE tool support.

20.4.1. Implicit Weaving

We have demonstrated that we can decompose the overall system behavior into autonomous smaller pieces of behavior (aspect objects and core objects). Weaving is the process of combining different pieces of code (aspects code with core functionality code) into one executable module. We achieve implicit weaving by means of the event broadcasting techniques that send events from one state to another. Implicit weaving has the benefit of reducing coupling, as it maintains separation of concerns at the design as well as the code phase.

20.4.2. Loose Coupling

Propagating events from one object to another increases coupling between them. On the other hand, broadcasting events eliminates coupling but increases overhead. We use unique event names when an object needs to signal an event to another object and do not want another object to respond to that event (synchronous). For example, in the bounded buffer, the synchronization aspect broadcasts the GET event. The scheduling aspect implicitly (no coupling) intercepts this event since it is the only object that is affected by it. The scheduling aspect in turn processes the request and broadcasts the event evGET. The bounded buffer again intercepts the event implicitly, does the actual reading of the item, and, once done, broadcasts the evDONE event to be intercepted by the scheduling aspect. Introducing new events for each interface to an object increases the number of events as the number of objects/aspects increases. Tradeoffs among these different possibilities are application-dependent.

20.4.3. Extensibility

We can add more orthogonal aspects to the system without impacting the existing orthogonal regions (existing aspects or main functionality). To demonstrate this, we introduce the Error Handler aspect to the concurrent bounded buffer. The Error Handler aspect statechart is shown in Figure 20-8 A.

Figure 20-8. Error Handler aspect.


We define an association relationship(s) between the Error Handler aspect and the other aspects/objects in the system. Assume that a new requirement has been added to enable the synchronization aspect to generate an error when a request for get is broadcast while the system is in EMPTY state. From this requirement, we can determine that there is an association relationship between the synchronization aspect and error aspects. This association is shown in Figure 20-8 (A); Figure 20-8 (B) shows the statechart for the Error Handler aspect. After the Error Handler aspect has been introduced to the system's class diagram via an association relationship with the synchronization aspect, the synchronization aspect can broadcast events to it. The synchronization aspect now broadcasts the ERROR event when there is a request for GET, when the buffer is in the EMPTY state, or when there is a request for put when the buffer is in FULL state. Nothing else has changed. There is no impact on the scheduling aspect or the buffer itself. If the system evolves so that the scheduler needs the new error service, we first must define an association to then. The schedule can then generate errors simply by broadcasting ERROR events.

20.4.4. Traceability

Earlier, we argued that one of the benefits of introducing aspects at an early phase of the development lifecycle is traceability: the ability to trace the derivation from requirements through design to code. Table 20-7 shows where the requirements of the bounded buffer have been implemented.

Table 20-7. Requirements Traceability

Requirement #

Requirement Description

Implementation

R1, R6, R7

Capacity requirements

Synchronization aspect

R2

Access requirements

Buffer class

R3, R4, R5

Scheduling requirements

Scheduling aspect


20.4.5. CASE Tools Support for Our Methodology

Having captured aspects at a high level, including their role, behavior, structure, and crosscutting of classes, we would like to feed the model into existing UML CASE tools. Our research has progressed to the point where we have automatically generated the code for the bounded buffer with Rhapsody [12]. An important property of this code is that it preserves the separation between core modules and aspect modules. This in turn preserves the advantages of aspect orientation at the code level.

20.4.6. Automatic Code Generation and Round-Trip Development

As shown in Figure 20-9, the system model consists of static and dynamic behavior [10]. Both have been described so that we can have full automatic code generation (including weaving). We have used UML's class diagrams to describe the static view of the model and UML's statecharts to describe the dynamic view of the model. We fed our model to Rhapsody and automatically generated code from the design.

Figure 20-9. Automatic code generation via existing CASE tools.


In Figure 20-9, the double arrows between code and system model means round-trip development. Changes to either (code or design) are automatically reflected in the other. This round trip feature is supported by most existing object-oriented CASE tools.



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