1. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Objectives Lecture # 05: Design Principles I - Correctness and Robustness SWE 316: Software Design and Architecture  Introducing two design Principles:  Correctness  Robustness Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. Ch 4 Requirements Analysis Design Implementation ArchitectureFrameworkDetailed Design Key:= less affected

2. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Correctness Goal: That each artifact satisfies designated requirements, and that together they satisfy all of the application’s requirements. 4.1 Correctness InterfacesModularizationRobustnessDesign Details 2/24

3. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 Correctness InterfacesModularizationRobustnessDesign Details 3/24

4. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Informal approaches to correctness  Correctness by Informal Methods Simplify 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) Correctness InterfacesModularizationRobustnessDesign Details 4/24

5. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Sufficient Designs: Terminology and Rationale A design sufficient to implement the requirements. a correct design Sometimes called … the design must be entirely understandable It follows that … the design very modular A common way to achieve this is to make … Minimum goal: Correctness InterfacesModularizationRobustnessDesign Details 5/24

6. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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” Correctness InterfacesModularizationRobustnessDesign Details 6/24

7. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Invariants for Class Automobile -- with variables mileage, VehicleID, value, originalPrice, and type : 1) mileage > 0 2) mileage < 1000000 3) vehicleID has at least 8 characters 4) value >= -300  ($300 is the disposal cost of a worthless automobile) 5) originalPrice >= 0 6) ( type == “REGULAR” && value <= originalPrice ) ||  ( type == “VINTAGE” && value >= originalPrice ) Correctness InterfacesModularizationRobustnessDesign Details 7/24

8. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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  Accessors can be coded to maintain invariants Correctness InterfacesModularizationRobustnessDesign Details 8/24

9. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 Correctness Interfaces ModularizationRobustnessDesign Details 9/24

10. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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() Correctness Interfaces ModularizationRobustnessDesign Details 10/24

11. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Introducing Interfaces Shipment Dimensions getWidth() getLength() getWeight() TransportationMeans getDuration() setVehicle() printRoute() GoodsType describeType() setType() perishable() Shipment Dimensions TransportationMeans GoodsType Original form Forms using interfaces Shipment setVehicle() perishable() getWidth() printRoute() describeType() getLength() getDuration() setType() Correctness Interfaces ModularizationRobustnessDesign Details 11/24

12. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 Correctness Interfaces ModularizationRobustnessDesign Details 12/24

13. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Package Interfaces Pricing purchases Furniture Clothing Appliance Selection ClothingTryout «singleton» PurchasesIF Correctness Interfaces ModularizationRobustnessDesign Details 13/24

14. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Participant- services Conversation- services Example of Package Interfaces Conversation chatServer chatClient Display ConversationManager ClientComm ServerComm billing AccountingBill Financial Message- reception Correctness Interfaces ModularizationRobustnessDesign Details 14/24

15. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Sec 4.1.3 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 CorrectnessInterfaces Modularization RobustnessDesign Details 15/24

16. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 CorrectnessInterfaces Modularization RobustnessDesign Details 16/24

17. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Modularization  Choosing packages  Essential part of choosing an application ’ s architecture  Decompose application into a set of packages (typically 3 to 10) CorrectnessInterfaces Modularization RobustnessDesign Details 17/24

18. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 CorrectnessInterfacesModularization Robustness Design Details 18/24

19. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 CorrectnessInterfacesModularization Robustness Design Details 19/24

20. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 CorrectnessInterfacesModularization Robustness Design Details 20/24

21. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Wrapping Parameters (to handle constraints) 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 ….. } … } CorrectnessInterfacesModularization Robustness Design Details 21/24

22. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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 CorrectnessInterfacesModularizationRobustness Design Details 22/24

23. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser How Much Design Detail Before Initial Coding? Very simple 0% Recommended % of design detail before starting to code Very complex 100% Type of application Inexperienced designer Experienced designer Diminishing ability of designer to envisage consequences of design decision. CorrectnessInterfacesModularizationRobustness Design Details 23/24

24. SWE 316: Software Design and Architecture – Dr. Khalid Aljasser 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. CorrectnessInterfacesModularizationRobustnessDesign Details 24/24