AB

LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Lab: 5

Interaction Diagrams: Sequence

AB
LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

LAB No 5__________________________________________________18/05/2023

1. Objectives:

After completing this lab, Students will be able to;

 Understand integration diagrams and what a sequence diagram is?
 Prepare a sequence diagram
 How to model the creation of an object
 Work with some UML 2.0 additions to sequence diagrams
 Where sequence diagrams fit in the big picture of the UML

2. Corresponding CLO and PLO:

 CLO 1, PLO 3
3. Theory:
Interaction diagrams describe how groups of objects collaborate in some behavior. An
interaction diagram typically captures the behavior of a single use case. Interaction diagrams do
not capture the complete behavior, only typical scenarios.
Analyzing a System’s Behavior:
UML offers two diagrams to model the dynamics of the system: sequence and collaboration
diagrams. These diagrams show the interactions between objects.
Sequence Diagrams:
Sequence diagrams are a graphical way to illustrate a scenario:
 They are called sequence diagrams because they show the sequence of message passing
between objects.
 Another big advantage of these diagrams is that they show when the objects are created
and when they are destructed. They also show whether messages are synchronous or
asynchronous
Creating Sequence Diagrams:
 You must know the scenario you want to model before diagramming sequence diagrams.
 After that specify the classes involved in that scenario.
 List the involved objects in the scenario horizontally on the top of the page.
 Drop a dotted line beneath every object. They are called lifelines.
 The scenario should start by a message pass from the first object.
 You must know how to place the objects so that the sequence is clear.
 You may start the scenario by an actor.
 Timing is represented vertically downward.
 Arrows between life lines represents message passing.
 Horizontal arrows may pass through the lifeline of another object, but must stop at
some other object.
 You may add constraints to these horizontal arrows.
 Objects may send messages to themselves.
 Long, narrow rectangles can be placed over the lifeline of objects to show when the
object is active. These rectangles are called activation lines.
AB
LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

4. Equipment’s:
 Star UML
 Edraw Max
 GUI design Studio
 Balsamiq
5. Procedure:

Working with Sequence Diagrams

The state diagrams are on a single object. They show the changes an object goes through. The
UML enables you to expand your field of view and show how an object interacts with other objects.
In this expanded field of view, you'll include an important dimension—time. The key idea here is
that interactions among objects take place in a specified sequence, and the sequence takes time to go
from beginning to end. When you create a system, you specify the sequence, and you use the UML
sequence diagram to do it.
What Is a Sequence Diagram?
The sequence diagram consists of objects represented in the usual way (as named rectangles
with the name underlined), messages represented as solid-line arrows, and time represented as a
vertical progression.
Objects
The objects are laid out near the top of the diagram from left to right. They're arranged in any
order that simplifies the diagram. Extending downward from each object is a dashed line called the
object's lifeline. Along the lifeline is a narrow rectangle called an activation. The activation
represents an execution of an operation the object carries out. The length of the rectangle signifies
the activation's duration. Duration, and time in general, are represented in a rough, ordinal way. This
means that each dash in a lifeline usually doesn't stand for a specific unit of time but is intended to
give a general sense of duration. Figure 1 shows an object, lifeline, and activation.

Figure 1. Representing an object in a sequence diagram.

Messages
A message that goes from one object to another goes from one object's lifeline to the other
object's lifeline. An object can also send a message to itself—that is, from its lifeline back to its own
lifeline.

One type of message is a call. This is a request from the object sending the message to the
object receiving the message. The request is for the receiver to carry out one of its (the receiver's)
operations. Usually, this entails the sender waiting for the receiver to carry out that operation. Because
the sender waits for the receiver (that is, "synchs up" with the receiver), this message is also referred
to as synchronous.
UML signifies this message type with a filled arrowhead at the end of a solid line. It's typically
the case that a call involves a return message from the receiver, although modelers often omit the
AB
LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

symbol for the return message. The symbol for the return message is an open-stick arrowhead with a
dashed line. Figure 2 shows these symbols.

Figure 2. The UML symbol for a call and for a return.

Many Happy Returns

A few words about that return message symbol. First, it might be a little confusing because it
closely resembles a dependency arrow. Second, as you read more about UML, you might find
differing representations for a return message. Documentation from the UML 1.x era sometimes
shows this symbol with the open-stick arrowhead and sometimes with the same arrowhead as the call.
UML 2.0 specifies the symbol shown in Figure 2, and that's the one I'll use.
Another kind of message is asynchronous. With this one, the sender transfers control to the
receiver and doesn't wait for the operation to complete. The symbol for this message is an open-stick
arrowhead, as Figure 3 shows.

Figure 3. The UML symbol for an asynchronous message.

The Missing Arrowhead

What about that extra UML 1.x arrowhead? That was an open-stick half-arrowhead. (Imagine
the arrowhead in Figure 3 with half the arrowhead missing.) UML 1.x used it to stand for
asynchronous messages. The idea was to have one kind of symbol for an asynchronous message and
another for a transfer-of-control message, but the boundaries among message categories sometimes
became fuzzy. I'll adopt the UML 2.0 categories and work only with the symbols in Figures 2 and 3.

Time
The diagram represents time in the vertical direction: Time starts at the top and progresses
toward the bottom. A message that's closer to the top occurs earlier in time than a message that's
closer to the bottom.
Thus, the sequence diagram is two-dimensional. The left-to-right dimension is the layout of the
objects, and the top-to-bottom dimension shows the passage of time. Figure 4 shows the essential
symbol set of the sequence diagram, with the symbols working together. The objects are laid out
across the top. Each object's lifeline is a dashed line extending downward from the object. A solid line
with an arrowhead connects one lifeline to another and represents a message from one object to
another.
AB
LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Figure 4. The symbols in a sequence diagram.

Cars and Car Keys

You might be familiar with the kind of car key that allows you to remotely lock and unlock a
car. It also lets you open the car's trunk. If you have one of these keys, you know what happens when
you push the "lock" button. The car locks it, and then it blinks its lights and beeps to let you know it's
finished locking its doors.

A Class Diagram
Let's capture all this in a class diagram. Figure 5 shows the relationships among the CarOwner,
Car, and CarKey classes, as well as some other concepts.

Figure 5. The relationships among CarOwner, CarKey, and Car.

The Car processes a message from the key and causes the appropriate behavior to take place.
Notice a couple of things about this diagram. In the CarKey class, note the signature of
getButtonPress(). This operation works with a button name ("lock," "unlock," or "openTrunk"). The
idea is that the Car receives a message from the CarKey, processes that message, and implements the
operation corresponding to the name of the pressed button.
The diagram also shows the two signals BlinkLights and Beep. You model a signal as a class
with the keyword «signal» added. The dependency arrows between Car and each signal show that the
Car sends these signals. Once again, the UML has no symbol for send, so you add the keyword
«send» to the dependency arrow.
AB
LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Note that the CarOwner class shows something you haven't seen before in a class icon—the two
occurrences of the «signal» keyword. These show you that CarOwner is capable of receiving these
signals. The signals don't request the CarOwner to do anything. Because the Car (the sender) isn't
making a request when it sends those signals, it certainly isn't waiting for the CarOwner to do
anything. Hence, the sequence diagram uses the asynchronous message symbol to model signals.

A Sequence Diagram
The class diagram in Figure 5 is a static view of the little world of the CarOwner, CarKey, Car,
and the two signals. A sequence diagram provides a dynamic view. How? By showing the messages
that pass from one of these entities to another. Start by drawing three objects. One object is an
instance of CarOwner, another is an instance of CarKey, and the third is an instance of Car. Lay them
out across the top of the diagram and drop a lifeline from each one, as in Figure 6.

Figure 6. The beginning of a sequence diagram.

Anonymous Objects
As you can see, none of these objects has a specific name (myCar:Car, for example). Next, add
the arrows to model messages that go from lifeline to lifeline, as in Figure 7. The first message (the
one highest in the vertical dimension) is a request from CarOwner to CarKey. The request is for
CarKey to implement its getKeyPress() operation, registering the button the CarOwner has pressed
(generically referred to as b). The stick arrowhead indicates that CarOwner is transferring control to
CarKey.
AB
LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Figure 7. Messages complete the sequence diagram.

CarKey then sends a message to Car, calling on Car to implement its processKeyMessage()
operation, depending on the specified button. After it processes the message from CarKey, Car sends
itself a message to implement the operation that corresponds to the pressed button. Note the
expression in brackets. That's a guard condition It's the UML's way of saying "if." So if the pressed
button was "lock," the Car sends itself a request to carry out the lock() operation. Then Car sends its
two signals to CarOwner. The first message and the signals are examples of

the two usages of the stick arrowhead. This example shows one use of a sequence diagram—
modeling the interactions in a domain defined by a class diagram. The next example shows another
context for applying sequence diagrams.
The Soda Machine
The sequence diagram is useful for modeling the scenarios of a use case. In this example, you'll model
scenarios of the "Buy soda" use case. You'll begin with a class diagram, as you did in the preceding
example. The class diagram will model the entities that make up a soda machine. To keep it simple,
assume three components—a front, a register and a dispenser. Engineers who make a living designing
and building soda machines, of course, have a different idea of the number of components, but these
components will do for this example.
In your model of the soda machine, the front Accepts selections and cash Displays prompts like "Out
of selection" and "Use correct change" Receives change from the register and makes it available to
the customer Returns cash Receives a can of soda from the dispenser and makes it available to the
customer The register Gets the customer's input (that is, the selection and the cash) from the front
Updates its cash reserve Checks for change The dispenser Checks the availability of a selection
Releases a can of soda. Assume the soda machine is an aggregation of these three components.
Figure 8 shows the class diagram.
AB
LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Figure 8. Your model of a soda machine.

Let's model the best-case scenario of the "Buy soda" use case: The customer inserts the correct
change, and the customer's selection is available. The sequence goes like this: The customer inserts
the money into the money slot in the front of the machine and makes a selection.
1. The money travels to the register, which updates itself
2. Because this is the best-case scenario, an availability check reveals the soda is in stock, and the
register has the dispenser release the soda to the front of the machine.
3. Figure 9 shows the sequence diagram that models these steps.

Figure 9. A sequence diagram that models the best-case scenario of the "Buy soda" use case.
This is just one scenario in this use case. In another scenario, the customer's selection might be sold
out. Figure 10 shows a sequence diagram that models the sold-out scenario.
AB
LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Figure 10. A sequence diagram that, models the sold-out scenario of the "Buy soda" use case
 LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Here's another scenario. Suppose the customer does not insert the correct amount of change? Figure
11 shows the sequence diagram for that one.

Figure 11. A sequence diagram for the incorrect-change scenario.

Finally, suppose the customer does not insert the correct change, and the soda machine is out of
change? The sequence diagram for that scenario is in Figure 12.

SE4th FICT BUITEMS

AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Figure 12. Sequence diagram for the incorrect-change-and machine- is-out-of-change scenario
Sequence Diagrams: The Generic Sequence Diagram
So far, you've put just one scenario into a sequence diagram. When you do this, you create an
instance sequence diagram. If you include all of a use case's scenarios when you draw a sequence
diagram, you create a generic sequence diagram. Let's put all our scenarios into one diagram.
We need some way of indicating conditions; one condition necessitates the messages in one scenario,
another condition necessitates others. Recall from the example with cars and car keys that UML
provides the guard condition to indicate if. This is just a bracketed statement for a condition that has
to be in place to follow one path rather than another. For example, to show that an object sends a
message only if the selected soda is sold out, preface that message with [sold out].
The guard conditions provide essentially the same information as the return messages. For example,
[sold out] lets you know that a selection is unavailable, just as the "Sold Out" return message does.
For this reason, you can remove the return messages. Keeping them around would make the diagram
cumbersome. One more idea and you'll be ready to take the plunge into a generic sequence diagram.
You want to be able to show that if you fully follow one scenario's sequence of messages to its
conclusion, the transaction is over, and that the remaining messages are related to other scenarios. To
do this, you preface the final message in each scenario with «transaction over». Figure 13
incorporates these ideas.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Figure 13. A generic sequence diagram for the soda machine.

Follow the diagram from top to bottom. It starts with the customer requesting the Front to accept his
or her cash and selection. Next, the Front asks the Register to get the customer's input. If the cash is
greater than the price of the soda, the Register checks its cash reserve for change. If no change is
available, the Register has the Front return the customer's cash and then has the Front display a
prompt that says "Use Correct Change." The transaction is over. Next on the Register's lifeline,
you're in effect looking at a different scenario. The Register has the Dispenser check for the
availability of the customer's selection.
If it's sold out, the Register asks the Front to display a prompt that says "Sold Out" and then has the
Front return the customer's cash. Once again, the transaction is over. Moving down the Register's
lifeline, you see that if the transaction continues, the Register updates its cash reserve according to
the cash and the price. If the cash is greater than the price, the Register has the Front receive the
change. Then the Register asks the Dispenser to release the selected soda, the Dispenser requests the
Front to receive the soda, and the transaction (happily) is over. Are you getting the idea that behind
every use case lurks one or more sequence diagrams? Combine sequence diagrams. It's called an
Interaction Overview Diagram.
Creating an Object in the Sequence
A few years ago, telecommunications giant Ericsson demonstrated a technology that enables
customers to use their cell phones to buy from soda machines. A commercial during a recent Super
Bowl telecast portrayed this technology in action. How would you model this interaction in a
sequence diagram? What would you have to add? Let's begin once again with a class diagram. Figure
14 is an expansion of Figure 8.
Through a wireless connection, the CellPhone interfaces to the Front. The Front is smarter than
before and now has the ability to process information from the Customer. In this version it acquires
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

an additional capability—the real focus here: It creates a transaction record of the interaction between
the customer and the soda machine. The machine uses this record to charge the customer's credit card
for the soda. Your sequence diagram has to visualize the creation of the transaction record.

Figure 14. Expanding the class diagram from Figure 8 to show a cell phone as an interface to a soda
machine.

On to the sequence diagram. We'll work with the best-case scenario: The customer keys his or her
credit card information into the cell phone and sends it to the Front. The Front processes the
information and displays an "Approved" prompt to the Customer. The Customer keys a selection into
the cell phone, which sends it to the Front. In this version of the soda machine, the Front processes
the information and communicates directly with the Dispenser to check availability and to instruct
the Dispenser to release the soda. The rest of the scenario is just like the original best-case scenario in
the twentieth-century soda machine, except for the creation of the TransactionRecord. Figure 15
presents the sequence diagram. All the objects are across the top, except the TransactionRecord
object. Why? Because it's not one of the objects that exists at the beginning of the sequence. You
show its creation by positioning it in the vertical dimension according to when it's created. Another
aspect of modeling object–creation is the «create» keyword you put on the message sent from the
creator object to the created object. (Because the Register isn't involved in this sequence, it doesn't
appear in the diagram.)
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Figure 15. A sequence diagram that models the best-case scenario of using a cell phone as an
interface to a soda machine.
The Cell Phone: A Universal Communicator?
Several organizations around the world are working on ways to turn that little phone you're holding
into a true Renaissance device. In Estonia, some people already use cell phones to interact with
parking meters. Ericsson employees can use their cell phones to advance slides in PowerPoint
presentations. A British company called Shazam Entertainment has developed technology that
enables you to use your cell phone to automatically retrieve information about a song you're listening
to. How? Just hold up your phone to the radio or stereo speaker! To read more about these projects
and others, see "If Walls Could Talk, Streets Might Join In" in the September 18, 2003 New York
Times. While we're on the subject of object creation, we should also talk about object destruction. To
show an object being destroyed, you place a large, bold X at the bottom of its lifeline, as in Figure 16.
The left-hand part of the figure shows an object destroying itself (perhaps because a certain amount
of time has passed). The right-hand part of the figure shows that an object can instruct another object
to destroy itself. It does this by sending a message whose label is a «destroy» keyword.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Fig 16.An object can destroy itself (left), or it can receive an instruction to be destroyed (right)
Framing a Sequence: Sequence Diagramming in UML 2.0
UML 2.0 adds a useful touch to sequence diagrams. You can now frame a sequence diagram by
surrounding it with a border and adding a compartment in the upper left corner. The compartment
contains information that identifies the diagram. One of the pieces of information is an operator, an
expression that describes the type of diagram inside the frame. For a sequence diagram, the operator
is sd. Figure 17 shows our generic sequence diagram framed in the UML 2.0 style. Along with the
operator, the compartment contains the name of the interaction (BuySoda) the diagram depicts.

Figure 17. Framing a sequence diagram in UML 2.0.

Interaction Occurrences
The framing concept is helpful because you can apply it in a number of ways. Here's an example: If
you're creating instance sequence diagrams for the scenarios in a use case, you'll notice a fair amount
of duplication from diagram to diagram. Framing gives you a quick and easy way to reuse part of
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

one sequence diagram in another. You draw a frame around part of the diagram, label the frame's
compartment, and just insert the frame with a label (but without the messages and lifelines) into the
new diagram. This particular framed part is called an interaction occurrence. Its operator is ref.
Figure 18 shows the frame around part of the best- case scenario. The framed part is the interaction
occurrence that handles the delivery of the soda. Figure 19 shows how to reuse that interaction
occurrence in the incorrect change scenario.

Figure 18. Framing an interaction occurrence in a sequence diagram.

AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Figure 19. Reusing an interaction occurrence.

Combined Interaction Fragments
An interaction occurrence is a special case of an interaction fragment—UML 2.0's generic name for
a piece of a sequence diagram. You can combine these interaction fragments in various ways. The
operator indicates the type of combination. To show a combination, frame the entire set of fragments,
and use a dotted line as a border between adjoining interaction fragments. The two types of
combinations I think will be the most widely used are denoted by the alt operator and by the par
operator.
In the alt combination, each fragment is an alternative and can proceed only under certain
conditions. Guard conditions indicate which fragment can take place. Figure 20 shows this type of
combination in the generic sequence diagram.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Figure 20. In the alt type of combined interaction fragments, each fragment is an alternative and
proceeds only under certain conditions.
In contrast with the ref operator, the idea here is clarity rather than reuse. If you compare Figure 20
with Figure 17, you'll see that the guard conditions in the fragments eliminate the need for some of
the guard conditions on the messages. In my view, this clarifies the generic diagram and makes it
easier to follow.
In the par combination, the combined fragments work in parallel and don't interfere with one
another. For example, suppose your soda machine works extremely efficiently: It returns the
customer’s change and delivers the selection at the same time. This necessitates that several events
happen together. Figure 9
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Figure 21. In the par type of interaction fragment combination, the fragments work in parallel and
don't interfere with one another.

Task 1:
Model a UML sequence diagram of ‘View Grades’ use case of the Grading System. In doing
this we should model three workflows.
 The teacher views the grades for a student.
 The teacher attempts to view the grade for student, but the student doesn’t exist in the system.
 The teacher attempts to view the grade for the student, but the student doesn’t have any grades in the
system.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Task 2:
Draw a UML sequence diagram of online book seller web site.
Scenario:
Online customer can search book catalog, view description of a selected item, add item to cart, do checkout.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Task 3:
Draw a UML sequence diagram of your own project scenario(General or specific) from Lab
2.
Scenario:
[Search for rooms]
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

6. Observations:
In this lab, we learned about the Sequence UML diagram which is widely used for the purpose of
finding out how the different parts of the system interact with each other and communicate with each
other through sending and receiving messages.
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

7. Rubrics:
Absent Student is Student Student Student Student
unable to can has has perfectly
follow the understand followed constructe implemente
provided the instruction d the d a working
instructio provided s to functional/ model/
ns laboratory construct working logic/
properly. instruction the schematic/ circuit/
The s and fundament model/ block
student familiar al block diagram/
can name with the schematic/ diagram/ code and
Demonstratio the lab block code, and successfull
n hardware environme diagram/ have y executed
or nt (Trainer/ code/ successfull the lab
simulation software/ model on y executed objective in
platform, IDE), but the the Realtime or
but unable cannot protoboard program/ in a
to implement / trainer/ run circuit simulation
implemen on the simulation on environmen
t anything platform software. software t and
practically practically platform produced
or on the or on the the desired
software software results
Category Ungrade Very Poor Fair Good Excellent
d Poor
Percentage [0] [1-20] [21-40] [41-60] [61-80] [81-100]
Marks 0.0 0.1 0.2 0.3 0.4 0.5

Date Total Instructor’s Signature

Marks

Report Plagiarize Requirement Observation Appropriate Correctly

not d content s are listed s are computation drawn
submitte presented and recorded s or conclusio
d or experimental along with numerical n with
Laborator incomplet procedure is detailed analysis is exact
y e presented procedure performed results
Reports submissio and
n complete
report in
all
respects
Category Ungrade Very Poor Fair Good Excellent
d Poor
Percentag [0] [1-20] [21-40] [41-60] [61-80] [81-100]
e
AB LAB MANUAL SOFTWARE DESIGN AND ARCHITECTURE

Marks 0.0 0.1 0.2 0.3 0.4 0.5

Date Total Instructor’s Signature

Marks