1 / 21

Chapter 4 Design Principles I Correctness and Robustness

Chapter 4 Design Principles I Correctness and Robustness. Process Phase Affected by This Chapter. Requirements Analysis. Design. Framework. Architecture. Detailed Design. Implementation. Key:. = less affected.

diannah
Download Presentation

Chapter 4 Design Principles I Correctness and Robustness

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 4Design Principles ICorrectness and Robustness

  2. Process Phase Affected by This Chapter Requirements Analysis 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 < 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.

  7. Introducing Interfaces 1 of 2 Shipment setVehicle() perishable() getWidth() printRoute() 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() 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 «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 > 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. 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? Video CheckOutDurationDisplay Customer CheckOutDisplay BarCodeReader RegisterNewVideoDisplay Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

More Related