Section 9.8. Timing Constraints


9.8. Timing Constraints

Up 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 them


9.8.1. Timing Constraint Formats

A 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


Table 9-1. Different ways of specifying a timing constraint

Timing Constraint

Description

{t..t+5s}

The duration of the event or state should be 5 seconds or less.

{<5s}

The duration of the event or state should be less than 5 seconds. This is a slightly less formal than {t..t+5s}, but an equivalent notation.

{>5s, <10s}

The duration of the event or state should be greater than 5 seconds, but less than 10 seconds.

{t}

The duration of the event or state should be equal to the value of t. This is a relative measure, where t could be any value of time.

{t..t*5}

The duration of the event or state should be the value of t multiplied 5 times. This is another relative measure (t could be any value of time).


9.8.2. Applying Timing Constraints to States and Events

At 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





Learning UML 2.0
Learning UML 2.0
ISBN: 0596009828
EAN: 2147483647
Year: 2007
Pages: 175

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