1 / 25

Component-Level Design

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.

nuru
Télécharger la présentation

Component-Level Design

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Component-Level Design Requirements gathering Analysis/Specification Architectural design Component-level design Coding Testing CS427

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

  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 CS427

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

  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 CS427

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

  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 CS427

  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 > “May 13, 1993”) return 31.5; else return 39; } ... } CS427

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

  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 CS427

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

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

  14. State diagram for sockets uninitialized connect() listen() passive active disconnect() newconn1() newconn1() isconnecting() q0len!=0 CONNECTING isconnected() isconnected() qlen!=0 isconnected() CONNECTED accept() CS427

  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” CS427

  16. State Pattern • From “Design Patterns” ConnectingState SocketState listen() connect() newconn1() ... Socket ConnectedState ... PassiveState CS427

  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 CS427

  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 CS427

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

  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 CS427

  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, don’t tell.” CS427

  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 CS427

  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 CS427

  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 CS427

  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 CS427

More Related