1 / 93

6. DESIGN II: DETAILED DESIGN

6. DESIGN II: DETAILED DESIGN. Software Engineering Roadmap: Chapter 6 Focus. Develop Architecture - see chapter 5. Identify corporate practices. Perform Detailed Design - apply design patterns - accommodate use cases supply methods - exploit libraries (STL, Java, …)

sveta
Download Presentation

6. DESIGN II: DETAILED DESIGN

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. 6. DESIGN II:DETAILED DESIGN

  2. Software Engineering Roadmap: Chapter 6 Focus Develop Architecture - see chapter 5 Identify corporate practices 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 Plan project Analyze requirements Maintain Integrate & test system Design Implement Test units 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.” 2. Domain classes 3. Architecure Cable Auto Road 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.” 2. Domain classes 3. Architecure Cable (not specifically required) Auto Road Pylon 4. Detailed Design (added for detailed design) Support use case Auto Cable Guardrail Road Smith Hill Pylon Jones Hollow 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) 2. Introduce design patterns & classes which connect the architecture classes with the domain classes -- see section tbd 3. Refine models & make them consistent -- see section tbd . . . . .

  8. 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* • use case model • 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 3. Refine models, make consistent, ensure complete 4. Specify class invariants* -- section 3.1 For each class ... 5. Specify methods with pre- and post-conditions, flowcharts* & pseudocode* -- sections 3 and 4 For each method ... 6. Sketch unit test plans -- see chapter 8 For each unit ... 7. Inspect test plans & design -- section 9 * if applicable 8.Release for implementation 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 One way to ... 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 One way to ... 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 U. P. Term Requirements Analysis Design Implemen- tation Test (Jacobson et al) Inception Elaboration Construction Transition 1* Jacobson et al: 2 3 Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k ….. ….. *Key: terminology used in this book “Detailed design” 1 = “Requirements” 2 = “Achitecture” 3 =

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

  13. 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×) Analysis Design 1/2 After Jacobson et al: USDP

  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 Design 2/2 After Jacobson et al: USDP

  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 Design 2/2 After Jacobson et al: USDP

  16. Designing Against Interfaces Client code Used code Abstract layer BillingClient listCustomers() billCustomers() Customer bill() printAccounts() -- written in terms of Customer (not specific types of Customer) Concrete (non-abstract) layer RegularCustomer bill() printAccounts() 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 Design1/2: Sequence Diagrams One way to ... 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. Refine Models for Detailed Design2/2: Data Flow Diagrams One way to ... 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 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

  21. Classes of the EncounterForeignCharacter Use Case EngagementDisplay displayResult() Engagement execute() EncounterGame PlayerCharacter setQuality() EncounterCast displayForeignChar() setPlayerQuality() setForeignQuality() ForeignCharacter 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 Customer. getDetails() Account. getDeposit() Cus- tomer User . . . . .

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

  24. 3. Specifying classes and functions

  25. Specify A Class One way to ... 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. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  26. Specify a Function One way to ... 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 Canister Class name + numCanisters: int - numWafers: int - size: float Attribute: type +: visible from without + display() - getNumSlotsOpen() + setStatus() Operations Responsibilities: -- describes each canister undergoing fabrication 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 xI denotes an attribute; xP denotes a function parameter; x' is the value of x after execution; X denotes a class constant • Invariant of withdraw(): • availableFundsI = max( 0, balanceI ) . . . . . *The function invariant is an additional pre- and post-condition

  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 xI denotes an attribute; xP denotes a function parameter; x' is the value of x after execution; X denotes a class constant *The function invariant is an additional pre- and post-condition Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  30. 4. Specifying algorithms

  31. Parameter & settings make sense? Flowchart Example N Y Nominal path Set _name to “defaultName" Parameter name too long? N Y 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 ); } Set _name to parameter Truncate name Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  32. An Architecture for Chaining static ruleBase static factList Rule addRule() proveAntecedents() forwardChain() Fact content addFact() proveBack() consequent 1 1..n antecedents Set Fact.factList to the known facts and a Rule.ruleBase to the known rules. Create Fact object soughtFact Execute soughtFact.proveBack( ruleBase ); 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? Y N Another rule R with soughtFact as consequent? Nominal path Y N Apply R.proveAntecedents() Succeeded? Y N Report TRUE Report FALSE Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  34. Pseuodocode Example • 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 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 PseuodocodeExample 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. Pseudocode Extraction • //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() ); • . . . . . . . . . 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 One way to ... 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 Factory design pattern BiologicalCell getNewCellObject() Client AnimalCell getNewCellObject() PlantCell getNewCellObject() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

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

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

  45. public classMyOfficeApplication { 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(); . . . PrototypeDesign 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. Prototype Design Pattern: Typical Code 2/2 abstract classDocument { protected Document clone(); } . . . .

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

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

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

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

More Related