6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design...
-
Upload
angelina-bishop -
Category
Documents
-
view
223 -
download
0
Transcript of 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design...
![Page 1: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/1.jpg)
6. DESIGN II:DETAILED DESIGN
![Page 2: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/2.jpg)
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.
![Page 3: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/3.jpg)
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.
![Page 4: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/4.jpg)
1. Introduction to Detailed Design
![Page 5: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/5.jpg)
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. Domainclasses
Auto
Road
Cable
Pylon
![Page 6: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/6.jpg)
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. Domainclasses
Auto
Road
Support use case Auto
Road4. DetailedDesign
Smith Hill
Cable
Cable
Jones Hollow
Pylon
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.
![Page 7: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/7.jpg)
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
. . . . .
![Page 8: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/8.jpg)
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.
![Page 9: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/9.jpg)
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.
![Page 10: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/10.jpg)
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 reviewed3. Update the documentation set
– more detailed schedule with modules & inspections4. Inspect the detailed designs
– see figure TBD below5. Rework as a result of inspections6. Conduct post mortem and write out lessons learned
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 11: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/11.jpg)
Unified Software Development Process: Design
Inception Elaboration Construction TransitionU. 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:
![Page 12: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/12.jpg)
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
![Page 13: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/13.jpg)
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
![Page 14: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/14.jpg)
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
![Page 15: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/15.jpg)
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
![Page 16: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/16.jpg)
Designing Against Interfaces
Customerbill()
printAccounts()
RegularCustomerbill()
printAccounts()
BillingClientlistCustomers()billCustomers()
Abstract layer
Concrete (non-abstract) layer
Client code Used 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.
![Page 17: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/17.jpg)
2. Sequence and data flow diagrams for detailed design
![Page 18: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/18.jpg)
Refine Models for Detailed Design
1/2: Sequence Diagrams1. 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.
![Page 19: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/19.jpg)
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 Design2/2: Data Flow Diagrams
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 20: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/20.jpg)
2. execute()
2.1 setPlayerQuality()
2.3 setForeignQuality()
engagement:Engagement
1.3 new Engagement()
3.2 displayResult()
:Player’s main
character
:Encountergame
Sequence Diagram for Encounter Foreign Character Use Case
:EngagementDisplay
freddie: Foreign
Character
1.2 display()
:EncounterCast
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()
![Page 21: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/21.jpg)
Classes of the EncounterForeignCharacter Use Case
Engagementexecute()
EngagementDisplaydisplayResult()
EncounterGame
EncounterCastdisplayForeignChar()
setPlayerQuality()setForeignQuality()
ForeignCharactersetQuality()
PlayerCharactersetQuality()
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 22: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/22.jpg)
Detailed Data Flow Diagram for a Banking Application
User
Customer.getDetails()
Cus-tomer
Account.getDeposit()
. . . . .
![Page 23: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/23.jpg)
screentemplate
Detailed Data Flow Diagram for a Banking Application
User
Customer.getDetails()
Account.getPass-word()Account.
verifyPass-word()
Expand details……..
Pass-word
Cus-tomer
Account
unacceptableATM users
Cus-tomer
Deposit-screen.
display()
Account.getDeposit()
status
locallog
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 24: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/24.jpg)
3. Specifying classes and functions
![Page 25: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/25.jpg)
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.
![Page 26: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/26.jpg)
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.
![Page 27: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/27.jpg)
Classes at Detailed Design
Responsibilities:-- describes each canister undergoing fabrication
+ display()- getNumSlotsOpen()+ setStatus()
+ numCanisters: int - numWafers: int- size: float
Canister Class name
Attribute: type
+: visiblefrom without Operations
Place for comments
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 28: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/28.jpg)
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
. . . . .
![Page 29: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/29.jpg)
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.
![Page 30: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/30.jpg)
4. Specifying algorithms
![Page 31: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/31.jpg)
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.
![Page 32: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/32.jpg)
An Architecture for Chaining
RuleaddRule()
proveAntecedents()forwardChain()
Factcontent
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.
![Page 33: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/33.jpg)
Flowchart for soughtFact.proveBack( ruleBase )soughtFact
in factList?N
Another rule Rwith
soughtFact as consequent?
Y
Apply R.proveAntecedents()
YNominal path
Succeeded?
Report TRUE
Y
Report FALSE
N
N
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 34: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/34.jpg)
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
. . . .
![Page 35: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/35.jpg)
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.
![Page 36: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/36.jpg)
//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.
![Page 37: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/37.jpg)
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.
![Page 38: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/38.jpg)
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.
![Page 39: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/39.jpg)
5. Design Patterns II: Techniques of detailed design
![Page 40: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/40.jpg)
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 patternsConsider 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.
![Page 41: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/41.jpg)
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.
![Page 42: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/42.jpg)
MyOfficeApplicationmyMethod()
Prototype: Example
PurchaseOrderDocument clone()
InvoiceDocument clone()
Documentclone()
_documentPrototype
Client
. . . . .
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 43: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/43.jpg)
MyOfficeApplicationmyMethod()
Prototype: Example
PurchaseOrderDocument clone()
InvoiceDocument clone()
Documentclone()
documentPrototypeS
Client
Customerclone()
CashCustomer clone()
CreditCustomer clone()
customerPrototypeS
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 44: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/44.jpg)
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 Customer it is being executed with
. . . .
![Page 45: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/45.jpg)
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.
![Page 46: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/46.jpg)
abstract class Document
{ protected Document clone();}
Prototype Design Pattern: Typical
Code 2/2
. . . .
![Page 47: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/47.jpg)
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.
![Page 48: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/48.jpg)
Abstract Factory
Applied to Encounter
Area
Level3Area
Level3FactorygetArea()getAreaConnection()
EnvironmentFactorygetArea()buildConnection()
EncounterEnvironment
Client1..n
. . . . .
![Page 49: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/49.jpg)
Abstract Factory Applied to Encounter
Area
Level2Area
Level2FactorygetArea()getAreaConnection()
EncounterAreaConnection
EnvironmentFactorygetArea()getConnection()
EncounterEnvironmentgetArea()getConnection()incrementLevel()
Level2AreaConnection
Client
«create» «create»
1..n
1..n
Area getArea() { return envFactory.getArea();}
envFactory
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 50: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/50.jpg)
Abstract Factory
Applied to Encounter
Area
Level2AreaLevel1Area Level3Area
Level1FactorygetArea()getAreaConnection()
Level2FactorygetArea()getAreaConnection()
Level3FactorygetArea()getAreaConnection()
EncounterAreaConnection
EnvironmentFactorygetArea()getConnection()
EncounterEnvironment
Level1AreaConnection Level2AreaConnection
Client
Level3AreaConnection
«create»
1..n
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 51: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/51.jpg)
NonLeafNode
The Basis for Composite & Decorator Structures
Component
“every object involvedis 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.
![Page 52: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/52.jpg)
NonLeafNodedoIt()
Composite & Decorator Structures
etc.
component
ComponentdoIt()
LeafdoIt()
TypeANonLeafNodedoIt()
TypeBNonLeafNodedoIt()
Composite: 1..nClient
Decorator: 1
for all elements e in componente.doIt()
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 53: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/53.jpg)
Architecture of Encounter: Class Model
EncounterCharacters
EncounterGame
EncounterCast
EncounterGame
EncounterEnvironment
EncounterEnvironment
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 54: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/54.jpg)
Adapter Design Pattern
Financialamount() Principal
computeValue()
Client
Legacy systemAdaptationApplication
![Page 55: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/55.jpg)
FinancialAdapteramount()
Adapter Design Pattern
{ legacyAdaptee.computeValue(); }
Financialamount() Principal
computeValue()
Client
Legacy systemAdaptation
legacyAdaptee
Application
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 56: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/56.jpg)
Proxy Design Pattern After Gamma et al BaseActiveClass
expensiveMethod()cheapMethod()
RealActiveClassexpensiveMethod()
cheapMethod()
ProxyexpensiveMethod()
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.
![Page 57: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/57.jpg)
The Iterator Design Pattern
iterator:Iterator
element:Element
Aggregate of Elementobjects
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.
![Page 58: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/58.jpg)
The Mediator Design Pattern
Encapsulates behavior among objects of a class so that they needn’t refer to each other.
Mediator Colleague
ConcreteMediator
ConcreteColleague1 ConcreteColleague2
Gamma et al
![Page 59: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/59.jpg)
The Mediator Design Pattern
EngagementDisplayItem
Mediator Colleague
ConcreteMediator ConcreteColleague1 ConcreteColleague2
SetQualitiesDisplay
… Applied to Encounter
QualListDisp QualValueDisp
EncounterDisplay
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 60: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/60.jpg)
7. Standards, notation and tools for detailed design
![Page 61: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/61.jpg)
IEEE 1016-1987 Software Design Document Table of Contents (Reaffirmed 1993)
1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations2. References3. 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 dependencies5. 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 description6. 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
![Page 62: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/62.jpg)
/**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.
![Page 63: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/63.jpg)
/**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.
![Page 64: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/64.jpg)
8. Effects on projects of completing detailed designs
![Page 65: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/65.jpg)
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 ProjectUp-to-Date
After Completing Detailed Design
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 66: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/66.jpg)
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 LOC4. 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.
![Page 67: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/67.jpg)
CATEGORY
Very small
Small Medium LargeVery large
METHOD
TYPE
Calcula-tion
2.34 5.13 11.25 24.66 54.04
Data 2.60 4.79 8.84 16.31 30.09
I/O 9.01 12.06 16.15 21.62 28.93
Logic 7.55 10.98 15.98 23.25 33.83
Set-up 3.88 5.04 6.56 8.53 11.09
Text 3.75 8.00 17.07 36.41 77.67
Table 6.1 Lines of code (Humphrey)
![Page 68: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/68.jpg)
Normal Distribution of “Medium”, “Small” etc.
-2
Standard deviations from the mean
VS
7%
Approximate percentage of methods classified with this description
![Page 69: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/69.jpg)
Normal Distribution of “Medium”, “Small” etc.
0 1-1 2-2
Standard deviations from the mean
MS L
VS VL
38%24% 24% 7%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.
![Page 70: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/70.jpg)
9. Quality in detailed designs
![Page 71: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/71.jpg)
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.
![Page 72: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/72.jpg)
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
– generalityenables design of similar applications?
– expandabilityenables enhancements?
– efficiencyspeed, 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.
![Page 73: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/73.jpg)
Severity Description
UrgentFailure causes system crash, unrecoverable data loss; or jeopardizes personnel
HighCauses impairment of critical system functions, and no workaround solution does exist
MediumCauses 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.
![Page 74: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/74.jpg)
Severity Description
Major Requirement(s) not satisfied
Medium Neither major nor trivial
Trivial A 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.
![Page 75: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/75.jpg)
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.
![Page 76: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/76.jpg)
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.
![Page 77: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/77.jpg)
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.
![Page 78: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/78.jpg)
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.
![Page 79: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/79.jpg)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
IF aQuality is not recognizedLog error to log file Inform user qualities unchanged
ELSE IF aQualityValue out of bounds
Log error to log fileInform user qualities unchanged
ELSESet the stated quality to aQualityValueReduce the remaining qualities, ... retaining their mutual proportion, ... making the sum of qualities unchanged
ENDIFENDIF
Pseudocodefor Inspection1
2345678910
setQuality() should be mentioned
Lacks detail on how to allocate the remaining quality values
Make these preconditions; don’t check.
![Page 80: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/80.jpg)
10. Summary
![Page 81: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/81.jpg)
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.
![Page 82: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/82.jpg)
Case Study
![Page 83: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/83.jpg)
Detailed Design of RolePlayingGame Package
RPGamehandleEvent()
GameStatehandleEvent()state
{ state.handleEvent(); }
. . . .
![Page 84: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/84.jpg)
Detailed Design of RolePlayingGame Package
RPGamehandleEvent()
GameStatehandleEvent()stateS
{ stateS.handleEvent(); }
RPGMouseEventListenermouseEnter()
MouseListener
{ rPGameS.handleEvent(); }
rPGameS
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 85: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/85.jpg)
eventTarget
2. mouseClicked()
User
1. mouseaction
3. handleEvent( Event )
:RPGame :GameState
4. handleEvent( Event)
:RPGMouseEventListener
Sequence Diagram forHandling Mouse Events
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 86: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/86.jpg)
RPG Video Game Architecture Packages -- showing domain classes only
«framework package»
«framework package»
«framework package»
«framework package»
«application package»
Characters
GameArtifacts
RolePlayingGame
GameEnvironment
EncounterEnvironment
PlayerCharacter
EncounterCharacter
«application package»
ForeignCharacter
EncounterCharacters «application package»
EncounterGame Engagement
EngagementDisplay
EncounterGame
Area
PlayerQualityWindow
«uses»
«uses»
«uses»
EncounterAreaConnection
ConnectionHyperlink
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 87: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/87.jpg)
EncounterGameDisplays
Detailed Design of EncounterGameDisplays
Sub-package
EngagementDisplay
PreparinghandleEvent()
ReportinghandleEvent()
SetQualityDisplay
EncounterDisplayItem
QualListDispl
QualValueDispl
SetQualValueDispl
EncounterCast
EncounterDisplay
MouseListener
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 88: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/88.jpg)
:EngagementDisplay
2. mouseClicked()
User
1. hit dismissbutton
:RPGMouseEventListener
3. handleEvent()
:EncounterGame
:ReportingEncounter
4. handleEvent()
5. setVisible( false )
6. setState(new Waiting())
Sequence Diagram forDismissing Engagement
Display
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
![Page 89: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/89.jpg)
:PlayerQualityWindow
2. mouseClicked()
User
1. hit dismissbutton
:RPGMouseEventListener
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.
![Page 90: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/90.jpg)
:AreaConnectionHyperlink
2. mouseClicked()
User
1. hit areaconnectionhyperlink
:RPGMouseEventListener
: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
![Page 91: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/91.jpg)
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.
![Page 92: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/92.jpg)
EncounterEnvironment Package
GameEnvironment
GameCharacterGameArea
GameAreaConnection
. . . .
![Page 93: 6. DESIGN II: DETAILED DESIGN. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap:](https://reader035.fdocuments.us/reader035/viewer/2022062308/56649dde5503460f94ad779c/html5/thumbnails/93.jpg)
EncounterEnvironment Package
GameEnvironment
GameCharacterGameArea
EncounterEnvironment
Area
EncounterEnvironment
GameAreaConnection
EncounterAreaConnection
ConnectionHyperlink
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.