UML Timing Diagrams: An Agile Introduction

Timing diagrams are used to explore the behaviors of one or more objects throughout a given period of time. There are two basic flavors of timing diagram, the concise notation depicted in Figure 1 and the robust notation depicted in Figure 2. Timing diagrams are often used to design embedded software, such as control software for fuel injection system in an automobile, although they occasionally have their uses for business software too. Figure 1 depicts the lifecycle of a single seminar, showing its timeline quite clearly. The :Seminar label indicates that the lifeline being explored is that of an instance of Seminar. The critical states that the seminar exhibits – Proposed, Scheduled, Enrolling Students, Being Taught, Final Exams, Closed – are listed across the diagram. The two lines surrounding the states are called a general value lifeline. In this case I’m using them to show the value of the state of a seminar, but you could also explore the value of a single attribute of an object if you so choose. When the two lines cross one another it indicates a transition point between states. Along the bottom of the diagram timing constraints are shown, in this case indicating the period of time during which the seminar is in each state.

Figure 1. Timing diagram (concise notation).

It’s interesting to note the differences between the timing diagram of Figure 1 and the state machine diagram. Several states from the state machine diagram are encompassed by the Enrolling Students state of the timing diagram. That’s perfectly fine because I’m using each diagram for its individual strengths – concise timing diagrams are good at exploring one or more objects throughout a period of time and state machine diagrams are good at exploring the detailed transitions between states as the result of events (either external or internal). Remember AM’s Apply the Right Artifact(s) practice and use the right model for the job.

Figure 2 depicts a timing diagram which explores the details of what happens while a seminar is being taught. In this jaded example the professor delivers the seminar and marks student work and the teaching assistant develops the course material just in time for it to be taught. A UML frame is being used to bound the two lifelines (that of the professor and the teaching assistant); we could very easily have modeled more lifelines simply by adding other sections to the frame. The box lines are called state timelines, in this case there are discrete transitions between states resulting in a box line although had the transitions been continuous in nature (such as the change in temperature) a curvy line would have been drawn. The states/conditions applicable to the lifeline, such as Mark Student Work and Idle, are listed along the left-hand side of the diagram. Events/stimuli, such as Holiday Break and Break Ends, are optionally labeled at transition points to indicate the reason for the change. The arrows between timelines are messages between the objects.

Several ways to indicate time are shown in Figure 2. A timing constraint, {Oct 5..Oct 10} is shown as are time observations (t=Nov 25 and t=Dec 1). Timing constraints and time observations can be applied to a variety of UML diagrams, including all forms of interaction diagrams such as sequence diagrams and communication diagrams, although I find them most useful on timing diagrams. Unique to timing diagrams are timing rulers, depicted as tick mark values along the bottom of the diagram.

Figure 2. Timing diagram (robust notation).

Remaining Agile

Both notations have their purposes, although the robust notation seems the more useful of the two particularly for objects that move back and forth between states. The more lifelines you try to model at once the harder it is to draw the diagram so two lifelines is about as complex as I like to get. I draw timing diagrams on whiteboards, I don’t know of any mainstream modeling tool oriented towards business application development that supports this kind of diagram.

In my opinion very few developers will find that they need UML timing diagrams, so I really can’t recommend that you invest the time to learn them. For the few times that you need to explore timing issues free form diagrams will very likely suffice.

Source

This artifact description is excerpted from Chapter 11 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

Translations

Japanese

Disclaimer

The notation used in these diagrams, particularly the hand drawn ones, may not conform perfectly to the current version of the UML for one or more of reasons:

The notation may have evolved from when I originally developed the diagrams. The UML evolves over time, and I may not have kept the diagrams up to date.
I may have gotten it wrong in the first place. Although these diagrams were thoroughly reviewed for the book, and have been reviewed by thousands of people online since then, an error may have gotten past of us. We’re only human.
I may have chosen to apply the notation in “non-standard” ways. An agile modeler is more interested in created models which communicate effectively than in conforming to notation rules set by a committee.
It likely doesn’t matter anyway, because the modeling tool(s) that you’re using likely won’t fully support the current version of the UML notation perfectly anyway. Bottom line is that you’re going to be constrained by your tools anyway.

If you’re really concerned about the nuances of “official” UML notation then read the current version of the UML specification.