14.2 Control Strategies


In addition to partitioning behavior into the lifecycles of objects, we need some strategies to organize control from a broad perspective. First among these is whether control is "pushed" or "pulled" along a single macro control cycle. In the online bookstore, for example, the checkout of a shopping cart pushes control and the associated parameters forward until the order is shipped or held up on back-order. In contrast, we could have organized control so a shipping clerk attempted to pack a shipment by requesting the next order, thus "pulling" the data toward the shipment.

The online bookstore ordering control cycle naturally favors pushing control, so let's examine a more neutral example.

14.2.1 Push and Pull Control

A power company sends bills to customers based on the meter readings taken at the customers' electric meters. These readings are taken on different days by different meter readers reading meters along different routes.

In a simple model where each meter is billed separately, we can imagine a simple control scheme where a bill is pushed out when a meter is read, as shown schematically in Figure 14.4.

Figure 14.4. Push Control

graphics/14fig04.gif

But while some customers are billed for a single meter only, other customers are billed for readings taken at several meters. These meters may be along different routes read on different days. A push scheme for the control would require a separate bill per reading, which is not what the customer wants.

In addition, to even out the work in the billing department, bills are produced on fixed days each month according to a billing cycle, which also argues against a simple push approach.

On the other hand, a pure pull approach would create the bills on the accounts' cycle dates. The bills would then request readings of the meters. These requests would then dispatch the meter readers to read the meters. The meter readings would then be posted to the bills. Only when all the readings were collected could the bills be sent, as illustrated in Figure 14.5.

Figure 14.5. Pure Pull Approach

graphics/14fig05.gif

Such an approach might be reasonable if the all the meters were read immediately (e.g., through electronic remote meter reading), but in practice, both bills and readings are scheduled in advance according to billing cycles and meter routes.

We therefore have two macro control cycles: one focused on the meter readings and the other centered around billing cycles.

14.2.2 The Pivot Point

Control can be divided so that it is pushed one way and pulled from another.

Meter readings will be pushed into the system, but only so far as they create charges against the accounts. The charges are then not billed until the account to which they are posted is billed according to its regular billing cycle. Likewise, the account cannot be billed unless there are charges posted to the account from the meter readings.

The pivot point is the class at which the flow of control changes from push to pull or vice versa.

Figure 14.6 shows how a meter reading pushes data down to the charges, while the bill pulls data up from the charges to assemble the monthly bill. The pivot point is the class that represents the highest common factor of the data: We break meter readings down into charges and assemble them into the monthly bill.

Figure 14.6. Two Concurrent Cycles with a Pivot Point

graphics/14fig06.gif

The best pivot point is that class at which the data can no longer be pushed or pulled usefully to the next step. Hence, the data in the power company billing example can be pushed until it is represented as a charge, but it can't be pushed further. This matches the macro cycle of the meter reading. Similarly, the data can be pulled as far back as the charge, but charges can't be created until the meter is actually read. This corresponds to the macro cycle of the billings. Both views support the notion that the pivot point is the charge class.

14.2.3 Finding the Pivot

The concepts of mixed push-and-pull control and the pivot point are important when a domain has multiple concurrent activities that need to rendezvous. In the case of the power company, meter reading and billing occur concurrently in the large, but the production of an individual bill requires the completion of individual meter readings. In the case of the online bookstore, three macro control cycles rendezvous: Customers place orders, product is available in inventory, and shipping clerks prepare shipments.

To find the pivot point, examine the class diagram for the classes that participate in the collaborations, and use the class that has the most instances as the pivot point. Often the class with the most instances in a collaboration is the one that represents the last useful stage of disassembly into more objects. The next step is to reassemble the many objects into larger units based on some controlling incident.

The left side of Figure 14.7 shows a simplified class diagram for the electric company. (To clarify the assembly and disassembly of the data, the diagram replaces all association classes with simple associations.) Data can be pushed as far as the Charge before the charges need to be accumulated based on the time at which the Billing Groups are sent out. The Charge is the "highest common factor" of Billing Groups and Meter Readings, hence the pivot point for the electricity company is the Charge.

Figure 14.7. Class with the Most Instances is a Candidate Pivot Point

graphics/14fig07.gif

Similarly, for the bookstore, the pivot point is the shipment. The order comprises several shipment items that are in turn assembled into a shipment by a shipping clerk.

In addition to this data assembly/disassembly criterion, assigners factor strongly into the problem of organizing control. When one object in a competitive association is available but the other side is not, control can go only as far as the assigner, so the macro control cycle is terminated.

For example, when a customer places an order, the order and its selections can be pushed only as far as inventory is available. The order is then pulled by the shipment assigner only when sufficient stock is available to create the shipment. Finally, the shipment is pulled by the shipping clerk only when a clerk can be assigned to pack the shipment.



Executable UML. A Foundation for Model-Driven Architecture
Executable UML: A Foundation for Model-Driven Architecture
ISBN: 0201748045
EAN: 2147483647
Year: 2001
Pages: 161

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net