Você está na página 1de 93

6.

DESIGN II: DETAILED DESIGN

Develop Architecture - see chapter 5

Software Engineering Roadmap: Chapter 6 Focus

Identify corporate practices Plan project


Analyze requirements

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

Maintain Integrate & test system Implement Test units

Design
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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Introduction to Detailed Design

Relating Use Cases, Architecture, & Detailed Design


1. Use case -analysis 2. Domain classes Auto Road Pylon 3. Architecure Cable

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.

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 Auto Road
(added for detailed design)

3. Architecure
(not specifically required)

Cable

Pylon Support use case Guardrail Cable

Auto

4. Detailed Design
Smith Hill

Road

Pylon
Jones Hollow

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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 .....

1. Begin with architectural models -- see chapter 5 class model: domain & architectural classes overall state model* overall data flow model* use case model

Typical Roadmap for Detailed 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 ...
* if applicable

6. Sketch unit test plans -- see chapter 8


7. Inspect test plans & design -- section 9 8.Release for implementation

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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.

Organize the Team for Detailed Design 2/2 2. Hold the kick-off meeting
revise as a group if not

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 Dont 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

Write out the conclusions and copy/e-mail every member Decide how and when the results are to be reviewed

Request time estimates to design lead by a fixed date

3. Update the documentation set

more detailed schedule with modules & inspections see figure TBD below

4. Inspect the detailed designs


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.

Unified Software Development Process: Design


U. P. Term 1* 2 3 Requirements
Jacobson et al:

Inception Elaboration

Construction

Transition

Analysis Design Implementation Test


(Jacobson et al) Prelim. Iter. iterations #1 Iter. Iter. #n #n+1 .. Iter. #m Iter. .. #m+1 Iter. #k

*Key: terminology
used in this book

1 = Requirements

2 = Achitecture

3=

Detailed design

Analysis
1. Conceptual & abstract

Design
1. Concrete: implementation blueprint 2. Specific for an implementation

1/2
After Jacobson et al: USDP

2. Applicable to several designs

Analysis
1. Conceptual & abstract

Design

1/2
After Jacobson et al: USDP

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
6. Outlines the design

Design

2/2

After Jacobson et al: USDP

6. Manifests the design (architecture one view)

7. Emerges from conceptual thinking 8. Lower priority for inprocess maintenance

7. May use tools (e.g. visual, round-trip engineering) 8. Higher priority for inprocess maintenance

Analysis
6. Outlines the design

Design

2/2

After Jacobson et al: USDP

6. Manifests the design (architecture one view)

7. Emerges from conceptual thinking


8. Lower priority for inprocess maintenance 9. Relatively unconstrained

7. May use tools (e.g. visual, round-trip engineering)


8. Higher priority for inprocess maintenance 9. Constrained by the analysis & architecture

10. Less focus on sequence diagrams


11. Few layers

10. More focus on sequence


11. Many layers

Designing Against Interfaces


Client code BillingClient
listCustomers() billCustomers() -- written in terms of Customer (not specific types of Customer)

Used code Customer


bill() printAccounts()

Abstract layer
RegularCustomer
bill() printAccounts()

Concrete (non-abstract) layer


Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

Refine Models for Detailed Design 2/2: Data Flow Diagrams


1. Gather data flow diagrams (DFDs) constructed for detailed requirements and/or architecture (if any). 2. Introduce additional DFDs, if necessary, to explain data and processing flows. 3. Indicate what part(s) of the other models the DFDs corresponds to.
e.g., the following DFD is for each Account object

4. Provide all details on the DFDs


indicate clearly the nature of the processing at each node indicate clearly the kind of data transmitted expand processing nodes into DFDs if the processing description requires more detail
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

:Encounter :Encounter game Cast


1.1 displayForeignChar()

freddie: Foreign Character

engagement: Engagement :Engagement Display :Players main character

1.2 display() 1.3 new Engagement() 2. execute() 2.1 setPlayerQuality() 2.2 setQuality() 2.3 setForeignQuality() 2.4 setQuality()

3.1 new EngagementDisplay()

3.2 displayResult()

Sequence Diagram for Encounter Foreign Character Use Case


Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Classes of the EncounterForeignCharacter Use Case


Engagement execute() EngagementDisplay displayResult()

EncounterGame

EncounterCast displayForeignChar() setPlayerQuality() setForeignQuality()

PlayerCharacter setQuality() ForeignCharacter setQuality()

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Detailed Data Flow Diagram for a Banking Application

Account. getDeposit()

Customer

User

Customer. getDetails()

.....

Detailed Data Flow Diagram for a Banking Application

Expand details .. User Customer. getDetails()

Account. getDeposit()

Customer

Account screen template Depositscreen. display() status Customer local log

unacceptable ATM users


Account. getPassword()

Account. verifyPassword()

Password

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

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 methods pre-conditions (what it assumes).
4. State the methods 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.

Classes at Detailed Design


Canister + numCanisters: int - numWafers: int - size: float + display() - getNumSlotsOpen() + setStatus() Responsibilities: -- describes each canister undergoing fabrication
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Class name Attribute: type

+: visible from without

Operations

Place for comments

Specifying Functions: withdraw() in Account

Invariant of withdraw():
availableFundsI = max( 0, balanceI ) .....

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

Specifying Functions: withdraw() in Account Invariant of withdraw(): availableFundsI = max( 0, balanceI )


xI denotes an attribute; xP denotes a function parameter; x' is the value of x after execution; X denotes a class constant

Precondition*:
withdrawalAmountP >= 0 AND

balanceI - withdrawalAmountP
>= OVERDRAFT_MAX Postcondition*:

balanceI' = balanceI - withdrawalAmountP


*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.

4. Specifying algorithms

Flowchart Example

Parameter & settings make sense?

Y
Nominal path

Set _name to defaultName"

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()"); } Set _name Truncate else to parameter name // 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 ); } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Parameter name too long?

An Architecture for Chaining


static factList static ruleBase

Fact
content addFact() proveBack()

consequent

Rule
addRule() proveAntecedents() forwardChain()

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.

soughtFact in factList?

Flowchart for soughtFact.proveBack( ruleBase )

Nominal path

Another rule R with soughtFact as consequent?

Apply R.proveAntecedents()

Succeede d?

Report TRUE

Report FALSE

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 section tbd for inspection results of this pseudocode

abort with "no supervisor approval for unusual duration" message ENDIF ENDIF

....

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 section tbd for inspection results of this pseudocode

Pseuodocode Example

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

//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

Pseudocode Extraction

if( supervisorMicrosecsApproval <= 0 )


throw ( new SupervisorMicrosecsApprovalException() ); .........
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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.

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.

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(?)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Factory: Example
Factory design pattern

Client

BiologicalCell getNewCellObject()

AnimalCell PlantCell getNewCellObject() getNewCellObject()


Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Prototype: Example

Client
_documentPrototype

MyOfficeApplication myMethod()
.....

Document clone()

PurchaseOrderDocument clone()

InvoiceDocument clone()

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Prototype: Example

Client

MyOfficeApplication myMethod()

documentPrototypeS

Document clone()

Customer customerPrototypeS clone() CreditCustomer clone() InvoiceDocument clone()

CashCustomer clone()

PurchaseOrderDocument clone()

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Prototype Design Pattern: Typical Code 1/2

public class MyOfficeApplication { 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

public class MyOfficeApplication

private static Document documentPrototypeS;


private static Customer customerPrototypeS; public MyOfficeApplication

Prototype Design Pattern: Typical Code 1/2

( Document dProtopypeP, Customer cPrototypeP )


This class is unaware of which type (subclass) of Document or Customer it is being executed with

documentPrototypeS = dProtopypeP;

customerPrototypeS = cPrototypeP; }
public myMethod { . . . . // Need a new Document object: Document d = documentPrototypeS.clone(); . . . . // Need a new Customer object: Customer c = customerPrototypeS.clone(); . . .

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

abstract class Document { } protected Document clone();

Prototype Design Pattern: Typical Code 2/2

....

abstract class Document

{ protected Document clone(); } public class InvoiceDocument { .... protected Document clone() {. . . . return new InvoiceDocument(); }

Prototype Design Pattern: Typical Code 2/2


Customer has an equivalent hierarchy of classes implementing clone()

public class PurchaseOrderDocument { .... protected Document clone() {. . . . return new PurchaseOrderDocument(); }
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Client 1..n
EncounterEnvironment Area EnvironmentFactory getArea() buildConnection()

Abstract Factory Applied to Encounter


.....

Level3Area

Level3Factory getArea() getAreaConnection()

Client

Area getArea() { return envFactory.getArea(); } EncounterEnvironment getArea() getConnection() incrementLevel() 1..n EnvironmentFactory getArea() getConnection()

envFactory

EncounterAreaConnection

1..n

Area

Level2Area
create

Level2AreaConnection
create

Abstract Factory Applied to Encounter

Level2Factory getArea() getAreaConnection()

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Client 1..n
EncounterEnvironment Area EnvironmentFactory getArea() getConnection()

Abstract Factory Applied to Encounter

EncounterAreaConnection Level1Area Level2Area Level3Area

Level1AreaConnection
create

Level2AreaConnection

Level3AreaConnection

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.

The Basis for Composite & Decorator Structures non-leaf node leaf node

Component
every object involved is a Component object non-leaf nodes have one or more components

NonLeafNode
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Composite & Decorator Structures


Client Component doIt()
Composite: 1..n

Decorator: 1

for all elements e in component e.doIt()

Leaf doIt()

NonLeafNode doIt()

component

TypeANonLeafNode doIt()

TypeBNonLeafNode doIt()

etc.

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Architecture of Encounter: Class Model

EncounterGame

EncounterGame
EncounterCharacters

EncounterCast
EncounterEnvironment

EncounterEnvironment
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Adapter Design Pattern


Application Adaptation Legacy system

Financial
amount()

Principal
computeValue()

Client

Adapter Design Pattern


Application Adaptation Legacy system

Financial
amount()

Principal
computeValue()

Client

FinancialAdapter
amount()

legacyAdaptee

{ legacyAdaptee.computeValue(); }
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Proxy Design Pattern After Gamma et al


Client
After Gamma et al

BaseActiveClass expensiveMethod() cheapMethod()

RealActiveClass _realActiveObject Proxy expensiveMethod() expensiveMethod() cheapMethod() cheapMethod()

... if ( _realActiveObject == null ){ // never referenced _realActiveObject = getRealActiveObject(); _realActiveObject.expensiveMethod(); }


Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Iterator Design Pattern


element: Element
After first() executes, iterator references this object.

Key: Intended sequence of Element objects

iterator: Iterator

Aggregate of Element objects Before next() executes, iterator references this object.

After next() executes, iterator references this object.

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Mediator Design Pattern


Encapsulates behavior among objects of a class so that they neednt refer to each other.

Mediator

Colleague

ConcreteColleague1 ConcreteColleague2

ConcreteMediator
Gamma et al

The Mediator Design Pattern


Mediator
ConcreteMediator
Elena
User Interface for Status

Colleague

ConcreteColleague1 ConcreteColleague2
Current life points: 56

EncounterDisplay
Strength Endurance Endurance Intelligence Patience Value

EngagementDisplayItem
Applied to Encounter

16.18
QualListDisp QualValueDisp

SetQualitiesDisplay
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

7. Standards, notation and tools for detailed design

IEEE 1016-1987 Software Design Document Table of Contents (Reaffirmed 1993)

1. Introduction 1.1. Purpose Architecture 1.2. Scope 1.3. Definitions, acronyms & abbreviations 2. References 3. Decomposition description 3.1. Module decomposition 3.1.1 Module 1 description 3.1.1 Module 2 description 3.2 Concurrent process decomposition 3.2.1 Process 1 description 3.2.2 Process 2 description 3.3 Data decomposition 3.3.1 Data entry 1 description 3.3.2 Data entry 2 description

4. Dependency description 4.1 Intermodule dependencies 4.2 Interprocess dependencies 4.3 Data dependencies 5. Interface description 5.1 Module interface 5.1.1 Module 1 description 5.1.2 Module 2 description 5.2 Process interface 5.2.1 Process 1 description 5.2.2 Process 2 description

6. Detailed design
6.1 Module detailed design 6.1.1 Module 1 detail 6.2.2 Module 2 detail 6.2 Data detailed design 6.2.1 Data entity 1 detail 6.2.2 Data entity 2 detail

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;

/** 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() ..

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Java Source with Javadoc 2/2


/** 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 ) ..
..
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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 inspection change

defect summary

Bring the Project Up-to-Date After Completing Detailed Design

number remaining open, found at detailed design, closed at detailed design where injected; include previous phases & detailed design stages
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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 Humphrys table below

3. Sum the LOC 4. Covert LOC to person-hours


use personal conversion factor if possible
otherwise use published factor

5. Ensure that your estimates of method sizes and time will be compared and saved at project end.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

CATEGORY

Table 6.1 Lines of code (Humphrey)

Very small

Small

Medium

Large

Very large

Calculation

2.34

5.13

11.25

24.66

54.04

Data

2.60

4.79

8.84

16.31

30.09

METHOD TYPE

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

Normal Distribution of Medium, Small etc.


Approximate percentage of methods classified with this description 7%
VS
-2

Standard deviations from the mean

Normal Distribution of Medium, Small etc.


Approximate percentage of methods classified with this description 7%
VS
-2 -1 0 1

24% 38% 24%


VL
2

7%

Standard deviations from the mean


Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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?

efficiency
speed, storage

Inspect Detailed 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: dont postpose
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Severity

Description

Urgent

Failure causes system crash, unrecoverable data loss; or jeopardizes personnel


Causes impairment of critical system functions, and no workaround solution does exist Causes impairment of critical system functions, though a workaround solution does exist Causes inconvenience or annoyance

High

Medium

Low 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.

Table 6.3 Defect severity classification using triage

Severity
Major Medium

Description
Requirement(s) not satisfied Neither major nor trivial

Trivial

A defect which will not affect operation or maintenance

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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.

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.

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.

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.

1 IF aQuality is not recognized Log error to log file 2 Inform user qualities unchanged 3 4 ELSE setQuality() IF aQualityValue out of bounds should be 5 mentioned Log error to log file 6 Inform user qualities unchanged 7 ELSE 8 Set the stated quality to aQualityValue 9 Reduce the remaining qualities, 10 ... retaining their mutual proportion, Make these ... making the sum of qualities unchanged preconditions; dont check. ENDIF Lacks detail on how to allocate ENDIF the remaining quality values
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Pseudocode for Inspection

10. Summary

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.

Case Study

Detailed Design of RolePlayingGame Package

RPGame
handleEvent()
state

GameState
handleEvent()

{ state.handleEvent(); }

....

Detailed Design of RolePlayingGame Package


MouseListener
{ rPGameS.handleEvent(); }

rPGameS

RPGMouseEventListener
mouseEnter()

RPGame
handleEvent()
stateS

GameState
handleEvent()

{ stateS.handleEvent(); }
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

User

eventTarget

:RPGame

:GameState

:RPGMouseEventListener
1. mouse action 2. mouseClicked()

3. handleEvent ( Event ) 4. handleEvent ( Event)

Sequence Diagram for Handling Mouse Events


Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

RPG Video Game Architecture Packages -showing domain classes only

RolePlayingGame
framework package

Characters
framework package

EncounterGame
application package

uses

EncounterCharacters uses
application package EncounterCharacter PlayerCharacter ForeignCharacter PlayerQualityWindow

EncounterGame

Engagement

EngagementDisplay

GameEnvironment
framework package

EncounterEnvironment
application package Area

uses

GameArtifacts
framework package

EncounterAreaConnection ConnectionHyperlink

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

MouseListener

EncounterGameDisplays

EncounterDisplayItem EncounterDisplay

EncounterCast
Detailed Design of EncounterGameDisplays Sub-package

QualListDispl

SetQualValueDispl

QualValueDispl Reporting
handleEvent()

EngagementDisplay
SetQualityDisplay
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Preparing
handleEvent()

User

:EngagementDisplay

Sequence Diagram for Dismissing Engagement Display


:ReportingEncounter :EncounterGame
3. handleEvent() 4. handleEvent()

1. hit dismiss button

:RPGMouse EventListener
2. mouseClicked()

5. setVisible( false )
6. setState (new Waiting())

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Sequence Diagram for Player Completes Setup


User :PlayerQualityWindow :SettingUp

1. hit dismiss button

:RPGMouse EventListener
2. mouseClicked()

:EncounterGame
3. handleEvent()
4. handleEvent()

5. setVisible( false ) 6. setState (new Waiting())

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

User :AreaConnectionHyperlink
1. hit area connection hyperlink

:EncounterCast

:Waiting

:RPGMouse EventListener
2. mouseClicked()

:EncounterEnvironment :EncounterGame
3. handleEvent() 4. handleEvent() 6. displayArea() 7. displayPlayerCharacter()

5. setVisible( false )

If foreign character present

Sequence Diagram for Player Moves to Adjacent Area

8. displayForeignCharacter() 9. setState (new Engaging())

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Detailed Design of EncounterCharacters Package


Characters
framework package

GameCharacter
EncounterCharacters
application package

EncounterCharacter

facade

PlayerCharacter

EncounterCast ForeignCharacter
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

EncounterEnvironment Package
GameEnvironment GameArea GameAreaConnection

GameCharacter

....

EncounterEnvironment Package
GameEnvironment GameArea GameAreaConnection GameCharacter

Area EncounterEnvironment

EncounterAreaConnection ConnectionHyperlink EncounterEnvironment

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.