Chapter 4 Design Principles I Correctness and Robustness

1
Chapter 4Design Principles ICorrectness and
Robustness
2
Process Phase Affected by This Chapter
Requirements Analysis
Design
Architecture
Framework
Detailed Design
Implementation
Key
less affected
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
3
Key Concept ? Correctness ?
Goal That each artifact satisfies designated
requirements, and that together they satisfy all
of the applications requirements.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
4
Sufficient Designs Terminology and Rationale
A design sufficient to implement the requirements.
Minimum goal
a correct design
Sometimes called
It follows that
the design must be entirely understandable
A common way to achieve this is to make
the design very modular
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
5
Key Concept ? Correctness by Informal Methods ?
Simplify and modularize designs until they
convince.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
6
Invariants for Class Automobile

• -- with variables mileage, VehicleID, value,
  originalPrice, and type 
• mileage gt 0
• mileage lt 1000000
• vehicleID has at least 8 characters
• value gt -300
• (300 is the disposal cost of a worthless
  automobile)
• originalPrice gt 0
• ( type REGULAR value lt originalPrice )
  
• ( type VINTAGE value gt
  originalPrice )

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
7
Introducing Interfaces 1 of 2
Shipment setVehicle() perishable() getWidth() prin
tRoute() describeType() getLength() getDuration()
setType()
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
8
Introducing Interfaces 2 of 2
Dimensions getWidth() getLength() getWeight()
TransportationMeans getDuration() setVehicle() pri
ntRoute()
GoodsType describeType() setType() perishable()
Original form
Shipment setVehicle() perishable() getWidth() prin
tRoute() describeType() getLength() getDuration()
setType()
Shipment
Forms using interfaces
Dimensions
Shipment
TransportationMeans
GoodsType
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
9
Package Interfaces
purchases
Pricing
Furniture
singleton PurchasesIF
Clothing
Selection
Appliance
ClothingTryout
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
10
Example of Package Interfaces
chatServer
Conversation
Conversation- services
ConversationManager
Participant- services
chatClient
ServerComm
Display
Message- reception
billing
ClientComm
Accounting
Bill
Financial
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
11
Key Concept ? Interfaces ?
-- collections of function prototypes Make
designs more understandable.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
12
Domain vs. Non-Domain Classes

• Domain classes Particular to the application
• Examples BankCustomer, BankTransaction, Teller
• Typically not GUI classes
• Sufficient to classify all requirements (see
  chapter xx)
• Non-Domain classes Generic
• Examples abstract classes, utility classes
• Arise from design and implementation
  considerations

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
13
Alternative Modularizations
Application tracking trajectory of rocket
carrying orbit-bound satellite into position
Alternative 1
mechanics
Alternative 2
control
position
trajectory
ground control
onBoardNavigation
weather
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
14
Improving Robustness Sources of Errors

• Protection from faulty Input
• User input
• Input, not from user
• Data communication
• Function calls made by other applications
• Protection from developer error
• Faulty design
• Faulty implementation

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
15
Constraints on Parameters

• Example
• int computeArea( int aLength, int aBreadth )
  
• Capture parameter constraints in classes if
  feasible
• int computeArea( RectangleDimension a
  RectangleDimension )
• Specify all parameter constraints in method
  comments
• aLength gt 0 and
• aBreadth gt 0 and
• aLength gt aBreadth
• Callers obey explicit requirements on parameters
  
• Problem is method programmers have no control
  over callers
• Check constraints first within the method code
• if( aLength lt 0 )
• Throw exception if this is a predictable
  occurrence
• Otherwise abort if possible
• Otherwise return default if it makes sense in
  context
• And generate warning or log to a file

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
16
Key Concept ? Robustness ?
-- is promoted by verifying data values before
using them.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
17
Wrapping Parameters
Replace int computeArea( int aLength, int
aBreadth ) .. with int
computeArea( Rectangle aRectangle )
.. -- where class Rectangle
Rectangle( int aLength, int aBreadth )
if( aLength gt 0 ) this.length aLength
else ..
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
18
Key Concept ? Robustness ?
-- is promoted by enforcing intentions.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
19
How Much Design Detail Before Initial Coding?
100
Inexperienced designer
Recommen-ded of design detail before starting
to code
Diminishing ability of designer to envisage
consequences of design decision.
Experienced designer
0
Very simple
Very complex
Type of application
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
20
Summary of This Chapter

• Correctness of a Design or Code
• Supports the requirements
• In general, many correct designs exist
• Robustness of a Design or Code
• Absorbs errors
• -- of the user
• -- of developers

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
21
Video Store Application Sufficient Classes?
Video
CheckOutDurationDisplay
Customer
CheckOutDisplay
BarCodeReader
RegisterNewVideoDisplay
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.