ComponentLevel Design - PowerPoint PPT Presentation

Loading...

PPT – ComponentLevel Design PowerPoint presentation | free to download - id: 90fd9-ZjY4O



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

ComponentLevel Design

Description:

Component-Level Design. Testing. Analysis/Specification. Requirements gathering ... Detailed design. Lots of different techniques. Most only works in a few places ... – PowerPoint PPT presentation

Number of Views:77
Avg rating:3.0/5.0
Slides: 26
Provided by: RalphEJ
Learn more at: http://www.cs.uiuc.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: ComponentLevel Design


1
Component-Level Design
Requirements gathering
Analysis/Specification
Architectural design
Component-level design
Coding
Testing
2
Design Noun
  • Refinement
  • Requirements
  • High-level design
  • Details
  • Information-hiding
  • Dont show everything
  • Reveal bit by bit
  • Modularity

3
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

4
Component Design
  • Structure techniques in book
  • flow charts
  • Nasi-Schneiderman diagrams
  • decision tables
  • pseudo-code
  • state machines

5
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

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

7
Decision table for recovery period
Conditions
1
4
2
5
3
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
T
F
F
T
F
F
F
Actions
x
x
x
x
x
8
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

9
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 gt May 13, 1993)
  • return 31.5
  • else return 39
  • ...

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

11
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

12
State diagram for stop light
30
R/Y
R/G
4
2
R/R
R/R
2
4
Y/R
G/R
Events are time delays, in seconds.
25
13
Pseudocode for stop light
  • Action Record integer wait, east, north
  • Action Actions1 .. 6
  • repeat forever
  • for I 1 to 6 do
  • setEast(actionsi.east)
  • setNorth(actionsi.north)
  • wait(actionsi.wait)
  • end for

14
State diagram for sockets
uninitialized
connect()
listen()
active
passive
disconnect()
newconn1()
newconn1()
isconnecting()
q0len!0
CONNECTING
isconnected()
isconnected()
qlen!0
isconnected()
CONNECTED
accept()
15
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

16
State Pattern
  • From Design Patterns

ConnectingState
SocketState listen() connect() newconn1() ...
Socket
ConnectedState
...
PassiveState
17
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

18
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

19
Design in XP
  • Much of the design gets created during
    refactoring.
  • Simple design
  • Code smells
  • Coding standards
  • Code communicates design

20
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

21
Keep System Simple
  • Decompose large classes
  • Variables that change together should stay
    together
  • Methods should be in class of variables that they
    access
  • Ask, dont tell.

22
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

23
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

24
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

25
  • 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
About PowerShow.com