component level design l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Component-Level Design PowerPoint Presentation
Download Presentation
Component-Level Design

Loading in 2 Seconds...

play fullscreen
1 / 25

Component-Level Design - PowerPoint PPT Presentation


  • 733 Views
  • Uploaded on

Component-Level Design. Requirements gathering. Analysis/Specification. Architectural design. Component-level design. Coding. Testing. “Design”: Noun. Refinement Requirements High-level design Details Information-hiding Don’t show everything Reveal bit by bit Modularity.

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 'Component-Level Design' - nuru


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
component level design
Component-Level Design

Requirements gathering

Analysis/Specification

Architectural design

Component-level design

Coding

Testing

CS427

design noun
“Design”: Noun
  • Refinement
    • Requirements
    • High-level design
    • Details
  • Information-hiding
    • Don’t show everything
    • Reveal bit by bit
  • Modularity

CS427

design verb
“Design”: Verb
  • Bounce from high-level to low-level
  • New requirements come after design is created
  • Design is created incrementally
    • As requirements are known
    • As better design ideas are invented
    • As design flaws are discovered

CS427

component design
Component Design

Structure techniques in book

  • flow charts
  • Nasi-Schneiderman diagrams
  • decision tables
  • pseudo-code
  • state machines

CS427

decision tables
Decision tables
  • Used to specify program with complex conditions
  • Makes it easy to see if any cases are missing
  • Can be implemented with IF statements

CS427

slide6
The recovery period is 27.5 years for residential real property, 31.5 years for non-residential real property placed in service before May 13, 1993, 39 years for non-residential real property placed in service after May 12, 1993, 50 years for railroad gradings and tunnel bores, except that nonresidential real property on an Indian reservation has a recovery period of 22 years.
decision table for recovery period
Decision table for recovery period

Conditions

1

2

3

4

5

Real property

Residential

Placed before May 13, 1993

Railroad grading or bore

On Indian reservation

27.5 years

31.5 years

39 years

50 years

22 years

T

T

T

T

T

T

F

F

F

F

T

F

F

F

T

F

F

F

T

Actions

x

x

x

x

x

CS427

pseudo code
Pseudo-code
  • Also known as “Program Design Language”
  • Advantages:
    • Expressive and compact
    • Can use any editor
    • (Sometimes) can compile it
  • Disadvantages:
    • Must know the language

CS427

pseudo code9
Pseudo-code

recoverPeriod(property) {

if (isReal(property)) {

if (isResidential(property)) return 27.5;

if (onReservation(property)) return 22;

if (isRailroad(property)) return 50;

if (property.date > “May 13, 1993”)

return 31.5;

else return 39;

}

...

}

CS427

pseudo code10
Pseudo-code
  • Works well with refinement
  • Write pseudo-code
    • as comments
    • with stubs
  • Gradually implement it all
  • Execute and test as you go

CS427

state machines fsm
State Machines (FSM)
  • Lots of theory
    • how to minimize number of states
    • how to merge state machines
    • how to tell whether two state machines are equal
  • Can generate code directly from state machines
    • but usually do not

CS427

state diagram for stop light
State diagram for stop light

30

R/G

R/Y

4

2

R/R

R/R

2

4

Y/R

G/R

Events are time delays, in seconds.

25

CS427

pseudocode for stop light
Pseudocode for stop light

Action = Record {integer wait, east, north}

Action: Actions[1 .. 6]

repeat forever

for I = 1 to 6 do

setEast(actions[i].east)

setNorth(actions[i].north)

wait(actions[i].wait)

end for

CS427

state diagram for sockets
State diagram for sockets

uninitialized

connect()

listen()

passive

active

disconnect()

newconn1()

newconn1()

isconnecting()

q0len!=0

CONNECTING

isconnected()

isconnected()

qlen!=0

isconnected()

CONNECTED

accept()

CS427

implementing socket
Implementing socket
  • Socket is an object
  • Actions are methods of the socket
  • State is stored in variable of the object
  • Each method uses IF statement to make sure socket is in the right state
  • When IF statements get too complicated, use “State Pattern”

CS427

state pattern
State Pattern
  • From “Design Patterns”

ConnectingState

SocketState

listen()

connect()

newconn1()

...

Socket

ConnectedState

...

PassiveState

CS427

detailed design
Detailed design
  • Lots of different techniques
  • Most only works in a few places
  • Pseudocode works most places, but often there is a better technique
  • Often best to use code and skip detailed design

CS427

design in xp
Design in XP
  • No required design documents
  • Developers talk about design, but write test cases and code
  • Need to design during:
    • estimating user stories
    • iteration planning (making engineering tasks)
    • at start of programming task
    • when task does not go well

CS427

design in xp19
Design in XP

Much of the design gets created during refactoring.

  • Simple design
  • Code smells
  • Coding standards
  • Code communicates design

CS427

keep system simple
Keep system simple
  • Small classes
    • 7 methods is very nice
    • 20 methods is a little large
    • 80 methods is horrible
  • Small methods
    • Smalltalk: 20 lines is large
    • Java: 40 lines is large
    • C++: 60 lines is large

CS427

keep system simple21
Keep System Simple
  • Decompose large classes
    • Variables that change together should stay together
    • Methods should be in class of variables that they access
    • “Ask, don’t tell.”

CS427

keep system simple22
Keep System Simple
  • Decompose large methods
    • Turn repeating code into new methods
    • Turn loop bodies into new methods
    • Turn complex conditions into new methods
    • Turn logical blocks into new methods, hiding temporaries

CS427

code design smells
Code (Design) Smells
  • Large classes, methods, packages
  • Duplication
  • Classes with no methods except accessors
  • One class with all the code
  • Complex conditionals and no polymorphism

CS427

good design
Good design
  • Good design is product of many small steps
  • “Do the right thing”
    • Each step adds a feature
    • Do one more thing right
  • “Do the thing right”
    • Each step makes design a little simpler
    • Eliminates one more unnecessary complexity

CS427

slide25
Next time:

http://www.acm.org/classics/may96/

On the Criteria To Be Used in Decomposing Systems into ModulesD.L. Parnas

http://www.toa.com/pub/abstraction.txt

CS427