11

Chapter 11:
The Object-Oriented Approach to
Design: Use Case Realization

Systems Analysis and Design

in a Changing World
 11
Agenda
 Object-oriented approach to design
 Design class diagrams
 Interaction diagrams
 Sequence diagrams
 Package diagrams
 Three-layer design
 11
Overview
 How to develop detailed object-oriented design models
 Programmers use models to code the system
 Two most important models are design class diagrams
and interaction diagrams
 Design class diagrams extend domain class diagrams
 Interaction diagrams extend system sequence
diagrams
 11
Object-Oriented Design – The Bridge
Between Analysis and Programming
 Bridge between user’s requirements and new
system’s programming
 Programmers use design to write code and test
new system
 Object-Oriented Event-Driven 11
Program Flow

Started with
domain class
diagram

What are the messages

that pass between objects?

Added as we evolve to
design class diagrams
 11
Start the Transition from Domain to Design
Class Diagrams

What are the

differences
between the
domain class
diagram and the
design class
diagram? 6
 11
Design Models with Their
Respective Input Models

Back and forth

and back and
forth and back
and forth…
 11
What did you learn?
 Which two models are most used to do
object-oriented design?
 11
Iterative Process of OO Design
 Create preliminary design class diagrams model
 Develop interaction diagrams for each use case
or scenario (realization of use cases)
 Return to design class diagram
 Develop method names based design of
interaction diagrams
 Update navigation visibility and attributes
 11
Design Classes and
Design Class Diagrams
 Design class diagrams and detailed interaction diagrams
 Use each other as inputs and developed in parallel
 Design decisions are made during development of
interaction diagrams
 Design class diagram is refined

 When developers build design class diagrams, more

classes are added
 11
Standard Stereotypes Found
in Design Models
Within the Problem
Domain Class

Interface between <<entity>>

and <<boundary>> Class

Exists on System
Automation Boundary

Sends data to/from

a database
 11
Internal Symbols Used to
Define a Design Class
 11
Student Class Examples for the Domain
Diagram and the Design Class Diagram
 11
What did you learn?
 List the elements included in a method
signature.
 Give an example of a method signature with
all elements listed correctly. This example
should be from your team project.
 11
Some Fundamental Design Principles
 Encapsulation – each object is self-contained unit that
includes data and methods that access data

 Object reuse – designers often reuse same classes for

windows components

 Information hiding – data associated with object is not

visible to outside world

 Navigation visibility – object is able to view and interact with

another object
 11
Navigation Visibility Between
Customer and Order
 11
Developing the First-Cut
Design Class Diagram
 Extend domain model class diagram:
 Elaborate attributes with type and initial value information
 Add navigation visibility arrows (hu?)
 Detailed design proceeds, use case by use case:
 Interaction diagrams implement navigation
 Navigation arrows are updated to be consistent
 Method signatures are added to each class
 11
RMO Domain Model Class Diagram
 11
First-cut RMO Design Class Diagram
 11
Question?
 Examine the following use case diagram, SSD,
and domain class diagram
 What types of changes will need to be performed
to transform the domain class diagram into a
design class diagram?
Dental System Use Case Diagram 11
 11
SSD for the “Record Dental Procedure”
use case
Dental System Domain Class Diagram 11
 11
Interaction Diagrams – Realizing Use
Case and Defining Methods
 Realization of use case done through interaction diagram
development
 Determine what objects collaborate by sending messages
to each other to carry out use case
 Sequence diagrams and collaboration diagrams represent
results of design decision
 11
What did you learn?
 What is meant by navigation visibility? How
is it shown in UML?
 11
Partial Design Class Diagram for the Look
Up Item Availability Use Case
 11
Object Responsibility
 Objects responsible for system processing
 Knowing about object’s own data and other classes with
which it collaborates to carry out use cases
 Doing activities to assist in execution of use case
 Receive and process messages
 Instantiate, or create, new objects required to complete
use case
 CRC cards – class-responsibility-collaboration
 11
SSD for the Look Up Item Availability
Use Case

Remember, we have
one SSD for each use
case!
It all started with events
from our event table

What objects are

involved in this use
case?
11
 11
Use Case Controller
 System sequence diagram (SSD) shows input messages
from external actors within use case
 Only indicates that messages go to system
 Use case controller classes are designed as collection point
for incoming messages
 Use case controller acts as intermediary between outside
world and internal system
 One Use Case Controller – Deposit
 Multiple Boundary Classes – Teller, ATM, electronic
transfer
 11
First-Cut Sequence Diagram
 Start with elements from SSD
 Replace :System object with use case controller
 Add other objects to be included in use case
 Select input message from the use case
 Add all objects that must collaborate
 Determine other messages to be sent
 Which object is source and destination of each
message?
 11
Objects included in Look Up Item
Availability
Replace :System
Instances of objects (not classes)
with Use Case
Controller that have data we care about

Same message
that was
originally sent
to :System
 11
First-Cut Sequence Diagram for the Look
Up Item Availability Use Case

Activation Lifelines
 11
Class diagram
updated with
method signatures,
one for each
message

Now I can update

the navigation
visibility!

Better use
pseudocode to
document how to
code each method
too!
 11
What did you learn?
 To develop a first-cut sequence diagram, you
should follow three steps. List the three
steps.
 11
Guidelines for Preliminary Sequence
Diagram Development
 Take each input message and determine internal messages
that result from that input
 For that message, determine its objective
 Needed information, class destination, class source, and
objects created as a result
 Identify complete set of classes affected by each input
message
 Select objects from domain class diagram
 Flesh out components for each message
 11
Question?
 Create an interaction diagram from an SSD
 Develop a first-cut sequence diagram, which only
includes the actor and the problem domain
classes.
 What updates would you make to transform the
domain class diagram into a design class
diagram?
SSD for the “Record Dental Procedure” 11
use case
: :Patient :Household :MedProdVisit :MedStaff
RecordDen
talProcedur
eHandler

patentID:=getID()
Address:=getAddress()

updateVerificationMessage:=
recordProcedure (staffID,description)

38
 11
Question?
 Create an interaction diagram from an activity
diagram (next)
 Develop a first-cut sequence diagram, which only
includes the actor and the problem domain
classes.
 What updates would you make to transform the
domain class diagram into a design class
diagram?
Activity Diagram & Domain Class Diagram for 11
the use case “Enter new patient information”

40
 11
Developing a Multilayer Design for
Look up item availability
 First-cut sequence diagram – classes in domain layer +
use case controller
 Add design for user-interface classes – view layer
 Forms added as windows classes to sequence
diagram
 Add design for data access classes – data access layer
with separate classes for database
 11
Look Up Item Availability Use Case with
View Layer and User-Interface Object
Add new user
interface class
 11
Partial Three-Layer Design for
Objects from Data
Look Up Item Availability Access Classes

aC:Cataog and
aP:ProductItem
are specific
instances of
objects
 11
SSD for the Telephone Order Scenario of
the Create New Order Use Case
Start at the top,
work your way to
the bottom,
adding objects,
messages, and
methods as you
go.
These can get
large and
complicated!
 11
Partial Sequence Diagram for the
Telephone Order Scenario
 11
Another Partial Sequence Diagram
for the Telephone Order Scenario
 11
Sequence Diagram for Telephone Order
Scenario of Create New Order Use Case
 11
Developing a Multilayer Design for
the Telephone Order Scenario
 To reduce complexity of diagrams, extend use case
scenario one message at a time
 Add user interface view layer to scenario
 Add single data access class
 Add each message to extend design
 Sequence diagrams can become complicated!
 Completed design provides foundation for programming the
use case
 11
Telephone Order Sequence Diagram for
the startOrder Message
 11
Telephone Order Sequence Diagram for
the addItem Message
 11
Telephone Order Sequence Diagram for
the final messages
 11
Updating the Design Class Diagram
 Design class diagrams developed for each layer
 New classes for domain layer use case controllers
 New classes for view layer and data access layer
 Sequence diagram’s messages used to add methods
 Constructor methods
 Data get and set method
 Use case specific methods
 11
Create New Order

4 Messages sent to Order

 11
Design Class, with Method Signatures,
for the Order class

4 Methods Supported
by Order
 11
Updated Design Class Diagram
for the Domain Layer
 11
Package Diagrams – Structuring
the Major Components
 High-level diagram in UML to associate classes of related
groups
 Identifies major components of a system and
dependencies
 Determines final program partitions for each layer
 View, domain, data access
 Can divide system into subsystem and show nesting
within packages
 11
Partial Design of a Three-Layer Package
Diagram for RMO Dependency Relationship:
(dashed arrows)
NewItemWindows is
dependent on OrderItem

If you change OrderItem

better look at
NeItemWindow

Package Names on Classes Within

Tabs Packages
 11
RMO Subsystem Packages
 11
Review
 Object-oriented approach to design
 Design class diagrams
 Interaction diagrams
 Sequence diagrams
 Collaboration diagrams
 Package diagrams
 Three-layer design