1 / 15

Designing Software for Ease of Extension and Contraction

A Team One Presentation. Designing Software for Ease of Extension and Contraction. Bob Hazen Tim Santucci Chris Dahn. Motivation. Industry has produced (is still producing) a number of complaints Cannot produce a “proper subset” of functionality Extension requires major re-writes

march
Download Presentation

Designing Software for Ease of Extension and Contraction

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. A Team One Presentation Designing Software for Ease of Extension and Contraction Bob Hazen Tim Santucci Chris Dahn

  2. Motivation • Industry has produced (is still producing) a number of complaints • Cannot produce a “proper subset” of functionality • Extension requires major re-writes • Contraction requires major re-writes • Cannot customize systems due to lack of flexibility CS-575 Software Design, Team 1

  3. Obstacles to Expansion and Contraction • Lack of information hiding • Knowledge of component relationships • Single component, multiple functionality • Violation of “uses” hierarchical structure CS-575 Software Design, Team 1

  4. Program Families • Classical training involves “programming by flow-chart” • But, we’re designing for a changing environment • Runtime environment • Implementation differences • User demands • Designing for expansion and contraction leads to program families CS-575 Software Design, Team 1

  5. The Methodology • Minimal subsets and minimal increments • Interface definitions using information hiding • Design as virtual machines • “Uses” hierarchy CS-575 Software Design, Team 1

  6. Example – The Automated Kitchen • Minimal subsets and increments • Level 0 • Boil • Bake • Sauté • Refrigerate • Slice • Dice CS-575 Software Design, Team 1

  7. The Automated Kitchen continued... • Minimal subsets and increments • Level 1 • Make tea, coffee, soup • Toast bread, bagels • Bake muffins, pot roast • Sauté eggs, pancakes • Chill juice, fruit, preserve foods CS-575 Software Design, Team 1

  8. The Automated Kitchen continued... • Minimal subsets and increments • Level 2 • Prepare breakfast • Prepare lunch • Prepare dinner CS-575 Software Design, Team 1

  9. The Automated Kitchen continued... • Minimal subsets and increments • Level 3 • Prepare food CS-575 Software Design, Team 1

  10. The Automated Kitchen continued... • Interface definitions using information hiding • Level 0 • Slicing is done with ginsu or veg-o-matic • Boiling is done with gas, electric, coal or microwave • Level 1 • Coffee is prepared on stovetop or drip brew • Bread is made in oven or bread machine • Level 2 • Breakfast is instant or drip coffee and sauté eggs or microwave breakfast CS-575 Software Design, Team 1

  11. The Automated Kitchen continued... • Design as virtual machines • Coffee maker • Bread machine • Scramble eggs • Boil water CS-575 Software Design, Team 1

  12. } make breakfast Level i uses at least 1 program on i-1 and nothing higher than i-1 brew coffee scramble eggs make toast make pancakes } boil saute bake slice mix Level 0 uses no other program The Automated Kitchen finally! • “Uses” hierarchy CS-575 Software Design, Team 1

  13. “Uses” criteria • A is simpler for using B • B is not complicated for not using A • B defines a useful program without A • A is not a useful program without B CS-575 Software Design, Team 1

  14. What does all this mean? • Requirements plan for changing environment • There’s no such thing as a free lunch • Levels are defined by the “uses” relationship, not by modules • “Low level” operations work on known data structures • “Mid level” operations swap known data structures for similar data structures • “High level” operations create and destroy these data structures CS-575 Software Design, Team 1

  15. Questions CS-575 Software Design, Team 1

More Related