close

Вход

Забыли?

вход по аккаунту

?

Component-level Design

код для вставкиСкачать
CS427:
Software Engineering I
Darko Marinov
(slides from Ralph Johnson)
1
Grading info
пЃєProject: You are graded on how well you
follow your process (you decide XP or RUP)
пЃ№You must know it
пЃ№You must follow it
пЃ№You must prove you follow it
пЃёMake a log of what you do every day
пЃёInteract with your TA
Don’t forget the product!
пЃєPostpone HW2? For two days? For a week?
CS427
15-2
Today: Component-level design
Requirements gathering
Analysis/Specification
Architectural design
Component-level design
Coding
Testing
CS427
15-3
“Design”: Noun
пЃєRefinement
пЃ№Requirements
пЃ№High-level design
пЃ№Details
пЃєInformation-hiding
Don’t show everything
пЃ№Reveal bit by bit
пЃєModularity
CS427
15-4
“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
15-5
Component design
Numerous techniques
пЂ­ Flow charts
пЂґDecision tables
пЂ№Pseudo-code (Ch. 13 of Hamlet and Maybee)
пЂ№State machines (Ch. 14 of Hamlet and Maybee)
CS427
15-6
Decision tables
пЃєUsed to specify program with complex
conditions
пЃєMake it easy to see if any cases are
missing
пЃєCan be implemented with IF statements
CS427
15-7
Example requirement
IRS Publication 946: “The recovery period is
27.5 years for residential real property,
31.5 years for nonresidential 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.”
CS427
15-8
Decision table for recovery
period
Conditions
Real property
Residential
Placed before May 13, 1993
Railroad grading or bore
On Indian reservation
1
T
T
2
T
F
T
F
F
3
T
F
F
F
F
4
T
F
5
T
F
T
F
T
Actions
27.5 years
31.5 years
39 years
50 years
22 years
x
x
x
x
x
CS427
15-9
Pseudocode
Also known as “Program Design Language”
пЃєAdvantages
пЃ№Expressive and compact
пЃ№Can use any editor
пЃ№Sometimes can type-check/compile it
пЃєDisadvantages
пЃ№Must know the language
CS427
15-10
Pseudocode
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
15-11
Pseudocode
пЃєWorks well with refinement
пЃєWrite pseudo-code
пЃ№As comments
пЃ№With stubs
пЃєGradually implement it all
пЃєExecute and test as you go
CS427
15-12
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
15-13
State diagram for stop light
30
2
R/G
R/Y
R/R
4
R/R
2
4
Y/R
G/R
25
CS427
Events are time
delays, in seconds.
15-14
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
15-15
State diagram for sockets
uninitialized
listen()
passive
newconn1()
connect()
active
newconn1()
disconnect()
isconnecting()
qlen!=0
isconnected() CONNECTING
qlen!=0 isconnected()
isconnected()
accept() CONNECTED
CS427
15-16
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
15-17
State pattern
From “Design Patterns”
ConnectingState
Socket
SocketState
listen()
connect()
newconn1()
...
CS427
ConnectedState
...
PassiveState
15-18
Detailed design
пЃєLots of different techniques
пЃєMost only works in a few places
пЃєPseudocode works in most places, but
often there is a better technique
пЃєOften best to use code and skip detailed
design
CS427
15-19
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
15-20
Design in XP
Much of the design created during refactoring
пЃ№Simple design
Code “smells”
пЃ№Coding standards
пЃ№Code communicates design
CS427
15-21
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
15-22
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
15-23
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
15-24
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
15-25
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
15-26
Next: Modularity and abstraction
Read:
http://www.acm.org/classics/may96/
D.L. Parnas “On the Criteria To Be Used in
Decomposing Systems into Modules”
Optional:
http://www.toa.com/pub/abstraction.txt
CS427
15-27
Документ
Категория
Презентации
Просмотров
4
Размер файла
292 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа