Sequence Diagrams and

Class Diagrams
slides by Prof. C. Constantinides

Guidelines for contracts

makeNewSale()
System
Use Case:
Process Sale

addLineItem ()
endSale()
makePayment()

Use Case

System
Sequence
Diagram

Operation:
makeNewSale
...
Operation:
addLineItem
...

makeNewSale()
addLineItem(id, quantity)
endSale()
makePayment(cashTendered) Operation:
endSale
...
Operation:
makePayment
...

System
Operations

Contracts

Sequence diagrams
Sequence diagrams illustrate interactions in a
kind of fence format.
Set of all operation contracts defines system
behavior.
We will create an interaction diagram for each
operation contract.
:ClassAInstance

:ClassBInstance

message1()
message2()
message3()
3

Example sequence diagram:

makePayment
:Register

:Sale

makePayment (cashTendered)
makePayment (cashTendered)
create (cashTendered)

:Payment

Illustrating classes and instances

To show an instance of a class, the regular class
box graphic symbol is used, but the name is
underlined. Additionally a class name should be
preceded by a colon.
An instance name can be used to uniquely
identify the instance.
Sale

Class

:Sale

Instance

s1:Sale

Named instance
5

 An object lifeline shows the extend of the life of

an object in the diagram.
Note that newly created objects are placed at
their creation height.
:Register

:Sale

makePayment()
makePayment()
create()

:Payment

Sequence diagrams

:A

:B

message1()
[color=red] calculate()

Example-Alternate Flow
(branching)
:A

:B

:C

message1()
[x<10] calculate()
[x>15] calculate()

Loops and Opt Flow

 Assume we need to create a Payment instance

and associate it with Sale. What class should be
responsible for this?
However, Register may become bloated if it is
assigned more and more system operations.
:Register

:Sale

makePayment()
create()

p:Payment

addPayment(p)
10

 An alternative design delegates the Payment

creation responsibility to Sale, which supports
higher cohesion in Register.
This design supports high cohesion and low
coupling.
:Register

:Sale

makePayment()
makePayment()
create()

:Payment

11

Return Values
Two Accepted ways of expressing return Values.
1. Using syntax returnVar = message(parameter).
2. Using a reply (or return) message at the end of
the activation bar for that method. If this is used
the return value is labeled with a description.

Use Case realizations

System
makeNewSale()
addLineItem(id, quantity)
endSale()
makePayment(cashTendered)
Contract CO1:
makeNewSale
Operation:
makeNewSale ()
Cross References: Use Case Process Sale.
Preconditions:
none.
Postconditions:
A Sale instance s was created. (instance
creation)
s was associated with Register
(association formed)
Attributes of s were initialized

A use-case realization
describes how a use case
is realized in terms of
collaborating objects.
UML interaction diagrams
are used to illustrate use
case realizations.
Recall Process Sale: from
the main scenario we
identified a number of
system events
(operations)
Each system event was
then described by a
contract.

13

Object design: makeNewSale

We work through the postcondition state changes
and design message interactions to satisfy the
requirements.
:Register
makeNewSale()

Register creates a
Sale by Creator.

create()

By Controller.

By Creator, Sale creates

an empty multiobject
which will eventually hold
SalesLineItem instances

:Sale
create()
:SalesLineItem

Implied to take place within the

constructor of Sale instance.

This is NOT a SalesLineItem

Instance but a collection object.
14

Creating design class diagrams

(DCDs)
Once the interaction diagrams have been
completed it is possible to identify the
specification for the software classes and
interfaces.
A class diagram differs from a Domain Model by
showing software entities rather than real-world
concepts.
The UML has notation to define design details in
static structure, or class diagrams.
15

 Typical information in a DCD includes:

Classes, associations and attributes

Interfaces (with operations and constants)
Methods
Attribute type information
Navigability
Dependencies

The DCD depends upon the Domain Model and

interaction diagrams.
The UP defines a Design Model which includes
interaction and class diagrams.
16

SuperclassFoo
or
SuperClassFoo { abstract }

3 common
compartments
1. classifier name
2. attributes
3. operations

an interface
shown with a
keyword

interface
Runnable
run()

- classOrStaticAttribute : Int
+ publicAttribute : String
- privateAttribute
assumedPrivateAttribute
isInitializedAttribute : Bool = true
aCollection : VeggieBurger [ * ]
attributeMayLegallyBeNull : String [0..1]
finalConstantAttribute : Int = 5 { readOnly }
/derivedAttribute
+ classOrStaticMethod()
+ publicMethod()
assumedPublicMethod()
- privateMethod()
# protectedMethod()
~ packageVisibleMethod()
constructor SuperclassFoo( Long )
methodWithParms(parm1 : String, parm2 : Float)
methodReturnsSomething() : VeggieBurger
methodThrowsException() {exception IOException}
abstractMethod()
abstractMethod2() { abstract } // alternate
finalMethod() { leaf } // no override in subclass
synchronizedMethod() { guarded }

officially in UML, the top format is

used to distinguish the package
name from the class name
unofficially, the second alternative
is common

java.awt::Font
or
java.awt.Font
plain : Int = 0 { readOnly }
bold : Int = 1 { readOnly }
name : String
style : Int = 0
...
getFont(name : String) : Font
getName() : String
...

Fruit
dependency

...
...

interface
implementation
and
subclassing

SubclassFoo

PurchaseOrder
1

...
run()
...
- ellipsis means there may be elements, but not shown
- a blank compartment officially means unknown but as a
convention will be used to mean no members

order

...
...

association with
multiplicities

17

Domain model vs. design model

classes
Domain model:
conceptual
perspective

Register

Sale

1 Captures

date: Date
isComplete : Boolean

Sale
Register
Design:
software perspective

date: Date
isComplete : Boolean
getBalance()
endSale()
makeNewSale()
addLineItem()
makePayment()

1 Captures

becomeComplete()
isComplete()
currentSale
makeLineItem()
makePayment()
getBalance()
getTotal()
18

Creating the design class diagram

Three section box

Navigability

Type information
Sale

Register

getBalance()
endSale()
makeNewSale()
addLineItem()
makePayment()

Captures

date: Date
isComplete : Boolean
1

becomeComplete()
isComplete()
makeLineItem()
makePayment()
getBalance()
getTotal()

methods; parameters not specified

19

How to build a class diagram

1.

2.

Identify all the classes participating in the

software solution. Do this by analyzing the
interaction diagrams. Draw them in a class
diagram.
Duplicate the attributes from the associated
concepts inProductCatalog
the DomainProductSpecification
Model.
Register

Payment

quantity

Store
address
phone

Sale
date: Date
isComplete

specification
price
id

amount: Money

SalesLineItem
quantity

20

3.

Add method names by analyzing the interaction

diagrams.

The methods for each class can be identified by

analyzing the interaction diagrams.
Sale

If the message makeLineItem is

sent to an instance of class
Sale, then class Sale must
define a makeLineItem method.

date: Date
isComplete: Boolean
makeLineItem()

:Register

3: makeLineItem(spec, quantity)

:Sale

21

4.

Add type information to the attributes and

methods.

Register

ProductSpecification

ProductCatalog

specification: String
price: Money
id: ItemID

endSale()
addLineItem()
makeNewSale()
makePayment()

getProductSpecification()

Sale

Store
address: Address
phone: PhoneNumber

date: Date
isComplete: Boolean
becomeComplete()
makeLineItem()
makePayment()
getTotal()

SalesLineItem

Payment
amount

quantity: integer
getSubtotal()

22

Method names - multiobjects

1: spec := getProductSpecification(id)

:ProductCatalog

1.1: spec := find(id)

:ProductSpecification

The find() message to

the multiobject should
be interpreted as a
message to the
container/ collection
object.
The find() method is
not part of he
ProductSpecification
class definition.

23

Associations, navigability, and

dependency relationships
Add the associations necessary to support the
required attribute visibility.
Each end of an association is called a role.

Navigability is a property of the role implying

visibility of the source to target class.
Attribute visibility is implied.
Add navigability arrows to the associations to indicate the
direction of attribute visibility where applicable.
Common situations suggesting a need to define an
association with navigability from A to B:
A sends a message to B.
A creates an instance of B.
A needs to maintain a connection to B

Add dependency relationship lines to indicate nonattribute visibility.

24

Illustrating attributes
Register class will probably
have an attribute pointing to a
Sale object.

Navigability arrow indicates

Register objects are connected
unidirectionally to Sale objects.

Sale

Register
1

Captures

endSale()
addLineItem()
makePayment()

date: Date
isComplete : Boolean
makeLineItem()

Absence of navigability arrow

indicates no connection from
Sale to Register.

25

Attributes as association texts vs.

as association types
using the attribute
text notation to
indicate Register has
a reference to one
Sale instance

OBSERVE: this style

visually emphasizes
the connection
between these classes

Sale

Register
currentSale : Sale

...

...

...

Register

Sale
1

...

currentSale

...

...
...

using the association notation to indicate

Register has a reference to one Sale instance

thorough and
unambiguous, but some
people dislike the
possible redundancy

Register
currentSale : Sale
...

Sale
1
currentSale

...
...
26

Example of attributes as
association types
Sale
Register
date: Date
isComplete : Boolean
getBalance()
endSale()
makeNewSale()
addLineItem()
makePayment()

1 Captures

Register has TWO

attributes:
currentSale: Sale
catalog: ProductCatalog

becomeComplete()
isComplete()
currentSale
makeLineItem()
makePayment()
getBalance()
getTotal()

catalog
1

ProductCatalog
addProduct()
getProductSpecification()
27

Collection attributes:
Two ways to illustrate
Sale
SalesLineItem

date: Date
lineItems: SalesLineItem [1..*]
or
lineItems: SalesLineItem [1..*] {ordered}

Sale

SalesLineItem
1..*
lineItems
{ordered, List}
An association end can optionally have
a property string like {ordered, List}

28

Store

Adding navigability and

dependency relationships
1

address : Address
1 phone : PhoneNumber

Uses

ProductSpecification

1
ProductCatalog

Contains

getRegister()
Looks-in

specification : String
price : Money
id: itemID

1
1 addProduct()
getProductSpecification()
1

Houses
1..*

Describes

Illustrates non-attribute visibility

Sale

Register
Captures
1
getBalance()
endSale()
makeNewSale()
addLineItem()
makePayment()
Logs-completed

SalesLineItem

date : Date
isComplete : Boolean
becomeComplete()
isComplete()
makeLineItem()
makePayment()
getBalance()
getTotal()
*

Contains
1

quantity : integer
1..*

getSubtotal()

Payment
amount : Money
Paid-by

29