1. Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1

2. © 2010 John Wiley & Sons Ltd. Chapter 20: Design Quality and Metrics 2

3. Learning Goals of This Chapter How do you assess the degree of understandability in a software design? How do you assess the degree of cohesion and coupling? -- degree of sufficiency? -- robustness? -- flexibility, reusability? -- time efficiency, space efficiency? -- reliability? -- security? How is quality in architecture selection measured? How is the quality of a detailed design measured? Requirements analysis Design Implementation Testing Maintenance Planning The Software Development Lifecycle Phase most relevant to this chapter is shown in bold © 2010 John Wiley & Sons Ltd. 3

4. The Quality of a Design 0 understandable (How cohesive and clear are the parts and how low is the number of connections between parts) 0: unclear parts and many connections among them 10: very understandable parts with few interconnections sufficient (How evidently it accommodates the requirements) 0: unrelated to the requirements 10: obviously accommodates every requirements robust 0: any input anomaly has serious consequences 10: every input anomaly accommodated smoothly How … 4

5. © 2010 John Wiley & Sons Ltd. The Quality of a Design 1 flexible 0: anticipated additional requirements require extensive change to the design 10: most anticipated requirements require no change to the design reusable 0: no parts of the design can be used in other applications 10: more than 75% of the classes can be used in other applications How … 5

6. © 2010 John Wiley & Sons Ltd. The Quality of a Design 3 efficient: Implementation based on this design … 0: … will probably not execute at required speed or use required storage 10: … will execute at with as much speed and storage to spare as reasonably conceivable reliable: Implementation based on this design … 0: … will probably fail with a clearly unacceptable frequency 10: … will probably fail well within the allowable frequency secure: 0: … will probably exceed the maximum allowable vulnerability limit 10: … will probably have as few vulnerabilities as can be expected How … 6

7. © 2010 John Wiley & Sons Ltd. Measuring the Sufficiency of a Design: Video Store Example VideoStore checkIn() checkOut() Design 1 VideoStore Design 2 DVDInventory DVD VSCustomer DVDRentalSet checkIn() checkOut() VSCustomerBase DVDRental * 1 * * 1 1 1 1 7

8. © 2010 John Wiley & Sons Ltd. Measuring the Robustness of a Design Design 1 VideoStore Design 2 DVDs DVD VSCustomer DVDRentals VSCustomers DVDRental * 1 * * 1 1 1 VideoStore customers DVDs rentals DVD VSCustomer 1 * * DVDRental 8

9. Robustness Metric Application will crash without a trace if it encounters any wrong or unanticipated input Degree to which the design reacts ideally to anomalous input 0 10 Application will recover ideally from any wrong or unanticipated input Will recover ideally half the time Application will crash half the time when it encounters any wrong or unanticipated input: 5 © 2010 John Wiley & Sons Ltd. 9

10. Design Flexibility Cost / Benefit Tradeoff Benefits of Flexible Designs Facilitates added requirements May result in more elegant and understandable designs Costs of Flexible Designs  Extra cost (time) needed  May result in cluttered and less understandable design  Time wasted if requirements expand in unexpected direction 10

11. © 2010 John Wiley & Sons Ltd. Reusability Attributes Abstract enough to get wide coverage – But too abstract = useless – E.g., class RetailArtifact may have too little content Specific enough to be useful – But not too specific – E.g., AcmeNumber6BrownPencil Parameterized methods – But not more than six parameters – Consider f( x1 ) also f( x1, x2 ) also f( x1, x2, x3 ); … 11

12. © 2010 John Wiley & Sons Ltd. Measuring Reusability Degree of coverage 0 = negligible coverage of different applications 2 = as wide as can be expected Degree of content 0 = negligible content or substance 2 = very rich content or associations Parameterization of methods – allows method reuse 0 = very restrictive methods; very narrow scope 2 = widely applicable methods 12

13. © 2010 John Wiley & Sons Ltd. Time Efficiency Example 13

14. :AreaConnectionHyperlink 2. mouseClicked() User 1. press area connection hyperlink :RPGMouse EventListener :Waiting 4. handleEvent() 5. setVisible( false )  6. displayArea() 8. displayPlayerCharacter() 3. handleEvent() :EncounterGame :EncounterEnvironment :EncounterCast Sequence Diagram for Player Moves to Adjacent Area :Area 7. display() :PlayerCharacter 9. showCharacter() © 2010 John Wiley & Sons Ltd. 14

15. Identifying Methods with Highest Potential Source of Delay StepFunctionRelative speed 0 = negligible 1 = neither 2 = significant 1Press area connection hyperlink0 2mouseClicked()0 3handleEvent()0 4 0 5setVisible( false )1 6displayArea()2 7display()1 8displayPlayerCharacter()2 9showCharacter()1 TOTAL7 / 12 © 2010 John Wiley & Sons Ltd. 15

16. Timing Diagram Execute method 1 Execute method 2 Execute method 3 Execute method 5 Execute method 2 Execute method 6 Execute method 4 thread 1 thread 2 time wait © 2010 John Wiley & Sons Ltd. 16

17. Source method and class of storage creation or reclamation Temp. or perm.? Maximum rate of increase, uncom- pressed Minimum rate of decrease, uncompressed Worst case Rental: saveRental() T514 bytes per minute for 2 days 6 clients; Title 100 bytes; director 30 bytes; stars 4 bytes  30; length 2. One title every 3 minutes. Rental: removeRental() P0 bytes per minute for 2 days 90% of rentals returned within 2 days DVDInventory: saveDVD() ………… DVDInventory: removeDVD() ………… Analyzing Secondary Storage © 2010 John Wiley & Sons Ltd. 17

18. Secondary Storage Needs Over Time: Video Store © 2010 John Wiley & Sons Ltd. 18

19. © 2010 John Wiley & Sons Ltd. Frequent Failure Points: Use Cases Data collection – from users – from other applications – from data communication Steps causing complexity – Use case indicates involved operations Anomalous situations – E.g., attempt to rent multiple copies of a movie 19

20. Setting qualities Frequent Failure Points: State Models -- “Encounter” Application Setting up Engaging Waiting Player completes setup Player dismisses report window Reporting Encounter completed Player dismisses set qualities widow Player requests status Player requests to set qualities Foreign character enters area [foreign character absent] [foreign character present] Player moves to adjacent area Player quits Foreign character enters area © 2010 John Wiley & Sons Ltd. 20

21. account # & deposit balance query account # & deposit account # User Make inquiry account database deposit transaction account data Validate inquiry Do deposit transaction Create account summary Validate deposit error Printer member banks bank name Display account data account display Frequent Failure Points: Data Flow Models ATM Application Check for money laundering account # & deposit account # alert/none © 2010 John Wiley & Sons Ltd. Get deposit Get inquiry 21

22. © 2010 John Wiley & Sons Ltd. Frequent Failure Points: Class Models Choke Points A class that relates to many other classes Deep inheritance Three or more levels of substantive inheritance VStoreRental VStoreCustomer DVD Rental DVDRentalCustomer VStoreCustomer RentalCustomer Customer 22

23. Security Metrics Operating system Object code ? ? Drive c: Drive d: ? Internet © 2010 John Wiley & Sons Ltd. 23

24. © 2010 John Wiley & Sons Ltd. A Design Beginning for Secure Simple Login Security encrypt() getUsersFromURL() Login User id ‡ password ‡ * ‡ encrypted Constructor queries for ID and password Attempts to keep secure content/algorithms in a single location. 24

25. © 2010 John Wiley & Sons Ltd. Property-based Security Metrics 1 Confidentiality oDegree to which data passed may become visible to the unauthorized oEstimated percentage of data compromises 1 Non-repudiation oDegree to which parties can prove the existence of agreements oEstimated percentage of un-provable agreements Integrity oExtent of ability to validate that data are not altered in transit oEstimated percentage of messages alterable in transit 1 i.e., of a specified severity. 25

26. © 2010 John Wiley & Sons Ltd. Property-based Security Metrics 2 Authentication oExtent of ability to validate user’s identity oEstimated percentage of improper authentications Authorization – Degree to which permission to deal with privileged data may be compromised – Estimated percentage of unauthorized permissions Availability oDegree to which availability could be compromised; e.g., by denial-of-service attacks oEstimated number of availability 1 compromises per year i.e., of given severity 26

27. © 2010 John Wiley & Sons Ltd. Property-based Security Metrics Scale of 1-10 Confidentiality oDegree to which data passed may become visible to the unauthorized Non-repudiation oDegree to which parties can prove the existence of agreements Integrity oExtent of ability to validate that data are not altered in transit Authentication oExtent of ability to validate user’s identity Authorization – Degree to which permission to deal with privileged data may be compromised Availability oDegree to which availability could be compromised; e.g., by denial-of- service attacks 27

28. © 2010 John Wiley & Sons Ltd. Architecture alternative 1. State design pattern 2. ad hoc GUI- driven 3. State- transition table Quality Quality weight: 1-10 High = 9; Medium = 5; Low = 2 Extension9HighLowMedium Change7HighLowMedium Simplicity5LowHighMedium Efficiency: speed 5MediumHighMedium Efficiency: storage 2Low Medium TOTAL: (higher = better)183126140 Fuzzy Method for Comparing Architectures © 2010 John Wiley & Sons Ltd. 28

29. © 2010 John Wiley & Sons Ltd. SimItem SimEvent serviceDuration Number Simulation execute() initialize() time() ScheduledEvents addEvent() removeEarliest() SimConfiguration setUp() QueueForTeller Architecture for a Simulation SimConfiguration SimItems SimEvents SimDriver Random Teller 29

30. RolePlayingGame State Design Pattern Applied to Encounter RPGame handleEvent() GameState handleEvent() state { state.handleEvent(); } Reporting handleEvent() Engaging handleEvent() SettingUp handleEvent() EncounterGame Waiting handleEvent() Setting Qualities handleEvent() © 2010 John Wiley & Sons Ltd. 30

31. © 2010 John Wiley & Sons Ltd. Architecture Alternative 2 for Encounter PlayerCharacter Area display() AreaConnector area1 area2 transition() PlayerCharacterWindow set( Quality, float ) exit() ActionListener ForeignCharacter 2 * 31

32. © 2010 John Wiley & Sons Ltd. Key: if this  event occurs while Encount er is in this  state, then perform the corresp onding action in the table. Event Click on exit Request quality change Dismiss quality window Foreign character enters Foreign character leaves Go to indicated area Show quality window Remove quality widow, and Transition to Waiting state Show both characters, and transition to Engaging state Engaging (do nothing) Compute results of engagement, and transition to Waiting state Setting qualities Transition to Waiting state Transition to Engaging state Transition to Waiting state Table-Driven State- Transition Event Handling © 2010 John Wiley & Sons Ltd. 32

33. © 2010 John Wiley & Sons Ltd. Architecture alternative 1. State design pattern 2. ad hoc GUI- driven 3. State- transition table Quality Quality weight: 1-10 High = 9; Medium = 5; Low = 2 Extension9HighLowMedium Change7HighLowMedium Simplicity5LowHighMedium Efficiency: speed 5MediumHighMedium Efficiency: storage 2Low Medium TOTAL: (higher = better)183126140 Fuzzy method for comparing architectures © 2010 John Wiley & Sons Ltd. 33

34. Preparing Defects in Encounter State-Transition Diagram Setting up EngagingWaiting Player completes setup Player dismisses window Reporting Move to adjacent area Foreign character enters area Player ready to proceed Foreign character enters area Player dismisses qualities menu Player requests status Player clicks qualities menu Not specific enough Not specific enough Does not handle player’s entry to area containing foreign character State unclear © 2010 John Wiley & Sons Ltd. 34

35. © 2010 John Wiley & Sons Ltd. Inspecting ‡ Detailed Designs 1 1. Prepare to record metrics during the design process. – Include (1.1) time taken; (1.2) type of defect; (1.3) severity 2. Ensure each architecture module is expanded. 3. Ensure each element of the detailed design is part of the architecture. – if an element does not belong to any such module, the architecture may have to be revised 4. Ensure the design fulfills its required functions 5. Ensure that design is complete (classes & methods) 6. Ensure that the design is testable. ‡ See chapter 5 for inspection procedures. 35

36. © 2010 John Wiley & Sons Ltd. 7. Check detailed design for -- – simplicity a design that few can understand (after a legitimate effort!) is expensive to maintain, and can result in defects – generality enables design of similar applications? – expandability enables enhancements? – efficiency speed, storage – portability Inspecting Detailed Designs 2 36

37. © 2010 John Wiley & Sons Ltd. 8. Ensure all detail provided – Classes Class invariants clear? (required limits on attributes; required relationships among attributes) – Methods Preconditions Invariants Postconditions Pseudocode Inspecting Detailed Designs 3 37

38. © 2010 John Wiley & Sons Ltd. SeverityDescription Urgent Failure causes system crash, unrecoverable data loss; or jeopardizes personnel High Causes impairment of critical system functions, and no workaround solution does exist Medium Causes impairment of critical system functions, though a workaround solution does exist Low Causes inconvenience or annoyance None None of the above IEEE 1044.1 Severity Classification © 2010 John Wiley & Sons Ltd. 38

39. © 2010 John Wiley & Sons Ltd. SeverityDescription MajorRequirement(s) not satisfied MediumNeither major nor trivial TrivialA defect which will not affect operation or maintenance Defect Severity Classification using Triage 39

40. IF aQuality is not recognized Log error to log file Inform user qualities unchanged ELSE IF aQualityValue out of bounds Log error to log file Inform user qualities unchanged ELSE Set the stated quality to aQualityValue Reduce the remaining qualities,... retaining their mutual proportion,... making the sum of qualities unchanged ENDIF Pseudocode Inspection 1 2 3 4 5 6 7 8 9 10 setQuality() should be mentioned Lacks detail on how to allocate the remaining quality values Make these preconditions as well. © 2010 John Wiley & Sons Ltd. 40