6 design ii detailed design
Download
1 / 93

6. DESIGN II: DETAILED DESIGN - PowerPoint PPT Presentation


  • 264 Views
  • Updated On :

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '6. DESIGN II: DETAILED DESIGN' - sveta


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
6 design ii detailed design l.jpg

6. DESIGN II:DETAILED DESIGN


Software engineering roadmap chapter 6 focus l.jpg
Software Engineering Roadmap: Chapter 6 Focus

Develop Architecture

- see chapter 5

Identify

corporate

practices

Perform Detailed Design

- apply design patterns

- accommodate use cases

supply methods

- exploit libraries (STL, Java, …)

- describe methods where required

- develop detailed object models

- develop other models

Plan

project

Analyze

requirements

Maintain

Integrate

& test system

Design

Implement

Test units

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


Chapter learning goals l.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.



Relating use cases architecture detailed design l.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.”

2. Domain

classes

3. Architecure

Cable

Auto

Road

Pylon


Relating use cases architecture detailed design6 l.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.”

2. Domain

classes

3. Architecure

Cable

(not specifically required)

Auto

Road

Pylon

4. Detailed

Design

(added for detailed design)

Support use case

Auto

Cable

Guardrail

Road

Smith

Hill

Pylon

Jones Hollow

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


Typical roadmap for detailed design l.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)

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

. . . . .


Typical roadmap for detailed design8 l.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*

    • use case model

  • 2. Introduce classes & design patterns* which connect the architecture classes with the domain classes -- sections 1 and 5

    • concentrate on riskiest parts first; try alternatives

3. Refine models, make consistent, ensure complete

4. Specify class invariants* -- section 3.1

For each class ...

5. Specify methods with pre- and post-conditions, flowcharts* & pseudocode* -- sections 3 and 4

For each method ...

6. Sketch unit test plans -- see chapter 8

For each unit ...

7. Inspect test plans & design -- section 9

* if applicable

8.Release for implementation

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


Organize the team for detailed design 1 2 l.jpg
Organize the Team for Detailed Design 1/2

One way to ...

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

  • Ensure team members aware of the models (views) they are expected to produce

    • typically object model, sequence diagrams, state, & data flow

  • Ensure team members aware of the notation expected

    • typically: UML plus a pseudocode standard and/or example

  • Design leader prepares list of modules

  • Design leader creates a meeting agenda

  • Project leader allocates time to agenda items

    (people can speak about detailed designs indefinitely if allowed to!)

    • allocate the time among the agenda items

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


Organize the team for detailed design 2 2 l.jpg
Organize the Team for Detailed Design 2/2

One way to ...

2. Hold the kick-off meeting

  • Designate someone to monitor the agenda item time

  • Confirm that the architecture is ready for detailed design

    • Make sure that module interfaces the are clear

      • revise as a group if not

    • Don’t try to develop detailed designs as a group

      • not necessary: individuals have the responsibility

      • groups are seldom good at designing details together

  • Allocate modules to members

    • Request time estimates to design lead by a fixed date

  • Write out the conclusions and copy/e-mail every member

  • Decide how and when the results are to be reviewed

    3. Update the documentation set

  • more detailed schedule with modules & inspections

    4. Inspect the detailed designs

  • see figure TBD below

    5. Rework as a result of inspections

    6. Conduct post mortem and write out lessons learned

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


Unified software development process design l.jpg
Unified Software Development Process: Design

U. P. Term

Requirements

Analysis

Design

Implemen-

tation

Test

(Jacobson et al)

Inception

Elaboration

Construction

Transition

1*

Jacobson et al:

2

3

Prelim.

iterations

Iter.

#1

Iter.

#n

Iter.

#n+1

Iter.

#m

Iter.

#m+1

Iter.

#k

…..

…..

*Key: terminology used in this book

“Detailed

design”

1 =

“Requirements”

2 =

“Achitecture”

3 =


Analysis l.jpg

1. Conceptual & abstract

2. Applicable to several designs

1. Concrete: implementation blueprint

2. Specific for an implementation

Analysis

Design

1/2

After Jacobson

et al: USDP


Analysis13 l.jpg

1. Conceptual & abstract

2. Applicable to several designs

3. «control», «entity» & «boundary» stereotypes

4. Less formal

5. Less expensive to develop

1. Concrete: implementation blueprint

2. Specific for an implementation

3. No limit on class stereotypes

4. More formal

5. More expensive to develop ( 5×)

Analysis

Design

1/2

After Jacobson

et al: USDP


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

Design

2/2

After Jacobson

et al: USDP


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

Design

2/2

After Jacobson

et al: USDP


Designing against interfaces l.jpg
Designing Against Interfaces

Client code

Used code

Abstract layer

BillingClient

listCustomers()

billCustomers()

Customer

bill()

printAccounts()

-- written in terms of Customer (not specific types of Customer)

Concrete (non-abstract) layer

RegularCustomer

bill()

printAccounts()

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



Refine models for detailed design 1 2 sequence diagrams l.jpg
Refine Models for Detailed Design1/2: Sequence Diagrams

One way to ...

1. Begin with the sequence diagrams constructed for detailed requirements and/or architecture (if any) corresponding to the use cases.

2. Introduce additional use cases, if necessary, to describe how parts of the design typically interact with the rest of the application.

3. Provide sequence diagrams with complete details

  • be sure that the exact objects & their classes are specified

  • select specific function names in place of natural language

    (calls of one object to another to perform an operation)

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


Slide19 l.jpg

Refine Models for Detailed Design2/2: Data Flow Diagrams

One way to ...

1. Gather data flow diagrams (DFD’s) constructed for detailed requirements and/or architecture (if any).

2. Introduce additional DFD’s, if necessary, to explain data and processing flows.

3. Indicate what part(s) of the other models the DFD’s corresponds to.

  • e.g., “the following DFD is for each Account object”

    4. Provide all details on the DFD’s

  • indicate clearly the nature of the processing at each node

  • indicate clearly the kind of data transmitted

  • expand processing nodes into DFD’s if the processing description requires more detail

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


Sequence diagram for encounter foreign character use case l.jpg
Sequence Diagram for Encounter Foreign Character Use Case

:Encounter

game

:Encounter

Cast

freddie:

Foreign

Character

engagement:

Engagement

1.1 displayForeignChar()

:Engagement

Display

1.2 display()

1.3 new Engagement()

2. execute()

:Player’s

main

character

2.1 setPlayerQuality()

2.2 setQuality()

2.3 setForeignQuality()

3.1 new EngagementDisplay()

2.4 setQuality()

3.2 displayResult()

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


Classes of the encounterforeigncharacter use case l.jpg
Classes of the EncounterForeignCharacter Use Case

EngagementDisplay

displayResult()

Engagement

execute()

EncounterGame

PlayerCharacter

setQuality()

EncounterCast

displayForeignChar()

setPlayerQuality()

setForeignQuality()

ForeignCharacter

setQuality()

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


Detailed data flow diagram for a banking application l.jpg
Detailed Data Flow Diagram for a Banking Application

Customer.

getDetails()

Account.

getDeposit()

Cus-

tomer

User

. . . . .


Detailed data flow diagram for a banking application23 l.jpg
Detailed Data Flow Diagram for a Banking Application

Expand details

……..

Customer.

getDetails()

Account.

getDeposit()

Cus-

tomer

User

Account

Cus-

tomer

screen

template

unacceptable

ATM users

local

log

Deposit-

screen.

display()

Account.

getPass-

word()

Account.

verifyPass-

word()

status

Pass-

word

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



Slide25 l.jpg

Specify A Class

One way to ...

1. Gather the attributes listed in the SRS.

  • if the SRS is organized by class

    2. Add additional attributes required for the design.

    3. Name a method corresponding to each of the requirements for this class.

  • easy if the SRS is organized by class

    4. Name additional methods required for the design.

    5. Show the attributes & methods on the object model.

    6. State class invariants.

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


Specify a function l.jpg
Specify a Function

One way to ...

1. Note the section(s) of the SRS or SDD which this function (method) satisfies.

2. State what expressions the function must leave invariant.

3. State the method’s pre-conditions (what it assumes).

4. State the method’s post-conditions (its effects).

5. Provide pseudocode and/or a flowchart to specify the algorithm to be used.

  • unless very straightforward

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


Classes at detailed design l.jpg
Classes at Detailed Design

Canister

Class name

+ numCanisters: int

- numWafers: int

- size: float

Attribute: type

+: visible

from without

+ display()

- getNumSlotsOpen()

+ setStatus()

Operations

Responsibilities:

-- describes each

canister undergoing

fabrication

Place for

comments

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


Specifying functions withdraw in account l.jpg
Specifying Functions: withdraw() in Account

xI denotes an attribute;

xP denotes a function parameter;

x' is the value of x after execution;

X denotes a class constant

  • Invariant of withdraw():

    • availableFundsI = max( 0, balanceI )

. . . . .

*The function invariant is an additional pre- and post-condition


Specifying functions withdraw in account29 l.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

xI denotes an attribute;

xP denotes a function parameter;

x' is the value of x after execution;

X denotes a class constant

*The function invariant is an additional pre- and post-condition

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



Flowchart example l.jpg

Parameter & settings make

sense?

Flowchart Example

N

Y

Nominal path

Set _name to

“defaultName"

Parameter name too long?

N

Y

protected final void setName( String aName )

{

// Check legitimacy of parameter and settings

if( ( aName == null ) || ( maxNumCharsInName() <= 0 ) ||

( maxNumCharsInName() > alltimeLimitOfNameLength() ) )

{ _name = new String( "defaultName" );

System.out.println

( "defaultName selected by GameCharacter.setName()");

}

else

// Truncate if aName too long

if( aName.length() > maxNumCharsInName() )

_name = new String

( aName.getBytes(), 0, maxNumCharsInName() );

else // assign the parameter name

_name = new String( aName );

}

Set _name

to parameter

Truncate

name

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


An architecture for chaining l.jpg
An Architecture for Chaining

static ruleBase

static factList

Rule

addRule()

proveAntecedents()

forwardChain()

Fact

content

addFact()

proveBack()

consequent

1

1..n

antecedents

Set Fact.factList to the known facts

and a Rule.ruleBase to the known rules.

Create Fact object soughtFact

Execute soughtFact.proveBack( ruleBase );

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


Flowchart for soughtfact proveback rulebase l.jpg
Flowchart for soughtFact.proveBack( ruleBase )

soughtFact

in factList?

Y

N

Another rule R

with soughtFact as consequent?

Nominal path

Y

N

Apply

R.proveAntecedents()

Succeeded?

Y

N

Report TRUE

Report FALSE

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


Pseuodocode example l.jpg
Pseuodocode Example

  • FOR number of microseconds supplied by operator

    • IF number of microseconds exceeds critical value

      • Try to get supervisor's approval

      • IF no supervisor's approval

        • abort with "no supervisor approval for unusual

        • duration" message ENDIF ENDIF

See section tbd for inspection results of this pseudocode

. . . .


Pseuodocode example35 l.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.


Pseudocode extraction l.jpg
Pseudocode Extraction

  • //p FOR number of microseconds supplied by operator

  • for( int i = 0; i < numMicrosecs; ++I ) {

    • //p IF number of microseconds exceeds critical value

    • if( numMicrosecs >

    • XRayPolicies.CRITICAL_NUM_MICROSECS )

      • //p Try to get supervisor's approval

      • int supervisorMicrosecsApproval =

      • getApprovalOfSuperForLongExposure();

      • //p IF no supervisor approval

      • if( supervisorMicrosecsApproval <= 0 )

      • throw ( new SupervisorMicrosecsApprovalException() );

  • . . . . . . . . .

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


Advantages of pseudocode flowcharts l.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.


Disadvantages of pseudocode flowcharts l.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.



Apply design patterns in detailed design l.jpg
Apply Design Patterns in Detailed Design

One way to ...

1. Become familiar with the design problems solved by design patterns

  • at a minimum, understand the distinction among (C) creational vs. (S) structural vs. (B) behavioral patterns

    Consider each part of the detailed design in turn:

    2. Determine whether the problem has to do with (C) creating something complex, (S) representing a complex structure, or (B) capturing behavior

    3. Determine whether there is a design patterns that addresses the problem

  • try looking in the category identified (C, S, or B)

    • use this book and/or Gamma et al [Ga]

      4. Decide if benefits outweigh drawbacks

  • benefits usually include increased flexibility

  • drawbacks increased class complexity(?), less efficient(?)

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


Factory example l.jpg
Factory: Example

Factory design pattern

BiologicalCell

getNewCellObject()

Client

AnimalCell

getNewCellObject()

PlantCell

getNewCellObject()

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


Prototype example l.jpg
Prototype: Example

Client

_documentPrototype

Document

clone()

MyOfficeApplication

myMethod()

. . . . .

PurchaseOrderDocument

clone()

InvoiceDocument

clone()

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


Prototype example43 l.jpg
Prototype: Example

Client

Document

clone()

documentPrototypeS

MyOfficeApplication

myMethod()

Customer

clone()

customerPrototypeS

CashCustomer

clone()

CreditCustomer

clone()

PurchaseOrderDocument

clone()

InvoiceDocument

clone()

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


Prototype design pattern typical code 1 2 l.jpg
Prototype Design Pattern: Typical Code 1/2

public classMyOfficeApplication

{ private static Document documentPrototypeS;

private static Customer customerPrototypeS;

. . . .

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


Prototype design pattern typical code 1 245 l.jpg

public classMyOfficeApplication

{ private static Document documentPrototypeS;

private static Customer customerPrototypeS;

public MyOfficeApplication

( Document dProtopypeP, Customer cPrototypeP )

{ documentPrototypeS = dProtopypeP;

customerPrototypeS = cPrototypeP; }

public myMethod

{ . . . . // Need a new Document object:

Document d = documentPrototypeS.clone();

. . . . // Need a new Customer object:

Customer c = customerPrototypeS.clone(); . . .

PrototypeDesign Pattern: Typical Code 1/2

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

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


Prototype design pattern typical code 2 2 l.jpg
Prototype Design Pattern: Typical Code 2/2

abstract classDocument

{ protected Document clone();

}

. . . .


Prototype design pattern typical code 2 247 l.jpg
Prototype Design Pattern: Typical Code 2/2

abstract classDocument

{ protected Document clone();

}

public classInvoiceDocument

{ . . . .

protected Document clone()

{. . . . return new InvoiceDocument();

}

Customer has an

equivalent

hierarchy of

classes

implementing

clone()

public classPurchaseOrderDocument

{ . . . .

protected Document clone()

{. . . . return newPurchaseOrderDocument();

}

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


Abstract factory applied to encounter l.jpg
Abstract Factory Applied to Encounter

Client

1..n

EncounterEnvironment

EnvironmentFactory

getArea()

buildConnection()

Area

Level3Area

. . . . .

Level3Factory

getArea()

getAreaConnection()


Abstract factory applied to encounter49 l.jpg
Abstract Factory Applied to Encounter

Area getArea() {

return envFactory.getArea();

}

Client

EncounterEnvironment

getArea()

getConnection()

incrementLevel()

EnvironmentFactory

getArea()

getConnection()

envFactory

EncounterAreaConnection

1..n

Area

1..n

Level2Area

Level2AreaConnection

«create»

«create»

Level2Factory

getArea()

getAreaConnection()

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


Abstract factory applied to encounter50 l.jpg
Abstract Factory Applied to Encounter

Client

1..n

EncounterEnvironment

EnvironmentFactory

getArea()

getConnection()

Area

EncounterAreaConnection

Level1Area

Level2Area

Level3Area

Level1AreaConnection

Level2AreaConnection

Level3AreaConnection

«create»

Level1Factory

getArea()

getAreaConnection()

Level2Factory

getArea()

getAreaConnection()

Level3Factory

getArea()

getAreaConnection()

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


The basis for composite decorator structures l.jpg
The Basis for Composite & Decorator Structures

non-leaf node

leaf node

Component

“non-leaf nodes have one or more components”

“every object involved

is a Component object”

NonLeafNode

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


Composite decorator structures l.jpg
Composite & Decorator Structures

Composite: 1..n

Component

doIt()

Client

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 l.jpg
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 l.jpg
Adapter Design Pattern

Application

Adaptation

Legacy system

Financial

amount()

Principal

computeValue()

Client


Adapter design pattern55 l.jpg
Adapter Design Pattern

Application

Adaptation

Legacy system

Financial

amount()

Principal

computeValue()

FinancialAdapter

amount()

legacyAdaptee

Client

{ 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 l.jpg
Proxy Design Pattern After Gamma et al

BaseActiveClass

expensiveMethod()

cheapMethod()

Client

After Gamma et al

RealActiveClass

expensiveMethod()

cheapMethod()

Proxy

expensiveMethod()

cheapMethod()

_realActiveObject

. . .

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

Key: Intended sequence of Element objects

The Iterator Design Pattern

element:

Element

Aggregate of Element

objects

After first() executes, iterator references this object.

iterator:

Iterator

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 l.jpg
The Mediator Design Pattern

Encapsulates behavior among objects of a class so that they needn’t refer to each other.

Colleague

Mediator

ConcreteColleague1

ConcreteColleague2

ConcreteMediator

Gamma et al


The mediator design pattern59 l.jpg
The Mediator Design Pattern

Colleague

Mediator

ConcreteMediator

ConcreteColleague1

ConcreteColleague2

EncounterDisplay

EngagementDisplayItem

… Applied to Encounter

QualListDisp

QualValueDisp

SetQualitiesDisplay

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



Ieee 1016 1987 software design document table of contents reaffirmed 1993 l.jpg
IEEE 1016-1987 Software Design Document Table of Contents (Reaffirmed 1993)

1. Introduction

1.1. Purpose

1.2. Scope

1.3. Definitions, acronyms

& abbreviations

2. References

3. Decomposition description

3.1. Module decomposition

3.1.1 Module 1 description

3.1.1 Module 2 description

3.2 Concurrent process

decomposition

3.2.1 Process 1 description

3.2.2 Process 2 description

3.3 Data decomposition

3.3.1 Data entry 1 description

3.3.2 Data entry 2 description

4. Dependency description

4.1 Intermodule dependencies

4.2 Interprocess dependencies

4.3 Data dependencies

5. Interface description

5.1 Module interface

5.1.1 Module 1 description

5.1.2 Module 2 description

5.2 Process interface

5.2.1 Process 1 description

5.2.2 Process 2 description

6. Detailed design

6.1 Module detailed design

6.1.1 Module 1 detail

6.2.2 Module 2 detail

6.2 Data detailed design

6.2.1 Data entity 1 detail

6.2.2 Data entity 2 detail

Architecture


Java source with javadoc 1 2 l.jpg
Java Source with Javadoc 1/2 (Reaffirmed 1993)

  • /**

    • 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() ……..

  • ……..

  • /**

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


Java source with javadoc 2 2 l.jpg
Java Source with Javadoc 2/2 (Reaffirmed 1993)

  • /**

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



    Bring the project up to date after completing detailed design l.jpg
    Bring the Project (Reaffirmed 1993)Up-to-Date After Completing Detailed Design

    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

    One way to ...

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


    Estimate size time from detailed designs l.jpg
    Estimate Size & Time from Detailed Designs (Reaffirmed 1993)

    One way to ...

    1. Start with the list of methods

    • ensure completeness, otherwise underestimate will result

      2. Estimate the lines of code (LOC) for each

    • classify as very small, small, medium, large, very large

      • normally in ± 7% / 24% / 38% / 24% / 7% proportions

    • use personal data to covert to LOC

      • otherwise use Humphry’s table below

        3. Sum the LOC

        4. Covert LOC to person-hours

    • use personal conversion factor if possible

      • otherwise use published factor

        5. Ensure that your estimates of method sizes and time will be compared and saved at project end.

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


    Slide67 l.jpg

    CATEGORY (Reaffirmed 1993)

    Very small

    Small

    Medium

    Large

    Very 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)


    Normal distribution of medium small etc l.jpg
    Normal Distribution of “Medium”, “Small” etc. (Reaffirmed 1993)

    Approximate percentage of methods classified with this description

    7%

    VS

    -2

    Standard deviations from the mean


    Normal distribution of medium small etc69 l.jpg
    Normal Distribution of “Medium”, “Small” etc. (Reaffirmed 1993)

    Approximate percentage of methods classified with this description

    S

    M

    L

    7%

    24%

    38%

    24%

    7%

    VS

    VL

    -2

    -1

    0

    1

    2

    Standard deviations from the mean

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



    Inspect detailed designs 1 of 2 l.jpg
    Inspect (Reaffirmed 1993)‡ Detailed Designs 1 of 2

    One way to ...

    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.


    Inspect detailed designs 2 of 2 l.jpg
    Inspect Detailed Designs (Reaffirmed 1993)2 of 2

    7. Check detailed design for --

    • simplicity

      a design that few can understand (after a legitimate effort!) is expensive to maintain, and can result in defects

    • generality

      enables design of similar applications?

    • expandability

      enables enhancements?

    • efficiency

      speed, storage

    • portability

      8. Ensure all details are provided

    • only code itself is excluded as a “detail”

    • the detail work must be done eventually, and this is the best time to do it: don’t postpose

    One way to ...

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


    Slide73 l.jpg

    Severity (Reaffirmed 1993)

    Description

    Urgent

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

    High

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

    Medium

    Causes impairment of critical system functions, though a workaround solution does exist

    Low

    Causes inconvenience or annoyance

    None

    None of the above

    Table 6.2 IEEE 1044.1 Severity classification

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


    Slide74 l.jpg

    Severity (Reaffirmed 1993)

    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.


    Types of defects 1 ieee l.jpg
    Types of Defects (1) (Reaffirmed 1993)(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 l.jpg
    Types of Defects (3) (Reaffirmed 1993)

    • [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 l.jpg
    Types of Defects (4) (Reaffirmed 1993)

    • [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 l.jpg
    Types of Defects (5) (Reaffirmed 1993)

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


    Pseudocode for inspection l.jpg
    Pseudocode (Reaffirmed 1993)for Inspection

    • IFaQuality is not recognized

      • Log error to log file

      • Inform user qualities unchanged

  • ELSE

  • IFaQualityValue out of bounds

    • Log error to log file

    • Inform user qualities unchanged

  • ELSE

    • Set the stated quality to aQualityValue

    • Reduce the remaining qualities,

    • ... retaining their mutual proportion,

    • ... making the sum of qualities unchanged

  • ENDIF

  • ENDIF

  • 1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    setQuality() should be mentioned

    Make these preconditions; don’t check.

    Lacks detail on how to allocate the remaining quality values

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


    10 summary l.jpg

    10. Summary (Reaffirmed 1993)


    Summary of detailed design l.jpg
    Summary of (Reaffirmed 1993)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 l.jpg

    Case Study (Reaffirmed 1993)


    Detailed design of roleplayinggame package l.jpg
    Detailed Design of (Reaffirmed 1993)RolePlayingGame Package

    GameState

    handleEvent()

    RPGame

    handleEvent()

    state

    { state.handleEvent(); }

    . . . .


    Detailed design of roleplayinggame package84 l.jpg
    Detailed Design of (Reaffirmed 1993)RolePlayingGame Package

    MouseListener

    { rPGameS.handleEvent(); }

    rPGameS

    RPGMouseEventListener

    mouseEnter()

    GameState

    handleEvent()

    RPGame

    handleEvent()

    stateS

    { stateS.handleEvent(); }

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


    Sequence diagram for handling mouse events l.jpg
    Sequence Diagram for (Reaffirmed 1993)Handling Mouse Events

    User

    eventTarget

    :GameState

    :RPGame

    :RPGMouseEventListener

    1. mouse

    action

    2. mouseClicked()

    3. handleEvent

    ( Event )

    4. handleEvent

    ( Event)

    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 l.jpg
    RPG Video Game Architecture Packages -- showing domain classes only

    RolePlayingGame

    «framework package»

    Characters

    «framework package»

    EncounterGame

    «uses»

    «application package»

    EncounterCharacters

    «uses»

    EncounterGame

    Engagement

    «application package»

    EngagementDisplay

    EncounterCharacter

    GameEnvironment

    PlayerCharacter

    «framework package»

    ForeignCharacter

    EncounterEnvironment

    «uses»

    PlayerQualityWindow

    «application package»

    Area

    EncounterAreaConnection

    GameArtifacts

    ConnectionHyperlink

    «framework package»

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


    Detailed design of encountergamedisplays sub package l.jpg
    Detailed Design of classes onlyEncounterGameDisplays Sub-package

    MouseListener

    EncounterGameDisplays

    EncounterCast

    EncounterDisplayItem

    EncounterDisplay

    QualListDispl

    SetQualValueDispl

    QualValueDispl

    Reporting

    handleEvent()

    EngagementDisplay

    Preparing

    handleEvent()

    SetQualityDisplay

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


    Sequence diagram for dismissing engagement display l.jpg
    Sequence Diagram for classes onlyDismissing Engagement Display

    User

    :EngagementDisplay

    :RPGMouse

    EventListener

    1. hit

    dismiss

    button

    :ReportingEncounter

    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.


    Sequence diagram for player completes setup l.jpg
    Sequence Diagram for classes onlyPlayer Completes Setup

    User

    :PlayerQualityWindow

    :SettingUp

    :RPGMouse

    EventListener

    1. hit

    dismiss

    button

    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.


    Sequence diagram for player moves to adjacent area l.jpg
    Sequence Diagram for classes onlyPlayer Moves to Adjacent Area

    User

    :AreaConnectionHyperlink

    :EncounterCast

    :Waiting

    1. hit

    area

    connection

    hyperlink

    :RPGMouse

    EventListener

    :EncounterEnvironment

    :EncounterGame

    2. mouseClicked()

    3. handleEvent()

    4. handleEvent()

    5. setVisible( false )

    6. displayArea()

    7. displayPlayerCharacter()

    If foreign character present

    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 l.jpg
    Detailed Design of classes only EncounterCharacters Package

    Characters

    «framework package»

    GameCharacter

    EncounterCharacters

    «application package»

    EncounterCharacter

    PlayerCharacter

    «facade»

    EncounterCast

    ForeignCharacter

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


    Encounterenvironment package l.jpg
    EncounterEnvironment classes only Package

    GameEnvironment

    GameCharacter

    GameArea

    GameAreaConnection

    . . . .


    Encounterenvironment package93 l.jpg
    EncounterEnvironment classes only Package

    GameEnvironment

    GameCharacter

    GameArea

    GameAreaConnection

    Area

    EncounterAreaConnection

    EncounterEnvironment

    ConnectionHyperlink

    EncounterEnvironment

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


    ad