Software Design

CS 406 Software Engineering I

Fall 2001

Aditya P. Mathur

Last update: October 2, 2001

Organization

Part I: Design principles and process

Part II: OO Design
Part III: Design Patterns
Part IV: Special topics

October 2, 2001 Software Design 2

Learning Objectives
To learn notations for representing a design.

To understand and be able to apply the basic

principles of software design. (GRASP
patterns).
To learn techniques and tools for Object-
Oriented Design.
• Interaction diagrams
• Class diagrams
• State diagrams
October 2, 2001 Software Design 3
 Models during the Design Phase

Object behavior model Class model

Static structure
diagrams
Interaction Diagrams:
Collaboration diagrams
Sequence diagrams
Design state model
Contracts for
State diagrams
methods and operations
for classes

October 2, 2001 Software Design 4

 A collaboration diagram

1: message2()
2: message3()
message1()
:classAinstance :classBinstance

message1() is sent to an instance of class A.

message2() and message3() are sent, in that
order, by an instance of class A to an instance of
class B.
One diagram for each system event.
October 2, 2001 Software Design 5
 A sequence diagram

:classAinstance :classBinstance
message1()

message2()

message3()

Focus of control,
activation box, optional May be used for multiple events.
October 2, 2001 Software Design 6
 Collaboration diagram: makepayment()

direction of message first internal message

makePayment(cashTendered) 1: makePayment(cashTendered)

:POST :Sale

first message 1.1: create(cashTendered)

link line
instance of a class :Payment
Note: Post is Register in the parameter
second edition of Larman.
October 2, 2001 Software Design 7
Making collaboration diagrams

One diagram for each system operation in the current

development cycle, e.g. for makepayment().

If the diagram gets complex, split into smaller

diagrams.

 Design a system of interacting objects to fulfill the tasks....this

is the tough part of design!

October 2, 2001 Software Design 8

Classes and Objects

Sale :Sale s1:Sale

class object or instance named object

October 2, 2001 Software Design 9

Links

msg1()

addPayment(cashTendered)
:Post :Sale

link line

Link illustrates client/server relationship.

October 2, 2001 Software Design 10

Messages

msg1() 1: message1()
2: message2()
3: message3()
:Post :Sale

all messages flow on the same link

October 2, 2001 Software Design 11

Parameters

msg1()

1: addPayment(amount:Money)
:Post :Sale

parameters shown within parentheses;

types may also be shown

October 2, 2001 Software Design 12

Return values

return value type

msg1()

1: tot:=total(): int
:Post :Sale

return value name

October 2, 2001 Software Design 13

Messages to “self” or “this”

msg1()

:Post

1: clear()

October 2, 2001 Software Design 14

Iteration

msg1()

1*: li = nextLineItem: SalesLineItem

:Post :Sale

iteration, no recurrence values

October 2, 2001 Software Design 15

Iteration with recurrence

msg1()

1*: [i:= 1..10] li = nextLineItem: SalesLineItem

:Post :Sale

iteration clause

October 2, 2001 Software Design 16

Iteration clause: Multiple messages

msg1()
{
for i:= 1 to 10
equal iteration clauses {
myB.msg2();
myC.meg3();
msg1() }
}
1*: [i:= 1..10] msg2()
:A :myB: B
2*: [i:= 1..10] msg3()
:myC: C
October 2, 2001 Software Design 17
Creation

new created instance

msg1()

1: create(cashier)
:Post :Sale
<<create>>
1: make(cashier)
create message with optional parameter for
initialization. Note that use of the name
create is a UML convention.

October 2, 2001 Software Design 18

Languages and create

Language Meaning of create()

C++ Automatic allocation, or

new() operator followed
by constructor call.

Java new() operator followed by

a constructor call.

October 2, 2001 Software Design 19

Message sequence numbering

first message not numbered

second
third (nested)
msg1()

1: msg2()
:classA :classB
1.1: msg3()
2.1: msg5()
2: msg4()
:classC
fifth (nested)
fourth
October 2, 2001 Software Design 20
Conditional message

msg1()

1*: [new sale] create()

:Post :Sale

1.1: create()
conditional message with test

:SalesLineItem

October 2, 2001 Software Design 21

 Mutually exclusive conditional messages

Unconditional after 1a and 1b are mutually

either msg2 or msg4 :ClassE exclusive
2: msg6()

msg1() 1a: [test_1] msg2()

:ClassA :ClassB
1b: [not test_1] msg4() 1a.1: msg3()

1b.1: msg5()
:ClassD :ClassC

October 2, 2001 Software Design 22

Collections

sales:Sale

A multiobject or a collection of instances,

e.g. a List of Sales.

October 2, 2001 Software Design 23

Messages to Multiobjects

Message sent to a
Multiobject.
msg1()

1*: s:=size(): int

:Sale :SalesLineItem
*

The two *’s imply iteration over all elements.

October 2, 2001 Software Design 24

Messages to multiobjects and an element [1]

Message sent to an
element.
msg1()

1: el:=create()
:Sale sl:SalesLineItem

2: addElement(el)
:SalesLineItem
Message sent to a
collection.
October 2, 2001 Software Design 25
Design Guidelines

 OO system consists of interacting objects.

 How does one determine the assignment of

responsibilities to various objects?

 There is no unique assignment and hence “good” and “poor”

designs, “beautiful” and “ugly” designs, “efficient” and
“inefficient” designs.

 Design guidelines assist in the derivation of a good

design.
October 2, 2001 Software Design 26
GRASP Patterns

 GRASP:
General Responsibility Assignment Software
Patterns

 These are best considered as design guidelines

and principles. These could also be considered
as “thought patterns” useful in software design.

October 2, 2001 Software Design 27

Guidelines and principles

 We first consider three useful guidelines:

 Expert
 Creator
 Controller
and two widely applicable principles:
 High cohesion
 Low coupling

October 2, 2001 Software Design 28

 POS: Partial Domain Model
Contains Product
Product
1 1…*
Specification
Catalog
Sales description
LineItem price
1 Used-by itemID
quantity *
Store 1 Describes
1..*
Contained-in Stocks *
address Item
1 name 1 *
Sale 1 Houses
date Captured-on *
Started-by Manager
time POS
Paid-by 1 1 1
1 1 1
1
Initiated-by 1
Payment 1 Records-sale-on
Customer Cashier
amount 1
October 2, 2001 Software Design 29
Expert

 Question:
How does one assign responsibilities ?

 Answer:
Assign a responsibility to an information
expert, i.e. to a class that has the information
needed to fulfill that responsibility.

October 2, 2001 Software Design 30

Expert: Example [1]

In POS, some class needs to know

Sale the grand total of a sale.
Who should be responsible for
date
knowing the grand total of a sale ?
time
Contains
1…* Product
Sales Described by
*
Specification
LineItem
description
quantity price
UPC
October 2, 2001 Software Design 31
Expert: Example [2]

 From the model, identify the class that contains

the information needed to obtain the grand
total.
 Information needed to obtain the grand total:
 Knowledge of all SaleItems
 Sum of their subtotals
 Only a Sale object possesses this knowledge.
 Sale being the information expert, we assign this responsibility to Sale.

October 2, 2001 Software Design 32

Partial collaboration diagram [1]

1: t:=getTotal()
:Sale

Sale
date New method added to
the Sale class. The class itself is
time derived from the domain model.
getTotal

October 2, 2001 Software Design 33

Expert: Example [3]

 What information is needed to determine subtotal ?

 We need:
 Quantity of each SalesLineItem and its price.
 Quantity is available with SalesLineItem and price
with ProductSpecification.

 Hence SalesLineItem is assigned the responsibility to

compute the subtotal.
October 2, 2001 Software Design 34
Partial collaboration diagram [2]

1: t:=total() 1*: st=getSubtotal()

:Sale

Sale
*
date
time :SalesLineItem
getTotal() 2.1: p:=getPrice()
SalesLineItem ProductSpecification
:ProductSpecification
quantity description
price
getSubtotal() itemID
getPrice()
October 2, 2001 Software Design 35
Summary: Example [4]

Class Responsibility

Sale Knows sale total

SalesLineItem Knows line item subtotal.

ProductSpecification Knows the price of a product

October 2, 2001 Software Design 36

Expert: Discussion
 Expert guideline used often.

 Fulfillment of a responsibility often requires interaction

amongst several objects (3 in our example). There are
many semi-experts who collaborate in performing a
task.
 Use of the Expert guideline allows us to retain
encapsulation of information.
 It often leads to “lightweight” classes collaborating to fulfill a responsibility.

October 2, 2001 Software Design 37

Expert: Disadvantages
 On some occasions the Expert guideline might not
suggest a desirable solution.
 Example: Who should save Sale in a database ?
 As all the information to be saved is in the Sale
class, it should be responsible for saving the
information.
 This implies that the Sale class must know about
handling databases. Adding database related
methods to sale class will make it in-cohesive.
 It also violates the “separation of concerns” principle.

October 2, 2001 Software Design 38

Expert: Benefits
 Objects use their own information to fulfill tasks,
hence encapsulation is maintained.

 This leads to low coupling.

 Behavior is distributed across cohesive and lightweight

classes.

October 2, 2001 Software Design 39

Creator [1]

 Question:
Who should be responsible for creating an
instance of a class ?

 Answer:
Assign to B the responsibility to create an
object of class A if the following is true:

October 2, 2001 Software Design 40

Creator [2]

 B aggregates objects of type A.

 B contains objects of type A.

 B records instances of objects of type A.

 B closely uses objects of type A.

 B has the data passed to A when A is created.

Implication: B is an expert in the creation of A.

October 2, 2001 Software Design 41
Creator: Example [1]

Who should be responsible

Sale for creating a SalesLineItem ?
date
time
Contains
1…* Product
Sales Described by
*
Specification
LineItem
description
quantity price
itemID
October 2, 2001 Software Design 42
Creator: Example [2]

 Sale contains many SalesLineItem objects.

 This implies that Sale is a good candidate

for creating a SalesLineItem.

 This leads to the following collaboration

diagram.
October 2, 2001 Software Design 43
Sequence diagram for the creation of
SalesLineItem

:POST :Sale

makeLineItem(quantity)
create(quantity)
:SalesLineItem

October 2, 2001 Software Design 44

Partial collaboration diagram

makeLineItem(quantity)
:Sale
1: create(quantity)

Sale :SalesLineItem
date
time
makeLineItem()
total() New method added to
the Sale class.

October 2, 2001 Software Design 45

Creator: Discussion

 Creator guides the assignment of responsibility of

creating objects.

 Creator suggests that the enclosing container or aggregate class

is a good candidate for the creation of the object contained.

October 2, 2001 Software Design 46

Controller [1]

 Question:
Who should be responsible for handling
system events ?
Recall that a system event is a high level event, an external
event, generated by a system actor.
 Answer:
Assign a responsibility to handle a system
event to a controller.

October 2, 2001 Software Design 47

Controller [2]

 A controller is a non-user interface object that

handles system events. Here is a list of
controllers:
Façade controller: Represents the overall
system, device, or business.

Use case controller: Represents an artificial

handler of all events of a use case.

October 2, 2001 Software Design 48

Controller [3]

 window, applet, view, document do not qualify

as controllers. They typically receive system
events and delegate them to a controller.

 System event examples:

•Pressing the “end of sale” button.
•Request Spell Check.
•Request Engine Start.

October 2, 2001 Software Design 49

System operations

System
endSale()
enterItem()
makePayment()

During system behavior analysis, system operations are

assigned to the class System. It does not imply that the class
named System performs these during design. Instead, during
design, a controller class is assigned to perform these
operations.
October 2, 2001 Software Design 50
Controller: Example (1)

Which object should be

responsible for handling the enterItem()
system event message ?

enterItem(upc,quantity)
:???

October 2, 2001 Software Design 51

Controller: Example [1]

enterItem(upc,quantity) Represents the overall

system
:POST
enterItem(upc,quantity)
:Store Represents overall business

enterItem(upc,quantity) Represents a real world

:Cashier actor
Represents an artificial
enterItem(upc,quantity) handler

:BuyItemsHandler
October 2, 2001 Software Design 52
Controller: Example [2]

System POST
endSale() …...
enterItem() endSale()
makePayment() enterItem()
makePayment()
System operations
Allocation of system
discovered during
operations during design
analysis

During design the system operations, identified during

analysis, are assigned to one or more of controller classes.
October 2, 2001 Software Design 53
Controller: Discussion [1]

 Controllers must be chosen to handle incoming events.

 Use the same controller class for events of one use case. This
allows maintenance of the state of a use case.

 Do not assign “too much” responsibility to a controller. A

controller should delegate to other objects work that
needs to be done while coordinating an activity.

October 2, 2001 Software Design 54

Controller: Discussion [2]

 Façade controllers are suitable when there are only a

“few” system events.

 They are also useful when it is not possible to redirect

system events to other controllers as, for example, in a
message processing system.

 Selecting a use case controller leads to a different controller for

each use case. This controller is not a domain object. For example,
for “Buy items” use case one might construct a “BuyItemsHandler”
class.

October 2, 2001 Software Design 55

Controller: Discussion [3]

 When an existing controller becomes too large, one may

choose a use case controller. This will likely help in
maintaining low coupling and high cohesion.

 Corollary: External interfacing objects should not have

the responsibility for handling system events. Instead,
these should be handled in the domain layer objects as
opposed to being handled in application layer objects.

October 2, 2001 Software Design 56

Bloated controller

 Signs of a bloated controller:

 There is only one controller receiving all system events.

 The controller performs all tasks itself without delegating

any task to other objects.

 A controller has many attributes and maintains significant

information about the domain.

 A controller duplicates information found in other objects.

October 2, 2001 Software Design 57

Avoiding bloated controller

 Add more controllers. If necessary, use role-controllers

and use-case controllers.
 An airline reservation system may contain the following
controllers:

Role controllers Use case controllers

ReservationAgent MakeAReservationHandler

Scheduler ManageSchdulesHandler

FareAnalyst ManageFaresHandler
October 2, 2001 Software Design 58
Presentation (Interface) Layer [1]

 Avoid using presentation layer to handle system events.

 Use of domain layer objects to handle system events is

preferred.

 Example:
Assume that POS application has a window that
displays sale information and captures cashier’s
operations. Suppose that a Java applet displays the
window. Let us see how the presentation and domain
layers can be coupled.
October 2, 2001 Software Design 59
Sample GUI for Point of Sale Terminal

Object Store _ x

UPC 1 Quantity 5

Price 2 Description 6

Total 3 Balance 7

Cash 4

8 Enter Item 9 End Sale 10 Make Payment

October 2, 2001 Software Design 60

Sample course of events

Actor System

1 Customer arrives at the

POST checkout with items
to purchase.
2 For each item, the Cashier 3 Adds information on the item
enters the UPC in 1 of to the current sales transaction.
Window 1. The quantity of this Description and price of the item
item is optionally entered in 5. are displayed in 2 and 6 of
Window 1.

October 2, 2001 Software Design 61

 Sample course of events(2)

Actor System

4 Completion of item entry is 5 Computes and displays the

indicated by the Cashier to POST sale total in 3.
by pressing widget 9.

6 .......

October 2, 2001 Software Design 62

 Presentation layer [2]
Object Store _ x
Cashier
UPC Quantity
Cash

Cash Balance
Presses button Enter Item End Sale Make Payment

System event onEnterItem()

message :SaleJFrame
Presentation layer
1: enterItem(upc,quantity)

1.1: makeLineItem(upc,quantity)
Controller
:POST :Sale

October 2, 2001 Software Design Domain layer 63

Presentation layer [3]

 SaleJFrame passes on the enterItem() message to the

domain layer.

 It does not get involved in the processing of this

message.

 Thus, business processing logic is in a domain object,

not in the presentation object.

 Presentation layer objects have lower opportunity for re-

use due to their coupling with the environment.
October 2, 2001 Software Design 64
 Presentation layer: undesirable coupling [4]

Object Store _ x
Cashier
UPC Quantity
Cash

Cash Balance
Presses button Enter Item End Sale Make Payment

onEnterItem()
Business logic embedded in
presentation layer. :SaleJFrame
Presentation layer

1: makeLineItem(upc,quantity)
:Sale

Domain layer
October 2, 2001 Software Design 65
Presentation layer [5]

 Some applications do not have a user interface. They

receive messages from an external system. For
example, LDAP (Light Weight Directory Protocol) might
receive a message from a CGI script.

 In these cases the messages is encoded in a “stream” or

as a CORBA message.

October 2, 2001 Software Design 66

Presentation layer [6]

 In applications with windows, the window might

choose who the controller will be.

 Different windows may collaborate with different

controllers.

 However, in a message handling application, the

Command design pattern is useful.

October 2, 2001 Software Design 67

Low coupling

 How to achieve low dependency and increased reuse?

 A class with high coupling is undesirable because:

• Changes in related classes force local

changes.
• This class is harder to understand in
isolation.
• This class is harder to reuse because its use requires the
inclusion of all classes it is dependent upon.

October 2, 2001 Software Design 68

Low coupling: Example (1)

Consider the following partial conceptual model:

Payment POST Sale

What class should be responsible for

creating an instance of Payment ?

October 2, 2001 Software Design 69

Low coupling: Example [1]

One solution is to let POST create an instance

of Payment and pass a reference this Payment to Sale.
This solution is suggested as POST records a Payment.

makePayment()

1: create()
:POST p:Payment

2: addPayment(p)
:Sale
October 2, 2001 Software Design 70
Low coupling: Example [3]

Another solution is to let Sale create an

instance of Payment.

makePayment()

1: makePayment()
:POST :Sale
1.1: create()

Which of the two solutions is p:Payment

preferable from the point of view
of coupling?
October 2, 2001 Software Design 71
Low coupling: Discussion [1]

 Encourages assigning a responsibility to keep coupling

low.
 Supports design of relatively independent, hence more
reusable, classes.
 Reusable classes have a positive effect on productivity,
i.e. may lead to higher productivity.
 However, the quest for low coupling to achieve
reusability in a future (mythical!) project may lead to
increased project cost.

October 2, 2001 Software Design 72

Low coupling: Discussion [2]

 It is important for the designer to assess the current

level of coupling and attempt to reduce it if it is likely to
cause problems.

 It is important to note that a moderate degree of

coupling between classes is normal. After all an OO
application is a collection of communicating objects!

October 2, 2001 Software Design 73

High cohesion

 Question:
How to keep design complexity manageable.

 Answer:
Assign responsibilities while maintaining high
cohesion.

October 2, 2001 Software Design 74

High cohesion: Example [1]

 Creation of a Payment can be assigned to POST as it

records a payment in real world. This is suggested by
the guidelines associated with Creator.

 This is acceptable. However, if this logic is applied in

several other similar situations, more and more work
is likely to be assigned to one class.

 This might lead to an in-cohesive class.

October 2, 2001 Software Design 75

High cohesion: Example [2]

 For example, if there are 50 system operations, and

POST does some work related to each, the POST will
be a large incohesive class.

 In contrast, a design that lets Sale create Payment,

supports higher cohesion in POST.

 This design supports both high cohesion and low

coupling and hence is preferred over the first one.

October 2, 2001 Software Design 76

Interaction diagrams and system events

 We now consider two use cases and their associated events:

 Buy items
• enterItem
• endSale
• makePayment
 Start up
• startUp

 For each system event we create a collaboration diagram

whose starting message is the system event message.
What should be our controller class?
October 2, 2001 Software Design 77
Choosing the controller class

 Choices:
 POST or a new class such as RetailSystem:
represents the entire system.
 Store: represents the business.
 Cashier: represents a real-world entity.
 BuyItemsHandler: represents an artificial handler.
 We select POST as there are only a few system
operations.

October 2, 2001 Software Design 78

Choosing the controller class

1. Choices:
POST or a new class such as RetailSystem:
represents the entire system.

Store: represents the business.

Cashier: represents a real-world entity.

BuyItemsHandler: represents an artificial handler.

2. We select POST as there are only a few system operations.

October 2, 2001 Software Design 79

System events

enterItem()
:POST
endSale()
We select the POST
:POST class to handle system
events.
makePayment()
:POST
startUp
:POST
October 2, 2001 Software Design 80
Interaction diagrams and contracts

 For each contract work through the responsibilities

and post-conditions, and design message
interactions.

 Example:
The enterItem() system operation requires a Sale to be
created in its contract.

 A collaboration diagram that satisfies this state

change:

October 2, 2001 Software Design 81

Partial collaboration diagram: enterItem()

enterItem(upc,quantity)

1: [new sale] create()

:POST :Sale

Post-condition: If a new sale, Sale was

created (instance creation).

October 2, 2001 Software Design 82

On the value of post-conditions

 Post-conditions are only an initial estimate of what

must be achieved.

 Thus, treat contracts as a starting point for determining

what must be done.

 New post-conditions might arise during design and old

ones might be found redundant.

 Recall...we are encouraging iterative development!

October 2, 2001 Software Design 83

Collaboration diagrams and the conceptual model

 Some objects in collaboration diagrams are drawn

from the conceptual model.

 Responsibility assignment depends to some extent

upon information in the conceptual model.

 New concepts might be discovered during design and

previously identified concepts might be ignored.

October 2, 2001 Software Design 84

Collaboration diagram: enterItem (1)

Name: enterItem
(upc: number, quantity: int)
Responsibilities: Enter sale of an item and
add it to the sale. Display the
item description and price.
Type: System
Cross reference: Use cases: Buy items
Exceptions: If the UPC is not valid, indicate
that it was an error.

October 2, 2001 Software Design 85

Collaboration diagram: enterItem (2)

Pre-condition: UPC is known to the system.

Post-conditions:

 If a new sale, a Sale was created (instance

creation)
 If a new sale, Sale was associated with the POST
(association formed).
 SalesLineItem.quantity was set to quantity (attribute
modification).
 The SalesLineItem was associated with ProductSpecification
based on UPC match (association formed).
October 2, 2001 Software Design 86
Collaboration diagram (1)

enterItem(upc,quantity)
:POST

Collaboration diagram begins by “some object” sending

an enterItem() message to an instance of POST.

October 2, 2001 Software Design 87

Making a new Sale

 Contract post-conditions related to new Sale:

 If a new Sale, a Sale was created (instance creation).
 If a new sale, the new Sale was associated with the
POST (association formed).
 POST can be considered as one that records Thus, POST
is a reasonable choice as a creator of Sale. POST will
then also have a reference to this instance of Sale.
 A container SalesLineItem must be created by Sale.

October 2, 2001 Software Design 88

 Collaboration diagram

enterItem(upc,quantity) 1: [new sale] create()

:POST :Sale

1.1: create()
by controller
by creator
:SalesLineItem

Display of the item description an empty collection that

will eventually hold
and its price is ignored for now.
instances of SalesLineItem
October 2, 2001 Software Design 89
Creating a new SalesLineItem (1)

 More enterItem contract post-conditions:

 A SalesLineItem was created (instance creation).
 The SalesLineItem was associated with the Sale (association
formed).
 SalesLineItem.quantity was set to quantity (attribute
modification)
 The SalesLineItem was associated with a ProductSpecification
(association formed).

October 2, 2001 Software Design 90

Creating a new SalesLineItem (2)

 Sale contains SalesLineItem objects. Hence Sale should

create SalesLineItem.
 SalesLineItem can be associated with Sale by string it in
the container of line items.
 POST must pass the quantity to Sale with the create
message.
 A makeLineItem message is sent to Sale for it to create
a SalesLineItem.

October 2, 2001 Software Design 91

Finding a product specification

 It is necessary to retrieve ProductSpecification based on

the UPC of a SalesLineItem.
 Question:
Who should have the responsibility for knowing a
ProductSpecification ?
 Expert guidelines suggest that ProductCatalog is a good
candidate for this responsibility.

October 2, 2001 Software Design 92

Visibility to a ProductCatalog

 Who should send the specification message to the

ProductCatalog to ask for a ProductSpecification ?
 We assume that POST and ProductCatalog were
instantiated during the StartUp use case and that the
are connected permanently.
 Thus we let POST send the specification message to
ProductCatalog.
 Note that POST knows how to get to ProductCatalog.
We say that POST has “visibility” to ProductCatalog.

October 2, 2001 Software Design 93

 The enterItem() collaboration diagram

1: [new sale] create()

enterItem(upc,qty)
3: makeLineItem(spec,qty)
:POST :Sale

2: spec:=specification(upc)
1.1: create()
3.1 create(spec,qty)
:Product
by expert 3.2: add(s))
Catalog
2.1: spec:=find(upc) :
:SalesLineItem
:
:SalesLineItem

sl:SalesLineItem

October 2, 2001 Software Design 94

Collaboration diagram: endSale (1)

Name: endSale()

Responsibilities: Record the end of sale and

display sale total.
Type: System
Cross reference: Use cases: Buy items
Exceptions: If a sale is not underway,
indicate that it was an error.

October 2, 2001 Software Design 95

Collaboration diagram: endSale (2)

Pre-condition: UPC is known to the system.

Post-conditions:
 Sale.isComplete was set to true (attribute modification).

October 2, 2001 Software Design 96

Choosing the controller class

 Who should be responsible for receiving the

endSale message?
 We continue to use POST as the controller.

October 2, 2001 Software Design 97

Setting the Sale.isComplete

 Who should be responsible for ensuring the

post-condition?
 As Sale knows and maintains the isComplete
attribute, it should have the responsibility of
setting isComplete.

October 2, 2001 Software Design 98

Collaboration diagram: endSale()

endSale() 1: saleComplete()

:POST :Sale

by controller
by expert

October 2, 2001 Software Design 99

Display of information

 One responsibility in the endSale contract is that the

sale total must be displayed.
 Do not use the domain layer objects to communicate
with windows or presentation layer objects.
 Use the Observer pattern.
 Note that Sale must know the total before it can be
displayed!!

October 2, 2001 Software Design 100

Computing the sale total-Review

 Who should be responsible form computing the sale total?

Obviously… Sale as it is the expert !
 What information is required to compute the total ?
 Sub-totals of all SalesLineItem.
 Who should be responsible for computing the sub-totals?
Obviously… SalesLineItem as it is the expert in this case.
 Who has the price for each SalesLineItem?…
ProductSpecification. Hence SalesLineItem must
communicate with ProductSpecification to obtain the price.

October 2, 2001 Software Design 101

The Sale total collaboration diagram

by expert
tot:=total() 2: st:=subtotal()
:Sale :sli:SalesLineItem

1*: [for each] sli:=next())

by expert 2.1: pr=price()

Sale--total() :
{ :SalesLineItem
total:=0;
for each SalesLineItem.sli
tot:=tot+sli.subtotal(); prodSpec: Product
return tot; specification
}
October 2, 2001 Software Design 102
Collaboration diagram: makePayment (1)

Name: makePayment(amount:float)

Responsibilities: Record the payment, compute

balance, and print a receipt.

Type: System
Cross reference: Use cases: Buy items
Exceptions: If a sale is not complete,
indicate an error.

October 2, 2001 Software Design 103

Collaboration diagram: makePayment (2)

Pre-condition: None.
Post-conditions:
 A Payment was created (instance creation)
 Payment.tendered is set to amount (attribute modification).
 The Payment was associated with the Sale (relationship formed).
 The Sale was associated with the Store to add it to the historical
log of completed sales (relationship formed).

October 2, 2001 Software Design 104

Choosing the controller class

 Who should be responsible for receiving the

endSale message?
 We continue to use POST as the controller.

October 2, 2001 Software Design 105

Creating Payment

 Who should be responsible for creating an

instance of Payment ?
 There are two candidates:
 POST
 Sale
 Selecting Sale lightens the workload of Payment.
 Also POST does not need to know about
Payment which leads to lower coupling in
POST.

October 2, 2001 Software Design 106

The makePayment collaboration diagram

by Creator, low coupling

makePayment(cashTendered)
1: makePayment(cashTendered)
:POST :Sale

by controller 1.1create(cashTendered)

:Payment

October 2, 2001 Software Design 107

Balance computation collaboration diagram

We have ignored the

display of balance.

bal:=balance() 1: amt:=amount()
:Sale :Payment

Sale is responsible for knowing the

2 t=total() balance. It needs visibility into
Payment to ask for cash tendered. As
Sale created Payment it has visibility
into it.
October 2, 2001 Software Design 108
Logging the Sale (1)

 Who should be responsible for knowing all the

logged sales and doing the logging ?
 There are two candidates:
 Store
 SalesLedger (new idea from basic accounting!)
 As the design grows Store will become
incohesive, hence SalesLedger seems to be a
good idea.

October 2, 2001 Software Design 109

Logging the Sale (2)

 Consider the following post-condition:

 The Sale was associated with the Store to add it to the historical
log of completed sales.
 This post-condition needs to change if we decide to use
SalesLedger to log the sale.
 If we decide to use SalesLedger than contracts need to
be altered to avoid design divergence.

October 2, 2001 Software Design 110

The logging collaboration diagram

makePayment(cashTendered)
1: makePayment(cashTendered)
:POST s:Sale

2:addSale(s)
by expert 1.1create(cashTendered)

:Store
:Payment
2.1:add(s)
:
completedSales:Sale
October 2, 2001 Software Design 111
Collaboration diagram: startUp() (1)

 Most systems have a StartUp() use case.

 It is recommended that the collaboration
diagram for startUp be taken up towards the
end.
 startUp() operation is often dependent on the
programming language and the operating
system used.
 A common approach is to create an initial
domain object.
October 2, 2001 Software Design 112
 Collaboration diagram: startUp() (2)

 In the initialization method of this initial object, create other

problem domain objects.
public class POSTApplet extends Applet
Here, Store is the {
initial domain object. public void init ()
It creates other {
domain objects.
post = store.getPOST();
}
private Store store = new Store();
private POST post;
private Sale sale;
}
October 2, 2001 Software Design 113
Collaboration diagram: startUp() (3)

Name: startUp()

Responsibilities: Initialize the system

Type: System
Post-conditions:
 Store, POST, ProductCatalog, and ProductSpecifications
created (instance creation).
 ProductCatalog associated with ProductSpecifications

October 2, 2001 Software Design 114

Collaboration diagram: startUp() (4)

 Post-conditions:
 Store, POST, ProductCatalog, and
ProductSpecifications created (instance creation).
 ProductCatalog associated with ProductSpecifications
 Store associated with POST (association formed).
 POST associated with ProductCatalog (association
formed).

October 2, 2001 Software Design 115

StartUp collaboration diagram (5)

Reference to the product

catalog passed to POST.

create() 2: create(pc)
:Store :POST

1.1: create()
1:create()
by creator 1.2.2*: add(ps)
ProductSpecification
ProductSpecification
pc:ProductCatalog

1.2.1*: create(upc,price,description)
1.1: loadProdSpec ps:productSpecification
October 2, 2001 Software Design 116
Connecting presentation and domain layers(1)

1: create()
2: p=getPOST():POST
create()
:POSTApplet store: Store

First the applet creates an instance of

Store. Store in turn creates an instance
of POST. Then the applet requests Store for
a reference to the POST instance.The applet
can now send messages directly to POST as
in the next diagram.
October 2, 2001 Software Design 117
 Connecting Presentation layer to the domain layer (2)

Object Store _ x
Cashier
UPC Quantity
Cash

Cash Balance
Presses button Enter Item End Sale Make Payment

onEnterItem()
Presentation layer
:PostApplet

1:enterItem(upc,qty)
Domain layer
:POST

October 2, 2001 Software Design 118

 Connecting Presentation layer to the domain layer (3)

Object Store _ x
Cashier
UPC Quantity
Cash

Cash Balance
Presses button Enter Item End Sale Make Payment

onEnterItem()
Presentation layer 3: t:=total(): float
:PostApplet

1:enterItem(upc,qty)
2: [no sale] sale:=getSale():Sale
Domain layer
post:POST sale:Sale

October 2, 2001 Software Design 119

Class notation

A class diagram exhibits classes and their

associations used in an application.

ClassName Contrast this with a conceptual model which

shows domain concepts and their associations.
attributes
methods

A class

October 2, 2001 Software Design 120

CRC cards

 CRC: Class-responsibility-collaboration cards

 Instead of using diagrams to show class
responsibilities and collaboration, CRC cards are
suggested.
 These are index cards and one for each class.
 In a team, each person plays the role of one or
more classes and holds the corresponding
card(s).
 Helpful in group design efforts.
October 2, 2001 Software Design 121
CRC cards
class name

Responsibility Order Collaboration

Check if item in stock Order line item

Determine price Order line item

Check for valid payment Customer

Dispatch to delivery address Database interface

October 2, 2001 Software Design 122

Summary

 What did we learn?

 Design process (in part)

 Collaboration diagrams (notation)

 Design principles and guidelines

 Creation of collaboration diagrams using design principles and

guidelines

October 2, 2001 Software Design 123