20.3. THE PROCESS PRESCRIBED BY OUR METHODOLOGYAn 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 StepsA 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.
20.3.2. The Concurrent Bounded Buffer ProblemWithin 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.
20.3.3. Analysis and DesignRequirements 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.
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.
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.
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 DiagramsClass 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
Figure 20-6. Event broadcasting.On a PUT event (see Figure 20-6 (B)), it
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
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:
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. |