Chapter 12

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Object-Oriented Design:
Fundamentals
Chapter 12

Systems Analysis and

Design in a Changing
World 7th Ed

Satzinger, Jackson &

Burd

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
Chapter 10 Outline
 Object-Oriented Design: Bridging from
Analysis to Implementation
 Object-Oriented Architectural Design:
Component Diagram
 Design Classes and the Design Class
Diagram
 Detailed Design with CRC Cards
 Fundamental Detailed Design Principles

Systems Analysis and Design in a Changing World, 6th Edition 3

 Learning Objectives
 Explain the purpose and objectives of object-
oriented design
 Develop UML component diagrams
 Develop design class diagrams
 Use CRC cards to define class responsibilities
and collaborations
 Explain some of the fundamental principles of
object-oriented design

Systems Analysis and Design in a Changing World, 6th Edition 4

Overview
 This chapter and the next focus on designing
software for the new system, at both the
architectural and detailed level design
 Design models are based on the requirements
models learned in Chapters 3, 4, and 5
 For architectural design, the model is shown
as a UML component diagram
 For detailed design, the main models are
design class diagrams and sequence
diagrams
 In this chapter, the CRC Cards technique is
used to design the OO software
Systems Analysis and Design in a Changing World, 6th Edition 5
 Design Activities and Iterations

Systems Analysis and Design in a Changing World, 7th Ed - Chapter 6 ©2016.

6
Cengage Learning. All rights reserved.
Component Diagram
for Architectural Design
 Component diagram –
 A type of design diagram that shows the overall
system architecture and the logical components within
it for how the system will be implemented
 Identifies the logical, reusable, and transportable
system components that define the system
architecture
 The essential element of a component diagram is the
component element with its API.
 Application program interface (API) –
 The set of public methods that are available to the
outside world

Systems Analysis and Design in a Changing World, 6th Edition 8

 Analysis
Models to
Design
Models

Systems Analysis and Design in a Changing World, 7th Ed - Chapter 6 ©2016.

9
Cengage Learning. All rights reserved.
Component Diagram
for Architectural Design

Systems Analysis and Design in a Changing World, 6th Edition 10

Systems Analysis and Design in a Changing World, 6th Edition 11
Recall from Chapter 6: Major
Components of Design

Systems Analysis and Design in a Changing World, 6th Edition 12

OO Design:
The Bridge from Analysis to Design
 OO Design: Process by which a set of detailed OO design
models are built to be used for coding

 Strength of OO is requirements models from Chapters 3, 4, and

5 are extended to design models. No reinventing the wheel

 Design models are created in parallel to actual

coding/implementation with iterative SDLC

 Agile approaches says create models only if they are

necessary. Simple detailed aspects don’t need a design model
before coding

Systems Analysis and Design in a Changing World, 6th Edition 13

 Object-Oriented Program Flow
Three Layer Architecture

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Analysis to Design to
Implementation: Model Flow

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
Detailed Design
Use Case Realization
 Design and Implement Use Case by Use Case
 Sequence Diagram—extended for system sequence
diagram adding a controller and the domain classes
 Design Class Diagram—extended from the domain
model class diagram and updated from sequence
diagram
 Messages to an object become methods of the design class
 Class Definition—written in the chosen code for the
controller and the design classes
 UI Classes—forms or pages are added to handle
user interface between actor and the controller
 Data Access Classes—are added to handle domain
layer requests to get or save data to the database

Systems Analysis and Design in a Changing World, 6th Edition 17

Design Classes in Detailed Design
 Elaborate attributes—visibility, type, properties
 Add methods and complete signatures

Systems Analysis and Design in a Changing World, 6th Edition 18

Detailed Design
Sequence Diagram Example
 Use case Update student name

Systems Analysis and Design in a Changing World, 6th Edition 19

 Introduction to Design Models:
Communication Diagram

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Introduction to Design Models:
Class-Responsibility-Collaboration (CRC)

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Sample
Java
with
Methods

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
Steps of Object-Oriented Design

 Object-oriented design
 The process to identify the classes, their methods
and the messages required for a use case

 Use case driven

 Design is carried out use case by use case

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Steps of Object-
Oriented Design

 Three paths
 Simple use case
use CRC Cards
 Medium use case
use Communication
Diagram
 Complex use case
use Sequence
Diagram

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
Design Class Diagrams
 stereotype a way of categorizing a model element by its
characteristics, indicated by guillemots (<< >>)
 persistent class a class whose objects exist after a
system is shut down (data remembered)
 entity class a design identifier for a problem domain
class (usually persistent)
 boundary class or view class a class that exists on a
system’s automation boundary, such as an input window
form or Web page
 controller class a class that mediates between
boundary classes and entity classes, acting as a
switchboard between the view layer and domain layer
 data access class a class that is used to retrieve data
from and send data to a database

Systems Analysis and Design in a Changing World, 6th Edition 26

 Design Class Stereotypes

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Notation for a Design Class
 Syntax for Name, Attributes, and Methods

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
Notation for Design Classes
 Attributes
 Visibility—indicates (+ or -) whether an attribute can
be accessed directly by another object. Usually
private (-) not public (+)
 Attribute name—Lower case camelback notation
 Type expression—class, string, integer, double, date
 Initial value—if applicable the default value
 Property—if applicable, such as {key}
 Examples:
-accountNo: String {key}
-startingJobCode: integer = 01

Systems Analysis and Design in a Changing World, 6th Edition 29

Notation for Design Classes
 Methods
 Visibility—indicates (+ or -) whether an method can be
invoked by another object. Usually public (+), can be
private if invoked within class like a subroutine
 Method name—Lower case camelback, verb-noun
 Parameters—variables passed to a method
 Return type—the type of the data returned
 Examples:
+setName(fName, lName) : void (void is usually let off)
+getName(): string (what is returned is a string)
-checkValidity(date) : int (assuming int is a returned code)

Systems Analysis and Design in a Changing World, 6th Edition 30

Notation for Design Classes
 Class level method—applies to class rather than
objects of class (aka static method). Underline it.
 +findStudentsAboveHours(hours): Array
 +getNumberOfCustomers(): Integer
 Class level attribute—applies to the class rather
than an object (aka static attribute). Underline it.
 -noOfPhoneSales: int
 Abstract class– class that can’t be instantiated.
 Only for inheritance. Name in Italics.
 Concrete class—class that can be instantiated.

Systems Analysis and Design in a Changing World, 6th Edition 31

Notation for Design Classes
method arguments and return types not shown

Systems Analysis and Design in a Changing World, 6th Edition 32

 First-Cut Design Class Diagram
 Proceed use case by use case, adding to the diagram
 Pick the domain classes that are involved in the use
case (see preconditions and post conditions for ideas)
 Add a controller class to be in charge of the use case
 Determine the initial navigation visibility requirements
using the guidelines and add to diagram
 Elaborate the attributes of each class with visibility and
type
 Note that often the associations and multiplicity are
removed from the design class diagram as in text to
emphasize navigation, but they are often left on
Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12
©2016. Cengage Learning. All rights reserved.
 Start with
Domain
Class
Diagram
RMO Sales
Subsystem

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
Notation for Design Classes
 Navigation Visibility
 The ability of one object to view and interact with another object
 Accomplished by adding an object reference variable to a class.
 Shown as an arrow head on the association line—customer can
find and interact with sale because it has mySale reference
variable

Systems Analysis and Design in a Changing World, 6th Edition 35

Navigation Visibility Guidelines
 One-to-many associations that indicate a
superior/subordinate relationship
 are usually navigated from the superior to the
subordinate
 Mandatory associations, in which objects in one
class can’t exist without objects of another class,
 are usually navigated from the more independent
class to the dependent
 When an object needs information from another
object, a navigation arrow might be required
 Navigation arrows may be bidirectional.
Systems Analysis and Design in a Changing World, 6th Edition 36
 Create
First Cut
Design
Class
Diagram
Use Case
Create
telephone sale
with controller
added

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Steps of Object-
Oriented Design

 Three paths
 Simple use case
use CRC Cards
 Medium use case
use Communication
Diagram
 Complex use case
use Sequence
Diagram

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
Designing With CRC Cards
 CRC Cards—Classes, Responsibilities, Collaboration
Cards
 OO design is about assigning Responsibilities to
Classes for how they Collaborate to accomplish a use
case
 Usually a manual process done in a brainstorming
session
 3 X 5 note cards
 One card per class
 Front has responsibilities and collaborations
 Back has attributes needed

Systems Analysis and Design in a Changing World, 6th Edition 39

 Example of CRC Card

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
CRC Cards Procedure
 Because the process is to design, or realize, a single
use case, start with a set of unused CRC cards. Add a
controller class
 (Controller design pattern).
 Identify a problem domain class that has primary
responsibility for this use case
 that will receive the first message from the use case
controller. For example, a Customer object for new sale.
 Use the first cut design class diagram to identify other
classes that must collaborate with the primary object
class to complete the use case.
 Have use case descriptions and SSDs handy
Systems Analysis and Design in a Changing World, 6th Edition 41
 CRC Cards Procedure (continued)
 Start with the class that gets the first message from the controller. Name
the responsibility and write it on card.

 Now ask what this first class needs to carry out the responsibility. Assign
other classes responsibilities to satisfy each need. Write responsibilities on
those cards.

 Sometimes different designers play the role of each class, acting out the
use case by verbally sending messages to each other demonstrating
responsibilities

 Add collaborators to cards showing which collaborate with which. Add

attributes to back when data is used

 Eventually, user interface classes or even data access classes can be

added Systems Analysis and Design in a Changing World, 6th Edition 42
Use Case Descriptions
 Write a brief description as shown in Chapter 3
for most use cases.

Systems Analysis and Design in a Changing World, 7th edition – Chapter

435
©2016. Cengage Learning. All rights reserved.
Use Case Descriptions
 Write a fully developed use case description for more
complex use cases
 Typical use case description templates include:
 Use case name
 Scenario (if needed)
 Triggering event
 Brief description
 Actors
 Related use cases (<<includes>>)
 Stakeholders
 Preconditions
 Post-conditions
 Flow of activities
 Exception conditions

Systems Analysis and Design in a Changing World, 7th edition – Chapter 5

©2016. Cengage Learning. All rights reserved. 44
Fully
Developed
Use Case
Description

Use case: Create

customer
account

45
Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016.
Cengage Learning. All rights reserved.
 Example: Create customer Account

 First-cut DCD

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Example: Create customer account

 Controller and primary domain class

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Example: Create customer account
 Problem domain classes and user interface
classes

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Example: Create customer account
 Adding data access classes

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Example: Create customer account
 Final DCD with method signatures

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
 Example: Create telephone sale

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
Example: DCD for
Create telephone
sale

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 12

©2016. Cengage Learning. All rights reserved.
Fundamental Design Principles
 Coupling
 A qualitative measure of how closely related classes
are linked (tightly or loosely coupled)
 Two classes are tightly coupled if there are lots of
associations with another class
 Two classes are tightly coupled if there are lots of
messages to another class
 It is best to have classes that are loosely coupled
 If deciding between two alternative designs, choose
the one where overall coupling is less

Systems Analysis and Design in a Changing World, 6th Edition 57

Fundamental Design Principles
 Cohesion
 A qualitative measure of the focus or unity of purpose
within a single class (high or low cohesiveness)
 One class has high cohesiveness if all of its
responsibilities are consistent and make sense for
purpose of the class (a customer carries out
responsibilities that naturally apply to customers)
 One class has low cohesiveness if its responsibilities
are broad or makeshift
 It is best to have classes that are highly cohesive
 If deciding between two alternative designs, choose
the one where overall cohesiveness is high

Systems Analysis and Design in a Changing World, 6th Edition 58

 Cohesion
 Cohesion measures how much a design makes
the design and architectural elements to be
responsible of one and only task/function.

BankAccount BankLoan

+Open() +Grant()
+Close() +Decrease()
+GetBalance():double +GetInstallment():double
+Activate() +Activate()
+GetLoanBalance():doub
+Reactivate()
le
+GetLoanBalance():doub
HighleCohesion?!
High Cohesion?!
 High Cohesion?!

Fundamental Design Principles
 Protection from Variations
 A design principle that states parts of a system
unlikely to change are separated (protected) from
those that will surely change
 Separate user interface forms and pages that are
likely to change from application logic
 Put database connection and SQL logic that is likely to
change in separate classes from application logic
 Use adaptor classes that are likely to change when
interfacing with other systems
 If deciding between two alternative designs, choose
the one where there is protection from variations

Systems Analysis and Design in a Changing World, 6th Edition 60

Fundamental Design Principles
 Indirection
 A design principle that states an intermediate class is
placed between two classes to decouple them but still
link them
 A controller class between UI classes and problem
domain classes is an example
 Supports low coupling
 Indirection is used to support security by directing
messages to an intermediate class as in a firewall
 If deciding between two alternative designs, choose
the one where indirection reduces coupling or
provides greater security

Systems Analysis and Design in a Changing World, 6th Edition 61

Summary
 This chapter focused on designing software that solves
business problems by bridging the gap between analysis and
implementation.
 Architectural design is the first step, and the UML component
diagram is used to model the main components and
application program interfaces (API)
 Detail design of software proceeds use case by use case,
sometimes called “use case driven” and the design of each
use case is called use case realization.
 Detailed design models used are design class diagrams
(DCDs) and sequence diagrams.
 The design class diagram is developed is two steps: The first
cut diagram is based on the domain model class diagram, but
then it is expanded as responsibilities are assigned and
sequence diagrams are developed.

Systems Analysis and Design in a Changing World, 6th Edition 63

Summary (continued)
 Design class diagrams include additional notation because
design classes are now software classes, not just work
concepts.
 Key issues are attribute elaboration and adding methods.
Method signatures include visibility, method name,
arguments, and return types.
 Other key terms are abstract vs. concrete classes, navigation
visibility, and class level attributes and methods,
 CRC Cards technique can be used to design how the classes
collaborate to complete each use case. CRC stands for
Classes, Responsibilities, and Collaborations.
 Sometimes the CRC cards approach is used for the initial
design of a use case that is further developed using
sequence diagrams (as in the next chapter).

Systems Analysis and Design in a Changing World, 6th Edition 64

Summary (continued)
 Once responsibilities are assigned to classes, the design
class diagram is updated by adding methods to classes and
updating navigation visibility.
 Decisions about design options are guided by some
fundamental design principles. Some of these are coupling,
cohesion, protection from variations, indirection, and object
responsibility.

Systems Analysis and Design in a Changing World, 6th Edition 65