1. 6. DESIGN II: DETAILED DESIGN

2. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 6 Focus Identify corporate practices Develop Architecture - see chapter 5 Perform Detailed Design - apply design patterns - accommodate use cases supply methods - exploit libraries (STL, Java, …) - describe methods where required - develop detailed object models - develop other models Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

3. Chapter Learning Goals Understand how design patterns describe some detailed designs Specify classes and functions completely Specify algorithms –use flowcharts –use pseudocode Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. 1. Introduction to Detailed Design

5. Relating Use Cases, Architecture, & Detailed Design 1. Use case -- analysis “Cars should be able to travel from the top of Smith Hill at 65 mph, travel in a straight line, and arrive at Jones Hollow within 3 minutes.” 3. Architecure2. Domain classes Auto Road Cable Pylon

6. Relating Use Cases, Architecture, & Detailed Design 1. Use case (part of requirements) “Cars should be able to travel from the top of Smith Hill at 65 mph, travel in a straight line, and arrive at Jones Hollow within 3 minutes.” 3. Architecure2. Domain classes Auto Road Support use case Auto Road 4. Detailed Design Smith Hill Cable Jones Hollow Pylon (not specifically required) (added for detailed design) Guardrail Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

7. Typical Roadmap for Detailed Design 1. Begin with architectural models -- see chapter 5 class model: domain & architectural classes overall state model* overall data flow model* overall use case model (several use cases) 3. Refine models & make them consistent -- see section tbd 2. Introduce design patterns & classes which connect the architecture classes with the domain classes -- see section tbd.....

8. Typical Roadmap for Detailed Design 8.Release for implementation 1. Begin with architectural models -- see chapter 5 class model: domain & architectural classes overall state model* overall data flow model* use case model 6. Sketch unit test plans -- see chapter 8 7. Inspect test plans & design -- section 9 3. Refine models, make consistent, ensure complete 5. Specify methods with pre- and post-conditions, flowcharts* & pseudocode* -- sections 3 and 4 2. Introduce classes & design patterns* which connect the architecture classes with the domain classes -- sections 1 and 5 concentrate on riskiest parts first; try alternatives 4. Specify class invariants* -- section 3.1 * if applicable For each class... For each method... For each unit... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

9. Organize the Team for Detailed Design 1/2 1. Prepare for a detailed design kick-off meeting. –Ensure team members aware of the models (views) they are expected to produce typically object model, sequence diagrams, state, & data flow –Ensure team members aware of the notation expected typically: UML plus a pseudocode standard and/or example –Design leader prepares list of modules –Design leader creates a meeting agenda –Project leader allocates time to agenda items (people can speak about detailed designs indefinitely if allowed to!) allocate the time among the agenda items Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

10. Organize the Team for Detailed Design 2/2 2. Hold the kick-off meeting –Designate someone to monitor the agenda item time –Confirm that the architecture is ready for detailed design Make sure that module interfaces the are clear –revise as a group if not Don’t try to develop detailed designs as a group –not necessary: individuals have the responsibility –groups are seldom good at designing details together –Allocate modules to members Request time estimates to design lead by a fixed date –Write out the conclusions and copy/e-mail every member –Decide how and when the results are to be reviewed 3. Update the documentation set –more detailed schedule with modules & inspections 4. Inspect the detailed designs –see figure TBD below 5. Rework as a result of inspections 6. Conduct post mortem and write out lessons learned Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

11. Unified Software Development Process: Design InceptionElaborationConstructionTransitionU. P. Term Requirements Analysis Design Implemen- tation Test (Jacobson et al) Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k ….. 1* 3 2 1 =3 =2 = * Key: terminology used in this book “Requirements”“Achitecture” “Detailed design” Jacobson et al:

12. Analysis 1. Conceptual & abstract 2. Applicable to several designs 1. Concrete: implementation blueprint 2. Specific for an implementation After Jacobson et al: USDP Design 1/2

13. Analysis 1. Conceptual & abstract 2. Applicable to several designs 3. «control», «entity» & «boundary» stereotypes 4. Less formal 5. Less expensive to develop 1. Concrete: implementation blueprint 2. Specific for an implementation 3. No limit on class stereotypes 4. More formal 5. More expensive to develop (  5 × ) After Jacobson et al: USDP Design 1/2

14. 6. Outlines the design 7. Emerges from conceptual thinking 8. Lower priority for in- process maintenance 6. Manifests the design (architecture one view) 7. May use tools (e.g. visual, round-trip engineering) 8. Higher priority for in- process maintenance Analysis After Jacobson et al: USDP Design 2/2

15. 6. Outlines the design 7. Emerges from conceptual thinking 8. Lower priority for in- process maintenance 9. Relatively unconstrained 10. Less focus on sequence diagrams 11. Few layers 6. Manifests the design (architecture one view) 7. May use tools (e.g. visual, round-trip engineering) 8. Higher priority for in- process maintenance 9. Constrained by the analysis & architecture 10. More focus on sequence 11. Many layers Analysis After Jacobson et al: USDP Design 2/2

16. Designing Against Interfaces Customer bill() printAccounts() RegularCustomer bill() printAccounts() BillingClient listCustomers() billCustomers() Abstract layer Concrete (non-abstract) layer Client codeUsed code -- written in terms of Customer (not specific types of Customer ) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

17. 2. Sequence and data flow diagrams for detailed design

18. Refine Models for Detailed Design 1/2: Sequence Diagrams 1. Begin with the sequence diagrams constructed for detailed requirements and/or architecture (if any) corresponding to the use cases. 2. Introduce additional use cases, if necessary, to describe how parts of the design typically interact with the rest of the application. 3. Provide sequence diagrams with complete details –be sure that the exact objects & their classes are specified –select specific function names in place of natural language (calls of one object to another to perform an operation) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

19. 1. Gather data flow diagrams (DFD’s) constructed for detailed requirements and/or architecture (if any). 2. Introduce additional DFD’s, if necessary, to explain data and processing flows. 3. Indicate what part(s) of the other models the DFD’s corresponds to. –e.g., “the following DFD is for each Account object” 4. Provide all details on the DFD’s –indicate clearly the nature of the processing at each node –indicate clearly the kind of data transmitted –expand processing nodes into DFD’s if the processing description requires more detail Refine Models for Detailed Design 2/2: Data Flow Diagrams Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

20. 2. execute() 2.1 setPlayerQuality() 2.3 setForeignQuality() engagement: Engagement 1.3 new Engagement() 3.2 displayResult() :Player’s main character :Encounter game Sequence Diagram for Encounter Foreign Character Use Case :Engagement Display freddie: Foreign Character 1.2 display() :Encounter Cast 1.1 displayForeignChar() 2.2 setQuality() 2.4 setQuality() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 3.1 new EngagementDisplay()

21. Classes of the EncounterForeignCharacter Use Case Engagement execute() EngagementDisplay displayResult() EncounterGame EncounterCast displayForeignChar() setPlayerQuality() setForeignQuality() ForeignCharacter setQuality() PlayerCharacter setQuality() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

22. Detailed Data Flow Diagram for a Banking Application User Customer. getDetails() Cus- tomer Account. getDeposit().....

23. screen template Detailed Data Flow Diagram for a Banking Application User Customer. getDetails() Account. getPass- word() Account. verifyPass- word() Expand details …….. Pass- word Cus- tomer Account unacceptable ATM users Cus- tomer Deposit- screen. display() Account. getDeposit() status local log Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

24. 3. Specifying classes and functions

25. 1. Gather the attributes listed in the SRS. –if the SRS is organized by class 2. Add additional attributes required for the design. 3. Name a method corresponding to each of the requirements for this class. –easy if the SRS is organized by class 4. Name additional methods required for the design. 5. Show the attributes & methods on the object model. 6. State class invariants. Specify A Class Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

26. Specify a Function 1. Note the section(s) of the SRS or SDD which this function (method) satisfies. 2. State what expressions the function must leave invariant. 3. State the method’s pre-conditions (what it assumes). 4. State the method’s post-conditions (its effects). 5. Provide pseudocode and/or a flowchart to specify the algorithm to be used. –unless very straightforward Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

27. Classes at Detailed Design Responsibilities: -- describes each canister undergoing fabrication + display() - getNumSlotsOpen() + setStatus() + numCanisters: int - numWafers: int - size: float Canister Class name Attribute: type +: visible from without Operations Place for comments Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

28. Specifying Functions: withdraw() in Account Invariant of withdraw(): availableFundsI = max( 0, balanceI ) *The function invariant is an additional pre- and post-condition xI denotes an attribute; xP denotes a function parameter; x' is the value of x after execution; X denotes a class constant.....

29. Specifying Functions: withdraw() in Account Invariant of withdraw(): availableFundsI = max( 0, balanceI ) Precondition*: withdrawalAmountP >= 0 AND balanceI - withdrawalAmountP >= OVERDRAFT_MAX Postcondition*: balanceI' = balanceI - withdrawalAmountP *The function invariant is an additional pre- and post-condition xI denotes an attribute; xP denotes a function parameter; x' is the value of x after execution; X denotes a class constant Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

30. 4. Specifying algorithms

31. Flowchart Example protected final void setName( String aName ) { // Check legitimacy of parameter and settings if( ( aName == null ) || ( maxNumCharsInName() <= 0 ) || ( maxNumCharsInName() > alltimeLimitOfNameLength() ) ) { _name = new String( "defaultName" ); System.out.println ( "defaultName selected by GameCharacter.setName()"); } else // Truncate if aName too long if( aName.length() > maxNumCharsInName() ) _name = new String ( aName.getBytes(), 0, maxNumCharsInName() ); else // assign the parameter name _name = new String( aName ); } Parameter & settings make sense? Set _name to “defaultName" Y Parameter name too long? N Truncate name Set _name to parameter YN Nominal path Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

32. An Architecture for Chaining Rule addRule() proveAntecedents() forwardChain() Fact content addFact() proveBack() consequent antecedents static factList static ruleBase Set Fact.factList to the known facts and a Rule.ruleBase to the known rules. Create Fact object soughtFact Execute soughtFact.proveBack( ruleBase ); 1 1..n Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

33. Flowchart for soughtFact.proveBack( ruleBase ) soughtFact in factList ? N Another rule R with soughtFact as consequent ? Y Apply R.proveAntecedents() Y Nominal path Succeede d? Report TRUE Y Report FALSE N N Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

34. FOR number of microseconds supplied by operator IF number of microseconds exceeds critical value Try to get supervisor's approval IF no supervisor's approval abort with "no supervisor approval for unusual duration" message ENDIF ENDIF Pseuodocode Example See section tbd for inspection results of this pseudocode..

35. FOR number of microseconds supplied by operator IF number of microseconds exceeds critical value Try to get supervisor's approval IF no supervisor's approval abort with "no supervisor approval for unusual duration" message ENDIF ENDIF IF power level exceeds critical value abort with "power level exceeded" message ENDIF IF ( patient properly aligned & shield properly placed & machine self-test passed ) Apply X-ray at power level p ENDIF.......ENDFOR Pseuodocode Example See section tbd for inspection results of this pseudocode Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

36. //p FOR number of microseconds supplied by operator for( int i = 0; i < numMicrosecs; ++I ) { //p IF number of microseconds exceeds critical value if( numMicrosecs > XRayPolicies.CRITICAL_NUM_MICROSECS ) //p Try to get supervisor's approval int supervisorMicrosecsApproval = getApprovalOfSuperForLongExposure(); //p IF no supervisor approval if( supervisorMicrosecsApproval <= 0 ) throw ( new SupervisorMicrosecsApprovalException() ) ;......... Pseudocode Extraction Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

37. Advantages of Pseudocode & Flowcharts  Clarify algorithms in many cases  Impose increased discipline on the process of documenting detailed design  Provide additional level at which inspection can be performed  Help to trap defects before they become code  Increases product reliability  May decreases overall costs Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

38. Disadvantages of Pseudocode & Flowcharts  Creates an additional level of documentation to maintain  Introduces error possibilities in translating to code  May require tool to extract pseudocode and facilitate drawing flowcharts Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

39. 5. Design Patterns II: Techniques of detailed design

40. Apply Design Patterns in Detailed Design 1. Become familiar with the design problems solved by design patterns –at a minimum, understand the distinction among (C) creational vs. (S) structural vs. (B) behavioral patterns Consider each part of the detailed design in turn: 2. Determine whether the problem has to do with (C) creating something complex, (S) representing a complex structure, or (B) capturing behavior 3. Determine whether there is a design patterns that addresses the problem –try looking in the category identified (C, S, or B) use this book and/or Gamma et al [Ga] 4. Decide if benefits outweigh drawbacks –benefits usually include increased flexibility –drawbacks increased class complexity(?), less efficient(?) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

41. Factory: Example AnimalCell getNewCellObject() PlantCell getNewCellObject() Factory design pattern BiologicalCell getNewCellObject() Client Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

42. MyOfficeApplication myMethod() Prototype: Example PurchaseOrderDocument clone() InvoiceDocument clone() Document clone() _documentPrototype Client..... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

43. MyOfficeApplication myMethod() Prototype: Example PurchaseOrderDocument clone() InvoiceDocument clone() Document clone() documentPrototypeS Client Customer clone() CashCustomer clone() CreditCustomer clone() customerPrototypeS Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

44. public class MyOfficeApplication {private static Document documentPrototypeS; private static Customer customerPrototypeS; Prototype Design Pattern: Typical Code 1/2 This class is unaware of which type (subclass) of Document or C ustomer it is being executed with..

45. public class MyOfficeApplication {private static Document documentPrototypeS; private static Customer customerPrototypeS; public MyOfficeApplication ( Document dProtopypeP, Customer cPrototypeP ) {documentPrototypeS = dProtopypeP; customerPrototypeS = cPrototypeP; } public myMethod {.... // Need a new Document object : Document d = documentPrototypeS.clone();.... // Need a new Customer object : Customer c = customerPrototypeS.clone();... Prototype Design Pattern: Typical Code 1/2 This class is unaware of which type (subclass) of Document or Customer it is being executed with Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

46. abstract class Document {protected Document clone(); } Prototype Design Pattern: Typical Code 2/2..

47. abstract class Document {protected Document clone(); } Prototype Design Pattern: Typical Code 2/2 public class InvoiceDocument {.... protected Document clone() {.... return new InvoiceDocument(); } public class PurchaseOrderDocument {.... protected Document clone() {.... return new PurchaseOrderDocument(); } Customer has an equivalent hierarchy of classes implementing clone() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

48. Abstract Factory Applied to Encounter Area Level3Area Level3Factory getArea() getAreaConnection() EnvironmentFactory getArea() buildConnection() EncounterEnvironment Client 1..n.....

49. Abstract Factory Applied to Encounter Area Level2Area Level2Factory getArea() getAreaConnection() EncounterAreaConnection EnvironmentFactory getArea() getConnection() EncounterEnvironment getArea() getConnection() incrementLevel() Level2AreaConnection Client «create» 1..n Area getArea() { return envFactory.getArea(); } envFactory Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

50. Abstract Factory Applied to Encounter Area Level2AreaLevel1AreaLevel3Area Level1Factory getArea() getAreaConnection() Level2Factory getArea() getAreaConnection() Level3Factory getArea() getAreaConnection() EncounterAreaConnection EnvironmentFactory getArea() getConnection() EncounterEnvironment Level1AreaConnectionLevel2AreaConnection Client Level3AreaConnection «create» 1..n Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

51. NonLeafNode The Basis for Composite & Decorator Structures Component “every object involved is a Component object” “non-leaf nodes have one or more components” leaf nodenon-leaf node Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

52. NonLeafNode doIt() Composite & Decorator Structures etc. component Component doIt() Leaf doIt() TypeANonLeafNode doIt() TypeBNonLeafNode doIt() Composite: 1..n Client Decorator: 1 for all elements e in component e.doIt() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

53. Architecture of Encounter: Class Model EncounterCharacters EncounterGame EncounterCast EncounterGame EncounterEnvironment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

54. Adapter Design Pattern Financial amount() Principal computeValue() Client Legacy systemAdaptationApplication

55. FinancialAdapter amount() Adapter Design Pattern { legacyAdaptee.computeValue(); } Financial amount() Principal computeValue() Client Legacy systemAdaptation legacyAdaptee Application Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

56. Proxy Design Pattern After Gamma et al BaseActiveClass expensiveMethod() cheapMethod() RealActiveClass expensiveMethod() cheapMethod() Proxy expensiveMethod() cheapMethod() Client _realActiveObject... if ( _realActiveObject == null ){ // never referenced _realActiveObject = getRealActiveObject(); _realActiveObject.expensiveMethod(); } After Gamma et al Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

57. The Iterator Design Pattern iterator: Iterator element: Element Aggregate of Element objects Key: Intended sequence of Element objects After first() executes, iterator references this object. After next() executes, iterator references this object. Before next() executes, iterator references this object. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

58. The Mediator Design Pattern Encapsulates behavior among objects of a class so that they needn’t refer to each other. Mediator Colleague ConcreteMediator ConcreteColleague1ConcreteColleague2 Gamma et al

59. The Mediator Design Pattern EngagementDisplayItem Mediator Colleague ConcreteMediatorConcreteColleague1ConcreteColleague2 SetQualitiesDisplay … Applied to Encounter QualListDispQualValueDisp EncounterDisplay Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

60. 7. Standards, notation and tools for detailed design

61. IEEE 1016-1987 Software Design Document Table of Contents (Reaffirmed 1993) 1. Introduction 1.1.Purpose 1.2.Scope 1.3.Definitions, acronyms & abbreviations 2. References 3. Decomposition description 3.1.Module decomposition 3.1.1 Module 1 description 3.1.1 Module 2 description 3.2 Concurrent process decomposition 3.2.1 Process 1 description 3.2.2 Process 2 description 3.3 Data decomposition 3.3.1 Data entry 1 description 3.3.2 Data entry 2 description 4. Dependency description 4.1 Intermodule dependencies 4.2 Interprocess dependencies 4.3 Data dependencies 5. Interface description 5.1 Module interface 5.1.1 Module 1 description 5.1.2 Module 2 description 5.2 Process interface 5.2.1 Process 1 description 5.2.2 Process 2 description 6. Detailed design 6.1 Module detailed design 6.1.1 Module 1 detail 6.2.2 Module 2 detail 6.2 Data detailed design 6.2.1 Data entity 1 detail 6.2.2 Data entity 2 detail Architecture

62. /** No character name will ever exceed this length */ public final int alltimeLimitOfNameLength () …….. /** For logging*/ protected void display() …….. /** Accessor of _name. "defaultName" assigned if this is first-time access. */ public String getName() …….. Java Source with Javadoc 1/2 …….. /** Character of role-playing games. @author Eric Braude @version 0.1, 7/14/98 */ public abstract class GameCharacter { /** Name of the game character; initially null */ private String _name; Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

63. /** Subclasses must declare limit on size of character names */ protected abstract int maxNumCharsInName(); /** Sets _name to aName if length is within aMaxNumChars in length; otherwise truncates. Inheritors should use this for setName( String ), but not override @param aName: proposed name for _name @param aMaxNumChars -- at which to truncate aName */ protected final void setName( String aName ) …….. …….. Java Source with Javadoc 2/2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

64. 8. Effects on projects of completing detailed designs

65. 1. Make sure the SDD reflects latest version of detailed design, as settled on after inspections. 2. Give complete detail to the schedule (SPMP). 3. Allocate precise tasks to team members (SPMP). 4. Improve project cost & time estimates (see below). 5. Update the SCMP to reflect the new parts. 6. Review process by which the detailed design was created, & determine improvements. Include... –time taken; broken down to include preparation of the designs inspection change –defect summary number remaining open, found at detailed design, closed at detailed design where injected; include previous phases & detailed design stages Bring the Project Up-to-Date After Completing Detailed Design Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

66. Estimate Size & Time from Detailed Designs 1. Start with the list of methods –ensure completeness, otherwise underestimate will result 2. Estimate the lines of code (LOC) for each –classify as very small, small, medium, large, very large normally in ± 7% / 24% / 38% / 24% / 7% proportions –use personal data to covert to LOC otherwise use Humphry’s table below 3. Sum the LOC 4. Covert LOC to person-hours –use personal conversion factor if possible otherwise use published factor 5. Ensure that your estimates of method sizes and time will be compared and saved at project end. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

67. CATEGORY Very small SmallMediumLarge Very large METHOD TYPE Calcula- tion 2.345.1311.2524.6654.04 Data2.604.798.8416.3130.09 I/O9.0112.0616.1521.6228.93 Logic7.5510.9815.9823.2533.83 Set-up3.885.046.568.5311.09 Text3.758.0017.0736.4177.67 Table 6.1 Lines of code (Humphrey )

68. Normal Distribution of “Medium”, “Small” etc. -2 Standard deviations from the mean VS 7% Approximate percentage of methods classified with this description

69. Normal Distribution of “Medium”, “Small” etc. 012-2 Standard deviations from the mean MSL VSVL 38%24% 7% Approximate percentage of methods classified with this description Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

70. 9. Quality in detailed designs

71. Inspect ‡ Detailed Designs 1 of 2 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 detail is part of the architecture. –if a detail 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 1 for inspection procedures. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

72. 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 8. Ensure all details are provided –only code itself is excluded as a “detail” –the detail work must be done eventually, and this is the best time to do it: don’t postpose Inspect Detailed Designs 2 of 2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

73. 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 Table 6.2 IEEE 1044.1 Severity classification Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

74. SeverityDescription MajorRequirement(s) not satisfied MediumNeither major nor trivial TrivialA defect which will not affect operation or maintenance Table 6.3 Defect severity classification using triage Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

75. Types of Defects (1) (IEEE) [PS] Logic problem (forgotten cases or steps; duplicate logic; extreme conditions neglected; unnecessary functions; misinterpretation; missing condition test; checking wrong variable; iterating loop incorrectly etc.) [PS] Computational problem (Equation insufficient or incorrect; precision loss; sign convention fault) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

76. Types of Defects (3) [XDOC, PS] Data problem (sensor data incorrect or missing; operator data incorrect or missing; embedded data in tables incorrect or missing; external data incorrect or missing; output data incorrect or missing; input data incorrect or missing) [XDOC, PS] Documentation problem (ambiguous statement etc.) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

77. Types of Defects (4) [XDOC, PS] Document quality problem (Applicable standards not met etc.) [XDOC, PS] Enhancement (change in program requirements etc.) [XDOC, PS] Failure caused by a previous fix Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

78. Types of Defects (5) Performance problem [XDOC, PS] Interoperability problem (not compatible with other software or component) [XDOC, PS] Standards conformance problem [XDOC, PS] Other (none of the above) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

79. 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 for 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; don’t check.

80. 10. Summary

81. Summary of Detailed Design Should be sufficient to code from Try standard design patterns Define selected algorithms –flowcharts –pseudocode Apply select tools –e,g., Javadoc Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

82. Case Study

83. Detailed Design of RolePlayingGame Package RPGame handleEvent() GameState handleEvent() state { state.handleEvent(); }..

84. Detailed Design of RolePlayingGame Package RPGame handleEvent() GameState handleEvent() stateS { stateS.handleEvent(); } RPGMouseEventListener mouseEnter() MouseListener { rPGameS.handleEvent(); } rPGameS Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

85. eventTarget 2. mouseClicked() User 1. mouse action 3. handleEvent ( Event ) :RPGame :GameState 4. handleEvent ( Event) :RPGMouseEventListener Sequence Diagram for Handling Mouse Events Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

86. RPG Video Game Architecture Packages -- showing domain classes only «framework package» «application package» Characters GameArtifacts RolePlayingGame GameEnvironment EncounterEnvironment PlayerCharacter EncounterCharacter «application package» ForeignCharacter EncounterCharacters «application package» EncounterGame Engagement EngagementDisplay EncounterGame Area PlayerQualityWindow «uses» EncounterAreaConnection ConnectionHyperlink Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

87. EncounterGameDisplays Detailed Design of EncounterGameDisplays Sub-package EngagementDisplay Preparing handleEvent() Reporting handleEvent() SetQualityDisplay EncounterDisplayItem QualListDispl QualValueDispl SetQualValueDispl EncounterCast EncounterDisplay MouseListener Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

88. :EngagementDisplay 2. mouseClicked() User 1. hit dismiss button :RPGMouse EventListener 3. handleEvent() :EncounterGame :ReportingEncounter 4. handleEvent() 5. setVisible( false )  6. setState (new Waiting())  Sequence Diagram for Dismissing Engagement Display Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

89. :PlayerQualityWindow 2. mouseClicked() User 1. hit dismiss button :RPGMouse EventListener 3. handleEvent() :EncounterGame :SettingUp 4. handleEvent() 5. setVisible( false )  6. setState (new Waiting())  Sequence Diagram for Player Completes Setup Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

90. :AreaConnectionHyperlink 2. mouseClicked() User 1. hit area connection hyperlink :RPGMouse EventListener :Waiting 4. handleEvent() 5. setVisible( false )  9. setState (new Engaging()) 6. displayArea() 7. displayPlayerCharacter() 3. handleEvent() :EncounterGame :EncounterEnvironment :EncounterCast If foreign character present 8. displayForeignCharacter() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Sequence Diagram for Player Moves to Adjacent Area

91. Detailed Design of EncounterCharacters Package «facade» EncounterCast PlayerCharacter ForeignCharacter Characters «framework package» GameCharacter EncounterCharacters «application package» EncounterCharacter Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

92. EncounterEnvironment Package GameEnvironment GameCharacter GameArea GameAreaConnection..

93. EncounterEnvironment Package GameEnvironment GameCharacter GameArea EncounterEnvironment Area EncounterEnvironment GameAreaConnection EncounterAreaConnection ConnectionHyperlink Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.