Lecture # 05: Design Principles I - Correctness and Robustness

1. SWE 316: Software Design and Architecture Lecture # 05: Design Principles I - Correctness and Robustness Ch4 Requirements Analysis • Introducing two design Principles: • Correctness • Robustness 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.

2. 2/24 Correctness Interfaces Modularization Robustness Design Details Correctness 4.1 Correctness Goal: That each artifact satisfies designated requirements, and that together they satisfy all of the application’s requirements.

3. 3/24 Correctness Interfaces Modularization Robustness Design Details Approaches to correctness • How can we know that a design is correct or even sufficient? • Approaches to correctness • Informal approaches • Formal approaches • Informal approaches: to be convinced that the design covers the required functionality. • Formal approaches • Formal methods for establishing correctness involve applying mathematical logic to analyzing the way in which the variables change • Formal methods are usually applied when the design enters the detailed design

4. 4/24 Correctness Interfaces Modularization Robustness Design Details Informal approaches to correctness • Correctness by Informal MethodsSimplify and modularize designs until they are convincing. • Informal Approaches • Informal approaches are based on the common sense idea that before we can proclaimed a design to be correct, we have to understand it completely. • Informal approaches require that design must be • Readable (to enhance understanding) • Modular (to deal with complexity)

5. 5/24 Correctness Interfaces Modularization Robustness Design Details 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

6. 6/24 Correctness Interfaces Modularization Robustness Design Details Formal approaches to correctness • Formal approaches • Keeping variable changes under tight control • It can be achieved through invariants • Invariants are unchanging relationships among variable values • Invariants used at class level are class invariants • Examples: • “length>=0” • “length * breadth == area”

7. 7/24 Correctness Interfaces Modularization Robustness Design Details Invariants for Class Automobile -- with variables mileage, VehicleID, value, originalPrice, and type:  • mileage > 0 • mileage < 1000000 • vehicleIDhas 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)

8. 8/24 Correctness Interfaces Modularization Robustness Design Details Formal approaches to correctness (cont.) • Some guidelines for achieving correctness at coding level • Make variables private • Change the variables values only through public accessor methods • Accessorscan be coded to maintain invariants

9. 9/24 Correctness Interfaces Modularization Robustness Design Details Interfaces to modules • Interfaces: collections of function prototypes: Make designs more understandable. • Modularity • Modularization is key to assess the correctness of a design • A module can be either a class or a package of classes • An interface is a set of functions forms (or prototypes). 4.1.2

10. 10/24 Correctness Interfaces Modularization Robustness Design Details Interfaces to modules • Interfaces to classes • When a class supports many methods, it is often beneficial to group them into several interfaces • Grouping allows reuse Shipment setVehicle() perishable() getWidth() printRoute() describeType() getLength() getDuration() setType()

11. 11/24 Correctness Interfaces Modularization Robustness Design Details Introducing Interfaces Dimensions getWidth() getLength() getWeight() TransportationMeans getDuration() setVehicle() printRoute() GoodsType describeType() setType() perishable() Original form Shipment Shipment setVehicle() perishable() getWidth() printRoute() describeType() getLength() getDuration() setType() Forms using interfaces Dimensions Shipment TransportationMeans GoodsType

12. 12/24 Correctness Interfaces Modularization Robustness Design Details Interfaces to modules • Interfaces to Packages • Interface to package is different idea than an interface to a class • Provide an interface for a designated object of a class in the package or • Define a class in a package and define its interface as static methods

13. 13/24 Correctness Interfaces Modularization Robustness Design Details Package Interfaces purchases Pricing Furniture «singleton» PurchasesIF Clothing Selection Appliance ClothingTryout

14. 14/24 Correctness Interfaces Modularization Robustness Design Details Example of Package Interfaces chatServer Conversation- services Conversation ConversationManager ServerComm Participant- services chatClient Display billing Message- reception Accounting Bill ClientComm Financial

15. 15/24 Correctness Interfaces Modularization Robustness Design Details Modularization • To modularize an object-oriented application • Create packages at the higher level • Create classes at the lower level • Choosing classes (Two kinds of classes) • Domain classes • classes that pertain to the specific application under design. • Can be obtained from the sequence diagrams of use cases. • Non-domain classes • generalization of domain classes Sec 4.1.3

16. 16/24 Correctness Interfaces Modularization Robustness Design Details Domain vs. Non-Domain Classes • Domain classes: Particular to the application • Examples: BankCustomer, BankTransaction, Teller • Typically not GUI classes • Sufficient to classify all requirements • Non-Domain classes: Generic • Examples: abstract classes, utility classes • Arise from design and implementation considerations

17. 17/24 Correctness Interfaces Modularization Robustness Design Details Modularization • Choosing packages • Essential part of choosing an application’s architecture • Decompose application into a set of packages (typically 3 to 10)

18. 18/24 Correctness Interfaces Modularization Robustness Design Details Robustness • The ability to handle anomalous situations • Incorrect user input • Faulty data communication • Developer errors • Verifying Input. • Robustness is promoted by verifying data values before using them. • Check all inputs for constraints. It can include: • Type verification, Preconditions, Invariants, Postconditions • Initialize variables and objects at declaration/ creation time improve robustness

19. 19/24 Correctness Interfaces Modularization Robustness Design Details Sources of Errors • Robustness --- ability to handle anomalous situations even in the presence of errors • Sources of error: • Faulty input • User input • Input, not from users • Data communication • Function calls made by other applications • Developer errors • Faulty design • Faulty implementation

20. 20/24 Correctness Interfaces Modularization Robustness Design Details Constraints on Parameters Example: intcomputeArea( intaLength, intaBreadth ) { … } • Capture parameter constraints in classes if feasible intcomputeArea( 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

21. 21/24 Correctness Interfaces Modularization Robustness Design Details Wrapping Parameters (to handle constraints) ReplaceintcomputeArea( intaLength, intaBreadth) {..} with intcomputeArea( Rectangle aRectangle) {..} -- where class Rectangle { … Rectangle( intaLength, intaBreadth ) { if( aLength > 0 ) this.length = aLength; else ….. } … }

22. 22/24 Correctness Interfaces Modularization Robustness Design Details Design Details • How much is enough? • Most detailed design provide • Class, sequence, state, and activity models • Provide activity diagram or pseudocode for complex methods only • Code before design? • Depends of the nature of the task and the experience of the programmer. • Design details through a graph Sec 4.3

23. 23/24 Correctness Interfaces Modularization Robustness Design Details How Much Design Detail Before Initial Coding? 100% Inexperienced designer Recommended % of design detail before starting to code Diminishing ability of designer to envisage consequences of design decision. Experienced designer Very complex Very simple 0% Type of application

24. 24/24 Correctness Interfaces Modularization Robustness Design Details 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 • is promoted by enforcing intentions.