Common Modeling Techniques
Modeling Multiple Flows of Control
Building a system that encompasses multiple flows of control is hard. Not only do you have to decide how best to divide work across concurrent active objects, but once you've done that, you also have to devise the right mechanisms for communication and synchronization among your system's active and passive objects to ensure that they behave properly in the presence of these multiple flows. For that reason, it helps to visualize the way these flows interact with one another. You can do that in the UML by applying class diagrams (to capture their static semantics) and interaction diagrams (to capture their dynamic semantics) containing active classes and objects.
Mechanisms are discussed in Chapter 29; class diagrams are discussed in Chapter 8; interaction diagrams are discussed in Chapter 19 . |
- Identify the opportunities for concurrent execution and reify each flow as an active class. Generalize common sets of active objects into an active class. Be careful not to over-engineer your system by introducing unnecessary concurrency.
Process views are discussed in Chapter 19; classes are discussed in Chapters 4 and 9; relationships are discussed in Chapters 5 and 10 . - Consider a balanced distribution of responsibilities among these active classes, then examine the other active and passive classes with which each collaborates statically. Ensure that each active class is both tightly cohesive and loosely coupled relative to these neighboring classes and that each has the right set of attributes, operations, and signals.
- Capture these static decisions in class diagrams, explicitly highlighting each active class.
- Consider how each group of classes collaborates with one another dynamically. Capture those decisions in interaction diagrams. Explicitly show active objects as the root of such flows. Identify each related sequence by identifying it with the name of the active object.
- Pay close attention to communication among active objects. Apply synchronous and asynchronous messaging, as appropriate.
- Pay close attention to synchronization among these active objects and the passive objects with which they collaborate. Apply sequential, guarded, or concurrent operation semantics, as appropriate.
For example, Figure 23-4 shows part of the process view of a trading system. You'll find three objects that push information into the system concurrently: a StockTicker, an IndexWatcher, and a CNNNewsFeed (named s, i, and c, respectively). Two of these objects (s and i) communicate with their own Analyst instances (a1 and a2). At least as far as this model goes, the Analyst can be designed under the simplifying assumption that only one flow of control will be active in its instances at a time. Both Analyst instances, however, communicate simultaneously with an AlertManager (named m). Therefore, m must be designed to preserve its semantics in the presence of multiple flows. Both m and c communicate simultaneously with t, a tradingManager. Each flow is given a sequence number that is distinguished by the flow of control that owns it.
Figure 23-4. Modeling Flows of Control

State machines are discussed in Chapter 22 . |
Modeling Interprocess Communication
As part of incorporating multiple flows of control in your system, you also have to consider the mechanisms by which objects that live in separate flows communicate with one another. Across threads (which live in the same address space), objects may communicate via signals or call events, the latter of which may exhibit either asynchronous or synchronous semantics. Across processes (which live in separate address spaces), you usually have to use different mechanisms.
Signals and call events are discussed in Chapter 21 . |
Modeling location is discussed in Chapter 24 . |
- Model the multiple flows of control.
Stereotypes are discussed in Chapter 6; notes are discussed in Chapter 6; collaborations are discussed in Chapter 28; nodes are discussed in Chapter 27 . - Model messaging using asynchronous communication; model remote procedure calls using synchronous communication.
- Informally specify the underlying mechanism for communication by using notes, or more formally by using collaborations.
Figure 23-5 shows a distributed reservation system with processes spread across four nodes. Each object is marked using the process stereotype. Each object is marked with a location attribute, specifying its physical location. Communication among the ReservationAgent, TicketingManager, and HotelAgent is asynchronous. Communication is described in a note as building on a Java Beans messaging service. Communication between the tripPlanner and the ReservationSystem is synchronous. The semantics of their interaction is found in the collaboration named CORBA ORB. The TRipPlanner acts as a client, and the ReservationAgent acts as a server. By zooming into the collaboration, you'll find the details of how this server and client collaborate.
Figure 23-5. Modeling Interprocess Communication
