The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Common Modeling Techniques

Modeling Timing Constraints

Modeling the absolute time of an event and modeling the relative time between events are the primary time-critical properties of real time systems for which you'll use timing constraints.

To model timing constraints,

• For each event in an interaction, consider whether it must start at some absolute time. Model that real time property as a timing constraint on the message.

• For each interesting sequence of messages in an interaction, consider whether there is an associated maximum relative time for that sequence. Model that real time property as a timing constraint on the sequence.

For example, as shown in Figure 24-4, the left-most constraint specifies the repeating start time for the call event refresh. Similarly, the right timing constraint specifies the maximum duration for calls to getImage.

Often, you'll choose short names for messages so that you don't confuse them with operation names.

Modeling the Distribution of Objects

When you model the topology of a distributed system, you'll want to consider the physical placement of both nodes and artifacts. If your focus is the configuration management of the deployed system, modeling the distribution of nodes is especially important in order to visualize, specify, construct, and document the placement of physical things such as executables, libraries, and tables. If your focus is the functionality, scalability, and throughput of the system, modeling the distribution of objects is what's important.

Deciding how to distribute the objects in a system is a difficult problem, and not just because the problems of distribution interact with the problems of concurrency. Naive solutions tend to yield profoundly poor performance, and over-engineered solutions aren't much better. In fact, they are probably worse because they usually end up being brittle.

To model the distribution of objects,

• For each interesting class of objects in your system, consider its locality of reference. In other words, consider all its neighbors and their locations. A tightly coupled locality will have neighboring objects close by; a loosely coupled one will have distant objects (and thus there will be latency in communicating with them). Tentatively allocate objects closest to the actors that manipulate them.

• Next consider patterns of interaction among related sets of objects. Colocate sets of objects that have high degrees of interaction, to reduce the cost of communication. Partition sets of objects that have low degrees of interaction.

• Next consider the distribution of responsibilities across the system. Redistribute your objects to balance the load of each node.

• Consider also issues of security, volatility, and quality of service, and redistribute your objects as appropriate.

• Assign objects to artifacts so that tightly coupled objects are on the same artifact.

• Assign artifacts to nodes so that the computation needs of each node are within capacity. Add additional nodes if necessary.

• Balance performance and communication costs by assigning tightly coupled artifacts to the same node.

Figure 24-5 provides an object diagram that models the distribution of certain objects in a retail system. The value of this diagram is that it lets you visualize the physical distribution of certain key objects. As the diagram shows, two objects reside on a Workstation (the Order and Sales objects), two objects reside on a Server (the ObserverAgent and the Product objects), and one object resides on a DataWarehouse (the ProductTable object).