Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

Similar presentations

Presentation on theme: "1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)"— Presentation transcript:

1 1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

2 CS42715-2 Grading info zProject: You are graded on how well you follow your process (you decide XP or RUP) yYou must know it yYou must follow it yYou must prove you follow it xMake a log of what you do every day xInteract with your TA yDon’t forget the product! zPostpone HW2? For two days? For a week?

3 CS42715-3 Today: Component-level design Testing Analysis/Specification Requirements gathering Architectural design Component-level design Coding

4 CS42715-4 “Design”: Noun zRefinement yRequirements yHigh-level design yDetails zInformation-hiding yDon’t show everything yReveal bit by bit zModularity

5 CS42715-5 “Design”: Verb zBounce from high-level to low-level zNew requirements come after design is created zDesign is created incrementally yAs requirements are known yAs better design ideas are invented yAs design flaws are discovered

6 CS42715-6 Component design Numerous techniques  Flow charts 4Decision tables 9Pseudo-code (Ch. 13 of Hamlet and Maybee) 9State machines (Ch. 14 of Hamlet and Maybee)

7 CS42715-7 Decision tables zUsed to specify program with complex conditions zMake it easy to see if any cases are missing zCan be implemented with IF statements

8 CS42715-8 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.”

9 CS42715-9 Decision table for recovery period 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 TT 142 T 53 Actions Conditions T T T T T F T FFF F F FFF F x x x x x

10 CS42715-10 Pseudocode zAlso known as “Program Design Language” zAdvantages yExpressive and compact yCan use any editor ySometimes can type-check/compile it zDisadvantages yMust know the language

11 CS42715-11 Pseudocode recoverPeriod(property) { if (isReal(property)) { if (isResidential(property)) return 27.5; if (onReservation(property)) return 22; if (isRailroad(property)) return 50; if ( > “May 13, 1993”) return 31.5; else return 39; }... }

12 CS42715-12 Pseudocode zWorks well with refinement zWrite pseudo-code yAs comments yWith stubs zGradually implement it all zExecute and test as you go

13 CS42715-13 State machines (FSM) zLots of theory yHow to minimize number of states yHow to merge state machines yHow to tell whether two state machines are equal zCan generate code directly from state machines yBut usually do not

14 CS42715-14 State diagram for stop light R/R R/YR/G Y/RG/R 2 25 4 2 30 4 Events are time delays, in seconds.

15 CS42715-15 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

16 CS42715-16 State diagram for sockets qlen!=0 active CONNECTING uninitialized CONNECTED passive qlen!=0 newconn1() isconnected() accept() newconn1() disconnect() isconnecting() isconnected() listen() connect()

17 CS42715-17 Implementing socket zSocket is an object zActions are methods of the socket zState is stored in variable of the object zEach method uses IF statement to make sure socket is in the right state zWhen IF statements get too complicated, use “State Pattern”

18 CS42715-18 State pattern zFrom “Design Patterns” Socket SocketState listen() connect() newconn1()... PassiveState ConnectingState ConnectedState...

19 CS42715-19 Detailed design zLots of different techniques zMost only works in a few places zPseudocode works in most places, but often there is a better technique zOften best to use code and skip detailed design

20 CS42715-20 Design in XP zNo required design documents zDevelopers talk about design, but write test cases and code zNeed to design during: yEstimating user stories yIteration planning (making engineering tasks) yAt start of programming task yWhen task does not go well

21 CS42715-21 Design in XP Much of the design created during refactoring ySimple design yCode “smells” yCoding standards yCode communicates design

22 CS42715-22 Keep system simple zSmall classes y7 methods is very nice y20 methods is a little large y80 methods is horrible zSmall methods ySmalltalk: 20 lines is large yJava: 40 lines is large yC++: 60 lines is large

23 CS42715-23 Keep system simple zDecompose large classes yVariables that change together should stay together yMethods should be in class of variables that they access y“Ask, don’t tell.”

24 CS42715-24 Keep system simple zDecompose large methods yTurn repeating code into new methods yTurn loop bodies into new methods yTurn complex conditions into new methods yTurn logical blocks into new methods, hiding temporaries

25 CS42715-25 Code (design) smells zLarge classes, methods, packages zDuplication zClasses with no methods except accessors zOne class with all the code zComplex conditionals and no polymorphism

26 CS42715-26 Good design zGood design is product of many small steps z“Do the right thing” yEach step adds a feature yDo one more thing right z“Do the thing right” yEach step makes design a little simpler yEliminates one more unnecessary complexity

27 CS42715-27 Next: Modularity and abstraction Read: D.L. Parnas “On the Criteria To Be Used in Decomposing Systems into Modules” Optional:

Download ppt "1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)"

Similar presentations

Ads by Google