Chapter 4 Design Principles I Correctness and Robustness

Chapter 4 Design Principles I Correctness and Robustness

Requirements Analysis Process Phase Affected by This Chapter Design Framework. Architecture. Detailed Design Key: = less affected Implementation 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 Minimum goal: A design sufficient to implement the requirements. Sometimes called … a correct design 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 Method 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 -- with variables mileage, Automobile Vehicle. ID, value, original. Price, and type: 1) mileage > 0 2) mileage < 1000000 3) vehicle. ID has at least 8 characters 4) value >= -300 ($300 is the disposal cost of a worthless automobile) 5) original. Price >= 0 6) ( type == “REGULAR” && value <= original. Price ) || Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Introducing Interfaces 1 of 2 Shipment set. Vehicle() perishable() get. Width() print. Route() describe. Type() get. Length() get. Duration() set. Type() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Introducing Interfaces 2 of 2 Original form Shipment set. Vehicle() perishable() get. Width() print. Route() describe. Type() get. Length() get. Duration() set. Type() Dimensions. Transportation. Means Goods. Type get. Width() get. Duration() describe. Type() get. Length() set. Vehicle() set. Type() get. Weight() print. Route() perishable() Shipment Forms using interfaces Dimensions Shipment Transportation. Mean Goods. Type Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Package Interfaces purchases Pricing Furniture Clothing Appliance «singleton» Purchases. IF Selection Clothing. Tryout Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Example of Package Interfaces chat. Server Conversationservices Conversation. Manager Participantservices Server. Comm chat. Client Display Messagereception billing Accounting Client. Comm 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 o Domain classes: Particular to the application o Examples: Bank. Customer, Bank. Transaction, Teller o Typically not GUI classes o Sufficient to classify all requirements (see chapter xx) o Non-Domain classes: Generic o Examples: abstract classes, utility classes o Arise from design and implementation Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Alternative Modularizations Alternative 1 mechanics Application tracking trajectory of rocket carrying orbit-bound satellite into position Alternative 2 control position ground control trajectory on. Board. Navigation weather Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Improving Robustness: Sources of Errors 1. Protection from faulty Input o User input o Input, not from user • • Data communication Function calls made by other applications 2. Protection from developer error o Faulty design o Faulty implementation Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Example: Constraints on Parameters int compute. Area( int a. Length, int a. Breadth ) { … } q Capture parameter constraints in classes if feasible int compute. Area( Rectangle. Dimension a Rectangle. Dimension ) q Specify all parameter constraints in method comments a. Length > 0 and a. Breadth > 0 and a. Length >= a. Breadth q Callers obey explicit requirements on parameters o Problem is method programmers have no control over callers q Check constraints first within the method code if( a. Length <= Adapted 0 ) 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.

Wrapping Parameters Replace int compute. Area( int a. Length, int a. Breadth ) {. . } with int compute. Area( Rectangle a. Rectangle ) {. . } -- where class Rectangle { … Rectangle( int a. Length, int a. Breadth ) { if( a. Length > 0 ) this. length = a. Length; 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% Recomme n-ded % of design detail before starting to code Inexperienced designer Experienced designer 0% Very simple Diminishing ability of designer to envisage consequences of design decision. 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 q Correctness of a Design or Code o Supports the requirements o In general, many correct designs exist q Robustness of a Design or Code o Absorbs errors o -- of the user o -- of developers Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Video Store Application: Sufficient Classes? Video Customer Check. Out. Duration. Display Check. Out. Display Bar. Code. Reader Register. New. Video. Display Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.