Types of Diagrams

• Structural Diagrams – focus on static aspects of the software system

• Class, Object, Component, Deployment

• Behavioral Diagrams – focus on dynamic aspects of the software

system
• Use-case, Sequence, State Chart, Activity
Structural Diagrams
• Class Diagram – set of classes and their relationships. Describes
interface to the class (set of operations describing services)
• Object Diagram – set of objects (class instances) and their
relationships
• Component Diagram – logical groupings of elements and their
relationships
• Deployment Diagram - set of computational resources (nodes) that
host each component.
Behavioral Diagram
• Use Case Diagram – high-level behaviors of the system, user goals,
external entities: actors
• Sequence Diagram – focus on time ordering of messages
• Collaboration Diagram – focus on structural organization of objects
and messages
• State Chart Diagram – event driven state changes of system
• Activity Diagram – flow of control between activities
 Issue Library item Loan - Sequence Diagram.
Is s u e L o a n

D e s c rip tio n L ib ra ria n B o ro w e r B o o k

Is s u e L o a n sI s u e
L o a n
C h e c k B o ro w e rL o a n C h e c k
S ta ut s L o a n
S ta tu s
C h e c k F in e s O w in g
C h e c k N o o fC u re n t
L o a n s
C h e c k n o .o fO v e rd u e C h e c k if
L o a n s o v e rd u e
fBI o ro w e rL o a n S ta tu s O K
T h e n
Is s u e B o o k to B o ro w e r Is s u e to B o ro w e r
U p d a et B o o k D e ta ils
(B o ro w e Nr o D, a et
D u e )
A d d B o o k to B o ro w e r A d d B o o k to
L is t L o a n L is t
E n d IF
L ib ra ria n B o ro w e r B o o k
 Exercise
Each lecturer has a name, address and telephone
number and is qualified to present one or more modules.
We store the date when the lecturer became qualified to
teach the module
A module has at least one lecturer qualified to teach it but
it may have many 
Each module has a number, title and a date of next
revision
Each module will have several scheduled presentations
Details of the date, duration and location are recorded for
each presentation
Each presentation will be given by only one lecturer but
one lecturer may give many presentations
Draw a class diagram (s) for this problem
 Developing Sequence Diagrams
• Identify the relevant objects involved in the
computation
• Establish the role of each object
• Identify the controller
• Identify the collaborators
• Decide on the messages between objects
 Sequence diagram notation

:Object 1 :Object 2

Actors
Objects
Sequence diagram notation

:Object 1 :Object 2

Lifelines
Identify the existence of the object over time.
Sequence diagram notation

:Object 1 :Object 2

Activations
Indicate when an object is performing an action
Sequence diagram notation

:Object 1 :Object 2

message

Messages
Indicate the communications between objects
Sequence diagram notation

:Object 1 :Object 2

message

message

Sequence
Vertical position signifies sequence – earlier
messages appear nearer the top.
 Sequence Diagram

• Tracks a sequence of events in a scenario

• Identifies all objects involved

Objects
O1 O2 O3 O4 O5 indicates
that the
E1 event
E2 effects the
Events object
E3

E4
 Sequence modelling

For each event, ask “what objects does this involve?”

– Used to identify new classes

– Determines how classes interact

Sequence diagram for Print Invoice use
case
: Print Invoice
Print Invoice - class diagram

Print Invoice From our sequence diagram, we

find our first object!
: Print Invoice : Customer
Record

Get Customer Name

Now we implement the

first step of the scenario
by getting the Print
Invoice control class to
send a message.

And then we need a

recipient of the message.
So we have found another
object
Print Invoice - class diagram

Print Invoice Customer Record

We can see that as the objects communicate we

need a relationship between them.
: Print Invoice : Customer : Invoice
Record

Get Customer Name

Print Customer Name

Moving on to the
next step of the
scenario

We now have a
third object!
 : Print Invoice : Customer : Sales Items : Invoice
Record

Get Customer Name

Print Customer Name

Get Customer Address

Print Customer Address

Get Unbilled Invoicable Items

Print Invoice Lines

Print Total

Print Terms and Conditions

So we continue!
 So what have we done?
• Worked through a Use Case scenario step by step
• Introduced a controller object to drive things
• Sent messages from one object to another
• Found objects to deal with the messages
 What have we got left to do?
• Find operations on objects to support the messages
• Find attributes to support the objects
: Print Invoice : Customer : Sales Items : Invoice
Record

GetName( )

So we work
through the
messages and
apply
operations
: Print Invoice : Customer : Sales Items : Invoice
Record

GetName( )

PrintCustName( )

And so we
continue
: Print Invoice : Customer : Sales Items : Invoice
Record

GetName( )

PrintCustName( )

GetAddress( )

PrintCustAddress( )

GetUnbilledItems( )

PrintLines( )

PrintTotal( )

PrintTermsConditions( )

And all the way through the sequence diagram

A Simpler Example - Sending an email
 Working from a scenario

Sending an email

1. Press “New ” email icon

2. Enter person’s name in “To” section
3. Type subject
4. Type contents
5. Press Send button
6. System looks up email address in address book
7. System submits the email to the email server
 Starting the diagram
• If this is an interactive scenario, we always have an actor driving it, so we put one on
the sequence diagram

: user
 Add objects
The first interaction is with the icon bar, which we can treat as an object

: icon bar

: user
 Add message
The user talks to the icon bar

: icon bar

: user
 Label the communication

: icon bar

: user
click send mail

Remember that actors can only communicate with interface

objects such as screens, menus and icon bars.
The icon bar has some work to do.
It creates an email page.

: icon bar : email page

: user
click send mail create

Now the user can see the email page and use it.
The next three steps are filling in the details on the email page

: icon bar : email page

: user
click send mail create

fill in to box
fill in subject box
fill in contents box
The user then clicks Send

: icon bar : email page

: user
click send mail create

fill in to box
fill in subject box
fill in contents box

send
Now consider how to do the sending
: icon bar : email page : address book

: user
click send mail create

fill in to box
fill in subject box
fill in contents box

send
look up email address

We can choose to get the email page to look up the email

address from an address book object
 The arrow allows information to
return
: icon bar : email page : address book

: user
click send mail create

fill in to box
fill in subject box
fill in contents box

send
look up email address

So we don’t need to put a return arrow with the email address

going back to the email page
We can choose to get the email page to submit the email to the
email server

: icon bar : email page : address book : email server

: user
click send mail create

fill in to box
fill in subject box
fill in contents box

send
look up email address

submit email
And if we think carefully, the email page always closes after the send.

: icon bar : email page : address book : email server

: user
click send mail create

fill in to box
fill in subject box
fill in contents box

send
look up email address

submit email

close
Now we go through and change the messages to operations
on the object

: icon bar : email page : address book : email server

: user
send mail( ) create

fill in to box
fill in subject box
fill in contents box

send
look up email address

submit email

close
And so on, all the way through

: icon bar : email page : address book : email server

: user
send mail( ) create( )

enterTo( )
enterSubject( )
enterContents( )

send( )
getEmailAddress( )

submitEmail( )

close( )
 Developing a Sequence Diagram

Work through a scenario step by step

Make actors communicate with screens, icons, menus
Make the screen actions (etc) trigger actions with objects
Convert the actions to operations
 Sequence Diagrams – why bother?
• Tie use cases and object models together

• Use the sequences in use cases

• Identify objects

• Identify relationships

• Identify operations
 Sequence Diagrams

• Used to model object interactions on a time

axis.
– Dynamic aspects of a system.
– How objects collaborate to realize a use case.

• Distribute use case behavior to classes.

– Starting to look at how the system does something
rather that just what is done.
• For now, high level interactions
– Look at more detailed level later
Why do sequence diagrams?

• Add detail to use cases.

• Specify how objects collaborate.
• Move closer to design.
 Lifelines

Object1

Underline on name
Represents time during
indicates object
which the object exists.
(vs class)

May run entire length of

diagram or may start or end More notation for
within the diagram names is defined in
UML. (We will learn
as needed.)
 Messages

• Interactions are represented by messages sent from

one object to another.
• Long narrow vertical box on lifeline indicates focus
of control.
– When an object is active, either because it is doing something, or
because it has sent a message to another object that is doing
something on its behalf.
– Not always shown.
 Messages

Arrows are labeled with the name of the message, or

stimulus, that they represent.
 Kinds of Messages

UML defines four kinds of

messages:
Synchronous Sender waits for a reply
(Procedural message)

Return
The reply to a synchronous
message
Often not shown
Asynchronous
Sender does not wait for a reply

Flat
Don’t know or don’t care
 Synchronous Messages

• Used when we want to things to be done one at a

time.
• Like procedure calls in program.
• Sender waits for response to message before
doing anything more.
 Sequence Diagram vs Activity Diagram
• When do I use a sequence diagram and
when do I use an activity diagram?
– How do I decide which one is appropriate?

• Ans: First of all, you don’t have to choose.

You can do both.
• Depends on what you want to show.
• Activity diagrams focuses on the sequence
of actions.
– Doesn’t show why an object does something.
• Sequence diagrams show “flow of
information”
(Who says what to whom).
 Class Activity
• Draw a sequence chart for the ATM machine use cases

• Use cases descriptions on next slide.

Elaborated Use Case Diagram for ATM  
ATM System

CheckBalance <<include>>
*

ValidateCustomer
* *

*
<<include>> BankingSystem
WithdrawCash
* *

<<include>>
*
Customer
<<extend>>
* TransferMoney PayBill

CollectUsageStats
* *

BankManager