Design Ii: Detailed Design

6.
DESIGN II:
DETAILED DESIGN
Develop Software Engineering
Architecture Roadmap:
- see chapter 5 Chapter 6 Focus
Identify Perform Detailed Design

corporate - apply design patterns
practices - accommodate use cases
supply methods
- exploit libraries (Java, Swing…)
Plan - describe methods where required
project - develop detailed object models
- dev. detailed logic (pseudo-code)
Analyze Maintain
requirements
Integrate
Design & test system
Implement Test units
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Chapter Learning Goals
• Understand how design patterns
describe some detailed designs
• Specify classes and functions completely
• Specify algorithms
– use flowcharts
– use pseudocode
1. Introduction to Detailed Design
Objective: To fully prepare for implementation of a
system that meets requirements.
Outcomes: (1) blueprints (models),
(2) associated details (documentation),
(3) detailed implementation plan for construction,
integration and testing
Relating Use Cases, Architecture, & Detailed Design
1. Use case -- 2. Domain 3. Architecure

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

(part of classes (not specifically required) Cable
requirements)
Auto
“Cars should
be able to Road Pylon
travel from the
top of Smith (added for
detailed design) Support use case
Hill at 65 mph, Auto
travel in a Guardrail Cable
straight line, 4. Detailed Road
and arrive at Design
Jones Hollow Smith
within 3 Hill Pylon
minutes.” Jones Hollow
• What is the difference between high-level
(architectural) design and detailed design?
• High-Level Design
• Detailed Design
1. Begin with architectural models -- see chapter 5 Typical
• class model: domain & architectural classes Roadmap
• overall state model* for
• overall data flow model* Detailed
• use case model Design
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
For each class ... 4. Specify class invariants* -- section 3.1
For each method ... 5. Specify methods with pre- and post-conditions,
flowcharts* & pseudocode* -- sections 3 and 4
For each unit ... 6. Sketch unit test plans -- see chapter 8
7. Inspect test plans & design -- section 9
* if applicable
8.Release for implementation
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
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 section 9)
5. Rework as a result of inspections
6. Conduct post mortem and write out lessons learned
Unified Software Development Process: Design
U. P. Term Inception Elaboration Construction Transition
Requirements
1* Jacobson et al:
Analysis
2
3 Design
Implemen-
tation
Test
(Jacobson et al) Prelim. Iter. Iter. Iter. Iter. Iter. ….. Iter.
…..
iterations #1 #n #n+1 #m #m+1 #k
*Key: terminology “Detailed
used in this book 1 = “Requirements” 2 = “Achitecture” 3= design”
Analysis Design 1/2
After Jacobson
1. Conceptual & abstract 1. Concrete: et al: USDP
implementation
blueprint
2. Applicable to several 2. Specific for an
designs implementation
3. «control», «entity» & 3. No limit on class
«boundary» class stereotypes
stereotypes
4. Less formal 4. More formal
5. Less expensive to 5. More expensive to
develop develop (~ 5 times)
Analysis Design 2/2 After Jacobson
et al: USDP
6. Outlines the design 6. Manifests the design

7. Emerges from (architecture one view)
conceptual thinking 7. May use tools (e.g. visual,
8. Flexibility still exists round-trip engineering)
for process 8. Maintaining estabished
modifications process is a high priority
9. Relatively 9. Constrained by the
unconstrained analysis & architecture
10. Less focus on 10. More focus on seq. diag.
sequence diagrams
11. Many layers
11. Few layers
Designing Against Interfaces
Client code Used code
BillingClient Customer
listCustomers() bill()
billCustomers() printAccounts()
-- written in terms of
Customer (not Abstract layer
specific types of
Customer) RegularCustomer
bill()
printAccounts()
Concrete (non-abstract) layer

Reusing Components
• Reusable functionality is becoming more
convenient to locate and use
– Microsoft .NET freamework
– COM objects / OMG’s CORBA
– Javascript libraries
– JavaBeans (servlet code)
– Ruby on Rails
– PHP libraries
– GitHub code
– Python libraries
2. Sequence and data flow diagrams
for detailed design
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)
Refine Models for Detailed Design
2/2: Data Flow Diagrams
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
Requirements: Sequence Diagram for
Engage Foreign Character Use Case
:Encounter freddie: :Engagement :Engagement
Game Foreign Display
Character
:Player
Character
1.1 create; display
1.2 create
2.1 execute
2.2 change quality values
3.1 Display result

3.2 create
:Encounter :Encounter freddie: engagement:
game Cast Foreign Engagement
Character
1.1 displayForeignChar()
1.2 display() :Engagement

Display
1.3 new Engagement()
2. execute() :Player’s
main
2.1 setPlayerQuality() character
2.2 setQuality()
2.3 setForeignQuality()
3.1 new EngagementDisplay()
2.4 setQuality()
3.2 displayResult()
Design: Sequence Diagram for Encounter Foreign Character

Use Case
Classes of the EncounterForeignCharacter Use Case
Engagement EngagementDisplay
execute() displayResult()
EncounterGame
PlayerCharacter
EncounterCast setQuality()
displayForeignChar()
setPlayerQuality()
ForeignCharacter
setForeignQuality()
setQuality()
Detailed Data Flow Diagram for a Banking
Application
customer
Account. info Customer.
User getDetails()
getDeposit()
Account
Cus-
tomer
screen unacceptable
template local ATM users
log
Deposit-
screen. Account.
display() getPass-
Account. word()
status verifyPass- pass-
word() word
CRC Cards
• Class Responsibility and Collaboration

cards provide an effective technique for exploring
the possible ways of allocating responsibilities to
classes and the collaborations that are necessary to
fullfil the responsibilities.
• A helpful demonstration:
– https://www.youtube.com/watch?v=5IpsMwxL
37k
Design Refinement with CRC Cards
• Exercise:
• Use Case: You are registering for a new
course in astronomy. You require
permission from the instructor and you must
interact with the registrars office to signup
and pay for the course.
• Develop the classes and responsibilities
using CRC cards
3. Specifying classes and functions
Specify A Class
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 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
Classes at Detailed Design
Data type
Range
Default value
Security issues Canister Class name
+ numCanisters: int
- numWafers: int Attribute: type
- size: float
+: visible + display()
from without - getNumSlotsOpen() Operations
+ setStatus()
Interface specs Responsibilities:
Place for
Functional -- describes each comments
details canister undergoing
Invariants fabrication Instance details
4. Specifying algorithms
Flowchart
Example
N Parameter & Y
for setName() settings make Nominal path
sense?
Set _name to
“defaultName"
N Parameter Y
protected final void setName( String aName ) name too
{ long?
// 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()");
}
Set _name Truncate
else
// Truncate if aName too long to parameter name
if( aName.length() > maxNumCharsInName() )
_name = new String
( aName.getBytes(), 0, maxNumCharsInName() );
else // assign the parameter name
_name = new String( aName );
} Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
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
See later
section tbd for abort with "no supervisor approval for unusual
inspection
results of this duration" message ENDIF ENDIF
pseudocode
....
//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 Pseudocode
int supervisorMicrosecsApproval = Extraction
getApprovalOfSuperForLongExposure();
//p IF no supervisor approval
if( supervisorMicrosecsApproval <= 0 )
throw ( new SupervisorMicrosecsApprovalException() );
.........
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 decrease overall costs
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
5. Design Patterns II: Techniques of
detailed design
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(?)
User Interface Design
• System users often judge a system by its
interface rather than its functionality
• A poorly designed interface can cause a user
to make catastrophic errors
• Poor user interface design is the reason why
so many software systems are never used
User-Centred design
• User-centred design is an approach to UI
design where the needs of the user are
paramount and where the user is involved in
the design process
• UI design always involves the development
of prototype interfaces
• See UI_design.ppt
7. Standards, notation and tools for
detailed design
IEEE 1016-1987 Software Design Document Table of Contents (Reaffirmed 1993)
1. Introduction 4. Dependency description
1.1. Purpose Architecture 4.1 Intermodule dependencies
1.2. Scope 4.2 Interprocess dependencies
1.3.beDefinitions,
Can acronyms
replaced with: 4.3 Data dependencies
& abbreviations
6.1 Class#1 detailed design 5. Interface description
2. References 5.1 Module interface
6.1.1 Attributes
3. Decomposition description 5.1.1 Module 1 description
3.1.6.1.2 Methods
Module decomposition 5.1.2 Module 2 description
6.1.3 Instance1details
3.1.1 Module description 5.2 Process interface
6.1.4. Other: 2 description
3.1.1 Module 5.2.1 Process 1 description
- UI details
3.2 Concurrent (if applicable)
process 5.2.2 Process 2 description
decomposition 6. Detailed design
3.2.1 Process 1 description 6.1 Module detailed design
3.2.2 Process 2 description 6.1.1 Module 1 detail
3.3 Data decomposition 6.2.2 Module 2 detail
3.3.1 Data entry 1 description 6.2 Data detailed design
3.3.2 Data entry 2 description 6.2.1 Data entity 1 detail
6.2.2 Data entity 2 detail
8. Effects on projects of completing
detailed designs
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 Bring the Project
• inspection Up-to-Date
• change After Completing
– defect summary Detailed Design
• number remaining open, found at detailed design, closed at
detailed design
• where injected; include previous phases & detailed design stages
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.
9. Quality in detailed designs
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.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. ‡ See chapter 1 for inspection procedures.
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?
Inspect
– efficiency Detailed
speed, storage Designs 2 of 2
– 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
Inspection for Defects
• Identify defect and its type
• Specify its severity (two methods following slides)
• Identify the source of the defect – so that
the defect does not occur in another project
…
• At another time, usually one person works
on a resolution to defect
Severity Description
Failure causes system crash, unrecoverable data

Urgent
loss; or jeopardizes personnel
Causes impairment of critical system functions,

High
and no workaround solution does exist
Causes impairment of critical system functions,

Medium
though a workaround solution does exist
Low Causes inconvenience or annoyance

Table 6.2 IEEE 1044.1
None None of the above Severity classification
Table 6.3 Defect severity classification using Triage
Severity Description
Major Requirement(s) not satisfied
Medium Neither major nor trivial
Trivial A defect which will not affect

operation or maintenance
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)
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.)
• [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
• [PS] Suspect performance problem (inefficient
logic, data structure)
• [XDOC, PS] Interoperability problem (not
compatible with other software or component)
• [XDOC, PS] Standards conformance problem
Pseudocode
1 IF aQuality is not recognized for Inspection
2 Log error to log file
3 Inform user qualities unchanged
4 ELSE setQuality()
5 IF aQualityValue out of bounds should be
6 Log error to log file mentioned
7 Inform user qualities unchanged
8 ELSE
9 Set the stated quality to aQualityValue
10 Reduce the remaining qualities,
Make these ... retaining their mutual proportion,
preconditions; ... making the sum of qualities unchanged
don’t check. ENDIF
Lacks detail on how to allocate
ENDIF the remaining quality values
Case Study
Detailed Design of RolePlayingGame Package
RPGame GameState
handleEvent() state handleEvent()
{ state.handleEvent(); }
....
Detailed Design of RolePlayingGame Package
MouseListener
{ rPGameS.handleEvent(); }
rPGameS RPGMouseEventListener
mouseEnter()
RPGame GameState
handleEvent() stateS handleEvent()
{ stateS.handleEvent(); }
User eventTarget :RPGame :GameState
:RPGMouseEventListener
1. mouse
action
2. mouseClicked()
3. handleEvent
( Event )
4. handleEvent
( Event)
Sequence Diagram for

Handling Mouse Events
RPG Video Game Architecture Packages --
showing domain classes only RolePlayingGame
Characters «framework package»
«framework package» «uses»

EncounterGame
EncounterCharacters «uses» «application package»
«application package» EncounterGame Engagement

EngagementDisplay
EncounterCharacter
GameEnvironment
PlayerCharacter «framework package»
ForeignCharacter
EncounterEnvironment «uses»
PlayerQualityWindow
«application package»
Area EncounterAreaConnection
GameArtifacts
«framework package» ConnectionHyperlink
MouseListener
EncounterGameDisplays
EncounterDisplayItem EncounterCast
EncounterDisplay Detailed Design of

EncounterGameDisplays
Sub-package
QualListDispl SetQualValueDispl
QualValueDispl
EngagementDisplay Reporting
handleEvent()
SetQualityDisplay Preparing
handleEvent()
Sequence Diagram for
Dismissing Engagement
User :EngagementDisplay Display
1. hit :RPGMouse
dismiss EventListener :ReportingEncounter
button
2. mouseClicked() :EncounterGame
3. handleEvent()
4. handleEvent()
5. setVisible( false )

6. setState
(new Waiting()) 
Sequence Diagram for Player Completes Setup
User :PlayerQualityWindow :SettingUp
1. hit :RPGMouse
dismiss EventListener
button
2. mouseClicked() :EncounterGame
3. handleEvent()
4. handleEvent()

6. setState
(new Waiting()) 
User :AreaConnectionHyperlink :EncounterCast :Waiting
1. hit :RPGMouse :EncounterEnvironment
area
EventListener
connection
hyperlink :EncounterGame
2. mouseClicked()
3. handleEvent()
4. handleEvent()

6. displayArea()
7. displayPlayerCharacter()
If foreign character present
Sequence Diagram 8. displayForeignCharacter()
for Player Moves to 9. setState

Adjacent Area (new Engaging())
Detailed Design of EncounterCharacters Package
Characters
«framework package»
GameCharacter
EncounterCharacters
«application package»
EncounterCharacter
PlayerCharacter
«facade»
EncounterCast
ForeignCharacter
EncounterEnvironment Package
GameEnvironment
GameArea GameCharacter
GameAreaConnection
....
EncounterEnvironment Package
GameEnvironment
GameArea GameCharacter
GameAreaConnection
Area
EncounterAreaConnection
EncounterEnvironment ConnectionHyperlink
EncounterEnvironment

Design Ii: Detailed Design

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Design Ii: Detailed Design

Uploaded by

Copyright:

Available Formats

6.

Identify Perform Detailed Design

• Specify classes and functions completely

1. Use case -- 2. Domain 3. Architecure

1. Use case 2. Domain 3. Architecure

2. Introduce classes & design patterns* which connect the

1. Prepare for a detailed design kick-off meeting.

6. Outlines the design 6. Manifests the design

Concrete (non-abstract) layer

2.2 change quality values

3.1 Display result

1.2 display() :Engagement

Design: Sequence Diagram for Encounter Foreign Character

• Class Responsibility and Collaboration

1. Gather the attributes listed in the SRS.

FOR number of microseconds supplied by operator

 May decrease overall costs

 Introduces error possibilities in translating to code

 May require tool to extract pseudocode and

1. Start with the list of methods

2. Ensure each architecture module is expanded.

4. Ensure the design fulfills its required functions

Failure causes system crash, unrecoverable data

Causes impairment of critical system functions,

Causes impairment of critical system functions,

Low Causes inconvenience or annoyance

Major Requirement(s) not satisfied

Medium Neither major nor trivial

Trivial A defect which will not affect

• [PS] Logic problem

• [XDOC, PS] Data problem (sensor data

• [XDOC, PS] Document quality problem

• [XDOC, PS] Enhancement (change in

• [XDOC, PS] Failure caused by a previous fix

• [PS] Suspect performance problem (inefficient

logic, data structure)

• [XDOC, PS] Interoperability problem (not

compatible with other software or component)

• [XDOC, PS] Standards conformance problem

Sequence Diagram for

«framework package» «uses»

«application package» EncounterGame Engagement

EncounterDisplay Detailed Design of

User :PlayerQualityWindow :SettingUp

If foreign character present

Sequence Diagram 8. displayForeignCharacter()

for Player Moves to 9. setState

You might also like