Chapter 4 Design Principles I Correctness and Robustness

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.

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.

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.

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.

Invariants for Class Automobile -- with variables mileage, VehicleID, value, originalPrice, and type:  mileage > 0 mileage < 1000000 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Key Concept:  Robustness  -- is promoted by enforcing intentions. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

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.

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.