Section 20.3. THE PROCESS PRESCRIBED BY OUR METHODOLOGY


20.3. THE PROCESS PRESCRIBED BY OUR METHODOLOGY

An important element of a sound behavioral modeling approach is a rigorous methodology that ensures that the semantics of the constructed model conforms to its implementation and requirements. In this section, we introduce the process prescribed by the design methodology. Section 20.3.1 describes the activities that have to be carried out to apply the methodology. We introduce the methodology by example in Sections 20.3.2 through 20.3.5. Section 20.3.6 outlines the benefits realized by this methodology.

20.3.1. AO Modeling Steps

A methodology's process describes the sequence activities that must be carried out to apply the methodology [11]. It also describes the output of each step. Table 20-2 shows the modeling steps of our methodology. In the following sections, we outline how and when to apply each step and each step's output.

Table 20-2. Modeling Steps

Step #

Description

Output

1

Identify key core objects in the system.

Core objects

2

Identify crosscutting concerns.

Aspects

3

Identify how objects and aspects relate to each other by defining association relationships between them.

Associations (messages, each message implies an association between participating objects)

4

Model each object and aspect as an autonomous class.

Classes

5

Draw the class diagram based on previous four steps.

Class diagram

6

Identify the set of states for each object in the object structure and the dependencies between them.

A set of states names and state dependencies

7

Use the output of step 6 to describe the behavior of each class in the class diagram using statecharts.

Statecharts (behavioral description)

8

Use broadcasting mechanisms to send messages (events) between object's statechart using associations from step 3.

Implicit weaving

9

Introduce aspects as they arise orthogonally to the system and determine association relationships to existing objects and aspects.

Extensible model that is easy to maintain and comprehend


20.3.2. The Concurrent Bounded Buffer Problem

Within the concurrent objects, state transitions may occur if a method is invoked or a timer has expired. Associating aspects to be evaluated when an object method is invoked is troublesome for the system modeler and developer, as the specification and constraints of these aspects are state-dependent. To illustrate the practicality of our design methodology, we apply it to the design and development of a concurrent bounded buffer. In Table 20-3, we outline the requirements that we placed on the bounded buffer system. The buffer has a limited capacity and can handle multiple read requests concurrently, while queuing all write requests. Write requests should block all other services; a blocked service is queued until the buffer is finshed writing. Synchronization and scheduling requirements crosscut the core functionality of the bounded buffer.

Table 20-3. Bounded Buffer Requirements

Requirement #

Requirement Description

R1

The buffer will have a limited capacity.

R2

Items in the buffer will be accessed via get and put methods.

R3

The system will allow more than one reader to access the buffer at the same time.

R4

The system will allow only one writer to access the buffer at a certain time.

R5

The buffer will block all requests when a writer is present.

R6

The buffer will block get requests when it's empty.

R7

The buffer will block put requests when it's full.


20.3.3. Analysis and Design

Requirements R6 and R7 in Table 20-3 state that we allow only the put method to proceed when the buffer is in an EMPTY state. Either put or get can be issued when the buffer is in PARTIAL state. And we shall allow only get when the buffer is in FULL state. Requirements R7 and R8 are the synchronization requirements that control access to the bounded buffer. Requirements R3 through R6 are the main scheduling requirements. They impose certain access requirements on the system, for example, that only one writer can access the system at a time, or that more than one reader can access the system at a time. Synchronization constraints and scheduling specifications are the main crosscutting requirements (aspects) that influence the execution of the invoked methods based on the object state. Figure 20-3 shows the state machine for the system with the synchronization requirements and the scheduling policies intermixed with the main functionality of the buffer. Our approach extracts these scattered aspect codes and models as autonomous pieces of behavior. In the bounded buffer statechart shown in Figure 20-3, it is troublesome to associate a condition to a transition. For example, when the buffer is in PARTIAL state and it receives a get event, the buffer has to evaluate the synchronization constraint (if the number of items in the buffer is equal to zero) and the scheduling constraint (if there are any writers accessing the buffer, queue request) before proceeding with the transition. Depending on the outcome of both constraints, the buffer might transit to the EMPTY state or remain in the PARTIAL state. We are able to eliminate the hardwiring of conditions to transitions. This hard wiring is the main cause for tangled design and its consequent tangled code.

Figure 20-3. Concurrent bounded buffer statechart with crosscutting concerns intermixed with main functionality.


Steps 1 and 2. So far, we know that our system is composed of one main object that handles reading from and writing to the buffer. We also know that the buffer requires synchronization and scheduling, which will be modeled as aspects. The outputs from Steps 1 and 2 are shown in Table 20-4.

Table 20-4. Output from Step 1 and Step 2

Step 1

Identify key objects in the system.

BoundedBuffer object

Step 2

Identify crosscutting concerns.

Synchronization Aspect, Scheduling Aspect


Step 3. For objects to communicate, they must associate with each other. We have cleanly mapped the states of the bounded buffer to the states of the scheduling aspect by a one-to-one relationship, as shown in Table 20-5.

Table 20-5. Mapping Bounded Buffer States to Scheduling Aspect States

Bounded Buffer State

Scheduling Aspect State

Description

IDLE

IDLE

There are no requests.

Writing

HaveWriters

A writer is currently writing to the buffer

Reading

Has-a-Readers

Readers currently reading from the buffer.


We have also related the synchronization aspect states to the buffer's states (FULL, PARTIAL, and EMPTY) depending on the number of items in the buffer. This mapping allows the synchronization aspect to block get requests when there are no items in the buffer (R7) and to block put methods when the buffer has reached its maximum capacity (R8). To prevent deadlocks, synchronization concerns have to be resolved before scheduling concerns. This implies a temporal ordering of the synchronization and scheduling aspects. The output from Step 3 is shown in Table 20-6. These associations are required to enable objects to communicate with each other.

Table 20-6. Output from Step 3

Step 3

Identify how objects and aspects relate to each other by defining association relationships between them.

Association:

Scheduling Aspect BoundedBuffer object.

Synchronization Aspect Scheduling Aspect.


So far, we have identified objects, aspects, and association relationships between them. The next action is described in Section 20.3.4, constructing the class diagram.

20.3.4. Structural Description Using Class Diagrams

Class diagrams can be used to describe the static structure of the system (classes, aspects) and define the static relationships between these objects. For objects to communicate, they must associate with each other; therefore, we have to use the associations from Step 3 to connect them. We study the structure of the model using the bounded buffer problem. The bounded buffer system consists of the main functionality object, the synchronization aspect, and the scheduling aspect (from Step 3). Figure 20-4 shows the class diagram for the bounded buffer, which is the output of Steps 4 and 5. Each class in the class diagram defines its own static structure including attributes, methods, and interfaces. The lines between classes denote association relationships. The scheduling aspect is associated with readers' and writers' queues to queue read and write requests when they have to be blocked (i.e., when a put request is currently running).

Figure 20-4. Bounded buffer class diagram.


20.3.5. Modeling Crosscutting Concerns (Steps 68)

The model shown in Figure 20-3 does not align with the main principles of separation of concerns. It is clear that both synchronization and scheduling constraints crosscut the main functionality of the bounded buffer. The conditions are hard-wired to the transition. We need to extract these conditions from the main functionality of the buffer and model them as autonomous pieces of behavior (aspects). By doing so, we guarantee that the bounded buffer's main functionality (design and the associated code) will not be tangled with the synchronization and scheduling aspects. Transitions in the bounded buffer are now controlled by aspects, which can be described by an independent statechart, as shown in Figure 20-5. Notice that extracting these crosscutting concerns (synchronization and scheduling) from the main bounded buffer makes the main functionality easier to understand and reuse, as the buffer deals only with reading and writing items.

Figure 20-5. Concurrent bounded buffer statechart with aspects.


We have achieved a unified approach. The states of the buffer, synchronization, and scheduling aspect are now controlled by the same events (put and get). Producers that trigger the put event and consumers that trigger the get event can access the system concurrently. The synchronization aspect intercepts events by default as reflected by the arrow going into the aspect state machine region. State transitions are dependent on the aspect's state (and implicitly on the buffer's state). For example, when there are no items in the buffer, the synchronization aspects are in the EMPTY state. When a producer issues a put event, the following occurs.

The synchronization aspect intercepts the event, as its region is the only region that has a transition triggered by the put event shown in Figure 20-6 (A). It

  • Changes its state to PARTIAL.

  • Increases the number of items by one.

  • Broadcasts a PUT[1] event.

    [1] Event PUT is not the same as event Put or put.

  • The scheduling aspect region is the only region that has a transition triggered by the PUT event.

Figure 20-6. Event broadcasting.


On a PUT event (see Figure 20-6 (B)), it

  • Changes its state to haveWriters (assuming it's in IDLE state).

  • Increases the number of writers by one.

  • Broadcasts an evPUT event to the buffer.

The buffer is the only region that has a transition triggered by the evPUT event. When the buffer receives the evPUT event (see Figure 20-6 (C)), it

  • Changes its state to Writing. (That is, it starts writing the item into the buffer.)

  • When the put operation successfully completes writing the buffer, the buffer broadcasts an evDONE event back to the scheduling aspect.

Figure 20-7 shows the events as they progress from one object to another in response to a producer issuing event evPUT. The sequence of events is as follows:

  • A consumer object issues the put event.

  • The synchronization aspect intercepts the event (since its region is the only region that has a transition triggered by the put event), and it changes its state to PARTIAL, increases the number of items by one, and broadcasts the PUT event, as shown in Figure 20-7 (A).

  • Since the scheduling aspect region is the only region that has a transition triggered by the PUT event, it changes its state to haveWriters (assume that it is in the IDLE state), increases the number of writers by one, and broadcasts the evPUT event, as shown in Figure 20-7 (B).

  • Once the buffer receives the evPUT event, it changes its state to writing and starts writing the item into the buffer. When writing completes, it transitions back to IDLE state and broadcasts the event DONE, as shown in Figure 20-7 (C).

Figure 20-7. Event broadcasting.


The scheduling aspect intercepts the event DONE, decreases the number of writers by one, and returns to the IDLE state.



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