1. Chapter 4 Design Principles I Correctness and Robustness

2. Process Phase Affected by This Chapter
Requirements
Analysis
Process Phase Affected by This Chapter
Design
Framework
Architecture
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 application’s 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 > 0
mileage <
vehicleID has at least 8 characters
value >= -300
($300 is the disposal cost of a worthless automobile)
originalPrice >= 0
( type == “REGULAR” && value <= originalPrice ) ||
( type == “VINTAGE” && value >= 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()
printRoute()
describeType()
getLength()
getDuration()
setType()
Introducing Interfaces 1 of 2
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()
printRoute()
GoodsType
describeType()
setType()
perishable()
Original
form
Shipment
setVehicle()
perishable()
getWidth()
printRoute()
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 PurchasesIF Clothing
«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 Modularizations
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 > 0 and
aBreadth > 0 and
aLength >= 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 <= 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. Replace int computeArea( int aLength, int aBreadth ) {..}
Wrapping Parameters
Replace int computeArea( int aLength, int aBreadth )
{..}
with int computeArea( Rectangle aRectangle )
-- where class Rectangle
{ …
Rectangle( int aLength, int aBreadth )
{ if( aLength > 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
Type of application
Very complex
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?
CheckOutDurationDisplay
Customer
CheckOutDisplay
BarCodeReader
RegisterNewVideoDisplay
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.