0% found this document useful (0 votes)
23 views28 pages

Lec-9 Design-Basics

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
23 views28 pages

Lec-9 Design-Basics

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 28

LECTURE 9: Object Oriented Design

Basics
Ivan Marsic
Rutgers University
Topics

 Gluing the Modules from Analysis Stage


– Assigning responsibilities for actions of use-case plans
to modules
 Design Principles
• Expert Doer
• High Cohesion
• Low Coupling
 Business Policies
 Class Diagram

2
System Sequence Diagrams
We already worked with interaction diagrams: System Sequence Diagrams

: System
User Timer
«initiating actor» «offstage actor»
select function(“unlock")

prompt for the key


Time
enter key
verify key

signal: valid key, lock open


open the lock,
turn on the light

start ("duration“)

System Sequence Diagrams represent interactions between the actors


(the system is also an “actor”)
3
Design: Object Interactions
Design
Sequence Diagram

System Sequence Diagram

Controller : Checker : KeyStorage : LockCtrl

User
«initiating actor»
ystem
: System
Timer
«offstage actor»
checkKey()
sk := getNext()
select function(“unlock")

prompt for the key


alt val != null setOpen(true)
enter key
verify key

signal: valid key, lock open


open the lock, [else] val == null : setLit(true)
turn on the light

start ("duration“)

• System Sequence Diagrams represent interactions of external actors


• Module Sequence Diagrams represent interactions of modules inside the system4
Metaphor for Software Design:
“Connecting the Dots” within the System Box
SYSTEM

:InterfacePage :SearchRequest :Controller :PageMaker :DatabaseConn :Archiver :Notifier :InvestigRequest


Resident Database Landlord

We start System Sequence Diagrams (which show only actors and the system as a “black box”)
to design the internal behavior using concept modules from the Domain Model
and modify or introduce new modules, as needed to make the given system function work. 5
Types of Object Responsibilities
 Knowing responsibility: Memorizing data values,
collections, or references to other objects, represented
as attributes
 Doing responsibility: Performing computations, data
processing, control of physical devices, etc.,
represented as methods
 Delegation responsibility: Delegating subtasks to
object’s dependencies,
represented as sending messages (method invocation)

6
Example …

Delegation responsibilities identified for the system function “enter key”:

Responsibility Description
Send message to Key Checker to validate the key entered by the user.

Send message to a DeviceCtrl to disarm the lock device.

Send message to a DeviceCtrl to switch the light bulb on.

Send message to PhotoObserver to report whether daylight is sensed.

Send message to a DeviceCtrl to sound the alarm bell.

7
Assigning Responsibilities:
Design Diagramming

: Controller : Checker : DeviceCtrl

checkKey()

activate( "lock" )
?

(a) Hand-drawn during creation (b) Computer-based UML


specification of the design

 Two purposes of design diagrams:


a) Communication tool, during the creative process  use hand drawings and
take an image by phone camera (don’t waste time on polishing something until you’re feel confident that you
reached a good design)

b) Specification tool for documentation  use UML design tools to produce


presentable and professional-looking diagrams
8
Gluing the Modules
(“Connecting the Dots”)
Starting Points: Domain Model from UC-1 (concept modules):
Symbolizes Symbolizes
“worker”-type “thing”-type
Use Case UC-1: Unlock (plan of action): concept.
«entity»
concept.
«entity»
KeyChecker KeyStorage
1. User enters the key code
2. System verifies that the key is valid «boundary»
KeycodeEntry
«entity»
Key
3. System signals the key validity
4. System controls: «boundary» «control»
(a) LockDevice to disarm the lock StatusDisplay Controller LockDevice
«boundary»
(b) LightSwitch to turn the light on HouseholdDeviceOperator

User LightSwitch
Gluing the Modules by Plan Walkthrough
Starting Points: Domain Model from UC-1 (concept modules):
Symbolizes Symbolizes
“worker”-type “thing”-type
Use Case UC-1: Unlock (plan of action): concept.
«entity»
concept.
«entity»
KeyChecker KeyStorage
1. User enters the key code
2. System verifies that the key is valid «boundary»
KeycodeEntry
«entity»
Key
3. System signals the key validity
4. System controls: «boundary» «control»
(a) LockDevice to disarm the lock StatusDisplay Controller LockDevice
«boundary»
(b) LightSwitch to turn the light on HouseholdDeviceOperator

Scenario Walkthrough: User LightSwitch

for mapping a Use Case plan-of-action to the Domain Model


Q: who handles this data? e:
e s sag (k)
dm ey
Interface objects and Controller sen checkK

return value
Q: who performs the verification? Based on what data?

Key Checker, based on entered key-code and stored valid keys

Design Sequence Diagram


Mapping Actions to Modules
Starting Points: Domain Model from UC-1 (concept modules):
Symbolizes Symbolizes
“worker”-type “thing”-type
Use Case UC-1: Unlock (plan of action): concept.
«entity»
concept.
«entity»
KeyChecker KeyStorage
1. User enters the key code
2. System verifies that the key is valid «boundary»
KeycodeEntry
«entity»
Key
3. System signals the key validity
4. System controls: «boundary» «control»
(a) LockDevice to disarm the lock StatusDisplay Controller LockDevice
«boundary»
(b) LightSwitch to turn the light on HouseholdDeviceOperator

Scenario Walkthrough: User LightSwitch

for mapping a Use Case plan-of-action to the Domain Model


Q: who handles this data?

Interface objects and Controller message: checkKey(k)

Q: who performs the verification? Based on what data? return value

Key Checker, based on entered key-code and stored valid keys message: ???

Q: who signals? Based on what data?


Controller and Interface objects, based on key verification; because they are «boundary»
Q: who signals? Based on what data?
Controller or Key checker ???, based on key verification
Sequence Diagram (in progress)

Q: who performs the verification? Based on what data? return value

Key Checker, based on entered key-code and stored valid keys message: ???

Q: who signals? Based on what data?


Controller and Interface objects, based on key verification; because they are «boundary»
Q: who signals? Based on what data?
Controller or Key checker ???, based on key verification 12
Alternative Designs:

versus

 Which design is better?


 How to evaluate the “goodness” of a design?

13
How Data Travels
Option A:
“expert” (Key Checker) passes the information (key validity) to another object (Controller)
which uses it to perform some work (activate the lock device)

key-code key-code is-valid activation-params

Controller Checker Controller LockCtrl

“expert” on key validity

Option B:
“expert” (Key Checker) directly uses the information (key validity)
to perform some work (activate the lock device)
Advantage:
key-code key-code activation-params
Shorter communication chain
Controller Checker LockCtrl
Drawback:
Extra responsibility for Checker
“expert” on key validity
Characteristics of Good Designs

 Short communication chains between the objects

 Balanced workload across the objects


– divide-and-conquer during analysis
should divide the system into manageablemethod_1()
modules method_1()
method_2()

 Low degree of connectivity (associations) among the method_N()

objects
– A system with “hub” modules
is more prone to failures

15
Some Design Principles
 Expert Doer Principle: module that knows should
communicate information to those that need it
• How to recognize a violation: If a method call passes many arguments

 High Cohesion Principle: module should not take on too


many computation responsibilities
• How to recognize a violation: If a class has many loosely or not-related
attributes and methods
• Single Responsibility Principle (next lecture)

 Low Coupling Principle: module should not delegate


responsibilities in many tiny parts
• How to recognize a violation: many outgoing links
• Better solution: Hierarchical delegation by limiting the number of
dependencies for each delegate and letting the delegates further split the
complex resopnsibilities

There are many more … (next lecture) 16


Design Involves Compromises
 Any nontrivial design is a compromise between the
desired and the possible
 Design principles may contradict each other:
– Shortening the communication chain (expert doer) tends to
concentrate responsibilities to fewer objects (low cohesion)
– Minimizing the number of responsibilities per object (high
cohesion) tends to increase the number of dependencies
(strong coupling)
 It is critical for others to know how the designer resolved
each compromise/tradeoff, so others can evaluate the
reasoning
– document the reasons for choosing the particular tradeoffs
and compromises
– code alone cannot provide this information
• code shows the product but not the process of reasoning
17
Design: Assigning Responsibilities

(a) (b)

 Although the Checker is the first to acquire the information about the key validity, we decide
to assign the responsibility to activate the DeviceCtrl to the Controller
 This is because the Controller would need to know key-validity information anyway—to
inform the user about the outcome of the key validity checking
 In this way, we maintain the Checker focused on its specialty (key validation) and avoid
assigning unrelated responsibilities to it

18
Responsibility-Driven Design
1. Identify the responsibilities
• start with a use case plan-of-action and the domain model
• some may be missed at first and identified during implementation of the design
2. For each responsibility, identify candidate modules or objects to
assign to
– if the choice appears to be unique then move to the next
responsibility
3. Consider the merits and tradeoffs of each alternative by applying the
design principles
– select what you consider the “optimal” choice
4. Document the reasoning process by which you arrived to each
responsibility assignment
– design involves tradeoffs—let others know how you resolved them
– preserve not only the final chosen design but also all the alternatives
you considered and their perceived merits (process, instead of product only!)
19
time to tidy up …
Unlock Use Case
: Controller k : Key : Checker : KeyStorage : DeviceCtrl : PhotoObsrv : Logger

enterKey()
«create»

loop [for all stored keys]


val := checkKey( k )
sk := getNext()

compare(k, sk)

logTransaction( k, val )
«destroy»

alt val == true activate( "lock" )

dl := isDaylight()
Time
opt dl == false activate( "bulb" )

[else] numOfAttempts++

alt numOfAttempts == maxNumOfAttempts


denyMoreAttempts()

activate( "alarm" )

[else]

prompt: "try again"

20
Unlock Seq. Diag. Variation 1
To avoid an impression that the above design is the only one possible...
: Controller k : Key : Checker : KeyStorage : LockCtrl

k := create()

checkKey(k) loop
sk := getNext()

setValid(ok)

controlLock(k)
ok := isValid()

opt ok == true

setOpen(true)

 Sets a Boolean attribute of the Key object: ok = true/false;


 Business logic (IF-THEN rule) relocated from Controller to LockCtrl
 May be useful if Controller and LockCtrl are in different memory spaces and their
communication could be intercepted,
so the Key should be encrypted 21
Unlock Seq. Diag. Variation 2a
: LightCtrl : PhotoSObs

controlLight()
dl := isDaylight()

opt dl == false

setLit(true)

 Instead of the original solution where the Controller, gets involved in the operation of different devices, the
Controller only sends the message to one of a group of objects associated with a device
 Controller contains high-level business logic/policies and should not get involved in device-control details
 Checking whether it is dark and the light is needed should be a responsibility of LightCtrl
 Similarly, if other devices require multi-step control, the Controller should not be involved
– For example, MusicCtrl would find the appropriate playlist and activate the player
– AlarmCtrl will determine the list of who needs to be notified and send text messages

22
Unlock Seq. Diag. Variation 2b
: LightCtrl : PhotoSObs : LightCtrl : PhotoSObs

controlLight() checkIfDaylightAndIfNotThenSetLit()
dl := isDaylight() dl := isDaylight()

opt dl == false opt dl == false

setLit(true) This solution need setLit(true)


separate methods to:
- Turn light ON
- Turn light OFF

 It may seem helpful that checkIfDaylightAndIfNotThenSetLit() is named informatively (reveals the


intention) …
 but the low-level knowledge of operating a particular device (lighting) is encoded in the name of the
method …
 which, in turn, means that low-level knowledge (“mechanism”) is imparted onto the caller
(Controller) which should be concerned with high-level business policies
 Mixing low-level knowledge with high-level knowledge results in rigid and non-reusable designs

23
Summary of Some Design Variations
c
: Controller k : Key : Checker : KeyStorage : DeviceCtrl : PhotoObsrv : Logger
: DeviceCtrl : PhotoSObs
enterKey()
k := create()

loop [for all stored keys]


val := checkKey(k)
sk := getNext()

compare()
activate( "light" )
logTransaction(k, val) dl := isDaylight()
«destroy»

alt val == true activate(“lock”)

opt dl == false
dl := isDaylight()

a opt dl == false activate(“bulb”) setLit(true)

: Controller k : Key [else]


: Checker
numOfTrials++ : KeyStorage : DeviceCtrl
prompt:
"try again"
k := create()
opt numOfTrials == maxNumOfTrials activate(“alarm”)

loop
b
checkKey(k) : DeviceCtrl : PhotoSObs
sk := getNext()

setValid(ok)
checkIfDaylightAndIfNotThenSetLit()
controlLock(k) dl := isDaylight()

ok := isValid()
The caller opt dl == false
opt ok == true
could be
Controller or
setOpen(true) Checker setLit(true)
24
Are We Done w/ UC-1: Unlock ?
 Didn’t check that the user is at the right door
– Missing: Managing access rights
 Didn’t distinguish critical and non-critical functions
– For example, what if logTransaction() call to Logger does not
return, e.g., no access to database (network outage) or disk-
space full ?
– Missing: Independent execution of non-critical functions
 Adding new household devices causes major design changes
 Controller has several unrelated reasons for future changes:
1. Business policies are entangled with authentication mechanisms
2. Device management
 Etc.

 this design will be revisited in future lectures!


Business Policies
policy:

IF key  ValidKeys THEN disarm lock and turn lights on


ELSE
mechanism:
increment failed-attempts-counter
IF failed-attempts-counter equals maximum number allowed
THEN block further attempts and raise alarm

Should be moved into a separate object:


 Make them explicit part of the model
 Separate business policies from impl. Mechanism
See Dependency Inversion Principle (next lecture) 26
Class Diagram
Base Class
Container

Class diagram should be derived by looking-up the sequence diagrams


PhotoSObsrv Key KeyStorage
1..* 1
– code_ : string
+ isDaylight() : boolean – timestamp_ : long + getNext() : Key
– doorLocation_ : string
1 sensor validKeys 1

Controller
# numOfAttemps_ : long
# maxNumOfAttempts_ : long
+ enterKey(k : Key)
– denyMoreAttempts() KeyChecker
1

checker + checkKey(k : Key) : boolean


1 devCtrl – compare(k : Key, sk : Key) : boolean

DeviceCtrl
1 logger
# devStatuses_ : Vector
Class diagram corresponds to the static module
Logger + activate(dev : string) : boolean
+ deactivate(dev :string) : boolean
structure from conceptual analysis, but detailed and
+ logTransaction(k : Key) + getStatus(dev : string) : Object refined based on plan-to-module mapping
27
Traceability Matrix (3)
Mapping: Domain model to Class diagram
Software Classes

«html» interfacePage

DatabaseConnection
SearchRequest
Controller-SS1

Controller-SS2
PhotoSObsrv
KeyChecker
KeyStorage

PageMaker
DeviceCtrl

Logger
Key
Domain Concepts

Controller-SS1 X
StatusDisplay
Key X
KeyStorage X
KeyChecker X
HouseholdDeviceOperator X
IlluminationDetector X
Controller-SS2 X
SearchRequest X
For missing checks,
InterfacePage X
explain whether the
PageMaker X
concept module was
Archiver
DatabaseConnection
discarded or delayed
X
Notifier
until future iterations
InvestigationRequest
28

You might also like