Embed Size (px)
Citation preview
Copyright 1998
1
How to Conduct an Object-Oriented
Design Audit
Rebecca Wirfs-BrockWirfs-Brock Associates
Copyright 1998
2
Topics
When?Gathering, understanding, and
reviewingVerifying, recommending, and
reporting
Copyright 1998
3
SystemDescription Exploratory
Design
Refinement
Implementation
Planning
Deployment
Testing
Development Time
Effo
rt
Change CasesArchitecture
Application Hot Spots
When to Audit?Milestone Milestone Milestone
Copyright 1998
4
Informal Development Methods
Highly Responsive
mistakes easily fixed
new design ideas rapidly incorporated
Use Analysis and Design Methods and Techniques
Formal Methodstext book methods must be customized
Teams with Specialists
Frameworks impose consistency
Strongly influenced by Technical Architecture Design
Project Characteristics and
Design Audit Strategies
Small Medium Large
?
Copyright 1998
5
Use Cases
ConversationsCRC Cards
Class Hierarchies
System Architecture
Window Specs
Navigation Map
Transient Persistent
Collaboration Diagrams Sequence Diagrams
Change Cases
Context Diagrams
Contracts
Signatures
Candidate ObjectsAlgorithms
Hot Spots
Artifact Lifetimes
Copyright 1998
6
data
usagecost
code reuse
Reporting
suitableimplementable
quality
suggested improvementsvalid architecture
Copyright 1998
7
Precision, Accuracy, Scale, Quality
Precision- how much you care to say
Accuracy- how correct you are when you say it
Scale- how many things are hiding below what you are viewing
Quality- how well is the design suited to the job
Copyright 1998
8
Getting a Big PictureLower the precision, think more abstractly
characterize and stereotype objects, subsystems and interactions
Select items for relevanceonly look at domain objectsreview classes within an inheritance hierarchy or
compositionexamine uses cases that illustrate the core architecture
Bundle related things togetherSubsystems--- classes supporting a common functionClass categories--- classes with common behavior
Copyright 1998
9
Characterizing Objects and Interactions
Auditing the Boeing Microbrewery Design Case
Study“The Object/Oriented Brewery: A Comparison of Two Object-Oriented Development Methods,” R. Sharble, S. Cohen, ACM Sigsoft, vol. 18, no. 2
“The Object-Oriented Brewery: A Comparison of Two Object-Oriented Methods,”R. Sharble and S. Cohen, Boeing Technical Report BCS-G4059
Copyright 1998
10
ModelingWhat are the key concepts of this domain?What roles do they play?How can we characterize them?
EngineeringIs it well-behaved?Is it scaleable?
variables
operations
The Object
Copyright 1998
11
StereotypingQuickly Assessing Object Roles
Controllers: Manage work
Structurers: Maintain relationsbetween objects
Service-providers: Perform operations
Info-holders: Maintain changeable informationInfo-providers: Answer questions
Coordinators: Delegate work to others
Interfacers: Translateinformation and actions
Copyright 1998
12
Using a Consistent Control Style
Location of control within an architecture
Style of control
Copyright 1998
13
LayersInteracting with external events and
information
Control
Presentation
BusinessServices
TechnicalServices
User Interfacers
Controllers &Coordinators
Information-Holders& Service-Providers
Data and DeviceInterfacers
Utilities
Copyright 1998
14
Characteristics of Delegated Control
Coordinators know about fewer objects than dominating controllers
Objects both know and do things---blends of stereotypes
Higher level communications between objects
Benefits:Changes typically localized and simplerEasier to divide detailed design work
Copyright 1998
15
Characteristics of Centralized Control
Controllers can have extremely complex control logic
Controllers surrounded by simple information holders and service providers
Simple objects tend to have low-level, non-abstract interfaces
Drawback:Changes can ripple among controllingand controlled objects
Copyright 1998
16
Contrasting the Two Brewery Designs
Data-Driven Responsibility-Driven
centralized control delegated control
controllers coordinators
inherited attributes inherited behavior
many low-levelmessages
fewer, higher-levelmessages
lots of simplisticinformation holders
a few smart objects thatblend stereotypes
Copyright 1998
17
Transfer a Batch
Data-Driven Design Responsibility-Driven Design
Copyright 1998
18
Data-Driven Batch Transfer Design
ScheduledScheduledTransferTransfer
Location ofLocation ofAlgorithmAlgorithm
Location of DataLocation of Data
ContainerContainer
InterconnectInterconnect
In ProcessIn ProcessBatchBatch
ValveValveVatVat
PipePipePumpPump
Copyright 1998
19
Responsibility-Driven Batch Transfer
Design
Location ofLocation ofAlgorithmAlgorithm
Location of DataLocation of Data
TransferTransferOrderOrder
VatVat
PumpPump
ValveValve
BatchBatch
ManifoldManifold
Copyright 1998
20
Two Contrasting Classes
ContainerPurpose: An enclosed
volume that is intended to hold liquid.
Responsibilities:
knows whether clean, dirty or in use
knows distance
knows selected valve
ManifoldPurpose: A container for beer
that has multiple connections to others via valves.
Responsibilities:
knows whether clean, dirty or in use
determines distance
manages paths between manifolds
manages connections
Copyright 1998
21
Two Versions of ValveValve ValvePurpose: A mechanical device Purpose: A connection
that is used to connect or separate between two manifolds
two volumes
Responsibilities: Responsibilities:
know status (open/closed) know status (open/closed)
connect two manifolds
know manifolds
If valves knew their connections, manifolds could collaborate with them to connect and disconnect paths.
Copyright 1998
22
Responsibility-Driven Design
Delegated Control
Copyright 1998
23
Data-Driven DesignCentralized Control
Copyright 1998
24
Key Audit ActivitiesVerify application architectureAssess clarity and consistencyImprove key interactionsExamine use of inheritance and
compositionSuggest changes and behavior
refactorings that improve usability, maintainability, and extensibility
Copyright 1998
25C
OR
BA
NameServer
DomainServer
LegacyServer
ApplicationServer
WebServer
WWWBrowser
WWWBrowser
Bank AgentApplication
Bank AgentApplication
CGICORBA
CO
RBA
CORBA
Inte
rnet
Inte
rnet
CORBA
CORBA
CORBA
Validating an Architecture
Reviewing Communications and Control Style of a distributed Internet Banking Application
Copyright 1998
26
DomainServer
LegacyServer
ApplicationServer
WebServer
WWWBrowser
Bank AgentApplicationInternet
Control
Presentation
BusinessServices
TechnicalServices
Utilities BAF
4-Layer
Mapping 4 Layers to the Virtual ATM
Copyright 1998
27
VATM HierarchiesBAFSession (first cut)
BafSession
BafApplicationSession BafDomainSession BafLegacySession BafDatabaseSession
Knows statusManages resourcesManages a result cacheProvide services
Maintains legacy connectionHandles legacy transaction requests
Knows database connectionStores and retrieves persistent objects
Knows userLogs in userManages legacy and db connectionsMaintains user session historyTimes session
Knows userKnows application stateKnows domain sessionControls application
Copyright 1998
28
RecommendationLimit visibility of domain objects to the
domain serverMinimize synchronization complexity
between sessions on multiple processorsMinimize domain and application server
coupling
Initiate service requests on the application server
Process requests on the domain server
Provide request results that can be queried
Copyright 1998
29
VATM HierarchiesBAFSession (second cut)
BafSession
BafApplicationSession BafDomainSession
Knows userKnows application stateKnows domain sessionCoordinate user requests
Knows userLogs in userManages legacy/db connectionsMaintains user session historyTimes sessionMake PaymentTransfer FundsGet Account Summary
.
.
Copyright 1998
30
VATM Object Collaborations
Login Use Case
Copyright 1998
31
VATM Hierarchies Refactoring to Reduce Class
Complexity
GdfSession
BafDatabaseSession
BafApplication Session
Baf DomainSession BafLegacySession
GdfBrokeredSessionKnows who does whatForwards messages
Knows statusManages resourcesManages a result cacheProvide services
Copyright 1998
32
VATM Compositions Minimize Database Design Changes
11..*
1
BafCustomerUser
1..*
11
BafUserAccount
1
1..* 1..*
1
BafCustomer
11..*
1BafAccount
11
1..*
1
1BafLegacyAccount
1 1
Copyright 1998
33
Object Design Guidelines
Favor composition over inheritanceFactor behavior into supporting methodsFavor simplicity
From simple to complex
parameterize a method
simple conditional checking and decisions within a method
classify variations with inheritance
dynamic interpretation of information
Copyright 1998
34
Fixing the Data-Driven Design
Removing Central Responsibilities
Copyright 1998
35
Improve Encapsulation
Approach #1Delegate creation of Bottled
Batch to In Process Batch
Approach #2 Collapse 2 information
holders into 1
In Process Batch
Batch
Bottled Batch sizerecipe IDbatch IDdate made: Datedate bottled: Datebottled: BooleaninProcess: Boolean
sizerecipe IDbatch IDdate made: Date
sizerecipe IDbatch IDdate bottled: Date
Copyright 1998
36
Managing Information Abstraction
Reviewing the Presentation Layer for a Customer Support
ApplicationPresentation Business Logic Database
CICS SQL
COBOL DB/2Smalltalk
Copyright 1998
37
Raise the Abstraction Level
“… instead of using a two element array to hold the old and new value [of a display field], create a class named VersionedObject.”
Array VersionedObject
oldValuenewValue
Copyright 1998
38
Whole ValueRaise the abstraction level of a
data type
WholeValue
dataunitOfMeasure
printOn:
asThisasThat
:
Week
3'Week(s)'
printOn:
asMonthsasDays
Example
Copyright 1998
39
Improve Maintenance by Compacting
ClassesMake smarter information holders
… we could eliminate subclasses… if a WorkObject adds responsibilities for knowing whether it should open a view or a dialog, and which view or dialog was appropriate
Remove weak classes from inheritance hierarchies“…icon, view and title string could easily be added as instances variables to
WorkObject. This would require addition of information … so they could be initialized. This removes 87 classes from the system.”
Copyright 1998
40
Safely Turning Responsibilities into Detailed Design and
Code
Rectangle
Knows location
Knows size
Draw
Rectangle
?
Copyright 1998
41
Safely Implementing Responsibilities
Avoid implementation revealing messagesexample: provide getters but not setters
lowerLeftCorner() upperLeftCorner()
lowerRightCorner() upperRightCorner()
Avoid redundant messagesAppropriately place responsibilities
Copyright 1998
42
Safely Implementing Responsibilities
Don’t spread an atomic responsibility across multiple messages
Avoid messages that break an objectrectangle.moveCorner(newCorner)
Avoid overly restrictive implementations Don’t cloak hidden limitationscreateRectangle (lowerLeftCorner, width, height)
replaced with
createConstrainedRectangle(lowerLeftCorner, width, height)
createMinimumSizedRectangle(lowerLeftCorner)
Copyright 1998
43
Good Interfaces Preserve a Good Design
“Consider the objects— books, radios, kitchen appliances, office machines, and light switches— that make up our everyday lives. Well-designed objects are easy to interpret and understand. They contain visible clues to their operation. Poorly designed objects can be difficult and frustrating to use. They provide no clues— or sometimes false clues. They trap the user and thwart the normal process of interpretation and understanding. Alas, poor design predominates. The result is a world filled with frustration, with objects that cannot be understood, with devices that lead to error.” Donald Norman, The Design of Everyday Things
