C HAPTER 11

Dynamic Object Modeling

No matter what happens, someone will find a way to take it too seriously.

Dynamic object modeling focuses on identifying the behavior and collabo-

rations between objects within your system. It is a critical aspect of object-
oriented (OO) design, as is structural object design (Chapter 12). Table 11.1
summarizes six dynamic modeling techniques described in this chapter, all of
them defined by the unified modeling language (UML) (Object Management
Group 2003).
The purpose of design is to determine how you are going to build your
system, information needed to drive the actual implementation of your system
(object-oriented programming is covered in Chapter 13). First, just like other
aspects of development, design is also an iterative process. Second, analysis
and design are highly interrelated as are design and programming.
This chapter addresses the following topics:

r UML sequence diagrams;

r UML communication diagrams;
r UML state machine diagrams;
r UML timing diagrams;
r UML interaction overview diagrams; and
r UML composite structure diagrams.

319

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 320 DYNAMIC OBJECT MODELING

TABLE 11.1. Dynamic Modeling Techniques

Model Description

A UML diagram that shows instances of classes,

Communication their interrelationships, and the message flow
diagram between them. Communication diagrams
typically focus on the structural organization of
objects that send and receive messages and are
used to get a “bird’s-eye view” of those
collaborating objects.
A UML diagram that depicts the internal structure
Composite structure of a classifier (such as a class, component, or
diagram use case), including the interaction points of the
classifier to other parts of the system. Typically
used to explore the detailed implement required
to support a critical transaction or
collaboration.
A UML diagram (Chapter 9) that overviews the
Interaction overview control flow within a system or business
diagram process. Each node/activity within the diagram
can represent another interaction diagram. Used
to connect a collection of detailed diagrams
together.
A UML diagram that models the sequential logic,
Sequence diagram in effect the time ordering of messages between
classifiers. This diagram is the mainstay of
dynamic modeling; it is often used as a bridge
between usage requirements (Chapter 5) and
detailed structural designs (Chapter 12) or to
model the detailed design of an operation or
service.
A UML diagram that describes the states an object
State machine or interaction may be in, as well as the
diagram transitions between states. Typically used to
explore the design of a complex class or
component.
A UML diagram that depicts the change in state or
Timing diagram condition of a classifier instance or role over
time. Typically used to show the change in state
of an object over time in response to external
events.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.1 UML Sequence Diagrams 321

11.1 UML SEQUENCE DIAGRAMS

UML sequence diagrams model the flow of logic within your system in a
visual manner, enabling you both to document and validate your logic, and
are commonly used for both analysis and design purposes. In fact they are
often described as the bridging technique between analysis artifacts such as
system use cases and robustness diagrams and design-oriented artifacts such
as UML class diagrams. Sequence diagrams are the most popular UML artifact
for dynamic modeling. Sequence diagrams, along with class diagrams and
physical data models (Chapter 12), are in my opinion the most important
design-level models for modern business application development.
Sequence diagrams are typically used to model the following:
r Usage scenarios. A usage scenario is a description of a potential way your
system is used. The logic of a usage scenario may be part of a use case,
perhaps an alternate course. It may also be one entire pass through a use
case, such as the logic described by the basic course of action or a portion
of the basic course of action, plus one or more alternate scenarios. The
logic of a usage scenario may also be a pass through the logic contained in
several use cases. For example, a student enrolls in the university, and then
immediately enrolls in three seminars.
r The logic of methods. Sequence diagrams can be used to explore the logic
of a complex operation, function, or procedure. One way to think of se-
quence diagrams, particularly highly detailed diagrams, is as visual object
code.
r The logic of services. A service is effectively a high-level method, often one
that can be invoked by a wide variety of clients. This includes Web services
as well as business transactions implemented by a variety of technologies
such as CICS/COBOL or CORBA-compliant object request brokers (ORBs).

Let us start with three simple examples. Figure 11.1 depicts a UML sequence
diagram for the Enroll in University use case of Fig. 11.2, taking a system-level
approach where the interactions among the actors and the system are shown.
Figure 11.3 depicts a sequence diagram for the detailed logic of a service to
determine whether an applicant is already a student at the university. Figure
11.4 shows the logic for how to enroll in a seminar. I will often develop a
system-level sequence diagram with my stakeholders to help to both visualize
and validate the logic of a usage scenario. It also helps me to identify significant
methods/services, such as checking to see whether the applicant already exists
as a student, which my system must support.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 322 DYNAMIC OBJECT MODELING

FIGURE 11.1. A high-level system sequence diagram for Enroll in University use case.

Name: Enroll in University

Identifier: UC 19

Description:
Enroll someone in the university.

Preconditions:
The Registrar is logged into the system.
The Applicant has already undergone initial checks to verify that they are
eligible to enroll.

FIGURE 11.2. The Enroll in University use case.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.1 UML Sequence Diagrams 323

Postconditions:
The Applicant will be enrolled in the university as a student if they are eligible.

Basic Course of Action:

1. An applicant wants to enroll in the university.

2. The applicant hands a filled out copy of form U113 University Application
Form to the registrar. [Alternate Course A: Forms Not Filled Out]
3. The registrar visually inspects the forms.
4. The registrar determines that the forms have been filled out properly.
[Alternate Course B: Forms Improperly Filled Out]
5. The registrar clicks on the Create Student icon.
6. The system displays U189 Create Student Screen.
7. The registrar inputs the name, address, and phone number of the ap-
plicant. [Extension Point: UC34 Perform Security Check. Applicable to
Step 17]
8. The system determines that the applicant does not already exist within
the system according to BR37 Potential Match Criteria for New Students.
[Alternate Course F: Students Appears to Exist within the System].
9. The system determines that the applicant is on the eligible applicants list.
[Alternate Course G: Person Is Not Eligible to Enroll]
10. The system adds the applicant to its records. The applicant is now con-
sidered to be a student.
11. The registrar helps the student to enroll in seminars via the use case UC
17 Enroll in Seminar.
12. The system calculates the required initial payment in accordance to BR16
Calculate Enrollment Fees.
13. The system displays U115 Fee Summary Screen.
14. The registrar asks the student to pay the initial payment in accordance to
BR19 Fee Payment Options.
15. The student pays the initial fee. [Alternate Course D: The Student Cannot
Pay at This Time]
16. The system prints a receipt.
17. The registrar hands the student the receipt.
18. The use case ends.

Alternate Course A: . . . .

FIGURE 11.2 (continued)

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 324 DYNAMIC OBJECT MODELING

FIGURE 11.3. A service-level sequence diagram.

The reason they are called sequence diagrams should be obvious: the se-
quential nature of the logic is shown via the ordering of the messages (the
horizontal arrows). The first message starts in the top left corner, the next
message appears just below that one, and so on.
The boxes across the top of the diagram represent classifiers or their in-
stances, typically use cases, objects, classes, or actors. Because you can send
messages to both objects and classes, objects respond to messages through the

aStudent: Student : Seminar : Course

enrollStudent(aStudent)
isStudentEligible(aStudent)
getSeminarHistory()

seminarHistory
eligibilityStatus
enrollmentStatus

FIGURE 11.4. Detailed sequence diagram for enrolling in a seminar.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.1 UML Sequence Diagrams 325

invocation of an operation and classes do so through the invocation of static

operations; it makes sense to include both in sequence diagrams. Because
actors initiate and take an active part in usage scenarios, they can also be in-
cluded in sequence diagrams. Objects have labels in the standard UML format
name: ClassName, where “name” is optional (objects that have not been given
a name on the diagram are called anonymous objects). Classes have labels in
the format ClassName, and actors have names in the format Actor Name. No-
tice how object labels are underlined, classes and actors are not. For example,
in Fig. 11.4, you see the Student object has the name aStudent—this is called a
named object—whereas the instance of Seminar is an anonymous object. The
instance of Student was given a name because it is used in several places as a
parameter in messages, whereas the instance of the Seminar did not need to
be referenced anywhere else in the diagram and thus could be anonymous. In
Fig. 11.3 the Student class sends messages to the PersistenceFramework class
(which could have been given the stereotype <<infrastructure>> but was
not to keep the diagram simple). Any message sent to a class is implemented
as a static method; more on this later.
The dashed lines hanging from the boxes are called object lifelines, repre-
senting the life span of the object during the scenario being modeled. The long,
thin boxes on the lifelines are activation boxes, also called method-invocation
boxes, which indicate processing is being performed by the target object/class
to fulfill a message. I will only draw activation boxes when I am using a tool
that natively supports them, such as a sophisticated CASE tool, and when I
want to explore performance issues. Activation boxes are too awkward to draw
on whiteboards or with simple drawing tools that do not easily support them.
The X at the bottom of an activation box, an example of which is presented
in Fig. 11.5, is a UML convention to indicate an object has been removed from
memory or that it has been “let go.” In languages such as C++ where you need
to manage memory yourself you need to invoke an object’s destructor, typically

TIP
Design Is So Important You Should Do It Every Day
It is critical to think through how you are going to build something, to actually
design it, before you build it. Your design efforts may take the form of a sketch
on a whiteboard, a detailed model created with a sophisticated modeling tool,
or a simple test that you write before you write business code. Agile developers
realize that design is so important that they do it every day, that design is not
just a phase that you do early in the project before getting to the “real work” of
writing the source code.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at

326

Enroll In Seminar
Basic Course of
Action
A Student :MainMenu :SecurityLogon :SeminarSelector
SD#: UC17-01 <<actor>> <<UI>> <<UI>> <<UI>>
:EnrollInSeminar
<<controller>>
1. Student indicates wish to enroll wish to enroll

<<create>>
2. Student inputs name and number name
student number

3. System verifies student

theStudent theStudent
<<destroy>>
X <<create>>
4. System displays seminar list
selection
5. Students picks seminar
6. System determines eligibility to enroll

7. System determines schedule fit

8. System calculates fees

X
9. System displays fees
10. System verifies student wishes to enroll
11. Students indicates yes.
12. System enrolls student in seminar

FIGURE 11.5. A UML sequence diagram for the basic course of action for the Enroll in Semi-
nar use case.

Cambridge Books Online © Cambridge University Press, 2010

https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at

327

schedule
:FeeDisplay Student seminar:Seminar theStudent :StudentFees
:StudentSchedule
<<UI>> :Student

isEligible(name, studentNumber)
<<create>>

Note: Need to
flesh this
message
out more.

isEligibleToEnroll(theStudent) qualifications()

getSchedule()
determineFit(seminar)

calculateFees(seminar, theStudent)

<<create>>

verification

X enrollStudent(theStudent)

FIGURE 11.5. (continued)

Cambridge Books Online © Cambridge University Press, 2010

 328 DYNAMIC OBJECT MODELING

modeled as a message with the stereotype of <<destroy>>. In languages such

as Java or C# where memory is managed for you and objects that are let go are
automatically removed from memory, something often referred to as garbage
collection. I generally do not bother with modeling object destruction at all
and will instead trust that the programmers, often myself, will implement
low-level details such as this appropriately.
Figure 11.5 presents a complex UML sequence diagram for the basic course
of action for the Enroll in Seminar use case. This is an alternative way for
modeling the logic of a usage scenario; instead of doing it at the system-level
such as Fig. 11.1 you simply dive straight into modeling the detailed logic at
the object-level. I will take this approach when I am working with developers
who are experienced sequence diagrammers and I have a large working space
(either a huge whiteboard or a CASE tool installed on a workstation with a
very large screen and good graphic card). Most of the time I will draw system-
level diagrams first and then create small diagrams along the lines of what is
shown in Fig. 11.3 and Fig. 11.4.
Messages are indicated on UML sequence diagrams as labeled arrows. When
the source and target of a message is an object or class the label is the signature
of the method invoked in response to the message. However, if either the
source or target is a human actor, then the message is labeled with brief text
describing the information being communicated. For example, in Fig. 11.5
the EnrollInSeminar object sends the message isEligibleToEnroll(theStudent)
to the instance of Seminar. Notice how I include both the method’s name
and the name of the parameters, if any, passed into it. The Student actor
provides information to the SecurityLogon object via the messages labeled
name and student number (these really are not messages; they are actually user
interactions).
Return values are optionally indicated using a dashed arrow with a label
indicating the return value. For example, the return value theStudent is indi-
cated coming back from the Student class as the result of invoking a message,
whereas no return value is indicated as the result of sending the message
isEligibleToEnroll(theStudent) to Seminar. My style is not to indicate the re-
turn values when it is obvious what is being returned, so I do not clutter
my sequence diagrams (as you can see, sequence diagrams get complicated
fairly quickly). Figure 11.6 shows an alternate way for indicating return val-
ues using the format message: returnValue for messages, as you would with
isEligibleToEnroll(theStudent): false.
In Fig. 11.5 the steps of the use case are summarized down the left-hand
side of the diagram. Notice how I used an informal wording for the use case

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.1 UML Sequence Diagrams 329

Enroll In Seminar
Alternate Course of
Action: Student Does
not Have Prerequisites :EnrollInSeminar :IneligibilityNotice :SeminarDetails seminar:Seminar
<<controller>> <<UI>> <<UI>>
SD #: UC17-01C Student
chooses
seminar isEligibleToEnroll(theStudent): false
C.6. System determines ineligibility to enroll
<<create>>
C.7. System informs the student of ineligibility
C.8. System informs the student of <<create>>
prerequisites
C.9. Use case resumes at step 4

FIGURE 11.6. Modeling an alternate course of action.

steps—formal wording is often too wordy to fit nicely on a diagram. What

is critical is that the step numbers correspond to those in the use case and
the general idea of the step is apparent to the reader of the diagram. With
this approach the reader can easily see which messages correspond to which
use case steps, offering a very straightforward and simple traceability between
models.
Notice the use of stereotypes throughout the diagrams. For the boxes, I
applied the stereotypes <<actor>>, <<controller>>, and <<UI>>, indi-
cating they represent an actor, a controller class, or a user-interface (UI) class,
respectively. I have also used visual stereotypes on some diagrams—a stick
figure for actors; the robustness diagram visual stereotypes for controller, in-
terface, and entity objects in Fig. 11.7; and a drum for the database. Stereotypes
are also used on messages. Common practice on UML diagrams is to indicate
creation and destruction messages with the stereotypes of <<create>> and
<<destroy>>, respectively. For example, you see the SecurityLogon object is
created in this manner (actually, this message would likely be sent to the class
that would then result in a return value of the created object, so I cheated a
bit). This object later destroys itself in a similar manner, presumably when
the window is closed.
I used a UML note in Fig. 11.5; notes are basically free-form text that can be
placed on any UML diagram, to provide a header for the diagram, indicating
its title and identifier (as you may have noticed, I give unique identifiers to

TIP
Design Models Need to Be Just Barely Good Enough
You do not need to model every single detail in your models, and the models do
not need to be perfect.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 330 DYNAMIC OBJECT MODELING

Student
new

studentPage:
: TranscriptBuilder student: : Seminar <<system>>
StudentInfoPage
Student Printer
new(student)
getSeminars()

loop [for each seminar]

getMark()

calculateMark()

Print
print(studentPage)

FIGURE 11.7. Modeling how transcripts are output.

all artifacts that I intend to keep). Notes are depicted as a piece of paper with
the top-right corner folded over. I also used a note to indicate future work
that needs to be done, during either analysis or design, in this diagram—
the qualifications() message likely represents a series of messages sent to the
student object. Common UML practice is to anchor a note to another model
element with a dashed line when appropriate; in this case the note is attached
to the message.
Although Fig. 11.5 models the logic of the basic course of action for the En-
roll in Seminar use case, how would you go about modeling alternate courses?
The easiest way to do so is to create a single sequence diagram for each alter-
nate course, as you see depicted in Fig. 11.6. This diagram models only the
logic of the alternate course, as you can tell by the numbering of the steps
on the left-hand side of the diagram, and the header note for the diagram
indicates it is an alternate course of action. Also notice how the ID of this
diagram includes that this is alternate course C, yet another modeling rule of
thumb I have found useful over the years.
Let us consider other sequence diagramming notation. Figure 11.6 includes
an initial message, Student chooses seminar, which is indicated by the filled in
circle. This could easily have been indicated via a method invocation, perhaps
enrollIn(seminar). Figure 11.7 shows another way to indicate object creation—
sending the new message to a class. We have actually seen three ways to achieve

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.1 UML Sequence Diagrams 331

FIGURE 11.8. Enrolling in the university.

this, the other two being to send a message with the <<create>> stereotype
and/or to send a message into the side of the classifier symbol (for example,
in Fig. 11.5 the message going into the side of EnrollInSeminar or in Fig. 11.7
the message going into the side of StudentInfoPage). My advice is to choose
one style and stick to it.
Figure 11.7 and Fig. 11.8 each depict a way to indicate looping logic.
One way is to show a frame with the label loop and a constraint indicating
what is being looped through, such as for each seminar in Fig. 11.7. Another
approach is to simply precede a message that will be invoked several times
with an asterisk, as you see in Fig. 11.8 with the inclusion of the Enroll in
Seminar use case.
Figure 11.7 includes an asynchronous message, the message to the system
printer that has the partial arrowhead. An asynchronous message is one where
the sender does not wait for the result of the message; instead it processes the
result when and if it ever comes back. Up until this point all other messages
have been synchronous, messages where the sender waits for the result before

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 332 DYNAMIC OBJECT MODELING

continuing on. It is common to send asynchronous messages to hardware

devices or autonomous software services such as message buses.
The method of modeling the inclusion of use cases used in Fig. 11.8 is
something that I first proposed in The Elements of UML Style (Ambler 2003b)
although I have no doubt that others use this approach as well. I basically
show the use case as a bubble across the top of the diagram, just like any other
classifier, and show a message sent to it with the <<include>> stereotype.
This is consistent with both use case diagramming and sequence diagramming
practices.
Figure 11.8 is also interesting because it shows how to model conditional
logic. In this case a frame with the label alt is used along with a guard, in this
case applicant on eligibility list. The frame is separated into regions separated
by dashed lines. In this case there are two regions, one for each alternative,
although you can have as many regions as you require (to support the visual
equivalent of a case statement). Each region requires a guard.

11.1.1 Visual Coding Via Sequence Diagrams

Earlier I stated that sequence diagrams are effectively a form of visual coding,
or perhaps another way to think of it is that sequence diagrams can be used
for very detailed design. When I developed the sequence diagram of Fig.
11.5 I made several decisions that could potentially affect my other models.
For example, as I modeled Step 10, I made the design decision that the fee
display screen also handled the verification by the student that the fees were
acceptable.
Also, as I was modeling Steps 2 and 3, I came to the realization that stu-
dents should probably have passwords to get into the system. When you are

TIP
Design for Your Implementation Environment Judiciously
Take advantage of features of your implementation environment, but be smart
about it. Trade-offs are normal, but understand the implications and manage
the risks involved. Every time you take advantage of a unique performance
enhancement in a product (such as a database, operating system, or middleware
tool) you are likely coupling your system to that product and, thus, reducing its
portability. To minimize the impact of your implementation environment on your
systems, you can layer your software (Chapter 10) and wrap specific features
to make them appear general to their users. Wrapping is discussed in detail in
Building Object Applications That Work (Ambler 1998a).

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.1 UML Sequence Diagrams 333

following the AM practices of active stakeholder participation and model with

others it is easy to find out whether ideas such as this make sense because all
you need to do is ask. In this case I discovered I was wrong: the combina-
tion of name and student number is unique enough for our purposes and the
university did not want the added complexity of password management. This
is an interesting decision that would potentially be recorded as a business
rule because it is an operating policy of the university, indicating the need to
follow the practice iterate to another artifact and jot down the rule if we are
interested in keeping a permanent record of it.

11.1.2 How to Draw Sequence Diagrams

I have been trying to explain to people how to draw sequence diagrams for
years, and what I have discovered is that the people who get it are either
very good at thinking in a logical manner and/or they are good at writing
software code. Sequence diagramming really is visual coding, even when you
are modeling a usage scenario via a system-level sequence diagram.
When I am creating a sequence diagram I will start by identifying the scope
of what I am trying to model, and because I prefer to follow the AM practice
model in small increments I will typically tackle small usage scenarios at the
system level or a single method/service at the detailed object level. A diagram
such as Fig. 11.5 is too complex to be useful in my experience.
I will then work through the logic with at least one more person, laying out
classifiers across the top as I need them. I automatically add the object lifelines
but, as I indicated earlier, will typically not invest time adding activation boxes.
The heart of the diagram is in the messages, which I add to the diagram one
at a time as I work through the logic. I rarely indicate return values; instead I
will give messages intelligent names, which often make it clear what is being
returned.
It is interesting to note that as you sequence diagram you will identify new
responsibilities for classes and objects, and, sometimes, even new classes. The
implication is that you may want to update your class model appropriately;
agile modelers will follow the practice create several models in parallel, some-
thing that CASE tools will do automatically. Remember that each message
sent to a class invokes a static method/operation on that class; each message
sent to an object invokes an operation on that object.
Regarding style issues for sequence diagramming, I prefer to draw messages
going from left to right and return values from right to left, although that
does not always work with complex objects/classes. I justify the label on

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 334 DYNAMIC OBJECT MODELING

messages and return values, so they are closest to the arrowhead. I also prefer
to layer the sequence diagrams: from left to right. I indicate the actors, then
the controller class(es), and then the user interface class(es), and, finally,
the business class(es). During design, you probably need to add system and
persistence classes, which I usually put on the right-most side of sequence
diagrams. Laying your sequence diagrams in this manner often makes them
easier to read and also makes it easier to find layering logic problems, such as
user-interface classes directly accessing persistence classes.

11.1.3 Keeping It Agile

The most important thing that you can do is to keep your diagrams simple,
both content wise and tool wise. I will sketch sequence diagrams on white-
boards to think something through, either to verify the logic in a use case or
to design a method or service. I rarely keep sequence diagrams as I find their
true value is in their creation.
A common mistake is to try to create a complete set of sequence diagrams for
your system. I have seen project teams waste months creating several sequence
diagrams for each of their use cases, one for the basic course of action and
one for each alternate course. My advice is to only create a sequence diagram
when you have complex logic that you want to think through—if the logic is
straightforward the sequence diagram will not add any value; you had might
as well go straight to code.

11.2 UML COMMUNICATION DIAGRAMS

A fundamental concept of the UML is that you use different diagrams for
different purposes. Class diagrams are used to model the static nature of
your system, sequence diagrams are used to model sequential logic, and state
machine diagrams are used to model the behavior of complex classes. But what
happens when you need to show the behavior of several objects collaborating
together to fulfill a common purpose? This is what UML communication
diagrams, formerly known as collaboration diagrams in UML 1.x, can be used
for because they provide a bird’s-eye view of a collection of collaborating
objects.
Communication diagrams show the message flow between objects in an
OO application and also imply the basic associations (relationships) between
classes. Figure 11.9 presents a simplified collaboration diagram for displaying

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.2 UML Communication Diagrams 335

1: getName(): seminarName
2: getDescription()
3: getLocation() 1.1: getName(): string
4: getSeatsLeft() 1.2: getNumber(): string
:Seminar 5: getStudentList() 2.1: getDescription(): string
Details :Seminar :Course
<<UI>>

* 5.1: getInfo

enrollment
:Enrollment
Actually a series of
getter invocations.

5.1.1: getInfo

student
:Student
5.1.1.1: getFullName()

FIGURE 11.9. A communication diagram for displaying seminar details.

a seminar details screen or page. The rectangles represent the various ob-
jects involved that make up the application. The lines between the classes
represent the relationships (associations, composition, dependencies, or in-
heritance) between them. The same notation for classes and objects used on
UML sequence diagrams are used on UML communication diagrams, another
example of the consistency of the UML. The details of your associations, such
as their multiplicities, are not modeled because this information is contained
on your UML class diagrams: remember that each UML diagram has its own
specific purpose and no single diagram is sufficient on its own. Messages are
depicted as a labeled arrow that indicates the direction of the message, using
a notation similar to that used on sequence diagrams.
Figure 11.10 summarizes the basic notation for modeling messages on
communication diagrams. Optionally, you may indicate the sequence number
in which the message is sent, indicate an optional return value, or indicate
the method name and the parameters (if any) passed to it. Sequence numbers
should be in the format A.B.C.D to indicate the order in which the messages
where sent. In Fig. 11.9 message 1 is sent to the Seminar object, which in turn
sends messages 1.1 and then 1.2 to the Course object. Message 5 is sent to the
Seminar object, which sends message 5.1 to enrollment, which in turn sends

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 336 DYNAMIC OBJECT MODELING

[sequenceNumber:] methodName(parameters) [: returnValue]

FIGURE 11.10. The basic notation for invoking a message on a communication diagram.

message 5.1.1 to student, and it finally sends message 5.1.1.1 to itself. Notice
how a recursive connection, or a self connection, is required so that student
can do this.
Although Fig. 11.9 applies sequence numbers to the messages, my expe-
rience is if you feel the need to use sequence numbers on communication
diagrams this is a good indication you should be using sequence diagrams in-
stead. The main difference between communication diagrams and sequence
diagrams is that sequence diagrams are good at showing sequential logic but
not that good at giving you a “big picture view” whereas communication
diagrams are the exact opposite.
In Fig. 11.9, you see the Seminar Details user-interface object collaborates
with the seminar object to obtain the information needed to display its infor-
mation. It first invokes the getter method to obtain the name of the seminar. To
fulfill this responsibility, the seminar object then collaborates with the course
object that describes it to obtain the name of the course. In this example I
showed return values for some messages but not others to provide examples
of how to do it. I will either indicate the type of the return value, for example,
string, or the result, such as seminarName. Normally I would not show return
values on this diagram because the messages are named well—my heuristic
is to only model return values when it is not clear what the message returns.
Better yet I try to find a new name for the message (remember that messages
map to operations implemented by your classes).
Another trick I often use is to consolidate trivial messages such as getter
invocations. In Fig. 11.9 I modeled the series of getter method invocations

TIP
You Typically Only Need a Few Models
Any given project team will only require a subset of the models described in this
book. Think of it like this: in your toolbox at home you have a wide array of
screwdrivers, wrenches, pliers, and so on. For any given repair job you will use
only a few of the tools. Different jobs, different tools. You never need all of your
tools at once, but over time you will use them in a variety of manners.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.3 UML State Machine Diagrams 337

to obtain the information needed to display the list of students enrolled in a

seminar as the single message getInfo. I also added a note to the diagram to
make it clear what I was doing, but I typically do not do that. Why is this
important? Because agile developers will only do things that add value, and
defining an exact list of getter invocations would not have added value.
You draw communication diagrams in the same way as you draw sequence
diagrams, the only real difference being that you lay out the notation in a
different manner. To tell you the truth I rarely find the need to create com-
munication diagrams although I have found them useful in situations where
we did not have use cases as the primary requirements artifact. Sequence di-
agrams and use cases seem to go hand in hand because of how easy it is to
model the sequential logic of a use case using a sequence diagram. Commu-
nication diagrams seem to be preferred by people with a “structure bent,”
people that focus on UML class diagrams or class responsibility collaborator
(CRC) cards, because of the similarity of communication diagrams with those
types of artifacts. As always, follow the AM practice apply the right artifact(s)
and use the most appropriate technique for your situation.

11.3 UML STATE MACHINE DIAGRAMS

Objects have both behavior and state or, in other words, they do things and
they know things. Some objects do and know more things, or at least more
complicated things, than other objects. Some objects are incredibly compli-
cated, so complex that developers can have difficulty understanding them.
To understand complex classes better, particularly those that act in different
manners depending on their state, you should develop one or more UML
state machine diagrams, formerly called state chart diagrams in UML 1.x,
describing how their instances work.
UML state machine diagrams depict the various states that an object may
be in and the transitions between those states. In fact, in other modeling
languages, it is common for this type of a diagram to be called a state-transition
diagram or even simply a state diagram. A state represents a stage in the
behavior pattern of an object, and like UML activity diagrams it is possible to
have initial states and final states. An initial state, also called a creation state,
is the one that an object is in when it is first created, whereas a final state
is one in which no transitions lead out of. A transition is a progression from
one state to another and will be triggered by an event that is either internal
or external to the object.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at

338

student enrolled
[seat available]/
addStudent() Open For Enrollment
scheduled open cancelled
Proposed Scheduled
entry/ logSize()
closed
cancelled cancelled student enrolled
[no seat available] /
addToWaitingList()
seat available
Full Closed to Enrollment
seminar split enroll student / closed
addToWaitingList(); entry/ notifyInstructor()
student dropped considerSplit()
[no seat available] student dropped cancelled
[seat available] /
cancelled
enrolFromWaitingList()

FIGURE 11.11. A UML 2 state machine diagram for the Seminar class during registration.

Cambridge Books Online © Cambridge University Press, 2010

 11.3 UML State Machine Diagrams 339

event [guard][/method list]

FIGURE 11.12. The format for transitions labels.

Figure 11.11 presents an example state machine diagram for the Seminar
class during registration. The rounded rectangles represent states: you see
that instances of Seminar can be in the Proposed, Scheduled, Open For Enroll-
ment, Full, and Closed to Enrollment states. An object starts in an initial state,
represented by the closed circle, and can end up in a final state, represented
by the bordered circle. This is the exact same notation used by UML activity
diagrams, a perfect example of the consistency of the UML.
The arrows in Fig. 11.11 represent transitions, progressions from one state
to another. For example, when a seminar is in the Scheduled state, it can be
either opened for enrollment or cancelled. Figure 11.12 depicts the nota-
tion for the labels on transitions. It is mandatory to indicate the event that
causes the transition, such as open or cancelled. Guard, conditions that must
be true for the transition to be triggered, are optionally indicated. The [no seat
available] guard is shown on the student enrolled transition from the Open For
Enrollment to the Closed To Enrollment state. Guards can be described in any
manner, including both free-form text or formal language—when I am white-
boarding I will use free-form text to ensure that it is readable by everyone,
but with a sophisticated CASE tool I would consider using either a program-
ming language such as Java or a modeling language such as object constraint
language (OCL) if the tool has the ability to actually process that information
into something useful (such as executable code). The invocation of methods,
such as addToWaitingList(), can optionally be indicated on transitions. The
order in the listing implying the order in which they are invoked.
States are represented by the values of the attributes of an object. For
example, a seminar is in the Open For Enrollment state when it has been
flagged as open and seats are available to be filled. It is possible to indicate the
invocation of methods within a state; for example, upon entry into the Closed
To Enrollment state the method notifyInstructor() is invoked. The notation used
within is the same as that used on transitions, the only difference being that
the method list is mandatory and the event is optional. For example in the
Full state the operations addToWaitingList() and considerSplit() are invoked
whenever a student is enrolled. Had there been no event indicated those
methods would be invoked continuously (in a loop) whenever the object is

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 340 DYNAMIC OBJECT MODELING

TIP
Agile Designs Are Emergent, They Are Not Defined Up Front
Although you will do some modeling during “cycle 0” (just enough to get your
team going), you do not need to get a fully documented set of models in place
before you may begin coding. Your overall system design will emerge over time,
evolving to fulfill new requirements and take advantage of new technologies as
appropriate.

in that state. I indicate the methods to run during the state when I want to
indicate a method is to be run continuously: perhaps a method that polls
other objects for information or a method that implements the logic of an
important business process. Methods to be invoked when the object enters
the state are indicated by the keyword entry, as you see with both the Open
For Enrollment and Closed To Enrollment states in Fig. 11.11. Methods to be
invoked as the object exits the state are indicated by the keyword exit. The
capability to indicate method invocations when you enter and exit a state is
useful because it enables you to avoid documenting the same method several
times on each of the transitions that enter or exit the state, respectively.
Transitions are the result of the invocation of a method that causes an
important change in state. Understanding that not all method invocations
will result in transitions is important. For example, the invocation of a getter
method likely would not cause a transition because it is not changing the
state of the object (unless lazy initialization is being applied). Furthermore,
Fig. 11.11 indicates an attempt to enroll a student in a full seminar may not
result in the object changing state, unless it is determined that the seminar
should be split, even though the state of the object changes (another student
is added to the waiting list). You can see that transitions are a reflection of
your business rules. For example, you see that you can attempt to enroll a
student in a course only when it is open for enrollment or full, and that a
seminar may be split (presumably into two seminars) when the waiting list is
long enough to justify the split. You can have recursive transitions, also called
self transitions, that start and end in the same state. An example of which is
the student dropped transition when the seminar is full.
For the sake of convention, we say an object is always in one and only one
state, implying transitions are instantaneous. Although we know this is not
completely true (every method is going to take some time to run), this makes
life a lot easier for us to assume transitions take no time to complete.
Because the lifecycle of a seminar is so complex Fig. 11.11 only depicts
part of it. Figure 11.13 depicts the entire lifecycle, with Fig. 11.11 shown as

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.3 UML State Machine Diagrams 341

Enrollment

Open For
Proposed
Enrollment
student dropped
[seminar size > 0]
classes
Closed to Being end Final
Scheduled Full
Enrollment term Taught Exams
started
student dropped closed
cancelled [seminar size = 0]

FIGURE 11.13. The complete Seminar lifecycle.

a substate of the Enrollment state. I could have included all of the details in
Fig. 11.13 but chose not to in order to keep the diagram simple—I prefer to
follow the AM practices depict models simply and model in small increments.
In fact, instead of creating a diagram such as Fig. 11.13 I typically prefer
something more along the lines of the high-level view of Fig. 11.14 with
detailed views such as Fig. 11.11. This approach keeps the diagrams small
and easy to understand.
Figure 11.15 depicts a slightly different take on state machine diagrams;
this time it is much closer to an analysis level diagram because it shows what
is happening to the seminar while it is in this state from the point of view of
the people involved. It is organized into two parallel swim lanes representing
concurrent substates—one from the point of view of the professor teaching
the seminar and the other showing the actions of the teaching assistant re-
sponsible for keeping the seminar material up to date. Concurrent substates
are common with hardware but very uncommon in business classes, hence
the goofy example. Normally I would depict this sort of information using

term classes
started Being end Final
Enrollment
Taught Exams

canceled student dropped closed

[seminar size > 0]

[seminar size = 0]

FIGURE 11.14. A top-level state machine diagram.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 342 DYNAMIC OBJECT MODELING

FIGURE 11.15. The Being Taught state.

either a UML activity diagram or a UML timing diagram (Section 11.4) but I
needed an example to show extra notation.
Figure 11.15 shows several ways to depict transitions. The Break Starts tran-
sition exiting from the Being Taught states is applicable to all of the substates;
you know this because it exits from the superstate instead of an individual
substate. The Work Submitted transition is potentially triggered by several
sources; you know this because it is attached to the outside edge of the super-
state, whereas the source of the Break ends transition is explicitly defined as
the School Break state. The initial transition into this state is the Term Started
transition, indicated through the use of an initial state symbol. I could also
have modeled this state coming from an Enrollment state; either approach is
fair.
The Term Started and Break Ends transitions are first merged, then they lead
to a fork, which in turn leads to one or the other set of concurrent substates.
A history pseudo-state is shown (the circle with the H), indicating that if
Seminar was previously in this state, left it, and the returns that it will go back
to the substate it was originally in. The arrow leaving the history pseudo-state

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.3 UML State Machine Diagrams 343

TIP
State Modeling Often Reveals Potential Error Conditions
Identifying potential error conditions while you are state machine modeling is
common because you are constantly asking “should this transition be allowed
when the object is in this state?” When the answer is yes, you need to add the
transition to your diagram. When the answer is no, you may need to document
this potential issue so your programmers develop the proper error checking code,
so the transition is not allowed to occur.

indicates that the Deliver Course Material substate is the default the very first
time that Seminar enters the Begin Taught superstate.
When drawing a state machine diagram the thing you want to do is to
identify the creation state and whether any final states exist. After you have
done this, ask yourself what other states or stages in the life of an object does
it pass through? You can often find states by looking at the boundary values
of your attributes. For example, when the number of students in a seminar
reaches the maximum, it becomes full. Full is a valid state because different
rules now apply: when a student tries to enroll, he is put on a waiting list and
the seminar is a candidate to be split in two.
Once you have identified as many states as you can, start looking for transi-
tions. For each state, ask yourself how the object can get out of it, if possible.
This will give you a transition. Because all transitions lead from one state
to another, ask yourself what new state the transition leads you to (do not
forget about recursive transitions that lead to the same state). You should also
look at the methods you identified in your class diagram. Some of them will
correspond to a transition in your state diagram.
Although being able to inherit state diagrams would be nice, it is extremely
unlikely this will happen. The definition of inheritance says that although the
subclass is similar to the superclass, it is still different. The behavior of the
subclass is usually different than that of the superclass. This means you need
to reconsider the state diagram when you inherit from a class with one. The
one good thing is many of the states and transitions are reusable. You will
probably find either you add new states and transitions or you will redefine
some.
State machine modeling is a dynamic modeling technique, one that focuses
on identifying the behavior within your system—in this case, behavior specific
to the instances of a single class. My style is to draw one or more state machine
diagrams when a class exhibits different behavior depending on its state. For
example, the Address class is fairly simple, representing data you will display

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 344 DYNAMIC OBJECT MODELING

and manipulate in your system. Seminar objects, on the other hand, are fairly
complex, and therefore it makes sense to create a state machine diagram for
them.
In business applications it seems that a very small proportion of classes,
perhaps 5 percent at most, are complex enough to warrant the creation of
a state machine diagram. However, state machine diagrams are much more
common in real-time systems (Douglass 1999).

11.4 UML TIMING DIAGRAMS

Timing diagrams are one of the new artifacts added to UML 2, although they
have been one of the core diagrams within the hardware design and real-time
communities for decades. They are used to explore the behaviors of one or
more objects throughout a given time period. There are two basic flavors of
timing diagram, the concise notation depicted in Fig. 11.16 and the robust
notation depicted in Fig. 11.17. 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 11.16 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 am 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 11.16. UML timing diagram (concise notation) for the lifecycle of a seminar.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.4 UML Timing Diagrams 345

FIGURE 11.17. UML timing diagram (robust notation) for teaching a seminar.

It is interesting to note the differences between the timing diagram of Fig.

11.16 and the state machine diagram of Fig. 11.13. Several states from the
state machine diagram are encompassed by the Enrolling Students state of
the timing diagram. That is perfectly fine because I am 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 11.17 depicts a timing diagram that explores the details of what
happens while a seminar is being taught. In this jaded example the profes-
sor 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 teach-
ing 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,

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 346 DYNAMIC OBJECT MODELING

TIP
Prove It with Code
Never assume your design works; instead, obtain concrete feedback by writing
code that reflects your design as soon as possible.

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 rea-
son for the change. The arrows between timelines are messages between the
objects.
Several ways to indicate time are shown in Fig. 11.17. 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.
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 do not know of any mainstream modeling
tool oriented towards business application development that supports this
kind of diagram.
In my opinion very few business application developers will find that they
need UML timing diagrams, so I really cannot 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.

11.5 UML INTERACTION OVERVIEW DIAGRAMS

UML interaction overview diagrams are variants on UML activity diagrams,

which overview control flow. Figure 11.18 depicts an interaction overview di-
agram for enrolling in a seminar. The nodes within the diagram are frames in-
stead of the normal activities that you would see on an activity diagram. There

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.5 UML Interaction Overview Diagrams 347

FIGURE 11.18. UML interaction overview diagram for enrolling in a seminar.

are two types of frame shown: interaction frames, which depict any type of
UML interaction diagram (sequence diagram, communication diagram, tim-
ing diagram, interaction overview diagram), or interaction occurrence frames,
which indicate an activity or operation to invoke. There are two interaction
frames in the diagram, one that depicts a sequence diagram for determining
whether a student is eligible to enroll in a seminar and a communication
diagram to determine whether a seat is available in a seminar. These frames
indicate the type of diagram (sd for sequence diagrams, cd for communication
diagrams, td for timing diagrams, and iod for interaction overview diagrams)
and optionally the name of the diagram. The interaction occurrence frames
are of type ref and typically are anonymous as the name of the activity or
operation to be invoked should make it clear what is happening (otherwise
you need to rethink your naming strategy).
The other notation used on the diagram should be familiar to you. Decision
points are shown as diamonds, exactly as on UML activity diagrams. There
should be guards on all of the exiting flows although as you can see I will
forgo labeling some guards when it is obvious what is meant. Remember that
agile models do not need to be perfect, they just need to be good enough, but
just barely! Duration constraints, such as {0..7 msec}, are shown using the

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 348 DYNAMIC OBJECT MODELING

TIP
Continue to Use the Terminology of Your Stakeholders
It was a good idea for your requirements/analysis modeling efforts and it is a
good idea for your design modeling efforts as well.

same notation as on other types of interaction diagrams. The start and end
points use the same notation as initial and end states on UML state machine
diagrams and UML activity diagrams.
Although interaction overview diagrams are an interesting concept I doubt
that they will be used much in practice. Interaction frames are virtually useless
due to a lack of space—the diagrams that you can depict within the frames
will be too small to be of value. My suspicion is that interaction overview
diagrams will be abandoned within the marketplace in favor of UML activity
diagrams because they do not work well on whiteboards and the CASE tool
vendors can simply allow you to use other diagrams to describe the details of
activities. Perhaps I am wrong about this. Time will tell.

11.6 UML COMPOSITE STRUCTURE DIAGRAMS

UML composite structure diagrams are used to explore run-time instan-

ces of interconnected instances collaborating over communications links.
Figure 11.19 depicts a composite structure diagram for enrolling in a seminar.
The dashed oval, Enroll in Seminar, models a collaboration. A collaboration
enables you to model the relevant aspects of a cooperation between instances,
indicating the objects and the roles that they take within the collaboration.
The rectangles model instances of any type of classifier, including classes,
objects, or interfaces. The properties used in the collaboration, such as the
prerequisite seminars that a student has taken in the past, are optionally in-
dicated with the classifier boxes.
An alternative form of this diagram is shown in Fig. 11.20, something I refer
to as a collaboration-style composite structure diagram. I would really like to
refer to this as a collaboration diagram, but my fear is that this name would be
confusing for anyone familiar with UML 1.x’s collaboration diagrams, which
are now called communication diagrams. In this diagram the collaboration
symbol contains a detailed composite structure diagram, showing how the
composite structure diagrams can effectively be nested within one another.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 11.6 UML Composite Structure Diagrams 349

FIGURE 11.19. Composite structure diagram for enrolling in a seminar.

FIGURE 11.20. Collaboration-style composite structure diagram for enrolling in a seminar.

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014
 350 DYNAMIC OBJECT MODELING

It is interesting to note that UML composite structure diagrams are very sim-
ilar to object role model (ORM) diagrams (Chapter 8) in notation. Although
the two diagrams explore similar issues, i.e., structure, they do so in differ-
ent ways. ORM diagrams are very good for explored detailed relationships
between entities whereas the focus of composite structure diagrams is on
exploring collaborations between entities.
To be honest, I do not find composite structure diagrams to be of much
use either. I would much rather use UML sequence diagrams for exploring a
collaboration because the notation is much more robust and because far more
developers understand the notation.

11.7 WHAT YOU HAVE LEARNED

Dynamic object modeling focuses on identifying the behavior and collabo-

rations between objects within your system. It is a critical aspect of object-
oriented design that leads into structural object design described in the next
chapter. You learned that you have several dynamic object modeling options—
UML sequence diagrams, UML communication diagrams, UML state machine
diagrams, UML timing diagrams, UML interaction overview diagrams, and
UML composite structure diagrams—as well as how to create them.

11.8 REVIEW QUESTIONS

1. Develop a state machine diagram for a bank account, based on the infor-
mation in the bank case study in Chapter 1.
2. Using a UML sequence diagram, model the act of successfully transferring
funds from a checking account to a savings account using an automated
teller machine.
3. Model the usage scenario from Question 2 using a UML collaboration
diagram.
4. Model the usage scenario from Question 2 using the detailed form of a
UML timing diagram.
5. Model the usage scenario from Question 2 using a UML composite structure
diagram.
6. Compare and contrast the diagrams of Questions 2 through 5. What are
the advantages and disadvantages of each, and when would you use each?
Why?

Downloaded from https:/www.cambridge.org/core. New York University Libraries, on 20 Jan 2017 at 17:08:24, subject to the Cambridge Core terms of use, available at
Cambridge Books Online © Cambridge University Press, 2010
https:/www.cambridge.org/core/terms. https://doi.org/10.1017/CBO9780511584077.014