9.8. Timing ConstraintsUp until this point, you have really only been establishing the foundation of a timing diagram. Participants, states, time, and events and messages are the backdrop against which you can start to model the information that is really important to a timing diagramtiming constraints . Timing constraints describe in detail how long a given portion of an interaction should take. They are usually applied to the amount of time that a participant should be in a particular state or how long an event should take to be invoked and received, as shown in Figure 9-13. By applying constraints to this timing diagram, the duration of event1 must be less than one value of the relative measure t, and p2:Participant2 should be in State4 for a maximum of five seconds. Figure 9-12. Participant state changes make much more sense when you can see the events that cause them9.8.1. Timing Constraint FormatsA timing constraint can be specified in a number of different ways, depending on the information your are trying to model. Table 9-1 shows some common examples of timing constraints. Figure 9-13. Timing constraints can be associated with an event or a state and may or may not be accompanied by constraint boundary arrows
9.8.2. Applying Timing Constraints to States and EventsAt the beginning of this chapter, we extended Requirement A.2 to specify some timing considerations. Requirement A.2's timing considerations can now be added to the timing diagram as timing constraints. Figure 9-14 completes the Create a new Regular Blog Account timing diagram, capturing Requirement A.2's timing considerations by applying constraints to the relevant states. As you can see from Figure 9-14, applying the 5 seconds per new regular blog account creation timing constraint is not a straightforward job since it affects several different nested interactions between participants. This is where the skill of the modeler comes into play on a timing diagram; you need to decide which events or states need to be allocated portions of the available five seconds so each participant can do its job (and get those allocations right). Figure 9-14. From when the :Administrator clicks on submit until the point at which the system has created a new account, no more than five seconds have passed |